DLL to C：无头文件DLL导出表转C绑定代码

简介DLL to C v2.42 面向从事逆向分析、遗留代码维护与 C/C 二次开发的工程师用于在丢失 DLL 源码时把二进制模块还原为可编译的 C/C 工程并输出各数据段的结构定义减少只能靠调试器硬啃汇编的麻烦。工具支持代码段反汇编以及结构模式、完整结构模式、注释模式、精确模式等多种拆解方式导入地址表可选择动态、静态或直接地址初始化便于按目标程序特点灵活取舍。压缩包约 1.1MB共 110 个文件主体是 40 个 cpp 源文件与 36 个头文件并配有 9 份 txt 说明、7 个 sln 和 7 个 vcproj 工程配置另有少量 png 截图、dll、rc 资源脚本、exe 与 htm 页面可直接用 Visual Studio 打开对照调试。目前已有 698 人学习下载适合需要还原接口、复现数据结构或研究反汇编输出组织方式的读者参考。1. 一个 DLL 发送过来却没有头文件DLL to C 能提供哪些帮助上周又被问到一个老问题客户只提供了一个xxx.dll没有头文件、没有.lib、没有文档导出的函数原型全靠猜而项目必须在 C/C 工程里调用它。这类情况在接第三方组件、维护老旧应用软件、给遗留插件补接口时反复出现。DLL to C v2.42 就是专门处理这个问题的它读取 DLL 的导出目录把每个导出函数转换成可以编译的 C 源码运行时通过LoadLibrary/GetProcAddress把函数指针绑定上去调用方式和静态链接几乎一样。它不做反编译也不还原内部逻辑只解决一件事让函数能被正确调用。适合手里有 DLL、拿不到开发包又必须在自己的工程里调用它的人。2. 先看懂 PE 导出表DLL to C 生成的到底是什么东西要判断生成结果是否可用得先知道它读取的是什么。生成器本身不包含任何“理解” DLL 的能力它只是把 PE 文件导出目录里的三张表翻译成 C 声明。这三张表理解清楚了后面所有“明明有导出却绑不上”“绑上了但一调就崩”的问题都能自己定位。2.1 导出目录里的三张表与一次对齐PE 的可选头里有 16 个数据目录项第 0 项指向导出目录结构里关键是这几个字段Base起始序号通常从 1 开始、NumberOfFunctions函数 RVA 数组长度、NumberOfNames名字表长度、AddressOfFunctionsRVA 数组、AddressOfNames名字字符串 RVA 数组按字典序排好、AddressOfNameOrdinals名字索引到函数索引的桥。注意NumberOfFunctions和NumberOfNames常常不相等差值就是“只有序号、没有名字”的导出。生成器做的第一件事就是把这三张表按索引对齐遍历名字表拿到名字用名字表下标去AddressOfNameOrdinals拿到函数索引再用索引去AddressOfFunctions拿到 RVA最终序号是Base 索引。对齐完成之后得到一张表格每行是三个值名字、序号、RVA。这一步自己验证一遍后面排查问题时会省很多时间。常见做法是用 PE 导出查看器把名字单独导出来和生成的头文件逐行比对# 只保留 序号 / hint / RVA / 名字 四列都存在的行取最后一列名字 dumpbin /exports bin/demo_plugin.dll \ | awk NF4 $1 ~ /^[0-9]$/ {print $4} \ | sort exports_names.txt # 生成的头文件里函数指针变量的声明通常一行一个 grep -oE \bp[A-Za-z_][A-Za-z0-9_]* gen/dlltoc/demo_plugin.h \ | sed s/^p// | sort gen_names.txt # 差异就是生成器没吃进去的导出 diff exports_names.txt gen_names.txt这段脚本的逻辑很直接第一个命令过滤掉表头和无意义的行因为dumpbin的输出里只有数据行满足“四列以上且第一列是纯数字”sort是为了和后面同样排序过的结果做diff。第二个命令靠一个命名约定做近似提取p前缀是生成器给函数指针加的前缀不同版本可能不一致跑之前先打开头文件看一眼实际风格不对就换正则。参数上唯一需要注意的是 DLL 路径如果是 32 位 DLL 而你在 64 位环境的命令行里跑某些查看器会拒绝解析这时候换一个位数匹配的查看器即可。2.2 生成物的形状函数指针表加一次性绑定不管版本怎么变生成物的骨架基本固定头文件里把每个导出声明成一个函数指针类型的extern变量源文件里提供一个加载函数内部LoadLibrary之后逐个GetProcAddress填表再提供一个卸载函数。下面这段是我按生成物的常见形状手写的等价示意用来讲解结构实际变量名和函数名以工具输出为准/* demo_plugin.h —— 结构示意命名以实际生成结果为准 */ #ifndef DEMO_PLUGIN_H #define DEMO_PLUGIN_H #ifdef __cplusplus extern C { #endif /* 每个导出一个函数指针类型调用约定必须和 DLL 里一致 */ typedef int (__cdecl *PFN_Add)(int a, int b); typedef void (__stdcall *PFN_Reset)(void); extern PFN_Add pAdd; /* 调用时直接用 pAdd(1, 2) */ extern PFN_Reset pReset; /* 返回 0 表示全部绑定成功非 0 时不要调用任何函数指针 */ int DemoPlugin_Load(const char *dllPath); void DemoPlugin_Free(void); #ifdef __cplusplus } #endif #endif/* demo_plugin.c —— 绑定与解绑 */ #include windows.h #include demo_plugin.h static HMODULE g_hMod NULL; PFN_Add pAdd NULL; PFN_Reset pReset NULL; int DemoPlugin_Load(const char *dllPath) { if (g_hMod ! NULL) return 0; /* 幂等重复调用不重复加载 */ g_hMod LoadLibraryA(dllPath); if (g_hMod NULL) return -1; /* 拿 GetLastError() 看原因 */ pAdd (PFN_Add) GetProcAddress(g_hMod, Add); pReset (PFN_Reset)GetProcAddress(g_hMod, Reset); if (pAdd NULL || pReset NULL) { /* 缺一个就整体失败别带病运行 */ FreeLibrary(g_hMod); g_hMod NULL; return -2; } return 0; } void DemoPlugin_Free(void) { if (g_hMod NULL) return; pAdd NULL; pReset NULL; /* 先清指针再卸模块 */ FreeLibrary(g_hMod); g_hMod NULL; }逻辑说明强制转换(PFN_Add)是必须的GetProcAddress返回的是无类型函数指针直接赋给具体类型在 C 下编译不过。绑定失败时立刻FreeLibrary并把句柄置空是为了避免出现“模块还在但表是半填的”这种中间态。卸载函数里先清指针再卸模块顺序不能反反了就是典型的野指针来源。参数说明dllPath建议传绝对路径或者至少传相对于进程工作目录的稳定路径。传相对路径是新手最容易出错的地方——工作目录会因为快捷方式、计划任务、服务启动方式而变本地调试正常、装到别人机器上就报 126。-1和-2两个返回码拆开是为了让调用方一眼看出是“模块压根没装上”还是“模块装上了但导出对不上”这两种情况的排查方向完全不同。2.3 三条路线的取舍拿到一个没有开发包的 DLL能走的路其实只有三条选错会带来后续大量维护成本。维度静态导入.lib .h手工 GetProcAddressDLL to C 生成代码前提条件必须有 .lib 和准确原型只需要 DLL只需要 DLL缺失导出暴露时机链接期编译就报错运行期运行期加载函数返回非 0按序号导出需要自行编写 .def支持MAKEINTRESOURCE取决于生成器是否保留序号多版本 DLL 共存困难符号会冲突天然支持句柄隔离天然支持句柄隔离代码可读性最好最差几十个函数全是样板中等函数名即导出名维护成本换 DLL 要重新链接每加一个函数改一处重新生成一次即可选生成代码的理由本质上是把“链接期的确定性”换成了“生成期的确定性”。如果 DLL 版本稳定、原型明确静态导入仍然是最省事的选择但现实里更多的情况是版本半年一换、导出时增时减这时候一次重新生成比重新找 .lib 靠谱得多。代价要认所有错误都推迟到运行期所以加载函数的返回值必须当成契约来用不能忽略。3. 跑通第一次转换从体检到编译通过转换本身只要几秒钟真正花时间的是转换前的确认和转换后的接入。这三十分钟如果省掉后面会用几倍的时间在崩溃和错误码里找原因。3.1 转换前的四项体检第一项是位数。用查看器看 PE 头的 machine 字段或者在导出查看器的输出里找machine (x86)/machine (x64)这一行。32 位进程加载 64 位 DLL 会直接返回 193反过来是 126两个错误码看起来都像“找不到文件”其实跟路径毫无关系。第二项是依赖链。目标 DLL 自己可能还依赖别的 DLLLoadLibrary加载时会一并解析任何一个缺失都整体失败。依赖查看类的工具能列出直接依赖把缺失的那个一起放到同目录再试。第三项是导出可见性。有的 DLL 导出表是空的函数全在里面但不对外暴露这种无论用什么工具都转换不出东西只能换方案。第四项是语言。如果导出名是一串以?开头的乱码说明是 C 编译且没有加extern C名字被修饰过了转换器会原样保留后面绑定的时候要按修饰名去查。3.2 命令行与输出落位工具是命令行的不带参数跑一次会打印用法参数名以它自己打印的为准不要照抄别人的截图dlltoc.exe # 先看 usage确认参数名 dlltoc.exe bin/demo_plugin.dll -o gen/dlltoc # 输入 DLL输出到独立目录 ls -l gen/dlltoc # 确认 .c 和 .h 都在逻辑说明第一条命令不带参数是为了避免在参数拼错的情况下得到一个“看起来成功但输出为空”的结果。第二条把输出丢进gen/dlltoc这样一个独立目录是为了让生成物和手写代码物理隔离——生成物随时会被覆盖手写代码混进去就会被冲掉。参数说明输入路径建议用完整路径某些版本对相对路径的处理依赖当前工作目录-o后面必须是已存在的目录或者工具会自动创建跑之前先确认一下不然可能报一个和权限毫无关系的错误。3.3 初始化时序Load 放哪里、Free 谁来调生成代码最容易出问题的地方在于“什么时候 Load”而不在代码本身。三种常见放法各有适用场景放在main/WinMain最前面最安全生命周期覆盖整个进程放在某个业务模块的初始化函数里适合插件式架构模块卸载时对应 Free放在第一次调用前的懒加载里代码最省事但引入了线程安全问题。我一般选第一种或者在有明确模块边界时选第二种。懒加载看起来很优雅实际项目里十次有八次会在多线程下出问题——两个线程同时进来都看到指针是 NULL都去LoadLibrary模块引用计数变成 2卸载时只减了 1DLL 就永远留在进程里了。还有一个必须明确的约定DemoPlugin_Free之后所有已经传出去的函数指针都作废。如果业务代码里有回调注册、有对象把函数指针存进了自己的成员卸载前必须先注销否则就是标准的释放后使用。3.4 最小验证三步确认绑定真的成功不要一上来就接业务逻辑先写一个二十行的验证程序。跑通了再往工程里接能把“生成代码的问题”和“业务代码的问题”彻底分开。/* selftest.c —— 最小验证先证明绑定链路通 */ #include windows.h #include stdio.h #include demo_plugin.h int main(void) { int rc DemoPlugin_Load(bin/demo_plugin.dll); if (rc ! 0) { /* -1: 模块没装上看 GetLastError-2: 装上了但有导出没绑上 */ printf(load failed, rc%d, lastError%lu\n, rc, GetLastError()); return 1; } printf(Add(2,3) %d\n, pAdd(2, 3)); /* 期望 5不对就是原型猜错了 */ pReset(); /* 无返回值只要不崩就算过 */ DemoPlugin_Free(); return 0; }逻辑说明返回值分支把两类失败拆开打印GetLastError()紧跟在失败之后取值中间不插入任何其他 API 调用否则错误码会被覆盖。pAdd(2, 3)的结果必须和预期一致——这一步不只是验证“能不能调”更是在验证参数类型和返回类型有没有猜对。参数说明编译时把生成的.c一起加进工程不要单独编译成静态库再链接那样在排查符号冲突时会更麻烦如果用的是 C 编译器记得头文件里的extern C包裹生效否则链接期会报名字找不到。三步验证的判定标准很明确第一步rc 0说明导出全部绑上第二步返回值正确说明原型对得上第三步Free之后进程正常退出说明生命周期没写错。三步都过再谈业务集成。4. 调用约定与名字修饰看不见的那一半导出表里只有名字和地址没有参数类型也没有调用约定。这两样东西生成器给不了你只能自己去对。绝大部分“绑上了但一调就崩”的问题根源都在这里。4.1 x86 的 stdcall、cdecl 与 N 后缀32 位下调用约定决定了参数由谁清栈。__cdecl由调用方清栈__stdcall由被调方清栈。猜错的直接后果是栈指针失衡函数返回后ESP偏移了几个字节接下来任何一次内存访问都可能出错崩溃位置离真正的原因很远非常难查。好消息是 x86 的修饰名会透露信息。__stdcall导出的名字通常长成_Name8这样后面的数字是参数占用的字节总数。看到8就知道参数一共 8 字节——两个int或者一个int加一个指针或者一个double。这已经能排除掉一大半错误猜测了。__cdecl导出一般只加前导下划线即_Name。64 位下情况简化了很多调用约定统一不再有名字修饰的N后缀导出名就是源码里的名字。所以同一个 DLL 的 32 位版和 64 位版导出名可能不一样生成代码不能直接复用。源码声明32 位导出名64 位导出名int __cdecl Add(int, int)_AddAddint __stdcall Add(int, int)_Add8Addvoid __stdcall Reset(void)_Reset0Resetvoid Foo::Bar(int)C?BarFooQAEXHZ同名修饰形式这张表的用法拿到 DLL 先用导出查看器看一眼实际名字和源码里可能的声明形式对上再决定生成代码里的函数指针该写哪种调用约定。不要凭直觉凭直觉的代价通常是一次莫须有的崩溃。4.2 C 修饰名怎么提供进去如果导出名是以?开头的一长串说明这是 C 的修饰名里面编码了类名、参数类型、const 属性等等。GetProcAddress要求传入的是二进制里原样的字符串所以生成代码里必须用修饰名去查不能用“看起来正常”的短名。正确做法是把修饰名完整复制进去注意反斜杠和特殊字符不要被转义破坏/* 修饰名里有 和 ?用字符串字面量原样传别做任何美化 */ typedef void (__cdecl *PFN_Bar)(void *self, int v); PFN_Bar pBar (PFN_Bar)GetProcAddress(g_hMod, ?BarFooQAEXHZ); if (pBar NULL) { /* 常见原因DLL 是 64 位但拿的是 32 位的名字或版本不一致 */ return -2; }这里有个隐藏问题C 成员函数第一个参数是this生成器从导出表里看不到这一点它会按普通函数生成参数列表是空的或者错的。所以遇到 C 修饰名不要直接相信生成的函数指针类型要按修饰名反推出的签名手工改或者干脆在源码里写一层 C 风格导出把它包起来。还有一种更稳妥的处理方式如果对方能改代码让对方加extern C再加__declspec(dllexport)一次性解决名字修饰问题。改不了就只能按照修饰名处理没有第三条路。4.3 序号导出与转发导出有些 DLL 出于兼容性考虑导出表里只有序号没有名字NumberOfFunctions远大于NumberOfNames。这种导出不能按名字查要把序号当成指针传/* 序号导出第二个参数不是字符串而是把整数强转成指针 */ FARPROC p GetProcAddress(g_hMod, (LPCSTR)MAKEINTRESOURCE(17)); if (p NULL) { /* 序号超出 Base..BaseNumberOfFunctions-1 范围或该位置是空洞 */ }MAKEINTRESOURCE是个宏把整数塞进指针的低位因为合法字符串指针的高位不为零系统靠这个区分两种查询方式。序号本身不是从 0 开始的实际序号是Base 索引Base一般是 1但也有从别的数字开始的务必看导出目录里的Base字段。转发导出是另一类特殊情况导出表里这个名字存在但它指向的 RVA 落在了导出目录范围内那块内存其实是一个字符串形如OTHER.FuncName表示这个函数实际实现在另一个模块里。运行期系统会自动处理转发GetProcAddress通常能正常返回真正的风险在于被转发到的那个模块缺失时整个LoadLibrary会失败而错误信息只会告诉你“找不到模块”不会告诉你是被依赖的那个。5. 避坑与排查五条现场记录下面五条是按踩到的频率排序的每一条都能对上一类具体现象。遇到问题先往这五条上套能省掉大量盲目试错。5.1 现象LoadLibrary 返回 NULL错误码 126 或 193现象很一致本地调试跑得好好的拷到测试机就失败GetLastError()打印出来是 126偶尔是 193。原因是两件事被混在了一起。126 是“找不到指定的模块”注意这个“模块”指的是目标 DLL 自己或者它的依赖不是路径拼错了——路径错也是 126依赖缺失也是 126所以必须进一步区分。193 是“不是有效的应用程序”几乎百分之百是位数不匹配32 位进程去加载 64 位 DLL或者反过来。解决办法分两步。先用 PE 查看器确认目标 DLL 的 machine 字段和当前进程位数一致一致的话再看依赖把目标 DLL 拖进依赖查看工具红色标记的就是缺的补齐到同目录。另外别忘了运行时库某些 DLL 依赖特定版本的 C 运行时机器上没装也会报 126。排查时把LoadLibraryA换成绝对路径先排除路径因素能少绕一圈。5.2 现象绑定全部成功第一次调用就 0xC0000005加载函数返回 0函数指针也都非 NULL一调用就访问违例崩溃栈在 DLL 内部。原因基本是调用约定或参数原型猜错。生成器只有名字和地址参数类型纯粹靠猜猜错了在 32 位下表现为栈失衡在 64 位下表现为寄存器里传了错误的值——比如把一个指针参数当成了整数DLL 内部解引用这个“指针”就崩了。解决办法是回到修饰名。32 位下N的数字能反推参数总字节数用它去校验你的原型声明64 位下没有这个线索就得靠文档、靠对方的示例代码、靠反汇编看函数入口怎么用参数。实在拿不到就先用最保守的签名试参数全用void*返回值也用void*能跑通再逐步收紧。我一般会先写一个只调一个最简单导出的最小用例确认约定对了再批量接。5.3 现象导出列表里明明有GetProcAddress 返回 NULL用查看器看得到名字代码里查不到GetLastError()是 127。原因有三类。一是名字不匹配导出表里是_Add8代码里查的是Add或者反过来64 位 DLL 查了带后缀的名字。二是序号导出名字本来就为空只能按序号查。三是转发导出名字在但实现不在被转发到的模块缺失时查询也会失败。解决办法是先打印实际导出名逐字节比对注意大小写和前后下划线。确认是修饰名问题就加回退逻辑先查裸名再查修饰名确认是序号导出就改用MAKEINTRESOURCE转发导出则要先保证被转发到的模块能被加载。这类问题的排查效率取决于你有没有一份可靠的导出清单所以在第 2 章那个diff脚本上花十分钟是值得的。5.4 现象Free 之后偶发崩溃或者第二次 Load 后指针失效程序运行一段时间后随机崩崩溃点在使用某个函数指针的地方前面看起来一切正常。原因是卸载后指针成了野指针。DemoPlugin_Free里如果只调了FreeLibrary而没有把函数指针表清空那些指针还指着已经解除映射的地址一旦有延迟调用或者回调触发就会崩。另一个变体是引用计数别的地方也LoadLibrary了同一个 DLL你这边FreeLibrary只减了计数模块没真正卸载指针看起来还能用等对方也卸载了就一起失效。解决办法是把“清指针”和“卸模块”绑成一个原子操作顺序固定为先置空再卸载并且给加载函数加幂等判断。对于跨模块共享的 DLL用一个全局的引用计数包一层谁加载谁负责卸载不要让两个模块各自管各自的。血泪经验是这类崩溃的复现周期很长等线上报上来再查成本极高所以宁可一开始就写严谨。5.5 现象结构体传参读出乱码数值全不对函数能调通不崩但传进去的结构体在 DLL 里读出来是垃圾数据或者返回的结构体字段错位。原因是对齐方式和类型宽度不一致。Windows 平台默认按 8 字节对齐但有些 SDK 为了跨平台或者兼容旧版本结构体是按 1 字节或 4 字节紧凑排列的两边不一致就会整体偏移。另一个常见原因是用了long这种宽度随平台变化的类型32 位下 4 字节、64 位下 8 字节结构体布局直接变了。解决办法是在头文件里显式写#pragma pack(push, 1)包裹结构体定义函数返回后再pop所有整数类型统一用固定宽度的int32_t/uint64_t不要用long。如果对方文档里给了结构体大小加一行static_assert(sizeof(MyStruct) 32, layout mismatch)把它钉死编译期就能拦住对齐错误比运行期调试划算得多。6. 把绑定表包一层三个回退开关和一份自检清单生成代码直接拿来用是可以的但只要 DLL 版本会变就值得在生成物外面再包薄薄一层。我一般加三个回退名字回退、序号回退、缺失降级。名字回退是先按裸名查失败再按修饰名查这样 32/64 位两套 DLL 共用一份代码序号回退是对那些只有序号的导出留一个兜底缺失降级则是允许某些非关键导出绑不上用一个返回错误码的桩函数顶替避免一处缺失导致整个模块不可用。/* 三层回退的绑定辅助裸名 - stdcall 修饰名 - 序号 */ static FARPROC bind_any(HMODULE h, const char *name, int ordinal) { FARPROC p GetProcAddress(h, name); /* 1. 裸名64 位和 cdecl 走这里 */ if (p ! NULL) return p; char buf[256]; _snprintf_s(buf, sizeof buf, _TRUNCATE, _%s8, name); p GetProcAddress(h, buf); /* 2. 补 stdcall 后缀N 按实际参数改 */ if (p ! NULL) return p; return GetProcAddress(h, (LPCSTR)MAKEINTRESOURCE(ordinal)); /* 3. 按序号兜底 */ }这段的关键在于第三步序号的取值必须来自导出目录的Base 索引不能凭感觉写。8那个后缀也要按实际参数字节数改写死成 8 只对两个整型参数的函数成立所以更稳妥的做法是把后缀当成参数传进来或者维护一张小表。验证方法我习惯做成自检函数在调试版里每次启动都跑一遍遍历整张绑定表把为 NULL 的项打印出来同时打印每一层回退实际命中的是哪一层。命中第二层或第三层说明当前环境和生成代码的假设有偏差这时就该停下来看一眼而不是让它悄悄跑过去。/* 调试期自检一眼看出哪些导出没绑上、走的是哪条回退路径 */ for (int i 0; i g_bindCount; i) { if (g_bindTable[i].ptr NULL) { OutputDebugStringA([dlltoc] missing export: ); OutputDebugStringA(g_bindTable[i].name); OutputDebugStringA(\n); } }还有一份交叉核对清单是我每次换 DLL 版本必做的导出数量和上次比有没有减少、Base有没有变、有没有新增的转发导出、调用约定有没有从 cdecl 变成 stdcall。这四项里任何一项变了生成代码都得重新过一遍不能直接替换文件。看起来啰嗦但换版本出的事故绝大多数都能被这四项拦住。说个自己的教训。早年接过一个项目对方给 DLL 的时候说“接口没变直接换文件就行”我信了只核对了文件名和导出数量对得上就发布了。结果对方把其中一个函数从__cdecl改成了__stdcallx86 下栈失衡前三天没事第四天在高并发下开始随机崩定位花了整整一周。从那以后我每次换 DLL 都强制走一遍dumpbin /exports的完整比对包括修饰名后缀里的N数字一个字符都不放过。希望这条经验能帮你减少一些麻烦。本文还有配套的精品资源点击获取