IDA故障排除过程记录

由于IDA闭源，又加上其十分无效的官方文档（指和代码无异，代码也没有注释，文档也没有注释）。因此如果出现任何错误，都需要进行分析和查错，这一过程很麻烦。于是我在这里给出逆向IDA错误代码的方法。本文可以作为部分错误的索引，也可以作为逆向一个大型软件的初学者教程。

也算是久病成医了，众所周知越是容易发生的故障在要紧的时候越会发生。上次ciscn边逆边修ida。这次打完了，我就要看看ida到底抽什么疯！

情景再现

你遇到了下述故障

是的，这个故障没有给出其他的信息。像这样的“一刀砍死”的故障还有很多。

IDA的霸王条款是告诉你要么生成一个dump，然后关闭IDA，要么直接退出。于是你生成了dump文件。

按下确定之后，IDA就随风而逝了。你气急败坏的不断导入文件，但是IDA就是屹然不动。欸，错误修复了吗？如修！

观察故障的表和log，也没有任何反馈。于是你开始去搜索。搜索的结果就是，没有任何帮助。于是你来到了一片没有知识的荒原。于是只好干回老本行，用逆向手段观察这个错误是什么。简称，用IDA调试IDA。

安全模式

借鉴Windows的灾难修复过程，程序的“安全模式”指的是关闭其他一切插件、附件，以最初的配置启动IDA。因为你很明确在你第一次启动IDA的时候这个程序运行是正常的，只是有一天你心血来潮看到了IDA的某个插件，于是你装了第一个插件。于是你接着装了第二个，第三个，直到今天这个可怕的错误爆发。

首先你要禁用所有plugin。将你的plugin文件夹按照日期排序，从新到旧移除你以前安装的插件。

最终你发现，如果装上红框里的插件，这个错误就会出现。于是你锁定了这个插件，修复这个插件就可以了。

修复的参考步骤将放在后文技术节

未知bug

可是你没有安装任何插件，或者说这个bug如影随形，根本不是插件引起的。于是我们进入Exception Analysis阶段。

使用WinDBG打开导出的dump文件

windbg大名鼎鼎，其威名必不用说。载入后，你会看到红框部分的提示

windbg的语法在此不表，虽然诸位不开发驱动或者硬件，但是windbg是推荐学一学的。根据上面的提示，我们按下这个超链接（或者键入指令）

经过windbg的一顿操作，下面的输出多了不少

我们继续向下翻

在这里，记录了发生错误的进程名称和错误代码。一般而言，根据规范引发的错误，尤其是经由RaiseException的错误，大多都应该返回一个有效的错误码。这一点在Windows的蓝屏分析上尤其重要。使用WinDBG分析BSOD错误也是这个思路，根据PROCESS NAME就可以分析错误应用，并由此大概可以猜测到底是什么故障了。

我们本寄希望于错误代码能告诉我们就行发生了什么错误，但是奈何这个错误代码0xe0424242根本狗屁不通。于是我们只好接着向下看。注意到接下来出现STACK TEXT。这里代表栈追踪，用于指示程序在执行过程中发生异常或错误时的调用堆栈信息。系统的代码调用路径就显示在堆栈跟踪上。

堆栈跟踪中显示，调用链如下：

那么回溯上去，我们可以从内存地址ida64!init_database+0xe2d开始看。打开IDA，注意到此时的被调用方为ida64，代表dll。载入dll，根据导出表找到init_database的基址

计算init_database+0xe2d，追踪到对应的内存位置

由于栈底保留的是返回指针，即函数ret之后应该执行的下一条指令的位置，于是我们知道异常的发生应该在函数sub_101CA560内。

注意user2bin+0x4200位置的代码，在往下追踪之前，我们先看看这是干什么的。

根据提示字符串，这是在加载插件时出现故障了。

追踪到sub_101CBC60函数内查看

注意到这里发生错误(interr的条件为!v44 && *((char *)v40 + 144) < 0)，很明显v40是一个结构体。动态调试一下看

分析过程不表，因为已经可以用动态调试的方法获得参数，在这里给出函数的原型

其第三个参数file_path为加载的dll等一众插件的地址。这里会对插件进行初始化。

其中参数v44为当前插件的代码入口。

而v40+144我猜测是链表的next项。如果插件出现未卸载或者什么别的后卸载故障（例如内存未回收等），那么这里的代码入口和下一表项可能出现为空、为负数的故障，因此引发错误，错误编号1827。

部分故障码分析结果

有了上面的分析基础，又加上ida本身并不进行反调试，因此可以搜索interr的函数调用，分析上下文，给出错误原因。

1491

IDA 7.0故障，已经在后续版本中被修复了。

这个故障由 IDA Pro 中的 winbase_debmod.cpp （ Windows 调试器模块）引发。这段代码的目的是向 ntdll_vec_t 类型的容器中添加一个新的 ntdll_range_t 元素。

该函数 ntdll_vec_t::add() 在调试器模块中用于添加对应的 ntdll（NT DLL）库的信息。这段代码包含了一个断言（assertion）QASSERT(1491, size() < 2)，它的作用是确保容器中的元素数量不超过 2。如果当前容器中的元素数量已经达到或超过 2，那么这个断言将会触发一个错误（error）编号为 1491。

根据提供的信息，为了解决在 Windows 10 的版本大于 16xxx 下使用 IDA Pro 7.0 时的问题，建议注释掉这个断言或者通过修复二进制文件来禁用这个检查。

40343

此故障属于Qt界面方面的故障，根据调试信息

这里会进入选择架构框

根据网上的教程，引发此错误的原因应该是由于路径中出现宽字符（例如中文），导致qword_7ff755247b70对应的参数（即支持的架构数量）归零，然后选中的架构又高于0，于是引发了40341错误。

1203

来源：

由于版本是6.8，已经老旧到近10年了，这个报错很可能已经被消除了，因此在此不表。如果确实有大哥2024年还在用2014年的工具....升级一下ida吧

40178

BUGFIX: debugger: using instant debugger for debugging a 32bit MacOSX application could cause internal error 40178

，早在6.4版本就修复了MACOSX的故障，

520

BUGFIX: Leaving a mark, and then right-clicking on the address of an instruction could cause IDA to INTERR with the code 520

，虽然听上去520，但是这是一个bug，已经在6.9版本修复了。

1827

分析过程不表，插件出现故障。修复的方法是修改插件的加载flag。（目前不确定是否100%有效，Use at your own risk）

这里插播一个小知识

• PLUGIN_MOD (0x0001): 表示插件可以修改IDA的状态或行为。
• PLUGIN_DRAW (0x0002): 表示插件可以在IDA的图形界面上进行绘图或显示自定义图形。
• PLUGIN_SEG (0x0004): 该标志在IDA 7.0之前使用，现在已被弃用，不再使用。
• PLUGIN_UNL (0x0008): 该标志在IDA 7.0之前使用，现在已被弃用，不再使用。
• PLUGIN_HIDE (0x0010): 表示插件应该隐藏其界面，以便在加载时不显示插件的任何用户界面元素。
• PLUGIN_DBG (0x0020): 表示插件是一个调试器插件，用于与调试器交互。
• PLUGIN_PROC (0x0040): 表示插件是一个处理器模块（Processor Module），用于支持特定的处理器架构。
• PLUGIN_FIX (0x0080): 表示插件是一个修复插件，用于修复IDA中的一些问题或提供额外的修复功能。
• PLUGIN_MULTI (0x0100): 表示插件是一个多实例插件，允许同时存在多个实例。
• PLUGIN_SKIP: 表示插件在初始化期间被跳过。
• PLUGIN_OK: 表示插件初始化成功。
• PLUGIN_KEEP: 表示插件在IDA关闭时保持加载状态。

这些常量用于设置插件的标志属性，并根据插件的需求来定义其行为和特性。插件开发者可以根据需要选择适当的标志来定义插件的行为。

PLUGIN_KEEP 是一个IDA插件的常量，用于定义插件的行为和生命周期。具体来说，它指定了插件在IDA关闭时是否保持加载状态。

当插件被设置为 PLUGIN_KEEP 时，它将保持加载状态，即使用户关闭了IDA。这意味着，在下次启动IDA时，插件将继续保持加载状态，并自动运行。

插件保持加载状态的好处是，它可以在IDA重新启动时无缝地恢复之前的状态和设置。例如，如果插件负责维护一些用户自定义的配置或数据，那么通过设置 PLUGIN_KEEP，它可以确保这些数据在IDA关闭和重新打开后仍然可用。

值得注意的是，插件的保持加载状态并不意味着它会一直运行。插件的运行仍然取决于其初始化函数的调用时机和其他条件。

来源：ChatGPT

2028

遇到过一次，原因是在文件加载之前就调用了Strings窗口。

可能是出于安全性设计，因此修复方案也很简单，别调用就行。

这个也是插件故障。