“我正在参加「掘金·启航计划」”

引言

预备知识：blog.csdn.net/z929118967/…

I 符号化的方法

• 借助第三方工具：bugly.qq.com 制作慢

登录bugly.qq.com/v2/crash-re… 压缩上传符号表。 找到对应的记录分析。

• 利用Xcode自带的symbolicatecrash 进行符号化

1、export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer 2、symbolicatecrash appName.crash appName.app > appName.log

devzkndeMacBook-Pro:LatestBuild devzkn$ /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash --dsym=/Users/devzkn/work/.git//LatestBuild/.dylib.dSYM /Users/devzkn/Desktop/SpringBoard-2018-03-12-162524.ips  --output=/Users/devzkn/Desktop/kn.crash

• 利用ASRL的特性进行栈符号恢复：用这些栈地址减去偏移然后去ida里面找到对应的方法

restore-symbol:A reverse engineering tool to restore stripped symbol table for iOS app. github.com/zhangkn/res…

• lldb调试器栈符号恢复脚本

这里的符号恢复仅仅针对的是OC函数，C函数如果符号表被strip以后是没有办法恢复其符号信息的。 为什么OC函数可以去做符号恢复？ 在macho文件中的_DATA数据段中有很多objc的节信息，里面保存了所有的类以及方法等元数据信息。 github.com/zhangkn/Fri…

1.1 通过命令行工具 symbolicatecrash 来手动符号化 crash log

Use Xcode'ssymbolicatecrash tool to symbolicate your crash report. This tool will search system symbols in the iOS DeviceSupportpath automatically.

export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
symbolicatecrash appName.crash appName.app > appName.log

具体的做法：

• 查找symbolicatecrash 工具的目录

➜  Debug-iphoneos cd /Applications/Xcode.app/Contents

➜  Contents find . -name  'symbolicatecrash'    
./Developer/Platforms/MacOSX.platform/Developer/iOSSupport/Library/PrivateFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

./Developer/Platforms/WatchSimulator.platform/Developer/Library/PrivateFrameworks/DVTFoundation.framework/symbolicatecrash

./Developer/Platforms/AppleTVSimulator.platform/Developer/Library/PrivateFrameworks/DVTFoundation.framework/symbolicatecrash

./Developer/Platforms/iPhoneSimulator.platform/Developer/Library/PrivateFrameworks/DVTFoundation.framework/symbolicatecrash

./SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

• 符号化: symbolicatecrash appName.crash appName.app > appName.log

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash --dsym=/Users/mac/Desktop/aaa3ffdf-16ce-3065-bcba-293f7aee7c9b.dSYM /Users/mac/Desktop/crashlog-EEF95364-6768-44D3-B8DF-46EC13B0D245.txt --output=/Users/mac/Desktop/kn.crash

• 符号化之前后的效果对比

1.2 通过 Xcode 进行符号化：

将 .crash 文件，.dSYM 和 .app 文件放到同一个目录下，打开 Xcode 的 Window 菜单下的 organizer，再点击 Device tab，最后选中左边的 Device Logs。选择 import 将 .crash 文件导入就可以看到 crash 的详细 log 了。

1.3 遇到的常见问题

• 手动解析iOS crash文件时候，会出现这个报错

Error: "DEVELOPER_DIR" is not defined at /Applications/Xcode.app/Contents

解决方案 export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

1.4 iOS15崩溃排查技巧

symbolicatecrash符号化分析问题、导出和隐藏符号 blog.csdn.net/z929118967/…

iOS15符号化换新工具了， iOS 15 的crash 文件改了格式, 用 Xcode 13 的 symbolicatecrash 也无法解析了,可使用脚本将新格式转换为之前的格式，再丢进去 symbolicate。

Mac OS 11.3+的系统用Console 打开也会自动转换,或者用 Xcode 的 View Devide Logs 来先给开发这边先查看

关注#公号：iOS逆向，回复translation 下载转换脚本

python3 translation.py -i {input_sybolicated_json_file} -o {output_path}

II 、导出和隐藏符号

2.1 导出符号信息

• 查看导出符号信息：nm -gm tmp_64.dylib

(__DATA,__data) external (undefined) external _CFDataCreate (from CoreFoundation) (undefined) external _CFNotificationCenterGetDarwinNotifyCenter (from CoreFoundation) (__TEXT,__text) external (undefined) external _IOObjectRelease (from IOKit) (undefined) external _IORegistryEntryCreateCFProperty (from IOKit) 000000010ffa3f97 (__DATA,__objc_data) external OBJC_CLASS_BslyjNwZmPCJkVst 000000010ffa3f97 (__DATA,__objc_data) external _OBJC_CLASS__ChiDDQmRSQpwQJgm

2.2 控制符号是否导出

static 参数修饰,不会导出符号信息

static char _person_name[30] = {'\0'};

• 在编译参数中加入-exported_symbols_list export_list

• 在编译参数中指定-fvisibility=hidden，对指定符号增加visibility(“default”)来导出符号

#define EXPORT __attribute__((visibility("default")))

III 根据 iOS 崩溃日志获取对应系统库源码

定位崩溃日志对应的系统库源码找到CURRENT_PROJECT_VERSION

• 根据系统版本号寻找
• 根据系统编译版本号寻找

3.1 根据系统版本号 (OS Version)定位源码

根据OS Version寻找CURRENT_PROJECT_VERSION

• 崩溃日志

Incident Identifier: 6156848E-344E-4D9E-84E0-87AFD0D0AE7B
CrashReporter Key:   76f2fb60060d6a7f814973377cbdc866fffd521f
Hardware Model:      iPhone8,1
Process:             TouchCanvas [1052]
Path:                /private/var/containers/Bundle/Application/51346174-37EF-4F60-B72D-8DE5F01035F5/TouchCanvas.app/TouchCanvas
Identifier:          com.example.apple-samplecode.TouchCanvas
Version:             1 (3.0)
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           com.example.apple-samplecode.TouchCanvas [1806]

Date/Time:           2020-03-27 18:06:51.4969 -0700
Launch Time:         2020-03-27 18:06:31.7593 -0700
OS Version:          iPhone OS 13.3.1 (17D50)


22  libdyld.dylib                     0x00000001b6728360 start + 4

• 依据 Xcode 发布的历史版本文案，推断 iPhone OS V13.3.1 对应的 macOS 版本是10.15.2。因此去 opensource.apple.com/ 找到对应的版本

如果没有找到对应的源码文件，则尝试查找上一个版本

• 根据二进制文件名：libdyld.dylib 推断对应的PROJECT_NAME是dyld
• 对照 macOS 10.15.2 ，可以推断dyld的项目版本号CURRENT_PROJECT_VERSION是 733.8

• 点击右侧下载按钮，即下载源码

缺点

1、 部分情况无法准确得知对应的macOS 系统版本号,CURRENT_PROJECT_VERSION 不够精确。 2、 部分情况无法根据二进制文件反推出对应的 PROJECT_NAME 无法根据libsystem_asl.dylib找到与 system_asl 相关的源码

3.2 根据系统编译版本号定位源码

根据OS Build Version 获取 PROJECT_VERSION

• 1、在 ~/Library/Developer/Xcode/iOS\ DeviceSupport目录下查找到对应的二进制文件。

➜  ~ cd  ~/Library/Developer/Xcode/iOS\ DeviceSupport
➜  iOS DeviceSupport find . -name libdyld.dylib

./14.0 (18A373)/Symbols/usr/lib/system/libdyld.dylib
./12.4.8 (16G201)/Symbols/usr/lib/system/libdyld.dylib

如果本地没有找到，可以去网络搜索collected iOS-System-Symbols/blob

• 2、接下来你可以使用 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool、file、及llvm-objdump -m 查看macho的对应的CURRENT_PROJECT_VERSION

例如使用 otool -l ./Symbols/usr/lib/system/libdyld.dylib，发现 14.0 (18A373)对应的libdyld.dylib的CURRENT_PROJECT_VERSION是828.4.0

Load command 5
          cmd LC_ID_DYLIB
      cmdsize 56
         name /usr/lib/system/libdyld.dylib (offset 24)
   time stamp 2 Thu Jan  1 08:00:02 1970
      current version 828.4.0
compatibility version 1.0.0

当然如果你习惯使用llvm-objdump ，也可以使用-m和-s 进行获取CURRENT_PROJECT_VERSION信息

llvm-objdump -s ./Symbols/usr/lib/system/libdyld.dylib | grep "Contents of section __const" -A 3
llvm-objdump -m --dylibs-used ./Symbols/usr/lib/system/libdyld.dylib

-m, -macho 使用Mach-O特定的目标文件解析器。使用-macho时，命令和其他选项的行为可能会有所不同。 -s 显示文件中每个段的内容

• llvm-objdump.cpp

3.3 小结

	优点	缺点
系统版本号	简单，无需对应的符号文件	部分情况无法准确得知对应的macOS 系统版本号,部分情况无法根据二进制文件反推出对应的 PROJECT_NAME
系统编译版本号		需要下载对应的符号文件（通常在1G以上）

IV dSYM的其他应用场景

场景：用户在机器1上用 Xcode 将 App 工程（存放于本机文件路径1）布署到 iPhone 上，然后在机器2上用 Xcode 打开文件路径2的工程，然后 Attach 到 iPhone 上的 App 进程，这时 Xcode 因为找不到文件路径1所以无法显示源代码，这时 Xcode 只能展示汇编代码

4.1 Xcode调试非本机构建的程序

• 在 lldb 中增加符号文件路径: (lldb) target symbols add /Users/mac/Downloads/testApp.dSYM

• 在 lldb 中设置机器1上的文件路径1与机器2上的文件路径2的映射关系：

/* 设置源机器与当前机器上源文件路径的映射关系 */
(lldb) settings set target.source-map "机器1上的文件路径1" "机器2上的文件路径2"

/* 添加映射关系 */
(lldb) settings append target.source-map "机器1上的文件路径1" "机器2上的文件路径2"

/* 显示已配置的映射关系 */
(lldb) settings show target.source-map 

机器1上的文件路径1和机器2上的文件路径2应该包含相同版本的源文件，否则调试时会显示异常

see also

查看模块偏移后的基地址

(lldb) image list -o -f

[  0] 0x0000000000eb8000 /Users/mac/Library/Developer/Xcode/DerivedData/Housekeeper-fzqstvcmffmiksaunlmbvfhyqpei/Build/Products/Debug-iphoneos/Housekeeper.app/Housekeeper

ASLR偏移 ---- 虚拟内存起始地址与模块基地址的偏移量

• llvm-objdump

选项	说明
-arch=	指定体系架构给反汇编器，使用-version命令查看可用的体系架构
-cfg	为目标文件中的每个符号创建一个CFG，并将其写入graphviz文件（仅限Mach-O）。
-dsym=	使用.dSYM文件获取调试信息。
-g	如果可用，从调试信息中打印行信息。
-m, -macho	使用Mach-O特定的目标文件解析器。使用-macho时，命令和其他选项的行为可能会有所不同。
-mattr=<a1,+a2,-a3,…>	定位特定属性。
-mc-x86-disable-arith-relaxation	禁用X86的算术指令放宽
-stats	启用程序的统计输出
-triple=	目标三重拆解，使用-version命令查看可用目标。
-x86-asm-syntax=	与-disassemble选项一起使用时，选择要从X86后端发出的代码样式。支持的值是：att(AT&T式语法)/intel(英特尔式语法)，默认值是att