内联函数是否会使对已编译的二进制文件进行逆向工程变得更加困难？
那么基本上，除了可能的性能影响之外，内联函数是否会对从编译和链接的二进制文件中对程序进行逆向工程的难度产生重大影响？
我的意思是，应该是这样，因为 1) 破解者只是看到更多的机器指令，而不是很好理解的“调用 XXXXX”，他可能已经发现可以做某件事。 2）内联为编译器优化代码提供了更多可能性，这更加令人困惑，对吗？
另外，考虑到 inline 关键字只是对编译器的一个建议，这到底能产生多大的效果呢？我们应该打扰吗？我的意思是，当然他们最终会破解它，但如果通过如此简单的措施我们可以让破解者的生活变得更加困难，为什么不呢？
So basically, besides possible performance effects, does inlining functions have any considerable effect on how difficult it is to reverse-engineer the program from its compiled and linked binary?
I mean, it should be, since 1) the cracker just sees more machine instructions, instead of nice understandable "call XXXXX", which he may already have discovered to do a certain thing. and 2) inlining provides more possibilities for the compiler to optimize code, and that is even more obfuscation, right?
Also, considering the inline keyword is just a suggestion to the compiler, how much effect can this really have? Should we bother? I mean, of course they will crack it eventually, but if by such simple measures we can make the cracker's life harder, why not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
选择是否内联方法不应该基于逆向工程的容易程度。内联和非内联之间的差异可以忽略不计。
例外情况是，如果您有任何反盗版代码，则内联该代码，甚至使用宏来确保其“内联”，都可以帮助消除单点故障。
如果您对此感到担忧，我建议您研究一下在二进制文件上运行的混淆工具。
The choice to inline methods or not should not be based on how easy it is to reverse engineer. The difference between inlining and not will be negligible.
The exception is if you have any anti-piracy code, inlining that, or even using macros to ensure it's "inlined" can help remove a single point of failure.
If you're concerned about this, I suggest looking into obfuscation tools that operate on the binary.
它将降低你的输入和他的输出之间的相似性。不过，这通常不会对他的努力产生太大影响。
It will decrease the similarity between your input and his output. It generally won't have much effect on his efforts in general though.