★ FEATURED ARTICLE 简介这份资源是OllyDBG插件开发的学习源码包面向软件逆向工程初学者与希望扩展调试器功能的开发者。OllyDBG作为知名动态反汇编器其开放API允许开发者编写插件而Plug110正是一个完整的插件示例涵盖书签标记、命令执行、命令处理等核心模块帮助读者理解插件从初始化、消息处理到卸载的完整生命周期。压缩包共21个文件约209KB包含3个c源文件、2个cpp文件、1个h头文件、1个def导出定义、1个hlp帮助文档及1个rtf说明另有mak、dsp、dsw、bpr等编译工程配置和lib库文件分别对应Borland C与Visual C环境。已有229人学习下载。通过分析源码读者可掌握OllyDBG API调用、自定义命令注册、插件注册流程与编译设置并借助帮助文档逐步理解各模块协同方式为开发自己的调试插件和深入逆向工程实践打下基础。1. plug110 插件源码从调试器扩展机制到可复现的二次开发第一次拿到 plug110 这类调试器插件源码时很多人会下意识地把它当成一个“能跑就行”的小工具编译通过、加载进调试器、菜单里多出一项就觉得已经吃透了。真正上手改功能才会发现插件和调试器之间那层接口才是核心菜单怎么注册、事件怎么回调、进程内存怎么读写、反汇编结果怎么拿全都藏在一套约定好的导出函数和结构体里。plug110 作为一类经典的调试器插件源码价值不在于它本身功能多强而在于它把“调试器如何被扩展”这件事摊开给你看。适合谁读想给调试器加自定义分析能力的安全研究员、需要批量处理样本的逆向工程师以及想理解 Windows 用户态调试接口的开发者。这一篇不讲空泛概念只讲怎么把这份源码读通、编译出来、改出一个自己的功能以及中间会踩哪些坑。2. 调试器插件到底怎么被加载导出函数与事件模型2.1 插件不是 DLL 那么简单关键是导出约定Windows 下调试器插件通常就是一个 DLL但调试器不会随便加载任意 DLL。它会在启动时扫描插件目录对每个 DLL 调用LoadLibrary然后通过GetProcAddress查找几个约定名字的导出函数。plug110 这类源码里最关键的导出一般包括插件初始化入口、插件销毁入口以及一个用于接收调试事件的回调注册函数。调试器加载插件后先调用初始化函数把自身的一组服务函数指针通过结构体传进来插件拿到这些指针才能反过来调用调试器的内存读写、反汇编、符号解析等能力。这个“调试器传服务指针给插件、插件注册回调给调试器”的双向约定是整个插件机制的核心。很多新手改源码时只盯着插件自己的逻辑忽略了服务结构体的版本和字段偏移结果一调用就崩。常见做法是先把服务结构体的定义完整抄下来确认字段顺序和调试器版本匹配再动业务代码。// 插件导出入口的典型形态示意字段名以实际源码为准 // 调试器加载 DLL 后会查找这个导出名 __declspec(dllexport) int __cdecl PluginInit(void* hostServices) { // hostServices 是调试器传入的服务函数表 // 第一步永远是校验版本避免结构体错位 HostApi* api (HostApi*)hostServices; if (api-version ! EXPECTED_API_VERSION) { return 0; // 版本不匹配直接拒绝加载别硬跑 } g_api api; // 存全局后续回调里要用 // 注册我们关心的调试事件 g_api-register_event_callback(ON_PROCESS_START, OnProcStart); g_api-register_event_callback(ON_BREAKPOINT, OnBreakpoint); return 1; // 返回非零表示加载成功 }这段代码的逻辑很直白先校验接口版本再把服务表存到全局最后注册事件回调。参数说明上hostServices是调试器传进来的指针不能假设它长期有效通常要在初始化时把需要的函数指针复制出来返回值必须是调试器约定的成功标志返回 0 会被当成加载失败。注意事件回调注册的时机必须在初始化函数内完成放到别的地方可能调试器还没进入事件循环注册就丢了。2.2 事件回调是插件的生命线插件加载成功后大部分时间都在等调试事件。断点命中、进程创建、模块加载、异常分发这些都会触发回调。plug110 源码里通常有一个事件分发函数根据事件类型 switch 到不同处理逻辑。理解这一点才能知道自己的功能该挂在哪个事件上。比如你想在每次断点命中时打印寄存器就该挂断点事件想在进程刚启动时注入分析逻辑就挂进程创建事件。// 事件回调的典型分发结构 void __cdecl OnDebugEvent(DebugEvent* evt) { switch (evt-type) { case ON_PROCESS_START: // 进程刚起来此时模块还没加载完别急着读代码段 Log(process started, pid%d, evt-pid); break; case ON_BREAKPOINT: // 断点命中此时可以安全读取寄存器和栈 HandleBreakpoint(evt-tid, evt-address); break; case ON_MODULE_LOAD: // 模块加载适合做符号或导入表分析 AnalyzeModule(evt-module_base, evt-module_size); break; default: break; } }逻辑说明事件类型决定你能安全做什么。进程创建事件里读代码段往往拿到的是空页因为主模块还没映射完断点事件里读寄存器和栈是安全的因为线程已经停在确定状态。参数上evt-pid、evt-tid、evt-address这些字段是否有效取决于事件类型源码里一般有注释标明改代码前务必确认。我一般会在每个 case 开头加一句日志确认事件真的按预期触发这是排查“功能没反应”最快的手段。2.3 内存读写与反汇编插件能力的边界插件能做的事受限于调试器暴露的服务函数。plug110 源码里通常会封装几个常用能力读进程内存、写进程内存、反汇编指定地址、解析符号。这些能力不是无限的读内存要处理跨页和不可读页反汇编要处理变长指令边界。很多插件翻车就翻在没做异常保护读一个非法地址直接把调试器带崩。// 安全读取目标进程内存的封装 int SafeReadMemory(void* addr, void* buf, size_t size) { // 先查页属性不可读就别试了 if (!g_api-is_memory_readable(addr, size)) { Log(addr %p not readable, skip, addr); return 0; } // 分页读取避免跨页失败 size_t done 0; while (done size) { size_t chunk min(size - done, PAGE_SIZE); if (!g_api-read_memory((char*)addr done, (char*)buf done, chunk)) { return 0; // 任何一页失败就整体放弃别返回半截数据 } done chunk; } return 1; }这段封装的价值在于把“可读性检查”和“分页读取”两件事做掉。参数上PAGE_SIZE一般取 4096is_memory_readable是调试器提供的查询函数不是所有版本都有没有的话就得靠read_memory的返回值自己判断。注意返回半截数据比返回失败更危险调用方可能拿它去解析结构体直接越界。我一般要求这个函数要么全成功要么全失败。3. 把 plug110 源码编译跑起来环境、依赖与最小验证3.1 编译环境怎么搭才不返工plug110 这类源码多数是 C/C 写的年代偏早常见的是用某版本 Visual Studio 的旧工具集。直接拿最新工具集编译最容易出的问题是字符集和结构体对齐。老代码里char*和TCHAR混用新工具集默认 Unicode一编译一堆类型不匹配。我的做法是先看源码里有没有工程文件有就按它标注的工具集装没有就新建一个 Win32 DLL 工程把字符集设成多字节运行库设成静态减少对目标机器运行库的依赖。# 用命令行编译的最小示例工具集按源码年代选 # 假设源码在 src/ 下输出 plug110.dll cl /nologo /LD /MT /D _CRT_SECURE_NO_WARNINGS ^ /I include ^ src/plugin_main.c src/event_handler.c src/memory_util.c ^ /Fe:plug110.dll ^ /link /DEF:plug110.def命令说明/LD生成 DLL/MT静态链接运行库/I include指定头文件目录/DEF指定导出定义文件。参数上/MT和/MD的区别在于目标机器要不要装对应运行库插件这种要加载进别人进程的东西静态链接更省事。注意导出定义文件里必须列出调试器要找的那几个函数名名字错了调试器就认为这不是合法插件直接跳过。3.2 加载验证先确认插件被认出来编译出 DLL 只是第一步能不能被调试器认出来是另一回事。把 DLL 放到调试器的插件目录启动调试器看插件菜单或日志里有没有出现。没有出现先查三件事导出函数名对不对、位数对不对32 位调试器只能加载 32 位插件、依赖 DLL 是否齐全。这三件事按顺序查能解决八成“加载失败”。// 用导出查看工具确认导出名或自己写个最小检查 // 伪代码枚举 DLL 导出确认关键函数存在 for each export in dll: if export.name PluginInit or export.name PluginUnload: print(found:, export.name)逻辑说明调试器找的就是固定名字的导出名字差一个字符都不行。参数上导出名区分大小写__cdecl和__stdcall会影响调用约定进而影响调试器能否正确调用。注意有些源码用.def文件重命名导出这时候要看.def里的名字不是函数本名。3.3 最小功能验证加一行日志插件被认出来之后别急着改复杂功能。先在初始化函数里加一行日志输出确认初始化真的被调用了。再在事件回调里加一行日志确认事件真的进来了。这两行日志是后续所有调试的基础没有它们你根本不知道问题出在加载阶段还是事件阶段。__declspec(dllexport) int __cdecl PluginInit(void* hostServices) { HostApi* api (HostApi*)hostServices; if (api-version ! EXPECTED_API_VERSION) return 0; g_api api; // 最小验证确认初始化被调用 g_api-log(plug110 init ok, api version%d, api-version); g_api-register_event_callback(ON_BREAKPOINT, OnBreakpoint); return 1; }参数说明g_api-log是调试器提供的日志函数输出到调试器自己的日志窗口比OutputDebugString更可靠因为它不依赖调试器是否捕获调试输出。注意日志函数本身也可能因为版本问题不存在源码里如果有条件编译按实际接口来。4. 改出一个自己的功能从读寄存器到批量分析4.1 选一个够小又够完整的功能切入改源码最忌讳一上来就动核心逻辑。我的习惯是选一个“读寄存器并打印”这种小功能它完整走通了事件回调、服务调用、日志输出三条链路改通了再往上加逻辑就顺。plug110 源码里一般已经有类似示例找到它改改输出格式确认能跑再动别的。void __cdecl OnBreakpoint(unsigned int tid, void* address) { // 断点命中读取当前线程的寄存器上下文 RegContext ctx; if (!g_api-get_thread_context(tid, ctx)) { g_api-log(get context failed, tid%u, tid); return; } // 打印关键寄存器EIP 指向断点地址 g_api-log(break at %p, EAX%08X EBX%08X ECX%08X, address, ctx.Eax, ctx.Ebx, ctx.Ecx); }逻辑说明get_thread_context拿到的是线程停在断点时的寄存器快照address是断点地址通常和ctx.Eip一致。参数上tid是线程 ID不是进程 ID多线程场景下必须用事件给的 tid不能自己猜。注意寄存器结构体的字段名和位数取决于目标架构32 位和 64 位不一样源码里如果有条件编译别改错分支。4.2 把单次分析扩展成批量处理单次打印只是验证真正有用的是批量。比如你想统计某个函数被调用的次数就在断点回调里累加计数在进程退出事件里输出汇总。这里的关键是状态管理插件是常驻的全局变量会跨事件、跨进程保留必须自己做好清理否则第二个进程的数据会污染第一个。// 全局统计状态注意跨进程清理 static unsigned int g_hit_count 0; static unsigned int g_current_pid 0; void __cdecl OnProcessStart(unsigned int pid) { // 新进程开始重置统计避免上一个进程的数据残留 g_current_pid pid; g_hit_count 0; } void __cdecl OnBreakpoint(unsigned int tid, void* address) { if (address g_target_address) { g_hit_count; } } void __cdecl OnProcessExit(unsigned int pid) { if (pid g_current_pid) { g_api-log(pid%u hit count%u, pid, g_hit_count); } }逻辑说明OnProcessStart里重置计数OnProcessExit里输出汇总这样每个进程的统计互不干扰。参数上g_target_address是你要监控的地址实际使用中通常从模块基址加偏移算出来不能写死。注意如果调试器支持多进程同时调试全局变量就不够用了得用 pid 做键的映射表这是从单进程扩展到多进程的必经一步。4.3 反汇编与符号让输出可读地址和寄存器是给机器看的人要看得懂还得靠反汇编和符号。plug110 源码里一般会封装反汇编服务传入地址和缓冲区返回指令文本。符号解析则依赖调试器是否加载了符号文件。这两样东西能让你的插件输出从“一堆十六进制”变成“函数名加偏移”排查效率差好几倍。void PrintDisasm(void* address) { char text[128] {0}; // 反汇编一条指令长度由服务函数返回 int len g_api-disasm(address, text, sizeof(text)); if (len 0) { g_api-log(disasm failed at %p, address); return; } // 尝试解析符号失败就只打印地址 const char* sym g_api-resolve_symbol(address); if (sym) { g_api-log(%s%p: %s, sym, (char*)address - g_api-symbol_base(sym), text); } else { g_api-log(%p: %s, address, text); } }逻辑说明disasm返回指令长度用于判断是否成功resolve_symbol返回符号名失败返回空。参数上text缓冲区要足够大变长指令文本可能较长128 字节是保守值。注意符号解析在没加载符号文件时一定失败别把它当成 bug先确认符号路径配置对了。5. 避坑与排查插件开发里最容易翻车的五件事5.1 加载后没反应日志也没有现象DLL 放进插件目录调试器启动后菜单没变化日志窗口也没有插件的任何输出。原因通常是导出函数名不对或者位数不匹配。调试器找PluginInit你导出的是plugin_init大小写差一点就找不到。解决用导出查看工具确认导出名和调试器文档里的约定逐字比对同时确认 32/64 位一致32 位调试器加载不了 64 位 DLL反过来也一样。5.2 一断点就崩调试器跟着挂现象插件加载正常一命中断点调试器就崩溃退出。原因多半是回调里读了非法内存或者调用了不存在的服务函数。老源码里的服务结构体字段偏移和新版调试器不一致按老偏移调用就跳到错误地址。解决在回调入口加日志确认崩在哪一步所有内存读取走安全封装先查可读性服务函数调用前确认版本匹配不匹配就降级或直接不启用该功能。5.3 统计数字越跑越大跨进程污染现象监控一个进程时计数正常换一个进程后计数从上次的值继续涨。原因是全局变量没在进程切换时重置。解决在进程创建和进程退出事件里做状态清理用 pid 做键管理多进程状态。如果调试器支持同时调试多个进程全局变量方案直接不可用必须换成映射表。5.4 反汇编输出乱码或截断现象反汇编出来的指令文本是乱码或者只显示一半。原因通常是缓冲区太小或者字符集不匹配。变长指令文本可能超过预期长度缓冲区给小了就被截断老代码用多字节字符集新工程默认 Unicode输出就乱。解决缓冲区给足至少 128 字节确认工程字符集和源码一致必要时显式转换。5.5 插件卸载后调试器行为异常现象禁用或卸载插件后调试器某些功能不正常比如断点失效。原因是插件在初始化时改了调试器状态卸载时没恢复。比如插件注册了全局钩子、改了断点属性、占用了某些资源卸载函数里没释放。解决初始化里做的每一件事卸载里都要有对应的逆操作资源申请和释放成对写别指望调试器帮你清理。6. 进阶技巧用条件断点思路做精准过滤插件开发到后面最值钱的技巧不是写多少功能而是让插件只在真正关心的时候干活。调试器自带条件断点但条件复杂时性能很差每次命中都要解析表达式。更高效的做法是在插件里自己做过滤断点回调里先做轻量判断不满足条件直接返回满足条件再做重活。这样把过滤逻辑编译成机器码比解释执行条件表达式快得多。具体做法是在断点回调入口先用几个整数比较快速排除大部分命中。比如你只关心某个地址范围、某个线程、某个调用栈深度这些都能用寄存器值和内存读几个字节判断出来。只有全部通过才去读完整上下文、反汇编、解析符号。我一般会把过滤条件写成一个小函数返回布尔值回调里第一行就调用它。// 轻量过滤只关心特定地址范围且特定线程的断点 static int ShouldHandle(unsigned int tid, void* address) { // 地址范围判断纯整数比较极快 if ((char*)address g_range_start || (char*)address g_range_end) { return 0; } // 线程过滤只关心主线程 if (tid ! g_main_tid) { return 0; } return 1; } void __cdecl OnBreakpoint(unsigned int tid, void* address) { // 第一行就过滤不满足直接走避免任何重操作 if (!ShouldHandle(tid, address)) { return; } // 到这里才做读上下文、反汇编这些重活 RegContext ctx; if (g_api-get_thread_context(tid, ctx)) { g_api-log(target hit at %p, EAX%08X, address, ctx.Eax); } }这段代码的价值在于把过滤成本压到最低。ShouldHandle里只有整数比较和指针比较没有内存读取没有函数调用命中一万次也只花可忽略的时间。参数上g_range_start和g_range_end通常从模块基址加偏移算出来g_main_tid在进程创建事件里记录。注意过滤条件要尽量用事件里已经有的数据别在过滤函数里读内存否则过滤本身就变重了。另一个进阶点是利用调试器的符号服务做函数级过滤。如果你只关心某个函数的调用可以在模块加载事件里解析出该函数的地址范围之后断点回调里只比较地址是否落在范围内。这比每次解析符号快得多因为符号解析只在模块加载时做一次。我一般会在模块加载事件里把关心的函数地址缓存起来回调里直接用缓存值比较。验证插件过滤是否生效最直接的办法是加计数器过滤前命中多少次过滤后处理多少次两个数字一对比就知道过滤有没有起作用。如果过滤后处理次数还是很高说明过滤条件写松了或者事件挂错了地方。这个计数器我一般保留在调试版本里发布版本再去掉省得每次都要重新加。最后说个血泪经验插件里所有全局状态都要假设“会被多进程、多线程同时访问”。我早期写的一个统计插件单进程跑得好好的一开多进程调试数字全乱查了半天才发现是全局变量没加锁也没按 pid 隔离。后来养成习惯凡是跨事件的全局状态要么用 pid 做键要么加锁要么干脆改成每次从调试器服务里现查。这个习惯帮我省了无数后悔药。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
