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（名字表长度）、AddressOfFunctions（RVA 数组）、AddressOfNames（名字字符串 RVA 数组，按字典序排好）、AddressOfNameOrdinals（名字索引到函数索引的桥）。

注意NumberOfFunctions和NumberOfNames常常不相等，差值就是“只有序号、没有名字”的导出。生成器做的第一件事，就是把这三张表按索引对齐：遍历名字表拿到名字，用名字表下标去AddressOfNameOrdinals拿到函数索引，再用索引去AddressOfFunctions拿到 RVA，最终序号是Base + 索引。对齐完成之后，得到一张表格，每行是三个值：名字、序号、RVA。

这一步自己验证一遍，后面排查问题时会省很多时间。常见做法是用 PE 导出查看器把名字单独导出来，和生成的头文件逐行比对：

# 只保留 序号 / hint / RVA / 名字 四列都存在的行，取最后一列名字 dumpbin /exports bin/demo_plugin.dll \ | awk 'NF>=4 && $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，能走的路其实只有三条，选错会带来后续大量维护成本。

选生成代码的理由，本质上是把“链接期的确定性”换成了“生成期的确定性”。如果 DLL 版本稳定、原型明确，静态导入仍然是最省事的选择；但现实里更多的情况是版本半年一换、导出时增时减，这时候一次重新生成比重新找 .lib 靠谱得多。代价要认：所有错误都推迟到运行期，所以加载函数的返回值必须当成契约来用，不能忽略。

3. 跑通第一次转换：从体检到编译通过

转换本身只要几秒钟，真正花时间的是转换前的确认和转换后的接入。这三十分钟如果省掉，后面会用几倍的时间在崩溃和错误码里找原因。

3.1 转换前的四项体检

第一项是位数。用查看器看 PE 头的 machine 字段，或者在导出查看器的输出里找machine (x86)/machine (x64)这一行。32 位进程加载 64 位 DLL 会直接返回 193，反过来是 126，两个错误码看起来都像“找不到文件”，其实跟路径毫无关系。

第二项是依赖链。目标 DLL 自己可能还依赖别的 DLL，LoadLibrary加载时会一并解析，任何一个缺失都整体失败。依赖查看类的工具能列出直接依赖，把缺失的那个一起放到同目录再试。

第三项是导出可见性。有的 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，卸载时只减了 1，DLL 就永远留在进程里了。

还有一个必须明确的约定：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导出的名字通常长成_Name@8这样，@后面的数字是参数占用的字节总数。看到@8，就知道参数一共 8 字节——两个int，或者一个int加一个指针，或者一个double。这已经能排除掉一大半错误猜测了。__cdecl导出一般只加前导下划线，即_Name。

64 位下情况简化了很多：调用约定统一，不再有名字修饰的@N后缀，导出名就是源码里的名字。所以同一个 DLL 的 32 位版和 64 位版，导出名可能不一样，生成代码不能直接复用。

这张表的用法：拿到 DLL 先用导出查看器看一眼实际名字，和源码里可能的声明形式对上，再决定生成代码里的函数指针该写哪种调用约定。不要凭直觉，凭直觉的代价通常是一次莫须有的崩溃。

4.2 C++ 修饰名怎么提供进去

如果导出名是以?开头的一长串，说明这是 C++ 的修饰名，里面编码了类名、参数类型、const 属性等等。GetProcAddress要求传入的是二进制里原样的字符串，所以生成代码里必须用修饰名去查，不能用“看起来正常”的短名。

正确做法是把修饰名完整复制进去，注意反斜杠和特殊字符不要被转义破坏：

/* 修饰名里有 @ 和 ?，用字符串字面量原样传，别做任何"美化" */ typedef void (__cdecl *PFN_Bar)(void *self, int v); PFN_Bar pBar = (PFN_Bar)GetProcAddress(g_hMod, "?Bar@Foo@@QAEXH@Z"); 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..Base+NumberOfFunctions-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。

原因有三类。一是名字不匹配，导出表里是_Add@8，代码里查的是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, "_%s@8", 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改成了__stdcall，x86 下栈失衡，前三天没事，第四天在高并发下开始随机崩，定位花了整整一周。从那以后我每次换 DLL 都强制走一遍dumpbin /exports的完整比对，包括修饰名后缀里的@N数字，一个字符都不放过。希望这条经验能帮你减少一些麻烦。

本文还有配套的精品资源，点击获取