Windows下用C++写的带图形界面的WinPcap抓包分析工具源码

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

简介：这是一个可在Windows上直接编译运行的图形化网络抓包工具源码包，基于WinPcap驱动实现底层数据捕获，使用Visual Studio MFC框架开发，包含完整的UI模块：网卡选择对话框、实时抓包启停控制、BPF语法过滤规则配置（FilterDl.cpp）、十六进制与ASCII双栏数据显示窗口（OutputDataDlg）。支持逐层解析以太网帧、ARP、IPv4、ICMP、TCP、UDP等主流协议，各协议解析逻辑封装在独立类中（如FramePacket.h、IPPacket.cpp、TCPPacket.cpp），能提取原始报文、还原关键字段（源/目的MAC/IP/端口、TTL、标志位、校验和等），并支持基础流量统计与帮助文档（help.CHM）。工程结构清晰，含全部资源文件（res/目录）、预编译头（StdAfx.cpp）、资源定义（resource.h）及VS6工程文件（.dsw/.dsp），无需额外配置即可加载编译。适合用于理解协议栈数据流转过程、教学演示网络通信细节，或作为轻量级局域网诊断工具的二次开发基础。

1. 项目概述：这不是一个“玩具”，而是一套能真正跑起来的协议教学沙盒

你手头拿到的这个源码包，名字叫“Windows下用C++写的带图形界面的WinPcap抓包分析工具”，听起来平平无奇，但如果你真把它在VS6里点开、编译、运行起来，再抓几个QQ登录包或浏览器HTTP请求看看——你会立刻意识到：这根本不是网上常见的那种“Hello World式”Demo，而是一个结构完整、逻辑自洽、能真实反映网络协议栈数据流转全过程的可执行教学沙盒。它不追求Wireshark那样的全协议覆盖和高性能过滤，但把从网卡驱动层到应用层展示的每一步都掰开了、揉碎了，用最朴素的C++类封装和MFC控件串联起来。关键词里提到的“WinPcap抓包”、“C++网络解析”、“MFC抓包工具”，每一个都不是虚词：wpcap.lib是它和物理网卡对话的唯一通道；FramePacket.h到ICMPPacket.cpp这一整套头文件与实现文件，构成了一个微型、可调试、可打断点的协议解析引擎；而OutputDataDlg那个双栏窗口，左边十六进制、右边ASCII，光标一停就能看到TCP标志位在哪一字节哪一位——这种“所见即所得”的调试体验，在纯命令行工具里是永远得不到的。

我第一次把它编译出来时，特意在宿舍局域网里抓了一个ARP请求包。当我在ARPPacket.cpp里打上断点，看着m_nOperation字段从0x0001（REQUEST）一步步被GetOperation()解析出来，再跳转到OutputDataDlg里，看到那行“Who has 192.168.1.100? Tell 192.168.1.1”的ASCII映射文本时，那种对协议“活过来”的实感，比看十遍RFC文档都来得直接。它适合谁？不是给想写企业级流量审计系统的工程师当脚手架——那太轻量；也不是给完全没碰过socket的新手当入门教材——那又略显硬核。它最适合的是已经学过《计算机网络》前五章、能画出TCP三次握手图、但还没亲手拆解过一个真实IP包的同学；也适合需要快速验证某个协议字段位置、或者给学生做课堂演示的讲师；甚至适合那些想给老旧工控设备加个简易通信诊断功能的嵌入式老兵——因为它的代码没有花哨的模板元编程，没有跨平台抽象层，就是干干净净的Win32 API + MFC + WinPcap三件套，改一行代码，编译一下，效果立现。它不教你如何设计高并发架构，但它会手把手告诉你：一个以太网帧的前6字节是目的MAC，紧接着6字节是源MAC，再2字节是类型字段，而当你判断出这是0x0800（IPv4）后，接下来的20字节才是IP首部——这些看似基础的知识点，在真实数据流里，从来不是静态的表格，而是动态的内存偏移和字节运算。这个项目，就是帮你把教科书上的箭头，变成VS调试器里的变量值。

2. 整体架构与设计思路：为什么是WinPcap + MFC + 分层类库？而不是libpcap + Qt 或者 .NET？

这套工具的架构选择，绝不是随手拍脑袋定的，而是由目标场景、开发年代和教学目的共同决定的。我们先拆开来看三个核心组件的选型逻辑：

第一，为什么是WinPcap，而不是libpcap或Npcap？
WinPcap是2000年代初Windows平台上事实标准的抓包驱动，它提供了一套稳定、成熟、文档齐全的C接口（pcap_open_live,pcap_next_ex,pcap_compile等），其底层通过NDIS Intermediate Driver直接与网卡交互，绕过了TCP/IP协议栈，从而能捕获到所有经过网卡的数据包，包括ARP、ICMP错误报文、甚至畸形包。而libpcap是Unix/Linux上的原生库，虽然有Windows移植版（如WinPcap本身最初就是libpcap的Windows分支），但直接用libpcap头文件在VS里编译，会遇到路径、链接器选项、驱动签名等一系列兼容性问题。至于Npcap，它是WinPcap的现代继任者，支持Win10/11、Loopback捕获、更安全的驱动模型，但它发布于2017年之后，而这个工程的.dsw（Visual Studio 6 Workspace）和.dsp（Project）文件明确指向VS6时代——那时候Npcap还没出生。更重要的是，教学目的决定了稳定性压倒新特性：WinPcap的API极其简单，pcap_t*句柄、struct pcap_pkthdr时间戳+长度、u_char*原始数据指针，三样东西就构成了整个数据获取链条，没有任何异步回调、事件循环的复杂抽象，新手一眼就能看懂while (pcap_next_ex(adhandle, &header, &pkt_data) >= 0)这行代码在干什么。换成Npcap，虽然多了npf.sys驱动和npcap.dll的便利，但也要多引入#include <Packet32.h>、#pragma comment(lib, "Packet.lib")等额外依赖，对“零配置即编译”的教学目标反而是一种干扰。

第二，为什么是MFC，而不是Qt或WinForms？
这个问题的答案藏在.dsw和.dsp文件里。Visual Studio 6（1998年发布）是MFC 4.2的黄金时代，而Qt在Windows上的成熟商用要等到2005年Qt 4.x之后；.NET Framework更是2002年才随VS.NET首次亮相。这个工程诞生的年代，MFC就是Windows原生GUI开发的唯一正统。它的优势在于：与Win32 API无缝衔接、资源编辑器（Resource Editor）可视化拖拽UI、消息映射宏（ON_BN_CLICKED,ON_COMMAND）让事件处理逻辑清晰可见。你看CapturePacketDlg.cpp里那一长串ON_COMMAND(IDC_START_CAPTURE, &CCapturePacketDlg::OnBnClickedStartCapture)，虽然现在看有点啰嗦，但每个按钮点击对应哪个函数，一目了然，没有信号槽的隐式连接，也没有XAML绑定的间接层。对于教学而言，MFC的“笨重”恰恰是优点：它强迫你去理解CDialog::DoModal()如何弹出模态对话框，CListCtrl::InsertItem()如何向列表控件插入一行，CDC::TextOut()如何在客户区绘图——这些底层细节，正是理解GUI程序运行机制的基石。换成Qt，connect(button, &QPushButton::clicked, this, &MyClass::onClicked)一行搞定，但“clicked信号是如何从操作系统消息队列冒泡上来的”这个问题，就被框架完美地隐藏了。

第三，为什么是“分层类库”设计，而不是一个大函数解析所有协议？
这是整个项目最具教学价值的设计。FramePacket.h、ARPPacket.h、IPPacket.h、TCPPacket.h……这些头文件不是为了炫技，而是严格遵循OSI七层模型（或TCP/IP四层模型）的思维导图。一个数据包进来，先被FramePacket解析出以太网首部（目的MAC、源MAC、类型）；如果类型是0x0806，就交给ARPPacket继续解析；如果是0x0800，则交给IPPacket；IP首部里的协议字段如果是6（TCP），再交给TCPPacket……这种“工厂模式+责任链”的解析流程，用C++的构造函数参数传递（TCPPacket::TCPPacket(const u_char* pkt_data)）和dynamic_cast（虽然本项目没用，但扩展时很自然）就能轻松实现。它带来的好处是：可测试性极强。你可以单独写一个main()函数，只传入一段伪造的TCP首部字节流（比如unsigned char tcp_raw[] = {0x00, 0x50, 0x00, 0x51, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x50, 0x02, 0x71, 0x10, 0x00, 0x00, 0x00, 0x00};），然后调用TCPPacket tcp(pkt_data); cout << "Source Port: " << tcp.GetSourcePort();，立刻验证端口解析是否正确。这种单元测试能力，在一个单文件巨函数里是无法想象的。而且，当你要添加对DNS协议的支持时，只需要新建DNSPacket.h/.cpp，在IP解析逻辑里加一句if (ip.GetProtocol() == 17 && udp.GetDestPort() == 53) new DNSPacket(udp.GetPayload());，整个架构无需伤筋动骨。这就是良好分层设计的力量：它让复杂问题变得可分解、可验证、可扩展。

3. 核心模块深度解析：从网卡驱动到ASCII显示，每一行代码都在讲一个网络故事

我们不再泛泛而谈“它能解析协议”，而是把源码树里最关键的几个文件拎出来，像解剖一只麻雀一样，逐层拆解它们是如何协作，把网卡上一闪而过的电信号，最终变成你屏幕上可读的“GET / HTTP/1.1”。这个过程，本质上就是一次完整的网络协议栈逆向工程。

3.1 网卡选择与驱动初始化：AdapaterSelection.cpp 是你的第一道门

打开AdapaterSelection.cpp，你会发现它继承自CDialog，核心逻辑在OnInitDialog()和OnOK()两个函数里。OnInitDialog()做的第一件事，是调用pcap_findalldevs(&alldevs, errbuf)——这是WinPcap的入口函数，它会枚举系统中所有可用的网络适配器（网卡），返回一个pcap_if_t*链表。这个链表里的每个节点，都包含适配器名称（如\\Device\\NPF_{A1B2C3D4-E5F6-7890-G1H2-I3J4K5L6M7N8}）、描述（如“Realtek PCIe GbE Family Controller”）、IP地址列表等信息。AdapaterSelection对话框的列表控件（m_AdapterList）就是靠遍历这个链表，把description字段填进去的。

这里有个极易被忽略但至关重要的细节：适配器名称（name）才是pcap_open_live()真正需要的参数，而不是你在网络连接里看到的“本地连接”这种友好名称。OnOK()函数里，当你选中某一项并点击确定，它会先通过m_AdapterList.GetCurSel()获取当前索引，再用这个索引去alldevs链表里找到对应的pcap_if_t*节点，最后取出->name字段，作为后续捕获句柄的创建依据。很多初学者在这里栽跟头，以为直接传“本地连接”字符串就行，结果pcap_open_live()返回NULL，errbuf里提示“no such device”。这是因为WinPcap根本不认识“本地连接”这个名字，它只认\\Device\\NPF_...这种内核对象路径。AdapaterSelection的存在，本质上就是为了解决这个“人名”和“身份证号”的映射问题。它还做了另一件聪明事：在OnInitDialog()末尾，调用了pcap_freealldevs(alldevs)，及时释放了pcap_findalldevs()分配的内存。WinPcap的API设计非常“C风格”，所有_findalldevs、_compile等函数分配的内存，都必须手动_free，否则就是内存泄漏。这个细节，恰恰是C/C++程序员和Java/Python程序员思维方式的根本差异：前者时刻绷着“谁分配谁释放”的弦，后者则交给GC。

3.2 数据捕获与线程控制：CapturePacketDlg.cpp 是心脏起搏器

CapturePacketDlg.cpp是主对话框，也是整个工具的控制中枢。它的核心成员变量pcap_t* m_adhandle，就是从AdapaterSelection那里拿到适配器名后，通过pcap_open_live(adapter_name, 65536, PCAP_OPENFLAG_PROMISCUOUS, 1000, errbuf)创建出来的捕获句柄。“65536”是快照长度（snaplen），意味着最多捕获每个包的前65536字节，这对绝大多数协议分析足够了；PCAP_OPENFLAG_PROMISCUOUS是混杂模式标志，开启后网卡会接收所有经过它的包，而不仅是发给自己的；“1000”是超时毫秒数，表示pcap_next_ex()最多等待1秒，避免无限阻塞。这个句柄一旦创建成功，就握住了网卡的“命脉”。

真正的捕获动作发生在OnBnClickedStartCapture()里。它首先检查m_adhandle是否为空，然后启动一个工作线程（AfxBeginThread(CaptureThreadProc, this)）。注意，这里没有用std::thread（那是C++11之后的事），而是MFC封装的AfxBeginThread，其线程函数CaptureThreadProc是一个静态成员函数，通过LPVOID pParam参数把this指针传进去，从而在线程内部可以访问CCapturePacketDlg的所有成员。线程函数的核心就是一个死循环：

while (m_bCapturing) { if (pcap_next_ex(m_adhandle, &header, &pkt_data) >= 0) { // 解析数据包，并发送到UI线程更新显示 ProcessPacket(header, pkt_data); } }

这里的关键是m_bCapturing这个布尔标志。OnBnClickedStopCapture()做的唯一一件事，就是把m_bCapturing设为false，从而让工作线程自然退出。这是一种非常经典且安全的线程退出方式，避免了TerminateThread()这种粗暴手段可能导致的资源未释放问题。ProcessPacket()函数则是整个解析流程的起点，它会根据pkt_data的首字节，判断这是以太网帧，然后创建FramePacket对象，开始层层解析。

3.3 协议分层解析引擎：FramePacket.cpp 到 ICMPPacket.cpp 是一套精密的瑞士军刀

现在，我们进入最核心的解析环节。假设ProcessPacket()收到了一个典型的HTTP GET请求包，pkt_data指向的是一段连续的内存，内容大致如下（十六进制）：

00 11 22 33 44 55 66 77 88 99 AA BB 08 00 45 00 01 C0 00 00 40 00 80 06 00 00 C0 A8 01 01 C0 A8 01 64 00 50 1F 90 00 00 00 00 00 00 00 00 50 02 71 10 00 00 00 00 00 00 47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A ...

FramePacket的构造函数会从pkt_data[0]开始，依次读取：
-m_DestMAC[6]：00 11 22 33 44 55
-m_SrcMAC[6]：66 77 88 99 AA BB
-m_Type：08 00→ 转换为ntohs()后是0x0800，确认为IPv4

接着，它调用GetPayload()方法，返回pkt_data + 14（以太网首部固定14字节）的指针，这个指针就交给了IPPacket。IPPacket的构造函数首先读取m_Version_IHL（版本+首部长度），这里是0x45，说明IP版本是4，首部长度是5×4=20字节。然后它计算出IP首部结束位置（pkt_data + 20），再读取m_Protocol字段（第10字节，此处为0x06），确认是TCP协议。于是，它再次调用GetPayload()，返回pkt_data + 20的指针，交给TCPPacket。

TCPPacket的构造函数就更有意思了。它首先要计算TCP首部长度。TCP首部有一个“数据偏移”字段（Data Offset），位于首部第12字节的高4位。这个字段的单位是“4字节”，所以实际首部长度 =(data_offset >> 4) * 4。在我们的例子中，pkt_data[12]是0x50，0x50 >> 4是0x05，所以TCP首部长度是20字节。这意味着，从pkt_data + 20开始的20字节，就是TCP首部；再往后，才是HTTP的GET / HTTP/1.1载荷。TCPPacket的GetSourcePort()方法，就是简单地读取首部第0-1字节（00 50），然后ntohs()转换为网络字节序，得到80端口。而GetFlags()方法，则是读取首部第12字节（0x50），然后用位运算flags & 0x02来判断SYN位是否置位（0x50 & 0x02 = 0x00，不置位），flags & 0x10来判断ACK位（0x50 & 0x10 = 0x10，置位）——这就是三次握手中“SYN-ACK”包的识别逻辑。

整个解析过程，没有一行魔法代码，全是基于RFC文档定义的固定偏移量和位操作。ARPPacket.cpp里解析m_nOperation字段，就是读取ARP首部第6-7字节；ICMPPacket.cpp里解析m_nType，就是读取ICMP首部第0字节。这种“指针+偏移+位运算”的原始手法，虽然不如现代序列化库（如Protobuf）优雅，但它让你彻底明白：协议，本质上就是一堆约定俗成的字节排列规则。当你在调试器里看到m_nType的值从内存里被准确读出为8（Echo Request），你就不会再把“ping”当成一个黑盒子了。

3.4 过滤规则与BPF语法：FilterDl.cpp 是你的数据筛子

FilterDl.cpp实现的是一个过滤器设置对话框。它的核心，是将用户输入的、类似"tcp port 80"这样的字符串，通过WinPcap的pcap_compile()函数，编译成一个高效的BPF（Berkeley Packet Filter）虚拟机指令数组，再用pcap_setfilter()将其应用到捕获句柄上。BPF是一种精简的汇编语言，pcap_compile()会把高级字符串翻译成一系列ld,jeq,ret等指令。

例如，"tcp port 80"会被编译成：
1.ldh [12]—— 加载以太网类型字段（偏移12）
2.jeq #0x800, continue, drop—— 如果不是IPv4（0x0800），跳转到drop
3.ldb [23]—— 加载IP协议字段（IPv4首部固定20字节，但BPF有优化，直接从23开始算）
4.jeq #6, continue, drop—— 如果不是TCP（6），跳转到drop
5.ldh [20]—— 加载TCP源端口（IP首部20字节 + TCP首部0字节）
6.jeq #80, accept, next—— 如果源端口是80，接受
7.ldh [22]—— 加载TCP目的端口（IP首部20字节 + TCP首部2字节）
8.jeq #80, accept, drop—— 如果目的端口是80，接受，否则丢弃

这个过程之所以重要，是因为它展示了性能与灵活性的平衡。如果不在内核驱动层过滤，而是把所有包都拷贝到用户态再用C++字符串匹配，那么千兆网卡每秒百万级的包，会瞬间拖垮你的CPU。BPF指令在npf.sys驱动里执行，只把符合条件的包复制上来，这是WinPcap高性能的基石。FilterDl.cpp的UI设计也很务实：它提供了一个编辑框让用户输入，旁边一个“编译”按钮，点击后调用pcap_compile()，如果返回失败，就把errbuf里的错误信息（如“syntax error”、“unknown protocol”）显示在对话框里，方便用户调试。这种即时反馈，是教学工具不可或缺的体验。

3.5 实时数据显示与双视图：OutputDataDlg.cpp 是你的数据显微镜

OutputDataDlg.cpp是整个工具的“脸面”，它用一个CListCtrl（列表控件）显示包摘要（时间、长度、协议、源/目的），用一个CEdit（编辑控件）显示原始数据的十六进制与ASCII双栏视图。它的核心挑战是：如何高效地、线程安全地，把工作线程解析出的数据，实时刷新到UI上？

答案是Windows消息机制。ProcessPacket()在解析完一个包后，不会直接调用OutputDataDlg的成员函数（因为那是UI线程的上下文，跨线程调用MFC控件是危险的），而是调用PostMessage(WM_USER_PACKET, WPARAM(ptr_to_packet_info), LPARAM(packet_length))，向主窗口发送一条自定义消息。CCapturePacketDlg的OnUserPacket()消息处理函数收到后，再把这个消息转发给OutputDataDlg的AddPacketToList()方法。AddPacketToList()内部，会调用CListCtrl::InsertItem()插入新行，并调用CListCtrl::SetItemText()设置各列文本。

而双栏视图的渲染，则是另一个精彩之处。OutputDataDlg维护一个std::vector<u_char>缓存，每次收到新包，就清空缓存，把pkt_data的header.len字节memcpy进去。然后，它用一个双重循环来格式化显示：

for (int i = 0; i < packet_size; i += 16) { CString line; // 左栏：地址 + 16字节十六进制 line.Format(_T("%04X "), i); for (int j = 0; j < 16; j++) { if (i+j < packet_size) line.AppendFormat(_T("%02X "), packet_data[i+j]); else line += _T(" "); } // 右栏：16字节ASCII line += _T(" "); for (int j = 0; j < 16; j++) { if (i+j < packet_size) { char c = packet_data[i+j]; line += (c >= 32 && c <= 126) ? c : '.'; } } m_HexEdit.SetSel(-1, -1); // 光标移到末尾 m_HexEdit.ReplaceSel(line + _T("\r\n")); }

这段代码的精妙在于，它没有使用任何第三方富文本控件，纯粹用CEdit的ReplaceSel()模拟了一个只读的、带自动换行的十六进制查看器。%04X确保地址对齐，%02X确保每个字节占两位，c >= 32 && c <= 126这个判断，精准地筛选出可打印ASCII字符（空格32到~126），其余一律显示为.。当你在Wireshark里看到熟悉的“0000 00 11 22 33 … GET / HTTP/1.1”，其背后的实现逻辑，不过就是这么几行朴实无华的C++代码。

4. 实操编译与运行指南：从VS6加载到抓到第一个包，避坑全流程

现在，让我们放下理论，真正动手。这套源码的目标环境是Visual Studio 6（VC6），这是它能“零配置即编译”的前提。如果你手头只有VS2019或VS2022，别急，我们有一套兼容方案。整个过程，我按“绝对不能错”的顺序，把每一个可能卡住你的地方都列出来，并附上解决方案。

4.1 环境准备：VS6是首选，但VS2019也能搞定

首选方案：Visual Studio 6（推荐用于教学）
下载并安装VS6（网上有ISO镜像），安装时务必勾选“Visual C++ 6.0”和“Microsoft Foundation Classes”。安装完成后，直接双击CapturePacket.dsw工作区文件，VS6会自动加载整个工程。此时，你可能会看到一个警告：“This project was created with a newer version of Visual C++…”，忽略它，因为.dsw/.dsp本身就是VS6的原生格式。

备选方案：Visual Studio 2019（推荐用于现代开发）
VS2019无法直接打开.dsw/.dsp，但可以“导入”。步骤如下：
1. 新建一个空的“MFC应用程序”项目（不要选“基于对话框”，选“基于对话框”即可，因为CapturePacketDlg就是对话框类）。
2. 在解决方案资源管理器中，右键项目名 → “添加” → “现有项”，然后把源码包里所有.cpp和.h文件（除了StdAfx.cpp和resource.h，这两个会自动生成）全部添加进来。
3. 关键一步：右键项目 → “属性” → “配置属性” → “常规” → “使用MFC” → 选择“在共享DLL中使用MFC”。
4. 同样在“配置属性” → “C/C++” → “常规” → “附加包含目录”，添加WinPcap的Include路径，例如C:\WpdPack\Include。
5. “链接器” → “常规” → “附加库目录”，添加WinPcap的Lib路径，例如C:\WpdPack\Lib。
6. “链接器” → “输入” → “附加依赖项”，添加wpcap.lib和packet.lib（packet.lib是WinPcap的辅助库，用于PacketOpenAdapter等旧API，虽然本项目主要用pcap_*，但加上更保险）。

提示：WinPcap SDK可以从官网（已归档）或各大技术论坛下载WpdPack_X.X.zip。解压后，Include和Lib文件夹就是你需要的。务必下载与你的VS版本匹配的SDK（32位或64位）。本项目是32位应用，所以用WpdPack\Lib\wpcap.lib，而不是WpdPack\Lib\x64\wpcap.lib。

4.2 编译前的三处关键修改（VS6和VS2019通用）

即使环境配好了，直接编译还是会报错。以下是三个必须手动修改的地方，它们是历史遗留问题，但改起来很简单：

修改1：解决stricmp函数未声明问题
在StdAfx.h（或任意一个被所有CPP包含的头文件，如CapturePacket.h）的顶部，添加：

#include <string.h> #ifndef stricmp #define stricmp _stricmp #endif

原因：stricmp是旧版CRT的函数，VS2015之后被_stricmp取代，而VS6用的就是stricmp。加这个宏定义，让新旧编译器都能识别。

修改2：解决snprintf函数兼容性问题
在OutputDataDlg.cpp或IPPacket.cpp中，如果出现snprintf调用，将其替换为_snprintf（VS6）或snprintf_s（VS2019）。更稳妥的做法是，在StdAfx.h里统一定义：

#ifdef _MSC_VER #if _MSC_VER >= 1400 // VS2005及以后 #define MY_SNPRINTF _snprintf_s #else #define MY_SNPRINTF _snprintf #endif #else #define MY_SNPRINTF snprintf #endif

然后在代码里用MY_SNPRINTF(buf, sizeof(buf), "%s", str)。

修改3：修正FilterDl.cpp中的pcap_compile参数
在FilterDl.cpp的OnCompileFilter()函数里，找到pcap_compile()调用。VS6的WinPcap头文件中，该函数原型是：

int pcap_compile(pcap_t *, struct bpf_program *, char *, int, bpf_u_int32);

而较新版本的头文件可能是：

int pcap_compile(pcap_t *, struct bpf_program *, const char *, int, bpf_u_int32);

如果编译报错“cannot convert parameter 3 from ‘char’ to ‘const char‘”，只需把filter_str变量声明改为const char* filter_str = ...即可。

4.3 运行时依赖与驱动安装：没有wpcap.dll，一切皆空

编译通过只是第一步，运行时还有两个硬性依赖：

依赖1：wpcap.dll
这个DLL必须放在你的可执行文件（CapturePacket.exe）的同一目录下，或者Windows系统目录（如C:\Windows\System32）里。最简单的方法，就是把WpdPack\DLLs\wpcap.dll复制到你的Debug/或Release/输出目录里。如果运行时报错“找不到wpcap.dll”，八成就是这个原因。

依赖2：WinPcap驱动（npf.sys）
这才是最关键的一步。wpcap.dll只是一个用户态接口，它背后需要npf.sys这个内核驱动来真正和网卡对话。你必须在目标机器上安装WinPcap。去WinPcap官网下载WinPcap_4_1_3.exe（这是最后一个稳定版），以管理员身份运行安装。安装过程中，它会自动安装npf.sys驱动，并注册为Windows服务。安装完成后，你可以在“设备管理器”的“网络适配器”下面，看到每个网卡多了一个名为“WinPcap NPF driver”的子项。如果没有这个子项，pcap_findalldevs()一定会返回空链表，AdapaterSelection对话框里就什么也选不了。

注意：WinPcap与Npcap不能共存。如果你之前装过Npcap，请先卸载它，再安装WinPcap，否则会有驱动冲突。

4.4 首次运行与抓包验证：从选择网卡到看见HTTP

一切就绪后，按下F5启动调试：
1.AdapaterSelection对话框弹出，你应该能看到至少一个网卡（如“以太网”或“WLAN”）。选中它，点“确定”。
2. 主窗口出现，点击“开始捕获”按钮。此时，状态栏应该显示“正在捕获…”。
3. 打开浏览器，访问任意一个HTTP网站（避免HTTPS，因为加密后看不到明文）。
4. 回到抓包工具，你应该能在列表里看到源源不断的包。找一个“TCP”协议、长度较大的包（>100字节），双击它。
5.OutputDataDlg窗口弹出，左侧是十六进制，右侧是ASCII。滚动到底部，你应该能看到清晰的GET / HTTP/1.1、Host:、User-Agent:等字段。

如果到这里都成功了，恭喜你，你已经亲手启动了一个真实的网络嗅探器。这个过程，比任何网络课程都更能让你理解：网络，不是抽象的概念，而是实实在在的、可以被你用指针读取的字节流。

5. 常见问题与排查技巧实录：那些让我熬夜到凌晨三点的坑

在帮几十个同学和同事搭建这个环境的过程中，我整理了一份“血泪史”问题清单。这些问题，99%都源于对Win32开发、MFC消息机制或WinPcap驱动模型的细微误解。我把它们按发生频率排序，并给出最直接的排查路径。

5.1 问题速查表

5.2 独家避坑技巧：来自一线调试的“野路子”

技巧1：用pcap_dump()保存抓包文件，用Wireshark交叉验证
当你的解析结果和Wireshark不一致时，不要盲目怀疑代码。在CaptureThreadProc()里，pcap_next_ex()成功后，立即调用：

pcap_dumper_t* dump = pcap_dump_open(m_adhandle, "debug.pcap"); if (dump) { pcap_dump((u_char*)dump, &header, pkt_data); pcap_dump_close(dump); }

然后用Wireshark打开debug.pcap，对比同一个包的解析结果。Wireshark是业界标杆，如果它和你的结果不同，那一定是你的偏移量算错了。这个技巧，能帮你把“我的程序有问题”这个模糊问题，精准定位到“IPPacket.cpp第42行，m_nTTL = pkt_data[8];应该是pkt_data[8]还是pkt_data[9]？”这种具体问题。

技巧2：在OutputDataDlg里加“原始数据长度”显示，秒杀越界读取
在OutputDataDlg的标题栏或状态栏，动态显示当前包的header.len值。这样，当你看到一个包的header.len是60，却在TCPPacket里试图读取pkt_data[60]（第61字节）时，一眼就能发现越界。这是一个极其简单，但效果拔群的调试辅助。

技巧3：禁用混杂模式（PCAP_OPENFLAG_PROMISCUOUS），专抓本机收发包
如果在复杂的网络环境（如公司内网、有防火墙）里抓不到包，先把pcap_open_live()的第三个参数从PCAP_OPENFLAG_PROMISCUOUS改成0（非混杂模式）。这样，WinPcap只会捕获发给本机或从本机发出的包，过滤掉其他主机的流量，大大降低干扰，更容易验证基础功能是否正常。

技巧4：用pcap_stats()做流量统计，反向验证捕获是否生效
在OnBnClickedStartCapture()里启动线程后，另起一个定时器（SetTimer()），每隔1秒调用一次：

struct pcap_stat stat; if (pcap_stats(m_adhandle, &stat) == 0) { TRACE(_T("Packets received: %d, dropped: %d\r\n"), stat.ps_recv, stat.ps_drop); }

如果ps_recv一直在增长，说明捕获是成功的；如果ps_drop远大于ps_recv，说明你的机器处理不过来，需要增大缓冲区（pcap_setbuff()）或降低捕获速率（增加pcap_open_live()的超时参数）。

6. 拓展与二次开发：从教学工具到你的专属网络助手

这个项目的价值，远不止于“能跑起来”。它的清晰架构和模块化设计，让它成为一个绝佳的二次开发起点。我来分享几个真实可行的拓展方向，每一个都只需要修改少量代码，就能带来质的提升。

6.1 添加HTTP协议解析：让OutputDataDlg直接显示URL和状态码

目前的OutputDataDlg只显示原始字节，而HTTP是应用层协议，它的解析逻辑完全可以加在TCPPacket之后。思路是：当TCPPacket解析出目的端口为80或源端口为80时，检查其载荷（GetPayload()返回的指针）是否以"GET "、"POST "、"HTTP/"开头。如果是，就新建一个HTTPPacket类：

class HTTPPacket { public: HTTPPacket(const u_char* payload, int len) : m_payload(payload), m_len(len) {} CString GetMethod() { /* 解析第一行，提取GET/POST */ } CString GetURL() { /* 解析第一行，提取/xxx路径 */ } CString GetStatus() { /* 解析响应行，提取200 OK */ } private: const u_char* m_payload; int m_len; };

然后在ProcessPacket()里，当检测到HTTP流量时，创建HTTPPacket对象，并把GetMethod()和GetURL()的结果，作为新列添加到CListCtrl里。这样，列表里就不再是枯燥的“TCP”，而是醒目的“HTTP GET /index.html”。这个改动，工作量不到50行代码，但用户体验提升巨大。

6.2 实现简单的流量统计面板：不只是抓包，还要会“看”

在主对话框里，添加一个CStatic控件，命名为IDC_STAT_PACKETS。在CaptureThreadProc()的循环里，用一个全局原子变量（LONG g_total_packets = 0; InterlockedIncrement(&g_total_packets);）来计数。然后在UI线程里，用一个定时器（SetTimer(1, 1000, NULL)）每秒更新一次：

void CCapturePacketDlg::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent == 1) { CString str; str.Format(_T("总包数: %ld"), g_total_packets); GetDlgItem(IDC_STAT_PACKETS)->SetWindowText(str); } }

更进一步，你可以用std::map<CString, int>来统计每个IP地址的通信次数，或者用std::map<int, int>来统计每个TCP端口的连接数，把这些数据用CListCtrl或CChartCtrl（需要额外引入）可视化出来。这已经是一个简易的网络流量监控仪表盘了。

6.3 将MFC界面迁移到现代UI框架：Qt或Dear ImGui

如果你厌倦了MFC的老式界面，这个项目的业务逻辑（抓包、解析、存储）是完全独立于UI的。你可以把CapturePacketDlg.cpp、ProcessPacket()、所有*Packet.cpp文件，全部封装进一个独立的静态库（.lib）或DLL。然后，新建一个Qt Widgets Application，创建一个QMainWindow，在它的槽函数里，调用你封装好的StartCapture()、StopCapture()、GetNextPacket()等接口。UI部分，用QTableWidget替代CListCtrl，用QTextEdit的setPlainText()替代CEdit::ReplaceSel()。这样，你保留了全部核心价值，却拥有了现代化、跨平台的界面。Dear ImGui更是轻量，几行代码就能做出一个极简的、游戏风格的抓包调试界面，特别适合嵌入到其他C++应用中。

这个源码包，就像一块未经雕琢的璞玉。它没有华丽的外表，但内里是扎实的网络原理、严谨的C++实践和清晰的软件工程思想。它不承诺给你一个企业级产品，但它保证，只要你愿意花上一个下午，跟着这篇文章，从安装驱动到看到第一个HTTP包，你对网络的理解，就会从二维的教科书，跃升为三维的、可触摸、可调试、可修改的真实世界。这，就是它最不可替代的价值。

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

简介：这是一个可在Windows上直接编译运行的图形化网络抓包工具源码包，基于WinPcap驱动实现底层数据捕获，使用Visual Studio MFC框架开发，包含完整的UI模块：网卡选择对话框、实时抓包启停控制、BPF语法过滤规则配置（FilterDl.cpp）、十六进制与ASCII双栏数据显示窗口（OutputDataDlg）。支持逐层解析以太网帧、ARP、IPv4、ICMP、TCP、UDP等主流协议，各协议解析逻辑封装在独立类中（如FramePacket.h、IPPacket.cpp、TCPPacket.cpp），能提取原始报文、还原关键字段（源/目的MAC/IP/端口、TTL、标志位、校验和等），并支持基础流量统计与帮助文档（help.CHM）。工程结构清晰，含全部资源文件（res/目录）、预编译头（StdAfx.cpp）、资源定义（resource.h）及VS6工程文件（.dsw/.dsp），无需额外配置即可加载编译。适合用于理解协议栈数据流转过程、教学演示网络通信细节，或作为轻量级局域网诊断工具的二次开发基础。

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