开发者

Application Reverse Engineering Protection / Hardening

开发者 https://www.devze.com 2023-01-05 09:38 出处:网络
I want to protect my applications from reverse engineering. What I would like to do is protect the executable from any tampering, such as with hex editors, resource editors, and dis-assembly tamperin

I want to protect my applications from reverse engineering.

What I would like to do is protect the executable from any tampering, such as with hex editors, resource editors, and dis-assembly tampering.

My idea is to have the application check the hash value of itself against an imported value in a version file from the service server (probably an xml file or flatfile开发者_如何学C), then shut down the application or somehow disable it's functionality completely if the values do not match.

I am in strange waters here, so if anyone has any comments, suggestions, ideas, or code examples, I would appreciate it.

The Development Language is C++ but I would happily take examples from any language.

Thanks in advance for any assistance.


I'm afraid it's not that easy.

If someone has the ability to modify the executable, then they have the ability to remove any check the application does against a known hash.

You can do more complicated things, such as encrypt the application's data using the hash of the known executable as the key, but that only makes it slightly more difficult to circumvent.


The makers of all kinds of very expensive software have been trying to come up with a solution to this for decades - and their efforts have always been worked around by people with far fewer resources.


The short answer is you can't. You can make it more difficult, but ultimately your code has to run on the processor, so the instructions can be read, modified or ignored on the fly.

If you can control the hardware, then you can make it harder, but ultimately if people are determined enough, they can break through whatever you do.

Appeal to people's honesty, it's easier for you and probably just as effective!


The most common way to do this simply is to use a packer. This is done in a lot of malware as well as some commercial software. There are standard packers like upx to do this post-compilation but any reverse engineer will get around this very easily.

Packers are used by commercial software as best effort obfuscation and to reduce the size of the binary via its compression capabilities. They are/were also used by (mostly) primitive malware. Careful here as many AV will flag your binary as malware just for recognizing the presence of packers and self modifying/obfuscated code.

Read up on the history and state of the art in malware/virus anti-debugging and packers/cryptors, there are a few Phrack magazine articles on this and resources on virus/malware research sites and forums. Just remember they are only speed bumps.

The only correct/undefeatable (non-speedbump) way to do this is by encrypting the code with a strong algorithm like AES and then decrypting it with a key at runtime- but then the user needs a key to run it. A pre-shared key/passphrase or the commercially popular dongle solution are the most common as mentioned earlier)

EDIT: most post-compilation packers and cryptors are language agnostic for the most part


The only solution that really prevents your software from being tampered is encrypting the executable and decrypting only that parts of it which are currently executed - and only if the decryption is done in a "trusted device", e.g. a USB dongle.

There are some products available which are pretty good, e.g. a product of my employer.

All software-only protection schemes can more or less easily be cheated.


Try obfuscating the code so that it would frustrate anyone trying to reverse-engineer it or have it self-destroy itself if anyone tried to tamper with it!

0

精彩评论

暂无评论...
验证码 换一张
取 消