有哪些方法可以保护 exe 文件免受逆向工程的影响。许多打包程序可用于打包 exe 文件。http://c-madeeasy.blogspot.com/2011/07/protecting-your-c 中提到了这种方法-programexe-files-from.html
这种方法有效吗?
有哪些方法可以保护 exe 文件免受逆向工程的影响。许多打包程序可用于打包 exe 文件。http://c-madeeasy.blogspot.com/2011/07/protecting-your-c 中提到了这种方法-programexe-files-from.html
这种方法有效吗?
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:
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
打包、压缩和任何其他二进制保护方法都只会阻碍或减慢代码的反转,它们从来都不是,也永远不会是 100% 安全的解决方案(尽管有些营销会让你相信)。您基本上需要评估您所面对的黑客级别,如果他们是脚本儿童,那么任何需要真正努力和技能的打包者(即:那些缺乏解包脚本/程序/教程的人)会阻止他们。如果你面对的是有技能和资源的人,那么你可以忘记保护你的代码安全(正如许多评论所说:如果操作系统可以读取它来执行它,那么你也可以,只是需要更长的时间)。如果您关心的不是您的 IP,而是您的程序所做的某些事情的安全性,那么您可能会更好地以即使使用原始源也不会受到攻击的方式重新设计(chrome 采用这种方法)。
反编译总是可能的。该声明
可以通过打包/压缩可执行文件 (.exe) 来消除此威胁以进行扩展。
在您的链接网站上是一个明显的谎言。