【问题标题】:Decoding ARM instruction from GDB从 GDB 解码 ARM 指令
【发布时间】:2022-01-21 12:32:11
【问题描述】:

我想了解/解码我的 aarch64 设备上的 ARM 指令。

我有以下用 C 语言编写的代码:

void test_function(int a, int b, int c, int d) {
  int flag;
  char buffer[10];

  flag = 31337;
  buffer[0] = 'A';
}

int main() {
  test_function(1, 2, 3, 4);
}

gcc -g stack_example.cgdb -q ./a.out 生成以下程序集:

(gdb) disass main
Dump of assembler code for function main:
   0x00000000000016d4 <+0>:     stp     x29, x30, [sp, #-16]!
   0x00000000000016d8 <+4>:     mov     x29, sp
   0x00000000000016dc <+8>:     mov     w0, #0x1                        // #1
   0x00000000000016e0 <+12>:    mov     w1, #0x2                        // #2
   0x00000000000016e4 <+16>:    mov     w2, #0x3                        // #3
   0x00000000000016e8 <+20>:    mov     w3, #0x4                        // #4
   0x00000000000016ec <+24>:    bl      0x16a8 <test_function>
   0x00000000000016f0 <+28>:    mov     w0, wzr
   0x00000000000016f4 <+32>:    ldp     x29, x30, [sp], #16
   0x00000000000016f8 <+36>:    ret
End of assembler dump.
(gdb) disass test_function
Dump of assembler code for function test_function:
   0x00000000000016a8 <+0>:     sub     sp, sp, #0x20
   0x00000000000016ac <+4>:     str     w0, [sp, #28]
   0x00000000000016b0 <+8>:     str     w1, [sp, #24]
   0x00000000000016b4 <+12>:    str     w2, [sp, #20]
   0x00000000000016b8 <+16>:    str     w3, [sp, #16]
   0x00000000000016bc <+20>:    mov     w8, #0x7a69                     // #31337
   0x00000000000016c0 <+24>:    str     w8, [sp, #12]
   0x00000000000016c4 <+28>:    mov     w8, #0x41                       // #65
   0x00000000000016c8 <+32>:    strb    w8, [sp, #2]
   0x00000000000016cc <+36>:    add     sp, sp, #0x20
   0x00000000000016d0 <+40>:    ret
End of assembler dump.

当我现在做break 10break test_functionrundisass main 时,我明白了

(gdb) disass main
Dump of assembler code for function main:
   0x00000055907a86d4 <+0>:     stp     x29, x30, [sp, #-16]!
   0x00000055907a86d8 <+4>:     mov     x29, sp
   0x00000055907a86dc <+8>:     mov     w0, #0x1                        // #1
   0x00000055907a86e0 <+12>:    mov     w1, #0x2                        // #2
   0x00000055907a86e4 <+16>:    mov     w2, #0x3                        // #3
   0x00000055907a86e8 <+20>:    mov     w3, #0x4                        // #4
=> 0x00000055907a86ec <+24>:    bl      0x55907a86a8 <test_function>
   0x00000055907a86f0 <+28>:    mov     w0, wzr
   0x00000055907a86f4 <+32>:    ldp     x29, x30, [sp], #16
   0x00000055907a86f8 <+36>:    ret
End of assembler dump.

现在根据Arm Architecture Reference Manual Armv8, for A-profile architecture, page 934,BL 指令以 100101 开头,后跟一个 26 位立即数。

用yield检查程序计数器所在位置的内存

(gdb) x/16b 0x55907a86ec
0x55907a86ec <main+24>: 11101111        11111111        11111111        10010111        11100000        00000011        00011111        00101010
0x55907a86f4 <main+32>: 11111101        01111011        11000001        10101000        11000000        00000011        01011111        11010110

我认为,指令从第四个字节开始,但我不确定。我试图重建地址 0x55907a86a8,但无法重建。有人可以帮忙吗?

【问题讨论】:

  • 地址是相对于当前地址给出的。该指令以小端编码。应用这两个提示,您应该能够找到解决方案。
  • 正如 fuz 所说,偏移量是小端序,所以它是 11 11111111 11111111 11101111,它是十进制的 -17 并移动了 2。所以,你有 55907a86ec - (17 &lt;&lt; 2) = 0x55907a86a8

标签: c debugging assembly arm arm64


【解决方案1】:

AArch64 指令采用 little-endian 编码,因此如果您一次转储一个字节的代码,则每个 4 字节字的字节顺序将相反。因此,从您的输出中,您必须获取前 4 个字节,颠倒它们的顺序(但不要颠倒字节内的位),然后将它们连接起来。 (您可以通过 x/tw 0x55907a86ec 来让调试器为您执行此操作。)这给出:

10010111111111111111111111101111

实际上最高 6 位是操作码100101。直接是11111111111111111111101111。这是二进制补码中的负数(记住立即数是符号扩展的),值为-17-0x11。这个数字乘以 4(左移两位),得到-0x44 并添加到bl 指令本身的地址以找到分支目标。确实是0x00000055907a86ec - 0x44 = 0x55907a86a8,这是调试器显示给你的地址,也是test_function的第一条指令的地址。

注意ASLR 是在您开始运行程序时完成的,这就是为什么反汇编在run 之前和之后显示不同地址的原因。如果您在run 之后执行disassemble test_function,您应该会看到它从0x55907a86a8 开始。尽管如此,如果您查看预 ASLR 的反汇编,您会注意到 bl test_function 指令的地址(0x16ec)与 test_function 本身的地址(0x16a8)之间的相对位移是相同的-0x44。 (确实ASLR是以页为单位完成的,所以低12位是不变的。)

【讨论】:

  • 谢谢!我自己永远无法找到左移。我只能发现两个地址的偏移量 0x...EC - 0x...A8 = 0x44 = 68 和 -68=1111 1111 1111 1111 1111 1111 1011 1100 这确实是直接左移两次..为什么它不是编码为-68,而是-17?这对我来说似乎很神奇,我不明白为什么会这样,一个人必须先左移两次,但它似乎有效。参考文献中没有提示。
  • @jahro_me:架构参考手册确实(间接地)说发生了移位:解码显示imm26:'00',也就是说“附加两个零位”,相当于左移。在汇编器符号下,它说“它与该指令地址的偏移量在 +/-128MB 范围内,编码为 imm26 乘以 4。”原因很简单,它获得了两个有用的位。 AArch64 指令始终对齐到 4 个字节,因此如果在指令中对位移进行编码而没有移位,则低 2 位将始终为零并有效浪费。 [...]
  • @jahro_me:在这种情况下,您可以获得的最大位移将是 2^26 字节 = +/- 32 MB。通过移位,这些位不会被浪费,并且您可以获得高达 +/- 128 MB 的位移,这对于大型程序来说要好得多。本质上,两个低位可以被视为隐含的零,而不是在指令中实际编码。
  • 优秀。是的,我已经阅读了有关 bits(64) offset = SignExtend(imm26:'00', 64); 的信息完全有道理。我应该更仔细地阅读。最好的问候和感谢您的出色回答!
猜你喜欢
  • 2012-07-14
  • 1970-01-01
  • 1970-01-01
  • 2017-07-11
  • 1970-01-01
  • 1970-01-01
  • 2019-04-26
  • 1970-01-01
  • 2019-04-30
相关资源
最近更新 更多