iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题)

简介: 利用Xcode自带的symbolicatecrash 进行符号化

引言

预备知识:https://blog.csdn.net/z929118967/article/details/127726025

I 符号化的方法

  • 借助第三方工具:bugly.qq.com 制作慢
登录 https://bugly.qq.com/v2/crash-reporting 压缩上传符号表。
找到对应的记录分析。
  • 利用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.
https://github.com/zhangkn/restore-symbol4iOS14
这里的符号恢复仅仅针对的是OC函数,C函数如果符号表被strip以后是没有办法恢复其符号信息的。
为什么OC函数可以去做符号恢复?
在macho文件中的_DATA数据段中有很多objc的节信息,里面保存了所有的类以及方法等元数据信息。
https://github.com/zhangkn/FridaLib4macho

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符号化分析问题、导出和隐藏符号
https://blog.csdn.net/z929118967/article/details/104983425

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。因此去 https://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 显示文件中每个段的内容

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偏移 ---- 虚拟内存起始地址与模块基地址的偏移量
选项 说明
-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
目录
相关文章
|
11天前
|
搜索推荐 Android开发 iOS开发
安卓与iOS系统的用户界面设计对比分析
本文通过对安卓和iOS两大操作系统的用户界面设计进行对比分析,探讨它们在设计理念、交互方式、视觉风格等方面的差异及各自特点,旨在帮助读者更好地理解和评估不同系统的用户体验。
35 1
|
11天前
|
Android开发 数据安全/隐私保护 iOS开发
安卓与iOS系统的发展趋势与比较分析
【2月更文挑战第6天】 在移动互联网时代,安卓和iOS系统作为两大主流移动操作系统,各自呈现出不同的发展趋势。本文将从技术角度出发,对安卓和iOS系统的发展方向、特点及未来趋势进行比较分析,以期为读者提供更深入的了解和思考。
49 4
|
11天前
|
存储 监控 iOS开发
iOS应用崩溃了,如何通过崩溃手机连接电脑查找日志方法
在iOS应用开发过程中,调试日志和奔溃日志是开发者必不可少的工具。当iOS手机崩溃时,我们可以连接电脑并使用Xcode Console等工具来查看日志。然而,这种方式可能不够方便,并且处理奔溃日志也相当繁琐。克魔助手的出现为开发者带来了极大的便利,本文将详细介绍其功能和使用方法。 克魔助手会提供两种日志,一种是实时的,一种的是崩溃的。(由于崩溃日志的环境很麻烦,目前只展示实时日志操作步骤)
|
8月前
|
C语言 索引
09-iOS之load和initialize底层调用原理分析
09-iOS之load和initialize底层调用原理分析
61 0
|
6月前
|
Android开发 iOS开发
[√]cocos2dx openal在ios崩溃的问题分析
[√]cocos2dx openal在ios崩溃的问题分析
79 0
|
11天前
|
安全 搜索推荐 Android开发
Android 与 iOS 的比较分析
【2月更文挑战第5天】 Android 和 iOS 是目前市场上两种最流行的移动操作系统,它们都拥有自己的特点和优势。本文将会分别从操作系统设计、应用生态、安全性等方面对这两种操作系统进行比较和分析,希望能够帮助读者更好地选择适合自己的移动设备。
|
10月前
|
存储 编解码 缓存
HTTP Live Streaming直播(iOS直播)技术分析与实现
HTTP Live Streaming直播(iOS直播)技术分析与实现
139 1
|
12月前
|
自然语言处理 搜索推荐 iOS开发
iOS MachineLearning 系列(19)—— 分析文本中的问题答案
本篇文章将介绍Apple官方推荐的唯一的一个文本处理模型:BERT-SQuAD。此模型用来分析一段文本,并根据提供的问题在文本中寻找答案。需要注意,BERT模型不会生成新的句子,它会从提供的文本中找到最有可能的答案段落或句子。
145 0
iOS MachineLearning 系列(19)—— 分析文本中的问题答案
|
监控 iOS开发 MacOS
iOS 友盟崩溃日志分析——Binary images
iOS 友盟崩溃日志分析——Binary images
220 0
|
存储 监控 网络协议
iOS 友盟崩溃日志分析——Thread state
iOS 友盟崩溃日志分析——Thread state
547 0