The CSAW Finals VMs were out a while ago and I for one was super happy they did that. So I downloaded all the challenges related to reversing (obviously :)) and started working on them.
The first one was a PE executable called csaw2013reversing3.exe. Initial notes showed that it was a small EXE at 7 KB, didn't have any strings to help you out and imported just 3 DLLs. Quickly loading up the program in IDA showed that Msgbox with a Flag popup was eventually called. So maybe it's not too big.
I learnt about something called rebasing during this challenge. Every EXE has something called an ImageBase. It's just a location in memory where the EXE starts loading itself into and starts running from. Now the Image Base in IDA is 400000 by default. So when I loaded the program in, I found that interesting functions started at 401030. This was fine. Now though I wanted to start running the binary in Olly, I don't particularly enjoy studying pure static disassembly listings.. ;)..
The moment I loaded it in Olly though...I couldn't find 401030 at all. It started loading at a number of random locations, which kept changing every time. So I started reading. Turns out, that Win 7 has ASLR (Address Space Layout Randomization) on by default. In short, this just means that the OS randomizes the locations that your program loads at..every time. So even if you tell your program to load at 400000 every time..the OS will say. Nope.. and load you elsewhere. I found this out by using a tool called CFF Explorer to edit and save the Image Base to 400000..which didn't work. So I ended up turning ASLR off for my reversing VM (Don't do this on any machine which matters to you..ASLR is a good thing to leave on :)). On a Win 7 machine, ASLR can be turned off by creating a key HKLM\SYSTEM
\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages and setting it to 0. Reboot to make sure - it's Windows :)
Ok good. Now Olly started loading at 400000 and I could see my functions in Olly and IDA - at the same places - easier. Stepping through the function quickly I found that srand() was called to seed the random number generator..so that rand() could be called later on and generate 2 random numbers - one at 40107D and one at 40110A.The last bit from both these is extracted and used as an input into a switch - case structure.
So the first switch-case structure is for hex 0-F and the second is for hex 0-7. A jump to that specific structure happens..based on input .. as follows.
Eventually there is a jump to a call at 401000 which performs some simple XOR operations and stores the result at a predefined memory location (decided by HeapCreate and HeapAlloc). As shown in the screen-shot below, the encrypted text is stored at 1DE07E0.
Right click on the highlighted location and click Follow in Dump to look at the content in the bottom pane as shown below. You can see this text changing after the CALL to 401000 is made.
The second switch case chooses a number between 0 and 7 and calls 401000 as before. It operates and stores content in the same location as before, acting on the encrypted text. Eventually a flag is popped up with the contents at 1DE07E0.
Notice that the text is all junk. It's certainly not the flag. This means that the numbers we chose were incorrect. Wait..what do you mean.."chose?". After all rand() was called..rt? I didn't choose anything. Well...it's a CTF - means you have to play with the output of rand and make it select the right numbers. Okay..let's think how to do this..
What do we have now? 1 switch case with 4 possible paths (one each for 0,1,2,3) and a 2nd switch case again with 4 paths (again for 0,1,2,3). This means there are a total of 16 possible paths if we call 401000 twice. The other options are to call 401000 only once..either for the first rand() call or the send rand() call. That's 4+4=8. And a total..of 24 cases. Here's a list of all possibilities:
Only Switch case 1 - 0,1,2,3
Only Switch case 3 - 0,1,2,3
Both switch cases - 00,01,02,03,10,11,12,13,20,21,22,23,30,31,32,33
The chances are that it's encrypted twice. That's just a guess from someone who's done a few challenges. It could well be wrong..but let's try. Remember we want the encryption to be called twice..
Set a breakpoint on 401093 and change EAX to 1 (I know this as I solved it :)) but you would try to get all those combinations in your switch case structure..and conclude. So lets change EAX to 1 and go in. Notice that there is a jump at 4010C9 which jumps right over the CALL 401000 which does the encryption. So there's something there..which we need to do...and force it to CALL 401000. What?
Look at 4010C3 - it's copying fs:30 + 2 into EAX. That location is the PEB (something every process has) and field 2 stores a flag which is set to 1 if we're inside a debugger. So EAX will have 1 after this statement. And the TEST EAX,EAX will fail (from our perspective) and we make the JMP at 4010C9. We want to NOT jump here but a little later..at 4010D1. So we need to tell the program that we're not inside a debugger. There's a few ways to do it... but I used the Olly Advanced Plugin for Olly 1.10 and checked the IsDebuggerPresent box. This clears the fs:30+2 bit...and makes it 0. The TEST EAX, EAX "succeeds" this time and we jump to 401103 instead and CALL 401000 and perform an operation on the encrypted text. Here you see that the bit is 0 and not 1.
The same logic repeats for the 2nd switch case, only this time we want to take the branch for 3,7 instead. Note that the fs:30+2 location is accessed there as well. Eventually you want to jump to 401179 and NOT 401180 so that the CALL 401000 is triggered.
The CALL is made and the encrypted text (which was already encrypted once) is "re-encrypted". Run the program now and look at the flag popup. Oops. Blank :(. No worry.. go to the actual location where the encrypted text is stored.
The first one was a PE executable called csaw2013reversing3.exe. Initial notes showed that it was a small EXE at 7 KB, didn't have any strings to help you out and imported just 3 DLLs. Quickly loading up the program in IDA showed that Msgbox with a Flag popup was eventually called. So maybe it's not too big.
I learnt about something called rebasing during this challenge. Every EXE has something called an ImageBase. It's just a location in memory where the EXE starts loading itself into and starts running from. Now the Image Base in IDA is 400000 by default. So when I loaded the program in, I found that interesting functions started at 401030. This was fine. Now though I wanted to start running the binary in Olly, I don't particularly enjoy studying pure static disassembly listings.. ;)..
The moment I loaded it in Olly though...I couldn't find 401030 at all. It started loading at a number of random locations, which kept changing every time. So I started reading. Turns out, that Win 7 has ASLR (Address Space Layout Randomization) on by default. In short, this just means that the OS randomizes the locations that your program loads at..every time. So even if you tell your program to load at 400000 every time..the OS will say. Nope.. and load you elsewhere. I found this out by using a tool called CFF Explorer to edit and save the Image Base to 400000..which didn't work. So I ended up turning ASLR off for my reversing VM (Don't do this on any machine which matters to you..ASLR is a good thing to leave on :)). On a Win 7 machine, ASLR can be turned off by creating a key HKLM\SYSTEM
\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages and setting it to 0. Reboot to make sure - it's Windows :)
Ok good. Now Olly started loading at 400000 and I could see my functions in Olly and IDA - at the same places - easier. Stepping through the function quickly I found that srand() was called to seed the random number generator..so that rand() could be called later on and generate 2 random numbers - one at 40107D and one at 40110A.The last bit from both these is extracted and used as an input into a switch - case structure.
So the first switch-case structure is for hex 0-F and the second is for hex 0-7. A jump to that specific structure happens..based on input .. as follows.
Eventually there is a jump to a call at 401000 which performs some simple XOR operations and stores the result at a predefined memory location (decided by HeapCreate and HeapAlloc). As shown in the screen-shot below, the encrypted text is stored at 1DE07E0.
The second switch case chooses a number between 0 and 7 and calls 401000 as before. It operates and stores content in the same location as before, acting on the encrypted text. Eventually a flag is popped up with the contents at 1DE07E0.
Notice that the text is all junk. It's certainly not the flag. This means that the numbers we chose were incorrect. Wait..what do you mean.."chose?". After all rand() was called..rt? I didn't choose anything. Well...it's a CTF - means you have to play with the output of rand and make it select the right numbers. Okay..let's think how to do this..
What do we have now? 1 switch case with 4 possible paths (one each for 0,1,2,3) and a 2nd switch case again with 4 paths (again for 0,1,2,3). This means there are a total of 16 possible paths if we call 401000 twice. The other options are to call 401000 only once..either for the first rand() call or the send rand() call. That's 4+4=8. And a total..of 24 cases. Here's a list of all possibilities:
Only Switch case 1 - 0,1,2,3
Only Switch case 3 - 0,1,2,3
Both switch cases - 00,01,02,03,10,11,12,13,20,21,22,23,30,31,32,33
The chances are that it's encrypted twice. That's just a guess from someone who's done a few challenges. It could well be wrong..but let's try. Remember we want the encryption to be called twice..
Set a breakpoint on 401093 and change EAX to 1 (I know this as I solved it :)) but you would try to get all those combinations in your switch case structure..and conclude. So lets change EAX to 1 and go in. Notice that there is a jump at 4010C9 which jumps right over the CALL 401000 which does the encryption. So there's something there..which we need to do...and force it to CALL 401000. What?
Look at 4010C3 - it's copying fs:30 + 2 into EAX. That location is the PEB (something every process has) and field 2 stores a flag which is set to 1 if we're inside a debugger. So EAX will have 1 after this statement. And the TEST EAX,EAX will fail (from our perspective) and we make the JMP at 4010C9. We want to NOT jump here but a little later..at 4010D1. So we need to tell the program that we're not inside a debugger. There's a few ways to do it... but I used the Olly Advanced Plugin for Olly 1.10 and checked the IsDebuggerPresent box. This clears the fs:30+2 bit...and makes it 0. The TEST EAX, EAX "succeeds" this time and we jump to 401103 instead and CALL 401000 and perform an operation on the encrypted text. Here you see that the bit is 0 and not 1.
The same logic repeats for the 2nd switch case, only this time we want to take the branch for 3,7 instead. Note that the fs:30+2 location is accessed there as well. Eventually you want to jump to 401179 and NOT 401180 so that the CALL 401000 is triggered.
The CALL is made and the encrypted text (which was already encrypted once) is "re-encrypted". Run the program now and look at the flag popup. Oops. Blank :(. No worry.. go to the actual location where the encrypted text is stored.
Yay :). You could also adjust ESI to ESI+1 by right clicking on ESI and saying Increment. Then the flag would be displayed in the popup box as well. Have fun.
No comments:
Post a Comment