IDA异常处理表怎么看 IDA异常处理流程怎么追踪

在IDA里看异常处理，最容易走偏的地方，是把它当成普通数据段去扫。实际上，Windows下最常见、也最适合在IDA里系统追踪的，是x64这一类表驱动异常处理：异常目录先指向.pdata，.pdata里是按函数地址排序的函数表项，再由每一项跳到.xdata里的展开信息。顺序理清以后，后面看处理函数、追语言级处理逻辑，都会顺很多。

一、IDA异常处理表怎么看

先别一上来就在反汇编正文里找异常处理函数，更稳的入口是先开子视图。Hex-Rays官方把【Segments】、【Hex View】、【Imports】、【Exports】这些窗口都列成了标准子视图，其中【Segments】和【Hex View】最适合拿来定位异常目录、.pdata和.xdata的实际位置。

1、先确认样本是不是表驱动异常处理

对PE映像来说，可选头的数据目录里本来就有Exception Table项，PE规范还明确写到它指向.pdata。也就是说，先看异常目录有没有地址和大小，再去对应段里落位，比直接全文搜索更稳。

2、在.pdata里先看函数表项三元组

微软对x64的定义很直接，RUNTIME_FUNCTION一项就是函数起始地址、函数结束地址、展开信息地址这三个字段，而且这些地址都是相对映像基址的32位偏移，表项还要求按函数地址排序。你在IDA里看到这种连续三元组时，基本就已经摸到异常处理表主线了。

3、再从UnwindData跳到.xdata看UNWIND_INFO

UNWIND_INFO里最先要看的不是细节代码，而是版本、标志位、前导长度、展开码数量和帧寄存器信息。因为这些字段决定了这是不是普通展开信息，还是已经带异常处理器、终止处理器，或者链式展开信息。

4、标志位决定后面怎么追

如果看到UNW_FLAG_EHANDLER或UNW_FLAG_UHANDLER，说明这条记录后面会跟处理函数地址以及语言相关的处理数据；如果看到UNW_FLAG_CHAININFO，就说明这不是主记录，而是要继续顺着链到上一级UNWIND_INFO去找真正的主入口。这个判断要先做，不然很容易跳错目标。

5、原始字节看不顺时就把结构补起来

如果IDA没把.pdata或.xdata解释得很舒服，不要硬看裸字节。Hex-Rays官方说明里，Local Types现在就是类型管理中心，可以在里面补结构体、改结构体，再把这些类型应用回当前数据库。用它把RUNTIME_FUNCTION和UNWIND_INFO手工立起来，后面读表会轻松很多。

二、IDA异常处理流程怎么追踪

异常处理流程不是从处理函数名开始追，而是从当前函数有没有函数表项开始追。微软给出的x64展开过程本身就是一条很好用的逆向路径，按这条路径在IDA里倒着走，通常不会乱。

1、先从目标函数回查它对应的RUNTIME_FUNCTION

如果你现在正盯着某个可疑函数，先去.pdata里找BeginAddress和EndAddress能覆盖它代码范围的那一项。微软文档说明，异常分发时第一步就是按当前RIP去搜索描述当前函数的RUNTIME_FUNCTION表项，所以逆向时从函数范围反查表项，本身就是顺着系统逻辑在走。

2、从表项跳到UNWIND_INFO以后先分三种情况

微软把后续路径分得很清楚：当前地址如果落在epilog，系统会继续模拟收尾；如果落在prolog，就按展开码回退前导效果；如果既不在前导也不在收尾，且标志位表明有异常处理器，那么才会真正调用语言相关处理器。这个分法在IDA里特别有用，因为它能帮你先判断当前代码块到底是不是异常处理真正介入的区域。

3、遇到EHANDLER或UHANDLER时再追处理函数本体

当UNWIND_INFO标志位表明有处理器后，再去取后面的处理函数相对地址和处理数据。微软文档同时强调，语言相关处理数据的格式并没有统一规范，它完全由具体处理器决定，所以你追到这里后，重点要转到处理函数本体以及它消费这些数据的方式，而不是指望所有样本都能套同一模板。

4、链式展开一定要追到主记录为止

如果你只停在带UNW_FLAG_CHAININFO的次级记录上，后面很容易把函数边界和真正入口看偏。微软明确说明，链式展开会一路连到一个已经清掉链标志的主UNWIND_INFO，那一项才真正指向过程入口，所以链一旦出现，就不要半路停。

5、交叉引用窗口用来收口

追到处理函数地址以后，可以直接开IDA的Cross references窗口看当前位置的引用关系。Hex-Rays官方说明，这个窗口会列出所有指向当前位置的引用，并允许你围绕当前地址做跳转和整理。拿它来收口异常分发表、处理函数和业务函数之间的关系，效率通常比在正文里反复跳更高。

三、IDA里最容易看错的是哪里

异常处理这块最常见的误判，不是没找到表，而是把几种完全不同的信息混到一起。先把这些误区拎开，后面判断会稳很多。

1、不要把.reloc当成异常处理表

PE里Exception Table指向的是.pdata，而Base Relocation Table指向的是.reloc。两者都在数据目录里，但作用完全不同，一个服务异常处理，一个服务基址重定位，读表时不要混。

2、不是每个函数都一定有RUNTIME_FUNCTION

微软对x64的说明写得很明确，表驱动异常处理要求为会分配栈空间或会调用其他函数的非叶子函数建立表项。反过来说，纯叶子函数本来就可能没有表项，所以你在.pdata里找不到，不一定是IDA漏掉了。

3、语言相关数据没有统一长相

很多人看到处理器地址后，就想按固定结构去解后面的数据，但微软文档已经说了，语言相关处理数据的格式完全由具体处理器自己定义。也就是说，后半段一定要回到具体编译器和运行时语义里去看，不能只靠通用表头。

4、流程追踪要和当前地址位置结合

同一张异常表，不同当前位置看到的分发结果可能不同。因为系统判断时会先分清当前RIP是在prolog、epilog，还是普通函数体，再决定是模拟回退、继续展开，还是调用语言处理器。逆向时不把当前地址放进去，流程很容易追成静态表解析，而不是实际分发路径。

总结

IDA异常处理表怎么看，核心是先从Exception Table定到.pdata，再从RUNTIME_FUNCTION跳到.xdata里的UNWIND_INFO。IDA异常处理流程怎么追踪，核心则是把当前函数范围、UNWIND_INFO标志位、链式记录、处理函数地址和交叉引用这几层串起来。把这条线走顺之后，你看到的就不只是几块表数据，而是一条完整的异常分发与展开路径。