![[pwnre]利用Flair签名库自动化识别静态编译二进制文件中的库函数](images/news1.jpg)
1. 静态编译与符号剥离的困境当你拿到一个静态编译且去除了符号的二进制文件时第一眼看到的就是满屏的sub_xxxx和loc_xxxx。这种场景在CTF逆向题和真实世界的恶意软件分析中都很常见。我最近分析一个物联网设备固件时就遇到了一个完全静态编译的ARM架构二进制文件里面调用了200多个标准库函数但全都变成了没有名字的地址。静态编译之所以让分析变得困难是因为它把程序依赖的所有库函数都打包进了最终的可执行文件。正常情况下动态链接的二进制文件会保留对共享库的引用IDA可以轻松识别出这些外部函数。但静态编译后这些函数边界消失了再加上开发者刻意去除调试符号整个二进制文件就变成了一个黑箱。更棘手的是不同版本的库函数实现可能有细微差别。我曾经遇到过一个案例同一个memcpy函数在glibc 2.27和2.31中的汇编实现就有所不同。这导致基于错误版本生成的签名文件完全无法匹配。2. Flair签名技术原理剖析2.1 函数指纹生成机制Flair的核心在于它创造性地使用了函数指纹技术。这个技术不是简单比较汇编代码而是提取函数的多个特征组合成签名。具体来说它会分析函数的基本块(Basic Block)控制流结构特定指令序列的模式如函数序言和结语对特殊寄存器的使用习惯字符串常量的引用情况举个例子一个典型的libc函数如strlen在不同编译环境下可能产生不同的机器码但其核心特征保持不变它会有循环结构、会读取ESI/RDI寄存器的内容、会使用SCASB指令等。Flair就是捕捉这些不变特征来生成签名。2.2 签名数据库的构建流程制作.sig文件的过程实际上是对目标库进行反汇编和特征提取。IDA自带的pelf工具针对ELF文件会执行以下步骤解析库文件的符号表和重定位信息对每个函数进行反汇编提取上述特征并生成中间.pat文件使用sigmake工具将.pat转换为最终的.sig签名文件在实际操作中我建议使用如下命令生成更精确的签名./pelf -v -d8 libc.a libc.pat这里的-v参数启用详细输出-d8指定反汇编深度可以帮助发现更多函数特征。3. 实战签名应用全流程3.1 准备工作与环境配置首先需要准备签名文件集合。除了常见的sig-database外我推荐收集以下资源Ubuntu各版本官方libc静态库对应的签名Android NDK不同版本的签名常见嵌入式系统库如uClibc、dietlibc的签名将这些签名文件整理到IDA的sig目录后我习惯按如下结构组织sig/ ├── x86/ │ ├── glibc/ │ │ ├── 2.23.sig │ │ └── 2.27.sig ├── arm/ │ └── android/ │ ├── api19.sig │ └── api26.sig3.2 多版本签名智能匹配技巧在IDA中加载签名时有个实用技巧很多人不知道签名文件的加载顺序会影响匹配结果。我的经验是先加载范围更广的通用签名如通用的glibc签名然后加载特定版本签名如ubuntu18.04的签名最后尝试加载自定义生成的签名如果发现匹配结果不理想可以尝试右键点击签名窗口选择Rescan Program这会让IDA重新评估所有可能的匹配。4. 高级技巧与疑难解决4.1 签名冲突的手动处理当sigmake生成.exc文件时说明遇到了函数签名冲突。这种情况下我通常的处理流程是首先检查冲突函数是否属于同一功能类别优先保留更常用或更完整的函数实现对于不确定的函数使用-标记暂时排除一个实际案例在处理musl libc时多个字符串处理函数产生了冲突。通过检查.exc文件发现这些函数都有相似的汇编结构但处理逻辑不同。最终我选择保留strcpy而非strncpy因为前者在二进制中出现频率更高。4.2 自动化检测脚本的深度使用lscan.py脚本虽然方便但有几个增强使用技巧使用多线程加速扫描python lscan.py -S sig_database/ -f target_binary -t 8生成详细匹配报告python lscan.py -S sig_database/ -f target_binary -o report.html自定义匹配阈值默认0.8可能过高python lscan.py -S sig_database/ -f target_binary --threshold 0.6在我的测试中适当降低阈值到0.6-0.7区间可以显著提高老旧库文件的识别率。5. 真实案例分析去年分析某路由器固件时遇到一个静态编译的MIPS二进制文件。使用标准方法无法识别任何库函数。经过以下步骤最终解决了问题从固件中提取出libuClibc-1.0.12.a库文件使用mips版flair工具生成自定义签名发现签名冲突多达47处通过交叉引用确定关键函数最终成功识别出85%的标准库函数这个案例说明对于非x86架构准备正确的构建工具链和库文件至关重要。我后来建立了一个自动化脚本可以自动从固件文件系统中提取可能的库文件并尝试生成签名。6. 性能优化与最佳实践经过多次实践我总结出以下优化建议对大型二进制文件先使用lscan缩小库版本范围优先尝试目标系统发行版对应的库版本在IDA中使用Apply signature而非全局加载节省内存定期整理sig目录移除重复或低质量签名对关键函数可以手动创建函数原型辅助分析一个典型的优化案例分析500MB大小的游戏引擎二进制时通过预筛选只加载了3个最可能的签名文件将分析时间从2小时缩短到15分钟。
[pwnre]利用Flair签名库自动化识别静态编译二进制文件中的库函数
1. 静态编译与符号剥离的困境当你拿到一个静态编译且去除了符号的二进制文件时第一眼看到的就是满屏的sub_xxxx和loc_xxxx。这种场景在CTF逆向题和真实世界的恶意软件分析中都很常见。我最近分析一个物联网设备固件时就遇到了一个完全静态编译的ARM架构二进制文件里面调用了200多个标准库函数但全都变成了没有名字的地址。静态编译之所以让分析变得困难是因为它把程序依赖的所有库函数都打包进了最终的可执行文件。正常情况下动态链接的二进制文件会保留对共享库的引用IDA可以轻松识别出这些外部函数。但静态编译后这些函数边界消失了再加上开发者刻意去除调试符号整个二进制文件就变成了一个黑箱。更棘手的是不同版本的库函数实现可能有细微差别。我曾经遇到过一个案例同一个memcpy函数在glibc 2.27和2.31中的汇编实现就有所不同。这导致基于错误版本生成的签名文件完全无法匹配。2. Flair签名技术原理剖析2.1 函数指纹生成机制Flair的核心在于它创造性地使用了函数指纹技术。这个技术不是简单比较汇编代码而是提取函数的多个特征组合成签名。具体来说它会分析函数的基本块(Basic Block)控制流结构特定指令序列的模式如函数序言和结语对特殊寄存器的使用习惯字符串常量的引用情况举个例子一个典型的libc函数如strlen在不同编译环境下可能产生不同的机器码但其核心特征保持不变它会有循环结构、会读取ESI/RDI寄存器的内容、会使用SCASB指令等。Flair就是捕捉这些不变特征来生成签名。2.2 签名数据库的构建流程制作.sig文件的过程实际上是对目标库进行反汇编和特征提取。IDA自带的pelf工具针对ELF文件会执行以下步骤解析库文件的符号表和重定位信息对每个函数进行反汇编提取上述特征并生成中间.pat文件使用sigmake工具将.pat转换为最终的.sig签名文件在实际操作中我建议使用如下命令生成更精确的签名./pelf -v -d8 libc.a libc.pat这里的-v参数启用详细输出-d8指定反汇编深度可以帮助发现更多函数特征。3. 实战签名应用全流程3.1 准备工作与环境配置首先需要准备签名文件集合。除了常见的sig-database外我推荐收集以下资源Ubuntu各版本官方libc静态库对应的签名Android NDK不同版本的签名常见嵌入式系统库如uClibc、dietlibc的签名将这些签名文件整理到IDA的sig目录后我习惯按如下结构组织sig/ ├── x86/ │ ├── glibc/ │ │ ├── 2.23.sig │ │ └── 2.27.sig ├── arm/ │ └── android/ │ ├── api19.sig │ └── api26.sig3.2 多版本签名智能匹配技巧在IDA中加载签名时有个实用技巧很多人不知道签名文件的加载顺序会影响匹配结果。我的经验是先加载范围更广的通用签名如通用的glibc签名然后加载特定版本签名如ubuntu18.04的签名最后尝试加载自定义生成的签名如果发现匹配结果不理想可以尝试右键点击签名窗口选择Rescan Program这会让IDA重新评估所有可能的匹配。4. 高级技巧与疑难解决4.1 签名冲突的手动处理当sigmake生成.exc文件时说明遇到了函数签名冲突。这种情况下我通常的处理流程是首先检查冲突函数是否属于同一功能类别优先保留更常用或更完整的函数实现对于不确定的函数使用-标记暂时排除一个实际案例在处理musl libc时多个字符串处理函数产生了冲突。通过检查.exc文件发现这些函数都有相似的汇编结构但处理逻辑不同。最终我选择保留strcpy而非strncpy因为前者在二进制中出现频率更高。4.2 自动化检测脚本的深度使用lscan.py脚本虽然方便但有几个增强使用技巧使用多线程加速扫描python lscan.py -S sig_database/ -f target_binary -t 8生成详细匹配报告python lscan.py -S sig_database/ -f target_binary -o report.html自定义匹配阈值默认0.8可能过高python lscan.py -S sig_database/ -f target_binary --threshold 0.6在我的测试中适当降低阈值到0.6-0.7区间可以显著提高老旧库文件的识别率。5. 真实案例分析去年分析某路由器固件时遇到一个静态编译的MIPS二进制文件。使用标准方法无法识别任何库函数。经过以下步骤最终解决了问题从固件中提取出libuClibc-1.0.12.a库文件使用mips版flair工具生成自定义签名发现签名冲突多达47处通过交叉引用确定关键函数最终成功识别出85%的标准库函数这个案例说明对于非x86架构准备正确的构建工具链和库文件至关重要。我后来建立了一个自动化脚本可以自动从固件文件系统中提取可能的库文件并尝试生成签名。6. 性能优化与最佳实践经过多次实践我总结出以下优化建议对大型二进制文件先使用lscan缩小库版本范围优先尝试目标系统发行版对应的库版本在IDA中使用Apply signature而非全局加载节省内存定期整理sig目录移除重复或低质量签名对关键函数可以手动创建函数原型辅助分析一个典型的优化案例分析500MB大小的游戏引擎二进制时通过预筛选只加载了3个最可能的签名文件将分析时间从2小时缩短到15分钟。
