在iOS故障转储中匹配偏移量以拆卸二进制

前端之家收集整理的这篇文章主要介绍了在iOS故障转储中匹配偏移量以拆卸二进制前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我无法匹配iOS崩溃转储的堆栈跟踪中的偏移量,在二进制文件的反汇编中由otool输出.

任何人都可以确认原则上我如何匹配这些.例如,如果我在崩溃转储中得到一行:

0 myapp  0x00005b0a  0x1000 + 19210

我会期望二进制文件中的违规指令的偏移量为0x5b0a,0x4b0a ….还是别的?

标题信息的解码中,otool还给出例如该信息(实际代码文件中的偏移0x0000224c开始):

Section
  sectname __text
   segname __TEXT
      addr 0x0000224c
      size 0x00063ad2
    offset 4684
     align 2^2 (4)
    reloff 0
    nreloc 0
      type S_REGULAR
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
 reserved1 0
 reserved2 0

所以,我没有100%肯定我正在正确地解释,但似乎是说,文件中的0x224c的代码最终在内存中的偏移量0x124c,但是我不知道这是如何安装的例如,位置0x1000.

我所遇到的问题是,假设偏移量为0x5b0a,那么那里的指令也不在0x4b0a,也不是0x6b0a,这是有道理的,因为它是有问题的实际指令(包括例如位于堆栈下方的位置,然后不指向分支指示).

(我知道,至少在ARM的早期版本中,由于指令管道,PC的值和相应的内存地址之间存在差异,我假设在报告的偏移量中会考虑到这样的差异在崩溃转储中,或者无论如何,我会看到分支指令有问题的一些指令,一方指出,如果这样的差异没有被考虑到…)

任何人都有光吗?

解决方法

只要myapp没有删除符号,你将能够使用atos.

你可以随时掌握更多细节,但这应该足以满足您的问题:

-o symbol_file # debugging information output by the compiler this may be a dSYM or the binary itself depending on who you saved symbol information
-l load address # the base address in the process space at which your library is loaded into the springboard process (Looks like 0x1000)
Also a list of addresses you wish to symbolicate

Usage:
    atos -o myapp -l 0x1000 0x00005b0a 0x0005bca ... etc

输出应该是终端的符号名称列表.再次,这要求myapp没有删除符号.

猜你在找的iOS相关文章