x64dbg 插件 SDK 回调结构完全指南从事件注册到 24 个回调结构的源码级详解【免费下载链接】x64dbgAn open-source user mode debugger for Windows. Optimized for reverse engineering and malware analysis.项目地址: https://gitcode.com/gh_mirrors/x6/x64dbgx64dbg 的插件 SDK 通过事件回调机制把调试器内部的状态变化进程/线程/DLL 的创建与销毁、断点命中、异常、单步、暂停/恢复等以结构化信息的形式交给插件处理。本文以官方插件文档 Callbacks/index.rst 为骨架逐一剖析 SDK 中全部 24 个回调结构PLUG_CB_*的触发时机、成员含义与实战用法并结合 _plugins.h 源码确认结构定义与事件枚举的真实形态。读完本文你将能够正确注册事件回调、按生命周期精准订阅感兴趣的调试事件、在自己的插件里安全地消费回调信息并借助PLUG_CB_LOADSAVEDB实现插件数据的持久化。一、回调机制总览CBPLUGIN签名与_plugin_registercallbackx64dbg 插件 SDK 中所有事件回调共享同一个函数类型CBPLUGIN。它的定义官方文档原样给出如下void CBPLUGIN( CBTYPE bType, // event type事件类型当同一函数服务于多个事件时用来区分 void* callbackInfo // 指向信息结构的指针具体类型见下文各 PLUG_CB_* 结构 );第一个参数bType是事件类型枚举CBTYPE第二个参数callbackInfo则指向与该事件对应的信息结构。在 _plugins.h 的_PLUGINS_H头文件中可以找到完整的枚举定义每个枚举值都对应一个PLUG_CB_*结构事件类型CBTYPE回调信息结构CB_INITDEBUGPLUG_CB_INITDEBUG*CB_STOPDEBUGPLUG_CB_STOPDEBUG*CB_CREATEPROCESSPLUG_CB_CREATEPROCESS*CB_EXITPROCESSPLUG_CB_EXITPROCESS*CB_CREATETHREADPLUG_CB_CREATETHREAD*CB_EXITTHREADPLUG_CB_EXITTHREAD*CB_SYSTEMBREAKPOINTPLUG_CB_SYSTEMBREAKPOINT*CB_LOADDLLPLUG_CB_LOADDLL*CB_UNLOADDLLPLUG_CB_UNLOADDLL*CB_OUTPUTDEBUGSTRINGPLUG_CB_OUTPUTDEBUGSTRING*CB_EXCEPTIONPLUG_CB_EXCEPTION*CB_BREAKPOINTPLUG_CB_BREAKPOINT*CB_PAUSEDEBUGPLUG_CB_PAUSEDEBUG*CB_RESUMEDEBUGPLUG_CB_RESUMEDEBUG*CB_STEPPEDPLUG_CB_STEPPED*CB_ATTACHPLUG_CB_ATTACHED*即PLUG_CB_ATTACH见注释CB_DETACHPLUG_CB_DETACHED*即PLUG_CB_DETACHCB_DEBUGEVENTPLUG_CB_DEBUGEVENT*CB_MENUENTRYPLUG_CB_MENUENTRY*CB_WINEVENTPLUG_CB_WINEVENT*CB_WINEVENTGLOBALPLUG_CB_WINEVENTGLOBAL*CB_LOADDB/CB_SAVEDBPLUG_CB_LOADSAVEDB*CB_FILTERSYMBOLPLUG_CB_FILTERSYMBOL*CB_TRACEEXECUTEPLUG_CB_TRACEEXECUTE*注册回调_plugin_registercallback回调的注册入口是 _plugin_registercallback其完整签名如下void _plugin_registercallback( int pluginHandle, // 插件句柄 CBTYPE cbType, // 事件类型 CBPLUGIN cbPlugin // 回调函数 );三个参数的语义pluginHandle调用方插件的句柄在pluginit中由调试器提供位于PLUG_INITSTRUCT.pluginHandle。cbType要订阅的事件类型取值为上表中的任意CB_*常量。cbPlugin满足CBPLUGIN签名的回调函数指针。该函数没有返回值。官方文档明确指出每个插件可以针对每个事件注册自己的回调但同一个事件上不能注册多个回调“It is not possible to have multiple callbacks on the same event”。因此若你希望在一个回调函数里处理多个事件应当利用CBPLUGIN的第一个参数bType在函数内部做分发下文示例会演示这种做法。回调使用三条铁律官方文档 Callbacks/index.rst 在开篇强调了三条硬性约束这是写出健壮插件的前提callbackInfo指针永远不会是NULL但结构内部的成员可能是NULL。例如PLUG_CB_LOADDLL中的modInfo在符号信息不可用时即为NULL解引用前必须判空。回调中拿到的任何指针都不能逃逸出回调函数作用域。这些指针指向调试器内部缓冲区回调返回后即失效如需长期保存数据必须深拷贝。回调内原则上禁止耗时操作请放到独立线程中执行。多数回调在调试主循环debug loop内被同步调用阻塞它们会直接拖慢调试器PLUG_CB_DEBUGEVENT的文档甚至单独加粗警告“这会严重拖慢调试器”。另外从源码角度补充一个细节_plugins.h 在定义这些结构前使用了#pragma pack(push, ...)强制结构对齐——x64 构建按 16 字节对齐x86 构建按 8 字节对齐。这意味着插件必须以与调试器一致的架构编译避免因结构布局不一致导致读取错位。二、调试会话生命周期回调这一组回调覆盖了“开始调试 → 附加/创建进程 → 停止调试”的完整生命周期是插件初始化与清理内部状态的天然挂载点。PLUG_CB_INITDEBUG调试初始化每次调试会话初始化时触发官方用途是初始化插件内部变量。其结构只有一个成员struct PLUG_CB_INITDEBUG { const char* szFileName; // 被调试的可执行文件路径 };szFileName携带即将被调试的目标文件路径可用来按目标文件区分不同的调试会话例如为不同程序准备不同的分析配置。该回调的典型场景是把插件维护的会话级状态清零、记录目标文件名。需要注意附加调试attach场景下该回调同样会触发此时szFileName为被附加进程的主模块路径。PLUG_CB_STOPDEBUG调试停止调试会话结束时触发官方用途是重置插件变量与CB_INITDEBUG成对出现struct PLUG_CB_STOPDEBUG { void* reserved; // 保留字段恒为 NULL勿使用 };该结构只有一个reserved占位成员没有任何可消费的数据纯粹作为生命周期信号使用。在源码 _plugins.h 中同样如此定义。此外源码中还存在一个未在 toctree 中列出的PLUG_CB_STOPPINGDEBUG_plugins.h表示“正在停止调试”的中间状态可供对时序更敏感的插件参考。PLUG_CB_ATTACH附加进程之前在附加到目标进程之前调用结构提供目标进程的 PIDstruct PLUG_CB_ATTACH { DWORD dwProcessId; // 即将附加的进程 ID };注意事件枚举注释中写的是“before attaching, after CB_INITDEBUG”即附加场景下时序为先CB_INITDEBUG再CB_ATTACH。插件可以在此回调中根据dwProcessId预置针对特定进程的分析状态。PLUG_CB_DETACH分离进程之前在从目标进程分离之前调用struct PLUG_CB_DETACH { PROCESS_INFORMATION* fdProcessInfo; // 进程信息句柄与 ID };fdProcessInfo指向PROCESS_INFORMATION其中包含被分离进程的句柄hProcess与进程/线程 ID可用于在分离前执行最后的清理动作例如关闭自己打开的目标进程句柄。PLUG_CB_CREATEPROCESS进程创建完成在调试循环内、进程创建之后触发触发时机非常精确位于符号处理器symbol handler初始化之后、数据库文件加载之后、以及在 TLS 回调 / 入口断点上设置断点之后。也就是说插件在此回调中看到的已经是一个“符号就绪、断点就位”的进程struct PLUG_CB_CREATEPROCESS { CREATE_PROCESS_DEBUG_INFO* CreateProcessInfo; // Windows SDK 进程创建调试信息 IMAGEHLP_MODULE64* modInfo; // 主模块的符号信息可为 NULL const char* DebugFileName; // 被调试文件名 PROCESS_INFORMATION* fdProcessInfo; // 进程信息 };四个成员的用途CreateProcessInfoCREATE_PROCESS_DEBUG_INFOwinnt.h包含hFile主模块映像句柄、hProcess、hThread、lpBaseOfImage映像基址等。modInfoIMAGEHLP_MODULE64dbghelp.h主模块的符号路径、基址、大小等符号不可用时为NULL。DebugFileName被调试文件路径等价于PLUG_CB_INITDEBUG.szFileName。fdProcessInfoPROCESS_INFORMATION进程与初始线程的句柄/ID。这是插件获取主模块基址和PE 头的最佳时机很多反混淆、API 跟踪类插件都在这里记录lpBaseOfImage。PLUG_CB_EXITPROCESS进程退出在调试循环内、进程退出之后触发时序在符号处理器被清理之前因此此时符号仍可用struct PLUG_CB_EXITPROCESS { EXIT_PROCESS_DEBUG_INFO* ExitProcess; // 退出码信息winnt.h };EXIT_PROCESS_DEBUG_INFO只有一个成员DWORD dwExitCode即进程退出码。插件可以在此回调中做最终的统计收尾如汇总本次会话的断点命中次数并写日志因为符号尚在还能做最后的地址→符号翻译。三、线程与模块回调线程和 DLL 的创建/销毁是动态分析中最常见的事件流这组回调给出了每个事件的精确挂载点。PLUG_CB_CREATETHREAD / PLUG_CB_EXITTHREAD线程创建回调的触发时机是在调试循环内、线程被加入调试器内部线程列表之后、调试器因线程创建而暂停之前、线程入口断点设置之后struct PLUG_CB_CREATETHREAD { CREATE_THREAD_DEBUG_INFO* CreateThread; // 线程创建调试信息winnt.h DWORD dwThreadId; // 新线程 ID };CREATE_THREAD_DEBUG_INFO包含hThread、lpThreadLocalBaseTEB 基址和lpStartAddress线程起始地址。dwThreadId则直接给出新线程的 ID方便与后续该线程的所有事件关联。线程退出回调的触发时机是在调试循环内、线程终止之后、线程从内部线程列表移除之前、因线程终止而暂停之前struct PLUG_CB_EXITTHREAD { EXIT_THREAD_DEBUG_INFO* ExitThread; // 线程退出调试信息winnt.h DWORD dwThreadId; // 退出的线程 ID };EXIT_THREAD_DEBUG_INFO携带dwExitCode线程退出码。插件可在CB_EXITTHREAD中完成对该线程私有数据的清理——由于此时线程尚未从列表移除仍能查询线程上下文。PLUG_CB_LOADDLL / PLUG_CB_UNLOADDLLDLL 加载回调的触发时机是在调试循环内、DLL 被加入内部库列表之后、DLL 入口断点设置之后struct PLUG_CB_LOADDLL { LOAD_DLL_DEBUG_INFO* LoadDll; // DLL 加载调试信息winnt.h IMAGEHLP_MODULE64* modInfo; // 该模块的符号信息可为 NULL const char* modname; // 模块名路径 };LoadDllLOAD_DLL_DEBUG_INFO含hFile模块映像句柄与lpBaseOfDll模块加载基址。modInfo该模块的符号信息未加载符号时为NULL。modname模块路径字符串注意它与LoadDll中的字段可能来自不同来源以modname为准可避免因映像路径与磁盘路径不一致导致的混淆。DLL 卸载回调的触发时机是在调试循环内、DLL 从内部库列表移除之前、因卸载而暂停之前struct PLUG_CB_UNLOADDLL { UNLOAD_DLL_DEBUG_INFO* UnloadDll; // DLL 卸载调试信息winnt.h };UNLOAD_DLL_DEBUG_INFO携带lpBaseOfDll据此可以从插件的模块表中移除对应记录。注意卸载回调发生在“移除之前”意味着此时还能通过基址在内部库列表里找到该模块并做最后的数据收集。四、断点、单步与暂停/恢复状态回调这组回调反映调试器执行状态的核心切换是条件断点、步进跟踪类插件的核心依赖。PLUG_CB_SYSTEMBREAKPOINT系统断点在调试循环内、命中系统断点时触发时序位于设置初始 dump 位置initial dump location之后、调试器在系统断点处暂停之前struct PLUG_CB_SYSTEMBREAKPOINT { void* reserved; // 保留字段 };系统断点system breakpoint / entry breakpoint是调试器接管目标进程后命中的第一个可控断点此刻系统 DLLntdll.dll等已加载、进程环境已就绪。虽然结构本身没有数据成员但它标志着“调试会话真正开始”适合在此处执行需要进程上下文的一揽子初始化。PLUG_CB_BREAKPOINT断点命中在调试循环内、普通软件断点、内存断点或硬件断点命中时触发时序位于调试器锁定暂停之后struct PLUG_CB_BREAKPOINT { BRIDGEBP* breakpoint; // 桥接层断点结构 };BRIDGEBP是桥接层bridge定义的断点描述结构位于 src/bridge 目录的桥接头文件中包含断点地址、类型软件/内存/硬件、命中次数等信息。这是实现“断点命中后自动记录寄存器/栈数据”类功能的主入口。由于触发时调试器已锁定暂停回调中读取寄存器、内存都是安全的。PLUG_CB_STEPPED单步完成在调试循环内、调试器完成一次单步之后触发同样位于锁定暂停之后struct PLUG_CB_STEPPED { void* reserved; // 保留字段 };该回调没有数据成员需要寄存器或当前指令信息时可在回调内通过 SDK 的寄存器/反汇编接口自行获取。它是构建步进级跟踪器step tracer的基础事件。PLUG_CB_PAUSEDEBUG暂停在调试循环内、调试器已锁定暂停之后触发且早于所有其他“暂停前”回调struct PLUG_CB_PAUSEDEBUG { void* reserved; // 保留字段 };它是最先被派发的暂停信号适合做全局性的“进入暂停态”标记如刷新插件 UI 上的状态指示。PLUG_CB_RESUMEDEBUG恢复在调试循环之外outside of the debug loop、调试器解锁恢复之后触发struct PLUG_CB_RESUMEDEBUG { void* reserved; // 保留字段 };注意它与前面几个回调的上下文差异CB_RESUMEDEBUG明确不在调试循环内执行。这是整个回调体系中少数几个“循环外”回调之一可安全地在此启动异步任务如预取下一次断点命中所需的数据不必担心阻塞调试事件分发。五、调试事件回调DEBUGEVENT、EXCEPTION 与 OUTPUTDEBUGSTRINGPLUG_CB_DEBUGEVENT一切调试事件任何调试事件都会触发本回调包括那些被调试器内部处理不暂停的事件。这是最底层的观察窗口struct PLUG_CB_DEBUGEVENT { DEBUG_EVENT* DebugEvent; // Windows SDK 原始调试事件 };DEBUG_EVENTwinnt.h包含dwDebugEventCode事件代码、dwProcessId、dwThreadId以及按事件类型联合的u成员。官方文档对本回调给出了最严厉的警告“避免在这里做任何耗时的事情这会严重拖慢调试器”因为每个事件包括LOAD_DLL_DEBUG_EVENT、OUTPUT_DEBUG_STRING_EVENT、EXCEPTION_DEBUG_EVENT等所有代码都会经过它任何多余计算都会被放大到每个调试事件上。需要全量事件流的场景如事件统计插件应在此只做轻量记录重活交给独立线程。PLUG_CB_EXCEPTION未处理异常在调试循环内、遇到调试器自身未处理的异常时触发时序位于设置继续状态continue status之后、调试器锁定暂停之后struct PLUG_CB_EXCEPTION { EXCEPTION_DEBUG_INFO* Exception; // 异常调试信息winnt.h };EXCEPTION_DEBUG_INFO含pExceptionRecordEXCEPTION_RECORD异常代码、地址、参数与dwFirstChance是否首次机会异常。注意这里的“unhandled (by the debugger)”指该异常未被调试器的内部异常处理机制接管因此这是异常分析插件如记录EXCEPTION_ACCESS_VIOLATION的地址与调用栈的核心挂载点。PLUG_CB_OUTPUTDEBUGSTRINGOutputDebugString 输出在调试循环内、收到DebugString事件即目标进程调用OutputDebugString/OutputDebugStringW时触发时序位于将该字符串转储到日志之前、因调试字符串而暂停之前struct PLUG_CB_OUTPUTDEBUGSTRING { OUTPUT_DEBUG_STRING_INFO* DebugString; // 调试字符串信息winnt.h };OUTPUT_DEBUG_STRING_INFO包含lpDebugStringData字符串指针、fUnicode是否 Unicode、nDebugStringLength长度。由于回调发生在写入日志之前插件可以在此截获、改写甚至过滤目标进程的调试输出是日志分析类插件的理想接入点。六、GUI 事件回调菜单、Windows 消息这组回调运行在 GUI 线程上下文处理插件菜单与 Qt 消息分发。PLUG_CB_MENUENTRY插件菜单点击插件通过_plugin_menuaddentry创建的菜单项被点击时触发GUI 会在本回调返回后恢复struct PLUG_CB_MENUENTRY { int hEntry; // 被点击菜单项的句柄 };hEntry是创建菜单项时返回的句柄回调内根据它分发到对应动作。由于 GUI 会阻塞等待回调返回这里同样不宜做长耗时操作耗时工作应派发到工作线程回调本身立即返回。PLUG_CB_WINEVENT窗口消息预处理在 Qt 的TranslateMessage和DispatchMessage之前即 PreTranslateMessage 阶段触发struct PLUG_CB_WINEVENT { MSG* message; // Windows 消息 long* result; // 消息处理结果 bool retval; // 仅当你希望 Qt 忽略该事件时置为 true };messageMSG结构含窗口句柄、消息号、wParam/lParam 等。result指向消息处理结果的长整型指针。retval置为true可让 Qt 忽略该事件否则保持false。官方文档特别警告在此回调中调用 user32 函数要格外小心处理不当会造成递归调用因为回调本身就在消息分发路径上。这是实现全局快捷键捕获、鼠标/键盘事件监听的关键接口。PLUG_CB_WINEVENTGLOBAL全局消息预处理同样在 PreTranslateMessage 阶段触发但作用域是全局的因此也能捕获快捷键见 Qt 文档。在 Qt5 中这个函数几乎不会被调用官方建议改用PLUG_CB_WINEVENT见 plugcbwineventglobal.rst 中“In Qt5 this function is almost never called”的说明struct PLUG_CB_WINEVENTGLOBAL { MSG* message; // Windows 消息 bool retval; // 仅当你希望 Qt 忽略该事件时置为 true };与PLUG_CB_WINEVENT相比它没有result成员。如果你面向 Qt5 开发请优先使用PLUG_CB_WINEVENT该结构保留主要是为兼容历史行为。七、数据持久化、符号过滤与条件追踪回调这一组回调赋予插件与调试器“数据库系统”和“符号系统”深度协作的能力。PLUG_CB_LOADSAVEDB插件数据持久化调试器的数据库加载/保存流程会调用本回调插件可借此把自己的数据随调试数据库一起以 JSON 格式存取struct PLUG_CB_LOADSAVEDB { json_t* root; // jansson JSON 根节点 int loadSaveType; // 加载/保存类型 };rootjansson 库项目内置于 src/dbg/jansson的json_t*根节点。加载时从中读取插件数据保存时向其中写入插件数据。loadSaveType取值为 _plugins.h 定义的两个常量PLUG_DB_LOADSAVE_DATA值为 1仅处理插件数据本身。PLUG_DB_LOADSAVE_ALL值为 2处理全部数据。回调由CB_LOADDB加载数据库与CB_SAVEDB保存数据库两个事件共用同一个PLUG_CB_LOADSAVEDB结构插件依据loadSaveType与当前是加载还是保存流程来读写root。这是实现“插件设置/断点注释随数据库文件持久化”的标准途径——例如把插件收集的标签、注释或自定义配置挂到root下的独立 JSON 键中随数据库一起被 database.cpp 的加载保存流程持久化。PLUG_CB_FILTERSYMBOL符号过滤在符号被发射到自动标签automatic labels之前触发。将retval置为false即可过滤掉该符号struct PLUG_CB_FILTERSYMBOL { const char* symbol; // 待发射的符号名 bool retval; // 置 false 以过滤该符号默认应保持 true };自动标签是调试器为模块地址自动生成的符号化名称。利用此回调插件可以实现“符号黑名单”——把噪声大、无意义的符号如编译器内部符号、重复的 stub 符号从自动标签中剔除从而净化反汇编视图。注意symbol指针同样只在回调作用域内有效。PLUG_CB_TRACEEXECUTE条件追踪控制条件追踪conditional tracing执行期间逐条触发插件可通过置位stop成员终止追踪struct PLUG_CB_TRACEEXECUTE { duint cip; // 当前指令指针current instruction pointer bool stop; // 置 true 以停止追踪 };duint是 x64dbg 的地址类型x64 下为 64 位无符号整数见 dbg_types.h。cip给出当前正在执行的指令地址插件可以在追踪循环中检查cip是否落入感兴趣的范围如某函数的边界一旦满足条件就置stop true让追踪提前终止。相比在追踪命令中使用表达式条件这提供了完全编程化的终止判定能力是“追踪直到满足任意复杂条件”的实现基础。八、实战示例一个同时订阅多个事件的插件回调结合前文下面给出一个完整可编译的注册与分发骨架演示如何使用bType在一个CBPLUGIN函数内处理多个事件并遵守“回调内轻量、数据深拷贝”的约束#include _plugins.h #include stdio.h // 全局保存的主模块信息在回调内深拷贝回调外使用 static duint g_mainBase 0; static char g_targetPath[MAX_PATH] { 0 }; static void CBPLUGIN myCallback(CBTYPE bType, void* callbackInfo) { switch (bType) { case CB_INITDEBUG: { // 会话开始记录目标路径 PLUG_CB_INITDEBUG* info (PLUG_CB_INITDEBUG*)callbackInfo; if (info-szFileName) strncpy(g_targetPath, info-szFileName, MAX_PATH - 1); break; } case CB_CREATEPROCESS: { // 进程就绪记录主模块基址深拷贝勿保存指针本身 PLUG_CB_CREATEPROCESS* info (PLUG_CB_CREATEPROCESS*)callbackInfo; if (info-CreateProcessInfo) g_mainBase (duint)info-CreateProcessInfo-lpBaseOfImage; break; } case CB_BREAKPOINT: { // 断点命中仅做轻量记录重活交给工作线程 PLUG_CB_BREAKPOINT* info (PLUG_CB_BREAKPOINT*)callbackInfo; if (info-breakpoint) Log(BP hit at %p\n, info-breakpoint-addr); break; } case CB_TRACEEXECUTE: { // 条件追踪命中目标范围立即停止 PLUG_CB_TRACEEXECUTE* info (PLUG_CB_TRACEEXECUTE*)callbackInfo; if (info-cip g_mainBase info-cip g_mainBase 0x1000) info-stop true; break; } case CB_STOPDEBUG: { // 会话结束清理 g_mainBase 0; g_targetPath[0] \0; break; } default: break; } } // 在 pluginit 中注册每个事件只能注册一次 _plugin_registercallback(pluginHandle, CB_INITDEBUG, myCallback); _plugin_registercallback(pluginHandle, CB_CREATEPROCESS, myCallback); _plugin_registercallback(pluginHandle, CB_BREAKPOINT, myCallback); _plugin_registercallback(pluginHandle, CB_TRACEEXECUTE, myCallback); _plugin_registercallback(pluginHandle, CB_STOPDEBUG, myCallback);要点回顾所有指针型成员szFileName、CreateProcessInfo、breakpoint在回调内要么被立即消费、要么被深拷贝绝不直接保存回调体内不做文件读写、网络请求等耗时操作CB_TRACEEXECUTE通过写回stop字段实现追踪控制。九、小结回调结构速查回调结构触发时机关键成员PLUG_CB_INITDEBUG调试初始化szFileNamePLUG_CB_STOPDEBUG调试停止reservedPLUG_CB_ATTACH附加前dwProcessIdPLUG_CB_DETACH分离前fdProcessInfoPLUG_CB_CREATEPROCESS进程创建完成基址、模块信息、进程信息PLUG_CB_EXITPROCESS进程退出后ExitProcess退出码PLUG_CB_CREATETHREAD线程创建后CreateThread、dwThreadIdPLUG_CB_EXITTHREAD线程终止后ExitThread、dwThreadIdPLUG_CB_LOADDLLDLL 加载后基址、modInfo、modnamePLUG_CB_UNLOADDLLDLL 卸载前UnloadDllPLUG_CB_SYSTEMBREAKPOINT系统断点reservedPLUG_CB_BREAKPOINT断点命中BRIDGEBP* breakpointPLUG_CB_STEPPED单步完成reservedPLUG_CB_PAUSEDEBUG调试器暂停reservedPLUG_CB_RESUMEDEBUG调试器恢复循环外reservedPLUG_CB_DEBUGEVENT一切调试事件DEBUG_EVENT*PLUG_CB_EXCEPTION未处理异常ExceptionPLUG_CB_OUTPUTDEBUGSTRINGDebugString 事件DebugStringPLUG_CB_MENUENTRY插件菜单点击hEntryPLUG_CB_WINEVENTQt 消息预处理MSG*、result、retvalPLUG_CB_WINEVENTGLOBAL全局消息预处理Qt5 几乎不调用MSG*、retvalPLUG_CB_LOADSAVEDB数据库加载/保存json_t* root、loadSaveTypePLUG_CB_FILTERSYMBOL符号发射前symbol、retvalPLUG_CB_TRACEEXECUTE条件追踪期间cip、stop所有回调结构的权威定义均可在 _plugins.h 中查到事件枚举在 _plugins.h 附近插件类型与基础宏则位于 _plugin_types.h。进一步查阅各回调的独立文档可前往 docs/developers/plugins/Callbacks 目录如 plugcbwinevent.rst、plugcbexception.rst 等注册 API 的完整说明见 registercallback.rst。掌握这 24 个回调结构你就拥有了在 x64dbg 全生命周期事件流中精准挂钩的能力无论是断点统计、符号过滤、条件追踪还是数据持久化都能找到对应的官方接入点。【免费下载链接】x64dbgAn open-source user mode debugger for Windows. Optimized for reverse engineering and malware analysis.项目地址: https://gitcode.com/gh_mirrors/x6/x64dbg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
x64dbg 插件 SDK 回调结构完全指南：从事件注册到 24 个回调结构的源码级详解
x64dbg 插件 SDK 回调结构完全指南从事件注册到 24 个回调结构的源码级详解【免费下载链接】x64dbgAn open-source user mode debugger for Windows. Optimized for reverse engineering and malware analysis.项目地址: https://gitcode.com/gh_mirrors/x6/x64dbgx64dbg 的插件 SDK 通过事件回调机制把调试器内部的状态变化进程/线程/DLL 的创建与销毁、断点命中、异常、单步、暂停/恢复等以结构化信息的形式交给插件处理。本文以官方插件文档 Callbacks/index.rst 为骨架逐一剖析 SDK 中全部 24 个回调结构PLUG_CB_*的触发时机、成员含义与实战用法并结合 _plugins.h 源码确认结构定义与事件枚举的真实形态。读完本文你将能够正确注册事件回调、按生命周期精准订阅感兴趣的调试事件、在自己的插件里安全地消费回调信息并借助PLUG_CB_LOADSAVEDB实现插件数据的持久化。一、回调机制总览CBPLUGIN签名与_plugin_registercallbackx64dbg 插件 SDK 中所有事件回调共享同一个函数类型CBPLUGIN。它的定义官方文档原样给出如下void CBPLUGIN( CBTYPE bType, // event type事件类型当同一函数服务于多个事件时用来区分 void* callbackInfo // 指向信息结构的指针具体类型见下文各 PLUG_CB_* 结构 );第一个参数bType是事件类型枚举CBTYPE第二个参数callbackInfo则指向与该事件对应的信息结构。在 _plugins.h 的_PLUGINS_H头文件中可以找到完整的枚举定义每个枚举值都对应一个PLUG_CB_*结构事件类型CBTYPE回调信息结构CB_INITDEBUGPLUG_CB_INITDEBUG*CB_STOPDEBUGPLUG_CB_STOPDEBUG*CB_CREATEPROCESSPLUG_CB_CREATEPROCESS*CB_EXITPROCESSPLUG_CB_EXITPROCESS*CB_CREATETHREADPLUG_CB_CREATETHREAD*CB_EXITTHREADPLUG_CB_EXITTHREAD*CB_SYSTEMBREAKPOINTPLUG_CB_SYSTEMBREAKPOINT*CB_LOADDLLPLUG_CB_LOADDLL*CB_UNLOADDLLPLUG_CB_UNLOADDLL*CB_OUTPUTDEBUGSTRINGPLUG_CB_OUTPUTDEBUGSTRING*CB_EXCEPTIONPLUG_CB_EXCEPTION*CB_BREAKPOINTPLUG_CB_BREAKPOINT*CB_PAUSEDEBUGPLUG_CB_PAUSEDEBUG*CB_RESUMEDEBUGPLUG_CB_RESUMEDEBUG*CB_STEPPEDPLUG_CB_STEPPED*CB_ATTACHPLUG_CB_ATTACHED*即PLUG_CB_ATTACH见注释CB_DETACHPLUG_CB_DETACHED*即PLUG_CB_DETACHCB_DEBUGEVENTPLUG_CB_DEBUGEVENT*CB_MENUENTRYPLUG_CB_MENUENTRY*CB_WINEVENTPLUG_CB_WINEVENT*CB_WINEVENTGLOBALPLUG_CB_WINEVENTGLOBAL*CB_LOADDB/CB_SAVEDBPLUG_CB_LOADSAVEDB*CB_FILTERSYMBOLPLUG_CB_FILTERSYMBOL*CB_TRACEEXECUTEPLUG_CB_TRACEEXECUTE*注册回调_plugin_registercallback回调的注册入口是 _plugin_registercallback其完整签名如下void _plugin_registercallback( int pluginHandle, // 插件句柄 CBTYPE cbType, // 事件类型 CBPLUGIN cbPlugin // 回调函数 );三个参数的语义pluginHandle调用方插件的句柄在pluginit中由调试器提供位于PLUG_INITSTRUCT.pluginHandle。cbType要订阅的事件类型取值为上表中的任意CB_*常量。cbPlugin满足CBPLUGIN签名的回调函数指针。该函数没有返回值。官方文档明确指出每个插件可以针对每个事件注册自己的回调但同一个事件上不能注册多个回调“It is not possible to have multiple callbacks on the same event”。因此若你希望在一个回调函数里处理多个事件应当利用CBPLUGIN的第一个参数bType在函数内部做分发下文示例会演示这种做法。回调使用三条铁律官方文档 Callbacks/index.rst 在开篇强调了三条硬性约束这是写出健壮插件的前提callbackInfo指针永远不会是NULL但结构内部的成员可能是NULL。例如PLUG_CB_LOADDLL中的modInfo在符号信息不可用时即为NULL解引用前必须判空。回调中拿到的任何指针都不能逃逸出回调函数作用域。这些指针指向调试器内部缓冲区回调返回后即失效如需长期保存数据必须深拷贝。回调内原则上禁止耗时操作请放到独立线程中执行。多数回调在调试主循环debug loop内被同步调用阻塞它们会直接拖慢调试器PLUG_CB_DEBUGEVENT的文档甚至单独加粗警告“这会严重拖慢调试器”。另外从源码角度补充一个细节_plugins.h 在定义这些结构前使用了#pragma pack(push, ...)强制结构对齐——x64 构建按 16 字节对齐x86 构建按 8 字节对齐。这意味着插件必须以与调试器一致的架构编译避免因结构布局不一致导致读取错位。二、调试会话生命周期回调这一组回调覆盖了“开始调试 → 附加/创建进程 → 停止调试”的完整生命周期是插件初始化与清理内部状态的天然挂载点。PLUG_CB_INITDEBUG调试初始化每次调试会话初始化时触发官方用途是初始化插件内部变量。其结构只有一个成员struct PLUG_CB_INITDEBUG { const char* szFileName; // 被调试的可执行文件路径 };szFileName携带即将被调试的目标文件路径可用来按目标文件区分不同的调试会话例如为不同程序准备不同的分析配置。该回调的典型场景是把插件维护的会话级状态清零、记录目标文件名。需要注意附加调试attach场景下该回调同样会触发此时szFileName为被附加进程的主模块路径。PLUG_CB_STOPDEBUG调试停止调试会话结束时触发官方用途是重置插件变量与CB_INITDEBUG成对出现struct PLUG_CB_STOPDEBUG { void* reserved; // 保留字段恒为 NULL勿使用 };该结构只有一个reserved占位成员没有任何可消费的数据纯粹作为生命周期信号使用。在源码 _plugins.h 中同样如此定义。此外源码中还存在一个未在 toctree 中列出的PLUG_CB_STOPPINGDEBUG_plugins.h表示“正在停止调试”的中间状态可供对时序更敏感的插件参考。PLUG_CB_ATTACH附加进程之前在附加到目标进程之前调用结构提供目标进程的 PIDstruct PLUG_CB_ATTACH { DWORD dwProcessId; // 即将附加的进程 ID };注意事件枚举注释中写的是“before attaching, after CB_INITDEBUG”即附加场景下时序为先CB_INITDEBUG再CB_ATTACH。插件可以在此回调中根据dwProcessId预置针对特定进程的分析状态。PLUG_CB_DETACH分离进程之前在从目标进程分离之前调用struct PLUG_CB_DETACH { PROCESS_INFORMATION* fdProcessInfo; // 进程信息句柄与 ID };fdProcessInfo指向PROCESS_INFORMATION其中包含被分离进程的句柄hProcess与进程/线程 ID可用于在分离前执行最后的清理动作例如关闭自己打开的目标进程句柄。PLUG_CB_CREATEPROCESS进程创建完成在调试循环内、进程创建之后触发触发时机非常精确位于符号处理器symbol handler初始化之后、数据库文件加载之后、以及在 TLS 回调 / 入口断点上设置断点之后。也就是说插件在此回调中看到的已经是一个“符号就绪、断点就位”的进程struct PLUG_CB_CREATEPROCESS { CREATE_PROCESS_DEBUG_INFO* CreateProcessInfo; // Windows SDK 进程创建调试信息 IMAGEHLP_MODULE64* modInfo; // 主模块的符号信息可为 NULL const char* DebugFileName; // 被调试文件名 PROCESS_INFORMATION* fdProcessInfo; // 进程信息 };四个成员的用途CreateProcessInfoCREATE_PROCESS_DEBUG_INFOwinnt.h包含hFile主模块映像句柄、hProcess、hThread、lpBaseOfImage映像基址等。modInfoIMAGEHLP_MODULE64dbghelp.h主模块的符号路径、基址、大小等符号不可用时为NULL。DebugFileName被调试文件路径等价于PLUG_CB_INITDEBUG.szFileName。fdProcessInfoPROCESS_INFORMATION进程与初始线程的句柄/ID。这是插件获取主模块基址和PE 头的最佳时机很多反混淆、API 跟踪类插件都在这里记录lpBaseOfImage。PLUG_CB_EXITPROCESS进程退出在调试循环内、进程退出之后触发时序在符号处理器被清理之前因此此时符号仍可用struct PLUG_CB_EXITPROCESS { EXIT_PROCESS_DEBUG_INFO* ExitProcess; // 退出码信息winnt.h };EXIT_PROCESS_DEBUG_INFO只有一个成员DWORD dwExitCode即进程退出码。插件可以在此回调中做最终的统计收尾如汇总本次会话的断点命中次数并写日志因为符号尚在还能做最后的地址→符号翻译。三、线程与模块回调线程和 DLL 的创建/销毁是动态分析中最常见的事件流这组回调给出了每个事件的精确挂载点。PLUG_CB_CREATETHREAD / PLUG_CB_EXITTHREAD线程创建回调的触发时机是在调试循环内、线程被加入调试器内部线程列表之后、调试器因线程创建而暂停之前、线程入口断点设置之后struct PLUG_CB_CREATETHREAD { CREATE_THREAD_DEBUG_INFO* CreateThread; // 线程创建调试信息winnt.h DWORD dwThreadId; // 新线程 ID };CREATE_THREAD_DEBUG_INFO包含hThread、lpThreadLocalBaseTEB 基址和lpStartAddress线程起始地址。dwThreadId则直接给出新线程的 ID方便与后续该线程的所有事件关联。线程退出回调的触发时机是在调试循环内、线程终止之后、线程从内部线程列表移除之前、因线程终止而暂停之前struct PLUG_CB_EXITTHREAD { EXIT_THREAD_DEBUG_INFO* ExitThread; // 线程退出调试信息winnt.h DWORD dwThreadId; // 退出的线程 ID };EXIT_THREAD_DEBUG_INFO携带dwExitCode线程退出码。插件可在CB_EXITTHREAD中完成对该线程私有数据的清理——由于此时线程尚未从列表移除仍能查询线程上下文。PLUG_CB_LOADDLL / PLUG_CB_UNLOADDLLDLL 加载回调的触发时机是在调试循环内、DLL 被加入内部库列表之后、DLL 入口断点设置之后struct PLUG_CB_LOADDLL { LOAD_DLL_DEBUG_INFO* LoadDll; // DLL 加载调试信息winnt.h IMAGEHLP_MODULE64* modInfo; // 该模块的符号信息可为 NULL const char* modname; // 模块名路径 };LoadDllLOAD_DLL_DEBUG_INFO含hFile模块映像句柄与lpBaseOfDll模块加载基址。modInfo该模块的符号信息未加载符号时为NULL。modname模块路径字符串注意它与LoadDll中的字段可能来自不同来源以modname为准可避免因映像路径与磁盘路径不一致导致的混淆。DLL 卸载回调的触发时机是在调试循环内、DLL 从内部库列表移除之前、因卸载而暂停之前struct PLUG_CB_UNLOADDLL { UNLOAD_DLL_DEBUG_INFO* UnloadDll; // DLL 卸载调试信息winnt.h };UNLOAD_DLL_DEBUG_INFO携带lpBaseOfDll据此可以从插件的模块表中移除对应记录。注意卸载回调发生在“移除之前”意味着此时还能通过基址在内部库列表里找到该模块并做最后的数据收集。四、断点、单步与暂停/恢复状态回调这组回调反映调试器执行状态的核心切换是条件断点、步进跟踪类插件的核心依赖。PLUG_CB_SYSTEMBREAKPOINT系统断点在调试循环内、命中系统断点时触发时序位于设置初始 dump 位置initial dump location之后、调试器在系统断点处暂停之前struct PLUG_CB_SYSTEMBREAKPOINT { void* reserved; // 保留字段 };系统断点system breakpoint / entry breakpoint是调试器接管目标进程后命中的第一个可控断点此刻系统 DLLntdll.dll等已加载、进程环境已就绪。虽然结构本身没有数据成员但它标志着“调试会话真正开始”适合在此处执行需要进程上下文的一揽子初始化。PLUG_CB_BREAKPOINT断点命中在调试循环内、普通软件断点、内存断点或硬件断点命中时触发时序位于调试器锁定暂停之后struct PLUG_CB_BREAKPOINT { BRIDGEBP* breakpoint; // 桥接层断点结构 };BRIDGEBP是桥接层bridge定义的断点描述结构位于 src/bridge 目录的桥接头文件中包含断点地址、类型软件/内存/硬件、命中次数等信息。这是实现“断点命中后自动记录寄存器/栈数据”类功能的主入口。由于触发时调试器已锁定暂停回调中读取寄存器、内存都是安全的。PLUG_CB_STEPPED单步完成在调试循环内、调试器完成一次单步之后触发同样位于锁定暂停之后struct PLUG_CB_STEPPED { void* reserved; // 保留字段 };该回调没有数据成员需要寄存器或当前指令信息时可在回调内通过 SDK 的寄存器/反汇编接口自行获取。它是构建步进级跟踪器step tracer的基础事件。PLUG_CB_PAUSEDEBUG暂停在调试循环内、调试器已锁定暂停之后触发且早于所有其他“暂停前”回调struct PLUG_CB_PAUSEDEBUG { void* reserved; // 保留字段 };它是最先被派发的暂停信号适合做全局性的“进入暂停态”标记如刷新插件 UI 上的状态指示。PLUG_CB_RESUMEDEBUG恢复在调试循环之外outside of the debug loop、调试器解锁恢复之后触发struct PLUG_CB_RESUMEDEBUG { void* reserved; // 保留字段 };注意它与前面几个回调的上下文差异CB_RESUMEDEBUG明确不在调试循环内执行。这是整个回调体系中少数几个“循环外”回调之一可安全地在此启动异步任务如预取下一次断点命中所需的数据不必担心阻塞调试事件分发。五、调试事件回调DEBUGEVENT、EXCEPTION 与 OUTPUTDEBUGSTRINGPLUG_CB_DEBUGEVENT一切调试事件任何调试事件都会触发本回调包括那些被调试器内部处理不暂停的事件。这是最底层的观察窗口struct PLUG_CB_DEBUGEVENT { DEBUG_EVENT* DebugEvent; // Windows SDK 原始调试事件 };DEBUG_EVENTwinnt.h包含dwDebugEventCode事件代码、dwProcessId、dwThreadId以及按事件类型联合的u成员。官方文档对本回调给出了最严厉的警告“避免在这里做任何耗时的事情这会严重拖慢调试器”因为每个事件包括LOAD_DLL_DEBUG_EVENT、OUTPUT_DEBUG_STRING_EVENT、EXCEPTION_DEBUG_EVENT等所有代码都会经过它任何多余计算都会被放大到每个调试事件上。需要全量事件流的场景如事件统计插件应在此只做轻量记录重活交给独立线程。PLUG_CB_EXCEPTION未处理异常在调试循环内、遇到调试器自身未处理的异常时触发时序位于设置继续状态continue status之后、调试器锁定暂停之后struct PLUG_CB_EXCEPTION { EXCEPTION_DEBUG_INFO* Exception; // 异常调试信息winnt.h };EXCEPTION_DEBUG_INFO含pExceptionRecordEXCEPTION_RECORD异常代码、地址、参数与dwFirstChance是否首次机会异常。注意这里的“unhandled (by the debugger)”指该异常未被调试器的内部异常处理机制接管因此这是异常分析插件如记录EXCEPTION_ACCESS_VIOLATION的地址与调用栈的核心挂载点。PLUG_CB_OUTPUTDEBUGSTRINGOutputDebugString 输出在调试循环内、收到DebugString事件即目标进程调用OutputDebugString/OutputDebugStringW时触发时序位于将该字符串转储到日志之前、因调试字符串而暂停之前struct PLUG_CB_OUTPUTDEBUGSTRING { OUTPUT_DEBUG_STRING_INFO* DebugString; // 调试字符串信息winnt.h };OUTPUT_DEBUG_STRING_INFO包含lpDebugStringData字符串指针、fUnicode是否 Unicode、nDebugStringLength长度。由于回调发生在写入日志之前插件可以在此截获、改写甚至过滤目标进程的调试输出是日志分析类插件的理想接入点。六、GUI 事件回调菜单、Windows 消息这组回调运行在 GUI 线程上下文处理插件菜单与 Qt 消息分发。PLUG_CB_MENUENTRY插件菜单点击插件通过_plugin_menuaddentry创建的菜单项被点击时触发GUI 会在本回调返回后恢复struct PLUG_CB_MENUENTRY { int hEntry; // 被点击菜单项的句柄 };hEntry是创建菜单项时返回的句柄回调内根据它分发到对应动作。由于 GUI 会阻塞等待回调返回这里同样不宜做长耗时操作耗时工作应派发到工作线程回调本身立即返回。PLUG_CB_WINEVENT窗口消息预处理在 Qt 的TranslateMessage和DispatchMessage之前即 PreTranslateMessage 阶段触发struct PLUG_CB_WINEVENT { MSG* message; // Windows 消息 long* result; // 消息处理结果 bool retval; // 仅当你希望 Qt 忽略该事件时置为 true };messageMSG结构含窗口句柄、消息号、wParam/lParam 等。result指向消息处理结果的长整型指针。retval置为true可让 Qt 忽略该事件否则保持false。官方文档特别警告在此回调中调用 user32 函数要格外小心处理不当会造成递归调用因为回调本身就在消息分发路径上。这是实现全局快捷键捕获、鼠标/键盘事件监听的关键接口。PLUG_CB_WINEVENTGLOBAL全局消息预处理同样在 PreTranslateMessage 阶段触发但作用域是全局的因此也能捕获快捷键见 Qt 文档。在 Qt5 中这个函数几乎不会被调用官方建议改用PLUG_CB_WINEVENT见 plugcbwineventglobal.rst 中“In Qt5 this function is almost never called”的说明struct PLUG_CB_WINEVENTGLOBAL { MSG* message; // Windows 消息 bool retval; // 仅当你希望 Qt 忽略该事件时置为 true };与PLUG_CB_WINEVENT相比它没有result成员。如果你面向 Qt5 开发请优先使用PLUG_CB_WINEVENT该结构保留主要是为兼容历史行为。七、数据持久化、符号过滤与条件追踪回调这一组回调赋予插件与调试器“数据库系统”和“符号系统”深度协作的能力。PLUG_CB_LOADSAVEDB插件数据持久化调试器的数据库加载/保存流程会调用本回调插件可借此把自己的数据随调试数据库一起以 JSON 格式存取struct PLUG_CB_LOADSAVEDB { json_t* root; // jansson JSON 根节点 int loadSaveType; // 加载/保存类型 };rootjansson 库项目内置于 src/dbg/jansson的json_t*根节点。加载时从中读取插件数据保存时向其中写入插件数据。loadSaveType取值为 _plugins.h 定义的两个常量PLUG_DB_LOADSAVE_DATA值为 1仅处理插件数据本身。PLUG_DB_LOADSAVE_ALL值为 2处理全部数据。回调由CB_LOADDB加载数据库与CB_SAVEDB保存数据库两个事件共用同一个PLUG_CB_LOADSAVEDB结构插件依据loadSaveType与当前是加载还是保存流程来读写root。这是实现“插件设置/断点注释随数据库文件持久化”的标准途径——例如把插件收集的标签、注释或自定义配置挂到root下的独立 JSON 键中随数据库一起被 database.cpp 的加载保存流程持久化。PLUG_CB_FILTERSYMBOL符号过滤在符号被发射到自动标签automatic labels之前触发。将retval置为false即可过滤掉该符号struct PLUG_CB_FILTERSYMBOL { const char* symbol; // 待发射的符号名 bool retval; // 置 false 以过滤该符号默认应保持 true };自动标签是调试器为模块地址自动生成的符号化名称。利用此回调插件可以实现“符号黑名单”——把噪声大、无意义的符号如编译器内部符号、重复的 stub 符号从自动标签中剔除从而净化反汇编视图。注意symbol指针同样只在回调作用域内有效。PLUG_CB_TRACEEXECUTE条件追踪控制条件追踪conditional tracing执行期间逐条触发插件可通过置位stop成员终止追踪struct PLUG_CB_TRACEEXECUTE { duint cip; // 当前指令指针current instruction pointer bool stop; // 置 true 以停止追踪 };duint是 x64dbg 的地址类型x64 下为 64 位无符号整数见 dbg_types.h。cip给出当前正在执行的指令地址插件可以在追踪循环中检查cip是否落入感兴趣的范围如某函数的边界一旦满足条件就置stop true让追踪提前终止。相比在追踪命令中使用表达式条件这提供了完全编程化的终止判定能力是“追踪直到满足任意复杂条件”的实现基础。八、实战示例一个同时订阅多个事件的插件回调结合前文下面给出一个完整可编译的注册与分发骨架演示如何使用bType在一个CBPLUGIN函数内处理多个事件并遵守“回调内轻量、数据深拷贝”的约束#include _plugins.h #include stdio.h // 全局保存的主模块信息在回调内深拷贝回调外使用 static duint g_mainBase 0; static char g_targetPath[MAX_PATH] { 0 }; static void CBPLUGIN myCallback(CBTYPE bType, void* callbackInfo) { switch (bType) { case CB_INITDEBUG: { // 会话开始记录目标路径 PLUG_CB_INITDEBUG* info (PLUG_CB_INITDEBUG*)callbackInfo; if (info-szFileName) strncpy(g_targetPath, info-szFileName, MAX_PATH - 1); break; } case CB_CREATEPROCESS: { // 进程就绪记录主模块基址深拷贝勿保存指针本身 PLUG_CB_CREATEPROCESS* info (PLUG_CB_CREATEPROCESS*)callbackInfo; if (info-CreateProcessInfo) g_mainBase (duint)info-CreateProcessInfo-lpBaseOfImage; break; } case CB_BREAKPOINT: { // 断点命中仅做轻量记录重活交给工作线程 PLUG_CB_BREAKPOINT* info (PLUG_CB_BREAKPOINT*)callbackInfo; if (info-breakpoint) Log(BP hit at %p\n, info-breakpoint-addr); break; } case CB_TRACEEXECUTE: { // 条件追踪命中目标范围立即停止 PLUG_CB_TRACEEXECUTE* info (PLUG_CB_TRACEEXECUTE*)callbackInfo; if (info-cip g_mainBase info-cip g_mainBase 0x1000) info-stop true; break; } case CB_STOPDEBUG: { // 会话结束清理 g_mainBase 0; g_targetPath[0] \0; break; } default: break; } } // 在 pluginit 中注册每个事件只能注册一次 _plugin_registercallback(pluginHandle, CB_INITDEBUG, myCallback); _plugin_registercallback(pluginHandle, CB_CREATEPROCESS, myCallback); _plugin_registercallback(pluginHandle, CB_BREAKPOINT, myCallback); _plugin_registercallback(pluginHandle, CB_TRACEEXECUTE, myCallback); _plugin_registercallback(pluginHandle, CB_STOPDEBUG, myCallback);要点回顾所有指针型成员szFileName、CreateProcessInfo、breakpoint在回调内要么被立即消费、要么被深拷贝绝不直接保存回调体内不做文件读写、网络请求等耗时操作CB_TRACEEXECUTE通过写回stop字段实现追踪控制。九、小结回调结构速查回调结构触发时机关键成员PLUG_CB_INITDEBUG调试初始化szFileNamePLUG_CB_STOPDEBUG调试停止reservedPLUG_CB_ATTACH附加前dwProcessIdPLUG_CB_DETACH分离前fdProcessInfoPLUG_CB_CREATEPROCESS进程创建完成基址、模块信息、进程信息PLUG_CB_EXITPROCESS进程退出后ExitProcess退出码PLUG_CB_CREATETHREAD线程创建后CreateThread、dwThreadIdPLUG_CB_EXITTHREAD线程终止后ExitThread、dwThreadIdPLUG_CB_LOADDLLDLL 加载后基址、modInfo、modnamePLUG_CB_UNLOADDLLDLL 卸载前UnloadDllPLUG_CB_SYSTEMBREAKPOINT系统断点reservedPLUG_CB_BREAKPOINT断点命中BRIDGEBP* breakpointPLUG_CB_STEPPED单步完成reservedPLUG_CB_PAUSEDEBUG调试器暂停reservedPLUG_CB_RESUMEDEBUG调试器恢复循环外reservedPLUG_CB_DEBUGEVENT一切调试事件DEBUG_EVENT*PLUG_CB_EXCEPTION未处理异常ExceptionPLUG_CB_OUTPUTDEBUGSTRINGDebugString 事件DebugStringPLUG_CB_MENUENTRY插件菜单点击hEntryPLUG_CB_WINEVENTQt 消息预处理MSG*、result、retvalPLUG_CB_WINEVENTGLOBAL全局消息预处理Qt5 几乎不调用MSG*、retvalPLUG_CB_LOADSAVEDB数据库加载/保存json_t* root、loadSaveTypePLUG_CB_FILTERSYMBOL符号发射前symbol、retvalPLUG_CB_TRACEEXECUTE条件追踪期间cip、stop所有回调结构的权威定义均可在 _plugins.h 中查到事件枚举在 _plugins.h 附近插件类型与基础宏则位于 _plugin_types.h。进一步查阅各回调的独立文档可前往 docs/developers/plugins/Callbacks 目录如 plugcbwinevent.rst、plugcbexception.rst 等注册 API 的完整说明见 registercallback.rst。掌握这 24 个回调结构你就拥有了在 x64dbg 全生命周期事件流中精准挂钩的能力无论是断点统计、符号过滤、条件追踪还是数据持久化都能找到对应的官方接入点。【免费下载链接】x64dbgAn open-source user mode debugger for Windows. Optimized for reverse engineering and malware analysis.项目地址: https://gitcode.com/gh_mirrors/x6/x64dbg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考