解析.so文件：基于调试符号还原未妥善版本化的源码

一、深挖编译环境与参数信息 #

• 除了DW_AT_producer，用readelf --debug-dump=info path/to/file还能提取更多关键信息：
  • 查找DW_AT_comp_dir获取编译时的工作目录，DW_AT_file查看关联的源码文件路径；
  • 搜索DW_MACINFO_开头的条目，能找到编译时定义的宏参数。
• 执行objdump -s --section=.comment path/to/file，查看编译器版本和编译过程中留下的注释信息，很多编译参数会被记录在这里。
• 如果是GCC编译的，直接用readelf -p .GCC.command.line path/to/file，这个段会直接保存完整的编译命令行，包括所有宏定义、优化选项、链接参数等，是还原编译环境的核心依据。

二、GDB进阶分析操作 #

• 执行(gdb) info variables，查看全局变量、静态变量的定义与值，和原版源码对比，快速定位新增或修改的变量（这往往对应源码的改动）。
• 对可疑函数执行(gdb) disassemble <function>，查看汇编代码，和原版编译生成的汇编对比——哪怕源码只有微小改动，汇编层面也会体现差异；如果是编译选项不同，也能从汇编的优化程度看出来。
• 设置断点跟踪执行流程：
  • 用(gdb) break <function>给目标函数设断点，程序触发断点后，用(gdb) step单步进入函数内部，(gdb) next单步跳过调用，结合(gdb) print <variable>查看变量值，对比原版代码的执行逻辑差异。
• 确认符号加载状态：用(gdb) show debug-file-directory检查GDB是否正确加载了目标.so的调试符号，避免分析错误的文件。

三、二进制差异精准定位 #

• 用diffoscope original_stripped.so modified_stripped.so对比strip后的两个文件，它会深入分析二进制内容、段结构、符号表等，精准定位那唯一一行差异的具体位置（比如对应哪个函数的汇编，或是哪个数据段的变化）。
• 导出汇编代码对比：

  objdump -d original.so > original.asm
  objdump -d modified.so > modified.asm
  diff original.asm modified.asm
  

  直接对比汇编代码，快速找到差异函数。
• 对比动态符号表：用nm -D original.so和nm -D modified.so，查看是否有新增、删除或修改的导出函数/变量。

四、其他辅助工具 #

• 用addr2line -e modified.so <差异地址>，把二进制差异的地址转换成源码行号（如果调试符号完整），直接定位到修改的源码位置。
• 执行readelf -S modified.so查看.so的段结构，对比原版的段大小、权限、属性（比如是否开启PIE、栈保护等），确认编译选项的差异。
• 提取字符串对比：strings modified.so | grep -v "^$"，导出.so中的所有字符串，和原版的字符串对比，新增的日志、错误提示等往往是源码修改的直接痕迹。

内容的提问来源于stack exchange，提问作者Marco Montevechi Filho