iOS 符号化方法

介绍 iOS 堆栈符号化常用的方法。

Share

符号化可以将上面的得到的代码内存地址转为可读的函数签名信息,包括函数名、文件名、行数等等,方便我们快速定位问题。

符号化常用方法

使用 backtrace_symbols_fd 方法进行运行时符号化

backtrace_symbols_fd 函数能够将从backtrace 中得到的原始堆栈信息进行符号化,并输出到控制台。

vm_address_t *stacks_2[128];
int depth = backtrace((void **)stacks_2, 128);
backtrace_symbols_fd((void **)stacks_2, depth, STDOUT_FILENO);     // STDOUT_FILENO 表示向屏幕输出
💡
注意,这里用的是 backtrace_symbols_fd 而不是 backtrace_symbols。backtrace_symbols 内部实现也有 alloc/malloc 相关的调用,在 malloc_logger 里面调用会陷入递归死循环

使用 atos 和 dSYM 对堆栈信息符号化

假设我们的崩溃日志系统收集到了下面这样的崩溃日志:

"0 libsystem_kernel.dylib 0x1b00df000 0x1b00e1d0c" "1 libsystem_kernel.dylib 0x1b00df000 0x1b00ffe70" "2 Keep 0x104584000 0x10704e864" "3 Keep 0x104584000 0x10704ac5c" "4 libsystem_malloc.dylib 0x192e77000 0x192e89b4c" "5 Keep 0x104584000 0x10a1d9c2c" "6 Keep 0x104584000 0x10a209ba4" "7 Keep 0x104584000 0x10a209e48" "8 Keep 0x104584000 0x108c877b8" "9 Keep 0x104584000 0x108c86c04" "10 Keep 0x104584000 0x108c6c8d0" "11 Keep 0x104584000 0x108c68938" "12 Keep 0x104584000 0x108c664d8" "13 Keep 0x104584000 0x108c66d5c" "14 Keep 0x104584000 0x108c66ee8" "15 libdispatch.dylib 0x183f33000 0x183f932b0" "16 libdispatch.dylib 0x183f33000 0x183f94298" "17 libdispatch.dylib 0x183f33000 0x183f3ca40" "18 libdispatch.dylib 0x183f33000 0x183f3d518" "19 libdispatch.dylib 0x183f33000 0x183f46fac" "20 libsystem_pthread.dylib 0x1cc79e000 0x1cc7a95bc" 

我们需要先拿到 App 的 dSYM 文件。之后在终端使用 xcrun atos 进行符号化。

xcrun atos -arch arm64 -o Keep.app.dSYM/Contents/Resources/DWARF/Keep -l 0x104584000
0x108c66ee8
# 第一行指令输入一次即可,随后可以逐次输入调用方法的内存地址

逐次输入各个调用方法的内存地址后,控制台会输出相应的解析结果。

符号化

动态库堆栈符号化

iOS 静态库是在程序编译的时候就进行了链接,拷贝到了 App 的可执行文件里。而动态库并不会在编译时置入 App 中,而是在 App 运行的时候去动态查找动态库并进行链接。

静态库代码发生崩溃时,堆栈信息也是和 App 放在一起的,内存加载地址一致,可以用 dSYM 解析。

但是动态库堆栈信息无法使用 dSYM 解析,需要利用动态库的 framework 进行解析。

堆栈信息:

"0 libdispatch.dylib 0x1210e4000 0x1210eabb8" "5 KPlayerCore 0x121f48000 0x121f61134" "6 KPlayerCore 0x121f48000 0x121f954a8" "7 KPlayerCore 0x121f48000 0x121f95634" "8 KPlayerCore 0x121f48000 0x121f74e5c" "9 libsystem_pthread.dylib 0x213dcc000 0x213dcd6b8"

找到工程使用的动态库 framework:

img.png

使用 atos 工具解析堆栈:

img.png

Read more

在 AI 时代,做 iOS 逆向分析有哪些高效手段

在 AI 时代,做 iOS 逆向分析有哪些高效手段

AI 发展如此迅猛,传统的代码手艺活已经被 AI 取代了很大一部分。除了生成代码外,AI 在其他的研发流程也能提升很多效率,例如这次要说的 AI 逆向分析。 在手工时代,我们逆向分析一个 iOS app,通常是使用 Hopper 或者 IDA 等软件查看解密的 Mach-O,然后利用软件提供的能力加上人工去分析逻辑流程。这个过程还要求我们懂一些基础的汇编语法。有时候还要去猜测哪些类哪些方法是负责某个逻辑,靠试验去验证。 现在来到了大模型时代,AI 不仅能自己通过一些简单的工具去分析 ipa 和 Mach-O ,也能使用更准更稳的 MCP、Skill 工具来做深度的分析。 Hopper MCP Hopper 在新版本支持了 MCP Server。 把 framework、Mach-O 或者解密后的 IPA 直接丢给它,

By Gray
Cinder:基于 Swift Macro 与 Mach-O Section 的解耦注册机制

Cinder:基于 Swift Macro 与 Mach-O Section 的解耦注册机制

Cinder(Github) 是一个无需逐模块启动注册、支持字符串、类型和函数调用的 Swift 编译期注册框架。 Cinder 是什么 在 iOS app 里借助 Mach-O 注册能力做一些二进制的插桩操作并不罕见。以往这些操作大都使用 objc runtime ,借助 __attribute__((used)) 和 __attribute__((section("name"))) 实现。在 Swift 上实现有一些难度,因为 Swift runtime 能力弱,以及早期的版本没有类似 objc 的 __attribute__ 能力。 * 在 Swift 5.10 版本,Apple 提供了 @_used 和

By Gray