如何保护 Exe 文件不被反编译

发布于 2024-11-27 01:41:05 字数 252 浏览 3 评论 0原文

保护Exe文件免受逆向工程的方法有哪些。有许多加壳器可以用来加壳exe文件。http://c-madeeasy.blogspot.com/2011/07/protecting-your-c-programexe-files-from.html

这种方法有效吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦幻的心爱 2024-12-04 01:41:14

目前有许多解决方案可用于保护您的应用程序免遭反编译。例如压缩、混淆、代码片段等。
您可以寻找一家公司来帮助您实现这一目标。

比如Nelpeiron，网站是：https://www.nalpeiron.com/
可以覆盖很多平台，Windows、Linux、ARM-Linux、Android。

另外Virbox也可以考虑：
网站是：https://lm-global.virbox.com/index.html
我推荐是因为他们有更多的选项来保护你的源代码，比如导入表保护、内存检查。

回复收藏 0 原文

阳光下慵懒的猫 2024-12-04 01:41:13

打包、压缩和任何其他二进制保护方法只会阻碍或减慢代码的逆转，它们从来都不是、也永远不会是 100% 安全的解决方案（尽管某些解决方案的营销会让您相信这一点）。您基本上需要评估您所面对的黑客的级别，如果他们是脚本小子，那么任何需要真正的努力和技能的加壳者（即：那些缺乏解包脚本/程序/教程的人））会阻止他们。如果您面对的是拥有技能和资源的人，那么您可以忘记保持代码安全（正如许多评论所说：如果操作系统可以读取它并执行它，您也可以，只是需要更长的时间）。如果您关心的不是您的 IP，而是您的程序所做的事情的安全性，那么您可能会更好地重新设计，使其即使使用原始源也无法受到攻击（chrome 采用这种方法）。

回复收藏 0 原文

我ぃ本無心為│何有愛 2024-12-04 01:41:13

反编译总是可能的。声明

可以通过打包/压缩来消除这种威胁
可执行文件（.exe）。

您链接的网站上是一个明显的谎言。

回复收藏 0 原文

木落 2024-12-04 01:41:12

防止程序被逆向工程（“理解”）的唯一好方法是修改其结构，从本质上迫使对手理解图灵机。本质上你要做的是：

采取一些通常被证明在计算上困难的问题
来合成一个你知道其结果的版本；与解决一个版本相比，这通常相当容易
使正确的程序执行取决于正确的答案，
如果答案不正确，则程序会毫无意义地计算

现在盯着你的代码的对手必须弄清楚“正确”的计算是通过解决算法难题。 40 年来，文献中存在大量 NP 难题，但无人有效解决；如果您的程序依赖于其中之一，那么 J. Random Reverse-Engineer 不会突然能够解决它们，这是一个很好的选择。

通常通过转换原始程序以掩盖其控制流和/或其数据流来实现这一点。一些技术通过将某些控制流转换为本质上的数据流（“通过该指针数组间接跳转”）来扰乱控制流，然后实现需要精确点分析的数据流算法，这既被证明是困难的，也被证明是困难的实践。

这是一篇论文，相当肤浅地描述了各种技术，但很容易阅读：
http://www.cs.sjsu.edu/faculty/stamp/students /kundu_deepti.pdf

这是另一个重点关注如何确保混淆转换产生保证可计算的结果难的：
http://www.springerlink.com/content/41135jkqxv9l3xme/

这是一项广泛调查多种控制流变换方式，
包括提供安全保证级别的那些：
http://www.springerlink.com/content/g157gxr14m149l13/

本文混淆了控制流低开销的二进制程序：
http://citeseerx.ist.psu.edu /viewdoc/summary?doi=10.1.1.167.3773&rank=2

现在，人们可能会经历很多麻烦防止程序被反编译。但如果反编译后的内容无法理解，你可能就不会费心了；这就是我会采取的方法。

如果您坚持阻止反编译，您可以通过考虑反编译的目的来解决这个问题。反编译本质上是建议您可以将目标程序的每个字节转换为一段代码。导致失败的一种方法是确保应用程序显然可以使用每个字节
作为计算机指令和数据，即使实际上没有这样做，并且这样做的决定被上述类型的方法混淆了。对此的一种变体是在代码中包含许多实际上是无条件的条件分支（使用控制流混淆方法）；分支的另一边落入看似有效的无意义代码，但分支到现有代码中的疯狂地方。这个想法的另一个变体是将您的程序实现为模糊解释器，并将实际功能实现为一组解释数据。
解决此问题的一个有趣方法是在运行时生成代码并即时执行；大多数传统语言（例如 C）几乎无法表示这一点。

像这样构建的程序很难反编译，更不用说事后理解了。

据称可以很好地保护二进制代码的工具列于：
https://security.stackexchange。 com/questions/1069/任何二进制代码保护和反逆向工程的综合解决方案

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

回复收藏 0 原文

~没有更多了~