简介一套原创的 MFC 与 WinpCap 网络嗅探器源码面向具备一定 C 或 MFC 基础、正在钻研网络协议分析与数据包捕获的开发者。程序界面友好支持 IPv4、IPv6、ARP、ICMP、TCP、UDP、HTTP 等协议的实时解析可在 Visual Studio 中直接编译运行也可以作为网络课程综合实验的起点。资源包共二十二个文件以七个头文件和四个 C 源文件为核心附带解决方案、工程配置以及图标、界面资源压缩后仅一点九二兆字节目录结构简洁适合逐文件对照学习。目前已有五千三百九十九人学习下载。从源码中可以梳理 WinpCap 的抓包初始化、数据包循环捕获和协议解析流程界面与逻辑分层清晰关键函数注释清楚便于读者在理解后扩展协议类型或添加报文导出功能也能为课程设计或毕业设计提供完整参考。1. MFCWinPcap网络嗅探器这个旧组合为什么还能写出可用的snifferMFCWinPcap网络嗅探器是一类在Windows下用MFC对话框界面包装WinPcap抓包能力的桌面工具。网络问题排查到最后经常绕不开抓包装上现成抓包工具可以看图但要是想做一个轻量的sniffer放进自己的工具链MFC加WinPcap这个组合依然是最顺手的路子。MFC负责窗口、列表、按钮WinPcap负责打开网卡并拿回原始帧两者一拼就是一个能跑的嗅探器。它适合三类人刚学TCP/IP协议栈的程序员想在局域网内做流量统计的开发者以及需要把抓包结果嵌入到自有工具里的老C工程师。它不能替你把应用层解码都做全但完全足够把数据链路层到传输层看明白。2. 搭建开发环境WinPcap SDK与VS配置的参数细节2.1 先装驱动再装SDK顺序反了就是第一个坑很多第一次接触WinPcap的开发者会直接拿WpdPack解压出来写代码后开始链接结果运行程序时pcap_findalldevs返回空或者提示找不到wpcap.dll。原因很简单SDK只是头文件和lib真正抓包靠的是系统服务中的NPF驱动。WinPcap的完整安装包里既包含驱动也包含用户态dllSDK包只是给你编译用的。我一般会先执行一次完整安装让驱动和wpcap.dll进入系统再解压SDK到固定目录例如D:\WpdPack。之后写代码时配置工程路径不要去复制dll到exe目录WinPcap是系统级组件复制dll反而会覆盖版本导致驱动和用户态不匹配。需要特别留意的是安装程序会用管理员权限注册NPF服务。如果你的开发机是精简版系统或者安全策略比较严NPF服务可能在安装时被禁用。检查方法是在服务管理里找到名称为NPF的服务状态应该是已启动。如果没启动右键启动一次再回到你的嗅探器程序里枚举网卡。这个动作我每次装完新环境都会做一遍省下来的是后续抓包全部失败的排查时间。2.2 VS工程属性附加包含目录、库目录与预处理定义创建MFC对话框工程后先在解决方案视图里把工程属性打开。C/C - 常规 - 附加包含目录填入WpdPack\Include链接器 - 常规 - 附加库目录填入WpdPack\Lib链接器 - 输入 - 附加依赖项按顺序填入wpcap.lib、Packet.lib、ws2_32.lib。这里顺序很关键因为wpcap.lib会引用packet.dll的导出接口把Packet.lib放后面容易出LNK2019。预处理定义也是容易漏的项目属性 - C/C - 预处理器 - 预处理器定义加上WPCAP和HAVE_REMOTE。前者告诉头文件启用WinPcap特有接口后者启用远程抓包接口虽然我们通常只用本机网卡但宏缺了会在pcap_open之类的地方产生接口声明不一致。字符集方面由于WinPcap头文件大量使用char*最省事的方式是把项目字符集设为“使用多字节字符集”如果用Unicode所有接口调用都要自己做转码在这个项目里建议不和Unicode死磕。下表是我每次新建工程都会核对一遍的配置快照配置项值备注附加包含目录D:\WpdPack\Include不要用带空格的路径附加库目录D:\WpdPack\Lib选择对应架构的libWin32用WpdPack\Lib\x86附加依赖项wpcap.lib;Packet.lib;ws2_32.lib顺序不要调整预处理器定义WPCAP;HAVE_REMOTE两个宏都需要字符集使用多字节字符集MFC默认Unicode要改掉依赖项里的ws2_32.lib是Windows Socket库WinPcap的用户态接口最终要调用Socket相关功能。Packet.lib在旧版本SDK里有时不出现但如果你用pcap_sendpacket发包wpcap.lib内部会引用它所以写成显式依赖最稳。2.3 第一段代码枚举本机网卡列表配置完先写一段最小的代码验证SDK和环境能否工作。在CAboutDlg里临时放一个按钮点击后枚举本机网卡#include pcap.h #include winsock2.h pcap_if_t *allDevs NULL; pcap_if_t *dev NULL; char errBuf[PCAP_ERRBUF_SIZE]; if (pcap_findalldevs_ex(PCAP_SRC_IF_STRING, NULL, allDevs, errBuf) 0) { AfxMessageBox(errBuf); return; } CString strInfo; int idx 1; for (dev allDevs; dev ! NULL; dev dev-next) { strInfo.AppendFormat(%d: %s\n, idx, dev-description ? dev-description : dev-name); } AfxMessageBox(strInfo); pcap_freealldevs(allDevs);这段代码的逻辑是pcap_findalldevs_ex枚举系统里的网络接口第一个参数传PCAP_SRC_IF_STRING表示本机设备第二个参数prescan传NULL即可返回值小于0表示失败错误信息在errBuf里。遍历链表时description字段可能为空特别是某些虚拟网卡所以用三目运算符回退到name。最后一定要调用pcap_freealldevs释放链表否则每次点击都会泄漏一块内存。这个枚举结果可以作为打开设备时的网卡名直接传给pcap_open_live。和老的pcap_findalldevs相比_ex版本多了一个远程主机参数但传PCAP_SRC_IF_STRING就能覆盖本机场景。它的链表节点里除了name和description还有Addresses字段里面可以读到IP地址和掩码。如果你后续要做网段过滤提前把这个地址信息取出来存到内存里会比每次抓包再查一遍快得多。3. 抓包核心流程打开网卡、BPF过滤与循环抓包的参数细节3.1 pcap_open_livesnaplen、promisc和to_ms怎么选拿到网卡名后打开设备的标准调用是pcap_open_live。它的四个参数分别是设备名、抓包长度、混杂模式、超时时间外加错误缓冲区。第一个参数就是2.3中遍历出来的dev-name。snaplen决定每个包最多从网卡拷贝多少字节到用户态如果只做协议头解析65535完全够用不会截断任何常见MTU下的报文。如果设成54就只能看到帧头加IP头TCP载荷全丢常用于只统计流量大小而不关心内容。promisc参数要在自己的网卡上谨慎使用。设0时只收目标地址为本机或广播、组播的报文设1时把所有经过网卡的帧都收上来。日常调试建议设0只有在你确认有权限监控的网段做流量统计时才设1。to_ms是读取超时单位毫秒我一般设1000或500配合pcap_next_ex可以让抓包循环每一秒醒一次刷新界面。设成0时没有超时pcap_next_ex会一直阻塞到有包为止停止按钮很难响应。下面这段是打开设备的样板pcap_t *adHandle NULL; char errBuf[PCAP_ERRBUF_SIZE]; adHandle pcap_open_live(devName, 65535, 0, 1000, errBuf); if (adHandle NULL) { AfxMessageBox(errBuf); return; }如果打开失败错误信息会通过errBuf带回。这里注意pcap_open_live返回NULL是唯一的失败判断devName要保证不是空指针建议先把网卡列表填充到下拉框再让用户选择不要在代码里硬编码网卡名。还有一种情况是网卡被其他程序独占WinPcap允许多个pcap_t同时打开同一个设备但某些网卡驱动对底层句柄有限制至少我遇到过打开第二个句柄后第一个抓包循环开始丢包的现象。后来同一时间只保留一个抓包线程问题就消失了。3.2 BPF过滤编译过滤器和内核级抓包WinPcap的过滤器走的是BPF机制过滤条件在网卡驱动里执行不是把包抓到用户态再丢弃所以效率高。pcap_compile和pcap_setfilter是两步操作。过滤语法很灵活例如“ip or arp”只收IP和ARP报文“tcp port 443”只收HTTPS流量“not udp”排除UDP。第一个参数是打开的pcap_t第二个参数存放编译后的bpf_program第三个参数optimize传1让编译器做优化第四个参数netmask一般传0xFFFFFFFF即可只有在需要对外部主机做广播路由优化时才需要网卡的真实掩码。下面这段展示了完整设置流程struct bpf_program fcode; if (pcap_compile(adHandle, fcode, ip or arp, 1, 0xFFFFFFFF) 0) { AfxMessageBox(过滤器编译失败); pcap_close(adHandle); return; } if (pcap_setfilter(adHandle, fcode) 0) { AfxMessageBox(设置过滤器失败); pcap_freecode(fcode); pcap_close(adHandle); return; } pcap_freecode(fcode);pcap_compile返回负数说明过滤表达式语法不对常见错误是拼写比如把“tcp port”写成“tcp portt”或者括号不匹配。pcap_setfilter执行后编译好的程序会提交给驱动之后就可以释放fcode了。有个细节过滤串在界面里让用户输入时一定要先校验长度老库没有溢出保护超长字符串可能导致解析异常。如果你需要同时抓多个端口可以写“tcp port 80 or tcp port 443”BPF的优先级是“or”低于“and”所以必须用括号把条件分组写“tcp and (port 80 or port 443)”更明确。3.3 抓包循环pcap_next_ex返回值的三态语义抓包主循环我习惯用pcap_next_ex而不是pcap_loop。pcap_loop是回调模型需要在回调里做解析和界面更新一旦回调函数执行时间太长底层缓冲区会丢包。pcap_next_ex每次调用返回一个状态码放在自己的while循环里更好控制。返回值只有三种1表示成功拿到一个包0表示在指定超时时间内没有包-1表示错误或驱动被卸载。代码是这样的struct pcap_pkthdr *header NULL; const u_char *pktData NULL; int ret 0; while (!m_bStop) { ret pcap_next_ex(adHandle, header, pktData); if (ret 1) { ParsePacket(header, pktData); } else if (ret 0) { ProcessPendingMessages(); } else { AfxMessageBox(抓包过程中出错); break; } }header里的pcap_pkthdr结构包含ts、caplen、len三个关键字段。ts是时间戳caplen是实际拷贝到缓冲区的字节数len是原始包长度。正常情况下caplen等于len如果snaplen设置太小或者网卡发生截断caplen会小于len。解析代码一律以caplen为准否则会越界读取。m_bStop是一个volatile型成员在停止按钮里置TRUE。这里要解释一下如果你在对话框按钮事件里直接改成循环等待m_bStop变为TRUE同样会卡住因为抓包线程还在pcap_next_ex里等待新包。正确做法是停止按钮里调用pcap_breakloop(adHandle)让阻塞的pcap_next_ex立即返回-1退出循环后再去收尾线程。底层缓冲区也是影响抓包完整性的关键。默认的内核缓冲区可能不够大在高流量网段下用户态来不及取包就会丢。常见做法是增加一句pcap_setbuff(adHandle, 1048576)把缓冲区扩到1MB。如果你的机器内存吃紧512KB也够大部分场景。这个参数不需要每个工程都调但做压力测试时丢包率异常先看这里。4. 协议解析实战从以太网帧头到TCP/UDP载荷的读取要点4.1 以太网帧头类型字段与VLAN标签的偏移抓到的pktData第一个字节就是目的MAC地址。以太网头固定14字节结构很简单6字节目的MAC、6字节源MAC、2字节上层协议类型。用结构体强转能提高可读性但必须把结构体紧凑对齐。我习惯在文件头部加上#pragma pack(1)和#pragma pack()包裹。代码#pragma pack(1) typedef struct _EthHeader { u_char dstMac[6]; u_char srcMac[6]; u_short ethType; } EthHeader; #pragma pack()读取协议号必须用ntohs因为网络序是大端X86小端机拿到的是倒过来的字节。常见的etherType是0x0800表示IPv40x0806表示ARP0x86DD对应IPv6。解析时先看ethType如果不是IPv4直接跳过。有一个所有新手都会踩的坑如果网络里启用了VLAN帧头里可能插入一个VLAN Tag此时ethType字段变成0x8100真正的类型在VLAN Tag之后这两字节需要再偏移4字节才能读到。判断逻辑要写成“如果是0x8100继续读下一段”否则IP层的解析数据全是错的。我就在办公网里遇到过这种现象因为交换机默认允许VLAN抓包显示ethType都是0x8100当时排查了很久才发现这个偏移问题。4.2 IP头首部长度、分片偏移与协议字段的正确读法IPv4头在没有选项的情况下固定20字节起始位置在以太网头之后14字节处。IP头结构可以定义成下面这样但注意首部长度字段只有4位表达的是以4字节为单位的长度所以真实长度是(verIhl 0x0F) * 4范围20到60字节。如果你直接用固定的20字节偏移去定位TCP头遇到带选项的包就会错位。#pragma pack(1) typedef struct _IPHeader { u_char verIhl; u_char tos; u_short totalLen; u_short id; u_short flagOff; u_char ttl; u_char protocol; u_short checksum; u_long srcAddr; u_long dstAddr; } IPHeader; #pragma pack()verIhl的高4位是版本号判断它等于4再继续低4位才是首部长度倍数。totalLen是包括IP头在内的完整IP包长度用ntohs读出来这个值可以用来做边界检查避免把下一帧数据误当成载荷。protocol字段为6时走TCP17走UDP。srcAddr和dstAddr各4字节标准做法是inet_ntoa转成点分字符串。但inet_ntoa返回的静态缓冲区不是线程安全的抓包线程和界面线程同时用时可能显示成同一个地址。我自己用一个线程安全的转换函数拿u_long值自己拼sprintf比调库函数放心。分片字段flagOff也要注意只有分片偏移为0的包才带有TCP/UDP头。非首片分片的IP载荷是原始IP数据里面没有端口信息如果强行按TCP解析会读到分片内容当端口数值完全不可信。实际项目中我一般先输出“IP分片”标记跳过传输层解析。还有一种情况是IP协议字段是ICMP此时没有TCP/UDP头解析分支单独处理或不处理都行。4.3 TCP/UDP解析端口、序列号与载荷定位TCP头最少20字节最多60字节区别是选项区。结构定义时offset字段的低4位是保留位高4位才是数据偏移乘以4。所以TCP头长度是(offset 4) * 4。flags字段是低8位控制位判断SYN、ACK、RST时用位运算与。端口、序列号都是网络序端口用ntohs序列号直接用ntohl转成主机序。下面定义结构#pragma pack(1) typedef struct _TCPHeader { u_short srcPort; u_short dstPort; u_long seq; u_long ack; u_char offsetFlags; u_char flags; u_short window; u_short checksum; u_short urgentPtr; } TCPHeader; #pragma pack()源端口和目的端口在TCP头的偏移0和2很多教程把整个TCP头画成一行一行的图但你只要记住前4个字节是端口然后是4字节序列号和4字节确认号。读取时用ntohs转换端口号得到的值可以直接显示在列表里。TCP载荷的起始位置是IP头起始位置加IP头长度加TCP头长度。计算前先做两层边界检查IP总长度要大于IP头长度捕获长度caplen要大于到载荷的偏移否则丢弃。UDP更简单固定8字节2字节源端口、2字节目的端口、2字节长度、2字节校验和。载荷位置在IP头加8字节处UDP长度字段包含UDP头本身用来判断包是否被截断。写解析时我把TCP和UDP分成两个函数参数是IP头指针、IP总长度和caplen函数内部各自计算偏移并返回载荷位置上层界面只负责显示。解析结果建议整理成一个统一的结构体包含协议类型、源IP、目标IP、源端口、目标端口、载荷长度和载荷指针。抓包线程拿到原始帧后逐层移指针每层偏移一旦算错后面全是乱的。最好的验证方式不是看界面显示而是让程序把每个包的前20个字节以十六进制打印出来自己先用现成抓包工具看过一遍再对照。5. 排查与避坑MFCWinPcap开发常见问题与5个典型翻车现场在MFC工程里集成WinPcap代码本身不难难的是环境和线程模型。下面几条是几乎每个开发者都会遇到的坑按“现象、原因、解决”写清楚。5.1 现象pcap_findalldevs返回成功但列表为空原因WinPcap的驱动服务没有启动最常见是只安装了SDK没有安装完整的WinPcap运行环境。另一个可能是安全策略限制了NPF服务加载导致底层接口枚举不到设备。解决重新以管理员身份运行WinPcap安装包安装完成后确认服务列表里名为NPF的服务是已启动状态。开发机和运行机都要装运行环境把SDK当运行库用是错的。安装后如果还为空检查是否在虚拟机环境某些虚拟机网卡驱动与WinPcap兼容性较差换桥接模式通常比NAT模式更容易被识别到。5.2 现象pcap_open_live返回NULL错误信息是“拒绝访问”原因WinPcap的用户态接口在打开设备时要求管理员权限。非管理员运行时即使枚举列表成功打开设备也会被拒绝。解决在VS工程属性里把UAC执行级别设为requireAdministrator这样编译出来的程序默认请求管理员权限。如果你是双击运行exe对exe右键属性-兼容性-以管理员身份运行也可以但不适合正式场景。更干净的做法是写manifest文件但MFC工程直接改链接器清单文件设置更方便。注意UAC级别设成最高后每次调试都会弹一次权限确认这是正常的不要关掉UAC来逃避弹窗。5.3 现象结构体强转后读出的MAC地址和端口是乱序的原因没有用紧凑对齐编译器在结构体成员间插入填充字节比如u_char类型后紧跟u_short时会自动对齐到2字节边界导致源端口读错。另一个原因是网络序没转主机序小端机器上直接读u_short得到的值是倒的。解决所有网络协议头结构都包在#pragma pack(1)里并用#pragma pack()结束。读多字节字段时统一用ntohs、ntohl不要图省事用memcpy。如果MAC地址显示成字节反着就是字节序问题不是结构体问题。这里有个通用的验证方式把抓到的第一个包的前14字节用十六进制打印出来比对源头MAC是否等于本机网卡的物理地址如果偏移正确打印出来的源MAC应该和你网卡地址一致。5.4 现象链接时报错LNK2019找不到pcap_findalldevs等符号原因附加依赖项顺序不对或者缺少某些库。WinPcap的开发库依赖Packet.lib而Packet.lib又依赖ws2_32.libWindows Socket库必须排在后面。解决在链接器-输入-附加依赖项里按wpcap.lib、Packet.lib、ws2_32.lib的顺序填写。如果用了远程抓包接口还要确保预处理定义WPCAP、HAVE_REMOTE都在这样wpcap.lib才会导入正确的接口。不要在代码里手动#pragma comment(lib,wpcap.lib)和项目配置混用只保留一处。另外旧版SDK的lib是按32位编译的如果你的MFC工程是x64平台一定要确认WpdPack\Lib\x64路径下有对应库文件否则链接器可能会退回到x86目录导致一把串。5.5 现象抓包线程里调用UpdateData或SendMessage界面卡死原因pcap_next_ex在工作线程中阻塞工作线程向主线程SendMessage同步派发窗口消息主线程此时正好在等待抓包循环返回或处理其他消息两线程互相等待形成死锁。另一种情况是pcap_loop回调函数里直接操作界面WinPcap的回调线程和MFC消息循环交错一样会卡。解决抓包和界面解耦。抓包线程只负责解析和把数据放进线程安全的队列或链表界面刷新用PostMessage发给主窗口PostMessage是异步的发出去立即返回不等待主线程处理。抓包循环里用m_bStop标志配合pcap_breakloop具体做法是停止按钮里把标志置True并调用pcap_breakloop(adHandle)让阻塞的pcap_next_ex立即返回-1再在循环外做一个等待线程退出的操作。不要让每个包都发一次窗口消息可以攒够50个或100个再发一次降低消息风暴的概率。我自己是把解析好的包描述结构体按批次放进一个CArray然后PostMessage一个自定义消息主窗口在处理函数里把整个批量复制出来再刷新列表。6. 把抓包结果可视化PostMessage异步刷新与导出pcap文件的实用技巧6.1 用PostMessage给主窗口发自定义消息MFC里消息映射用ON_MESSAGE(WM_PACKET_UPDATE, CMainFrame::OnPacketUpdate)。抓包线程在解析完一组包后调用PostMessage(HWND, WM_PACKET_UPDATE, 0, 0)主窗口处理器里再去更新列表控件。这样做既避免锁死又让所有GUI操作回到主线程符合MFC的线程模型。我一般攒一批包再刷一次不要抓到一包就立即刷新否则高速网络下界面会拖垮抓包性能。6.2 用虚拟列表CListCtrl承载解析结果解析结果多时逐条InsertItem会导致界面越来越慢。切换到LVS_OWNERDATA虚拟列表模式先SetItemCount(总包数)再在OnGetDispInfo里根据索引填充文本。这样列表控件是按需取数据内存里只保留一个包描述结构体数组包数量过万也不会卡。有个细节数据源用CArray存放包描述结构体抓包线程往末尾Add时要用临界区加锁主线程复制数据时也走同一把锁不要用SendMessage跨线程拿指针那样等于又回到同步死锁的老路上。6.3 导出标准pcap文件的字节序处理导出功能其实很值钱能把抓到的包交给其他工具做深度分析。pcap文件头是24字节魔数后面每包一个16字节包头加原始数据。写入时注意文件头魔数0xa1b2c3d3用字节序决定文件字节序x86小端直接fwrite即可。每包的时间戳用pcap_pkthdr里的ts.tv_sec和ts.tv_usec分别写入长度字段写成原始len和caplen。最后别忘了在文件末尾做一次fflush避免程序异常退出时丢数据。我常用的导出代码是打开时先写全局文件头然后每抓到一个包就追加一个包头和数据停止时关闭文件。这样抓包过程本身就能边抓边存不会等到最后再统一处理。写完导出功能后我习惯抓一个包导出的文件用现成工具打开对比一下包数量和长度能对得上就说明自己的偏移和字节序全对了。从那以后每次改协议解析代码我都强制走一遍“自定义导出-外部工具比对-界面显示”的验证流程这个习惯救了我好几次。希望帮到你。本文还有配套的精品资源点击获取