IDA Pro导出c代码后可读性很差怎么办 IDA Pro导出c代码时怎样减少结构混乱

IDA Pro导出C代码后可读性很差怎么办，以及导出C代码时怎样减少结构混乱，不少人第一次接触反编译结果的时候，都难免会觉得有些失望。导出来的内容，看上去确实有点像C语言，可是又跟真正的源码不是一回事，变量名满篇都是v1、v2、a1这一类，结构体也没有恢复出来，if、while、goto全部搅和在一起，读起来相当费劲。其实这种现象非常正常，IDA的反编译结果，更接近于“拿给人看的伪C代码”，它既不是原来项目里的那份源码，也不应当被直接当成可以维护的代码来用。反编译工具能够帮助分析人员去理解程序的逻辑，但是原始的变量名、注释，还有业务结构这一些信息，在编译之后绝大多数都已经丢掉了，只能依靠后期的整理，一点一点地补回来。

一、IDA Pro导出c代码后可读性很差怎么办

IDA Pro导出的C代码可读性差的时候，先不用急着把它们全部复制出来，然后拿到外面去修改。更加理想的做法，是在IDA里面先对关键的函数做一轮整理，整理完之后再去导出。否则，导出去的不过是数量庞大的临时变量，还有残缺不全的类型信息，这些东西放到文档里面，后面照样非常难读。

1、先把函数名和变量名改掉

最能影响阅读体验的，往往还不是语句本身，而是那些命名。像sub_401000、v7、a2这一类的名字，盯着看十分钟就容易把人看乱。可以先从导出函数、字符串的引用，还有关键的API调用这些地方入手，把那些明显能够判断出作用的函数，重新命一个名字，比如read_config、check_license、send_packet这样。变量也不需要一次就全部改完，可以先改参数、返回值、循环计数，还有状态标志这些比较关键的对象。

2、把类型信息补充完整

很多结构上的混乱，其实都是因为类型没有恢复好。指针被当成整数来看，结构体的字段没有被识别出来，数组和缓冲区的边界也不清楚，这样一来，伪代码自然就会非常难看。可以到【Local Types】里面去把结构体补上，再回到伪代码窗口当中，给变量重新指定类型。

类型一旦正确了，很多强制转换、偏移访问，还有那些看上去很奇怪的表达式，就都会变得顺一些。IDA的伪代码视图本身，也支持对变量、函数类型等做出交互式的调整，在调整之后，伪代码是会跟着发生改变的。

3、不要一口气导出所有的函数

全量导出在大多数情况下并没有什么用处，尤其是面对那种大型的DLL或者EXE文件。更值得推荐的方式，是依照分析的目标去导出，比如只导出初始化的函数、核心的校验函数、网络处理的函数，或者某一个跟崩溃相关的函数。那些暂时没有关联的函数，可以先留在IDA的工程里面，等到需要的时候再回过头来看。这样整理出来的材料会小很多，也不容易把阅读的人，淹没在一堆毫无意义的代码当中。

二、IDA Pro导出c代码时怎样减少结构混乱

结构上的混乱，并不一定全都是反编译失败的缘故，有些时候，是因为原来的程序本身就经过了优化、内联、宏展开、异常处理，或者是编译器的重排，等到这些步骤做完以后，控制流早就已经不像源码阶段那么清晰了。到了这个时候，不要硬着头皮把它整理成“漂亮的源码”，重点应当放在恢复逻辑的层次上面。

1、先看伪代码，再回到汇编里面去确认

Hex-Rays生成的伪代码，比较适合拿来快速阅读逻辑，但是在碰到关键位置的时候，最好还是再回到汇编视图，或者图形视图里面去核对一下。比如条件跳转、switch语句、函数指针、内存拷贝、异常分支这些地方，伪代码读起来可能就像普通的if，但实际上底层的逻辑要更加复杂。如果只看导出去的C代码，是很容易把某些边界的判断给漏掉的。

2、把大函数拆分成几个逻辑块

碰到那种几百行的大函数，不要急着从头一行一行读到尾。可以先按照字符串、API调用、分支出口、错误返回码这几样东西，把它大致切成几块：初始化的部分、参数检查的部分、核心处理的部分、异常返回的部分，还有资源释放的部分。等到导出整理的时候，也可以拿小标题或者注释，给它标一标，不必非要生硬地把它重写成真正的源码。

3、减少没有意义的表达式

有一些反编译出来的代码里面，会出现大量临时变量的赋值、重复的强制转换，还有各种偏移表达式。能够确认清楚含义的，可以在IDA里面先把类型和命名改掉，让伪代码自然地变得干净一些。那些暂时还确认不了的，就不要随手把它改成表面上看起来更顺眼的写法，因为一旦改错了，后面推导出来的分析结论，也就跟着一块儿偏掉了。

三、导出后结果怎么整理更容易复查

导出的结果，最好不要只是一堆代码往那里一贴就算完事了。如果是拿给团队里面其他人看的，又或者自己后面还打算继续往深里分析，那么建议把代码、注释，还有判断的依据，分别放到不同的位置。代码本身，只是一份材料，真正有价值的东西，是你对它的那部分理解。

1、把分析的目标保留下来

在开头的地方，写清楚这一次分析的到底是哪一个文件、哪一个版本，又涉及到了哪一个函数的范围。比如写上“本次只分析与授权校验相关的函数”，不要让别人误以为这就是一份完整的源码还原。

2、在关键的位置上加上简短的注释

注释不必写得密密麻麻。重点要写清楚的是参数的含义、返回值的判断、关键的分支、外部的调用，还有那些暂时没有确认下来的地方。比如“这里疑似是去读取配置项”“这个分支可能是失败返回”，这样的写法，比大段的解释要更有用处。

3、把不确定的结论保留下来

在反编译分析当中，很多东西无法马上确定，这是非常正常的。凡是还没有经过动态调试验证的地方，就不要把结论写得太死。可以把它标注成“疑似”，或者“需要结合运行时的情况再做确认”。这样报告看起来，可能语气没有那么绝对，但是反而会显得更加可信。

总结

IDA Pro导出C代码后可读性很差怎么办，以及IDA Pro导出C代码时怎样减少结构混乱，这两件事情的重点，并不是要把反编译得到的结果，硬生生地改成一版漂亮的源码，而是先在IDA里面，把命名、类型，还有关键的函数，都整理过一遍，然后再有选择性地导出。可读性变差的时候，先去修改函数名和变量名，接着补全结构体和类型；结构混乱的时候，要先按照逻辑块把它拆开，不要盲目地去美化。导出之后的内容，最好是配合着分析目标、关键注释，还有那些没有确定下来的地方，放在一起整理，这样一来，反编译的结果才会更像一份能够继续复查下去的分析材料，而不是一堆极其难读的伪C代码。