符号表还原迷惑

作者: coder_feng | 来源:发表于2021-07-08 06:52 被阅读0次

符号表还原迷惑
iOS逆向基础03-符号表
关于bugly的iOS符号表
dsym
ndk-stack使用及符号表还原
使用 C++filt 命令还原符号表
Unity BuglySDK符号表接入
杂记
编译器笔记44-运行存储分配-符号表
iOS Crash 常用分析方法

1.原因

最近观察bugly上面奔溃信息的时候，结合之前的atos还原符号表，还有自己对ASLR的概念，刹那间感觉思路了被混淆了，所以决定写文档记录一下混淆之处~

2.样本案例

0 libobjc.A.dylib _objc_retain + 16
1 HLLCourseLive 0x00000001003b8000 + 6239280
2 Foundation _NSDescriptionWithLocaleFunc + 96
5Foundation +[NSString stringWithFormat:] + 72
6 HLLCourseLive 0x00000001003b8000 + 6237928
7Foundation _NSDescriptionWithLocaleFunc + 96
10 Foundation +[NSString stringWithFormat:] + 72
11HLLCourseLive 0x00000001003b8000 + 6086132
12 libdispatch.dylib __dispatch_call_block_and_release + 24
17 libsystem_pthread.dylib__pthread_wqthread + 212

3.还原

1 HLLCourseLive 0x00000001005d8000 + 6239280，这里用这句为例

0x00000001005d8000 项目基地址
6239280(十进制)对应16进制0x5F3430，代表偏移量
0x00000001005d8000 + 0x5F3430 = 0x100BCB430

3.1还原方式1(基于基地址的更改)

通过hooper 工具

1. hopper -> Modify -> Change File Base Address... ，然后把基地址 0x00000001005d8000 输入，重新 Rebase 一下。
1. hopper -> Navigate -> Go to Address or Symbol... ，输入 0x100BCB430 这个地址，然后 go 到对应的崩溃地址。
  用hooper打开对应版本的二进制文件

第一步.更改基地址

baseAddress.png

原始baseAddress.png

更改后的baseAddress.png

第二步：去到奔溃地址

crashAddress.png

第三步定位方法

crash 定位方法.png

通过上面三部曲可以定位到最终的奔溃方法~

3.2还原方式2(移除ASLR)

这种方式也是通过hooper 工具，只不过是不需要修改baseAddress，但是需要我们自己计算相关地址,首先需要计算ASLR地址

ASLR地址 = image 基地址 - 二进制的vmaddress(64位的是0x100000000，32位的是0x00004000) = 0x00000001005d8000 - 0x100000000 = 0x5D8000;

hooper 中的奔溃地址 = 0x100BCB430 - 0x5D8000 = 0x1005F3430

用hooper打开对应版本的二进制文件，hopper -> Navigate -> Go to Address or Symbol. 输入奔溃地址0x1005F3430

没有更改baseAddress.png

3.3还原方式3(atos)

 songlin@feng-sl  ~/audio/aac   master ±✚  atos
[invalid usage]: no processes or executables specified

Usage: atos [-p pid] [-o executable] [-f file] [-s slide | -l loadAddress] [-arch architecture] [-printHeader] [-fullPath] [-inlineFrames] [-d delimiter] [address ...]

        -d/--delimiter     delimiter when outputting inline frames. Defaults to newline.
        --fullPath         show full path to source file
        -i/--inlineFrames  display inlined functions

简单使用例子：终端执行 xcrun atos -o ./appName -l 模块加载地址崩溃地址 -arch arm64 命令

代入我们样本案例使用：

songlin@feng-sl  ~/Documents/LogWidget   master  cd /Users/songlin/Documents/61相关/案例跟踪/5.2.0bugly/HLLCourseLive\ 2021-5-12,\ 4.18\ PM.xcarchive/dSYMs/HLLCourseLive.app.dSYM/Contents/Resources/DWARF
 songlin@feng-sl  ~/Documents/61相关/案例跟踪/5.2.0bugly/HLLCourseLive 2021-5-12, 4.18 PM.xcarchive/dSYMs/HLLCourseLive.app.dSYM/Contents/Resources/DWARF   master ±✚  ls
HLLCourseLive
 songlin@feng-sl  ~/Documents/61相关/案例跟踪/5.2.0bugly/HLLCourseLive 2021-5-12, 4.18 PM.xcarchive/dSYMs/HLLCourseLive.app.dSYM/Contents/Resources/DWARF   master ±✚  xcrun atos -o ./HLLCourseLive -l 0x00000001005d8000 0x100BCB430 -arch arm64
-[DLSocketUploadStateNetStatus description] (in HLLCourseLive) (DLSocketUploadStateModel.m:116)

从上面一样可以看到最终能定位到奔溃地址~

通过上面的3中还原方式，最终我都能定位到奔溃方法，但是其实我之前是有被混淆的，被混淆大概就是被这几个地址绕来绕去，有点分不清其代表含义，担心后面有同事也会出现这样的问题，所以这里梳理一下，其实3种方式的核心原理都是一样的，就是传入基地址，然后通过判断是64位还是32位，计算出来在mach-o二进制文件中的真实地址，然后定位到！