2

I'm reversing a code that is heavily obfuscated. It uses opaque predicates, call stack tampering, junk code and control flow flattering. Call stack tampering uses indirect branches (push register / retn) calculated with complex operations at runtime. It seems near impossible to reverse engineer. What would be the correct way to deal with code that uses many obfuscation techniques? I know some people use dynamic symbolic execution but I want to know if there are other ways to deal with this. Here is an example of one obfuscated function hex-ray output:

1

Usually, I try to detect which obfuscator has been used. Knowing your enemy is the first step towards the victory. If you can detect the obfuscator, you may be lucky and find the corresponding "deobfuscator". You won't have the original source, but you'll significantly decrease the entropy and the noise.

A good starting point is to look at how the strings are handled. Every obfuscator has its own way to do that, and it could be a clear indicator.

Another place I usually look for is the binary initialization: each obfuscator bootstraps it's own helper functions in a different way.

When I am unlucky, I tend to rely on symbolic execution combined with dynamic analysis via ollydbg and radare2.

| improve this answer | |
1

To add on too Yennefer's wonderful and respectable answer:

Going through the memory segments can definitely help, a lot of times obfuscators will tamper with those. Giving a possible clue as to what the obfuscator is.

Also look at the imported functions, how do those look? Some obfuscators mess around with the IAT, and some of the functions inside of the IAT can be tampered with, but "signature" code from those functions can be found, which can lead to what the obfuscator is.

Sometimes, there is even pre-built programs lying around the web that can automatically deobfuscate the program for you.

Good luck! :-)

| improve this answer | |
  • I can see some function imports like VirtualQuery, Sleep, ExitProcess. As far as I know the obfuscation and the packer are coded by the owners of the game. Its a dll that unpacks the game. My goal is to understand how it unpacks the game and how it detects cheats, so basically I need to understand every line of assembly and doing that on obfuscated assembly seems near impossible. – Francisco Linan Jan 5 at 15:41
  • Well, usually obfuscators are built as a separate executable. Fully reversing an obfuscator is a VERY daunting task, when you don't have access to the obfuscator especially. Normally when people reverse stuff like this they just search for opcode patterns, and how it compares to whats in IDA disassembly, then make conclusions about the obfuscator from there. – Graham Jan 5 at 21:08
  • Usually, games in particular are protected as last step by using an in-process stub, or, if you when used in platforms, by an extrernal library. However cheat detection is usually part of the game itself, therefore you have to go through two rather different paths. – Yennefer Jan 5 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.