很多人在排查 Windows 问题、研究软件报错或者做逆向分析时都会碰到一个需求想看看某个 DLL 文件里到底封装了哪些函数。单纯用记事本打开 DLL 就是一堆乱码看不到任何有价值的信息。这篇博文我就以 Win10 环境为例把几种常见的查看 DLL 导出函数的方法一次性讲清楚包括怎么用系统自带工具快速查看、怎么用专业工具把函数列表完整导出来以及我实际工作中踩过的一些坑。先说下这个话题适合谁如果你需要确认一个动态库是否提供了某个功能接口或者程序运行时提示“无法定位程序输入点”又或者你在用 C/C、C# 开发时想要确认某个第三方库的导出符号这篇文章都能帮到你。我不会只告诉你怎么点鼠标还会解释清楚每一步操作背后的原理这样你换一个工具、换一个场景也能举一反三。1. 内容整体设计与思路拆解1.1 为什么“查看 DLL 中的函数”是个高频需求DLLDynamic Link Library也就是动态链接库是 Windows 系统里被大量使用的共享代码库。你可能说不清系统里到底有多少个 DLL但几乎每个软件运行的时候都在加载它们。DLL 里的函数并不是“摆在那儿”等着你去看的它们有明确的导出机制只有被标记为“导出函数”的那些接口才能被外部程序调用。换句话说查看 DLL 里的函数本质上就是在看这个动态库对外暴露了哪些能力。这个需求通常出现在三种场景里排查软件运行异常程序启动时报“找不到指定的模块”或“无法定位程序输入点 xxx 于动态链接库 xxx.dll 上”。你要先确认这个 DLL 里是不是真的有这个函数才能判断是系统库版本不匹配还是软件本身被精简掉了关键组件。开发对接第三方库拿到一个第三方的 DLL但没有头文件和导入库.lib这时候就得靠“查看导出函数”来确定函数名、调用约定甚至折腾出动态加载的方案。逆向分析与安全研究安全工程师分析恶意软件、病毒样本时经常要快速看一个 DLL 导出了哪些函数。虽然恶意样本会做各种混淆但导出函数的命名往往能暴露它的行为逻辑。1.2 我选方案时的总体思路按场景区分工具查看 DLL 导出函数虽然有多种方案但每一种工具的定位和使用成本差距挺大。Dependencies旧称 Dependency Walker适合做完整依赖链分析dumpbin 适合在开发者命令提示符里快速查符号信息PE 查看器适合对着 PE 结构做深度剖析而字符串提取则是最简单、但最不准确的“兜底方案”。我下面这张表能帮你快速决策用哪个工具目标场景推荐工具信息完整度上手难度快速查看导出函数Microsoft Dependencies 或 Dependencies.exe高低开发环境下确认符号dumpbin /exports高中深度PE解析、看结构PE-bear、CFF Explorer极高高只想知道有没有某个字符串stringsSysinternals低会误报低提示Dependency Walker 这个老牌工具在 64 位系统上兼容性不好而且已经很多年不更新了在新出的 Win10 版本上打开复杂程序经常闪退。我一般首推微软新出的 Dependencies。2. 核心细节解析与实操要点2.1 DLL 文件的内部结构为什么不能直接双击看说到查看 DLL 里的函数首先得知道函数信息到底“藏”在文件的哪个位置。DLL 和 EXE 一样都遵循 PE 文件格式。PE 是 Windows 下的可执行文件格式里面分了多个区块Section比如代码区块.text、数据区块.data、资源区块.rsrc等。重点是PE 文件头部有一个“数据目录”结构其中有一项就是“导出表”Export Table。这个表记录了该 DLL 导出的所有函数名、序号、入口地址RVA相对虚拟地址等信息。外部程序调用这个 DLL 里的函数时系统会根据函数名或序号去查找导出表拿到函数真正所在的地址然后执行函数体代码。这就像一个大酒店有总服务台你想找某个客人函数先要去总台查一下他在哪个房间地址再过去敲门。DLL 的导出表就是这个“总服务台”。所以我们查看 DLL 函数本质上就是在解析 PE 文件、读取导出表的内容。理解了这一层后面用任何工具心里都有底了文件不是“明文”的函数名是结构化的存储方式所以用记事本打开看到的只是零散的“乱码”片段。有些 DLL 支持按序号导出不提供函数名。这种 DLL 用按名查找的方式看不到完整列表需要更专业的 PE 工具才能看清序号和地址的映射。导出表是有固定排序规则的一般按函数名字母顺序排列所以在大型 DLL 里找特定函数直接用工具查找功能效率更高。2.2 看懂导出函数的关键信息名称、序号、RVA、Hint用工具查看导出函数时你会看到一长串信息。以 dumpbin 的输出为例大致是这样ordinal导出序号。有些 DLL 的导出序号是固定的绑定导入时要用有些则是编译器自动分配的。hint是函数名在导出表的索引提示用于加速查找过程。RVA函数的相对虚拟地址。这个地址加上 DLL 加载基地址之后才是函数在内存中的实际入口地址。name函数被导出的名称也就是我们在代码里用 GetProcAddress(handle, 函数名) 所传的字符串。很多新手看 dumpbin 输出时会忽略 hint 和 ordinal 之间的区别但如果你做的是驱动开发或免安装软件兼容适配这个细节可能决定成败。比如有些 DLL 在更新后函数名没变但导出序号变了某些旧程序因为按序号绑定导入可能就会出现“无法定位”的问题。2.3 常见工具对比与选型我按实用性逐个说明下这几个工具先说优点再讲缺点。2.3.1 Microsoft DependenciesDependencies.exe这个东西的官方 GitHub 项目叫 lucasg/Dependencies最初是为了替代老旧的 Dependency Walker 而设计的。它的亮点是能直接查看 DLL 的依赖关系树双击任意节点就能看到对应的导出函数列表还能看导入表这个 DLL 依赖哪些其他 DLL 的哪些函数。使用场景很广我想确认某个 DLL 是否依赖于某个系统组件或者想在部署软件前检查所有依赖是否齐全用它效率极高。GUI 操作直观左侧是依赖树右侧有 Function 列表点一下就出来。2.3.2 dumpbindumpbin 是微软 Visual Studio 自带的一个命令行工具功能非常强大但位置藏得比较深通常必须在“开发者命令提示符”或者配置过环境变量的命令行窗口里运行。它的最强优势是可以和编译环境无缝衔接输出的信息详细且稳定批量处理时配合 findstr 过滤非常方便。在命令行里执行dumpbin /exports C:\Windows\System32\kernel32.dll它会输出一段类似File Type: DLL Section contains the following exports for KERNEL32.dll 00000000 characteristics FFFFFFFF time date stamp 0.00 version 1 ordinal base N number of functions N number of names ordinal hint RVA name 1 0 0002F1A0 AcquireSRWLockExclusive 2 1 0002F1D0 AcquireSRWLockShared ...这里能清晰看到函数名、序号、RVA。如果只想看某一类函数直接在命令行里加一个 findstr 过滤即可dumpbin /exports C:\Windows\System32\kernel32.dll | findstr /i File2.3.3 PE-bear 与 CFF Explorer这两款是 PE 结构分析领域的“瑞士军刀”。PE-bear 对很多做逆向的朋友不陌生它可以解析 PE 的每一个字段包括导出表、导入表、重定位表、资源段等。CFF Explorer 功能类似但它的 GUI 更传统但界面看起来稍微老旧。它们能看图也能改图对于只想查函数的人来说可能杀鸡用牛刀但如果 DLL 被加壳了UPX 壳、VMProtect 之类普通工具只能看到壳的导出函数看不到实际功能函数。这时候你必须在脱壳后再用 PE-bear 类工具验证导出表是否恢复完整。2.3.4 stringsSysinternals这不算一个正规的“查看导出函数”工具但你手上没有专业工具又急着快速判断某个 DLL 里是否包含某个敏感函数名时strings 可以临时顶一下。它会扫描整个文件中可打印的 ASCII 或 Unicode 字符串把看到的所有连续字符序列输出。函数名大概率会以字符串形式出现在导出表里所以你能搜到。缺点也明显它会搜出大量无关字符串比如报错提示、内部变量名、版权信息经常造成误判。而且如果文件被压缩或加壳strings 输出里可能根本没有关键函数名。3. 实操过程与核心环节实现3.1 用 Dependencies 快速查看 DLL 导出函数我建议新手直接用 Dependencies因为它的 GUI 最友好也能避免在命令行里折腾环境变量。具体步骤如下从 GitHub 下载 Dependencies 工具解压到一个目录注意运行环境是 Windows 10 x64 就选 x64 版本。启动 Dependencies.exe点击左上角的图标打开一个 DLL 文件。程序会自动分析 DLL 的导入表和依赖树加载完成可能需要几秒。在主界面的表格区域能找到“Functions”或带其他名字的选项卡这里会列出当前 DLL 的所有导出函数。在上方的搜索框输入关键词可以快速过滤函数列表。比如我想找 kernel32.dll 里是否包含 CreateFile直接输入 CreateFile 即可看到对应条目。如果你需要的仅仅是导出函数名而不是依赖关系其实可以借助“导出列表”菜单导出为文本文件方便后期写脚本分析。这里有个小技巧用 Dependencies 打开系统 DLL 时它会把系统目录中的所有依赖项也一起加载如果某个系统 DLL 版本不对软件会直接弹红色错误定位到具体模块。提示不要在生产环境运行的服务器上用 Dependencies 去加载大量 DLL它会读取文件头并生成依赖关系部分杀毒软件可能报毒如果只是为了查导出函数建议在隔离测试机或本地开发机操作。3.2 用 dumpbin 查看并导出函数列表命令行党的首选如果你已经在电脑上安装了 Visual Studio哪怕只是免费的 Build Tools那用 dumpbin 是最省事的。打开“开始菜单”搜索“Developer Command Prompt for VS 2022”或者类似名字点击进入然后在命令行中执行dumpbin /exports C:\Windows\System32\user32.dll注意这里的 /exports 是告诉 dumpbin 读取导出表。因为 dumpbin 输出内容可能会很长我习惯于把输出重定向到文本文件这样查看和筛选更容易dumpbin /exports C:\Windows\System32\user32.dll export_list.txt notepad export_list.txt然后就可以在记事本里搜索目标函数名。如果想在命令行里直接筛选可以dumpbin /exports C:\Windows\System32\user32.dll | findstr /i MessageBox这样输出里只保留包含 MessageBox 的行。有一个容易踩的坑不是所有 DLL 都有导出函数。比如某些纯资源 DLL只存放图标、字符串、图片等资源导出表是空的dumpbin 会提示 “No exports found”。这不代表文件损坏只是它确实没导出任何函数。3.3 用 PowerShell 动态获取 DLL 导出信息进阶玩法其实除了静态查看Win10 自带 PowerShell 也有办法判断一个 DLL 是否能被加载、某个函数是否存在。虽然 PowerShell 没法直接读取 PE 导出表但我们可以调用 Windows API 来验证$path C:\Windows\System32\kernel32.dll $assembly [System.Reflection.Assembly]::LoadFile($path) $assembly.GetTypes() | Select-Object -First 5这条命令对大多数 DLL 会报错因为 DLL 不一定是一个 .NET 程序集。不过如果是托管的 DLL比如 C# 写的类库这种方式就能列出里面的类型和方法。对于原生 C DLLPowerShell 里能用的方法就是通过 P/Invoke 调 LoadLibrary 和 GetProcAddress 做探测但解析过程比较麻烦不如直接用 dumpbin。PowerShell 的好处在于脚本化和批量处理。如果你需要一次性检查几十个 DLL 里是否包含某个函数可以反复调用 dumpbin 并解析输出虽然看起来没那么科技但胜在稳定。3.4 使用 PE-bear 深度查看导出表结构假如你想看更底层的结构比如导出表的“函数序号”和“函数地址的映射”可以直接用 PE-bear 打开 DLL然后找到“Data Directories”下的“Export Directory”项。这里会把 PE 头中记录的导出目录每一项列出来Export Address Table (EAT)函数入口地址数组按序号排列。Export Name Pointer Table函数名字符串指针数组。Export Ordinal Table函数名和序号之间的映射表。你会看到名称、序号和 RVA 一一对应。这种视角有点“硬核”但如果你的目的是分析 DLL 的导出方式是不是正常或者想手动修复损坏的导入导出表那就必须用到它。3.5 用 Everything 字符串搜索做应急判断如果 DLL 数量太多你又不想每次都打开 GUI 工具可以用 Everything文件搜索工具定位候选 DLL然后搭配 Sysinternals strings 做快速过滤strings -n 8 C:\path\to\your.dll | findstr /i FunctionName这里-n 8表示只输出长度至少 8 的字符串能有效减少噪声。这种方式适合“我只是想知道这个 DLL 提没提到过某函数名”的快速判断不严谨但效率高。3.6 小实验查看系统 DLL 并核对导出函数拿一个最常见的系统模块kernel32.dll它里面有大量进程、内存、文件相关 API。在开发者命令行执行dumpbin /exports C:\Windows\System32\kernel32.dll | more你会看到成百上千的函数名。我一般不会盯着全部看只关注当前需要的几个。例如要确认 CreateFileW 是否存在执行dumpbin /exports C:\Windows\System32\kernel32.dll | findstr CreateFile如果输出里同时有 CreateFileW 和 CreateFileA说明这个系统 DLL 同时支持宽字符和 ANSI 字符两个版本。这也是 Windows 开发里很常见的做法导出函数带 W 后缀的是宽字节版本带 A 后缀的是 ANSI 版本。4. 常见问题与排查技巧实录4.1 “无法定位程序输入点”是不是说明 DLL 里没这函数不一定。程序报“无法定位程序输入点”通常有两个原因DLL 里确实没有这个导出函数。DLL 里有这个函数但它位于比程序预期更低版本的 DLL 中或者被导入序号不匹配。我遇到过一种情况本机 system32 目录里有新版 DLL但程序目录里附带了一个旧版 DLL系统按照 DLL 搜索顺序先加载了目录下那个旧版于是报错。排查方法就是先把程序目录里的 DLL 全部列出来再用 dumpbin 一个个检查导出函数确认版本是否一致。4.2 Dependencies 打开 DLL 就崩溃或卡死Dependencies 对某些深度调用 API 的 DLL 分析起来会比较吃力特别是有自解密、反调试逻辑的模块。遇到这种情况先尝试只分析该 DLL不要自动递归分析依赖项。检查是否杀毒软件拦截了它加载系统组件。如果还是崩就换 dumpbin 只用命令行查看导出表。4.3 DLL 文件明明是 64 位的工具却说“不是有效的 Win32 程序”这是很多新手混淆的问题。PE 文件的位宽和“Win32 程序”是两个概念。如果你用 32 位工具去打开 64 位 DLL可能就能看到这种报错。Dependencies 要选对 x64 版本dumpbin 没有位宽问题但要注意使用对应架构的命令提示符。系统自带的 PE 格式接口并不区分位数但很多第三方解析器却区分所以遇到报错第一时间去确认工具架次。4.4 看不到导出函数但 DLL 没有损坏这种情况通常是因为 DLL 使用了“延迟加载”或者“按序号导出”。你说它没导出函数也不完全准确只是没有导出函数名而已。如果 DLL 模块采用了“非命名导出”你只能看到序号列表。用 PE-bear 打开看不到太多函数名时可以去导出表里看看 EntryPoint 是否只有序号、没有 Name 字段。4.5 无法找到 dumpbin 命令如果你安装了 Visual Studio但直接打开普通 CMD 输入 dumpbin会提示找不到命令。需要先加载 VsDevCmd.bat 或者使用开始菜单里的“开发者命令行提示符”。如果你只想跑 dumpbin不必安装完整的 Visual Studio IDE安装 Visual Studio Build Tools 即可会占用更少的磁盘空间。有个更省事的办法用 everything 搜索 dumpbin.exe找到路径后直接写全路径运行例如C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\bin\Hostx64\x64\dumpbin.exe /exports C:\path\to.dll为了避免每次都写这么长的路径你也可以把硬编码路径加进脚本里封装一下。4.6 如何批量统计 DLL 的导出函数数量假设你拿到了一个软件安装包里面散落着上百个 DLL你想统计每个 DLL 导出了哪些函数作为归档。手工一个个打开肯定不现实。我在实践里常用一个简单的批处理思路循环遍历目录下所有 DLL调用 dumpbin /exports 并把结果输出到同名文本文件echo off setlocal enabledelayedexpansion for /r C:\target_folder %%i in (*.dll) do ( echo Processing %%i dumpbin /exports %%i %%i_exports.txt 21 ) echo Done.注意第一次跑的时候先在一个小目录试点确认 dumpbin 的 /exports 参数能正常过滤掉“非 DLL”文件例如 .cpl、.exe 其实也能用 dumpbin 解析再放到大目录跑否则日志文件会非常多反而干扰你分析。4.7 查看带符号的 DLL 与调试符号PDB很多时候你看到的 DLL 导出函数是经过装饰的名字比如 C 类成员函数导出后会变成类似?CreateFileW...的样子。这是编译器对函数进行了 name mangling。遇到这种情况用 dumpbin /headers 加上 /symbols 可能也无法直接得到可读的原始签名最有效的方法是拿到对应的 PDB程序数据库文件在 WinDbg 或 Visual Studio 调试器里加载符号这样能看到原始的函数签名、参数类型和所在源代码行。如果 DLL 之外还有 PDB 但你想快速看函数名可以在 WinDbg 里执行x mydll!*这样会把所有导出的和内部的符号都列出来比 dumpbin 更直观。但要注意只有在系统加载该 DLL 后符号命令才能生效。4.8 查看 DLL 依赖关系才是最容易被忽略的坑许多人只盯着导出函数看却忽略了 DLL 依赖关系。一个 DLL 能不能被成功加载取决于它依赖的每一个 DLL 是否都能被找到。Win10 下排查依赖关系推荐用 Dependencies 的依赖树视图它会把缺失的模块标红。有个案例一个 EXE 调用某第三方 DLLDLL 里明明有目标函数但程序还是启动失败。我用 Dependencies 打开第三方 DLL 后发现它依赖了一个不在系统库列表里的 VC 运行库比如 msvcp140.dll目标电脑上没装 VC Redistributable所以加载失败。这个时候查再多次导出函数也没有用把运行库装好才解决问题。4.9 尝试在 32 位与 64 位之间迁移时的函数差异Win10 系统里System32 和 SysWOW64 两个目录都有大量系统 DLL。System32 里的是 64 位版本SysWOW64 里的是 32 位版本。函数名通常一样但函数实现的内部结构不同导出序号也可能有差异。如果你需要做 32 位兼容程序就要注意查看正确目录下的 DLL。我用 PE-bear 打开 System32 下的 kernel32.dll能看到导出表的 Base 是 1但打开 SysWOW64 下的 kernel32.dll会发现某些系统函数在 32 位环境里有不同的导出序号范围。这个细节会导致部分老程序在迁移后崩溃。4.10 不要忘记查看导入表Import Table与“导出表”相对的是“导入表”它记录的是当前 DLL 依赖其他 DLL 并调用了什么函数。想了解 DLL 的行为模式只查导出表不够还需要看导入表。例如一个 DLL 导出函数很少但导入了大量网络相关 API那它很可能在做网络通信。在 Dependencies 里导入表通常显示为“Imports”或每层依赖节点下的函数列表。在 dumpbin 里命令是dumpbin /imports C:\path\to\your.dll它会列出当前 DLL 从其他模块里导入的函数名。这种方式在分析恶意 DLL 或检测第三方组件行为时非常有效也能帮你确认某个 DLL 为什么总是缺依赖。5. 实操心得与扩展建议文章写到这里核心内容基本讲完了。我觉得有必要分享几个个人经验帮你少走弯路。第一先用系统自带工具再考虑第三方工具。很多人一上来就装各种 PE 查看器其实 Win10 系统只要装了 Visual Studio Build Tools用 dumpbin 就能解决绝大多数问题。而且 dumpbin 的输出是纯文本用脚本过滤起来非常方便适合自动化处理。如果电脑上实在没有编译环境再去下载 Dependencies 或 PE-bear。第二函数名的“加壳”问题要想清楚。如果你拿到的 DLL 被 UPX 加过壳dumpbin /exports 看到的可能只有 UPX 的几个导出函数其余函数全部隐藏。这并不代表函数不存在只是壳没有还原导出表。想查看真实导出函数要么先把 DLL 脱壳比如用 upx -d 命令要么用动态调试工具在运行时抓取。对于分析正常商用软件一般不会遇到这种场景但搞安全方向的朋友一定要有这个意识。第三系统 DLL 的版本差异比想象中大。Win10 的大版本更新会替换大量系统 DLL导出函数集合可能发生增减。如果你开发的是需要兼容多个 Win10 版本的软件尽量别依赖过于冷门的系统函数否则部署到老版本系统上就会报“无法定位程序输入点”。在开发机上确认 DLL 有某个函数完全不够还要去低版本的干净环境里验证。第四结合 Process Explorer 或 API Monitor 做动态验证。有时候静态导出函数表没问题但程序运行时实际调用的却是另一个模块里的同名函数。这时候用 API Monitor 挂钩目标函数能清楚看到调用栈到底是哪个 DLL 在执行。静态分析和动态验证结合能少走很多弯路。第五把常用 DLL 的函数导出成一个本地参考文件。我自己的电脑上维护了一个exports_dump文件夹把 kernel32.dll、user32.dll、advapi32.dll、shell32.dll 等核心库的 dumpbin 输出都保存了一份。每次写代码前想查某个 API 是否可用直接 grep 一下本地文件比启动工具快得多。dumpbin /exports C:\Windows\System32\kernel32.dll exports_kernel32.txt dumpbin /exports C:\Windows\System32\user32.dll exports_user32.txt dumpbin /exports C:\Windows\System32\advapi32.dll exports_advapi32.txt久而久之这套本地索引就成了我排查问题的“外置硬盘”遇到可疑 DLL 就能做快速比对不用每次翻工具。最后再分享一个小技巧如果只是临时想确认某个 DLL 文件的导出函数数量可用以下 PowerShell 快速统计$dumpbinPath C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\bin\Hostx64\x64\dumpbin.exe $output $dumpbinPath /exports C:\Windows\System32\user32.dll $numberOfFunctions ($output | Select-String -Pattern number of functions).ToString().Trim() $numberOfNames ($output | Select-String -Pattern number of names).ToString().Trim() Write-Host $numberOfFunctions Write-Host $numberOfNames当然这个路径会因为 VS 版本不同而变化你可以根据自己的目录去调整。利用相同思路你还能把所有输出写入 CSV 文件做长期版本追踪。DLL 函数查看这事听起来简单但涉及的工具链和细节其实不少。从系统自带的 dumpbin 到专业的 PE 解析工具再到动态调试器每一层工具都有自己的适用边界。掌握“导出一依赖一运行验证”这条完整链路你排查问题的时候才会更加心里有数。
