简介围绕Android平台.so动态链接库解析与JNI实践整理的示例工程资料面向具备一定Java基础、希望理解原生库结构与调用机制的Android开发者。内容以可导入的示例工程为线索涉及ELF头部、符号表、重定位信息等结构认知以及readelf、objdump、nm等分析工具的学习场景并延伸到gdbserver配合gdb的原生调试、JNIEXPORT与JNICALL函数声明、javah头文件生成和ABI分割打包等常见问题适合用作课堂演示、自学对照或项目排错参考。压缩包共30个文件包含18个class、5个java源文件、2个h头文件、2个so库以及classpath、prefs、project等工程配置整体约58KB体积轻便便于快速导入查看目录关系。已有3147人学习下载读者可借助其中的Java与C/C对应文件、现成so库和工程配置梳理Java层加载原生库、符号查找与多架构兼容的实践思路。1. 解析 SO 文件加载器为什么不读你的代码只读两张表很多人第一次解析 so 文件会默认它和普通的可执行文件差不多——代码、数据、符号按顺序排好从头读下去就行。把文件扔进十六进制视图就会发现开头几十个字节里没有一个字节是机器指令全是元数据魔数、位宽、字节序、入口地址以及两张表的位置和长度。真正的指令要等加载器读完这张“目录”才会被映射进内存。反直觉的结论在这里解析 so 文件九成工作量不是读机器码而是把几张表之间的指针关系理顺而其中最常被人翻来覆去琢磨的节区表在运行时压根不被加载器读取。加载器只认程序头表节区表是给链接器和分析工具看的。搞不清这条分界线地址错位、符号对不上、工具报错就都成了玄学。2. ELF 头与程序头表加载器凭什么只信这两张表ELF 头是整份文件的入口加载器拿到一个 so第一步就是读它程序头表紧随其后描述“这段字节应该被映射到哪个虚拟地址、给什么权限”。这两张表读错一个字段后面全是错的。2.1 e_ident 的 16 个字节位宽、字节序、ABI 一次交代清楚文件前 16 个字节是e_ident它是一段自描述的字节序列不依赖任何外部信息就能判断该怎么继续读下去。第 0~3 字节是魔数0x7F 45 4C 46直译过来就是“ELF”第 4 字节EI_CLASS决定后面所有结构的排布——值为 1 表示 32 位值为 2 表示 64 位第 5 字节EI_DATA表示字节序1 是小端、2 是大端第 6 字节是版本号目前恒为 1第 7 字节EI_OSABI标记目标 ABI第 8 字节是 ABI 版本第 9~15 字节是保留填充。这里最容易翻车的是“先入为主”。不少人写解析器时直接按 64 位结构体去unpack遇到 32 位库也不报错——因为e_phoff这类字段在两种位宽下的偏移不同读出来的值恰好落在合法范围内程序照跑只是后面所有地址都偏了。EI_CLASS必须是第一个分支条件。紧跟在e_ident之后的是e_type。共享库的类型是ET_DYN值为 3但要注意位置无关的可执行文件也是ET_DYN。所以光看e_type判断不了“这是不是动态库”得再看有没有DT_SONAME或者看是否带PT_INTERP。e_machine标出指令集AArch64 是0xB732 位 ARM 是0x28x86-64 是0x3E——解析重定位类型时必须先拿到这个值因为同一套重定位机制在不同指令集下的编号完全不同。64 位 ELF 头一共 64 字节32 位是 52 字节。剩下的字段里e_phoff是程序头表的文件偏移e_phentsize是单个表项大小e_phnum是表项数量e_shoff、e_shentsize、e_shnum对应节区表e_shstrndx指向节区名字符串表所在的下标。字段64 位偏移含义典型值e_ident0魔数 位宽 字节序7F 45 4C 46 02 01 01e_type16文件类型3ET_DYNe_machine18指令集0xB7AArch64e_phoff32程序头表偏移64e_shoff40节区表偏移文件尾部附近e_phnum56程序头数量8~12e_shnum60节区数量20~30加固后可能为 0e_phnum和e_shnum这两个值不值得信任是后面第 5 章要展开的事。这里先记住一条血泪经验任何从文件里读出来的偏移和长度在拿去当seek参数之前都要做一次边界校验否则一个构造过的 so 就能让你的解析器读到内存越界。2.2 程序头表p_offset 与 p_vaddr 是两个不同的坐标系程序头表是一组Elf64_Phdr每个 56 字节32 位是 32 字节字段依次是p_type、p_flags、p_offset、p_vaddr、p_paddr、p_filesz、p_memsz、p_align。p_type决定这一项描述什么只有PT_LOAD值为 1才会被真正映射。一个 so 通常有两到三个PT_LOAD一个只读的装代码和只读常量一个可读写的装数据、GOT 和.bss。p_flags是权限位读是 4、写是 2、执行是 1组合起来就是加载后那一页内存的属性。真正需要反复琢磨的是p_offset和p_vaddr的关系。p_offset是“这段内容在文件里从第几字节开始”p_vaddr是“这段内容加载后应该出现在哪个虚拟地址”。它们是两套坐标系只因为p_align这个约束才保持了一个固定差值。p_align一般是 0x1000也就是常说的 4KB 页部分移动端设备用 16KB 页值会变成 0x4000。加载器做映射时按页对齐切分p_vaddr去掉页内偏移必须等于p_offset去掉页内偏移。p_filesz和p_memsz的差值装的是.bss。文件里没有这块内容但内存里要给足空间加载器会在映射之后把那一段清零。解析 so 时如果只看p_filesz.bss里的全局变量就集体失踪。还有一个设计取舍值得说清楚相邻两个PT_LOAD的虚拟地址区间如果落在同一页里加载器没法给同一页设两套权限。常见的处理是以更严格的那套为准——一个只读段和一个可执行段压在同一页时这一页可能变成可读可执行。这不是 bug是页粒度映射的必然代价。2.3 用 Python 把 ELF 头和程序头读出来并做边界校验理解结构之后手写一遍比读十遍文档有用。下面这段代码只做两件事按EI_CLASS正确选择结构体格式以及在遍历程序头之前核对表本身是否落在文件范围内。import struct EHDR64 16sHHIQQQIHHHHHH # 小端 64 位 ELF 头 PHDR64 IIQQQQQQ # 程序头type/flags/off/vaddr/paddr/filesz/memsz/align def parse_elf(path): with open(path, rb) as f: blob f.read() size len(blob) ident blob[:16] if ident[:4] ! b\x7fELF: raise ValueError(不是 ELF 文件) ei_class, ei_data ident[4], ident[5] if ei_class ! 2: raise ValueError(这里只演示 64 位32 位需换结构体格式) if ei_data ! 1: raise ValueError(大端场景需把格式串前缀换成 ) # 注意格式串里的 16s 会吃掉 e_ident后面的字段偏移自动对齐 (_, e_type, e_machine, _, e_entry, e_phoff, _e_shoff, _e_flags, _e_ehsize, e_phentsize, e_phnum, *_rest) struct.unpack(EHDR64, blob[:64]) print(fmachine0x{e_machine:x} entry0x{e_entry:x} phnum{e_phnum}) # 边界校验表头 表长不能超出文件避免恶意文件把解析器带飞 table_end e_phoff e_phentsize * e_phnum if e_phoff 0 or table_end size or e_phentsize ! 56: raise ValueError(程序头表越界或长度非法) segs [] for i in range(e_phnum): off e_phoff i * e_phentsize p_type, p_flags, p_offset, p_vaddr, _, p_filesz, p_memsz, p_align \ struct.unpack_from(PHDR64, blob, off) segs.append((p_type, p_offset, p_vaddr, p_filesz, p_memsz)) if p_type 1: # PT_LOAD print(fLOAD off0x{p_offset:x} vaddr0x{p_vaddr:x} ffilesz0x{p_filesz:x} memsz0x{p_memsz:x} flags{p_flags}) return segs格式串16sHHIQQQIHHHHHH和小节 2.1 的字段表是一一对应的16s对应e_ident后面两个H是e_type和e_machineI是版本号三个Q是入口地址、程序头偏移、节区头偏移I是标志位随后一串H是各种尺寸和数量。用struct.unpack_from配合偏移而不用切片是为了后面复用到节区表和符号表时不用反复复制数据。e_phentsize ! 56这个判断看起来多余实际上拦得住一类样本把e_phentsize改成 0某些解析器会用phnum循环读到一片空白数据然后报告“没有 PT_LOAD 段”让人以为是脱壳失败。这段代码跑通之后你已经拿到了 so 的“执行视图”骨架——哪段字节会出现在哪个地址、有多大、什么权限。接下来的所有分析都是在这个骨架上去挂符号和重定位。3. 节区表与符号表.dynsym 和 .symtab 为什么不能混着读节区表是“链接视图”的核心。它把文件切成.text、.data、.rodata、.dynsym、.rela.dyn这样一块块命名区域分析工具靠它给用户呈现可读的结构。问题在于很多人把.symtab当成.dynsym的完整版觉得前者包含后者读哪个都行——在运行时这是错的。3.1 sh_link 与 sh_info节区表其实是一张带外键的表每个Elf64_Shdr是 64 字节字段是sh_name、sh_type、sh_flags、sh_addr、sh_offset、sh_size、sh_link、sh_info、sh_addralign、sh_entsize。sh_name是相对节区名字符串表的偏移不是指针那张表本身的位置由 ELF 头里的e_shstrndx指向。sh_type决定这一节是什么PROGBITS1是普通内容SYMTAB2和DYNSYM11是符号表STRTAB3是字符串表RELA4是带加数的重定位表DYNAMIC6是动态段GNU_HASH是哈希表。sh_link和sh_info才是这张表的精髓——它们让节区之间形成引用关系。sh_link是一个下标指向这一节依赖的另一节符号表的sh_link指向它的字符串表重定位表的sh_link指向它要作用的符号表。sh_info的含义随sh_type变化符号表里它表示“第一个非局部符号的下标”重定位表里它表示“这条重定位作用于哪个节区”。sh_info这个字段被忽略得非常普遍而它恰恰是判断符号可见性的关键。ELF 规定局部符号必须排在全局符号前面sh_info就是那条分界线。不知道这条规则把所有st_name非零的符号都当成导出符号分析结果自然离谱。对.dynsym而言它的sh_link指向.dynstrsh_info之后是真正的动态导出符号。.symtab的sh_link指向.strtab包含了局部符号、调试符号、静态函数但这份表可以被 strip 掉发布版 so 里经常不存在。运行时动态链接器只认.dynsym因为只有它在PT_LOAD覆盖范围内.symtab在加载后根本不进内存。3.2 符号表st_name 是偏移st_value 在 ET_DYN 里是相对地址一个符号表项Elf64_Sym是 24 字节st_name4 字节、st_info1、st_other1、st_shndx2、st_value8、st_size8。st_name是相对字符串表起点的字节偏移不是字符串长度也不是索引。st_info高低四位各管一摊高四位是绑定属性0 是局部、1 是全局、2 是弱符号低四位是类型1 是对象数据、2 是函数、6 是 TLS。想筛出导出的函数判断条件应该是“绑定为全局或弱 类型为函数”只看名字非空是不够的。st_value的语义随文件类型变。在ET_DYN的共享库里它是相对加载基址的偏移不是绝对虚拟地址函数在运行时真实地址等于加载基址加上这个值。解析崩溃栈时把st_value当绝对地址去比对就会出现整段偏移对不上的情况。st_shndx是符号所在节区下标值为 0 表示这个符号在本文件里没有定义需要动态链接器从别处解析0xFFF1表示绝对地址0xFFF2表示由公共块分配。解析导出符号时把st_shndx 0的项算进去就会得到一堆“看起来导出了但其实只是引用”的假符号。3.3 重定位改的是 GOT 槽位不是指令本身重定位表描述“加载时要把哪个地址写到哪里”。64 位下常见的是Elf64_Rela24 字节r_offset8 字节、r_info8 字节、r_addend8 字节。r_info不是单一值高 32 位是符号下标低 32 位是重定位类型。有些 32 位架构用的是Rel没有r_addend加数藏在被改写位置的原有内容里。重定位类型的编号跟指令集绑定。AArch64 上JUMP_SLOT是 1026GLOB_DAT是 1025RELATIVE是 1027x86-64 上JUMP_SLOT是 7GLOB_DAT是 6RELATIVE是 8。RELATIVE很特殊它的符号下标恒为 0语义是“把加载基址加到r_addend上再写进r_offset”本质上是一种位置无关的指针初始化。解析重定位时容易想当然的地方是r_offset它是要被改写位置的内存地址虚拟地址不是文件偏移。想把改写结果还原到文件里得先用程序头表把虚拟地址反算成文件偏移这一步在第 4 章会详细展开。3.4 延迟绑定第一次调用为什么跳进一段桩代码.rela.plt里的JUMP_SLOT条目描述的是外部函数调用的落地方式。函数被调用时编译器生成的不是直接跳转而是跳到.plt里的一小段桩代码桩代码从 GOT 里取出目标地址再跳过去。GOT 初始值指向桩代码里“解析之后继续执行”的那条指令于是第一次调用会绕回动态链接器由它算出真实地址写回 GOT之后每次调用就直接跳了。这套机制叫延迟绑定收益是启动时不用解析所有符号代价是第一次调用有额外开销。想从文件里分辨“哪些 GOT 槽位是函数指针”就看.rela.plt的条目——但要注意这些槽位在文件里存的是初始值真实地址在内存里脱壳或内存 dump 之后去读才能拿到解析结果。3.5 把 .dynsym 完整读出来有了前面的结构定义遍历动态符号只需要三次定位节区表 → 符号表节区 → 字符串表。SHDR64 IIQQQQIIQQ def find_sec_by_type(blob, shoff, shnum, shentsize, want_types): result [] for i in range(shnum): off shoff i * shentsize sh struct.unpack_from(SHDR64, blob, off) if sh[1] in want_types: result.append((i, sh)) return result def dump_dynsym(path): with open(path, rb) as f: blob f.read() *_, e_shoff, _, e_shentsize, e_shnum, _ struct.unpack(EHDR64, blob[:64])[5:11] # 注意这里只取 64 位 ELF 头中 shoff 之后的字段实际使用时建议整体解包 dynsym, find_sec_by_type(blob, e_shoff, e_shnum, e_shentsize, {11}) # SHT_DYNSYM idx, sh dynsym sh_link sh[6] # 指向 .dynstr 的节区下标 sym_off, sym_size, entsize sh[4], sh[5], sh[9] _, strsec [s for s in find_sec_by_type(blob, e_shoff, e_shnum, e_shentsize, {3}) if s[0] sh_link][0] str_off, str_size strsec[4], strsec[5] count sym_size // entsize for i in range(count): st_name, st_info, st_other, st_shndx, st_value, st_size_ \ struct.unpack_from(IBBHQQ, blob, sym_off i * entsize) if st_name 0: continue name blob[str_off st_name: blob.find(b\x00, str_off st_name)].decode(utf-8, replace) bind, typ st_info 4, st_info 0xF if bind in (1, 2) and typ 2 and st_shndx ! 0: # 全局/弱 函数 有定义 print(f{name} 0x{st_value:x} size{st_size_})struct.unpack_from(IBBHQQ, ...)的字段顺序和Elf64_Sym完全一致I是st_nameB是st_infoB是st_otherH是st_shndx两个Q分别是st_value和st_size。筛选条件写了三个绑定属性为全局或弱、类型为函数、st_shndx非零。少任何一个输出里都会混进未定义符号或数据对象。blob.find(b\x00, ...)是在字符串表里找结束符这一步必须带边界——恶意样本可以让st_name指向字符串表末尾之外find找不到结束符就会一路读到文件结束。实际工程里应该先校验str_off st_name str_off str_size。4. 动态段与初始化链路.dynamic 为什么是加壳与反调试的主战场节区表在运行时不被加载器读取那动态链接器靠什么找到符号表、字符串表、重定位表答案是.dynamic节区或者更准确地说是PT_DYNAMIC程序头指向的那块内容。这块内容在内存里一定存在而节区表可以不存在——这个差别决定了所有加固样本的分析策略。4.1 DT_ 标签一张用整数当 key 的配置表.dynamic是一串Elf64_Dyn每项 16 字节d_tag8 字节和d_val或d_ptr8 字节。d_tag是标签d_val的含义随标签变可能是个长度也可能是个虚拟地址。数组以DT_NULL值为 0结束。常见的标签里DT_NEEDED1是依赖库名的字符串表偏移DT_STRTAB5和DT_SYMTAB6分别是字符串表和符号表的虚拟地址DT_STRSZ10是字符串表长度DT_SYMENT11是单个符号项大小DT_RELA7和DT_RELASZ8是重定位表地址和总长度DT_JMPREL23单独指向 PLT 重定位DT_PLTRELSZ2是它的长度DT_PLTREL20说明它用Rel还是Rela。标签值含义注意点DT_STRTAB5字符串表虚拟地址需转文件偏移DT_SYMTAB6符号表虚拟地址同上DT_STRSZ10字符串表字节数用于边界校验DT_RELA7重定位表虚拟地址数量要除 entsizeDT_JMPREL23PLT 重定位地址常与 RELA 分开DT_INIT12初始化函数地址早于 init_arrayDT_INIT_ARRAY25初始化函数指针数组加壳重点DT_GNU_HASH0x6ffffef5符号哈希表地址反推符号数量这些地址全是虚拟地址不是文件偏移。想从文件里读到对应内容必须先做一次地址翻译遍历PT_LOAD找到满足p_vaddr addr p_vaddr p_filesz的那一段然后用addr - p_vaddr p_offset换算出文件位置。这一步是所有 so 解析器都绕不开的核心转换。4.2 节区头被抹掉之后怎么靠 PT_DYNAMIC 重建符号视图加固工具最常见的一招是把 ELF 头里的e_shoff、e_shnum、e_shstrndx全部清零。这时候所有依赖节区表的工具都会失效但程序照样能跑因为加载器不用节区表。重建视图的路径只有一条PT_DYNAMIC。流程是先从程序头表里找到p_type 2的项拿到动态段的虚拟地址翻译成文件偏移后逐项读Elf64_Dyn直到d_tag 0为止把读到的标签存进字典然后按DT_STRTAB、DT_SYMTAB、DT_STRSZ依次翻译地址。麻烦的是符号数量。有节区表的时候.dynsym的sh_size除以sh_entsize就是数量。没有节区表只能靠DT_HASH或DT_GNU_HASH反推。DT_HASH的头部两个 32 位整数分别是桶数和链数链数就是符号数量。DT_GNU_HASH更绕头部有桶数量、符号表偏移、布隆过滤器尺寸、布隆过滤器移位四个字段得先遍历桶数组找到最大的桶值再沿着链一路走到链尾才能确定最后一个符号的下标。def vaddr_to_off(segs, addr): for p_type, p_off, p_vaddr, p_filesz, p_memsz in segs: if p_type 1 and p_vaddr addr p_vaddr p_filesz: return addr - p_vaddr p_off raise ValueError(f地址 0x{addr:x} 不落在任何可加载段内) def read_dynamic(blob, segs): dyn {} dyn_vaddr next(s[2] for s in segs if s[0] 2) # PT_DYNAMIC off vaddr_to_off(segs, dyn_vaddr) while True: d_tag, d_val struct.unpack_from(QQ, blob, off) if d_tag 0: # DT_NULL 结束 break dyn[d_tag] d_val off 16 return dyn def symbol_count(blob, segs, dyn): if 5 in dyn: # DT_HASH 优先结构最简单 h_off vaddr_to_off(segs, dyn[5]) nbucket, nchain struct.unpack_from(II, blob, h_off) return nchain if 0x6ffffef5 in dyn: # 退化到 DT_GNU_HASH h_off vaddr_to_off(segs, dyn[0x6ffffef5]) nbuckets, symoff, bloom_size, bloom_shift struct.unpack_from(IIII, blob, h_off) buckets_off h_off 16 bloom_size * 8 buckets struct.unpack_from(f{nbuckets}I, blob, buckets_off) max_sym max(buckets) if max_sym 0: return symoff chain_off buckets_off nbuckets * 4 idx max_sym while True: h struct.unpack_from(I, blob, chain_off (idx - symoff) * 4)[0] if h 1: return idx 1 idx 1 raise ValueError(无法确定符号数量)vaddr_to_off里用p_filesz而不是p_memsz做上界是因为.bss那段在文件里没有内容用p_memsz会算出越界的偏移。read_dynamic没有设循环上限实际使用时要加一个最大项数保护防止恶意文件里没有DT_NULL导致死循环。symbol_count里DT_GNU_HASH的遍历逻辑是桶数组里存的是“该桶链上最后一个符号的下标”链里每一项的最低位是结束标记遇到最低位为 1 就说明到链尾了。这个反推过程依赖链的连续性如果加固工具打乱了链结构就只能退而求其次从DT_STRTAB的地址往前推一个保守上界——符号表紧挨着字符串表存放是常见布局但这不是规范保证的。4.3 init_array 的执行时机比常规入口更早的那一段初始化的调用顺序是固定的.init段先跑然后DT_INIT指向的函数然后是DT_INIT_ARRAY指向的函数指针数组最后才是运行时框架层的入口回调。DT_INIT_ARRAY的值是虚拟地址DT_INIT_ARRAYSZ是字节长度数组里每一项是一个函数指针——共享库是位置无关的所以这些指针要么是相对基址的偏移要么依赖RELATIVE重定位在加载时被修正。解析时要注意区分如果这一项落在某个PT_LOAD的地址范围内它就是偏移如果是一个极小值比如 0x1234它大概率是相对偏移。加壳样本把解密逻辑塞进DT_INIT_ARRAY原因很直接这个数组在动态链接器手里被执行早于任何业务代码而且完全可以指向一段在内存里被解密出来的代码。分析这类样本时从文件里静态读出来的init_array内容往往是加密的必须先确认有没有RELATIVE重定位作用在这块区域——有的话说明真实地址是加载时才算出来的静态读到的只是占位值。还有一种更隐蔽的做法把DT_INIT_ARRAY直接改写成指向.bss里的一块空间那块空间在加载时被清零然后由更早执行的.init段把函数指针写进去。这种布局下静态解析会看到一个全零的数组只能靠动态跟踪才能拿到真实入口。5. 解析 so 的避坑与排查五类不报错但答案错的现场解析器最怕的不是抛异常是安安静静给出一个错误答案然后你拿着这个答案去定位问题越找越远。下面这五类情况每一种都值得记进排查手册。5.1 符号名全是乱码st_name 越界与字符串表错位现象解析.dynsym时一部分符号名正常另一部分是看不懂的字节还有一部分直接是空字符串。原因st_name是相对字符串表起点的偏移一旦字符串表的文件偏移算错所有名字都会整体错位。最常见的错法是忽略了.dynstr的sh_offset和.dynsym的sh_link之间的间接关系直接把st_name当成文件绝对偏移去读。解决先在节区表里找到.dynstr的sh_offset和sh_size然后校验sh_offset st_name sh_offset sh_size再切片。同时检查st_name 0的情况——0 表示“无名字”应该跳过而不是读出一个空字符串。5.2 section 数量为 0工具直接报错退出现象e_shoff不为 0 但e_shnum为 0或者e_shstrndx等于0xFFFF所有依赖节区名的工具都失败。原因不是文件损坏是节区头被刻意处理过。e_shnum为 0 有两种语义真的没有节区或者“节区数量太多实际数量存在第 0 个节区的sh_size里”后者是 ELF 为超多节区文件留的扩展写法e_shstrndx等于0xFFFF表示真实下标存在第 0 个节区的sh_link里。解决先判断e_shoff是否为 0为 0 就直接走PT_DYNAMIC重建路线不为 0 就按扩展语义读第 0 个节区从sh_size和sh_link里取真实值。加固样本通常把e_shoff也清零这时候任何节区相关的路径都不该被尝试。5.3 虚拟地址当文件偏移用整段偏出去一个页现象按DT_SYMTAB的值去文件里读符号读出来的内容完全不像是符号表前几个字节看着像代码。原因DT_SYMTAB是虚拟地址.dynsym的文件偏移通常比它小一个到两个页。直接把虚拟地址当seek参数读到的位置偏了整段。解决写一个地址翻译函数遍历PT_LOAD做区间匹配用addr - p_vaddr p_offset换算。翻译完再交叉验证一次把结果附近的字节按符号表结构解出来看st_name是否落在DT_STRSZ范围内如果全部越界说明翻译错了。5.4 重定位条数对不上长度要除以项大小现象按DT_RELASZ循环读重定位读出来的项数比预期多一倍后面的项全是垃圾数据甚至把解析器带崩。原因DT_RELASZ是字节长度不是项数。Elf64_Rela是 24 字节32 位的Rel是 8 字节Rela是 12 字节。把字节长度当项数循环实际读的长度是应有的 24 倍。解决项数等于DT_RELASZ / sizeof(项)项大小由DT_PLTREL和位宽共同决定。另外要分别处理DT_RELA和DT_JMPREL它们是两块独立的区域混在一起读会出现重复项。5.5 32 位库按 64 位结构读字段错位却不报错现象解析一个 32 位 soe_phoff读出来是个巨大数字或者p_vaddr明显不合理但程序没抛异常只是后面全错。原因64 位 ELF 头是 64 字节32 位是 52 字节e_phoff在 64 位里是 8 字节的Q在 32 位里是 4 字节的I。用同一套struct格式去解后面的字段会整体错位而错位之后读到的值往往仍在合法范围内。解决把EI_CLASS作为第一判断分支为两种位宽各准备一套格式串任何共享代码路径都要显式传入位宽。测试集里至少要放一个 32 位样本否则这个问题在开发阶段完全暴露不出来。6. 设计取舍执行视图与链接视图为什么要分成两套PT_LOAD和节区表描述的是同一份文件却是两套互不依赖的视图。这不是历史包袱是有意的设计执行视图要在加载时被最小代价地消费所以它按页对齐、按权限分组一个段里可能塞着十几节链接视图要支持符号查找、调试信息、节区级增量链接所以它按语义分节粒度细到每个.text.foo。两套视图分开的直接后果是节区表可以整段删掉程序照跑程序头表少一项程序立刻加载失败。这也解释了为什么加固工具优先破坏节区表——成本低收益高不影响程序运行。代价是解析器必须处理“节区表不存在”这条路径而且要在两条路径上给出一致的结果。验证方法有三条我一般会同时跑第一符号数量交叉校验。有节区表时用sh_size / sh_entsize没有时用DT_HASH或DT_GNU_HASH反推两个值必须相等。不相等说明其中一条路径读错了。第二重定位落地页校验。把所有RELATIVE重定位的r_offset加上r_addend检查结果是否落在某个可写PT_LOAD的范围内。落在只读段或者段外说明地址翻译或者段解析有问题。第三段区间覆盖校验。把所有PT_LOAD的[p_vaddr, p_vaddr p_memsz)按页对齐合并检查.dynsym、.dynstr、.rela.dyn的地址是否都被覆盖。任何一个不在覆盖范围内说明这个结构的地址是从错误的地方读来的。提示这三条校验不要只在开发时跑线上解析不可信的 so 时也应该跑。校验失败的样本直接进隔离队列比让它在业务逻辑里产生一个错误地址安全得多。取舍的另一面是性能。按页分组意味着同一个PT_LOAD里混着可执行代码和只读常量做节区级的内存保护比如把.rodata单独设成只读不可执行在运行时做不到只能退回到段级权限。这是用空间换简单段数量少、映射次数少、内核页表项少代价是权限控制的粒度变粗。我之前写过一个批量分析 so 的脚本图省事只处理了 64 位样本跑了几千个文件都没报错直到有人扔进来一个 32 位的库输出的重定位表条目数比实际多了三倍排查了一整天才发现是格式串没换。从那以后我每次动手写地址翻译函数都会先跑一遍「符号数双路交叉 重定位落地页 段区间覆盖」这三项检查确认两条视图给出一致结果再往下做分析。希望帮到你。本文还有配套的精品资源点击获取
简介围绕Android平台.so动态链接库解析与JNI实践整理的示例工程资料面向具备一定Java基础、希望理解原生库结构与调用机制的Android开发者。内容以可导入的示例工程为线索涉及ELF头部、符号表、重定位信息等结构认知以及readelf、objdump、nm等分析工具的学习场景并延伸到gdbserver配合gdb的原生调试、JNIEXPORT与JNICALL函数声明、javah头文件生成和ABI分割打包等常见问题适合用作课堂演示、自学对照或项目排错参考。压缩包共30个文件包含18个class、5个java源文件、2个h头文件、2个so库以及classpath、prefs、project等工程配置整体约58KB体积轻便便于快速导入查看目录关系。已有3147人学习下载读者可借助其中的Java与C/C对应文件、现成so库和工程配置梳理Java层加载原生库、符号查找与多架构兼容的实践思路。1. 解析 SO 文件加载器为什么不读你的代码只读两张表很多人第一次解析 so 文件会默认它和普通的可执行文件差不多——代码、数据、符号按顺序排好从头读下去就行。把文件扔进十六进制视图就会发现开头几十个字节里没有一个字节是机器指令全是元数据魔数、位宽、字节序、入口地址以及两张表的位置和长度。真正的指令要等加载器读完这张“目录”才会被映射进内存。反直觉的结论在这里解析 so 文件九成工作量不是读机器码而是把几张表之间的指针关系理顺而其中最常被人翻来覆去琢磨的节区表在运行时压根不被加载器读取。加载器只认程序头表节区表是给链接器和分析工具看的。搞不清这条分界线地址错位、符号对不上、工具报错就都成了玄学。2. ELF 头与程序头表加载器凭什么只信这两张表ELF 头是整份文件的入口加载器拿到一个 so第一步就是读它程序头表紧随其后描述“这段字节应该被映射到哪个虚拟地址、给什么权限”。这两张表读错一个字段后面全是错的。2.1 e_ident 的 16 个字节位宽、字节序、ABI 一次交代清楚文件前 16 个字节是e_ident它是一段自描述的字节序列不依赖任何外部信息就能判断该怎么继续读下去。第 0~3 字节是魔数0x7F 45 4C 46直译过来就是“ELF”第 4 字节EI_CLASS决定后面所有结构的排布——值为 1 表示 32 位值为 2 表示 64 位第 5 字节EI_DATA表示字节序1 是小端、2 是大端第 6 字节是版本号目前恒为 1第 7 字节EI_OSABI标记目标 ABI第 8 字节是 ABI 版本第 9~15 字节是保留填充。这里最容易翻车的是“先入为主”。不少人写解析器时直接按 64 位结构体去unpack遇到 32 位库也不报错——因为e_phoff这类字段在两种位宽下的偏移不同读出来的值恰好落在合法范围内程序照跑只是后面所有地址都偏了。EI_CLASS必须是第一个分支条件。紧跟在e_ident之后的是e_type。共享库的类型是ET_DYN值为 3但要注意位置无关的可执行文件也是ET_DYN。所以光看e_type判断不了“这是不是动态库”得再看有没有DT_SONAME或者看是否带PT_INTERP。e_machine标出指令集AArch64 是0xB732 位 ARM 是0x28x86-64 是0x3E——解析重定位类型时必须先拿到这个值因为同一套重定位机制在不同指令集下的编号完全不同。64 位 ELF 头一共 64 字节32 位是 52 字节。剩下的字段里e_phoff是程序头表的文件偏移e_phentsize是单个表项大小e_phnum是表项数量e_shoff、e_shentsize、e_shnum对应节区表e_shstrndx指向节区名字符串表所在的下标。字段64 位偏移含义典型值e_ident0魔数 位宽 字节序7F 45 4C 46 02 01 01e_type16文件类型3ET_DYNe_machine18指令集0xB7AArch64e_phoff32程序头表偏移64e_shoff40节区表偏移文件尾部附近e_phnum56程序头数量8~12e_shnum60节区数量20~30加固后可能为 0e_phnum和e_shnum这两个值不值得信任是后面第 5 章要展开的事。这里先记住一条血泪经验任何从文件里读出来的偏移和长度在拿去当seek参数之前都要做一次边界校验否则一个构造过的 so 就能让你的解析器读到内存越界。2.2 程序头表p_offset 与 p_vaddr 是两个不同的坐标系程序头表是一组Elf64_Phdr每个 56 字节32 位是 32 字节字段依次是p_type、p_flags、p_offset、p_vaddr、p_paddr、p_filesz、p_memsz、p_align。p_type决定这一项描述什么只有PT_LOAD值为 1才会被真正映射。一个 so 通常有两到三个PT_LOAD一个只读的装代码和只读常量一个可读写的装数据、GOT 和.bss。p_flags是权限位读是 4、写是 2、执行是 1组合起来就是加载后那一页内存的属性。真正需要反复琢磨的是p_offset和p_vaddr的关系。p_offset是“这段内容在文件里从第几字节开始”p_vaddr是“这段内容加载后应该出现在哪个虚拟地址”。它们是两套坐标系只因为p_align这个约束才保持了一个固定差值。p_align一般是 0x1000也就是常说的 4KB 页部分移动端设备用 16KB 页值会变成 0x4000。加载器做映射时按页对齐切分p_vaddr去掉页内偏移必须等于p_offset去掉页内偏移。p_filesz和p_memsz的差值装的是.bss。文件里没有这块内容但内存里要给足空间加载器会在映射之后把那一段清零。解析 so 时如果只看p_filesz.bss里的全局变量就集体失踪。还有一个设计取舍值得说清楚相邻两个PT_LOAD的虚拟地址区间如果落在同一页里加载器没法给同一页设两套权限。常见的处理是以更严格的那套为准——一个只读段和一个可执行段压在同一页时这一页可能变成可读可执行。这不是 bug是页粒度映射的必然代价。2.3 用 Python 把 ELF 头和程序头读出来并做边界校验理解结构之后手写一遍比读十遍文档有用。下面这段代码只做两件事按EI_CLASS正确选择结构体格式以及在遍历程序头之前核对表本身是否落在文件范围内。import struct EHDR64 16sHHIQQQIHHHHHH # 小端 64 位 ELF 头 PHDR64 IIQQQQQQ # 程序头type/flags/off/vaddr/paddr/filesz/memsz/align def parse_elf(path): with open(path, rb) as f: blob f.read() size len(blob) ident blob[:16] if ident[:4] ! b\x7fELF: raise ValueError(不是 ELF 文件) ei_class, ei_data ident[4], ident[5] if ei_class ! 2: raise ValueError(这里只演示 64 位32 位需换结构体格式) if ei_data ! 1: raise ValueError(大端场景需把格式串前缀换成 ) # 注意格式串里的 16s 会吃掉 e_ident后面的字段偏移自动对齐 (_, e_type, e_machine, _, e_entry, e_phoff, _e_shoff, _e_flags, _e_ehsize, e_phentsize, e_phnum, *_rest) struct.unpack(EHDR64, blob[:64]) print(fmachine0x{e_machine:x} entry0x{e_entry:x} phnum{e_phnum}) # 边界校验表头 表长不能超出文件避免恶意文件把解析器带飞 table_end e_phoff e_phentsize * e_phnum if e_phoff 0 or table_end size or e_phentsize ! 56: raise ValueError(程序头表越界或长度非法) segs [] for i in range(e_phnum): off e_phoff i * e_phentsize p_type, p_flags, p_offset, p_vaddr, _, p_filesz, p_memsz, p_align \ struct.unpack_from(PHDR64, blob, off) segs.append((p_type, p_offset, p_vaddr, p_filesz, p_memsz)) if p_type 1: # PT_LOAD print(fLOAD off0x{p_offset:x} vaddr0x{p_vaddr:x} ffilesz0x{p_filesz:x} memsz0x{p_memsz:x} flags{p_flags}) return segs格式串16sHHIQQQIHHHHHH和小节 2.1 的字段表是一一对应的16s对应e_ident后面两个H是e_type和e_machineI是版本号三个Q是入口地址、程序头偏移、节区头偏移I是标志位随后一串H是各种尺寸和数量。用struct.unpack_from配合偏移而不用切片是为了后面复用到节区表和符号表时不用反复复制数据。e_phentsize ! 56这个判断看起来多余实际上拦得住一类样本把e_phentsize改成 0某些解析器会用phnum循环读到一片空白数据然后报告“没有 PT_LOAD 段”让人以为是脱壳失败。这段代码跑通之后你已经拿到了 so 的“执行视图”骨架——哪段字节会出现在哪个地址、有多大、什么权限。接下来的所有分析都是在这个骨架上去挂符号和重定位。3. 节区表与符号表.dynsym 和 .symtab 为什么不能混着读节区表是“链接视图”的核心。它把文件切成.text、.data、.rodata、.dynsym、.rela.dyn这样一块块命名区域分析工具靠它给用户呈现可读的结构。问题在于很多人把.symtab当成.dynsym的完整版觉得前者包含后者读哪个都行——在运行时这是错的。3.1 sh_link 与 sh_info节区表其实是一张带外键的表每个Elf64_Shdr是 64 字节字段是sh_name、sh_type、sh_flags、sh_addr、sh_offset、sh_size、sh_link、sh_info、sh_addralign、sh_entsize。sh_name是相对节区名字符串表的偏移不是指针那张表本身的位置由 ELF 头里的e_shstrndx指向。sh_type决定这一节是什么PROGBITS1是普通内容SYMTAB2和DYNSYM11是符号表STRTAB3是字符串表RELA4是带加数的重定位表DYNAMIC6是动态段GNU_HASH是哈希表。sh_link和sh_info才是这张表的精髓——它们让节区之间形成引用关系。sh_link是一个下标指向这一节依赖的另一节符号表的sh_link指向它的字符串表重定位表的sh_link指向它要作用的符号表。sh_info的含义随sh_type变化符号表里它表示“第一个非局部符号的下标”重定位表里它表示“这条重定位作用于哪个节区”。sh_info这个字段被忽略得非常普遍而它恰恰是判断符号可见性的关键。ELF 规定局部符号必须排在全局符号前面sh_info就是那条分界线。不知道这条规则把所有st_name非零的符号都当成导出符号分析结果自然离谱。对.dynsym而言它的sh_link指向.dynstrsh_info之后是真正的动态导出符号。.symtab的sh_link指向.strtab包含了局部符号、调试符号、静态函数但这份表可以被 strip 掉发布版 so 里经常不存在。运行时动态链接器只认.dynsym因为只有它在PT_LOAD覆盖范围内.symtab在加载后根本不进内存。3.2 符号表st_name 是偏移st_value 在 ET_DYN 里是相对地址一个符号表项Elf64_Sym是 24 字节st_name4 字节、st_info1、st_other1、st_shndx2、st_value8、st_size8。st_name是相对字符串表起点的字节偏移不是字符串长度也不是索引。st_info高低四位各管一摊高四位是绑定属性0 是局部、1 是全局、2 是弱符号低四位是类型1 是对象数据、2 是函数、6 是 TLS。想筛出导出的函数判断条件应该是“绑定为全局或弱 类型为函数”只看名字非空是不够的。st_value的语义随文件类型变。在ET_DYN的共享库里它是相对加载基址的偏移不是绝对虚拟地址函数在运行时真实地址等于加载基址加上这个值。解析崩溃栈时把st_value当绝对地址去比对就会出现整段偏移对不上的情况。st_shndx是符号所在节区下标值为 0 表示这个符号在本文件里没有定义需要动态链接器从别处解析0xFFF1表示绝对地址0xFFF2表示由公共块分配。解析导出符号时把st_shndx 0的项算进去就会得到一堆“看起来导出了但其实只是引用”的假符号。3.3 重定位改的是 GOT 槽位不是指令本身重定位表描述“加载时要把哪个地址写到哪里”。64 位下常见的是Elf64_Rela24 字节r_offset8 字节、r_info8 字节、r_addend8 字节。r_info不是单一值高 32 位是符号下标低 32 位是重定位类型。有些 32 位架构用的是Rel没有r_addend加数藏在被改写位置的原有内容里。重定位类型的编号跟指令集绑定。AArch64 上JUMP_SLOT是 1026GLOB_DAT是 1025RELATIVE是 1027x86-64 上JUMP_SLOT是 7GLOB_DAT是 6RELATIVE是 8。RELATIVE很特殊它的符号下标恒为 0语义是“把加载基址加到r_addend上再写进r_offset”本质上是一种位置无关的指针初始化。解析重定位时容易想当然的地方是r_offset它是要被改写位置的内存地址虚拟地址不是文件偏移。想把改写结果还原到文件里得先用程序头表把虚拟地址反算成文件偏移这一步在第 4 章会详细展开。3.4 延迟绑定第一次调用为什么跳进一段桩代码.rela.plt里的JUMP_SLOT条目描述的是外部函数调用的落地方式。函数被调用时编译器生成的不是直接跳转而是跳到.plt里的一小段桩代码桩代码从 GOT 里取出目标地址再跳过去。GOT 初始值指向桩代码里“解析之后继续执行”的那条指令于是第一次调用会绕回动态链接器由它算出真实地址写回 GOT之后每次调用就直接跳了。这套机制叫延迟绑定收益是启动时不用解析所有符号代价是第一次调用有额外开销。想从文件里分辨“哪些 GOT 槽位是函数指针”就看.rela.plt的条目——但要注意这些槽位在文件里存的是初始值真实地址在内存里脱壳或内存 dump 之后去读才能拿到解析结果。3.5 把 .dynsym 完整读出来有了前面的结构定义遍历动态符号只需要三次定位节区表 → 符号表节区 → 字符串表。SHDR64 IIQQQQIIQQ def find_sec_by_type(blob, shoff, shnum, shentsize, want_types): result [] for i in range(shnum): off shoff i * shentsize sh struct.unpack_from(SHDR64, blob, off) if sh[1] in want_types: result.append((i, sh)) return result def dump_dynsym(path): with open(path, rb) as f: blob f.read() *_, e_shoff, _, e_shentsize, e_shnum, _ struct.unpack(EHDR64, blob[:64])[5:11] # 注意这里只取 64 位 ELF 头中 shoff 之后的字段实际使用时建议整体解包 dynsym, find_sec_by_type(blob, e_shoff, e_shnum, e_shentsize, {11}) # SHT_DYNSYM idx, sh dynsym sh_link sh[6] # 指向 .dynstr 的节区下标 sym_off, sym_size, entsize sh[4], sh[5], sh[9] _, strsec [s for s in find_sec_by_type(blob, e_shoff, e_shnum, e_shentsize, {3}) if s[0] sh_link][0] str_off, str_size strsec[4], strsec[5] count sym_size // entsize for i in range(count): st_name, st_info, st_other, st_shndx, st_value, st_size_ \ struct.unpack_from(IBBHQQ, blob, sym_off i * entsize) if st_name 0: continue name blob[str_off st_name: blob.find(b\x00, str_off st_name)].decode(utf-8, replace) bind, typ st_info 4, st_info 0xF if bind in (1, 2) and typ 2 and st_shndx ! 0: # 全局/弱 函数 有定义 print(f{name} 0x{st_value:x} size{st_size_})struct.unpack_from(IBBHQQ, ...)的字段顺序和Elf64_Sym完全一致I是st_nameB是st_infoB是st_otherH是st_shndx两个Q分别是st_value和st_size。筛选条件写了三个绑定属性为全局或弱、类型为函数、st_shndx非零。少任何一个输出里都会混进未定义符号或数据对象。blob.find(b\x00, ...)是在字符串表里找结束符这一步必须带边界——恶意样本可以让st_name指向字符串表末尾之外find找不到结束符就会一路读到文件结束。实际工程里应该先校验str_off st_name str_off str_size。4. 动态段与初始化链路.dynamic 为什么是加壳与反调试的主战场节区表在运行时不被加载器读取那动态链接器靠什么找到符号表、字符串表、重定位表答案是.dynamic节区或者更准确地说是PT_DYNAMIC程序头指向的那块内容。这块内容在内存里一定存在而节区表可以不存在——这个差别决定了所有加固样本的分析策略。4.1 DT_ 标签一张用整数当 key 的配置表.dynamic是一串Elf64_Dyn每项 16 字节d_tag8 字节和d_val或d_ptr8 字节。d_tag是标签d_val的含义随标签变可能是个长度也可能是个虚拟地址。数组以DT_NULL值为 0结束。常见的标签里DT_NEEDED1是依赖库名的字符串表偏移DT_STRTAB5和DT_SYMTAB6分别是字符串表和符号表的虚拟地址DT_STRSZ10是字符串表长度DT_SYMENT11是单个符号项大小DT_RELA7和DT_RELASZ8是重定位表地址和总长度DT_JMPREL23单独指向 PLT 重定位DT_PLTRELSZ2是它的长度DT_PLTREL20说明它用Rel还是Rela。标签值含义注意点DT_STRTAB5字符串表虚拟地址需转文件偏移DT_SYMTAB6符号表虚拟地址同上DT_STRSZ10字符串表字节数用于边界校验DT_RELA7重定位表虚拟地址数量要除 entsizeDT_JMPREL23PLT 重定位地址常与 RELA 分开DT_INIT12初始化函数地址早于 init_arrayDT_INIT_ARRAY25初始化函数指针数组加壳重点DT_GNU_HASH0x6ffffef5符号哈希表地址反推符号数量这些地址全是虚拟地址不是文件偏移。想从文件里读到对应内容必须先做一次地址翻译遍历PT_LOAD找到满足p_vaddr addr p_vaddr p_filesz的那一段然后用addr - p_vaddr p_offset换算出文件位置。这一步是所有 so 解析器都绕不开的核心转换。4.2 节区头被抹掉之后怎么靠 PT_DYNAMIC 重建符号视图加固工具最常见的一招是把 ELF 头里的e_shoff、e_shnum、e_shstrndx全部清零。这时候所有依赖节区表的工具都会失效但程序照样能跑因为加载器不用节区表。重建视图的路径只有一条PT_DYNAMIC。流程是先从程序头表里找到p_type 2的项拿到动态段的虚拟地址翻译成文件偏移后逐项读Elf64_Dyn直到d_tag 0为止把读到的标签存进字典然后按DT_STRTAB、DT_SYMTAB、DT_STRSZ依次翻译地址。麻烦的是符号数量。有节区表的时候.dynsym的sh_size除以sh_entsize就是数量。没有节区表只能靠DT_HASH或DT_GNU_HASH反推。DT_HASH的头部两个 32 位整数分别是桶数和链数链数就是符号数量。DT_GNU_HASH更绕头部有桶数量、符号表偏移、布隆过滤器尺寸、布隆过滤器移位四个字段得先遍历桶数组找到最大的桶值再沿着链一路走到链尾才能确定最后一个符号的下标。def vaddr_to_off(segs, addr): for p_type, p_off, p_vaddr, p_filesz, p_memsz in segs: if p_type 1 and p_vaddr addr p_vaddr p_filesz: return addr - p_vaddr p_off raise ValueError(f地址 0x{addr:x} 不落在任何可加载段内) def read_dynamic(blob, segs): dyn {} dyn_vaddr next(s[2] for s in segs if s[0] 2) # PT_DYNAMIC off vaddr_to_off(segs, dyn_vaddr) while True: d_tag, d_val struct.unpack_from(QQ, blob, off) if d_tag 0: # DT_NULL 结束 break dyn[d_tag] d_val off 16 return dyn def symbol_count(blob, segs, dyn): if 5 in dyn: # DT_HASH 优先结构最简单 h_off vaddr_to_off(segs, dyn[5]) nbucket, nchain struct.unpack_from(II, blob, h_off) return nchain if 0x6ffffef5 in dyn: # 退化到 DT_GNU_HASH h_off vaddr_to_off(segs, dyn[0x6ffffef5]) nbuckets, symoff, bloom_size, bloom_shift struct.unpack_from(IIII, blob, h_off) buckets_off h_off 16 bloom_size * 8 buckets struct.unpack_from(f{nbuckets}I, blob, buckets_off) max_sym max(buckets) if max_sym 0: return symoff chain_off buckets_off nbuckets * 4 idx max_sym while True: h struct.unpack_from(I, blob, chain_off (idx - symoff) * 4)[0] if h 1: return idx 1 idx 1 raise ValueError(无法确定符号数量)vaddr_to_off里用p_filesz而不是p_memsz做上界是因为.bss那段在文件里没有内容用p_memsz会算出越界的偏移。read_dynamic没有设循环上限实际使用时要加一个最大项数保护防止恶意文件里没有DT_NULL导致死循环。symbol_count里DT_GNU_HASH的遍历逻辑是桶数组里存的是“该桶链上最后一个符号的下标”链里每一项的最低位是结束标记遇到最低位为 1 就说明到链尾了。这个反推过程依赖链的连续性如果加固工具打乱了链结构就只能退而求其次从DT_STRTAB的地址往前推一个保守上界——符号表紧挨着字符串表存放是常见布局但这不是规范保证的。4.3 init_array 的执行时机比常规入口更早的那一段初始化的调用顺序是固定的.init段先跑然后DT_INIT指向的函数然后是DT_INIT_ARRAY指向的函数指针数组最后才是运行时框架层的入口回调。DT_INIT_ARRAY的值是虚拟地址DT_INIT_ARRAYSZ是字节长度数组里每一项是一个函数指针——共享库是位置无关的所以这些指针要么是相对基址的偏移要么依赖RELATIVE重定位在加载时被修正。解析时要注意区分如果这一项落在某个PT_LOAD的地址范围内它就是偏移如果是一个极小值比如 0x1234它大概率是相对偏移。加壳样本把解密逻辑塞进DT_INIT_ARRAY原因很直接这个数组在动态链接器手里被执行早于任何业务代码而且完全可以指向一段在内存里被解密出来的代码。分析这类样本时从文件里静态读出来的init_array内容往往是加密的必须先确认有没有RELATIVE重定位作用在这块区域——有的话说明真实地址是加载时才算出来的静态读到的只是占位值。还有一种更隐蔽的做法把DT_INIT_ARRAY直接改写成指向.bss里的一块空间那块空间在加载时被清零然后由更早执行的.init段把函数指针写进去。这种布局下静态解析会看到一个全零的数组只能靠动态跟踪才能拿到真实入口。5. 解析 so 的避坑与排查五类不报错但答案错的现场解析器最怕的不是抛异常是安安静静给出一个错误答案然后你拿着这个答案去定位问题越找越远。下面这五类情况每一种都值得记进排查手册。5.1 符号名全是乱码st_name 越界与字符串表错位现象解析.dynsym时一部分符号名正常另一部分是看不懂的字节还有一部分直接是空字符串。原因st_name是相对字符串表起点的偏移一旦字符串表的文件偏移算错所有名字都会整体错位。最常见的错法是忽略了.dynstr的sh_offset和.dynsym的sh_link之间的间接关系直接把st_name当成文件绝对偏移去读。解决先在节区表里找到.dynstr的sh_offset和sh_size然后校验sh_offset st_name sh_offset sh_size再切片。同时检查st_name 0的情况——0 表示“无名字”应该跳过而不是读出一个空字符串。5.2 section 数量为 0工具直接报错退出现象e_shoff不为 0 但e_shnum为 0或者e_shstrndx等于0xFFFF所有依赖节区名的工具都失败。原因不是文件损坏是节区头被刻意处理过。e_shnum为 0 有两种语义真的没有节区或者“节区数量太多实际数量存在第 0 个节区的sh_size里”后者是 ELF 为超多节区文件留的扩展写法e_shstrndx等于0xFFFF表示真实下标存在第 0 个节区的sh_link里。解决先判断e_shoff是否为 0为 0 就直接走PT_DYNAMIC重建路线不为 0 就按扩展语义读第 0 个节区从sh_size和sh_link里取真实值。加固样本通常把e_shoff也清零这时候任何节区相关的路径都不该被尝试。5.3 虚拟地址当文件偏移用整段偏出去一个页现象按DT_SYMTAB的值去文件里读符号读出来的内容完全不像是符号表前几个字节看着像代码。原因DT_SYMTAB是虚拟地址.dynsym的文件偏移通常比它小一个到两个页。直接把虚拟地址当seek参数读到的位置偏了整段。解决写一个地址翻译函数遍历PT_LOAD做区间匹配用addr - p_vaddr p_offset换算。翻译完再交叉验证一次把结果附近的字节按符号表结构解出来看st_name是否落在DT_STRSZ范围内如果全部越界说明翻译错了。5.4 重定位条数对不上长度要除以项大小现象按DT_RELASZ循环读重定位读出来的项数比预期多一倍后面的项全是垃圾数据甚至把解析器带崩。原因DT_RELASZ是字节长度不是项数。Elf64_Rela是 24 字节32 位的Rel是 8 字节Rela是 12 字节。把字节长度当项数循环实际读的长度是应有的 24 倍。解决项数等于DT_RELASZ / sizeof(项)项大小由DT_PLTREL和位宽共同决定。另外要分别处理DT_RELA和DT_JMPREL它们是两块独立的区域混在一起读会出现重复项。5.5 32 位库按 64 位结构读字段错位却不报错现象解析一个 32 位 soe_phoff读出来是个巨大数字或者p_vaddr明显不合理但程序没抛异常只是后面全错。原因64 位 ELF 头是 64 字节32 位是 52 字节e_phoff在 64 位里是 8 字节的Q在 32 位里是 4 字节的I。用同一套struct格式去解后面的字段会整体错位而错位之后读到的值往往仍在合法范围内。解决把EI_CLASS作为第一判断分支为两种位宽各准备一套格式串任何共享代码路径都要显式传入位宽。测试集里至少要放一个 32 位样本否则这个问题在开发阶段完全暴露不出来。6. 设计取舍执行视图与链接视图为什么要分成两套PT_LOAD和节区表描述的是同一份文件却是两套互不依赖的视图。这不是历史包袱是有意的设计执行视图要在加载时被最小代价地消费所以它按页对齐、按权限分组一个段里可能塞着十几节链接视图要支持符号查找、调试信息、节区级增量链接所以它按语义分节粒度细到每个.text.foo。两套视图分开的直接后果是节区表可以整段删掉程序照跑程序头表少一项程序立刻加载失败。这也解释了为什么加固工具优先破坏节区表——成本低收益高不影响程序运行。代价是解析器必须处理“节区表不存在”这条路径而且要在两条路径上给出一致的结果。验证方法有三条我一般会同时跑第一符号数量交叉校验。有节区表时用sh_size / sh_entsize没有时用DT_HASH或DT_GNU_HASH反推两个值必须相等。不相等说明其中一条路径读错了。第二重定位落地页校验。把所有RELATIVE重定位的r_offset加上r_addend检查结果是否落在某个可写PT_LOAD的范围内。落在只读段或者段外说明地址翻译或者段解析有问题。第三段区间覆盖校验。把所有PT_LOAD的[p_vaddr, p_vaddr p_memsz)按页对齐合并检查.dynsym、.dynstr、.rela.dyn的地址是否都被覆盖。任何一个不在覆盖范围内说明这个结构的地址是从错误的地方读来的。提示这三条校验不要只在开发时跑线上解析不可信的 so 时也应该跑。校验失败的样本直接进隔离队列比让它在业务逻辑里产生一个错误地址安全得多。取舍的另一面是性能。按页分组意味着同一个PT_LOAD里混着可执行代码和只读常量做节区级的内存保护比如把.rodata单独设成只读不可执行在运行时做不到只能退回到段级权限。这是用空间换简单段数量少、映射次数少、内核页表项少代价是权限控制的粒度变粗。我之前写过一个批量分析 so 的脚本图省事只处理了 64 位样本跑了几千个文件都没报错直到有人扔进来一个 32 位的库输出的重定位表条目数比实际多了三倍排查了一整天才发现是格式串没换。从那以后我每次动手写地址翻译函数都会先跑一遍「符号数双路交叉 重定位落地页 段区间覆盖」这三项检查确认两条视图给出一致结果再往下做分析。希望帮到你。本文还有配套的精品资源点击获取
技术解析与应用实践)
