blocks|key|3431728|text|我对perl了解不多，但我将举一些例子说明为什么将编译后的代码反向编译为汇编是如此丑陋。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3431729|逆向工程c代码最丑陋的一点是，编译过程会移除所有类型信息。完全缺乏名称和类型是IMO最糟糕的部分。|3431730|在动态类型语言中，编译器需要保存更多有关这方面的信息。尤其是字段/方法/的名称...因为这些通常是字符串，不可能找到所有用途。|3431731|还有很多其他丑陋的东西。例如每次使用不同的寄存器来传递参数的整个程序优化。函数是内联的，因此一个简单的函数出现在许多地方，通常由于优化而以略有不同的形式出现。|3431732|堆栈上的相同寄存器和字节被函数中的不同内容重用。堆栈上的数组变得特别丑陋。因为您无法知道数组有多大以及它在哪里结束。|3431733|然后还有一些微优化，这可能会让人感到恼火。例如，有一次我花了15分钟来逆转一个简单的函数，这个函数曾经类似于return+x/1600。因为编译器认为除法很慢，所以用一个常量将除法重写为几个乘法、加法和按位运算。|offset|length|style|CODE|3431734|entityMap^0|0|0|0|0|0|1I|D|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@$L|X|M|Y|N|O]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

I don't know too much about perl, but I'll give some examples why reversing code compiled to assembly is so ugly.

The ugliest thing about reverse engineering c code is that the compilation removes all type information. This total lack of names and types is very the worst part IMO. 
In a dynamically typed language the compiler needs to preserve much more information about that. In particular the names of fields/methods/... since these are usually strings for which it is impossible to find every use.

There is plenty of other ugly stuff. Such as whole program optimization using different registers to pass parameters every time. Functions being inlined so what was one a simple function appears in many places, often in slightly different form due to optimizations.

The same registers and bytes on the stack get reused by different content inside a function. Gets especially ugly with arrays on the stack. Since you have no way to know how big the array is and where it ends.

Then there are micro-optimizations which can get annoying. For example I once spend >15 minutes to reverse a simple function that once was similar to <code>return x/1600</code>. Because the compiler decided that divisions are slow and rewrote that division by a constant into several multiplications additions and bitwise-operations.

blocks|key|5032013|text|Perl非常容易reverse+engineer。选择的工具是vi、vim、emacs或记事本。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5032014|entityMap|0|LINK|mutability|MUTABLE|url|http://faq.perl.org/perlfaq3.html#How_can_I_hide_the_s^0|8|G|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Perl is really easy to <a href="http://faq.perl.org/perlfaq3.html#How_can_I_hide_the_s" rel="nofollow">reverse engineer</a>. The tool of choice is vi, vim, emacs or notepad.

blocks|key|5032111|text|这确实提出了一个问题，为什么他们担心逆向工程。将机器代码转换回与原始源代码相似的代码比通常的字节码更难，但对于大多数邪恶的活动来说，这是无关紧要的。如果有人想复制你的秘密或破坏你的安全，他们可以做得足够多，而不用把它变成你的原始源代码的完美表示。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5032112|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

That does raise the question about why they're worried about reverse engineering. It is more difficult to turn machine code back to something resembling the original source code than it is byte-code normally but for most nefarious activities that's irrelevant. If someone wants to copy your secrets or break your security they can do enough without turning it back into a perfect representation of your original source code.

blocks|key|1365209|text|虚拟机的逆向工程代码通常更容易。虚拟机通常被设计为容易成为语言的目标。这意味着它通常合理、简单、直接地表示该语言的结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1365210|但是，如果您要处理的VM不是为该特定语言设计的(例如，将Perl编译为JVM)，这通常会使您更接近于使用为实际硬件生成的代码--也就是说，您必须针对预定义的体系结构做任何必要的工作，而不是设计适合源代码的目标。|1365211|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Reverse engineering code for a virtual machine is usually easier. A virtual machine is typically designed to be an easy target for the language. That means it typically represents the constructs of that language reasonably easily and directly.

If, however, you're dealing with a VM that wasn't designed for that particular language (e.g., Perl compiled to the JVM) that would frequently put you back much closer to working with code generated for real hardware -- i.e., you have to do whatever's necessary to target a pre-defined architecture instead of designing the target to fit the source.

blocks|key|2035582|text|好的，多年来关于这个问题已经有了足够的争论；大多数情况下，结果永远不会是决定性的……主要是因为这无关紧要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2035583|对于一个有动力的逆向工程师来说，两者都是一样的。|2035584|如果您正在使用伪可执行文件生成器，如perl2exe，那么这将比编译C更容易“反编译”，因为perl2exe根本不编译perl，它只是有点“隐藏”(参见http://www.net-security.org/vuln.php?id=2464；这确实很旧，但概念可能仍然相同(我没有研究过，所以不确定，但我希望您能理解我的意思))。|offset|length|2035585|我建议看看哪种语言最适合这项工作，这样实际产品的维护和开发才能明智和可持续地完成。|2035586|记住你_can_not_阻止一个有动机的对手，你需要让它比自己写的代价更高。|2035587|这4个应该会让它变得困难(但同样也不是不可能)……|2035588|1插入无意义的数学和复杂数据结构交互的噪声代码(随机位置，随机代码)(如果处理得当，如果目的是颠倒代码而不是功能，这将是一个非常令人头疼的问题)。|2035589|2作为构建过程的一部分，在源代码上链接一些(不同的)代码混淆器。|2035590|3应用软件保护加密狗，如果硬件不存在，它将阻止代码执行，这意味着在可以进行其余的反向操作之前，需要物理访问加密狗的数据：http://en.wikipedia.org/wiki/Software_protection_dongle|2035591|4总有一些保护器(例如Themida+http://www.oreans.com/themida.php)可以在.exe构建后保护它(无论它是如何编译的)。|2035592|..。这应该会让倒车的人感到足够头疼。|2035593|但请记住，所有这些也会花费金钱，所以你应该总是权衡你试图实现的目标，然后看看你的选择。|2035594|简而言之:这两种方法都同样不安全。除非您正在使用非编译的perl-to-exe生成器，在这种情况下，本机编译的EXE将胜出。|2035595|我希望这能帮到你。|2035596|entityMap|0|LINK|mutability|MUTABLE|url|http://www.net-security.org/vuln.php?id=2464|1|http://en.wikipedia.org/wiki/Software_protection_dongle|2|http://www.oreans.com/themida.php^0|0|0|24|18|0|0|0|0|0|0|0|1O|1J|1|0|J|X|2|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1G|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1H|8|@]|9|@$F|1I|G|1J|1|1K]]|A|$]]|$1|H|3|I|5|6|7|1L|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1M|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1N|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1O|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1P|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1Q|8|@]|9|@$F|1R|G|1S|1|1T]]|A|$]]|$1|T|3|U|5|6|7|1U|8|@]|9|@$F|1V|G|1W|1|1X]]|A|$]]|$1|V|3|W|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|20|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|21|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|22|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|1A]]|1B|$5|16|17|18|A|$19|1C]]|1D|$5|16|17|18|A|$19|1E]]]]

Ok, there has been suficient debate on this over the years; and mostly the results are never conclusive ... mainly because it doesn't matter.

For a motivated reverse engineer, both will be the same.

If you are using pseudo exe makers like perl2exe then that will be easier to "decompile" than compiled C, as perl2exe does not compile the perl at all, it's just a bit "hidden" (see <a href="http://www.net-security.org/vuln.php?id=2464" rel="nofollow">http://www.net-security.org/vuln.php?id=2464</a> ; this is really old, but concept is probably still the same (I haven't researched so don't know for sure, but I hope you get my point) )

I would advise look at the language which is best for the job so maintenance and development of the actual product can be done sensibly and sustainably.

Remember you _can_not_ stop a motivated adversary, you need to make it more expensive to reverse than to write it themselves.

These 4 should make it difficult (but again not impossible)...

[1] Insert noise code (random places, random code) which does pointless maths and complex data structure interaction (if done properly this will be a great headache if the purpose is to reverse the code rather than the functionality).

[2] Chain a few (different) code obfuscators on the source code as part of build process.

[3] Apply a Software protection dongle which will prevent code execution if the h/w is not present, this will mean physical access to the dongle's data is required before rest of the reversing can take place : <a href="http://en.wikipedia.org/wiki/Software_protection_dongle" rel="nofollow">http://en.wikipedia.org/wiki/Software_protection_dongle</a>

[4] There are always protectors (e.g. Themida <a href="http://www.oreans.com/themida.php" rel="nofollow">http://www.oreans.com/themida.php</a>) you can get which will be able to protect a .exe after it has been built (regardless of how it was compiled).

... That should give the reverser enough headache.

But remember that all this will also cost money, so you should always weigh up what is it that you are trying to achieve and then look at your options.

In short: Both methods are equally insecure. Unless you are using a non-compiling perl-to-exe maker in which case native compiled EXE wins.

I hope this helps.

blocks|key|2032674|text|C语言比字节编译的Perl代码更难反编译。任何经过字节编译的Perl代码都可以反编译。字节编译的代码不像在编译的C程序中那样是机器码。其他一些人建议使用代码混淆技术。这些只是使代码更难读的技巧，不会影响反编译Perl源代码的难度。反编译的源代码可能更难阅读，但有许多Perl去混淆工具可用，甚至还有一个Perl模块：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2032675|http://metacpan.org/pod/B::Deobfuscate|offset|length|2032676|像Par、PerlAPP或Perl2exe这样的Perl打包程序也不能提供源代码保护。在某些情况下，必须提取源代码，以便Perl可以执行脚本。即使像PerlAPP和Perl2exe这样尝试在源代码上使用一些加密技术的打包程序，也可以用调试器击败：|2032677|http://www.perlmonks.org/?displaytype=print;node_id=779752;replies=1|2032678|它可以防止有人随意浏览您的Perl代码，但即使是打包程序也必须在脚本运行之前将其解压缩。任何有决心的人都可以得到源代码。|2032679|反编译C完全是另一回事。一旦编译完成，它现在就是机器码了。你要么用大多数C反编译器得到汇编代码，要么一些商业C反编译器会获取汇编代码并尝试生成等效的C代码，但除非它是一个真正简单的程序，否则很少能够重新创建原始代码。|2032680|entityMap|0|LINK|mutability|MUTABLE|url|http://metacpan.org/pod/B%253a%253aDeobfuscate|1^0|0|0|12|0|0|0|0|1W|1|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@$D|Y|E|Z|1|10]]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@$D|13|E|14|1|15]]|A|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|I]]]]

C is harder to decompile than byte-compiled Perl code. Any Perl code that's been byte-compiled can be decompiled. Byte-compiled code is not machine code like in compiled C programs. Some others suggested using code obfuscation techniques. Those are just tricks to make code harder to read and won't effect the difficulty in decompiling the Perl source. The decompiled source may be harder to read but there are many Perl de-obfuscation tools available and even a Perl module:

<a href="http://metacpan.org/pod/B%3a%3aDeobfuscate" rel="nofollow">http://metacpan.org/pod/B::Deobfuscate</a>

Perl packing programs like Par, PerlAPP or Perl2exe won't offer source code protection either. At some point the source has to be extracted so Perl can execute the script. Even packers like PerlAPP and Perl2exe, which attempt some encryption techniques on the source, can be defeated with a debugger:

<a href="http://www.perlmonks.org/?displaytype=print;node_id=779752;replies=1" rel="nofollow">http://www.perlmonks.org/?displaytype=print;node_id=779752;replies=1</a>

It'll stop someone from casually browsing your Perl code but even the packer has to unpack the script before it can be run. Anyone who's determined can get the source code.

Decompiling C is a different beast altogether. Once it's compiled it's now machine code. You either end up with Assembly code with most C decompilers or some of the commercial C decompilers will take the Assembly code and try to generate equivalent C code but, unless it's a really simple program, seldom are able to recreate the original code.

Have a client that's claiming complied C is harder to reverse engineer than sudo "compiled" Perl byte-code, or the like. Anyone have a way to prove, or disprove this?

Reverse engineer "compiled" Perl vs. C?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有一个客户声称编译后的C比sudo“编译”的Perl字节码或类似代码更难进行反向工程。有谁有办法证明或反驳这一点吗？

问反向工程“编译”Perl与C？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问反向工程“编译”Perl与C？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问反向工程“编译”Perl与C？
EN