调试剥离的 ARM 二进制文件答案

【问题标题】：Debugging a stripped ARM binary调试剥离的 ARM 二进制文件
【发布时间】：2014-03-06 07:16:14
【问题描述】：

我用Hopper 反汇编了一个剥离的ARM 二进制文件，并找到了我感兴趣的方法的地址0x00065414。但是，当使用 gdb 连接到正在运行的应用程序时，所有地址都从我无法弄清楚的基地址开始。如何在 gdb 中确定我正在运行的应用程序基地址（入口点？）？

注意事项

使用Clutch 删除了二进制文件的 FairPlay DRM
通过使用a python script 清除 PIE 标头标志删除了 ASLR
使用 otool 验证更改

GDB 设置

$ gdb ./MyApplication
(gdb) attach -waitfor MyApplication

启动应用程序并在启动时立即暂停。

(gdb) where
#0  0x3bbcdb88 in <redacted> ()
#1  0x3bbbc8fc in <redacted> ()
#2  0x3bbc4130 in <redacted> ()
#3  0x3bbc4014 in ccpbkdf2_hmac ()
#4  0x3bb9f9d0 in CCKeyDerivationPBKDF ()
#5  0x0015b750 in dyld_stub_pthread_key_create ()
#6  0x0015ca46 in dyld_stub_pthread_key_create ()
#7  0x0015c69c in dyld_stub_pthread_key_create ()
#8  0x0015b4d0 in dyld_stub_pthread_key_create ()
#9  0x0015c110 in dyld_stub_pthread_key_create ()
#10 0x0001695a in dyld_stub_pthread_key_create ()
#11 0x000ba256 in dyld_stub_pthread_key_create ()
#12 0x00017bde in dyld_stub_pthread_key_create ()
#13 0x33b9eaac in <redacted> ()
#14 0x33b9e4f2 in <redacted> ()
#15 0x33b98b40 in <redacted> ()
#16 0x33b33a06 in <redacted> ()
#17 0x33b32cfc in <redacted> ()
#18 0x33b98320 in <redacted> ()
#19 0x3601876c in <redacted> ()
#20 0x36018356 in <redacted> ()
#21 0x31374776 in <redacted> ()
#22 0x31374712 in <redacted> ()
#23 0x31372ede in <redacted> ()
#24 0x312dd470 in CFRunLoopRunSpecific ()
#25 0x312dd252 in CFRunLoopRunInMode ()
#26 0x33b975c2 in <redacted> ()
#27 0x33b92844 in UIApplicationMain ()
#28 0x0001aaf2 in dyld_stub_pthread_key_create ()
#29 0x00009028 in dyld_stub_pthread_key_create ()

检查不同位置是否有预期的指令，以便设置断点：

(gdb) disas 0x65414
No function contains specified address.

我假设正确的位置是一些 + 0x65414。所以我尝试了以 UIApplicationMain 为基础的 0x33b92844。

(gdb) disas 0x33BF7C58
Dump of assembler code for function <redacted>:
0x33bf7934 <<redacted>+0>:  f0 b5                         push  {r4, r5, r6, r7, lr}

这个地址肯定是在编辑或符号剥离代码的土地上，但地址不会让你进入程序边界。所以这不是正确的地方。

【问题讨论】：

反汇编二进制文件。
@dwelch 二进制文件已使用 Hopper 反汇编。地址空间肯定与运行时不同。

标签： objective-c gdb arm reverse-engineering

【解决方案1】：

你可以试试：

starti

它让你进入你的动态链接器（如果你的二进制 id 是动态链接的），它将调用 __libc_start_main 函数，作为这个函数的参数，它给出了一个指向主函数的指针。所以你必须在这个地址（b*<addr_of_main>）上设置一个断点，然后使用continue 命令继续执行。现在你在 main 函数中，等待你的程序调用你的方法，如果你不能进入这个函数，你可以修改你的寄存器：

set $<register>=<value>

【讨论】：

【解决方案2】：

您的二进制文件可能加载了 ASLR，这是一种安全功能，可以使代码和数据的地址变得不可预测。

在 GDB 中尝试disabling ASLR - 在加载可执行文件之前。

(gdb) set disable-randomization off
(gdb) start

【讨论】：

我要从 Mach-O 标头中删除 PIE 标志并进行测试。
我认为 ASLR 建议是可靠的，但仍然涉及基地址。我要投票给你。
ASLR 已禁用，问题仍然存在。

【解决方案3】：

使用info file 和/或info shared 找出可执行文件的加载地址或实际入口点地址。

(gdb) info file
Mac OS X executable:
        <...>/test, file type mach-o-le.
        Entry point: 0x00002104
        0x00001000 - 0x0002b000 is <...>/test
        <...>

【讨论】：

我会检查这个，但我相信在设备上运行的剥离 ARM 二进制文件上没有可用的信息。