encryption – Hiding the code of an * .exe file

Question:

How can you hide the code of an exe-file (written, for example, in Delphi) from decryption under the disassembler and, subsequently, from the reverse.

Strings, for example, can be simply XORed or shifted each character by k positions in the ASCII table (the first is better, IMHO). But how to hide function names or even entire blocks of code? After all, many developers (especially virus writers) like to do this, thereby hiding their "creations" from unauthorized research. In the same way, the well-known SpyEye is hiding from antiviruses. How can I achieve this?

Answer:

(I haven't done any reversing for a while, so the information may be outdated )

• If we talk about serious obfuscation, then it makes sense to consider only languages ​​that are compiled into machine code ( C++ , for example). Languages ​​with an intermediate bytecode layer are usually easily reversible and, apparently, there are no more or less adequate ways to protect applications written in them yet.

• Adequate protectors perform a certain sequence of actions to protect the finished application from reversing:

• They insert ready-made anti-debugging code fragments into the finished binary (for example, decrypting it at runtime) , confuse sections, make tricky jumps, in general, make atomic changes (that do not change the behavior of the program!) On the executable code, which make it difficult for humans to debug .

• A person is a reverse engineer who opens your application in IDA , visually pulls out familiar patterns from the disassembler listing, traces the application, replacing the contents of the stack and patching this application in its runtime.

• And the main purpose of these protective actions of the protector is to make the reverser say "Ugh, it went to hell , zadolbalo", since the sequence of actions of the protector can always be done in the opposite direction, there would be experience and knowledge.

• A more serious protection, sometimes stopping even tough and experienced reversers, is virtualization of the application code in order to execute it on its own virtual machine (usually combined with the standard anti-debugging techniques described above) . In this case, the virtual machine is injected into the binary along with some IL code, which may look absolutely arbitrary. The parameters of the created machine can also vary within certain limits – if you wish, you can write a virtual machine with ternary logic.

• The bonus of this approach is that for a full-fledged reversing of such an application, it is necessary to reproduce this very virtual machine in some way. In such a situation (if the virtual machine turns out to be tricky enough) , most of the standard tools and reverser techniques stop working out of the box. Which, again, brings this very potential reverser closer to the state of "Thanks, I've had enough."

• Themida protects in this way with precision down to detail .

• In accordance with the above – if there is a desire to protect your program more or less worthily, then write your virtual machine and generate IL code for it from the existing object files of your application. This action will help weed out most of the reversers who have recently been taught and shown what IDA and how to apply patch .

• Quick test – in order to understand if you can create more or less adequate protection with virtualization, try to break ESET's CrackMe. If you understand what SSE with the general verification mechanics, then you can get down to business.

• There is always a set of ready-made public and private packers that you can use. Themida , ASProtect , FSG. It is also clear that there will always be a set of people who are able to remove these or other protectors.