SoFixer：ELF文件修复工具 逆向工程师的内存dump恢复方案

问题：内存dump的so文件为何无法使用？

在Android逆向分析与安全研究中，从内存中dump出的so文件往往呈现"损坏"状态——无法被动态加载器识别、函数调用失败、符号表丢失。这种现象源于内存映射与磁盘文件的本质差异：当so文件加载到内存后，操作系统会对其进行重定位、段加载优化和内存布局调整，导致dump文件缺失完整的ELF元数据。

典型症状包括：

• dlopen调用返回NULL并提示"invalid ELF header"
• IDA Pro加载时显示"corrupted section headers"
• 动态链接器报告"unable to resolve symbol"错误

方案：SoFixer的技术解决方案

SoFixer通过三大核心修复机制，重建ELF文件的完整性：

ELF结构三维重建技术

修复维度	技术要点	解决问题
节头表修复	基于内存页映射重建section headers	解决节区边界模糊问题
程序头表重建	根据PT_LOAD段属性恢复加载信息	修复内存布局错误
重定位表修复	符号地址重计算与偏移修正	解决函数调用失败

模块化架构设计

SoFixer采用分层设计确保修复精度：

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   ElfReader     │────▶│  ElfRebuilder   │────▶│   ObElfReader   │
│  (解析损坏ELF)  │     │  (执行修复逻辑)  │     │  (优化读取性能)  │
└─────────────────┘     └─────────────────┘     └─────────────────┘

实践：从dump到可用的完整工作流

🛠️ 操作场景：准备修复环境

# 克隆项目仓库
git clone https://gitcode.com/gh_mirrors/so/SoFixer
cd SoFixer

# 创建构建目录
mkdir build && cd build

# 构建64位修复工具
cmake -DSO_64=ON ..  # 32位系统移除-DSO_64=ON参数
make -j4  # 多线程编译

🛠️ 操作场景：获取内存dump文件

使用改进版IDA脚本精准dump：

import idaapi

# 定义dump范围（需从调试器获取实际地址）
start = 0x0000007DB078B000  // 内存起始地址
end = 0x0000007DB08DE000    // 内存结束地址
output = "dump.so"          // 输出路径

# 分段读取内存（避免单次读取过大）
chunk_size = 0x100000       // 64KB块大小
with open(output, 'wb') as f:
    offset = 0
    while offset < (end - start):
        # 计算当前块大小（处理最后一块）
        size = min(chunk_size, end - start - offset)
        # 读取内存数据
        data = idaapi.dbg_read_memory(start + offset, size)
        f.write(data)
        offset += size

🛠️ 操作场景：执行修复命令

基础修复命令：

# 基础修复模式
./SoFixer64 -s dump.so -o fixed.so -m 0x7DB078B000 -d

高级修复命令（使用原始so文件作为参考）：

# 增强修复模式（实验性功能）
./SoFixer64 -s dump.so -o fixed.so -m 0x7DB078B000 -b original.so -d

参数说明对比表：

参数	必选	作用	示例
-s	是	指定待修复文件路径	-s ./dump.so
-o	是	指定输出文件路径	-o ./fixed.so
-m	是	内存基地址（16进制）	-m 0x7DB078B000
-b	否	原始so文件路径	-b ./original.so
-d	否	启用调试输出	-d

原理：ELF修复的技术内幕

ELF结构修复流程

SoFixer的修复过程分为四个阶段：

1. 诊断阶段：分析dump文件的ELF头完整性，识别缺失的关键结构
2. 重建阶段：
   • 恢复程序头表(phdr)：根据内存页属性重建PT_LOAD段
   • 修复节头表(shdr)：重新计算节区偏移与大小
   • 重建符号表：从字符串表中恢复符号名称与地址
3. 重定位阶段：
   • 修正重定位入口(Rel/Rela)
   • 调整符号值与偏移量
4. 验证阶段：检查ELF结构有效性，确保符合加载规范

重定位表重建算法

重定位修复是SoFixer的核心技术，其算法流程如下：

输入：损坏的重定位表、内存基地址
输出：修复后的重定位表

1. 遍历所有重定位项
2. 对每个项执行：
   a. 计算原始文件偏移 = 内存地址 - 基地址
   b. 查找符号表对应条目
   c. 重新计算重定位类型与偏移
   d. 更新重定位表项
3. 重建重定位节区大小与偏移

常见错误诊断矩阵

问题现象	可能原因	解决方案
修复后文件无法加载	基地址错误	使用readelf -l检查加载地址，确保与-m参数一致
符号解析失败	重定位表未修复	添加-d参数查看重定位过程，确认原始so文件路径
节头表损坏提示	内存dump不完整	重新dump时增加结束地址冗余量（建议+0x1000）
构建失败	编译器版本过低	升级GCC至5.4以上，确保支持C++11特性
修复速度慢	文件过大	使用-b参数提供原始so文件加速修复

修复效果验证工具链

推荐使用以下工具验证修复结果：

1. ELF结构检查：

   readelf -h fixed.so  # 检查ELF头完整性
   readelf -l fixed.so  # 验证程序头表
   readelf -S fixed.so  # 检查节头表
   

2. 动态加载测试：

   # 简单加载测试
   python -c "from ctypes import CDLL; CDLL('./fixed.so')"
   
   # 详细加载日志
   LD_DEBUG=all java -Djava.library.path=. TestClass
   

3. 反汇编验证：

   objdump -d fixed.so | grep -A 20 "函数名"
   

高级用户自定义修复规则

SoFixer支持通过配置文件自定义修复策略，创建fixer_config.json：

{
  "section_fix": {
    "force_rebuild": ["plt", ".text"],  // 强制重建的节区
    "ignore_missing": [".comment"]      // 忽略缺失的节区
  },
  "relocation": {
    "skip_types": [16]                  // 跳过特定类型的重定位
  },
  "symbol": {
    "force_resolve": ["JNI_OnLoad"]     // 强制解析的符号
  }
}

使用自定义配置：

./SoFixer64 -s dump.so -o fixed.so -m 0x7DB078B000 -c fixer_config.json

总结

SoFixer通过系统化的ELF结构重建技术，解决了内存dump so文件的可用性问题。其核心价值在于：

• 自动化修复流程降低逆向分析门槛
• 模块化设计确保修复质量与性能
• 灵活的配置选项满足高级用户需求

对于逆向工程师和安全研究员，掌握SoFixer不仅意味着获得一个实用工具，更能深入理解ELF文件格式与内存加载机制。建议结合readelf、objdump等工具形成完整的ELF分析工作流，提升so文件修复的成功率。

记住：准确的内存基地址和完整的dump文件是修复成功的两大关键因素，在操作过程中应特别注意这两项参数的正确性。