Reversing iGo Navigation

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:)

I let the app modify the buffer and following is the result :

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

The decryption block uses multiple XOR’s which gives us clues about the underlying algorithm : It must be something similar to Blowfish because RC4 uses only one XOR.

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.

That is it for this week:) Thanks for reading!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s