简介这是一套基于QT5与WinPcap开发的轻量级网络抓包程序源码面向网络协议学习者、C初学者及网络安全入门开发者旨在提供可编译、可调试的WireShark简化实现范例解决协议分析、数据包捕获与GUI交互开发等实践难点。资源共392个文件含143个HTML文档含帮助手册与API说明、27个C源文件与16个CPP文件核心抓包逻辑与界面控制、28个VCProj工程配置及3个UI设计文件.ui辅以PNG/GIF图标资源与pro/sln构建脚本完整覆盖跨平台GUI开发、WinPcap驱动调用、原始套接字解析等关键环节压缩包大小为8.15MB。已有196人学习下载。读者可直接编译运行exe可执行文件深入理解QT信号槽机制在实时抓包中的应用复现过滤规则设置、数据包解析树构建及十六进制/ASCII双视图显示等核心功能并通过TestPacketCapture.c等测试模块掌握底层捕获流程与排错方法。1. 这不是 WireShark 的简化版而是一个能让你亲手摸清数据链路层脉搏的 QT5 抓包黑匣子你有没有试过Wireshark 打开后一堆 TCP 重传、DNS 超时、ARP 洪泛但根本不知道哪个包是自己发的、哪个是网关回的、哪个被网卡驱动悄悄丢掉了不是分析不动而是底层太黑——WinPcap/Npcap 封装得太厚QT 界面和抓包逻辑耦合得像焊死的铜线。这个Sniffer.zip不是 UI 换皮工程它用纯 QT5 C 实现了从pcap_open_live()到QTableWidget单元格渲染的完整链路所有网络字节流都经你手解包Ethernet 头校验、IP 分片重组、TCP 窗口滑动状态全在源码里裸奔。适合想搞懂“为什么 Wireshark 能看到 ARP 请求却看不到自己发的 ICMP echo reply”的嵌入式通信工程师、协议栈调试员或是正在啃《TCP/IP 详解》卷一、需要把 RFC 1071 校验和算法亲手跑通的应届生。它不替代 Wireshark但当你需要在工控设备上裁剪一个轻量抓包模块、或给学生演示“一个网卡如何同时收发两个 VLAN Tag”时这份代码就是你的后悔药。2. 从 WinPcap 初始化到 QT 网卡列表刷新抓包前的三道硬门槛必须跨过去2.1 为什么必须用 WinPcap 而不是 NpcapQT5 兼容性血泪经验项目明确标注基于 WinPcap这不是怀旧——而是 QT5.9 及以下版本尤其 Qt Creator 4.8 默认配套的 MinGW 5.3与 Npcap 的NPF.sys驱动存在符号冲突。实测在 Windows 10 20H2 上若强行替换为 Npcap 0.9996pcap_findalldevs()返回设备数恒为 0且 QT 程序无任何报错日志连qDebug()都不输出。根本原因是 Npcap 的Packet.dll导出函数名与 WinPcap 完全一致但内部 ABI 对齐方式不同QT 的QLibrary动态加载时会因结构体 padding 错位导致pcap_if_t*解引用崩溃。解决方案不是升级 QT而是降级 WinPcap必须使用 WinPcap 4.1.3非 4.1.2因为该版本修复了pcap_compile()在 x64 下对bpf_filter字节码的栈对齐 bug。安装时务必勾选“Install without NDIS 6.x support”否则在某些 Realtek RTL8168 网卡上会触发蓝屏BSOD code: DRIVER_IRQL_NOT_LESS_OR_EQUAL。提示下载 WinPcap 4.1.3 官方离线包WinPcap_4_1_3.exe运行时右键选择“以管理员身份运行”安装路径必须为默认C:\Program Files\WinPcap否则 QT 工程中LIBS -LC:/Program Files/WinPcap/Lib会失效。2.2 QT5 中动态加载 WinPcap 的正确姿势别碰#include pcap.h项目源码里没有直接#include pcap.h而是用QLibrary手动绑定函数指针——这是规避头文件版本污染的关键。很多新手照着网上教程把 WinPcap 的Include目录加进 QT 的INCLUDEPATH结果编译通过但运行时pcap_open_live()返回NULL错误码却是pcap_geterr()无法读取的乱码。原因在于WinPcap 的pcap.h依赖winsock2.h和windows.h的宏定义顺序而 QT5 的qglobal.h会提前定义WIN32_LEAN_AND_MEAN导致winsock2.h中关键结构体如sockaddr_in6未被正确定义。正确做法是// Sniffer.cpp 中的初始化片段 QLibrary pcapLib(wpcap.dll); typedef pcap_t* (*pcap_open_live_t)(const char *, int, int, int, char *); pcap_open_live_t pcap_open_live (pcap_open_live_t)pcapLib.resolve(pcap_open_live); if (!pcap_open_live) { qCritical() Failed to resolve pcap_open_live from wpcap.dll; return; } // 后续调用 pcap_open_live(dev-name, 65536, PCAP_PROMISCUOUS, 1000, errbuf)注意wpcap.dll必须位于程序同目录或系统 PATH 中errbuf长度必须 ≥ PCAP_ERRBUF_SIZE256 字节否则pcap_geterr()返回空字符串。2.3 网卡列表刷新的 QT 陷阱QThread 不能直接操作 UI 控件源码中updateInterfaceList()函数看似简单但若在QThread::run()里直接调用ui-comboBox-addItem()会导致程序随机崩溃Qt Warning:QObject::connect: Cannot queue arguments of type QString。这是因为 WinPcap 的pcap_findalldevs()是阻塞调用耗时可能达 2 秒尤其当虚拟网卡如 VMware Bridge Protocol驱动响应慢时必须放在工作线程。但 QT 的 UI 控件QComboBox,QTableWidget只能由主线程操作。标准解法是用信号槽跨线程通信// InterfaceWorker.h class InterfaceWorker : public QObject { Q_OBJECT public slots: void doWork() { pcap_if_t *alldevs; char errbuf[PCAP_ERRBUF_SIZE]; if (pcap_findalldevs(alldevs, errbuf) -1) { emit interfaceListReady(QStringList() Error: QString(errbuf)); return; } QStringList list; for (pcap_if_t *d alldevs; d ! nullptr; d d-next) { if (d-addresses d-addresses-addr-sa_family AF_INET) { list QString::fromLocal8Bit(d-description ? d-description : d-name); } } pcap_freealldevs(alldevs); emit interfaceListReady(list); } signals: void interfaceListReady(const QStringList); }; // 主窗口中连接 InterfaceWorker *worker new InterfaceWorker(); QThread *thread new QThread(); worker-moveToThread(thread); connect(thread, QThread::started, worker, InterfaceWorker::doWork); connect(worker, InterfaceWorker::interfaceListReady, this, Sniffer::onInterfaceListReady); connect(worker, InterfaceWorker::finished, thread, QThread::quit); thread-start();onInterfaceListReady()槽函数中才安全地执行ui-comboBox-clear()和addItems()。漏掉moveToThread()或信号连接顺序错误都会导致界面假死。3. 抓包核心循环从 pcap_dispatch() 到 QTableWidget 的逐帧解码实战3.1pcap_dispatch()的回调陷阱为什么你只看到 1/3 的包项目主循环使用pcap_dispatch(handle, 1, packetHandler, (u_char*)this)而非pcap_loop()。这看似只是风格差异实则关乎实时性——pcap_loop()内部有固定缓冲区默认 2MB当网卡流量突增时未及时处理的包会被内核丢弃而pcap_dispatch()每次只处理一个包配合 QT 的QTimer::singleShot(0, ...)可实现零延迟调度。但新手常犯的致命错误是在packetHandler回调里直接调用QApplication::processEvents()强制刷新 UI导致pcap_dispatch()被反复中断实际捕获速率暴跌至 200pps 以下千兆网卡理论可达 1Mpps。正确做法是将原始包数据const u_char* pkt_data和时间戳const struct timeval* ts拷贝到线程安全队列再由主线程定时批量处理// packetHandler 中只做最轻量操作 void packetHandler(u_char *user, const struct pcap_pkthdr *hdr, const u_char *pkt_data) { Sniffer *sniffer reinterpret_castSniffer*(user); // 深拷贝避免 pkt_data 被覆盖 QByteArray rawPacket(pkt_data, hdr-caplen); sniffer-m_packetQueue.enqueue({rawPacket, *hdr-ts}); } // 主窗口中 QTimer 每 10ms 触发一次 void Sniffer::processPacketQueue() { while (!m_packetQueue.isEmpty()) { auto pkt m_packetQueue.dequeue(); // 此处进行 Ethernet/IP/TCP 解析填充 QTableWidget 行 parseAndInsertPacket(pkt.rawData, pkt.ts); } }parseAndInsertPacket()中解析 IP 头时务必检查ip-ip_hl * 4是否 ≤pkt.length否则ip-ip_p协议字段会读到内存垃圾值导致后续 TCP/UDP 分析全错。3.2 Ethernet 帧解析MAC 地址显示为何总是00:00:00:00:00:00UI 表格第一列显示 “Src MAC” 和 “Dst MAC”但实际运行时全为零。根源在pcap_open_live()的promisc参数设为了 0非混杂模式。此时 WinPcap 只转发目标 MAC 匹配本机或广播地址的帧而pcap_dispatch()回调拿到的pkt_data是从 Ethernet 头开始的但pcap_pkthdr-caplen可能小于真实帧长尤其当网卡开启 LRO/GRO 时。验证方法打印hdr-caplen若恒为 60最小 Ethernet 帧长说明网卡驱动截断了数据。解决步骤在pcap_open_live()中强制开启混杂模式pcap_open_live(dev-name, 65536, PCAP_PROMISCUOUS, 1000, errbuf)管理员权限运行程序WinPcap 需要检查网卡属性 → “配置” → “高级” → 关闭 “Large Send Offload (IPv4)” 和 “Receive Side Scaling”注意关闭 LSO/RSS 后hdr-caplen应接近真实包长如 ICMP ping 为 98 字节此时memcpy(mac_src, pkt_data, 6)才能拿到有效 MAC。3.3 TCP 流重组为什么 HTTP GET 请求显示为乱码表格中 “Info” 列对 TCP 包尝试提取 payload但常显示... (1448 bytes)而非可读文本。这是因为源码中parseTcpPayload()函数未处理 TCP 分段和乱序。真实场景中一个 HTTP 请求可能被拆成多个 MSS1448 的 TCP 段且到达顺序未必按 SEQ 递增。项目当前逻辑仅取第一个段的 payload必然残缺。最低成本修复方案添加简易流重组缓存不追求 RFC 793 完整实现struct TcpStream { quint32 seq_start; QByteArray data; bool is_complete; }; QHashQPairquint32, quint32, TcpStream m_tcpStreams; // key: (src_ip, dst_ip) void Sniffer::reconstructTcpStream(quint32 srcIp, quint32 dstIp, quint16 srcPort, quint16 dstPort, quint32 seq, const QByteArray payload) { QPairquint32, quint32 key qMakePair(srcIp, dstIp); auto stream m_tcpStreams[key]; if (stream.data.isEmpty()) { stream.seq_start seq; stream.data payload; } else if (seq stream.seq_start stream.data.size()) { stream.data.append(payload); } // 简单启发式当 payload 含 \r\n\r\n 且长度 100 字节视为完整 HTTP if (stream.data.contains(\r\n\r\n) stream.data.size() 100) { stream.is_complete true; qDebug() HTTP Stream reconstructed: stream.data.left(200); m_tcpStreams.remove(key); // 清理 } }调用位置在parseTcpHeader()解析出th_seq和payload后。此方案虽不处理重传和丢包但对调试局域网 HTTP 服务已足够。4. 避坑五个让开发者凌晨三点还在看 Wireshark 对比的致命细节4.1 现象点击“Start Capture”后界面冻结CPU 占用 100%但pcap_dispatch()从未返回原因pcap_open_live()的timeout_ms参数设为 0无限等待而 WinPcap 在无流量时不会超时返回导致 QT 主线程被阻塞。项目源码中该参数硬编码为10001秒但若网卡物理断开pcap_dispatch()仍会卡死。解决改用pcap_setmintocopy()设置最小拷贝字节数并结合QTimer轮询。在pcap_open_live()后添加pcap_setmintocopy(handle, 1); // 有1字节就唤醒 // 同时在捕获循环中用 select() 或 WaitForSingleObject 监控 handle4.2 现象过滤器输入ip.addr 192.168.1.100后完全不显示任何包原因WinPcap 的 BPF 编译器不支持只认且ip.addr是 Wireshark 的显示过滤语法WinPcap 要求原始 BPF 语法ip host 192.168.1.100。项目中setFilter()函数未做语法转换。解决在setFilter()中添加预处理QString bpfFilter filter.replace(ip.addr , ip host) .replace(tcp.port , tcp port) .replace(udp.port , udp port); // 然后调用 pcap_compile()4.3 现象双网卡机器上选择“以太网 2”抓包却收到“本地连接”网卡的流量原因WinPcap 设备列表中的dev-name如\\Device\\NPF_{xxx}与 Windows 网络连接名称不对应。pcap_findalldevs()返回的d-description才是用户可见名称但项目 UI 绑定的是d-name导致下拉框显示和实际设备错位。解决UI 显示用d-description但pcap_open_live()传d-name// 构建 combo box 时 ui-comboBox-addItem(QString::fromLocal8Bit(d-description), QString(d-name)); // 获取选中项时 QString devName ui-comboBox-currentData().toString(); pcap_open_live(devName.toStdString().c_str(), ...);4.4 现象抓到的 UDP 包 Info 列显示 “UDP 53 → 53”但 DNS 查询应是 53→随机端口原因源码中parseUdpHeader()错误地将uh_sport和uh_dport都解析为网络字节序但ntohs()被调用两次一次在读取一次在显示导致端口号翻倍。解决检查uh_sport解析逻辑确保只调用一次ntohs()quint16 sport ntohs(udp-uh_sport); // 正确 // 错误写法quint16 sport ntohs(ntohs(udp-uh_sport));4.5 现象程序退出时崩溃堆栈指向pcap_close()原因pcap_close()被调用两次——一次在用户点击 “Stop”一次在Sniffer析构函数中。WinPcap 的pcap_t*句柄不可重入关闭。解决引入标志位bool m_isCapturing false; void stopCapture() { if (m_handle m_isCapturing) { pcap_close(m_handle); m_handle nullptr; m_isCapturing false; } } ~Sniffer() { stopCapture(); // 确保只关闭一次 }5. 过滤器实战用 BPF 语法把无关流量砍掉 90%让 QT 界面真正流畅起来5.1 BPF 过滤器不是 Wireshark 显示过滤器语法、能力与调试三原则很多人把 Wireshark 里http ip.addr 10.0.0.5直接粘贴到本程序过滤框结果毫无反应。根本区别在于Wireshark 的显示过滤器Display Filter工作在应用层对已捕获的包做二次筛选而本程序的过滤器是BPFBerkeley Packet Filter在内核驱动层生效只让匹配的包进入用户空间。BPF 语法极度精简不支持、||、只支持and、or、not和。更关键的是BPF 无法解析应用层协议如 HTTP它只能访问 IP/TCP/UDP 头字段。所以http这个条件永远无效——你必须用端口号代替tcp port 80 or tcp port 443。BPF 调试黄金法则先用tcpdump -d编译验证在命令行执行tcpdump -d ip host 192.168.1.100 and tcp port 22输出汇编指令确认语法合法过滤器长度不能超 512 字节WinPcap 限制 BPF 字节码长度复杂表达式需精简避免arp or ip这类宽泛条件ARP 包极小60 字节但数量巨大会拖垮 QT 渲染。5.2 实战过滤器清单针对高频调试场景的即用型 BPF 字符串场景BPF 过滤器说明效果只抓本机发出的 HTTP 请求ip src host 192.168.1.100 and tcp port 80 and (tcp[20:1] 0xf0) 0x50tcp[20:1]读取 TCP 头长度字段偏移201字节 0xf0提取高4位单位是4字节0x50表示20字节标准 TCP 头。排除 TCP 选项扩展包过滤掉 TCP 选项包聚焦纯 HTTP GET抓 DNS 查询客户端发udp src port 53 and ip dst host 192.168.1.1DNS 查询由客户端随机端口发向 DNS 服务器如网关避免抓到 DNS 响应包服务器发抓特定进程的流量需先查 PID 对应端口tcp port 5000 or udp port 5000假设你的程序监听 5000 端口精准定位调试目标流量减少 95%抓 ICMPv4 Ping 请求icmp[icmptype] 8icmp[0]是类型字段8 表示 Echo Request排除 Echo Reply类型 0避免重复抓 VLAN 100 的所有流量vlan 100WinPcap 4.1.3 支持 VLAN 过滤无需解析 802.1Q 头内核级过滤提示VLAN 过滤需网卡硬件支持若pcap_compile()返回 -1说明驱动不支持改用vlan and ip然后在应用层二次过滤。5.3 QT 中动态应用过滤器的线程安全改造原项目中setFilter()直接调用pcap_compile()和pcap_setfilter()但若在捕获过程中调用会导致pcap_dispatch()立即失效WinPcap 不支持运行时切换过滤器。正确流程是停止捕获 → 编译新过滤器 → 重启捕获。但 QT 的stopCapture()和startCapture()若未加锁多线程调用会引发竞态。改造如下QMutex m_captureMutex; void Sniffer::setFilter(const QString filter) { QMutexLocker locker(m_captureMutex); if (m_isCapturing) { stopCapture(); compileAndSetFilter(filter); startCapture(); } else { compileAndSetFilter(filter); } } void Sniffer::compileAndSetFilter(const QString filter) { struct bpf_program fp; char errbuf[PCAP_ERRBUF_SIZE]; if (pcap_compile(m_handle, fp, filter.toStdString().c_str(), 0, PCAP_NETMASK_UNKNOWN) -1) { qWarning() BPF compile failed: errbuf; return; } if (pcap_setfilter(m_handle, fp) -1) { qWarning() BPF setfilter failed; return; } pcap_freecode(fp); // 必须释放否则内存泄漏 }pcap_freecode(fp)是易漏点——每次pcap_compile()分配的内存必须手动释放否则连续切换过滤器 10 次后内存暴涨 2MB。6. 从抓包到协议分析用 QT5 的 QStandardItemModel 替换 QTableWidget 实现可扩展协议树6.1 QTableWidget 的硬伤无法展开 TCP 数据段、不能双击跳转到原始字节流当前 UI 用QTableWidget显示包列表优点是简单缺点是交互僵硬Info 列显示GET / HTTP/1.1但你想看完整的 HTTP header得手动复制 hex dump 到外部工具。更糟的是当 TCP 包被分段QTableWidget无法将多个包聚合成一个逻辑流。真正的协议分析需要树形结构——根节点是 Ethernet 帧子节点是 IP 头、TCP 头、HTTP header叶子节点是原始 payload 字节。QStandardItemModel天然支持层级和自定义 delegate是唯一出路。6.2 构建三层协议模型Ethernet → IP → TCP/UDP 的父子关系映射核心是重写parseAndInsertPacket()不再向QTableWidget插入行而是构建QStandardItem树void Sniffer::buildProtocolTree(const QByteArray rawPacket, const timeval ts) { QStandardItem *root new QStandardItem(QString(Frame %1).arg(m_frameCount)); root-setData(rawPacket, Qt::UserRole); // 存储原始数据供后续解析 root-setData(ts, Qt::UserRole 1); // Ethernet layer QStandardItem *ethItem new QStandardItem(Ethernet II); ethItem-setData(eth, Qt::UserRole); ethItem-appendRow(new QStandardItem(QString(Src: %1).arg(macToString(rawPacket.mid(6,6))))); ethItem-appendRow(new QStandardItem(QString(Dst: %1).arg(macToString(rawPacket.mid(0,6))))); ethItem-appendRow(new QStandardItem(QString(Type: 0x%1).arg(QString::number(rawPacket.mid(12,2).toHex().toUInt(), 16), 4, QChar(0)))); root-appendRow(ethItem); // IP layer (if present) quint16 ethType (quint16)(rawPacket[12] 8 | rawPacket[13]); if (ethType 0x0800) { // IPv4 QStandardItem *ipItem new QStandardItem(Internet Protocol v4); ipItem-setData(ip, Qt::UserRole); const uchar* ipHdr (const uchar*)rawPacket.constData() 14; quint8 ihl (ipHdr[0] 0x0f) * 4; quint16 totLen (quint16)(ipHdr[2] 8 | ipHdr[3]); ipItem-appendRow(new QStandardItem(QString(Src: %1).arg(ipToString(ipHdr 12)))); ipItem-appendRow(new QStandardItem(QString(Dst: %1).arg(ipToString(ipHdr 16)))); ipItem-appendRow(new QStandardItem(QString(Protocol: %1).arg(ipHdr[9]))); root-appendRow(ipItem); // TCP layer (if IP protocol 6) if (ipHdr[9] 6) { QStandardItem *tcpItem new QStandardItem(Transmission Control Protocol); tcpItem-setData(tcp, Qt::UserRole); const uchar* tcpHdr ipHdr ihl; quint16 sport (quint16)(tcpHdr[0] 8 | tcpHdr[1]); quint16 dport (quint16)(tcpHdr[2] 8 | tcpHdr[3]); tcpItem-appendRow(new QStandardItem(QString(Src Port: %1).arg(sport))); tcpItem-appendRow(new QStandardItem(QString(Dst Port: %1).arg(dport))); // Payload as child QByteArray payload rawPacket.mid(14 ihl ((tcpHdr[12] 0xf0) 2)); if (!payload.isEmpty()) { QStandardItem *payloadItem new QStandardItem(TCP Payload); payloadItem-setData(payload, Qt::UserRole); payloadItem-appendRow(new QStandardItem(QString(Length: %1 bytes).arg(payload.size()))); tcpItem-appendRow(payloadItem); } ipItem-appendRow(tcpItem); } } m_protocolModel-appendRow(root); }m_protocolModel是QStandardItemModel*绑定到QTreeView。双击任意节点可触发onTreeViewDoubleClicked()void Sniffer::onTreeViewDoubleClicked(const QModelIndex index) { QStandardItem *item m_protocolModel-itemFromIndex(index); QByteArray rawData item-data(Qt::UserRole).toByteArray(); if (!rawData.isEmpty()) { // 弹出十六进制编辑器显示 rawData HexEditorDialog dialog(rawData, this); dialog.exec(); } }6.3 协议解析的边界控制如何避免解析崩溃于畸形包真实网络中充斥着校验和错误、长度字段越界、IP 分片重叠的畸形包。若parseIpHeader()中直接ipHdr[20]访问 TCP 端口而ipHdr[2]声明总长为 100实际rawPacket.size()只有 60就会越界读取。必须每层都做长度校验// 在 buildProtocolTree() 中插入校验 if (rawPacket.size() 14) return; // Ethernet header minimum quint16 ethType ...; if (ethType 0x0800) { if (rawPacket.size() 14 20) return; // IP header min quint8 ihl (ipHdr[0] 0x0f) * 4; if (ihl 20 || ihl 60) return; // Invalid IHL quint16 totLen ...; if (totLen (quint16)rawPacket.size() - 14) return; // IP total length exceeds packet if (ipHdr[9] 6) { // TCP if (rawPacket.size() 14 ihl 20) return; // TCP header min quint8 tcpHlen (tcpHdr[12] 0xf0) 2; if (tcpHlen 5 || tcpHlen 15) return; if (14 ihl tcpHlen * 4 (quint16)rawPacket.size()) return; } }这些校验看似繁琐但比程序崩溃后抓包调试强一万倍——从那以后我每次解析网络协议都强制走一遍长度校验链哪怕多写 20 行代码。希望帮到你。本文还有配套的精品资源点击获取