【问题标题】:Get method name from __objc_selrefs in dyld_shared_cache从 dyld_shared_cache 中的 __objc_selrefs 获取方法名
【发布时间】:2020-03-28 16:44:39
【问题描述】:

我正在尝试制作一个类似于dyld_decachedsc_extractor 的dyld 提取器。但我无法解析 __objc_selrefs 部分。

出于测试目的,我使用了 libsystem_trace.dylib,并且能够找到并解析它的 mach_header 及其段和节。但是查看 __DATA.__objc_selrefs 部分,我发现像 0x201b8647fc8 和 0x201b860d716 这样的指针太高了,并且指向了缓存之外。

相比之下,在普通的 Macho 文件中,__objc_selrefs 部分中的指针指向它们在 __TEXT.__objc_methname 部分中的对应字符串。

我知道 dyld 会滑动和变基部分,但经过大量修改后,我仍然无法修复指针。任何指导都会令人惊叹,尤其是考虑到那里的资源很少。

【问题讨论】:

    标签: objective-c reverse-engineering extraction dyld mach-o


    【解决方案1】:

    这些“地址”不仅仅指向缓存之外,它们还指向 iOS 为用户空间地址空间分配的最大范围之外。
    问题是这些不是原始地址,它们是混合了一些标志的地址。我至少见过 0x20000000000 和 0x40000000000,它们似乎是 Objective-C 代码独有的。我不知道它们的含义或这些标志的真正位掩码是什么,但到目前为止,保留地址的低 40 位 (0xffffffffff) 已经为我完成了这项工作。
    那会变成例如您的 0x201b8647fc8 值转换为 0x1b8647fc8,它应该在共享缓存边界内。

    【讨论】:

    • 这很棒!我确实必须将 VMAddr 转换为物理地址,但这是一个简单的修复。另外,我在 dyld_cache_slide_info2 结构中找到了掩码,所以你是对的。
    猜你喜欢
    • 2019-04-16
    • 1970-01-01
    • 2018-01-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-09-25
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多