如果 `objdump -d --start-address` 从 x86 指令的中间开始打印会发生什么？

Question

...换句话说，x86-64 是否是一个独特的可解码代码，无论我从哪里开始解码，最终总是会产生正确的反汇编代码？

假设这（基本事实）是 ELF 文件的一部分。 第一条指令有六个字节长，从 0x5de5a2 到 0x5de5a7：

  ...
  5de5a2:       0f 84 d0 00 00 00       je     5de678 <_ZN16DefNewGeneration22copy_to_survivor_spaceEP7oopDesc.constprop.0+0x138>
  5de5a8:       48 c1 e8 03             shr    rax,0x3
  5de5ac:       83 e0 0f                and    eax,0xf
  ...

如果我执行objdump -d --start-address=0x5de5a2 ，则 output 确实是正确的。

如果我故意传入一个将“拆分”第一条指令的起始地址，例如，let start-address=0x5de524，会发生什么情况？

这就是我得到的： objdump -d --start-adress=0x5de5a4 ：

  ...
  5de5a4:       d0 00                   rol    BYTE PTR [rax],1
  5de5a6:       00 00                   add    BYTE PTR [rax],al
  5de5a8:       48 c1 e8 03             shr    rax,0x3
  5de5ac:       83 e0 0f                and    eax,0xf
  ...

在这种特定情况下， 0x5de5a2: je 5de678被反汇编成垃圾，但幸运的是，0x56e5a8 之后的所有代码仍然被正确解码。

我想问的是，这是我可以一直依赖的财产吗？ 我可以让objdump在文本部分的任意起始地址开始反汇编 x86 ELF 文件，即使起始地址会拆分合法指令，但期望 objdump “最终”打印正确的反汇编代码吗？

附加问题：起始地址未对齐对反汇编正确性的影响有多大？ 此属性是否也适用于其他 ISA？

Answer 1

X86 代码不是自同步的，如果你在一个不是指令正确开始的地址开始反汇编，你可能会或可能不会在一些错误指令后得到好的代码，但这不是你可以指望的).

在 x86 的早期，甚至有人知道写代码依赖于 x86 代码的非自同步性质，会有故意命中指令中间的 jmp 指令等等。

有一些 ISA 是自同步的，特别是具有固定长度指令的机器根据定义几乎是自同步的。 我不知道有哪些机器像 x86 那样具有可变长度指令并且是自同步的，但我绝不是专家。

Answer 2

“最终”打印出正确的反汇编代码？

Nitpick：这已经是该起点的正确反汇编。 如果您跳到那里，这就是 CPU 将执行的内容。 x86 机器代码是一个字节 stream ，它不是自同步的（与 UTF-8 不同），没有任何东西将字节标记为不是指令的开始。 这与 GDB 不允许您在layout asm TUI 模式下向后滚动的原因相同，如果它附近没有要反汇编的符号。

但是您真正要问的是，是的，通常解码将与编译器在几条指令中预期的指令边界同步，在 objdump 首先工作的非混淆可执行文件中¹ 。 许多字节序列形成短指令，并且有相当多的 1 字节操作码，您可以在其他指令中找到其中一些作为立即数或 ModRM/SIB 字节。 （例如00 00是add [rax], al .）在 x86-64 中，一些字节当前未定义为操作码，因此反汇编程序通常反汇编为.byte xyz并将下一个字节视为可能的指令开始。 在 32 位模式下，其中大部分是 1 字节指令，其中一些是 2 字节（push/pop 段 regs 和 BCD 指令，如 AAA 或 AAM）。

手工制作的机器代码序列可能会在更长的时间内支持不同的解码，在 memory 的相同字节中叠加两个不同的指令序列。

相同的字节块从不同的起点解码不同的方式有时仍被用作混淆技术。 例如向前跳转 1 个字节，或向后跳转到已经以不同方式运行的内容。 通常其中一个执行并不是很有用，只是为了混淆反汇编程序。 （这对性能不利，尤其是在 L1i 缓存中标记指令边界的 CPU 以及具有 uop 缓存的 CPU 上。）

在极端的代码大小优化中（例如代码高尔夫或演示场景），诸如在进入循环的第一次迭代时跳过 4 个字节之类的东西可以用一个 1 字节的操作码来完成，用于test eax, imm32的开始，如Tips for golfing in x86/x64 机器代码

有关的：

• 指令解码器如何区分前缀和主要操作码？
• 考虑到指令长度不同，CPU 如何知道下一条指令应该读取多少字节？
• 是否可以反向解码 x86-64 指令？ （不明确。）
• 当由 x86 CPU 解释时，是否有更多的字节序列有效？ - 请参阅评论中关于与您所问内容基本相同的主题的讨论。

---

脚注 1：设计用于处理潜在混淆二进制文件的更复杂的反汇编程序将从某个入口点开始，然后直接跳转以找到其他起点进行反汇编，希望从有效起点覆盖.text部分的所有字节以执行。 间接跳转和从未采用的条件分支仍然可以欺骗他们。

GCC 和 clang 使 x86 可执行文件易于反汇编，在 GCC 的情况下，从字面上打印与.p2align指令混合的 asm 文本并将其组装。 我听说 MSVC 有时是/不是那么微不足道，但我忘记了细节。 现在 MSVC 只是在函数之间使用int3 (0xcc) 填充。

另请参阅为什么编译器将数据放在 PE 和 ELF 文件的 .text(code) 部分以及 CPU 如何区分数据和代码？ - 他们没有，请参阅我的回答，了解 x86 没有好处的原因。 .rodata可能与.text连续，但分开分组。 一个提议的二进制随机化器需要处理这个问题，因为混淆的可执行文件可能会这样做，而不是因为正常的编译器 output。

---

其他 ISA

ARM “文字池”在函数之间填充数据（因为有一个相对于 PC 的寻址模式，位移有限，所以它对常量很有用）。 对于 Thumb 模式的可变长度指令，如果数据恰好设置了表明它是 32 位指令的两个 16 位块中的第一个的位集，那么反汇编可能会有一点歧义，但它来了就在 function 开始之前。

大多数具有可变长度指令的现代 ISA 都比 x86 设计得更好，更容易解码，因为初始块采用一致的方式来表示它是更长指令的开始。 （例如 1 位像 Thumb，或者我认为 RV32C 或 Agner Fog 的纸上 ISA ForwardCom的多个位，如果我没记错的话。）

因此很容易恢复同步，但如果您从较长指令的第二个或后面的块开始，第一个解码可能仍然“很奇怪”。 与 UTF-8 不同，机器代码不会在每个块上花费一点来表示它是一个延续，而不是新指令的开始。 在 UTF-8 文本中查找很重要，但机器代码通常只是执行，因此设计选择不同。