【问题标题】:Why is otool truncating my disassembly output?为什么 otool 会截断我的反汇编输出?
【发布时间】:2017-01-20 19:36:24
【问题描述】:

当我运行这个命令时

otool -t binary

otool 将正确转储binary 的文本部分。例如

0000000100002100   55 48 89 e5 41 56 53 48 8b 35 32 24 54 00 4c 8b 
:

但是当我运行这个命令时:

otool -tvV binary

otool 跳过大部分文本部分:

00000001003a32ce pushq %rbp
:

前 3805646 个字节只是被跳过而不是反汇编。如果我打开lldb中的二进制文件,我可以在跳过的地址处反汇编代码就好了。

有没有人有过类似的经历? otool 是否可能有内部大小限制并截断超出该限制的部分?是否有人发现了一种变通方法或知道免费提供的类似工具?

我尝试用lldb 反汇编整个二进制文件:

lldb binary
(lldb) dis -s 0x100002100 -e ...

-e 设置为文本部分中最后一个字节的地址,但这也不起作用。实际上lldb在分解大约5000字节的文本部分后停止输出。

【问题讨论】:

    标签: macos lldb disassembly mach-o otool


    【解决方案1】:

    我以前见过这个,我相信otool 正在(令人讨厌地)跳到第一个符号。如果你做nm -n binary,第一个定义的符号是00000001003a32ce吗?

    Xcode 附带了另一个名为otool-classic 的工具,它似乎可以反汇编整个文本段。据推测,它是 otool 在重写或类似的东西之前的旧版本。虽然它获取了整个文本段,但它可能在其他方面的功能较少(例如解码对选择器或字符串的引用)。要调用它,请使用xcrun otool-classic <args>

    在我的测试中,您还可以使用早期版本的 Xcode 附带的 otool 版本。 Xcode 7.3.1 和 Xcode 6.4 中的没有这个问题。 (这些是我碰巧方便测试的。其他可能也可以。)

    【讨论】:

    • 你可能就在这里。第一个带有地址的符号位于0x100000000,但这只是mh_execute_header,它不是真正的符号,而是用作基本偏移量。第二个位于0x1003a32ce,这是第一个“真实”符号。反汇编似乎从那里开始,跳过它之前的任何东西。哇,这太疯狂了。我会试试旧的 otool 看看会发生什么。
    • 是的,你完全正确。我从 Xcode 7.3.1 尝试了otool,它按预期工作,所以这显然是一个错误。你已经向苹果报告了吗?我想我现在会这样做,即使它被欺骗关闭。非常感谢!
    • 好的,看来 7.3.1 的 otool 也无法正常工作。它掩盖了第一个符号之前的一切,但在它之后什么都没有。只有将两者的输出结合起来才能得到整个二进制文件的汇编代码。
    • 嗯。在我的测试用例中,来自 7.3.1 的那个会反汇编整个文本段,而不仅仅是第一个符号。我还刚刚注意到 Xcode 7.x 和 Xcode 8.x 中都有一个otool-classic 命令。它似乎也有效。您可以使用xcrun otool-classic <args> 调用它。
    • otool-classic 确实可以正常工作,它真的可以反汇编所有内容!我不知道为什么 7.3.1 对我来说不能正常工作......也许是因为我没有将命令行完全更改为 7.3.1(仍设置为 8.2.1),只是直接从在 7.3.1 捆绑包中?但是有了 otool-classic,我们就有了完美的解决方案。您可能想将此添加到答案中,因为我认为这对于大多数有类似问题的人来说是完美的答案。
    【解决方案2】:

    根据 Ken Thomases 的回复和 cmets,我使用旧 Xcode 版本的 otool 进行了一些测试,发现 Xcode 7.3.1 中的 otool 效果更好,但也不会反汇编整个文本部分。我向 Apple 提交了错误报告,结果如下:

    工程部门已确定此问题的行为符合预期 关于以下信息:

    otool(1) 的实现在 Xcode 8 中更改为基于 llvm-objdump(1) 来自旧的 otool-classic(1),它仍然在 系统。

    对于llvm社区,目前启动反汇编的行为 第一个已知的符号是 llvm 社区的行为 愿望。

    确实,otool-classic 可以正常工作(xcrun otool-classic 可以正常工作),就像 Ken 在他的 cmets 中已经指出的那样,但我对这个回复不满意,所以我现在将在 LLVM 项目中提交一个错误.

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多