符号表还原迷惑

2021-07-08  本文已影响0人  coder_feng

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 工具

第一步.更改基地址

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二进制文件中的真实地址,然后定位到!

4.符号表还原原理分析

参考文章1:iOS Crash log符号化庖丁解牛
参考文章2:还原符号表
参考文章3:汇编定位 objc_msgSend + 16 出错的问题
参考文章4demo解说ASLR
参考文章5mach-o文件

5.样例存放地址

我的百度网盘->iOS学习->符号表还原->画啦啦项目->5.2.0bugly-> HLLCourseLive 2021-5-12, 4.18 PM.xcarchive

上一篇 下一篇

猜你喜欢

热点阅读