售前问题

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反编译so文件的时候，入口应该怎么去找，以及so文件在反编译完成以后，交叉引用又该怎样去看，先要弄清楚一件事情：so文件它并不是普通的exe，通常也没有一个像程序主函数那样清清楚楚的入口。so是共享库，里面很多的函数，都要等到宿主程序把它加载起来以后，才会被调用。IDA能够对so进行反汇编和反编译，但是在分析的时候，不能只盯着ELF Header里面的那个入口地址，更要去关注导出函数、初始化函数、JNI注册逻辑，还有交叉引用这一些关系。

IDA Pro arm64分析时重点看哪些寄存器IDA Pro arm64调用约定通常该怎样判断，重点并不是把所有寄存器全部背下来，而是先抓住“参数从哪里来、返回值放在哪里、函数怎样保存现场、栈上是否存在额外参数”。arm64反汇编中寄存器数量很多，但真正影响函数理解的，通常集中在参数寄存器、返回寄存器、栈指针、链接寄存器和少量被调用者保存寄存器上。

IDA Pro调试so文件的时候，会让人觉得很难附加，还有一旦so文件的符号缺了，该用什么办法去把信息补上，这是在做原生库分析时很容易碰到的问题。so文件一般不是自己独立去跑的程序，它得由某一个App、一个可执行文件或者一个进程动态地加载进来，所以在调试的时候，不能只把so文件往IDA里一拖，就等着它马上能停在断点上。IDA这个工具本身是支持调试的，也支持远程调试，对于Android原生库的调试也覆盖了ARM32、AArch64、x86和x64这些架构，但是到底能不能稳定地附加上去，还要看进程正处在什么状态、权限够不够、架构是不是匹配，以及符号信息是不是完整。

IDA Pro调试DLL为什么经常进不去，以及DLL的加载时机通常要怎么确认，是不少人在调试插件、组件库或业务模块时会碰到的情形。DLL本身一般不是独立运行的程序，它需要被某个宿主进程加载之后才会去执行代码。IDA的调试器既可以启动新的进程，也能够附加到已经跑起来的进程上，官方的Win32本地调试说明里面也明确提到，IDA Debugger支持Run和Attach这两种方式。所以，调试DLL的时候，关键之处并不是只把dll文件打开，而是要找到正确的宿主进程和正确的加载时机。