是否可以使用无法反向工程化为其源代码的gcc创建目标文件？

评论

如果机器可以读取...人类也可以读取。您可以为人类增加难度...但是最后，他们仍然可以/仍会阅读它。
stackoverflow.com/questions/4111808/…，stackoverflow.com/questions/1025494/obfuscating-c-c-code

#1 楼

无法使用AFAIK。但是，您还需要牢记其他事项：

使用GCC优化标志将有助于使代码看起来不易被人类阅读。当您以最高级别的优化进行编译时，编译器会四处移动，以至于“流”可能根本达不到您的期望。

还可以使用标志gcc -O3，它将强制gcc采取小功能并将其内联。这会将它们嵌入到您的代码中，而不是显示为函数调用。这会使它们更难区分。

要记住的一件事是，除去任何不需要的符号也很重要。 Gcc提供了-static和-fvisibility=hidden来帮助解决此问题。您还可以将-fvisibility-inlines-hidden标志传递给gcc以删除符号。

我想您可以使用gcc来防止逆向工程。此外，您还可以使用代码混淆，但是除非您自己实现，否则还会有问题，如果使用易于使用的方法或工具来防止逆向工程，则可能已经有解决它的工具。

请记住，最终的可执行文件中将包含信息以及诸如使用哪个版本的gcc进行编译。也可以使用-s命令将其删除。

如果我有可执行文件（strip），则可以在其上运行myprog来检查一些信息：

mike@mike-VirtualBox:~/C$ objdump --full-contents --section=.comment myprog | head
myprog:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 20285562 756e7475 2f4c696e  GCC: (Ubuntu/Lin
 0010 61726f20 342e362e 332d3175 62756e74  aro 4.6.3-1ubunt
 0020 75352920 342e362e 3300               u5) 4.6.3.


糟糕，您可以看到什么我使用的版本/编译器。好吧，我们可以解决以下问题：

mike@mike-VirtualBox:~/C$ strip -R .comment -R .note myprog
mike@mike-VirtualBox:~/C$ objdump --full-contents --section=.comment myprog | head
objdump: 
section '.comment' mentioned in a -j option, but not found in any input file
myprog:     file format elf64-x86-64


还有其他一些部分也可以剥离，例如objdump，但确实失去了便携性

评论

我不建议剥离.note.ABI-tag，因为它会阻止在FreeBSD或其他具有Linux仿真支持的OS上运行可执行文件。

–伊戈尔·斯科钦斯基♦
13年3月20日在13:34
@IgorSkochinsky-有关可移植性的一个很好的说明，我当时并没有考虑过，但是现在进行了更新。谢谢。

–迈克
13年3月20日在14:45
剥离不会从obj文件中删除GCC版本...

–烛光
13年3月21日在9:08
顺便说一句，我不确定为什么对变量名的建议。如果操作正确，则最终二进制文件中应该没有变量名，除非可能是公开导出的变量名，而且通常确实需要具有正确的可读名。

–伊戈尔·斯科钦斯基♦
13年3月26日在17:56
伊戈尔是正确的。创建二进制对象时，这些名称应由编译器销毁。在那种情况下，没有区别。如果要运送带有重型调试符号的二进制文件，则比命名变量要麻烦得多。

–滚轴
13年3月27日在6:48

#2 楼

简短答案：否。

长期答案：关于Boaz Barak，Oded Goldreich，Rusell Impagliazzazzo，Steven Rudich，Amit Sahai，Salil Vadhan和Ke Yang混淆程序的（Im）可能性。 />
中等答案：如果将程序提供给控制程序执行平台的用户，则无法防止其反向工程。您唯一希望做的就是强迫用户对软件进行黑盒分析（这意味着用户将只能在选定的输入上观察程序的输出）。

但是，即使没有额外的硬件（例如智能卡），也很难实施这种黑箱分析，因为用户应该能够在程序执行期间获取内存的中间快照。

评论

有关硬件安全性的其他信息：Google“有机硅中没有秘密”

–迈克尔·安德森（Michael Anderson）
2013年3月20日14:07


不要忘记，在某些时候您也需要调试该死的东西。混淆和重新排列二进制文件的次数越多，如果在现场出现问题，分析起来就越困难。如果未混淆的版本工作正常，但由于无法预料的时间安排或混淆本身引入的其他交互作用，则混淆版本的BSOD变得尤为重要。

– Modoc
13年3月20日在15:37

#3 楼

好吧，可能无法将文件重新还原为确切的原始源代码（例如，无法恢复注释或预处理器宏），但这可能不是您要问的。

肯定总是这样可能（尽管有时很困难）产生等效的源代码，其行为与已编译的代码相同。通过一些额外的工作，甚至有可能产生可以编译为完全相同的字节码的代码（只要不对编译后的二进制文件进行额外的后处理）。此演示文稿描述了一些实现此目的的方法，但我找不到幻灯片。