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

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

引言

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

I 符号化的方法

  • 借助第三方工具:bugly.qq.com 制作慢
  • 利用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符号化分析问题、导出和隐藏符号

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

在这里插入图片描述

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

在这里插入图片描述

缺点

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
目录
相关文章
|
13天前
|
安全 Android开发 数据安全/隐私保护
深入探讨iOS与Android系统安全性对比分析
在移动操作系统领域,iOS和Android无疑是两大巨头。本文从技术角度出发,对这两个系统的架构、安全机制以及用户隐私保护等方面进行了详细的比较分析。通过深入探讨,我们旨在揭示两个系统在安全性方面的差异,并为用户提供一些实用的安全建议。
|
2月前
|
开发工具 Android开发 Swift
安卓与iOS开发环境对比分析
在移动应用开发的广阔舞台上,安卓和iOS这两大操作系统无疑是主角。它们各自拥有独特的特点和优势,为开发者提供了不同的开发环境和工具。本文将深入浅出地探讨安卓和iOS开发环境的主要差异,包括开发工具、编程语言、用户界面设计、性能优化以及市场覆盖等方面,旨在帮助初学者更好地理解两大平台的开发特点,并为他们选择合适的开发路径提供参考。通过比较分析,我们将揭示不同环境下的开发实践,以及如何根据项目需求和目标受众来选择最合适的开发平台。
51 2
|
11天前
|
监控 iOS开发 开发者
iOS性能优化:深入函数调用栈与符号化技术
在iOS开发中,函数调用栈是理解程序执行流程和优化性能的关键。当应用出现性能问题或崩溃时,能够准确地读取和解析调用栈信息对于快速定位问题至关重要。本文将探讨iOS中的函数调用栈,以及如何通过符号化技术进行有效的性能调优。
24 3
|
11天前
|
监控 算法 iOS开发
深入探索iOS函数调用栈:符号化与性能调优实战
在iOS开发中,理解函数调用栈对于性能调优和问题排查至关重要。函数调用栈记录了程序执行过程中的函数调用顺序,通过分析调用栈,我们可以识别性能瓶颈和潜在的代码问题。本文将分享iOS函数调用栈的基本概念、符号化过程以及如何利用调用栈进行性能调优。
30 2
|
2月前
|
安全 Android开发 数据安全/隐私保护
探索安卓与iOS的安全性差异:技术深度分析与实践建议
本文旨在深入探讨并比较Android和iOS两大移动操作系统在安全性方面的不同之处。通过详细的技术分析,揭示两者在架构设计、权限管理、应用生态及更新机制等方面的安全特性。同时,针对这些差异提出针对性的实践建议,旨在为开发者和用户提供增强移动设备安全性的参考。
136 3
|
1月前
|
开发工具 Android开发 Swift
安卓与iOS开发环境的差异性分析
【10月更文挑战第8天】 本文旨在探讨Android和iOS两大移动操作系统在开发环境上的不同,包括开发语言、工具、平台特性等方面。通过对这些差异性的分析,帮助开发者更好地理解两大平台,以便在项目开发中做出更合适的技术选择。
|
2月前
|
安全 Linux Android开发
探索安卓与iOS的安全性差异:技术深度分析
本文深入探讨了安卓(Android)和iOS两个主流操作系统平台在安全性方面的不同之处。通过比较它们在架构设计、系统更新机制、应用程序生态和隐私保护策略等方面的差异,揭示了每个平台独特的安全优势及潜在风险。此外,文章还讨论了用户在使用这些设备时可以采取的一些最佳实践,以增强个人数据的安全。
|
3月前
|
Java 开发工具 Android开发
安卓与iOS开发环境对比分析
【8月更文挑战第20天】在移动应用开发的广阔天地中,Android和iOS两大平台各自占据着重要的位置。本文将深入探讨这两种操作系统的开发环境,从编程语言到开发工具,从用户界面设计到性能优化,以及市场趋势对开发者选择的影响。我们旨在为读者提供一个全面的比较视角,帮助理解不同平台的优势与挑战,并为那些站在选择十字路口的开发者提供有价值的参考信息。
|
2月前
|
IDE 开发工具 Android开发
安卓与iOS开发环境对比分析
本文将探讨安卓和iOS这两大移动操作系统在开发环境上的差异,从工具、语言、框架到生态系统等多个角度进行比较。我们将深入了解各自的优势和劣势,并尝试为开发者提供一些实用的建议,以帮助他们根据自己的需求选择最适合的开发平台。
47 1
|
3月前
|
开发框架 Android开发 Swift
安卓与iOS应用开发对比分析
【8月更文挑战第20天】在移动应用开发的广阔天地中,安卓和iOS两大平台各占半壁江山。本文将深入探讨这两大操作系统在开发环境、编程语言、用户界面设计、性能优化及市场分布等方面的差异和特点。通过比较分析,旨在为开发者提供一个宏观的视角,帮助他们根据项目需求和目标受众选择最合适的开发平台。同时,文章还将讨论跨平台开发框架的利与弊,以及它们如何影响着移动应用的开发趋势。