当我们有反编译器时，为什么我们需要检测二进制文件？
Why we need to instrument binary when we have a decompiler?
我正在研究二进制检测技术，我发现许多论文声称当源代码不可用时二进制检测是必要的。
虽然我们可能无法获得原始源代码，但可以从反编译器中获得语义等效的源代码（如 RetDec），在我看来，这足以完成以前由二进制检测完成的许多任务，例如软件故障隔离。有时我们甚至不必将二进制文件反编译为源代码——LLVM IR 足以进行许多代码检测和分析。
而且性能可能会更好，因为之后我们仍然在中间端进行优化。
我的猜测是
(1) 对于大多数二进制检测任务，反编译器无法很好地恢复代码，或者
(2) 反编译器只能解码一小部分二进制文件，或者
(3) 反编译器恢复大库需要很长时间，但二进制检测只需要很短的时间。
我的猜测是否正确？
这里的事实是什么？
编辑：
在众多二进制检测任务中，我的重点主要放在内存地址隔离上，通常通过屏蔽地址或在程序集中设置保护区来完成。只是好奇，如果我们可以将二进制文件反编译为这样的表示，为什么不在 LLVM IR 级别添加一些检查代码。
基本上，问题在于反编译器 "incomplete" 因为它们无法处理所有可能的二进制文件。然后，对于反编译器和二进制检测，也存在确定二进制中的代码和数据的问题——这通常是不可确定的，您只想检测代码，而不是更改数据。
使用二进制检测，您可以更轻松地逐步处理这个问题，只检测您知道的代码，"instrumentation"执行可能会使已知代码中断并检测更多（或者当什么是被认为是代码被作为数据访问，"undo"访问的工具）。
与所有事物一样，存在性能折衷——最极端的检测是使用仿真器在提取信息的同时执行代码，但这样做的成本很高。通过插入断点或插入代码的部分检测成本要低得多，但不够完整。反编译和重新编译可能允许较低的运行时间成本但较高的前期成本。
我正在研究二进制检测技术，我发现许多论文声称当源代码不可用时二进制检测是必要的。
虽然我们可能无法获得原始源代码，但可以从反编译器中获得语义等效的源代码（如 RetDec），在我看来，这足以完成以前由二进制检测完成的许多任务，例如软件故障隔离。有时我们甚至不必将二进制文件反编译为源代码——LLVM IR 足以进行许多代码检测和分析。 而且性能可能会更好，因为之后我们仍然在中间端进行优化。
我的猜测是 (1) 对于大多数二进制检测任务，反编译器无法很好地恢复代码，或者 (2) 反编译器只能解码一小部分二进制文件，或者 (3) 反编译器恢复大库需要很长时间，但二进制检测只需要很短的时间。
我的猜测是否正确？ 这里的事实是什么？
编辑： 在众多二进制检测任务中，我的重点主要放在内存地址隔离上，通常通过屏蔽地址或在程序集中设置保护区来完成。只是好奇，如果我们可以将二进制文件反编译为这样的表示，为什么不在 LLVM IR 级别添加一些检查代码。
基本上，问题在于反编译器 "incomplete" 因为它们无法处理所有可能的二进制文件。然后，对于反编译器和二进制检测，也存在确定二进制中的代码和数据的问题——这通常是不可确定的，您只想检测代码，而不是更改数据。
使用二进制检测，您可以更轻松地逐步处理这个问题，只检测您知道的代码，"instrumentation"执行可能会使已知代码中断并检测更多（或者当什么是被认为是代码被作为数据访问，"undo"访问的工具）。
与所有事物一样，存在性能折衷——最极端的检测是使用仿真器在提取信息的同时执行代码，但这样做的成本很高。通过插入断点或插入代码的部分检测成本要低得多，但不够完整。反编译和重新编译可能允许较低的运行时间成本但较高的前期成本。