VC++ Sniffer源码全解析：从网卡驱动到MFC抓包工具

VC++ Sniffer源码全解析：从网卡驱动到MFC抓包工具

发布时间：2026/10/4 13:44:16
VC++ Sniffer源码全解析：从网卡驱动到MFC抓包工具 简介面向C语言与网络编程学习者的VC网络抓包程序源码包属于经典sniffer嗅探器实现适合希望理解网卡数据包捕获原理、NDIS驱动接口及MFC界面开发的读者。压缩包共44个文件其中16个.h头文件负责数据结构、协议常量和接口声明8个.cpp文件承载对话框、视图及抓包逻辑另有dsw/dsp工程配置bmp/ico图形资源Packet32的def、dll、vxd等底层支持文件readme说明以及Release版exe整体仅78KB目录清晰。已有780人学习下载。源码包含GetPacket与Packet32两大模块前者提供MFC界面、列表展示和过滤条件后者封装对网卡驱动的访问二者结合可完整梳理从收包、过滤到协议字段解析的流程代码中使用Packet32库与NDIS接口对理解Windows下网络数据包捕获原理很有帮助。附带的exe可直接运行观察效果也能在VC环境重新编译调试适合网络编程入门、课程设计甚至毕业设计作为参考。1. 网络抓包不是玄学从VC Sniffer源码看穿网卡流量下班前最怕运维同事甩来一句话“内网怎么突然卡了你看下是不是哪台机器在狂发包。”这时候手边有个能抓包的工具比什么都管用。VC Sniffer这类程序的价值就在这它把一个网卡上“看不见的流量”变成屏幕上一个一个可读的帧。这份源代码包是典型的Visual C 6.0时代作品前半部分是Packet32驱动源码后半部分是一个MFC单文档抓包程序Release目录里还留着编好的GetPacket.exe。对想搞懂网络抓包原理、或者需要在自己程序里嵌入抓包能力的开发者来说它比装一个现成抓包库更有学习价值因为你从网卡驱动到应用层解析一整条链路都在源码里摆着想改哪一层都能改。2. 抓包原理与工程骨架Packet32驱动、MFC界面与源码目录怎么配合2.1 抓包为什么难在“Adapter”从网卡到应用层的两次搬运标准的Socket接口只能收自己进程的包想让网卡把所有经过的帧都交给你就必须借道网卡驱动。常见做法是装一套NDIS中间层驱动网卡驱动把每一帧复制一份给中间层中间层再通过设备IO把数据搬到用户态。这套源码里的Packet32就是干这件事的。它在Windows 9x下对应zpacket.vxd在NT系列下对应Packet32.dll加底层驱动。你看到的PACKOFF.H和PACKON.H这两个文件是打包pragma用来控制驱动与用户态通信时的结构体对齐防止两边内存布局对不上。刚读驱动代码的人容易晕其实只要记住一条主线网卡驱动、NDIS、设备控制这三层把原始帧送进你的应用。在这个工程里GetPacket.exe是MFC程序Packet32.dll是驱动在用户态的接口库zpacket.vxd是Windows 95/98时代的内核虚拟设备驱动。整套代码今天拿来编译、学习、改造成自己的工具都行但直接拿到Win10/11上跑就得看驱动兼容性这个到第4章再展开。理解分层是第一步用户态程序调用Packet32.dll提供的函数DLL再通过DeviceIoControl这类接口访问内核驱动驱动把网卡上的包拷到缓冲区。所以抓包程序的性能瓶颈往往不在解析代码而在这一条搬运链上能不能把缓冲区开得足够大。2.2 源码目录拆解哪些文件决定程序能不能跑我拿到这种源码包不会急着先编译整个解决方案而是先把文件角色理一遍。这个包里的文件看起来很多实际归成四类就清楚了文件/目录角色建议关注点GetPacket.dsw / GetPacket.dspVC 6.0工作区与项目文件导入工程时的入口GetPacket.cpp / GetPacketDoc.cpp / GetPacketView.cppMFC单文档程序骨架界面与数据模型怎么配合Packet32.c / Packet32.dll / Packet32.def用户态抓包库核心调用链抓包的主战场Packet32.dsp / Packet32.dswPacket32库的独立工程单独编库时用PACKOFF.H / PACKON.H / DEVIOCTL.H / NTDDNDIS.H内核通信与对齐控制结构体布局的关键zpacket.vxdWindows 9x内核驱动现代系统用不上但值得读实现ipaddr.h / ipaddr.cppIP地址辅助工具地址转换、掩码判断protocol.h协议头常量与结构定义解析层的入口FileterDlg.cpp / FileterDlg.h抓包过滤对话框注意拼写是Fileter不是Filterres / toolbar1.bmp / Toolbar.bmp界面资源图标、工具栏、版本信息我一般会先把Packet32子工程单独编一次确认驱动库能出DLL再回头编上层的GetPacket工程。因为这个工程的运行顺序比较讲究GetPacket.exe启动时需要Packet32.dll在PATH里能找到。你只编GetPacket子工程、不编Packet32跑起来就会报“找不到Packet32.dll”。Release目录里虽然带了现成的动态库但你自己改过代码之后就得两个工程一起编DLL输出目录也得设到exe旁边不然新改的逻辑根本不生效。这里还有一个考古细节FileterDlg这个类名是当年作者敲代码时把Filter拼成了Fileter。这种非故意错误在老项目里特别常见。你要是直接拿Filter去搜资料什么都搜不到拿文件名FileterDlg去搜反而能找到同类问题。以后接手任何老代码遇到类名、文件名拼写可疑的先按“原样搜索”而不是“按正确单词搜索”能少走很多弯路。2.3 编译环境选型VC 6.0工程在VS2008与新版系统下的生存办法这个工程的.dsp/.dsw是VC 6.0的工程格式自带的老参数跟今天的开发环境差异很大。我实测过的路径有两条第一装Visual Studio 2008VC 9.0转换工程。VS2008可以直接打开VC6的.dsw转换向导会生成.sln和.vcproj代码一般不用大改。不过有两个麻烦一是MFC头文件的包含路径不同二是VC6里默认允许的某些隐式转换在VC9里会变成警告甚至错误比如把WORD直接塞进BYTE变量。所以转换完不能直接按F7先看输出窗里有几条错误基本集中在隐式缩窄上。第二用更新的Visual Studio 2022打开。转换向导也能走完但风险更高。这个年代久远的工程里对库目录的写法和现在差异很大过时API报错会一批批来。我一般把这个源码包当“读码、学习、提取思路”的对象在VS2022里打开真要“编译、改动、跑起来”放VS2008或者装个带VC6的虚拟机更稳。你如果现在用的是Win10/11 64位系统编译成功之后还会撞上驱动签名的问题——这个放到第4章细说。具体步骤参考这个顺序1. VS2008菜单“文件 → 打开 → 项目/解决方案”选中GetPacket.dsw 2. 转换向导出现后保持默认生成解决方案文件 3. 在解决方案资源管理器里右键Packet32工程选择“生成” 4. Packet32生成成功后再右键GetPacket工程选择“生成” 5. 把生成的Packet32.dll复制到GetPacket.exe输出目录这个顺序其实是所有“一个解决方案里有库工程和应用工程”的老项目共同的规矩先编依赖、后编入口动态库必须让应用能找到。很多人栽在第五步DLL编好了但没复制过去exe一启动就报缺库。还有一点容易被忽略Packet32工程里带着Packet32.mak和Packet32.plg前者是NMake格式的旧式工程描述后者是VC6编译日志。在VS2008里打开Packet32.dsw时向导会同时看到.dsp和.mak两套构建描述选“转换.dsp”即可两套都转的话生成配置会互相覆盖。3. 核心代码走读从打开适配器到IP头、协议头解析的完整链路3.1 Packet32.dll的调用链打开适配器、设置缓冲区与循环接收Packet32的用户态接口核心调用链可以压缩成四步打开适配器、设置缓冲区、设置过滤、进入接收循环。以Packet32公开接口的风格为例// 1. 打开网络适配器返回一个句柄 LPADAPTER lpAdapter PacketOpenAdapter(adapterName); if (!lpAdapter) { // 常见失败原因权限不足、驱动没装、适配器名写错 return -1; } // 2. 设置内核缓冲区大小单位字节 // 抓大流量必须开大抓小流量开太大反而浪费内存 PacketSetBuff(lpAdapter, 512 * 1024); // 3. 设置过滤掩码NULL/0 表示接收所有帧 PacketSetFilter(lpAdapter, NULL, 0); // 4. 进入抓包循环 while (1) { LPPACKET lpPacket PacketAllocatePacket(); if (PacketReceivePacket(lpAdapter, lpPacket) lpPacket-ulUserBytes 0) { // lpPacket-Buffer 里就是原始以太网帧 DispatchPacket(lpPacket-Buffer, lpPacket-ulUserBytes); } PacketFreePacket(lpPacket); }这里有几个参数值得说清楚。PacketOpenAdapter的第一个参数是适配器名不是你控制面板里看到的“以太网”这种中文昵称是Packet32在机器上生成的设备名。怎么拿到这个名字常见做法是在程序启动时调用PacketGetAdapterNames把返回的字符串列表解析进下拉框这个源码包的GetPacket.cpp里应该有类似逻辑那就是整个程序的入口。PacketSetBuff的第二个参数是内核缓冲区大小抓大流量时开太小会丢包开太大内存吃紧512KB是抓内网流量的起跳值。PacketReceivePacket返回假不一定代表出错超时也会返回假所以循环里不要一收到假就退出要看具体错误码。这段循环还有一个细节PacketAllocatePacket和PacketFreePacket在循环里反复调用是为了每次接收都拿到独立的内存块。如果图省事只分配一次、反复复用同一个LPPACKET下一帧数据会覆盖上一帧你解析到一半的内容就是脏数据。老代码里这个坑藏得很深因为界面看起来还在刷新但列表里可能一半是坏帧。3.2 protocol.h与ipaddr.h从原始帧里抠出MAC、IP和端口抓包程序里最难看的代码是字节序处理。protocol.h这个文件里一般会定义以太网头、IP头、TCP/UDP头的结构体。注意这些结构体里的字段默认是网络字节序解析时要做ntohs转换。以经典定义为例// 以太网帧头固定14字节 typedef struct _ETH_HEADER { BYTE DstMac[6]; // 目标MAC数组顺序就是字节顺序 BYTE SrcMac[6]; // 源MAC WORD Proto; // 上层协议类型0x0800表示IPv4 } ETH_HEADER; // IP头最短20字节长度看VerLen字段的低4位 typedef struct _IP_HEADER { BYTE VerLen; // 高4位版本低4位首部长度/4 BYTE TOS; // 服务类型一般不用管 WORD TotalLen; // 整个IP包总长度 WORD Ident; // 标识符 WORD FragOffset; // 分片偏移 BYTE TTL; // 生存时间 BYTE Protocol; // 上层协议6TCP17UDP WORD Checksum; // 头校验和 DWORD SrcIP; // 源IP4字节 DWORD DstIP; // 目标IP } IP_HEADER;拿到Buffer之后前14字节是ETH_HEADER紧接着才是IP_HEADER。这里有几个老手都容易忘的坑。第一以太网协议类型字段是网络字节序判断是不是0x0800之前先ntohs一把直接拿原始值比对会漏掉所有IPv4包。第二IP头的真实长度要看VerLen的低4位再乘420字节只是起步值遇到带选项的IP头你跳过头部的字节数就不同。第三TCP头长度同样是一个可变字段解析端口之前先算对偏移否则拿到的全是错位数据。ipaddr.h和ipaddr.cpp干的事一般是把DWORD类型的IP转成“1.2.3.4”字符串顺带判断掩码归属。抓包列表里每一帧都要显示源IP和目标IP这个转换函数会被高频调用实现质量直接影响界面刷新速度。有的工程用inet_ntoa一行解决但这个函数内部用静态缓冲区多线程下会互相覆盖。这个工程是MFC单文档结构主线程处理一般没事如果你以后扩展成“抓包线程界面线程”分离就别再调inet_ntoa改成自己用格式化逐字节拼接虽然多写几行但线程安全。3.3 过滤对话框与视图刷新抓包结果如何在MFC里显示FileterDlg.h和FileterDlg.cpp是过滤条件对话框。所谓过滤在Packet32这套体系里分两层第一层是PacketSetFilter传给驱动的内核过滤基于BPF指令第二层是应用层自己过滤只把符合条件的帧显示出来。这个工程的类名是FileterDlg重心一般在应用层过滤因为BPF指令在代码里肉眼不好调界面上勾选条件更直观。应用层过滤的典型写法伪代码如下// 过滤条件示例只看目标端口是80的TCP包 if (ntohs(pTcpHeader-DstPort) 80) { AddPacketToList(pEthHeader, pIpHeader, pTcpHeader); }说明一下这段的位置DispatchPacket解析完协议头之后先走过滤条件通过才进ListView不通过直接释放内存。过滤界面上如果提供协议类型下拉框选TCP/UDP/ICMP这些条件会拼成一个结构体主窗口在DispatchPacket里逐帧判断。比起BPF内核过滤应用层过滤调试容易、改条件不用重装驱动代价是CPU占用高——高流量下每帧都做字符串和端口比较压力不小。抓包结果往GetPacketListView里放这里有一个非常典型的性能陷阱。如果每一帧都调InsertItem界面消息处理会被刷爆一秒钟进来几千个包时窗口基本是白的你以为是程序卡死其实是UI线程被重绘占满了。常见做法是抓包进队列定时器每50毫秒集中刷新一次ListView。我自己的习惯是抓包线程只负责往队列里塞指针UI定时器负责弹队列、批量插入、最后统一Invalidate。这样抓包线程不会被界面拖慢界面也不会因为包太多而假死。要做到这一步GetPacketView.cpp里的刷新逻辑就得从“逐包InsertItem”改成“批量InsertItem”这是把抓包程序从玩具变成工具的分水岭。4. 抓包程序避坑实录驱动加载失败、丢包与过滤失灵的五个现场4.1 现象运行GetPacket.exe时提示找不到Packet32.dll原因Packet32.dll不在exe所在目录也不在系统的PATH里。你改了源码重新编了DLL但编译输出目录是Packet32工程的Debug目录GetPacket.exe去自己目录里找不到自然起不来。解决把Packet32工程和GetPacket工程放在同一个解决方案里把DLL的输入输出目录都设成GetPacket.exe所在目录。最土但最有效的排查办法是打开Dependency Walker把exe拖进去看缺哪个节点红色高亮的地方就是问题所在。还有一种隐蔽情况DLL文件存在但导出的函数丢了。检查Packet32.def文件它是模块定义文件决定哪些函数能导出。改工程配置时不小心把.def从链接参数里去掉链接出来的DLL就是个空壳exe运行起来照样报加载失败。4.2 现象抓包循环一直有包但界面列表不刷新或假死原因ListView每帧都执行InsertItem高流量下UI线程卡在重绘里窗口消息无法处理WM_PAINT表现出来就是界面白了、拖不动了。解决批量插入前调用SetRedraw(FALSE)插入完再SetRedraw(TRUE)和Invalidate。把UI刷新控制在每秒20次左右不要让每帧都直接触达控件。我一般会把到达的包先压进一个队列UI定时器每50毫秒把队列里累积的帧一次性刷上去大致逻辑如下// 定时器回调里做批量刷新避免逐包InsertItem卡死UI m_uiLock.Enter(); while (!m_pendingPackets.empty()) { AddPacketToList(m_pendingPackets.front()); m_pendingPackets.pop_front(); } m_uiLock.Leave(); // 关闭重绘批量更新后再统一打开 m_listView.SetRedraw(FALSE); m_listView.Invalidate(); m_listView.SetRedraw(TRUE);这段代码的意义是双重的锁保证抓包线程和UI线程的队列访问安全SetRedraw(FALSE)把界面刷新停住等所有包都插完再一起重绘防止插入过程中界面反复画半成品。其实很多“抓包卡死”并不是抓包逻辑挂了就是界面刷新被拖死的你把刷新频控住问题就消掉一大半。4.3 现象过滤规则一设置一个包都收不到原因BPF过滤掩码设错。PacketSetFilter的第二个参数是BPF程序第三个参数是长度。如果你传入的是普通字符串底层拿到的是非法指令驱动直接把所有包丢掉。还有一种情况是端口字节序没转过滤条件写的是80底层拿到的却是0x5000反转后的值永远匹配不上。解决先用NULL、0做一次收包验证确认链路通。再加过滤时从最简单的条件开始比如只过滤IP协议类型0x0800能收到IP包后再往端口条件上加。不要一次把MAC、IP、端口全写上因为查错的时候你完全不知道是哪一段坏。如果想做内核级BPF过滤去查BPF指令格式的文档自己拼字节流之前先拿现成工具生成过滤指令确认能用再固化到代码里。4.4 现象Debug编译能跑Release一启动就崩原因MFC工程里常见的未初始化变量Debug配置下自动清零Release配置下是栈里的随机值。这个时代的抓包代码喜欢在栈上定义大的字节数组Release优化时栈帧布局变化缓冲区越界问题一下就炸出来。解决逐帧检查Buffer的拷贝长度和ulUserBytes是否一致。解析IP头时如果TotalLen小于实际收到的数据按TotalLen解析别按收包长度解析否则越界读从偶发崩溃变成稳定崩溃。Release下排这种问题我习惯在DispatchPacket入口加一条OutputDebugString记录每一帧的地址、长度、协议类型再配合WinDbg的!analyze看崩溃栈指向哪个偏移。凡是抓包程序内存问题基本都是同一个病根过度信任网卡给的长度没验证就往下读。4.5 现象Win10/11 64位下VxD加载失败或Packet32.dll无法控制网卡原因zpacket.vxd是Windows 9x时代的虚拟设备驱动Windows XP开始就不再支持。Packet32旧版DLL在64位系统上没有签名内核驱动加载会被拒绝这是驱动签名策略限制不是代码逻辑的问题。解决现代系统上复现这套源码只有两条路。第一条是保留上层MFC应用代码把底层抓包驱动替换成WinPcap或Npcap的驱动调用接口尽量对齐Packet32的命名这样上层改动最小。第二条是纯学习在虚拟机里装Windows XP镜像用VC6编译之后直接实验绕开驱动签名问题。我更推荐前者驱动直接用成熟库解析和显示用这套源码的逻辑组合起来在Win11上也能跑。如果目标是学驱动本身把NTDDNDIS.H和DEVIOCTL.H这两个头文件留着配合WDK读比真去编译VxD更实际这两个文件里的NDIS设备控制定义今天看依然有参考价值。5. 进阶验证用抓到的包反推TCP握手并顺手扩展一列HTTP Host5.1 用抓包结果验证TCP三次握手代码跑通之后最直观的验证不是看“能收到包”而是看能不能基于原始帧反推出协议过程。拿两台机器或者一台机器配两个网卡做实验一端用netstat起监听另一端发起连接抓包程序同时开着。你会看到三个关键帧SYN包、SYNACK包、ACK包。判断依据是TCP头里六个标志位按位与就能区分#define TCP_FLAG_FIN 0x01 #define TCP_FLAG_SYN 0x02 #define TCP_FLAG_RST 0x04 #define TCP_FLAG_PSH 0x08 #define TCP_FLAG_ACK 0x10 #define TCP_FLAG_URG 0x20 BYTE flag pTcpHeader-Flags; if ((flag TCP_FLAG_SYN) (flag TCP_FLAG_ACK)) { // 第二次握手SYNACK } else if ((flag TCP_FLAG_SYN) !(flag TCP_FLAG_ACK)) { // 第一次握手纯SYN } else if ((flag TCP_FLAG_ACK) !(flag TCP_FLAG_SYN)) { // 可能是第三次握手也可能是普通数据包 }这里有个我踩过的坑验证流程别用127.0.0.1回环Windows的loopback流量不一定走网卡驱动你在抓包里永远等不到SYN会误以为程序坏了。用局域网IP或者虚拟机网卡抓包逻辑才真正被触发。5.2 扩展给列表加一列HTTP Host源码跑稳定之后进阶用法很自然就出来了在ListView里加一列HTTP Host把80端口TCP包的应用层文本解析出来。常见做法是拿到TCP载荷指针后做一次内存搜索定位到“Host: ”字段截到回车符为止。注意HTTP头是明文但Host字段可能被拆到两个TCP段里所以要先做TCP流重组再解析。完整实现需要维护一个按四元组索引的重组缓冲区工作量不小但这个功能做完你的工具就从“能看包”进步到“能看业务了”。写完这段想起我第一次拿这类源码排查生产问题时的样子开了半天抓包一个包都收不到后来发现是过滤条件里写死只放行UDPTCP流量全被丢了。从那以后我所有抓包工具的验证流程都固定成三步先不设过滤网卡全收再按协议收最后才上端口级过滤一步不跳。希望帮到你。本文还有配套的精品资源点击获取