/p/1131/
本系列文章共三篇。本文是第二篇,讲 ELF 文件如何存放和使用 arm ehabi。关键词:.,.。
ELF . 和 . 的位置
Section角度:很久以前,readelf -S
时候一直不理解这两个 section 是做什么的,占空间,放的不是汇编,IDA 打开,里面也是一团意义不明的 data,总觉得没什么用。
1 2 3 4 5 6 7 8 9 10 11 |
~ readelf -S There are 25 section headers, starting at offset 0x1a130: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] . NOTE 00000134 000134 000098 00 A 0 0 4 [ 2] .-i NOTE 000001cc 0001cc 000024 00 A 0 0 4 ....... [14] . ARM_EXIDX 00013eb8 013eb8 000e80 08 AL 13 0 4 [15] . PROGBITS 00014d38 014d38 001014 00 A 0 0 4 |
Segment角度:readelf -l
时候,EXIDX
就是 .
,感觉还是有点用的,但仍然意义不明;不能直接确认 .
的位置。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
readelf -l Elf file type is DYN (Shared object file) Entry point 0x0 There are 8 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00000034 0x00000034 0x00100 0x00100 R 0x4 LOAD 0x000000 0x00000000 0x00000000 0x1802e 0x1802e R E 0x1000 LOAD 0x018570 0x00019570 0x00019570 0x01aa0 0x01cb9 RW 0x1000 DYNAMIC 0x019c94 0x0001ac94 0x0001ac94 0x00110 0x00110 RW 0x4 NOTE 0x000134 0x00000134 0x00000134 0x000bc 0x000bc R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 EXIDX 0x013eb8 0x00013eb8 0x00013eb8 0x00e80 0x00e80 R 0x4 GNU_RELRO 0x018570 0x00019570 0x00019570 0x01a90 0x01a90 RW 0x4 |
好了不废话了,本文只针对 shared_library
和 executable
的 ehabi 解析,不支持 relocatable
;因为 relocatable
拥有大量的 .
section 和重定位,有点复杂。
本文参考:
- 官方文档,发现看不懂的就去读文档:/documentation/ihi0038/b/
- llvm-readelf 的实现:/llvm/llvm-project/blob/master/llvm/tools/llvm-readobj/
- binutils-readelf 的实现 /bminor/binutils-gdb/blob/master/binutils/
- 看雪有篇不错的文档:原创andorid native栈回溯原理分析与思考
- 网上挺火的外国人的文档 《Stack frame unwinding on ARM》 (Ken Werner)(可以在《andorid native栈回溯原理分析与思考》的附件里下载到)
. 结构
这个 section 连续存放Entry,视为一个Entry数组。先要处理大小端问题,处理好后,每个 Entry 由两个 uint16 组成,相当于如下 struct:
1 2 3 4 |
struct EHEntry { uint32_t Offset; uint32_t World1; }; |
意义是函数起始偏移。最高 bit 一定是 0,结合当前偏移(当前 pc )进行使用
prel31
解码,得到 uint64_t。
格式为:
1 2 |
| 31----24 | 23----16 | 15-----8 | 7------0 | | 0XXXXXXX | XXXXXXXX | XXXXXXXX | XXXXXXXX | |
EHEntry.Word1
有三种情况:
-
EHEntry.Word1 == 1
,表示 CannotUnwind1
| 00000000 | 00000000 | 00000000 | 00000001 |
-
最高 bit 为 1,则
[31:24]
必须为0b10000000
(其实是 personality 为 0,属于 inline compact model),余下 X、Y、Z, 3 个 byte 表示字节码。1 2
| 31----24 | 23----16 | 15-----8 | 7------0 | | 10000000 | XXXXXXXX | YYYYYYYY | ZZZZZZZZ |
-
最高 bit 为 0,则整个 Word1 使用
prel31
解码,得到 uint64_t,指向真正的数据。必然会落在.
里。1 2
| 31----24 | 23----16 | 15-----8 | 7------0 | | 0XXXXXXX | XXXXXXXX | XXXXXXXX | XXXXXXXX |
prel31 解码
这个东西就是个计算方式,根据当前的绝对偏移(uint32),与当前的内容(uint32)进行运算,求出绝对偏移(uint64)。
对于 ELF 文件,我们可以假想它基址为 0,从而实现解析;
对于内存中的 ELF 片段,可以通过这个计算,根据当前位置寻找到附近的另一个位置,从而避免重定位;
下图代码中,Address 表示当前内容,Place 表示绝对偏移。
1 2 3 4 5 6 |
static uint64_t PREL31(uint32_t Address, uint32_t Place) { uint64_t Location = Address & 0x7fffffff; if (Location & 0x04000000) Location |= (uint64_t) ~0x7fffffff; return Location + Place; } |
. 结构
.
作为 .
的附属存在,存放数据,但无法直接找到每段数据的入口。入口需要借助上文 Entry.Word1
,当 Entry.Word1
的最高 bit 为 0 时,prel31
解码后一定会指向 .
的内容,这就是入口。
名词解释:personality
——特性,可能没有中文概念。
先读出第一个 uint32_t
,进行初步解析,再根据情况进行进一步解析,有以下的情况:
-
最高 bit 为 0,表示
generic personality
,使用prel31
解码,使用指向的函数进行 unwind。1 2
| 31----24 | 23----16 | 15-----8 | 7------0 | | 0XXXXXXX | XXXXXXXX | XXXXXXXX | XXXXXXXX |
-
最高 bit 为 1,表示
arm compact personality
,[31:28]
必须为0b1000
,[27:24]
有且仅有有0、1、2三种情况。-
0: inline compact model,X、Y、Z, 3 个 byte 表示字节码。
1 2
| 31----24 | 23----16 | 15-----8 | 7------0 | | 10000000 | XXXXXXXX | YYYYYYYY | ZZZZZZZZ |
-
1或者2:
[23:16]
表示 more_word(uint_8),表示剩余字节码个数,后面的都是字节码1 2 3
| 31----24 | 23----16 | 15-----8 | 7------0 | | 10000001 | MOREWORD | ........ | ........ | | 10000010 | MOREWORD | ........ | ........ |
-
字节码的反汇编
根据上文,我们可以得到每一处 Entry 及其 unwind方式。我们关心的是使用字节码进行 unwind (即 personality 为0、1、2)的情况,经过解析可以得到 uint8_t[N]
的字节码 ,解析方式在 “Table 4, ARM-defined frame-unwinding instructions” 文件章节。
参考 llvm-readelf
的实现,它的可读性最好,代码在 /llvm/llvm-project/blob/master/llvm/tools/llvm-readobj/ ,其中有大量OpcodeDecoder::Decode_XXXXX
函数可以抄。
纯体力活,没什么好说的,官方表格如下:
Instruction | Explanation |
---|---|
00xxxxxx | vsp = vsp + (xxxxxx << 2) + 4. Covers range 0x04-0x100 inclusive |
01xxxxxx | vsp = vsp – (xxxxxx << 2) - 4. Covers range 0x04-0x100 inclusive |
10000000 00000000 | Refuse to unwind (for example, out of a cleanup) (see remark a) |
1000iiii iiiiiiii (i not a ll 0) | Pop up to 12 integer registers under masks {r15-r12}, {r11-r4} (see remark b) |
1001nnnn ( nnnn != 13,15) | Set vsp = r[nnnn]
|
10011101 | Reserved as prefix for ARM register to register moves |
10011111 | Reserved as prefix for Intel Wireless MMX register to register moves |
10100nnn | Pop r4-r[4+nnn]
|
10101nnn | Pop r4-r[4+nnn] , r14 |
10110000 | Finish (see remark c) |
10110001 00000000 | Spare (see remark f) |
10110001 0000iiii ( i not all 0) | Pop integer registers under mask {r3, r2, r1, r0} |
10110001 xxxxyyyy | Spare (xxxx != 0000) |
10110010 uleb128 | vsp = vsp + 0x204+ (uleb128 << 2) (for vsp increments of 0x104-0x200, use 00xxxxxx twice) |
10110011 sssscccc | Pop VFP double-precision registers D[ssss]-D[ssss+cccc] saved (as if) by FSTMFDX (see remark d) |
101101nn | Spare (was Pop FPA) |
10111nnn | Pop VFP double-precision registers D[8]-D[8+nnn] saved (as if) by FSTMFDX (seeremark d) |
11000nnn (nnn != 6,7) | Intel Wireless MMX pop wR[10]-wR[10+nnn]
|
11000110 sssscccc | Intel Wireless MMX pop wR[ssss]-wR[ssss+cccc] (see remark e) |
11000111 00000000 | Spare |
11000111 0000iiii | Intel Wireless MMX pop wCGR registers under mask {wCGR3,2,1,0} |
11000111 xxxxyyyy | Spare (xxxx != 0000) |
11001000 sssscccc | Pop VFP double precision registers D[16+ssss]-D[16+ssss+cccc] saved (as if) by VPUSH (see remarks d,e) |
11001001 sssscccc | Pop VFP double precision registers D[ssss]-D[ssss+cccc] saved (as if) by VPUSH (see remark d) |
11001yyy | Spare (yyy != 000, 001) |
11010nnn | Pop VFP double-precision registers D[8]-D[8+nnn] saved (as if) by VPUSH (seeremark d) |
11xxxyyy | Spare (xxx != 000, 001, 010) |
实战:用 python 写一个 ehabi 的 parser
很遗憾,pyelftools 并未实现解析 arm ehabi 的功能,要有这个功能,我也懒得写本文了。。。
我为什么要写解析的功能?一方面因为 pyelftools 平时经常用,想为它做一些贡献;另一方面,我计划写一个 ida-arm-unwind 的插件,缺乏一个 python 库帮我完成解析,在 pyelftools 上补充功能是最合适的。
pull reqeust:/eliben/pyelftools/pull/328
merge commit:/eliben/pyelftools/commit/ee0facee32ae5fc91709c93f9a57a9a7683a3315
花了不少时间,写了将近 1000 行代码,实现得也比较优雅,大概有如下的功能:
- 加了
has_ehabi_infos
和get_ehabi_infos
两个 API,返回List[EHABIInfo]
。 - 添加
class EHABIInfo
,提供num_entry
和get_entry(i)
两个 API,返回EHABIEntry
。 - 添加
class EHABIEntry
及其子类,描述每个 unwind 条目,描述函数偏移和字节码,也可以反汇编
看一下效果:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
pyelftools git:(master) scripts/ -au test/testfiles_for_unittests/arm_exidx_test.so | head -n 20 Unwind section '.' at offset 0x639d8 contains 1933 entries Entry 0: Function offset 0x34610: @0x69544 Compact model index: 1 0x97 ; vsp = r7 0x41 ; vsp = vsp - 8 0x84 0x0d ; pop {r4, r6, r7, lr} 0xb0 ; finish 0xb0 ; finish Entry 1: Function offset 0x34640: @0x6bef4 Compact model index: 1 0x97 ; vsp = r7 0x41 ; vsp = vsp - 8 0x84 0x0b ; pop {r4, r5, r7, lr} 0xb0 ; finish 0xb0 ; finish |
总结
本文讲了 ELF 里 arm ehabi 的存放和使用。
第一篇指路:/p/1125
第二篇指路:/p/1131
第三篇指路:/p/1135