IDA Pro动态调试教程需要配哪些环境 IDA Pro动态调试教程里断点通常下在哪里

光靠盯着反汇编和那些近似C语言的伪代码来看，很多分叉的执行路径其实还是很难吃准；所以大家就会关心IDA Pro的动态调试流程到底需要提前配好哪些环境，在实际操作里头断点一般又该下在什么地方比较管用，从自己拥有授权的测试小软件开始练手是一条比较稳当的路。在铺排环境的时候，不妨先把操作系统、处理器架构、程序要用的依赖库和输入文件都一一备齐，然后再顺着软件大致的执行路径，循序渐进地把中断位置加上去；这么做既能比较清楚地观察到程序是怎么跑起来的，也不容易被环境方面的小毛小病把思路搅乱。

一、IDA Pro动态调试需要配好哪些环境

IDA Pro本身既支持在本机上面直接调试，也支持通过网络去调试另一台机器上的程序；对于刚开始接触的人来说，可以先拿一份自己编译好的测试程序，在本机把一整套调试流程跑通，等熟悉了以后，再去碰那些远程设备或者跨系统的场景，Hex-Rays官方的教程也是把Windows本地的可执行文件当成入门例子的。

1、准备好匹配的目标程序

首先，手里要有一份跟调试环境对得上号的目标软件，这就得先确认它的文件格式、处理器架构以及将来会在哪个系统上运行，比如Windows底下最常见的就是exe和dll文件，Linux系统里头则多半是ELF格式。光是文件本身还不够，最好连运行它所需要的那些依赖库、配套的配置文件，还有用来检查结果是不是对的测试数据，都一块儿放到同一个地方；要是目标软件本身连打都打不开，那IDA在启动调试这一步也就跟着失败了，后面的步骤全都白费。

2、挑选合适的调试器

在用IDA把那份二进制文件加载进来以后，顺着菜单栏点开【Debugger】，选择【Select debugger】，从里头挑一个跟目标环境相配的调试器；接着再进到【Debugger】下的【Process options】里面，把Application里指向的文件路径、Input file、Directory以及运行时要带的参数都仔细核对一遍。如果Application这一栏填的路径根本就不对，那IDA就没办法正常地把程序拉起来，调试自然也就进行不下去。

3、备好隔离的测试环境

因为动态调试是要实实在在地把目标程序运行起来的，所以在练习或者排查故障的时候，比较推荐的做法是找一台专门用来测试的电脑，或者开一个虚拟机，并且提前准备好一份可以反复使用的输入数据，这样每次跑的环境都是干净的，结果也能复现。要是目标程序属于服务端那种类型，那还得提前确认好网络端口通不通、账号有没有足够的权限、工作目录存不存在，以及它依赖的那些服务是不是都正处在运行状态，免得调试到一半才发觉环境压根就没搭对，浪费时间。

4、远程调试时要补上服务端

如果被调试的程序是搁在另一台电脑上的，这就属于远程调试的范围了，得先在那台目标机器上把IDA的调试服务端程序给启动起来，然后再回到自己本机上，从【Debugger】→【Process options】里面填好远程主机的地址、连接用的密码，还有目标机器上真实存在的一份文件路径。官方文档里特别叮咛过，远程调试时填进去的路径，必须得是远程主机真正能访问到的位置才行，否则连目标进程都连不上。

二、断点通常下在哪些地方比较有效

断点不要一上来就铺得满程序都是，比较省事的办法是先围着程序入口、被怀疑的目标函数，还有异常情况可能出现的附近，零零星星地设上几个中断位置，再依据寄存器、调用栈和内存的变化，一点点地把需要关注的范围收窄。

1、先让程序在入口处暂停一回

头一次跑的时候，可以先在程序的入口点那里让它停一下，只管确认程序是不是已经正常地加载起来了；如果后面需要把整个执行经过完整地记下来，也可以在入口这里就把追踪功能给打开，Hex-Rays的文档里也给出了类似的思路，就是在进程的入口先暂停，然后再开始做执行追踪，这种做法很适合用来捕捉程序从启动到结束的大致路线。

2、在可疑函数的入口处放下断点

当静态分析已经大致圈定出某个可疑的函数以后，可以把光标移到这个函数的开头位置，按下【F2】在那里安上一个断点，然后再按【F9】让程序全速跑起来。等程序在这个位置停住了，先别急着一行行地单步跟到系统库里面去，而是该多看看传过来的参数、当前寄存器的值、调用栈的样子，还有附近那段伪代码的逻辑，从这些地方找到突破口往往效率更高。

3、把断点下在分支判断的前后两处

有时候看到运行结果跟自己预想的不太一样，就可以在条件跳转指令的前后、返回值判断的位置附近，还有错误处理的那条分支上，各自搁上一个断点；接着拿一份正常的输入数据跑一遍，再换上一份故意造出来的异常输入跑一遍，然后把两次走过的路径放在一块儿做个对比，这种比对的方式常常比逐条单步跟踪要快得多，也更容易揪出问题的分歧点到底在哪里。

4、数值莫名其妙被窜改时用数据断点

要是碰上某个变量或者某块内存里头的数值突然变了，却怎么也翻不出来是哪条指令做的手脚，那就可以对着那个内存地址设下一个硬件断点，或者设成页面断点；官方文档里头写得比较明白，页面断点能够监视住指定的一片内存范围，不管是读、写还是去执行，只要碰到这些行为就能触发中断，有助于把偷偷修改数据的代码给逮出来。

三、动态调试结果该怎么检查

当程序在断点处停下来以后，真正要紧的事情是把当下的运行现场给记清楚；只盯着眼下那一条指令，很多时候是解释不了问题到底是从哪里冒出来的。

1、先去查看调用栈

调用栈能够比较清楚地说明程序是从什么地方一路调用才进到当前函数里面的，如果发现了异常，就可以顺着调用关系往上翻个几层，通常情况下就能看到业务逻辑的入口，以及参数最初是从哪里传下来的，这样能省掉不少来回翻代码的功夫。

2、再去分析寄存器和内存

函数的参数、返回的结果、缓冲区里实际装着的那些内容，还有指针到底指向了哪个地方，这些信息都得配合着处理器的架构来一起判断；如果某个数值看着就是不对劲，可以在十六进制视图里把那块内存给打开来直接查看，根据看到的东西再决定要不要继续往下单步跟踪，不必急着一头钻进更深的细节里。

3、记得保存数据库和调试记录

分析做到一个阶段之后，一定要把IDA的数据库给保存下来，同时顺手记下目标文件的哈希值、这回测试用了什么输入数据、断点都下在了哪些具体位置上，以及遇到了哪些异常的现象。这样一来，下次要继续排查的时候，就可以把之前做过的命名、注释和分析结论直接捡起来接着用，不用再花很大功夫重新整理一遍，分析思路也不容易断掉。

总结

总的来讲，对于IDA Pro动态调试需要配好哪些环境，以及调试过程中断点通常该下在哪里，整个处理思路其实可以缩成三个主要步骤：第一步，先把一份能跑起来的测试程序和相配的调试器准备好；第二步，从程序入口、被怀疑的目标函数，还有各个分支判断的地方，由少到多地加上断点；第三步，结合着调用栈、寄存器以及内存的变化，去解释观察到的运行结果。如果用到远程调试，那还得额外把服务端、主机连接信息和远程路径这些条件给补齐。断点下得少而方向明确，中间排查的经过反而会变得更加清爽，不容易被一堆多余的中断信号带偏了思路。