本文是对 Windows dynamic libraries, calling conventions, and transmute 的整理与翻译。内容结构概览从 ping.exe 开始逆向观察真正的ping不会自己实现所有协议而是调用 Windows 系统库。用 dumpbin 查看依赖库通过 Visual Studio 工具链中的dumpbin /dependents查看PING.EXE依赖哪些 DLL。定位 ICMP 相关函数通过dumpbin /imports和findstr找到IcmpSendEcho2Ex、Icmp6SendEcho2。找到 IPHLPAPI.dllICMP 相关函数来自 IP Helper API也就是IPHLPAPI.dll。用 API Monitor 观察真实调用通过监控PING.EXE看到创建 ICMP handle、调用IcmpSendEcho2Ex、默认 TTL 等信息。转向 Rust 实现使用stable-x86_64-pc-windows-msvc工具链保证和 Visual Studio/MSVC ABI 兼容。不直接链接 IPHLPAPI而是运行时加载通过KERNEL32.dll提供的LoadLibraryA和GetProcAddress动态打开 DLL、取函数地址。理解 Win32 字符串和调用约定A/W后缀、C 字符串、空字节结尾、stdcall调用约定。Rust FFI 基础extern stdcall、裸指针、c_void、HMODULE、unsafe。第一个坑字符串没有\0结尾Rust 字符串切片不是 C 字符串传给 Win32 API 时要手动补空字节。GetProcAddress 与函数指针拿到函数地址后不能直接当函数调用。transmute 登场把原始地址重新解释成函数指针用来调用MessageBoxA。总结这一篇不是直接实现 ping而是先打通 Rust 调用 Win32 API 的基础能力。上一篇文章从计算机网络的历史讲起解释了为什么会有以太网、MAC 地址、IP、DNS、DHCP以及为什么ping这样一个小工具背后牵扯到整套网络协议栈。到了这一篇问题终于开始落到具体实现上Windows 自带的ping.exe到底是怎么发出 ping 请求的直觉上ping.exe不太可能自己从零实现所有底层协议。它不应该自己管理网卡不应该自己处理整个 IP 协议栈也不应该绕过操作系统直接和硬件说话。真正合理的模型是ping.exe调用某个 Windows 系统库系统库再进入内核或网络栈由操作系统负责完成实际的数据包发送与接收。因此这一篇的目标不是马上写出完整 ping而是先学会观察现有程序如何调用 Windows API再用 Rust 复现这种调用方式。这个过程会涉及 Windows 动态库、PE/COFF 文件、dumpbin、IPHLPAPI.dll、LoadLibraryA、GetProcAddress、调用约定、C 字符串、裸指针、unsafe和transmute。这些东西看起来离 ping 很远但如果想在 Windows 上自己实现一个低层网络工具绕不开它们。一、ping.exe 不会独自完成所有工作在 Windows 上ping.exe位于C:\Windows\System32\PING.EXE它是一个普通可执行文件。用户在命令行里输入ping 8.8.8.8屏幕上会显示请求是否成功、往返时间、TTL 等信息。表面看起来这是ping.exe自己做的事但从操作系统结构看它很可能只是调用了系统提供的 API。原因很简单。发送 ICMP Echo 请求需要经过操作系统网络栈最终还会通过网卡把数据发到外部网络。普通应用程序不应该直接操作硬件也不应该复制一份完整网络协议栈。Windows 已经提供了相关系统库和内核接口ping.exe更合理的做法是调用这些接口。在 Linux 上如果想知道一个可执行文件依赖哪些动态库常用工具是ldd。但在 Windows 上工具名称和生态不一样。Windows 可执行文件通常是 PE/COFF 格式动态库是.dll文件。要查看 Windows 可执行文件依赖哪些 DLL可以使用 Visual Studio 工具链里自带的dumpbin。这就引出了第一步搭建一个能分析 Windows 可执行文件的环境。二、用 Visual Studio 工具链查看 PING.EXE 依赖在 Windows 上按照 Microsoft 官方方式构建和分析程序通常需要安装 Visual Studio 或 Visual Studio Build Tools。完整 Visual Studio 体积不小但它包含很多有用工具例如编译器、链接器、调试器、分析工具以及这里要用到的dumpbin。安装 Visual Studio 之后可以打开 “Developer Command Prompt” 或类似名称的工具命令行。它本质上还是cmd.exe但已经配置好了环境变量可以直接使用 Visual Studio 工具链中的命令。普通命令行里可能找不到dumpbin但开发者命令行可以。先用下面的命令查看PING.EXE依赖了哪些动态库dumpbin /dependents C:\Windows\System32\PING.EXE这里的/dependents是dumpbin的参数。Microsoft 命令行工具经常使用/flag这种风格而不是 Unix 工具里常见的--flag。输出结果会列出一组 DLL。除了msvcrt.dll、ntdll.dll、各种api-ms-win-core-*之外还能看到两个比较关键的库IPHLPAPI.DLL WS2_32.dllWS2_32.dll很容易让人想到 Windows Sockets也就是网络编程常见的 Winsock。IPHLPAPI.DLL则更像 “IP Helper API”直觉上和 IP 网络管理、ICMP、路由表、网卡信息等有关。但光看到依赖库还不够。一个程序依赖某个 DLL并不代表 ping 功能一定来自它。下一步需要查看PING.EXE从这些 DLL 里具体导入了哪些函数。三、从导入函数里找到 ICMP Echo继续使用dumpbin可以查看一个可执行文件导入了哪些外部函数dumpbin /imports C:\Windows\System32\PING.EXE完整输出会比较长所以可以配合findstr搜索感兴趣的关键词。findstr可以粗略理解为 Windows 里的grep。先搜索pingdumpbin /imports C:\Windows\System32\PING.EXE | findstr /I ping/I表示大小写不敏感。这样可以同时匹配ping、PING、Ping等形式。搜索ping可能没有结果因为 API 名字未必叫 ping。换一个思路ping 的底层语义是 ICMP Echo Request 和 Echo Reply所以可以搜索echodumpbin /imports C:\Windows\System32\PING.EXE | findstr /I echo这时能看到类似下面的函数名IcmpSendEcho2Ex Icmp6SendEcho2这就基本确认了方向。IPv4 的 ping 很可能走IcmpSendEcho2ExIPv6 的 ping 则可能走Icmp6SendEcho2。这两个名字已经非常明确它们属于 ICMP Echo 相关 API。接下来还要确认这些函数来自哪个 DLL。dumpbin /imports的完整输出会按 DLL 分组列出导入函数简单搜索函数名只能看到函数未必能看到分组上下文。可以用 PowerShell 做更方便的文本处理或者直接查看完整输出。最终可以定位到相关函数来自IPHLPAPI.dll。这一步非常关键。到这里已经知道 Windows 自带ping.exe并不是自己手搓 ICMP而是调用了 IP Helper API 里的 ICMP 相关函数。后续自己写程序时可以沿着同一条路线调用这些函数。四、文档有用但真实程序更有用查到IcmpSendEcho2Ex之后当然可以直接打开 Microsoft 文档看它的函数签名、参数含义、返回值说明。但只看文档有一个问题文档告诉你 API “可以怎么用”却不一定告诉你一个真实程序“实际怎么用”。尤其是 Win32 API 这类历史悠久的接口经常有大量参数、结构体、可选项、兼容行为。文档读起来可能很完整但第一次调用时仍然不知道哪些参数必须填哪些可以传空哪些结构体必须提前初始化哪些行为只是示例代码里的习惯。这时可以用 API Monitor 观察真实程序。API Monitor 是一个可以监控 Windows API 调用的工具。它加载大量 API 定义然后允许选择某一组 API 进行 hook再启动或附加到目标进程观察目标程序到底调用了哪些函数、传了什么参数、返回了什么结果。这里可以选择 IP Helper 相关 API然后监控新启动的PING.EXE。执行几次 ping 之后就能看到它调用了哪些 ICMP 函数以及参数大概是什么样子。从监控结果里可以得到几条重要信息。首先发送 ping 之前需要创建一个 ICMP handle。其次IcmpSendEcho2Ex参数很多但不少参数可以留空。再次Windows 的PING.EXE默认选择的 TTL 是 128。TTL 是 Time To Live它表示一个 IP 包最多可以经过多少次路由跳转每经过一个路由器TTL 通常减一减到 0 就会被丢弃用来避免数据包在网络中无限循环。监控结果里还会出现一个看起来奇怪的目标地址比如134744072。它不像常见的 IP 地址写法但如果把它按字节解释就会发现它其实是8.8.8.8。每个8都是一个字节API Monitor 把四个字节整体解释成了 32 位整数所以显示成了十进制整数。这是观察底层 API 时很常见的现象工具展示的数值格式不一定就是人类熟悉的格式必须理解底层二进制表示。到这里Windows 原生 ping 的调用路径已经基本清楚ping.exe使用 Win32 API 发送 ICMP Echo 消息相关函数来自IPHLPAPI.dll用dumpbin可以静态查看依赖和导入函数用 API Monitor 可以动态观察真实调用过程。五、为什么接下来选择 Rust如果完全按照 Windows 生态来写最自然的选择可能是 C、C 或 C#。Win32 API 本来就以 C 接口形式存在用 C 调用这些函数最直接C 可以在此基础上做封装C# 则可以通过 P/Invoke 调用系统库。但这里选择 Rust是因为目标不是复制 Microsoft 文档里的示例代码而是借这个过程学习 Rust 如何和外部系统 API 交互。Rust 默认强调内存安全和类型安全而 Win32 API 是典型的 C 世界接口裸指针、空指针、手动约定、调用约定、动态库、函数地址。二者相遇时很多边界问题会暴露出来。在 Windows 上使用 Rust需要注意工具链后缀。通过rustup安装 Rust 后如果使用的是stable-x86_64-pc-windows-msvc那么最后的msvc表示它使用 MSVC 工具链ABI 和 Visual Studio 2019 这类 Microsoft 工具链兼容。ABI 是 Application Binary Interface应用二进制接口。它关系到函数调用时参数怎么传、返回值怎么放、栈怎么管理、符号怎么链接等底层约定。要和 Windows 系统库正确交互ABI 兼容很重要。新建一个 Rust 二进制项目后可以用cargo build构建再用dumpbin /dependents查看生成的.exe依赖哪些 DLL。一个最小 Rust 程序通常不会自动依赖IPHLPAPI.dll。这意味着如果要调用 ICMP 相关函数有两条路可以走一种是在构建阶段配置链接让程序直接链接IPHLPAPI.dll另一种是在运行时通过系统 API 动态打开IPHLPAPI.dll再取出需要的函数地址。这里选择第二种路线。它更绕但能学到更多底层知识Windows 如何动态加载 DLL如何通过函数名找函数地址Rust 如何声明外部函数如何处理 C 字符串如何把原始地址转换成可调用的函数指针。六、用 KERNEL32.dll 动态加载库一个最小 Rust 程序虽然不会链接IPHLPAPI.dll但通常会依赖KERNEL32.dll。KERNEL32.dll提供了很多基础 Win32 API其中就包括动态加载库相关函数。要在运行时打开一个 DLL可以使用LoadLibraryA或LoadLibraryW。Win32 API 里很多处理字符串的函数都有两个版本A和W。A通常表示 ANSI 版本历史上接近 ASCII 或系统代码页W表示 Wide 字符版本通常使用 UTF-16。现代 Windows 对字符编码有更多兼容行为但理解A/W后缀仍然很重要。看到LoadLibraryA就应该知道它接收的是类似 C 字符串的窄字符指针看到LoadLibraryW就应该想到 UTF-16 宽字符串。如果用 Rust 来想象LoadLibrary最理想的函数签名可能是fnLoadLibrary(name:str)-Handle但 Win32 API 不是 Rust 写的它不认识 Rust 的str。C 世界里传字符串常见方式是传一个指向字节序列的指针并用空字节\0表示字符串结束。因此LoadLibraryA更接近下面的形式fnLoadLibraryA(name:*constu8)-Handle这里的*const u8是 Rust 的裸指针类型表示指向不可变字节的原始指针。const表示这个函数不应该修改传入的数据u8表示无符号 8 位整数也就是一个字节。不过在 Rust 里调用外部函数需要用extern声明。因为函数体不在当前 Rust 程序里而是在某个外部动态库里。声明形式类似extern{fnLoadLibraryA(name:*constu8)-Handle;}但这样还不完整因为 Win32 API 有特定调用约定。七、调用约定为什么重要调用约定决定了函数调用时的底层细节参数放在哪里是放寄存器还是栈上返回值放在哪里函数调用结束后由调用方还是被调用方清理栈不同大小的参数如何对齐函数名如何修饰。这些东西平时写高级语言时很少直接接触但一旦跨语言调用就非常重要。如果调用约定写错程序可能立刻崩溃也可能看起来暂时能跑但在某个诡异位置出现内存损坏、栈错乱或调试器无法解释的错误。更麻烦的是调用约定错误不一定在调用点立刻暴露可能会污染后续执行状态让问题变得很难查。Win32 API 常见调用约定是stdcall。Rust 允许在extern声明中指定调用约定因此应该写成externstdcall{fnLoadLibraryA(name:*constu8)-Handle;}这里的重点不是背下stdcall这个词而是理解跨语言调用时函数签名不只是参数类型和返回值类型还包括 ABI 和调用约定。Rust 编译器必须知道外部函数如何被调用否则生成的机器码就可能和真实函数不匹配。接下来还需要处理返回值类型也就是前面签名里的Handle。八、Windows 里的 handle 与 HMODULEWindows API 里到处都是 handle。打开文件会得到 handle创建窗口会得到 handle打开进程会得到 handle加载模块也会得到 handle。handle 可以理解为系统资源的某种引用。它不一定暴露真实内部结构只是让调用方在后续 API 中用它代表某个资源。LoadLibraryA在 C 文档中的声明类似HMODULELoadLibraryA(LPCSTR lpLibFileName);这里的返回值是HMODULE。H很多时候表示 handleMODULE表示模块也就是加载进程地址空间里的 DLL 或 EXE 模块。LPCSTR可以拆成 Long Pointer to Constant String大概意思是指向常量 C 字符串的指针。在 Rust 里不知道HMODULE具体指向什么结构也不应该随意解引用它。更安全的表达方式是把它当作不透明指针。Rust 标准库提供了std::ffi::c_void可以用来表示 C 里的void。于是可以定义usestd::ffi::c_void;typeHModule*constc_void;externstdcall{fnLoadLibraryA(name:*constu8)-HModule;}这段声明表达了几个关键信息LoadLibraryA是外部 Win32 函数调用约定是stdcall参数是一个 C 字符串指针返回值是一个不透明模块句柄。到这里Rust 编译器已经知道如何生成调用这个函数的代码。但真正调用它时又会遇到 Rust 的安全边界。九、调用外部函数为什么需要 unsafeRust 的安全模型无法保证外部 C 函数的行为。LoadLibraryA不是 Rust 写的Rust 编译器不知道它会不会读取越界内存不知道传入指针是否有效不知道它是否会保存这个指针不知道它是否会修改全局状态也不知道它是否遵守 Rust 的别名和生命周期规则。因此调用extern函数需要放在unsafe块里。unsafe不是关闭所有检查也不是让代码必然危险而是告诉编译器这里有一些 Rust 无法验证的前提程序员需要自己保证它们成立。第一次尝试可能会写成这样usestd::ffi::c_void;typeHModule*constc_void;externstdcall{fnLoadLibraryA(name:*constu8)-HModule;}fnmain(){lethunsafe{LoadLibraryA(IPHLPAPI.dll.as_ptr())};println!({:?},h);}这段代码能表达大概意图把 Rust 字符串IPHLPAPI.dll的底层指针传给LoadLibraryA然后打印返回的模块句柄。但运行后可能会发现返回值是空指针也就是0x0。按照 Win32 API 的习惯LoadLibraryA返回 NULL 往往表示加载失败。到这里表面上已经做了很多正确的事找到了正确的 DLL 名称声明了外部函数指定了调用约定使用了不透明指针类型也放进了unsafe块。结果仍然失败说明问题藏在更基础的位置。问题出在字符串上。十、Rust 字符串不是 C 字符串传给LoadLibraryA的并不是一个“字符串对象”而只是一个内存地址。Rust 的字符串切片str自己知道长度但当调用.as_ptr()时拿到的只是指向第一个字节的裸指针。这个指针本身不携带长度信息。C 字符串的约定完全不同。C 函数通常不知道字符串长度它会从传入地址开始一个字节一个字节往后读直到遇到空字节\0才认为字符串结束。这就是 null-terminated string也就是以空字节结尾的字符串。因此传入IPHLPAPI.dll.as_ptr()并不等于传入一个合法 C 字符串。内存中这段字节后面不一定紧跟着0。LoadLibraryA可能继续读取后面的随机内存把额外字节也当成文件名的一部分。运气好时它读到某个空字节后停止但文件名已经不对所以加载失败运气不好时它可能一直读到非法地址造成访问违规或段错误。修复方式很简单手动给字符串加上\0fnmain(){lethunsafe{LoadLibraryA(IPHLPAPI.dll\0.as_ptr())};println!({:?},h);}加上空字节之后LoadLibraryA能正确识别 DLL 名称返回值也不再是空指针。这是 Rust 调 Win32 API 时非常典型的第一课Rust 字符串和 C 字符串不是同一种东西。只传裸指针时长度信息会丢失如果目标 API 期待 C 字符串就必须保证字符串以\0结尾。更正式、更不容易出错的写法通常会使用CString等类型但这一篇为了暴露底层细节直接用\0展示了问题本质。十一、加载 DLL 之后还要取函数地址LoadLibraryA只能把 DLL 加载进当前进程并返回模块句柄。一个 DLL 里可以导出很多函数真正调用某个函数之前还需要根据函数名拿到它的地址。Windows 提供了GetProcAddressFARPROCGetProcAddress(HMODULE hModule,LPCSTR lpProcName);hModule是前面LoadLibraryA返回的模块句柄lpProcName是函数名同样是 C 字符串。返回值FARPROC可以理解为某个导出函数的地址。由于它可能指向任何签名的函数所以在 Rust 里可以先把它表示成不透明指针usestd::ffi::c_void;typeHModule*constc_void;typeFarProc*constc_void;externstdcall{fnLoadLibraryA(name:*constu8)-HModule;fnGetProcAddress(module:HModule,name:*constu8)-FarProc;}为了先验证这套机制可以不急着调用 ICMP 相关函数而是试一个更直观的 Win32 API弹出消息框。消息框函数MessageBoxA位于USER32.dll。先加载USER32.dll再从里面取出MessageBoxA的地址fnmain(){unsafe{lethLoadLibraryA(USER32.dll\0.as_ptr());letfGetProcAddress(h,MessageBoxA\0.as_ptr());println!(f {:?},f);}}如果打印出来的函数地址不是空指针说明 DLL 加载成功函数地址也找到了。但这还不意味着可以直接调用它。对 Rust 来说f只是一个裸指针不是函数。裸指针不能像函数一样写f(...)调用。要真正调用它必须告诉 Rust这个地址代表一个具有特定签名和调用约定的函数。十二、MessageBoxA 的函数签名MessageBoxA的 C 声明大概是intMessageBoxA(HWND hWnd,LPCTSTR lpText,LPCTSTR lpCaption,UINT uType);它用于弹出一个 Windows 消息框。hWnd是父窗口句柄可以传空指针表示没有父窗口lpText是消息正文lpCaption是标题uType是按钮和图标等配置简单情况下可以传 0。换成 Rust 函数指针类型可以写成externstdcallfn(*constc_void,*constu8,*constu8,u32)为了可读性可以定义类型别名typeMessageBoxAexternstdcallfn(*constc_void,*constu8,*constu8,u32,);这里仍然要注意调用约定。如果函数真实调用约定是stdcallRust 里的函数指针类型也必须写成extern stdcall fn(...)不能省略。另外空指针不能直接用整数0代替。Rust 标准库提供了std::ptr::null()可以用它创建一个空的不可变裸指针。正文和标题仍然要以\0结尾因为MessageBoxA也期待 C 字符串。理想上可能想写成usestd::{ffi::c_void,ptr::null};typeMessageBoxAexternstdcallfn(*constc_void,*constu8,*constu8,u32,);fnmain(){unsafe{lethLoadLibraryA(USER32.dll\0.as_ptr());letfGetProcAddress(h,MessageBoxA\0.as_ptr());letMessageBoxA:MessageBoxAf;MessageBoxA(null(),Hello from Rust\0.as_ptr(),null(),0,);}}但这不会编译。原因也合理f是*const c_void也就是一个原始地址MessageBoxA是一个函数指针类型。Rust 不会自动相信“这个地址就是这个签名的函数”。这种转换太危险必须显式告诉编译器。这时就轮到transmute出场。十三、transmute把一个值重新解释成另一种类型std::mem::transmute是 Rust 里非常强力也非常危险的工具。它可以把一个类型的值按原始位模式重新解释成另一个类型而不做任何转换。也就是说它不会检查这个地址是不是真的指向一个MessageBoxA不会检查函数签名是否匹配也不会检查调用约定是否正确。它只是相信程序员的判断。在这个场景里GetProcAddress返回一个原始函数地址而我们知道这个函数名是MessageBoxA也知道它的 Win32 函数签名。因此可以用transmute把原始地址转换为对应函数指针usestd::{ffi::c_void,mem::transmute,ptr::null,};typeHModule*constc_void;typeFarProc*constc_void;typeMessageBoxAexternstdcallfn(*constc_void,*constu8,*constu8,u32,);externstdcall{fnLoadLibraryA(name:*constu8)-HModule;fnGetProcAddress(module:HModule,name:*constu8)-FarProc;}fnmain(){unsafe{lethLoadLibraryA(USER32.dll\0.as_ptr());letMessageBoxA:MessageBoxAtransmute(GetProcAddress(h,MessageBoxA\0.as_ptr()));MessageBoxA(null(),Hello from Rust\0.as_ptr(),null(),0,);}}运行后如果一切正确会弹出一个来自 Rust 程序的 Windows 消息框。这说明几个底层能力已经打通Rust 程序可以调用KERNEL32.dll中的LoadLibraryA可以动态加载USER32.dll可以通过GetProcAddress获取导出函数地址可以把这个地址转换成函数指针并最终按照 Win32 调用约定调用它。这一步虽然只是弹了一个消息框但它的意义很大。因为调用MessageBoxA和调用IPHLPAPI.dll里的 ICMP 函数本质上是同一类问题加载 DLL取函数地址定义正确的 Rust 函数指针类型处理 C 字符串和结构体放进unsafe边界里调用。十四、这一篇真正建立了什么能力表面上看这一篇还没有发送真正的 ICMP Echo 请求也没有实现完整 ping。它做的事情似乎只是研究ping.exe、加载 DLL、弹出消息框。但从工程路径看这一步非常必要。首先通过dumpbin /dependents和dumpbin /imports可以知道一个 Windows 可执行文件依赖哪些库、导入哪些函数。这是一种静态观察能力。它能帮助我们从现有程序反推出可能使用的系统 API。对PING.EXE来说这一步定位到了IcmpSendEcho2Ex、Icmp6SendEcho2和IPHLPAPI.dll。其次通过 API Monitor可以看到真实程序如何调用系统 API。这是一种动态观察能力。静态导入表只能告诉你“程序可能调用这些函数”但监控运行时调用可以告诉你“它实际调用了什么、参数大概是什么”。对学习 Win32 API 来说这比只读文档更直观。再次通过 Rust FFI可以让 Rust 程序进入 Windows C API 世界。这个过程迫使我们面对很多平时容易忽略的底层细节Rust 字符串和 C 字符串不同裸指针没有长度信息外部函数不受 Rust 内存安全保证调用约定必须匹配handle 可以用不透明指针表示函数地址不能直接调用transmute必须放在unsafe里并且使用时要非常确定目标类型正确。最后通过LoadLibraryA和GetProcAddress可以在运行时动态加载 DLL而不是在编译阶段静态链接。这种方式灵活也更适合探索。后续如果要加载IPHLPAPI.dll并调用IcmpSendEcho2Ex整体流程已经基本清楚。十五、几个容易踩坑的点这一篇最值得记住的不是某一段代码而是几个跨语言调用时反复出现的坑。第一个坑是字符串。Rust 的str有长度信息C 字符串靠\0结束。把.as_ptr()传给 C 函数时传过去的只是地址不是完整字符串对象。如果目标 API 期待 C 字符串就必须保证结尾有空字节。否则函数可能读过界、读到垃圾数据甚至触发访问错误。第二个坑是调用约定。extern stdcall不是语法装饰而是 ABI 的一部分。调用约定错了程序可能表现得非常诡异。跨语言调用时必须让 Rust 的函数声明和真实外部函数在调用约定、参数类型、返回值类型上保持一致。第三个坑是空指针和错误处理。Win32 API 很多函数用 NULL 表示失败比如LoadLibraryA或GetProcAddress返回空指针时通常说明没有加载成功或没有找到函数。示例代码为了讲清主线没有展开完整错误处理实际工程里应该检查返回值并调用GetLastError等方式获取错误原因。第四个坑是unsafe的边界。unsafe并不意味着代码一定错误也不意味着 Rust 不再有价值。它的意义是把编译器无法证明安全的部分圈出来让危险集中在少量地方。理想写法是用少量unsafe封装底层调用再向外暴露安全的 Rust API。第五个坑是transmute。它很强但几乎没有保护。把一个原始地址转换成函数指针时必须保证地址非空、函数真实存在、签名正确、调用约定正确、生命周期合理。任何一个前提错了都可能导致未定义行为或崩溃。能不用transmute时应尽量不用必须用时应该把前提写清楚并把它限制在很小范围内。十六、从消息框回到 ping为什么要先调用MessageBoxA而不是直接调用IcmpSendEcho2Ex因为MessageBoxA更容易验证。它的效果很直观调用成功就弹窗调用失败就没有弹窗或崩溃。相比之下ICMP 调用涉及更多结构体、缓冲区、网络权限、目标地址、返回数据解析第一次上手时更难判断错误发生在哪一步。先用USER32.dll和MessageBoxA练习动态加载与函数调用可以把问题拆小。只要能成功弹出消息框就说明 FFI 的基础路径没问题。后续切换到IPHLPAPI.dll只需要把 DLL 名、函数名、函数签名、参数和返回值换成 ICMP 相关接口。这也是学习底层系统编程时很有效的方法不要一上来就挑战完整目标而是先选一个可观察、可验证、依赖较少的小 API把调用链路打通。等动态库加载、函数地址获取、调用约定、字符串、裸指针、unsafe都跑通之后再处理复杂业务逻辑。在整个 “Making our own ping” 系列里这一篇的地位就是铺路。第一篇回答“网络为什么长这样”第二篇回答“在 Windows 上Rust 怎么调用系统 API”。后面真正发送 ping 请求时就不需要再临时解释什么是 DLL、什么是 calling convention、为什么要unsafe、为什么字符串要\0结尾、为什么要把地址转换成函数指针。十七、总结这一篇的主线可以概括成一句话先研究 Windows 自带ping.exe如何工作再让 Rust 具备调用同类 Win32 API 的能力。具体过程是用 Visual Studio 工具链里的dumpbin查看PING.EXE的依赖库和导入函数找到IcmpSendEcho2Ex、Icmp6SendEcho2确认 ICMP 相关能力来自IPHLPAPI.dll再用 API Monitor 观察真实ping.exe调用过程看到它会创建 ICMP handle、调用IcmpSendEcho2Ex并使用默认 TTL 等参数随后转向 Rust用stable-x86_64-pc-windows-msvc工具链保证 ABI 兼容最后通过LoadLibraryA、GetProcAddress、extern stdcall、裸指针、c_void、unsafe和transmute成功从 Rust 中动态加载 Windows DLL 并调用MessageBoxA。这条路看起来绕但它让后面的实现有了坚实基础。自己写 ping 并不只是了解 ICMP 包格式还要知道操作系统提供了什么能力用户态程序如何进入系统 API动态库如何加载函数地址如何变成可调用的函数指针Rust 的安全边界又在哪里。真正的底层编程经常不是“知道一个函数名就能调用”而是要把函数所在的库、ABI、调用约定、字符串格式、指针类型、错误返回和运行时加载方式全部对齐。只要这些底层规则中有一个错了程序就可能失败、崩溃或者更糟糕地在看似正常运行很久之后才暴露问题。因此这一篇虽然没有真正发出 ping 包但已经完成了非常关键的一步从 Windows 原生程序中找到 ICMP API 的线索并用 Rust 打通调用 Win32 API 的底层通道。下一步就可以把MessageBoxA换成IPHLPAPI.dll中的 ICMP 函数真正开始构造和发送自己的 ping 请求。
从 Windows 的 ping.exe 入手：动态库、调用约定与 Rust FFI
发布时间：2026/6/14 20:00:06
本文是对 Windows dynamic libraries, calling conventions, and transmute 的整理与翻译。内容结构概览从 ping.exe 开始逆向观察真正的ping不会自己实现所有协议而是调用 Windows 系统库。用 dumpbin 查看依赖库通过 Visual Studio 工具链中的dumpbin /dependents查看PING.EXE依赖哪些 DLL。定位 ICMP 相关函数通过dumpbin /imports和findstr找到IcmpSendEcho2Ex、Icmp6SendEcho2。找到 IPHLPAPI.dllICMP 相关函数来自 IP Helper API也就是IPHLPAPI.dll。用 API Monitor 观察真实调用通过监控PING.EXE看到创建 ICMP handle、调用IcmpSendEcho2Ex、默认 TTL 等信息。转向 Rust 实现使用stable-x86_64-pc-windows-msvc工具链保证和 Visual Studio/MSVC ABI 兼容。不直接链接 IPHLPAPI而是运行时加载通过KERNEL32.dll提供的LoadLibraryA和GetProcAddress动态打开 DLL、取函数地址。理解 Win32 字符串和调用约定A/W后缀、C 字符串、空字节结尾、stdcall调用约定。Rust FFI 基础extern stdcall、裸指针、c_void、HMODULE、unsafe。第一个坑字符串没有\0结尾Rust 字符串切片不是 C 字符串传给 Win32 API 时要手动补空字节。GetProcAddress 与函数指针拿到函数地址后不能直接当函数调用。transmute 登场把原始地址重新解释成函数指针用来调用MessageBoxA。总结这一篇不是直接实现 ping而是先打通 Rust 调用 Win32 API 的基础能力。上一篇文章从计算机网络的历史讲起解释了为什么会有以太网、MAC 地址、IP、DNS、DHCP以及为什么ping这样一个小工具背后牵扯到整套网络协议栈。到了这一篇问题终于开始落到具体实现上Windows 自带的ping.exe到底是怎么发出 ping 请求的直觉上ping.exe不太可能自己从零实现所有底层协议。它不应该自己管理网卡不应该自己处理整个 IP 协议栈也不应该绕过操作系统直接和硬件说话。真正合理的模型是ping.exe调用某个 Windows 系统库系统库再进入内核或网络栈由操作系统负责完成实际的数据包发送与接收。因此这一篇的目标不是马上写出完整 ping而是先学会观察现有程序如何调用 Windows API再用 Rust 复现这种调用方式。这个过程会涉及 Windows 动态库、PE/COFF 文件、dumpbin、IPHLPAPI.dll、LoadLibraryA、GetProcAddress、调用约定、C 字符串、裸指针、unsafe和transmute。这些东西看起来离 ping 很远但如果想在 Windows 上自己实现一个低层网络工具绕不开它们。一、ping.exe 不会独自完成所有工作在 Windows 上ping.exe位于C:\Windows\System32\PING.EXE它是一个普通可执行文件。用户在命令行里输入ping 8.8.8.8屏幕上会显示请求是否成功、往返时间、TTL 等信息。表面看起来这是ping.exe自己做的事但从操作系统结构看它很可能只是调用了系统提供的 API。原因很简单。发送 ICMP Echo 请求需要经过操作系统网络栈最终还会通过网卡把数据发到外部网络。普通应用程序不应该直接操作硬件也不应该复制一份完整网络协议栈。Windows 已经提供了相关系统库和内核接口ping.exe更合理的做法是调用这些接口。在 Linux 上如果想知道一个可执行文件依赖哪些动态库常用工具是ldd。但在 Windows 上工具名称和生态不一样。Windows 可执行文件通常是 PE/COFF 格式动态库是.dll文件。要查看 Windows 可执行文件依赖哪些 DLL可以使用 Visual Studio 工具链里自带的dumpbin。这就引出了第一步搭建一个能分析 Windows 可执行文件的环境。二、用 Visual Studio 工具链查看 PING.EXE 依赖在 Windows 上按照 Microsoft 官方方式构建和分析程序通常需要安装 Visual Studio 或 Visual Studio Build Tools。完整 Visual Studio 体积不小但它包含很多有用工具例如编译器、链接器、调试器、分析工具以及这里要用到的dumpbin。安装 Visual Studio 之后可以打开 “Developer Command Prompt” 或类似名称的工具命令行。它本质上还是cmd.exe但已经配置好了环境变量可以直接使用 Visual Studio 工具链中的命令。普通命令行里可能找不到dumpbin但开发者命令行可以。先用下面的命令查看PING.EXE依赖了哪些动态库dumpbin /dependents C:\Windows\System32\PING.EXE这里的/dependents是dumpbin的参数。Microsoft 命令行工具经常使用/flag这种风格而不是 Unix 工具里常见的--flag。输出结果会列出一组 DLL。除了msvcrt.dll、ntdll.dll、各种api-ms-win-core-*之外还能看到两个比较关键的库IPHLPAPI.DLL WS2_32.dllWS2_32.dll很容易让人想到 Windows Sockets也就是网络编程常见的 Winsock。IPHLPAPI.DLL则更像 “IP Helper API”直觉上和 IP 网络管理、ICMP、路由表、网卡信息等有关。但光看到依赖库还不够。一个程序依赖某个 DLL并不代表 ping 功能一定来自它。下一步需要查看PING.EXE从这些 DLL 里具体导入了哪些函数。三、从导入函数里找到 ICMP Echo继续使用dumpbin可以查看一个可执行文件导入了哪些外部函数dumpbin /imports C:\Windows\System32\PING.EXE完整输出会比较长所以可以配合findstr搜索感兴趣的关键词。findstr可以粗略理解为 Windows 里的grep。先搜索pingdumpbin /imports C:\Windows\System32\PING.EXE | findstr /I ping/I表示大小写不敏感。这样可以同时匹配ping、PING、Ping等形式。搜索ping可能没有结果因为 API 名字未必叫 ping。换一个思路ping 的底层语义是 ICMP Echo Request 和 Echo Reply所以可以搜索echodumpbin /imports C:\Windows\System32\PING.EXE | findstr /I echo这时能看到类似下面的函数名IcmpSendEcho2Ex Icmp6SendEcho2这就基本确认了方向。IPv4 的 ping 很可能走IcmpSendEcho2ExIPv6 的 ping 则可能走Icmp6SendEcho2。这两个名字已经非常明确它们属于 ICMP Echo 相关 API。接下来还要确认这些函数来自哪个 DLL。dumpbin /imports的完整输出会按 DLL 分组列出导入函数简单搜索函数名只能看到函数未必能看到分组上下文。可以用 PowerShell 做更方便的文本处理或者直接查看完整输出。最终可以定位到相关函数来自IPHLPAPI.dll。这一步非常关键。到这里已经知道 Windows 自带ping.exe并不是自己手搓 ICMP而是调用了 IP Helper API 里的 ICMP 相关函数。后续自己写程序时可以沿着同一条路线调用这些函数。四、文档有用但真实程序更有用查到IcmpSendEcho2Ex之后当然可以直接打开 Microsoft 文档看它的函数签名、参数含义、返回值说明。但只看文档有一个问题文档告诉你 API “可以怎么用”却不一定告诉你一个真实程序“实际怎么用”。尤其是 Win32 API 这类历史悠久的接口经常有大量参数、结构体、可选项、兼容行为。文档读起来可能很完整但第一次调用时仍然不知道哪些参数必须填哪些可以传空哪些结构体必须提前初始化哪些行为只是示例代码里的习惯。这时可以用 API Monitor 观察真实程序。API Monitor 是一个可以监控 Windows API 调用的工具。它加载大量 API 定义然后允许选择某一组 API 进行 hook再启动或附加到目标进程观察目标程序到底调用了哪些函数、传了什么参数、返回了什么结果。这里可以选择 IP Helper 相关 API然后监控新启动的PING.EXE。执行几次 ping 之后就能看到它调用了哪些 ICMP 函数以及参数大概是什么样子。从监控结果里可以得到几条重要信息。首先发送 ping 之前需要创建一个 ICMP handle。其次IcmpSendEcho2Ex参数很多但不少参数可以留空。再次Windows 的PING.EXE默认选择的 TTL 是 128。TTL 是 Time To Live它表示一个 IP 包最多可以经过多少次路由跳转每经过一个路由器TTL 通常减一减到 0 就会被丢弃用来避免数据包在网络中无限循环。监控结果里还会出现一个看起来奇怪的目标地址比如134744072。它不像常见的 IP 地址写法但如果把它按字节解释就会发现它其实是8.8.8.8。每个8都是一个字节API Monitor 把四个字节整体解释成了 32 位整数所以显示成了十进制整数。这是观察底层 API 时很常见的现象工具展示的数值格式不一定就是人类熟悉的格式必须理解底层二进制表示。到这里Windows 原生 ping 的调用路径已经基本清楚ping.exe使用 Win32 API 发送 ICMP Echo 消息相关函数来自IPHLPAPI.dll用dumpbin可以静态查看依赖和导入函数用 API Monitor 可以动态观察真实调用过程。五、为什么接下来选择 Rust如果完全按照 Windows 生态来写最自然的选择可能是 C、C 或 C#。Win32 API 本来就以 C 接口形式存在用 C 调用这些函数最直接C 可以在此基础上做封装C# 则可以通过 P/Invoke 调用系统库。但这里选择 Rust是因为目标不是复制 Microsoft 文档里的示例代码而是借这个过程学习 Rust 如何和外部系统 API 交互。Rust 默认强调内存安全和类型安全而 Win32 API 是典型的 C 世界接口裸指针、空指针、手动约定、调用约定、动态库、函数地址。二者相遇时很多边界问题会暴露出来。在 Windows 上使用 Rust需要注意工具链后缀。通过rustup安装 Rust 后如果使用的是stable-x86_64-pc-windows-msvc那么最后的msvc表示它使用 MSVC 工具链ABI 和 Visual Studio 2019 这类 Microsoft 工具链兼容。ABI 是 Application Binary Interface应用二进制接口。它关系到函数调用时参数怎么传、返回值怎么放、栈怎么管理、符号怎么链接等底层约定。要和 Windows 系统库正确交互ABI 兼容很重要。新建一个 Rust 二进制项目后可以用cargo build构建再用dumpbin /dependents查看生成的.exe依赖哪些 DLL。一个最小 Rust 程序通常不会自动依赖IPHLPAPI.dll。这意味着如果要调用 ICMP 相关函数有两条路可以走一种是在构建阶段配置链接让程序直接链接IPHLPAPI.dll另一种是在运行时通过系统 API 动态打开IPHLPAPI.dll再取出需要的函数地址。这里选择第二种路线。它更绕但能学到更多底层知识Windows 如何动态加载 DLL如何通过函数名找函数地址Rust 如何声明外部函数如何处理 C 字符串如何把原始地址转换成可调用的函数指针。六、用 KERNEL32.dll 动态加载库一个最小 Rust 程序虽然不会链接IPHLPAPI.dll但通常会依赖KERNEL32.dll。KERNEL32.dll提供了很多基础 Win32 API其中就包括动态加载库相关函数。要在运行时打开一个 DLL可以使用LoadLibraryA或LoadLibraryW。Win32 API 里很多处理字符串的函数都有两个版本A和W。A通常表示 ANSI 版本历史上接近 ASCII 或系统代码页W表示 Wide 字符版本通常使用 UTF-16。现代 Windows 对字符编码有更多兼容行为但理解A/W后缀仍然很重要。看到LoadLibraryA就应该知道它接收的是类似 C 字符串的窄字符指针看到LoadLibraryW就应该想到 UTF-16 宽字符串。如果用 Rust 来想象LoadLibrary最理想的函数签名可能是fnLoadLibrary(name:str)-Handle但 Win32 API 不是 Rust 写的它不认识 Rust 的str。C 世界里传字符串常见方式是传一个指向字节序列的指针并用空字节\0表示字符串结束。因此LoadLibraryA更接近下面的形式fnLoadLibraryA(name:*constu8)-Handle这里的*const u8是 Rust 的裸指针类型表示指向不可变字节的原始指针。const表示这个函数不应该修改传入的数据u8表示无符号 8 位整数也就是一个字节。不过在 Rust 里调用外部函数需要用extern声明。因为函数体不在当前 Rust 程序里而是在某个外部动态库里。声明形式类似extern{fnLoadLibraryA(name:*constu8)-Handle;}但这样还不完整因为 Win32 API 有特定调用约定。七、调用约定为什么重要调用约定决定了函数调用时的底层细节参数放在哪里是放寄存器还是栈上返回值放在哪里函数调用结束后由调用方还是被调用方清理栈不同大小的参数如何对齐函数名如何修饰。这些东西平时写高级语言时很少直接接触但一旦跨语言调用就非常重要。如果调用约定写错程序可能立刻崩溃也可能看起来暂时能跑但在某个诡异位置出现内存损坏、栈错乱或调试器无法解释的错误。更麻烦的是调用约定错误不一定在调用点立刻暴露可能会污染后续执行状态让问题变得很难查。Win32 API 常见调用约定是stdcall。Rust 允许在extern声明中指定调用约定因此应该写成externstdcall{fnLoadLibraryA(name:*constu8)-Handle;}这里的重点不是背下stdcall这个词而是理解跨语言调用时函数签名不只是参数类型和返回值类型还包括 ABI 和调用约定。Rust 编译器必须知道外部函数如何被调用否则生成的机器码就可能和真实函数不匹配。接下来还需要处理返回值类型也就是前面签名里的Handle。八、Windows 里的 handle 与 HMODULEWindows API 里到处都是 handle。打开文件会得到 handle创建窗口会得到 handle打开进程会得到 handle加载模块也会得到 handle。handle 可以理解为系统资源的某种引用。它不一定暴露真实内部结构只是让调用方在后续 API 中用它代表某个资源。LoadLibraryA在 C 文档中的声明类似HMODULELoadLibraryA(LPCSTR lpLibFileName);这里的返回值是HMODULE。H很多时候表示 handleMODULE表示模块也就是加载进程地址空间里的 DLL 或 EXE 模块。LPCSTR可以拆成 Long Pointer to Constant String大概意思是指向常量 C 字符串的指针。在 Rust 里不知道HMODULE具体指向什么结构也不应该随意解引用它。更安全的表达方式是把它当作不透明指针。Rust 标准库提供了std::ffi::c_void可以用来表示 C 里的void。于是可以定义usestd::ffi::c_void;typeHModule*constc_void;externstdcall{fnLoadLibraryA(name:*constu8)-HModule;}这段声明表达了几个关键信息LoadLibraryA是外部 Win32 函数调用约定是stdcall参数是一个 C 字符串指针返回值是一个不透明模块句柄。到这里Rust 编译器已经知道如何生成调用这个函数的代码。但真正调用它时又会遇到 Rust 的安全边界。九、调用外部函数为什么需要 unsafeRust 的安全模型无法保证外部 C 函数的行为。LoadLibraryA不是 Rust 写的Rust 编译器不知道它会不会读取越界内存不知道传入指针是否有效不知道它是否会保存这个指针不知道它是否会修改全局状态也不知道它是否遵守 Rust 的别名和生命周期规则。因此调用extern函数需要放在unsafe块里。unsafe不是关闭所有检查也不是让代码必然危险而是告诉编译器这里有一些 Rust 无法验证的前提程序员需要自己保证它们成立。第一次尝试可能会写成这样usestd::ffi::c_void;typeHModule*constc_void;externstdcall{fnLoadLibraryA(name:*constu8)-HModule;}fnmain(){lethunsafe{LoadLibraryA(IPHLPAPI.dll.as_ptr())};println!({:?},h);}这段代码能表达大概意图把 Rust 字符串IPHLPAPI.dll的底层指针传给LoadLibraryA然后打印返回的模块句柄。但运行后可能会发现返回值是空指针也就是0x0。按照 Win32 API 的习惯LoadLibraryA返回 NULL 往往表示加载失败。到这里表面上已经做了很多正确的事找到了正确的 DLL 名称声明了外部函数指定了调用约定使用了不透明指针类型也放进了unsafe块。结果仍然失败说明问题藏在更基础的位置。问题出在字符串上。十、Rust 字符串不是 C 字符串传给LoadLibraryA的并不是一个“字符串对象”而只是一个内存地址。Rust 的字符串切片str自己知道长度但当调用.as_ptr()时拿到的只是指向第一个字节的裸指针。这个指针本身不携带长度信息。C 字符串的约定完全不同。C 函数通常不知道字符串长度它会从传入地址开始一个字节一个字节往后读直到遇到空字节\0才认为字符串结束。这就是 null-terminated string也就是以空字节结尾的字符串。因此传入IPHLPAPI.dll.as_ptr()并不等于传入一个合法 C 字符串。内存中这段字节后面不一定紧跟着0。LoadLibraryA可能继续读取后面的随机内存把额外字节也当成文件名的一部分。运气好时它读到某个空字节后停止但文件名已经不对所以加载失败运气不好时它可能一直读到非法地址造成访问违规或段错误。修复方式很简单手动给字符串加上\0fnmain(){lethunsafe{LoadLibraryA(IPHLPAPI.dll\0.as_ptr())};println!({:?},h);}加上空字节之后LoadLibraryA能正确识别 DLL 名称返回值也不再是空指针。这是 Rust 调 Win32 API 时非常典型的第一课Rust 字符串和 C 字符串不是同一种东西。只传裸指针时长度信息会丢失如果目标 API 期待 C 字符串就必须保证字符串以\0结尾。更正式、更不容易出错的写法通常会使用CString等类型但这一篇为了暴露底层细节直接用\0展示了问题本质。十一、加载 DLL 之后还要取函数地址LoadLibraryA只能把 DLL 加载进当前进程并返回模块句柄。一个 DLL 里可以导出很多函数真正调用某个函数之前还需要根据函数名拿到它的地址。Windows 提供了GetProcAddressFARPROCGetProcAddress(HMODULE hModule,LPCSTR lpProcName);hModule是前面LoadLibraryA返回的模块句柄lpProcName是函数名同样是 C 字符串。返回值FARPROC可以理解为某个导出函数的地址。由于它可能指向任何签名的函数所以在 Rust 里可以先把它表示成不透明指针usestd::ffi::c_void;typeHModule*constc_void;typeFarProc*constc_void;externstdcall{fnLoadLibraryA(name:*constu8)-HModule;fnGetProcAddress(module:HModule,name:*constu8)-FarProc;}为了先验证这套机制可以不急着调用 ICMP 相关函数而是试一个更直观的 Win32 API弹出消息框。消息框函数MessageBoxA位于USER32.dll。先加载USER32.dll再从里面取出MessageBoxA的地址fnmain(){unsafe{lethLoadLibraryA(USER32.dll\0.as_ptr());letfGetProcAddress(h,MessageBoxA\0.as_ptr());println!(f {:?},f);}}如果打印出来的函数地址不是空指针说明 DLL 加载成功函数地址也找到了。但这还不意味着可以直接调用它。对 Rust 来说f只是一个裸指针不是函数。裸指针不能像函数一样写f(...)调用。要真正调用它必须告诉 Rust这个地址代表一个具有特定签名和调用约定的函数。十二、MessageBoxA 的函数签名MessageBoxA的 C 声明大概是intMessageBoxA(HWND hWnd,LPCTSTR lpText,LPCTSTR lpCaption,UINT uType);它用于弹出一个 Windows 消息框。hWnd是父窗口句柄可以传空指针表示没有父窗口lpText是消息正文lpCaption是标题uType是按钮和图标等配置简单情况下可以传 0。换成 Rust 函数指针类型可以写成externstdcallfn(*constc_void,*constu8,*constu8,u32)为了可读性可以定义类型别名typeMessageBoxAexternstdcallfn(*constc_void,*constu8,*constu8,u32,);这里仍然要注意调用约定。如果函数真实调用约定是stdcallRust 里的函数指针类型也必须写成extern stdcall fn(...)不能省略。另外空指针不能直接用整数0代替。Rust 标准库提供了std::ptr::null()可以用它创建一个空的不可变裸指针。正文和标题仍然要以\0结尾因为MessageBoxA也期待 C 字符串。理想上可能想写成usestd::{ffi::c_void,ptr::null};typeMessageBoxAexternstdcallfn(*constc_void,*constu8,*constu8,u32,);fnmain(){unsafe{lethLoadLibraryA(USER32.dll\0.as_ptr());letfGetProcAddress(h,MessageBoxA\0.as_ptr());letMessageBoxA:MessageBoxAf;MessageBoxA(null(),Hello from Rust\0.as_ptr(),null(),0,);}}但这不会编译。原因也合理f是*const c_void也就是一个原始地址MessageBoxA是一个函数指针类型。Rust 不会自动相信“这个地址就是这个签名的函数”。这种转换太危险必须显式告诉编译器。这时就轮到transmute出场。十三、transmute把一个值重新解释成另一种类型std::mem::transmute是 Rust 里非常强力也非常危险的工具。它可以把一个类型的值按原始位模式重新解释成另一个类型而不做任何转换。也就是说它不会检查这个地址是不是真的指向一个MessageBoxA不会检查函数签名是否匹配也不会检查调用约定是否正确。它只是相信程序员的判断。在这个场景里GetProcAddress返回一个原始函数地址而我们知道这个函数名是MessageBoxA也知道它的 Win32 函数签名。因此可以用transmute把原始地址转换为对应函数指针usestd::{ffi::c_void,mem::transmute,ptr::null,};typeHModule*constc_void;typeFarProc*constc_void;typeMessageBoxAexternstdcallfn(*constc_void,*constu8,*constu8,u32,);externstdcall{fnLoadLibraryA(name:*constu8)-HModule;fnGetProcAddress(module:HModule,name:*constu8)-FarProc;}fnmain(){unsafe{lethLoadLibraryA(USER32.dll\0.as_ptr());letMessageBoxA:MessageBoxAtransmute(GetProcAddress(h,MessageBoxA\0.as_ptr()));MessageBoxA(null(),Hello from Rust\0.as_ptr(),null(),0,);}}运行后如果一切正确会弹出一个来自 Rust 程序的 Windows 消息框。这说明几个底层能力已经打通Rust 程序可以调用KERNEL32.dll中的LoadLibraryA可以动态加载USER32.dll可以通过GetProcAddress获取导出函数地址可以把这个地址转换成函数指针并最终按照 Win32 调用约定调用它。这一步虽然只是弹了一个消息框但它的意义很大。因为调用MessageBoxA和调用IPHLPAPI.dll里的 ICMP 函数本质上是同一类问题加载 DLL取函数地址定义正确的 Rust 函数指针类型处理 C 字符串和结构体放进unsafe边界里调用。十四、这一篇真正建立了什么能力表面上看这一篇还没有发送真正的 ICMP Echo 请求也没有实现完整 ping。它做的事情似乎只是研究ping.exe、加载 DLL、弹出消息框。但从工程路径看这一步非常必要。首先通过dumpbin /dependents和dumpbin /imports可以知道一个 Windows 可执行文件依赖哪些库、导入哪些函数。这是一种静态观察能力。它能帮助我们从现有程序反推出可能使用的系统 API。对PING.EXE来说这一步定位到了IcmpSendEcho2Ex、Icmp6SendEcho2和IPHLPAPI.dll。其次通过 API Monitor可以看到真实程序如何调用系统 API。这是一种动态观察能力。静态导入表只能告诉你“程序可能调用这些函数”但监控运行时调用可以告诉你“它实际调用了什么、参数大概是什么”。对学习 Win32 API 来说这比只读文档更直观。再次通过 Rust FFI可以让 Rust 程序进入 Windows C API 世界。这个过程迫使我们面对很多平时容易忽略的底层细节Rust 字符串和 C 字符串不同裸指针没有长度信息外部函数不受 Rust 内存安全保证调用约定必须匹配handle 可以用不透明指针表示函数地址不能直接调用transmute必须放在unsafe里并且使用时要非常确定目标类型正确。最后通过LoadLibraryA和GetProcAddress可以在运行时动态加载 DLL而不是在编译阶段静态链接。这种方式灵活也更适合探索。后续如果要加载IPHLPAPI.dll并调用IcmpSendEcho2Ex整体流程已经基本清楚。十五、几个容易踩坑的点这一篇最值得记住的不是某一段代码而是几个跨语言调用时反复出现的坑。第一个坑是字符串。Rust 的str有长度信息C 字符串靠\0结束。把.as_ptr()传给 C 函数时传过去的只是地址不是完整字符串对象。如果目标 API 期待 C 字符串就必须保证结尾有空字节。否则函数可能读过界、读到垃圾数据甚至触发访问错误。第二个坑是调用约定。extern stdcall不是语法装饰而是 ABI 的一部分。调用约定错了程序可能表现得非常诡异。跨语言调用时必须让 Rust 的函数声明和真实外部函数在调用约定、参数类型、返回值类型上保持一致。第三个坑是空指针和错误处理。Win32 API 很多函数用 NULL 表示失败比如LoadLibraryA或GetProcAddress返回空指针时通常说明没有加载成功或没有找到函数。示例代码为了讲清主线没有展开完整错误处理实际工程里应该检查返回值并调用GetLastError等方式获取错误原因。第四个坑是unsafe的边界。unsafe并不意味着代码一定错误也不意味着 Rust 不再有价值。它的意义是把编译器无法证明安全的部分圈出来让危险集中在少量地方。理想写法是用少量unsafe封装底层调用再向外暴露安全的 Rust API。第五个坑是transmute。它很强但几乎没有保护。把一个原始地址转换成函数指针时必须保证地址非空、函数真实存在、签名正确、调用约定正确、生命周期合理。任何一个前提错了都可能导致未定义行为或崩溃。能不用transmute时应尽量不用必须用时应该把前提写清楚并把它限制在很小范围内。十六、从消息框回到 ping为什么要先调用MessageBoxA而不是直接调用IcmpSendEcho2Ex因为MessageBoxA更容易验证。它的效果很直观调用成功就弹窗调用失败就没有弹窗或崩溃。相比之下ICMP 调用涉及更多结构体、缓冲区、网络权限、目标地址、返回数据解析第一次上手时更难判断错误发生在哪一步。先用USER32.dll和MessageBoxA练习动态加载与函数调用可以把问题拆小。只要能成功弹出消息框就说明 FFI 的基础路径没问题。后续切换到IPHLPAPI.dll只需要把 DLL 名、函数名、函数签名、参数和返回值换成 ICMP 相关接口。这也是学习底层系统编程时很有效的方法不要一上来就挑战完整目标而是先选一个可观察、可验证、依赖较少的小 API把调用链路打通。等动态库加载、函数地址获取、调用约定、字符串、裸指针、unsafe都跑通之后再处理复杂业务逻辑。在整个 “Making our own ping” 系列里这一篇的地位就是铺路。第一篇回答“网络为什么长这样”第二篇回答“在 Windows 上Rust 怎么调用系统 API”。后面真正发送 ping 请求时就不需要再临时解释什么是 DLL、什么是 calling convention、为什么要unsafe、为什么字符串要\0结尾、为什么要把地址转换成函数指针。十七、总结这一篇的主线可以概括成一句话先研究 Windows 自带ping.exe如何工作再让 Rust 具备调用同类 Win32 API 的能力。具体过程是用 Visual Studio 工具链里的dumpbin查看PING.EXE的依赖库和导入函数找到IcmpSendEcho2Ex、Icmp6SendEcho2确认 ICMP 相关能力来自IPHLPAPI.dll再用 API Monitor 观察真实ping.exe调用过程看到它会创建 ICMP handle、调用IcmpSendEcho2Ex并使用默认 TTL 等参数随后转向 Rust用stable-x86_64-pc-windows-msvc工具链保证 ABI 兼容最后通过LoadLibraryA、GetProcAddress、extern stdcall、裸指针、c_void、unsafe和transmute成功从 Rust 中动态加载 Windows DLL 并调用MessageBoxA。这条路看起来绕但它让后面的实现有了坚实基础。自己写 ping 并不只是了解 ICMP 包格式还要知道操作系统提供了什么能力用户态程序如何进入系统 API动态库如何加载函数地址如何变成可调用的函数指针Rust 的安全边界又在哪里。真正的底层编程经常不是“知道一个函数名就能调用”而是要把函数所在的库、ABI、调用约定、字符串格式、指针类型、错误返回和运行时加载方式全部对齐。只要这些底层规则中有一个错了程序就可能失败、崩溃或者更糟糕地在看似正常运行很久之后才暴露问题。因此这一篇虽然没有真正发出 ping 包但已经完成了非常关键的一步从 Windows 原生程序中找到 ICMP API 的线索并用 Rust 打通调用 Win32 API 的底层通道。下一步就可以把MessageBoxA换成IPHLPAPI.dll中的 ICMP 函数真正开始构造和发送自己的 ping 请求。
