I got a call from a close friend on Friday and the reason for the call was related to some possibly compressed file’s reversing and here is the reversing session I’have performed for him.
Let’s first talk a little about the environment because i generally use Kernel Debugger instead of a user one. Main reason behind is “I am used to kernel debugging and I really like the power of pausing the whole OS with just two keys:)” Don’t you think it’s great?
Actually my system is fine tuned for kernel debugging and I have all I need in place while using KD (all that scripts, symbols, paths and the other stuff).
So, first thing I generally do is placing a breakpoint at the OEP, which makes my target OS to break into KD as soon as it executes Entry point of the executable.
Following is the screen shot using CFF Explorer :
After running the executable, we find ourselves in the WinDBG. In order to fix what we did, replace the CC (int 3) with the original instruction (0xE8 in our case).
eb . 0xE8
Then we note the filename. What does this file have and how the Application uses it? This was the main question I was asked.
In order to be sure, I traced the application with Rohitab API Monitor and saw that everything is OK with a minor detail :
“ALL CreateFile calls return to same address 0x52E910” which means in our language : App has a wrapper function for CreateFile.
Most of the time I use IDA with WinDBG and support one with the other. They are both “best” in the field but when combined they become best of the best! Following script exports my current position in IDA as a well defined windbg break point.
After setting my break points for CreateFile I wrote a conditional break point command for properly stopping at “Turkey.poi” file access since there are a lot of CreateFile calls and then combined the IDA generated break point with my conditional windbg script file.
Following is the result of my conditional break point :
I let the CreateFile complete and noted down the file handle residing in EAX which was 0x1d4 in our case.
Then performed the same technique for ReadFile API.
Following is the call stack of ReadFile. There are a total of 12 stack frames. Our guy who is responsible for parsing that POI file must be residing somewhere here??? I have marked all these return addresses in the IDA for possible future use.
OK, now we need to get the buffer of ReadFile which is 0x15a9000
Just like CreateFile, read file also has a wrapper function :
Buffer was being saved into ECX. So ECX was my next target, after tracing ECX for some time, I noticed it was being saved into EAX.
As you can see from the image, App was trying to read and write some offsets of the buffer and surprise : XOR:)
After digging a little bit deeper, I was persuaded that I found the decryptor function and So I renamed it 🙂
I then dumped the first 0x1000 bytes by issuing the following command :
.writemem C:\\decrypted.dmp 0x15a9000 L1000
Then I checked the encryption algo. To tell the truth, I should have checked this before starting all this pain but I was told that the file was compressed which is why i did not check it with KANAL.