Reversing - Windows Easy/Medium + Some Hard
Reverse Engineering Windows Easy and Medium Challenges and a little of the hard one
Last updated
Reverse Engineering Windows Easy and Medium Challenges and a little of the hard one
Last updated
I am not the best when it comes to reverse engineering and binary exploitation so this and next week will be a bit rough. But, I did solve the easy and the medium challenges for RE this week, struggled a bit too much with the hard and ran out of time available with work.
To start we get a Windows executable (.exe) file. I started by downloading it and opening it up in Ghidra. From here we can find the main function by going to the 'entry' section in exports on the symbol tree in Ghidra and finding the function just before the exit call.
Now that we had the main function we could dig in and see what was going on under the hood.
Upon entering the function we can see what looks like, and are, print functions. Along with those we can see what looks like a check to see if enough arguments are passed to run the next section (line 9). Following this check we have a function that takes in the user input and checks if it is the password/flag (We will get into that function in a minute). If the check fails it prints "You are not leet enough" and if it passes it will print "You achieved level 2!".
Now lets go through that checkPassword function and see how I knew it was a check, outside of the context clues.
Looking through we can see what looks to be hex characters for "flag" but its missing parts of it (come on Ghidra!) and then a string compare (line 55) checking the user supplied password/flag to the one in memory.
Now, to find this password we can easily get it by using a debugger like ollydbg, and that's what I did.
Above you can see the address (004012e2) that I chose to set the breakpoint at so that I could view what two strings are being compared (the user supplied flag and the actual flag) so that I can just snatch the actual flag.
Now with the breakpoint set I hit run and it paused right where I wanted...
And we have the flag in memory! Easy win!
Now we get to a little more difficult (not really though because we used a debugger on the last one)
Everything started out the exact same really with finding the main function and renaming everything to what it does.
I noticed the only real difference was how the password checking function worked.
I decided to try to just solve it the same way I had last time and loaded it into Ollydbg and, when setting a breakpoint on the string compare on (line 107), I didn't see the flag show up as a pointer to ascii text for the flag. This had me confused for a bit until I realized I needed to enable the ascii dump feature and then the flag was revealed in memory there.
Ok so I did not finish the hard challenge but I wanted to showcase where I got to when slamming my head against the wall.
It started the same as the last two challenges but with some minor changes to the main function.
We can see there is now a function checking for debuggers at runtime. I knew this because when exploring it we could see strings for "ollydbg.exe" and "immunitydebugger.exe" that were being checked against the current process list and if there's a match it exits.
To bypass this I renamed ollydbg.exe to ollydb.exe. Easy win. Now that we can get passed that function we need to see how it is checking the user supplied password.
Looking at the next function we can see that it is XORing the user supplied password and then comes the password checking function which is checking the now XORd user supplied flag against the XORd flag.
Now, my theory was that if I could manipulate which memory location was passed to the XOR function I could get it to XOR the already XORd flag and it would come out ascii. Well I either am getting the memory location wrong for the flag, which I am 99% im not, or it is doing something more complex than an XOR that I am missing. I guess I won't know until someone explains it to me later on.
