How to Protect an Exe File from Decompilation

Question

What are the methods for protecting an Exe file from Reverse Engineering.Many Packers are available to pack an exe file.Such an approach is mentioned in http://c-madeeasy.blogspot.com/2011/07/protecting-your-c-programexe-files-from.html

Is this method efficient?

Answer 1

The only good way to prevent a program from being reverse-engineered ("understood") is to revise its structure to essentially force the opponent into understanding Turing Machines. Essentially what you do is:

• take some problem which generally proven to be computationally difficult
• synthesize a version of that whose outcome you know; this is generally pretty easy compared to solving a version
• make the correct program execution dependent on the correct answer
• make the program compute nonsense if the answer is not correct

Now an opponent staring at your code has to figure what the "correct" computation is, by solving algorithmically hard problems. There's tons of NP-hard problems that nobody has solved efficiently in the literature in 40 years; its a pretty good bet if your program depends on one of these, that J. Random Reverse-Engineer won't suddenly be able to solve them.

One generally does this by transforming the original program to obscure its control flow, and/or its dataflow. Some techniques scramble the control flow by converting some control flow into essentially data flow ("jump indirect through this pointer array"), and then implementing data flow algorithms that require precise points-to analysis, which is both provably hard and has proven difficult in practice.

Here's a paper that describes a variety of techniques rather shallowly but its an easy read: http://www.cs.sjsu.edu/faculty/stamp/students/kundu_deepti.pdf

Here's another that focuses on how to ensure that the obfuscating transformations lead to results that are gauranteed to be computationally hard: http://www.springerlink.com/content/41135jkqxv9l3xme/

Here's one that surveys a wide variety of control flow transformation methods, including those that provide levels of gaurantees about security: http://www.springerlink.com/content/g157gxr14m149l13/

This paper obfuscates control flows in binary programs with low overhead: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.167.3773&rank=2

Now, one could go through a lot of trouble to prevent a program from being decompiled. But if the decompiled one was impossible to understand, you simply might not bother; that's the approach I'd take.

If you insist on preventing decompilation, you can attack that by considering what decompilation is intended to accomplish. Decompilation essentially proposes that you can convert each byte of the target program into some piece of code. One way to make that fail, is to ensure that the application can apparently use each byte as both computer instructions, and as data, even if if does not actually do so, and that the decision to do so is obfuscated by the above kinds of methods. One variation on this is to have lots of conditional branches in the code that are in fact unconditional (using control flow obfuscation methods); the other side of the branch falls into nonsense code that looks valid but branches to crazy places in the existing code. Another variant on this idea is to implement your program as an obfuscated interpreter, and implement the actual functionality as a set of interpreted data. A fun way to make this fail is to generate code at run time and execute it on the fly; most conventional languages such as C have pretty much no way to represent this.

A program built like this would be difficult to decompile, let alone understand after the fact.

Tools that are claimed to a good job at protecting binary code are listed at: https://security.stackexchange.com/questions/1069/any-comprehensive-solutions-for-binary-code-protection-and-anti-reverse-engineeri

Answer 2

Packing, compressing and any other methods of binary protection will only every serve to hinder or slow reversal of your code, they have never been and never will be 100% secure solutions (though the marketing of some would have you believe that). You basically need to evaluate what sort of level of hacker you are up against, if they are script kids, then any packer that require real effort and skill (ie:those that lack unpacking scripts/programs/tutorials) will deter them. If your facing people with skills and resources, then you can forget about keeping your code safe (as many of the comments say: if the OS can read it to execute it, so can you, it'll just take a while longer). If your concern is not so much your IP but rather the security of something your program does, then you might be better served in redesigning in a manner where it cannot be attack even with the original source (chrome takes this approach).