简介这是一份面向逆向工程初学者与OllyDBG插件开发者的实战源码包以Plug110为例系统展示动态反汇编器插件的完整开发框架。资源共21个文件压缩包约209KB涵盖C与CPP源文件、头文件、模块定义文件、帮助文档及工程配置。其中源码部分涉及书签标记、命令执行与命令处理等核心逻辑头文件与def文件给出插件接口与导出函数声明hlp帮助文档提供开发指南mak、dsp、dsw、bpr等工程文件则适配Borland C与Visual C两套编译环境。已有229人学习下载读者可借此理解插件初始化、消息处理、API调用与注册机制掌握自定义命令扩展与调试流程控制方法并对照帮助文档逐步搭建自己的插件工程为后续漏洞分析与逆向工具开发打下基础。1. plug110 插件源码从调试器扩展机制到可复现的二次开发第一次拿到 plug110 这套 OllyDBG 插件源码时我盯着目录里那几个 .cpp 和 .h 文件看了很久——它不像一个完整产品更像一份“调试器扩展机制”的活体标本。OllyDBG 本身是经典的 32 位用户态调试器而 plug110 这类插件源码的价值在于它把“如何往调试器里挂功能”这件事拆开给你看。你能从中学到插件导出函数怎么被宿主识别、菜单和快捷键怎么注册、调试事件回调怎么拿到寄存器上下文。适合谁适合已经会用调试器下断点、但想自己写插件做批量分析、自动化标注或反混淆辅助的从业者。它解决的不是“怎么调试”而是“怎么让调试器按你的规则干活”。2. 插件导出与宿主加载plug110 源码里最先要读懂的三个函数2.1 从 OllyDBG 插件规范看 plug110 的入口点OllyDBG 插件本质是一个 DLL宿主在启动或手动加载时调用固定导出函数。plug110 源码里最关键的三个导出通常是_ODBG_Plugindata、_ODBG_Plugininit、_ODBG_Pluginmenu。第一个告诉宿主插件名和版本第二个做初始化并拿到宿主版本与回调表第三个注册菜单项。很多人第一次编译完插件发现 OllyDBG 根本不认八成是导出名写错或调用约定不对。// plug110 插件入口示例导出函数必须按 OllyDBG 规范声明 extern C __declspec(dllexport) int _ODBG_Plugindata(char *shortname) { // shortname 是宿主传入的缓冲区写入插件短名最长 31 字符 strcpy(shortname, plug110); return PLUGIN_VERSION; // 返回插件版本号宿主据此判断兼容性 } extern C __declspec(dllexport) int _ODBG_Plugininit( int ollydbgversion, HWND hwnd, ulong *features) { // ollydbgversion 是宿主版本features 用于声明插件需要的事件 if (ollydbgversion 110) return -1; // 版本不匹配直接失败 g_hwndMain hwnd; // 保存主窗口句柄后续弹窗要用 *features 0; // 按需设置比如 PF_... return 0; // 返回 0 表示初始化成功 }逻辑说明_ODBG_Plugindata只负责“报名”不要在里面做重活_ODBG_Plugininit才是拿宿主句柄和版本的地方。参数ollydbgversion是整数常见做法是判断是否低于你依赖的最低版本。features是位掩码plug110 里如果没用到特殊事件回调置 0 最安全。注意导出必须用extern C防止 C 名字修饰否则宿主按名字找不到。2.2 菜单注册与命令分发plug110 怎么把功能挂到右键菜单插件初始化成功后宿主会调用_ODBG_Pluginmenu来获取菜单项。plug110 源码里通常返回一个以\0分隔的字符串每项格式是“菜单文本|快捷键|描述”。命令分发靠_ODBG_Pluginaction根据传入的 action id 执行对应逻辑。extern C __declspec(dllexport) char * _ODBG_Pluginmenu( int origin, char *data, int item, int *flags) { // origin 表示菜单来源PM_MAIN 主菜单PM_DISASM 反汇编窗口右键等 if (origin PM_MAIN) { return 批量标注\0 // 菜单显示文本 1\0 // 快捷键这里用 1 对当前模块做批量注释\0; // 状态栏描述 } return nullptr; // 其他来源不注册 } extern C __declspec(dllexport) void _ODBG_Pluginaction( int origin, int action, void *data) { switch (action) { case 1: // 对应上面菜单项的顺序编号从 1 开始 DoBatchAnnotate(); // plug110 里的实际业务函数 break; default: break; } }逻辑说明_ODBG_Pluginmenu的返回值是静态字符串不要返回局部变量。origin决定菜单出现在哪PM_MAIN是主菜单PM_DISASM是反汇编窗口右键。action编号按菜单项顺序从 1 开始和字符串里的顺序严格对应。参数data在反汇编窗口来源时可能指向当前选中的指令地址plug110 里如果要做“对选中行操作”必须判断origin再解引用。2.3 调试事件回调拿到寄存器上下文的最小闭环插件要真正有用得能感知调试事件。OllyDBG 通过_ODBG_Pluginnotify通知插件断点命中、单步、模块加载等。plug110 源码里这个函数通常是个大 switch按code分支处理。extern C __declspec(dllexport) void _ODBG_Pluginnotify( int code, void *data1, ulong data2) { switch (code) { case PN_BREAKPOINT: { // data1 指向 t_reg 结构包含 EIP/EAX 等寄存器 t_reg *reg (t_reg *)data1; char buf[64]; sprintf(buf, 断点命中 EIP%08X, reg-eip); // 这里可以写日志或更新插件自己的窗口 OutputDebugStringA(buf); break; } case PN_NEWMODULE: // data1 指向模块信息data2 是模块基址 break; default: break; } }逻辑说明code是事件类型PN_BREAKPOINT最常用。data1的类型随code变化断点事件里是t_reg*这个结构在 OllyDBG 的插件 SDK 头文件里有定义。data2通常是辅助值比如模块基址。注意这个回调在调试器主线程里执行不要做耗时操作否则整个调试器会卡住。plug110 里如果要做批量分析常见做法是先把数据拷到队列另起线程处理。3. 编译与加载 plug110从源码到 OllyDBG 里能点的菜单3.1 用 Visual Studio 建 DLL 工程的四个关键设置plug110 是 32 位插件因为 OllyDBG 本身是 32 位进程。用 VS 新建“动态链接库”工程后第一件事是把平台切成 Win32不是 x64。第二字符集建议用多字节因为 OllyDBG 插件接口大量用char*用 Unicode 会多出一堆转换。第三运行库选多线程调试或发布都行但如果你把插件发给别人选/MT静态链接更省事。第四导出用 .def 文件比__declspec(dllexport)更稳因为 OllyDBG 对导出名大小写敏感。# 如果用命令行编译核心是 /LD 生成 DLL/MT 静态链接运行库 cl /LD /MT /DWIN32 plug110.cpp plugin_utils.cpp /link /DEF:plug110.def # plug110.def 内容示例 # EXPORTS # _ODBG_Plugindata # _ODBG_Plugininit # _ODBG_Pluginmenu # _ODBG_Pluginaction # _ODBG_Pluginnotify逻辑说明/LD告诉编译器产出 DLL。/MT避免目标机器缺运行库。.def文件里导出名必须和源码里函数名完全一致包括下划线。如果你用extern C加__declspec(dllexport)导出名可能带修饰用dumpbin /exports检查最保险。3.2 把 DLL 放进 OllyDBG 插件目录并验证加载编译出plug110.dll后放到 OllyDBG 安装目录的plugin子目录下。启动 OllyDBG如果插件加载成功主菜单会多出“插件”项里面能看到“plug110”。如果没出现按顺序排查DLL 是否 32 位、导出名是否正确、是否缺依赖 DLL。// 一个最小自检在 Plugininit 里写日志确认宿主调用了你 extern C __declspec(dllexport) int _ODBG_Plugininit( int ollydbgversion, HWND hwnd, ulong *features) { FILE *fp fopen(plug110_load.log, a); if (fp) { fprintf(fp, loaded, host version%d\n, ollydbgversion); fclose(fp); } return 0; }逻辑说明写文件日志是最朴素的验证手段。如果日志没生成说明宿主根本没调用_ODBG_Plugininit问题在导出或 DLL 架构。如果日志生成了但菜单没出现问题在_ODBG_Pluginmenu的返回值格式。参数ollydbgversion能帮你确认宿主版本有些插件接口在不同版本间有差异。3.3 用 plug110 的菜单命令做一次批量注释的完整流程假设 plug110 里有个“批量标注”功能逻辑是遍历当前模块的所有指令把调用 API 的地方加上注释。操作步骤先在 OllyDBG 里按 AltE 打开模块列表选中目标模块然后点插件菜单里的“批量标注”插件内部通过宿主回调遍历代码段。// 伪代码遍历模块代码段并加注释 void DoBatchAnnotate() { ulong base GetModuleBase(); // 从宿主接口拿当前模块基址 ulong size GetModuleSize(); // 模块大小 for (ulong addr base; addr base size; ) { // 用宿主提供的反汇编接口解码一条指令 t_disasm dis; int len Disasm(addr, dis, ...); if (len 0) break; if (dis.comment[0] 0 IsCallToAPI(addr)) { // 给这条指令设置注释 SetComment(addr, API call); } addr len; } }逻辑说明GetModuleBase、Disasm、SetComment都是宿主暴露给插件的接口plug110 源码里会有一层封装。Disasm返回指令长度必须按长度递增否则会解码错位。IsCallToAPI是自定义判断通常看操作数是不是call dword ptr [导入表地址]。注意遍历大模块时加进度提示否则用户以为卡死。4. 避坑与排查plug110 二次开发里最容易翻车的五件事4.1 插件加载后 OllyDBG 直接崩溃现象把编译好的 DLL 放进 plugin 目录启动 OllyDBG 瞬间闪退。原因最常见的是_ODBG_Plugindata里往shortname写入了超过 31 字符的字符串或者返回了非法版本号。解决短名控制在 10 字符以内版本号用 SDK 头文件里的宏不要自己瞎写。另一个原因是 DLL 依赖了调试版运行库而目标机器没有换/MT重新编译。4.2 菜单出现了但点击没反应现象插件菜单能显示点下去毫无动静。原因_ODBG_Pluginmenu返回的字符串格式不对比如少了\0分隔或者_ODBG_Pluginaction里的action编号和菜单顺序对不上。解决菜单字符串每一项必须以\0结尾最后再补一个\0。action从 1 开始按顺序编号不要跳号。用OutputDebugString在 action 里打日志确认是否被调用。4.3 断点回调里读寄存器读到脏数据现象_ODBG_Pluginnotify里打印 EIP结果每次都是 0 或乱码。原因data1的类型没按code正确转换或者回调发生在断点尚未完全建立上下文时。解决先判断code PN_BREAKPOINT再转t_reg*。如果还是不对检查 OllyDBG 版本和 SDK 头文件是否匹配不同版本t_reg布局可能有差异。稳妥做法是只读你确定存在的字段比如eip。4.4 批量操作把调试器卡死现象点了批量标注后OllyDBG 界面无响应几十秒后才恢复。原因_ODBG_Pluginaction在宿主主线程里同步执行遍历大模块时每条指令都调宿主接口开销累积。解决把批量任务拆成小块用SetTimer或另起线程分批处理每批之间让出消息循环。plug110 源码里如果直接写了个大循环这就是血泪教训。4.5 编译报错“无法解析的外部符号ODBG...”现象链接阶段报一堆_ODBG_开头的未解析符号。原因没有包含 OllyDBG 插件 SDK 的导入库或者 .def 文件里导出名和源码不一致。解决确认工程里链接了ollydbg.lib或对应版本的导入库并且 .def 文件里的导出名和dumpbin /exports看到的一致。如果 SDK 只给了头文件没给 lib用LoadLibraryGetProcAddress动态获取宿主接口但插件导出仍然需要 .def。5. 进阶把 plug110 改造成自己的自动化分析骨架5.1 用插件做条件断点日志不改 OllyDBG 一行代码OllyDBG 自带的条件断点功能有限plug110 的源码骨架可以让你在PN_BREAKPOINT回调里写任意判断逻辑。比如你只想在 EAX 等于某个魔数时记录其他情况自动继续。case PN_BREAKPOINT: { t_reg *reg (t_reg *)data1; if (reg-eax 0xDEADBEEF) { // 命中条件写日志并暂停 LogToFile(hit: EIP%08X, reg-eip); // 不调用继续调试器就停在这里 } else { // 不满足条件让调试器自动继续 // 具体接口名以 SDK 为准常见是 Go() 或 SetContinue() ContinueDebug(); } break; }逻辑说明ContinueDebug是示意名实际接口在 SDK 里可能是Go或通过设置标志位实现。关键点是在断点回调里决定“停还是走”比在 OllyDBG 界面里配条件断点灵活得多。参数reg-eax只是示例你可以组合多个寄存器或内存值。注意自动继续时不要形成死循环加个计数器上限。5.2 插件与外部工具联动把分析结果导出成可读格式plug110 的另一个进阶用法是把调试器里的信息导出给外部脚本处理。比如遍历模块的导入表把 API 调用关系写成 CSV再用 Python 做图分析。# 外部 Python 脚本读取插件导出的 CSV 并统计 API 调用频次 import csv from collections import Counter calls Counter() with open(plug110_export.csv, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: calls[row[api_name]] 1 for api, cnt in calls.most_common(20): print(f{api}: {cnt})逻辑说明插件端负责在调试器里遍历并写 CSVPython 端只做统计。CSV 字段建议包含address, api_name, module。这样分工的好处是插件保持轻量复杂分析放到外部。参数most_common(20)控制输出前 20 个按需调整。5.3 验证插件是否真正生效的三个检查点改完 plug110 后怎么确认你的修改起作用了第一看日志文件时间戳是否更新。第二在_ODBG_Pluginaction里加一个弹窗MessageBox点击菜单能弹出来说明命令分发通了。第三用dumpbin /exports plug110.dll确认导出函数一个不少。我一般会保留一个“自检”菜单项专门用来打印当前插件版本和宿主版本省得每次靠猜。// 自检菜单项的实现 void ShowSelfCheck() { char msg[128]; sprintf(msg, plug110 v1.0\nhost hwnd%p, g_hwndMain); MessageBoxA(g_hwndMain, msg, self check, MB_OK); }逻辑说明g_hwndMain是在_ODBG_Plugininit里保存的宿主主窗口句柄弹窗必须用它做父窗口否则可能被调试器窗口盖住。MessageBoxA用多字节版本和插件整体字符集一致。这个自检项在排查“插件到底加载没有”时特别省时间。5.4 一个我踩过的坑插件里不要缓存宿主指针早期我写插件时喜欢在_ODBG_Plugininit里把宿主给的函数指针表存到全局变量结果 OllyDBG 重启调试会话后指针失效插件行为变得诡异。后来改成每次用的时候通过宿主句柄重新获取或者只缓存句柄不缓存函数地址。这个习惯让我少了很多“玄学”崩溃。插件生命周期和调试会话生命周期不是一回事宿主可能在你不注意的时候重新初始化内部结构。希望帮到你。本文还有配套的精品资源点击获取