3

Recently I have found the article Using UPX as a Security Packer. Here, UPX is patched, after decompressing, also restores some overwritten bytes. This way, if somebody decompresses the binary with upx -d in order to analyse it, will obtain a nonworking binary. An other solution to prevent static analysis is to encrypt a part of the code and decrypt it at runtime using mprotect from C.

So actually both methods can be used to encrypt code, the only difference being, that in the first case the elf entry point is modified, and the stub restores the original code, in the second case the execution starts from the original entry point. The latter method seems to be more simple. If I want to protect my binary from disassembling, does the second method has any disadvantage compared to the first one? I think without antidebugging tricks both methods can be reversed the same way, and when decrypting is done memory can be dumped.

4

If I want to protect my binary from disassembling, does the second method has any disadvantage compared to the first one?

The second method requires that you have access to the source code¹, whereas you can apply the first method if all you have is the binary.

However, before employing either (or both) of these methods, keep in mind that they're both trivial to overcome via dynamic reverse engineering.

¹ You don't actually need the source code, but it's a much bigger pain to apply the first method relative to the second if you don't have the source code.

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.