This post is the continuation of the last one: http://www.behindthefirewalls.com/2013/11/hacklu-capturing-flag-v10.html


Remember that in the last post, we obtained the first password "r0b0RUlez!" for the challenge offered by Hack.lu. In this post, I am going to show you how to get the first and the second password using IDA Pro instead of OllyDbg. Ok, let's go...

In order to get the first password we can do a similar thing to we did in the previous post. (I am going to explain this swiftly because it was explained in the previous one).

If we set a breakpoint at "call strcnp" at 0x00401B6C, when the program is being debugged it will be stopped when it is comparing two strings, our password and the real one. After setting the breakpoint, press F9 in order to debug the program.



The program is open and we just need to type a password. In this case, "behindthefirewalls".


If we go to the Stack...


... we can see the the picture below.


  1. Our attempt to figure out the password
  2. The real password which the first one is being compared to.
  3. We are not sure about this string... Could it be the second password?
  4. String which will ask for the second password...
It seems too easy... We type the first password "r0b0RUlez!" which we already know is correct, and we try "u1nnf2lg" as second password...


But it does not work... The next step we can take is to set a breakpoint at "u1nnf2lg" "0x0023FDFC" in the stack, in order to stop the program at this address when it is being debugged and look at the code there... Just press F2 over the string to set the breakpoint.


After pressing OK, you will see a red line where the program will be stoped.


We debug the program again by pressing F9. It is necessary to type the first password again and then, the program will be stopped. But...


... the program has been debugged at, "0x0040161F" instead of "0x0023FDFC" where we set a breakpoint... What is happening? If we look at the assemble code in the picture below, we can see "int 3"... It seems that the software developer is trying to thwart our attempts to make a reverse engineer setting a breakpoint in its executable code source...


Don't worry, the pop up below appears. We need to click on "Change exception definition"...


... tick the "Pass to application"...


... and press OK and Yes and press F9 again.

After that the second password is required. We type for example "behindthefirewalls" and press F9 one more time.


Now, the program is stops at the right address, "0x0023FDFC".


If we look at the assemble code of the stack in a graphic, we can see the picture below where we can check that the program has been stopped at "cmp al, 2". We can see that there is a loop and a "xor eax, 2" instruction...


We can check that the EAX value is equal at 75 in hexadecimal which in ASCII is equal to "u" (the first character of "u1nnf2lg") and then it will be XOR with 0x02. 75 + 2 = 77 in hexadecimal is "w"... We can suppose the first character of the password could be "w"...


What would happen if we XORED with 0x02 the string "u1nnf2lg" which was found at the beginning of our post?

python -c "print ''.join([chr(ord(c) ^ 0x2) for c in 'u1nnf2lg'])"


We have the string "w3lld0ne" which seems to be the second password...


... and Yes!! We win!!!

If we analyze the loop we can say that it XOR with 0x02 character by character the string "u1nnf2lg" and the result is compared character by character with the typed password. If the first XORed character is the same as the first character typed by the user, then continue with the second one and so on... If not, the game is over...