行业解决方案
查看所有行业解决方案
IDA 用于解决软件行业的关键问题。
IDA Pro导出C代码后可读性很差怎么办,以及导出C代码时怎样减少结构混乱,不少人第一次接触反编译结果的时候,都难免会觉得有些失望。导出来的内容,看上去确实有点像C语言,可是又跟真正的源码不是一回事,变量名满篇都是v1、v2、a1这一类,结构体也没有恢复出来,if、while、goto全部搅和在一起,读起来相当费劲。其实这种现象非常正常,IDA的反编译结果,更接近于“拿给人看的伪C代码”,它既不是原来项目里的那份源码,也不应当被直接当成可以维护的代码来用。反编译工具能够帮助分析人员去理解程序的逻辑,但是原始的变量名、注释,还有业务结构这一些信息,在编译之后绝大多数都已经丢掉了,只能依靠后期的整理,一点一点地补回来。
IDA Pro反编译hex文件前需要准备什么,以及反编译hex文件时内存布局又该怎样核对,重点之处并不在于直接把hex文件拖进IDA然后按下F5,而在于先要判断清楚它到底是一份什么类型的镜像。hex文件常见于MCU固件、Bootloader、片上Flash数据或者烧录文件,它里面可能只包含代码段,也可能混杂着中断向量、校验区、配置字,还有多个不同的地址段。IDA本身能够处理原始二进制文件,也可以手动去布置段信息,Hex-Rays也专门说明过,在分析固件这一类原始文件的时候,正确的内存布局是极其重要的。
IDA Pro的F5伪代码里,变量名之所以非常混乱,以及在这伪代码当中,类型的信息又该用什么方法去补充,这当中的主要原因,在于反编译器所面对的,是编译之后的二进制结果,而并不是最初的源代码。程序在编译之后,很多变量名、结构体的名称、注释,还有局部的语义信息,都已经丢失了,再加上优化编译还会把寄存器反复使用、把多个变量合并到一处、把表达式拆开,所以F5生成的伪代码里面,就经常会见到v1、v2、a1、result这一类的临时命名。Hex-Rays的资料里也提到过,反编译视图当中的变量名和类型,是可以进行交互式修改的,IDA基础使用文档里也说明了,变量可以通过Rename操作去重新命名。
只有安装包、固件或者可执行文件,手里却没有任何源代码的时候,想要把程序内部的逻辑排查清楚,往往会变得特别费劲;而很多人会问IDA软件到底是做什么用的,以及IDA更适合去处理哪一类二进制文件,通常都得从二进制分析的场景里慢慢理解。简单来说,IDA能够把机器指令翻译成汇编代码,再配合函数识别、交叉引用、字符串、导入函数和控制流图这些信息,帮使用者把原本很难读的程序一点点拆开来看;其中IDA Pro这一款还提供了反编译和动态调试的本事,比较适合用来做软件分析、兼容性问题排查、固件研究还有程序故障的定位。
光靠盯着反汇编和那些近似C语言的伪代码来看,很多分叉的执行路径其实还是很难吃准;所以大家就会关心IDA Pro的动态调试流程到底需要提前配好哪些环境,在实际操作里头断点一般又该下在什么地方比较管用,从自己拥有授权的测试小软件开始练手是一条比较稳当的路。在铺排环境的时候,不妨先把操作系统、处理器架构、程序要用的依赖库和输入文件都一一备齐,然后再顺着软件大致的执行路径,循序渐进地把中断位置加上去;这么做既能比较清楚地观察到程序是怎么跑起来的,也不容易被环境方面的小毛小病把思路搅乱。
用IDA做exe静态分析,很多人最容易卡住的,不是菜单不会点,而是上来就急着看伪代码,结果文件入口、函数分布、导入表和字符串线索都还没先理清。Hex-Rays官方的基础文档其实把顺序写得很清楚,先把文件装进数据库并完成自动分析,再围绕反汇编窗口、函数窗口、导入导出视图和字符串窗口建立整体判断,最后再往局部逻辑深入。这样做的好处,是先把全局轮廓看明白,再决定哪里值得细看,效率会高很多。
很多人把DLL丢进IDA Pro以后,第一反应就是直接点开函数看伪代码,结果越看越散。更稳的顺序通常不是先扎进某个函数,而是先把DLL的几个基础面摸清楚:入口点在哪、导出表里暴露了什么、导入了哪些API、这些导出函数之间有没有明显的分发关系。Hex-Rays官方界面文档已经把Exports、Imports、Functions、Names、Strings这些视图单独列出来,而新版发行说明还提到,IDA会在exports和entry points列表里区分主入口点。这说明DLL分析本来就不该只盯伪代码窗口,而是要先从PE结构相关视图切进去。
刚开始用IDA做静态逆向,最容易走偏的地方,不是不会点菜单,而是一上来就想把整份样本一次看懂。Hex-Rays官方入门文档给出的顺序其实很清楚,先加载文件,等自动分析完成,再从函数、字符串、导入表和交叉引用这些基础线索往里走。这样做的好处是,先把程序骨架搭出来,再决定主逻辑从哪里切进去,不会一开始就被大段指令压住。
在IDA里看异常处理,最容易走偏的地方,是把它当成普通数据段去扫。实际上,Windows下最常见、也最适合在IDA里系统追踪的,是x64这一类表驱动异常处理:异常目录先指向.pdata,.pdata里是按函数地址排序的函数表项,再由每一项跳到.xdata里的展开信息。顺序理清以后,后面看处理函数、追语言级处理逻辑,都会顺很多。
这类问题通常出现在两种场景,一种是你在做自有软件的兼容性排障或安全自查,手里拿到的文件经过了加固或封装处理,导致分析链路不顺;另一种是你在分析异常样本或崩溃现场文件,文件结构不完整或内存映射不一致,导入后就报段错误。下面我会避开任何可能用于绕过软件保护的具体操作细节,给你一套更安全也更工程化的替代流程,重点解决如何让分析可复现,以及导入报段错误时如何定位根因并恢复到可分析状态。