简介基于MFC框架与WinPcap开发库实现的网络嗅探器源代码工程适合具备C基础、希望学习网络数据包捕获与协议解析的Windows开发者。程序界面友好支持IPv4、IPv6、ARP、ICMP、TCP、UDP及HTTP等主流协议的抓包与解析可用于局域网流量监测、网络故障排查及协议分析入门实践。压缩包约1.92MB包含22个文件以7个头文件、4个C源文件及Visual Studio工程文件为主另含界面图标、资源脚本等整体结构清晰易于在VS环境中打开编译与二次开发。已有5398人学习下载适合作为网络编程与嗅探器开发的参考例程可帮助读者理解WinPcap抓包流程、MFC界面与后台线程协作方式以及多协议解析模块的组织思路。1. 为什么还要自己写一个 MFCWinPcap 网络嗅探器前阵子调一个现场问题服务端口通着但业务就是不对我需要在 Windows 那台机器上看 TCP 层到底交出了什么。Wireshark 功能全但启动重过滤表达式写起来也得想半天于是翻了翻手头的 MFC 工程干脆自己写一个网络嗅探器。WinPcap 负责从网卡把原始帧截下来MFC 负责把解析结果摆到界面上这个组合虽然老但做抓包调试依然顺手而且能把 TCP/IP 协议栈的每个字节都在代码里过一遍。这个项目是我自己从零写的不是套开源壳子做完之后对网络排障的理解会扎实很多。适合谁做网络调试的、写毕业设计的、以及想在 C 桌面开发上练手的人。市面上 MFC 教程大多讲控件和对话框真正把抓包线程、协议解析、界面刷新串起来的少本文就是补这个缺口。2. 破包流程先想清楚以太网帧头、IP 偏移与 TCP 载荷的切分写任何一个 sniffer第一步不是打开网卡而是把“抓到的一个字节数组”翻译成有意义的协议字段。WinPcap 从网卡拷贝出来的是完整的数据链路层帧一个典型的 IPv4/TCP 帧长这样先是 14 字节以太网头然后是以太网类型字段里指出的上层协议如果是 0x0800 就是 IPv4IPv4 头默认 20 字节后面跟着 TCP 头默认也是 20 字节最后才是 HTTP 这类应用层载荷。解析顺序不能乱偏移算错一个字节后面全错。这一章把破包的步骤、代码和容易翻车的小细节一次讲完。2.1 以太网帧头第一刀切在偏移 0 的 14 个字节以太网头的结构很固定6 字节目的 MAC、6 字节源 MAC、2 字节类型字段一共 14 字节。类型字段常见取值有 0x0800IPv4、0x0806ARP、0x86DDIPv6。注意 WinPcap 给的数据是网络字节序大端所以类型字段要用ntohs转成主机字节序再比较直接拿memcmp(eth-ether_type, \x08\x00, 2)也没问题。#pragma pack(push, 1) typedef struct _ETH_FRAME { BYTE dst_mac[6]; // 目的 MAC BYTE src_mac[6]; // 源 MAC WORD ether_type; // 以太网类型需 ntohs 转换 } ETH_FRAME; #pragma pack(pop) // 判断是否为 IPv4 帧 const ETH_FRAME* eth (const ETH_FRAME*)frame; if (ntohs(eth-ether_type) ! 0x0800) { return; // 只处理 IPv4ARP/PPPoE 等先跳过 }代码里的#pragma pack(push, 1)很关键。C/C 结构体默认按 4 字节对齐编译器会在成员之间插入填充字节如果不禁用对齐sizeof(ETH_FRAME)就不是 14 而是 16后面的所有偏移全部错位。这是一个非常隐蔽的坑结构体定义看起来没错解析结果却全是乱的。另外如果帧里带了 802.1Q VLAN 标签以太网类型字段会变成 0x8100真正的类型藏在 VLAN 头后面的 2 字节里这时要从偏移 14 再往后跳 4 字节即 18 字节处才是 IP 头。不少教程直接跳过这个情况但真实局域网里带 VLAN 的帧并不少见抓包解析不出东西时值得怀疑一下。2.2 IP 头与 TCP 头协议字段和头长字段怎么读以太网头之后是 IP 头编程时要特别关注两个字段第一个字节的低 4 位是 IP 头长度IHL单位是 4 字节默认值是 5表示 20 字节但如果 IP 带了 Options这个值会变大。不能用固定偏移去取 TCP 头必须先读 IHL 再乘 4。第二个要关注的是第 9 字节从 IP 头起始算的 protocol 字段6 表示 TCP17 表示 UDP我们只对 TCP 感兴趣。#pragma pack(push, 1) typedef struct _IP_HEADER { BYTE ver_ihl; // 高 4 位版本号低 4 位头长单位 4 字节 BYTE tos; WORD total_len; WORD ident; WORD frag_off; BYTE ttl; BYTE protocol; // 6TCP, 17UDP WORD checksum; ULONG src_ip; ULONG dst_ip; } IP_HEADER; #pragma pack(pop) const IP_HEADER* ip (const IP_HEADER*)(frame 14); int ip_len (ip-ver_ihl 0x0F) * 4; // 头长度乘 4 if (ip-protocol ! 6) { return; // 只处理 TCP }IP 头之后是 TCP 头。TCP 头同样有长度字段在第十二字节的高 4 位叫数据偏移单位也是 4 字节。为什么要单独读出来因为 TCP 头可以带选项比如时间戳、MSS选项长度不固定。把 IP 头长度和 TCP 头长度都算出来后载荷指针就是frame 14 ip_len tcp_len。这里有个必须做的防御每次访问字段前都要判断帧长度够不够比如14 ip_len tcp_len frame_len就要直接丢弃。我第一次写这段时偷懒没检查结果抓包一小时程序突然崩溃pcap_next_ex的返回值一直正常其实内存已经被读穿了这是血泪经验。#pragma pack(push, 1) typedef struct _TCP_HEADER { WORD src_port; WORD dst_port; ULONG seq; ULONG ack; BYTE offset_reserved; // 高 4 位是数据偏移 BYTE flags; WORD window; WORD checksum; WORD urgent; } TCP_HEADER; #pragma pack(pop) int tcp_len ((tcp-offset_reserved 4) 0x0F) * 4; const BYTE* payload frame 14 ip_len tcp_len; int payload_len frame_len - (14 ip_len tcp_len);2.3 为什么要跨包重组HTTP 请求可能被拆成多个 TCP 段如果你抓一次打开网页的流量会发现请求头很少整整齐齐地躺在一个包里。TCP 是字节流协议它不关心应用层的消息边界发送方可以把一个 HTTP 请求拆成两个包发也可以把两个请求合并成一个包发。常见的拆法有几种第一种是 TCP 分段一个超过 MSS 的包会被拆开第二种是 TCP Offload 引擎把用户态缓冲直接切块交给网卡切点可能落在请求头中间第三种是接收方 ACK 时序导致的重传和乱序也会让载荷不连续。因此严谨的嗅探器必须做流重组用一个 key源 IP、目的 IP、源端口、目的端口唯一标识一条 TCP 连接每个方向各自维护一个字节队列收到包就往队列尾部追加载荷然后从队列里按\r\n\r\n切出完整 HTTP 头。最小实现思路是std::mapFlowKey, CByteArrayFlowKey 里存好四个字段重载小于运算符然后循环里map[key].Append(payload, payload_len)再去缓存里查找请求行和 Host 头。不过如果目标只是观察 URL 和排障单包解析加 Host 头匹配已经能覆盖大多数场景。我的建议是先把单包解析跑通再考虑流重组一步到位容易把调试复杂度拉高反而打击信心。3. 环境搭建把 WpdPack 接进 MFC 工程处理安装失败与链接错误WinPcap 要跑起来需要两样东西内核驱动 NPF安装 WinPcap 时注册进系统负责从网卡拷贝数据用户态库 wpcap.dll也就是开发时链接的wpcap.lib对应的动态库。开发时还需要 WpdPack 这个开发包里面有头文件和导入库。环境搭建的坑集中在驱动装不上、工程配置不对、运行时找不到 DLL 三处下面按顺序讲。3.1 驱动装不上“vivado winpcap安装失败”这类提示的共同原因很多软件安装包会顺带装 WinPcap网上搜“vivado winpcap安装失败”现象大多是安装程序执行到一半弹错误或者装完了但设备管理器里看不到 NPF 驱动。这类问题我从自己经历和帮人排查中总结原因基本是三选一。第一是权限不够NPF 驱动要写入系统驱动目录并注册服务必须以管理员身份运行安装程序。第二是系统兼容性Win10 和 Win11 对老版 WinPcap 的驱动签名不认可安装程序报告成功但驱动加载失败。第三是残留冲突以前装过另一套抓包驱动没卸载干净新驱动服务注册不进去。解决顺序我一般是右键安装包选择“以管理员身份运行”如果还不行卸载干净后重启再装依旧不行改用 Npcap 安装包安装时勾选“WinPcap API Compatibility Mode”。Npcap 是 WinPcap 的现代替代品兼容模式下会提供 wpcap.dll原有的 MFC 代码不需要改就能编译运行。这一步做完环境问题基本就能止损不要在报错后反复重装同一份安装包那是玄学。3.2 Visual Studio 工程配置预处理宏、附加目录与链接库驱动有了接下来把开发包接进工程。下载 WpdPack 压缩包解压后目录里会有 Include 和 Lib 两个文件夹。在 Visual Studio 里打开 MFC 工程属性按下面配置Project ItemDefinitionGroup ClCompile PreprocessorDefinitionsWPCAP;%(PreprocessorDefinitions)/PreprocessorDefinitions AdditionalIncludeDirectoriesC:\WpdPack\Include;%(AdditionalIncludeDirectories)/AdditionalIncludeDirectories /ClCompile Link AdditionalLibraryDirectoriesC:\WpdPack\Lib;%(AdditionalLibraryDirectories)/AdditionalLibraryDirectories AdditionalDependencieswpcap.lib;ws2_32.lib;%(AdditionalDependencies)/AdditionalDependencies /Link /ItemDefinitionGroup /Project上面的内容适合存成WinPcap.props文件在工程的属性管理器里右键“添加现有属性表”导入Debug 和 Release 共用这一份。要注意WPCAP这个预处理宏不能少它决定头文件是否声明 WinPcap 的扩展接口ws2_32.lib也要加上WinPcap 库内部调用了 Winsock 的字节序转换函数缺了它链接会报 unresolved external symbol。打开设备、抓包这些 API 的说明都集中在pcap.h里建议装一个 Visual Assist 或直接看头文件别只在网页上查零碎答案。3.3 运行时“wpcap.dll 找不到”与设备列表为空编译链接通过只是第一步双击 exe 运行可能出现“找不到 wpcap.dll”或“找不到 wpcap.dll 的依赖项”。解决办法是把 WpdPack 的Lib目录下对应平台x64 或 x86的 wpcap.dll 复制到 exe 所在目录。不推荐塞进 System32因为机器上有多个工程用不同版本的 WinPcapDLL 冲突会互相覆盖exe 目录隔离最省心。设备列表为空则先确认是否以管理员身份运行程序。WinPcap 打开设备需要管理员权限非管理员下pcap_findalldevs可能返回 0 个设备这是权限问题不是代码问题。另外无线网卡在部分驱动上抓不到 802.11 帧调试抓包建议插有线网卡。为了快速确认环境是否可用可以先写个控制台函数把设备名和描述打印出来pcap_if_t* alldevs NULL; char errbuf[PCAP_ERRBUF_SIZE]; if (pcap_findalldevs(alldevs, errbuf) -1) { TRACE(Lpcap_findalldevs error: %S\n, errbuf); return; } for (pcap_if_t* dev alldevs; dev ! NULL; dev dev-next) { TRACE(Lname: %S\n, dev-name); if (dev-description ! NULL) { TRACE(Ldesc: %S\n, dev-description); } } pcap_freealldevs(alldevs);打印不出设备名的优先级顺序是管理员权限、网卡是否禁用、驱动是否真正加载成功。确认环境这一步不要省我见过太多人代码写到一半才发现装的是另一台机器的驱动直接推翻重来。4. 用 WinPcap 抓包设备枚举、pcap_open_live 参数与线程协作环境通了核心逻辑就两件事把网卡打开然后循环收包。WinPcap 提供的 API 不算多但参数里藏着玄机特别是超时和混杂模式这两个概念直接影响抓包线程能不能及时退出、能不能收到想要的流量。这一章把设备枚举、打开参数和线程协作一次说透。4.1 枚举网卡pcap_findalldevs 返回的不只是设备名pcap_findalldevs枚举出的每个pcap_if_t结构体里name字段才是传给pcap_open_live的设备名description只是给人看的说明文字比如“Realtek PCIe GbE Family Controller”。有人图省事用 description 去匹配设备或者从下拉框选中后手动拼接设备名结果打开时老是报“No such device exists”。正确做法是把 name 直接存到下拉框的数据里选中什么就用什么。pcap_if_t里还有一个flags字段与PCAP_IF_LOOPBACK按位与可以判断是不是回环设备。WinPcap 原生抓不到本机 127.0.0.1 回环流量所以在设备枚举阶段就把回环设备过滤掉可以免得后续白忙活。4.2 pcap_open_live 的三个参数promisc、snaplen、to_ms打开设备的函数签名是pcap_open_live(const char* device, int snaplen, int promisc, int to_ms, char* errbuf)三个关键参数分别是m_handle pcap_open_live(dev_name, 65535, 1, 1000, errbuf); if (m_handle NULL) { AfxMessageBox(CString(L打开设备失败: ) CString(errbuf)); return FALSE; }snaplen是每个包最多拷贝多少字节到用户态。有人为了省内存把它设成 128结果 TCP 载荷被截断HTTP 解析必然失败。我一般设 65535也就是让每个包都完整拷贝性能开销并没有想象中大现代 CPU 完全扛得住。promisc设为 1 表示打开混杂模式网卡会把目的 MAC 不是自己的帧也交到上层协议栈这是嗅探器的必要条件。注意混杂模式在交换网络里只对广播帧、组播帧和本机收发流量有效不是半双工时代那种“能看到网线上所有比特”的效果想抓其他主机流量得在交换机上做端口镜像。to_ms是读超时单位毫秒设置为 1000 表示内核缓冲里没有数据时每 1 秒返回一次让抓包线程有机会检查停止标志如果设成 0pcap_next_ex会一直阻塞停止按钮点了没反应。这三个参数是一组配套缺一个都会在后续调试里翻车。4.3 抓包线程与 UI 线程PostMessage 而不是直接刷控件MFC 界面下抓包工作必须放在工作线程里否则界面会假死。常见做法是用AfxBeginThread开启抓包线程线程函数里循环调用pcap_next_ex抓到包后组装成一个对象通过PostMessage投递给主窗口主窗口的消息处理函数负责解析和刷新控件。UINT SniffThread(LPVOID param) { CMySnifferDlg* dlg (CMySnifferDlg*)param; pcap_t* handle dlg-m_handle; struct pcap_pkthdr* header NULL; const u_char* pkt_data NULL; int res 0; while (!dlg-m_bStop) { res pcap_next_ex(handle, header, pkt_data); if (res 1) { CPacketData* pkt new CPacketData(header, pkt_data); if (dlg-PostMessage(WM_SNIFFER_PACKET, (WPARAM)pkt, 0) FALSE) { delete pkt; // 窗口已关闭消息发不出去必须手动释放 } } else if (res 0) { // 超时无包继续循环顺带检查停止标志 } else { TRACE(Lpcap_next_ex error: %S\n, pcap_geterr(handle)); break; } } return 0; }为什么不用pcap_loop的回调方式回调是在 WinPcap 内部线程执行的你在回调里直接操作 CListCtrl 或 CStatusBar跨线程访问 UI 控件在 MFC 里是未定义行为轻则闪烁重则崩溃。PostMessage把数据交给主窗口的消息队列由主线程处理才是安全的做法。注意消息投递失败时要把对象 delete 掉否则PostMessage失败一次就泄漏一块内存跑一晚上量一大还是能看出内存涨。我在CPacketData的构造函数里直接memcpy一份帧数据这样pkt_data指向的缓冲区被 WinPcap 复用也不受影响后续解析完全基于自己持有的副本避免了一类很隐蔽的野指针问题。5. 踩坑排查pcap_next_ex 返回值、乱码、状态栏刷新与驱动安装这一章整理的坑都是我在调试这个 MFCWinPcap 嗅探器时真实撞过的每一条都能让你少折腾半天。按“现象、原因、解决”的顺序写方便对照排查。5.1 pcap_next_ex 返回 0 不是出错是超时现象程序跑一会儿自动停止明明网卡有流量但列表不再增长。原因把pcap_next_ex的返回值当成了布尔值返回 0 时以为出错了直接 break 退出线程。这三个返回值的语义是1 表示成功读到一个包0 表示超时时间内没有收到包这不是错误-1 才是真的出错此时要调pcap_geterr(handle)看原因。解决把 0 和 -1 分开处理0 继续循环-1 才退出。int res pcap_next_ex(handle, header, pkt_data); if (res 1) { // 正常收到包投递给 UI } else if (res 0) { // 超时不要 break继续循环等待 continue; } else { TRACE(Lpcap_next_ex error: %S\n, pcap_geterr(handle)); break; }初学者还容易犯另一个错把to_ms设成 0 想“永远等待”结果线程阻塞在pcap_next_ex里停止标志永远没机会被检查。记住to_ms是超时也是心跳1000 毫秒是比较合理的折中既能及时响应停止命令又不会因为空转把 CPU 拉满。5.2 Unicode 工程里抓到的主机名全是乱码现象MFC 工程默认使用 Unicode 字符集把payload里的字节直接赋给CString结果中文 URL、中文参数在界面上显示成一串乱码。原因WinPcap 给的是原始字节流编码是 UTF-8 或 GBK 取决于服务器和页面不是宽字符。直接用CString的宽字符构造函数会把每个字节当成一个 16 位字符完全错乱。解决解析阶段用CStringA保存原始字节只有当确认这段数据是可打印的 ASCII 时再转成 Unicode 显示。CStringA raw((const char*)payload, payload_len); CString display; if (raw.GetLength() 0) { int wlen MultiByteToWideChar(CP_UTF8, 0, raw, -1, NULL, 0); MultiByteToWideChar(CP_UTF8, 0, raw, -1, display.GetBuffer(wlen), wlen); display.ReleaseBuffer(); }转码代码里的CP_UTF8不是万能钥匙。国内很多 HTTP 站点返回的是 GBK 编码这时要分别在 CP_UTF8 和 CP_ACP 之间做尝试判断转码后是否包含0xFFFD这类替换字符。更稳妥的做法是界面上保留一份原始十六进制视图字符显示乱码时可以对照十六进制确认数据本身没丢这是排障时的后悔药。5.3 状态栏显示抓包统计“mfc状态栏怎么显示”这道坎现象状态栏不显示统计信息或者显示了但每个包里都刷新一次界面闪烁卡顿鼠标拖动窗口都费劲。原因有两层一是没有在状态栏上正确添加 Pane只用了默认的ID_SEPARATOR指示器二是刷新时机不对在PostMessage处理里每收到一个包就调SetPaneText高频刷新把 UI 线程拖死了。解决先定义一个包含两个指示器的数组一个是分隔符另一个是新加的 Pane然后SetPaneInfo设置拉伸方式统计信息用定时器聚合每秒刷一次。static UINT indicators[] { ID_SEPARATOR, // 第一个窗格显示提示信息 IDS_PACKET_INFO // 第二个窗格自定义显示抓包统计 }; m_statusBar.SetIndicators(indicators, 2); m_statusBar.SetPaneInfo(1, IDS_PACKET_INFO, SBPS_STRETCH, 0); // 每秒由定时器触发一次刷新统计 void CMySnifferDlg::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent 1) { CString strInfo; strInfo.Format(L总包数: %d HTTP: %d, m_totalPackets, m_httpPackets); m_statusBar.SetPaneText(1, strInfo); } CDialogEx::OnTimer(nIDEvent); }“mfc状态栏怎么显示”这类问题在网上能搜到很多代码片段但很少有教程提醒你状态栏刷新频率要和抓包频率解耦。我的做法是抓包线程只累加计数器主线程每秒读一次计数并刷新这样即使每秒抓到几千个包状态栏也只会刷新一次界面的流畅度完全是两个级别。现在有不少 AI 工具能补全 MFC 控件代码但如果你让它直接写抓包线程里的状态栏刷新它很容易给出一段“每个包都 SetPaneText”的代码逻辑上没错但运行起来就是这样卡死这是“看起来对”的典型例子。5.4 混杂模式没生效网卡收到的还是只有自己的流量现象开着嗅探器发现抓到的包全部是本机自己收发的网络里其他主机发到网关的广播帧也看不到。原因现代交换网络是点对点转发交换机会根据目的 MAC 把帧只发给对应端口混杂模式让本机网卡接收到达本端口的所有帧但交换机不是集线器不会把别的端口的数据复制过来。这不是代码问题是网络架构的边界。解决调试本机应用抓本机流量完全够用要抓其他主机的流量只能在交换机上配置端口镜像SPAN 或 RSPAN把目标端口的流量复制到你的端口。另外WinPcap 抓不到 127.0.0.1 回环流量如果你想验证 HTTP 客户端向本机服务发请求用回环地址是抓不到的改成抓本机到网关的真实 IP 流量或者换 Npcap 开启 loopback 抓包支持。做工具要先知道工具的边界这个问题就属于“折腾半天其实不是 bug”的类型。6. 把抓包结果翻译成人话URL 提取、验证与后续方向6.1 提取 URLHost 头和请求行的配合抓包线程把原始帧投递到主线程后解析逻辑首先要做的是从 TCP 载荷里找 HTTP 请求。只解析请求行GET /index.html HTTP/1.1是不够的因为现在的 HTTP/1.1 请求大多是相对路径完整 URL 需要把请求行里的路径和Host头拼起来。我的解析函数大致是这样CString ParseHttpUrl(const BYTE* payload, int len) { CStringA raw((const char*)payload, len); int line_end raw.Find(\r\n); if (line_end 0) return L; CStringA request_line raw.Left(line_end); if (!(request_line.Left(4) GET || request_line.Left(5) POST )) { return L; // 不是 HTTP 请求跳过 } CStringA path request_line.Mid(request_line.Find( ) 1); int path_end path.Find( ); if (path_end 0) path path.Left(path_end); // 取 Host 头 int host_pos raw.Find(Host:); if (host_pos 0) return L; CStringA host_line raw.Mid(host_pos 5); int host_end host_line.Find(\r\n); if (host_end 0) host_line host_line.Left(host_end); host_line.Trim(); CString result; result.Format(Lhttp://%S%S, host_line, path); return result; }这个函数只处理单包内的请求跨包拆分的 HTTP 头会解析失败但用于观察流量已经够用。拼接完成后可以用扩展名过滤掉图片和静态资源避免列表被logo.png这类 URL 刷屏。6.2 用真实流量做对拍验证工具写完必须验证。我的验证方法是在浏览器里刻意打开一个纯 HTTP 的站点不要开 HTTPS观察嗅探器输出的 URL 和浏览器地址栏、F12 开发者工具 Network 面板里的请求是否一致。多试几个场景URL 带中文参数、页面发 POST 表单、URL 里有%20这类编码。再进一步用 Wireshark 抓同一段流量找一个包的十六进制字节手工算出 IP 头、TCP 头偏移验到自己解析出的 HTTP 载荷位置和 Wireshark 标注一致为止。只要这一步对了说明解析逻辑和偏移计算都是可靠的。6.3 还能往哪走环回流量、HTTPS 解密与协议扩展这个项目还能继续扩展的方向很多把单包解析升级成流重组就能完整还原被拆分的 HTTP 请求接入 Npcap 的 loopback 抓包就能调试本机服务对 HTTPS 流量做 SNI 提取解析 TLS ClientHello 里的 server_name 字段可以知道连接了哪个域名解析 DNS 响应把访问过的域名和 IP 对应起来展示。我现在的习惯是写这类工具第一版先用黑窗口把解析结果打印出来确认每条协议逻辑都对了再套 MFC 界面界面美化永远放最后。做嗅探器的真正收获不是那个列表而是把“网线里流过的字节”在脑子里成像的能力。希望帮到你。本文还有配套的精品资源点击获取
