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

引言

准备常识: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

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

iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)
iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)
iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)
iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)

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

  • 依据系统版别号寻觅
  • 依据系统编译版别号寻觅
    iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)

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/ 找到对应的版别
    iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)

iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)

假如没有找到对应的源码文件,则尝试查找上一个版别

  • 依据二进制文件名:libdyld.dylib 揣度对应的PROJECT_NAME是dyld
  • 对照 macOS 10.15.2 ,能够揣度dyld的项目版别号CURRENT_PROJECT_VERSION是 733.8

iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)

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

iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)

缺点

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

iOS小技能:iOS15崩溃排查技巧(symbolicatecrash符号化分析问题、导出和隐藏符号)

当然假如你习惯运用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