“逆向工程”；“汇编”；Perl与C？

有一个客户机声称C比sudo“编译”Perl字节码等更难进行反向工程。有人有办法证明或反驳这一点吗

我对perl不太了解，但我将给出一些示例，说明为什么将编译的代码反向编译成汇编代码是如此难看

关于逆向工程c代码，最难看的是编译会删除所有类型信息。完全缺少名称和类型是我最糟糕的部分。
在动态类型化语言中，编译器需要保留更多关于该语言的信息。特别是字段/方法/的名称。。。因为这些通常是字符串，不可能找到每一个用途

还有很多其他丑陋的东西。例如每次使用不同的寄存器传递参数的整个程序优化。函数是内联的，所以一个简单的函数出现在许多地方，由于优化，通常以稍微不同的形式出现

堆栈上相同的寄存器和字节被函数中的不同内容重用。堆栈上的数组特别难看。因为您无法知道阵列有多大以及它的终点

---

还有一些微优化会让人恼火。例如，我曾经花费>15分钟来反转一个简单的函数，该函数曾经类似于

return x/1600

。因为编译器认为除法很慢，并将一个常数的除法重写为几个乘法、加法和位运算。

Perl非常容易实现。选择的工具是vi、vim、emacs或记事本。

虚拟机的逆向工程代码通常更容易。虚拟机通常被设计成该语言的一个简单目标。这意味着它通常可以简单直接地表示该语言的结构

---

但是，如果您正在处理的VM不是为该特定语言设计的（例如，编译到JVM中的Perl），这通常会使您更接近于使用为真实硬件生成的代码，即。，你必须做任何必要的事情来针对预定义的体系结构，而不是设计适合源代码的目标。

这确实提出了一个问题，即他们为什么担心逆向工程。将机器代码转换回类似于原始源代码的代码要比正常情况下的字节代码困难得多，但对于大多数邪恶的活动来说，这是不相关的。如果有人想复制你的秘密或破坏你的安全性，他们可以做得足够多，而不必把它变成你原始源代码的完美表现

好吧，多年来关于这一点一直有充分的争论；而且大部分结果都不是决定性的。。。主要是因为这无关紧要

对于一个积极的逆向工程师来说，两者都是一样的

如果您使用的是perl2exe之类的伪exe生成器，那么这将比编译的C更容易“反编译”，因为perl2exe根本不编译perl，它只是有点“隐藏”（请参阅；这确实很旧，但概念可能仍然相同（我还没有研究过，所以不确定，但我希望您理解我的观点））

我建议您考虑一下最适合这项工作的语言，这样实际产品的维护和开发就可以明智和可持续地进行

记住，你不能阻止一个有动机的对手，你需要让逆转比自己写更昂贵

这4个应该会让它变得困难（但也不是不可能）

[1] 插入噪声代码（随机位置，随机代码），它进行无意义的数学运算和复杂的数据结构交互（如果操作正确，如果目的是反转代码而不是功能，这将是一个非常头痛的问题）

[2] 作为构建过程的一部分，在源代码上链接几个（不同的）代码混淆器

[3] 应用软件保护加密狗，该加密狗将在不存在h/w的情况下阻止代码执行，这意味着在进行其余的反转之前，需要物理访问加密狗的数据：

[4] 你总是可以得到一些保护器（例如Themida），它们可以在.exe生成后保护它（不管它是如何编译的）

。。。这应该会让反转器头疼

但请记住，所有这些都会花费金钱，所以你应该经常权衡你想要实现的目标，然后再考虑你的选择

简而言之：这两种方法都同样不安全。除非您使用的是非编译perl-to-exe生成器，在这种情况下，本机编译的exe将获胜

---

我希望这能有所帮助。

C比字节编译的Perl代码更难反编译。任何经过字节编译的Perl代码都可以反编译。字节编译代码不像编译的C程序那样是机器代码。其他一些人建议使用代码混淆技术。这些只是使代码更难阅读的技巧，不会影响反编译Perl源代码的难度。反编译的源代码可能更难阅读，但有许多Perl解模糊工具可用，甚至还有一个Perl模块：

Perl打包程序（如PAR、PerlAPP或PerL2EXE）也不提供源代码保护。在某些时候，必须提取源代码，以便Perl可以执行脚本。即使像PerlAPP和Perl2exe这样试图在源代码上使用某些加密技术的打包程序，也可以通过调试器击败：

它将阻止某人随意浏览您的Perl代码，但即使是打包程序也必须在脚本运行之前解包。任何有决心的人都可以得到源代码

反编译C完全是另一回事。一旦编译完成，它现在就是机器代码了。你要么在大多数C反编译器中使用汇编代码，要么在一些商业C反编译器中使用汇编代码并尝试生成等效的C代码，除非它是一个非常简单的程序