逆向工程有那么危险吗？
我花了几个小时阅读《逆向工程》，特别是与 C/C++ 和 Exif 文件格式相关的内容。
2 个我找不到明确答案的问题：
为什么要使用 Exif 格式？保持应用程序程序集暴露的原因是什么？难道就没有办法隐藏它，这样只有操作系统才能提取汇编代码来运行它吗？
如果我可以读取任何程序的汇编代码，那么为什么我不能执行以下示例：
打开 Excel 的 EXIF 文件，找到与检查程序激活相关的函数并使其始终返回 true？
I spent a couple of hours reading over Reverse Engineering Specifically with relation to C/C++ and Exif file formats.
2 Questions which I couldn't find clear answers for:
Why Exif format at all? what's the reason to keep application's assembly exposed? Isn't there anyway to hide it so only the OS can extract the assembly code to run it?
If I can read assembly code of any program so why can't I do the following as example:
Open EXIF file for excel, find the function related to check for activation of the program and make it always return true?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“exe”文件格式（可能是微软的PE32+文件格式）不包含任何汇编语言。相反，如果包含机器代码（CPU 执行的一堆数字）和数据；标题描述了程序的不同部分应该加载到内存中的位置。
机器代码通常可以被反汇编。可以通过多种方式来防止这种情况（自修改代码、跳到指令中间等巧妙技巧）；但大多数工具（例如 C 编译器、链接器等）不支持自修改代码或巧妙的技巧，因此它们大多仅在极端情况下使用（旨在迷惑调试器的手写程序集等）。
理论上可以防止反汇编的另一种方法是加密。可能是操作系统在第一次执行页面/代码片段时对其进行解密，并在一段时间内未使用解密的页面/代码片段时丢弃它们。任何操作系统都不支持此功能（据我所知）；可能是因为它的性能成本很高。
原始机器代码的反汇编不能只是“重新组装”回机器代码。如果修改机器代码，则可以更改原始程序（例如禁用激活检查）。然而，有一些方法可以防止这种情况，包括：
a) 数字签名。基本思想是，可执行文件的发布者创建其文件的安全散列（“大校验和”），然后使用私钥对结果进行加密；其他任何人（操作系统）也可以创建文件的安全散列，并将其与发布者的预期结果（使用发布者的公钥解密发布者的结果）进行比较，以确定文件在发布后是否被修改（以及如果被篡改则拒绝执行）。 Windows、MacOS、UEFI 安全启动等使用/支持此功能。
b) 没有返回“是或否”结果的激活函数（黑客很容易猜测要返回的“正确”值），但有一个返回更复杂内容的激活函数（例如，解密所需配置或机密数据所需的加密密钥），黑客几乎不可能猜测要返回的“正确”值。
c) 将激活检查从可执行文件转移到其他内容（动态链接/共享库、操作系统、互联网上的远程服务器等）。
The "exe" file format (which is probably Microsoft's PE32+ file format) does not contain any assembly language. Instead if contains machine code (a bunch of numbers that the CPU executes) and data; with headers describing where different pieces of the program should be loaded into memory.
The machine code can normally be disassembled. This can be prevented in multiple ways (self modifying code, clever tricks like jumping into the middle of an instruction); but most tools (e.g. C compilers, linkers, etc) don't support self modifying code or clever tricks so they're mostly only used in extreme cases (hand written assembly designed to confuse debuggers, etc).
Another method that could prevent disassembly in theory is encryption; possibly with the OS decrypting pages/pieces of code when they're first executed and discarding the decrypted pages/pieces of code when they haven't been used for a small while. This isn't supported by any OS (that I'm aware of); likely because it'd have a high performance cost.
A disassembly of the original machine code can't just be "re-assembled" back into machine code. If you modify the machine code then you can alter the original program (e.g. disable an activation check). However, there are ways to prevent this, including:
a) Digital signatures. The basic idea is that the publisher of an executable creates a secure hash ("a big checksum") of their file then encrypts the result with a private key; and anyone else (the OS) can also create a secure hash of the file and compare it to the expected result from the publisher (from decrypting the publisher's result using the publisher's public key) to determine if file was modified after it was published (and then refuse to execute it if it was tampered with). This is used/supported by Windows, MacOS, UEFI secure boot, etc.
b) Not having an activation function that returns a "yes or no" result (where it's easy for a hacker to guess the "right" value to return), but having an activation function that returns something more complex (e.g. an encryption key that is needed to decrypt needed configuration or confidential data) where it's almost impossible for a hacker to guess the "right" value to return.
c) Shifting the activation check out of the executable and into something else (a dynamically linked/shared library, the OS, a remote server on the Internet, etc).