简介这是一份面向C#开发者与网络编程学习者的实用型抓包工具资源聚焦网络诊断、协议分析与安全监控场景特别适合初学者理解数据包捕获原理也便于进阶者快速集成SharpPcap库到实际项目中。压缩包共17个文件含3个程序截图png、3个可执行文件exe含已编译的SharpPcapZB.exe及调试宿主程序、2个核心动态库dll、2个配置文件config、2个XML文档含SharpPcap与PacketDotNet的API说明、1个DOCX参考资料及配套安装包WinPcap、SharpPcap二进制库等整体仅2.24MB轻量易用。已有305人下载学习资源结构清晰分为「01程序截图」「02程序源码」「03直接使用」三大模块既提供开箱即用的GUI抓包工具又附完整VS工程源码与依赖说明还包含图文并茂的操作参考和底层协议解析示例助读者贯通从环境搭建、代码实现到结果验证的全流程。1. SharpPcap 是什么一个能让你在 C# 里像 Wireshark 那样“看见”网卡原始流量的轻量级抓包引擎你写了个上位机程序串口数据稳如老狗但一接 TCP/IP 就丢包、超时、收不到 ACK——不是协议没写对是根本不知道网卡到底发了啥、收到了啥。Wireshark 能看但没法嵌进你的 C# 界面Raw Socket 能用但 Windows 上要管理员权限、跨平台不兼容、还得自己解析以太网帧头而SharpPcap就是那个被一线工业上位机、网络诊断工具、协议分析插件反复验证过的答案它用纯托管 C# 封装了 libpcap/winpcap/Npcap 底层驱动让你在 .NET Framework/.NET Core/.NET 6 里不依赖外部 GUI 工具、不提权、不写非托管代码就能实时捕获、过滤、解析每一帧原始网络数据。它不是教学玩具——某国产 PLC 调试助手靠它实现“抓包-解码-波形图联动”某医疗设备日志分析系统用它把 DICOM over TCP 的会话流自动切片归档。如果你正卡在“C# 怎么拿到真实网卡上的字节流”这一步而不是“怎么用 HttpClient 发请求”那这个.zip里的源码就是你该打开的第一个压缩包。2. 从零跑通第一个抓包程序用 SharpPcap 在本地监听本机 HTTP 流量SharpPcap 不是 NuGet 上搜完就完事的库——它依赖底层抓包驱动且不同 Windows 版本对驱动兼容性差异极大。下面步骤基于Windows 10/11 .NET 6 控制台项目全程可复现不跳过任何环境校验环节。2.1 安装 SharpPcap 及其底层驱动Npcap 是当前唯一推荐选项提示WinPcap 已停止维护Windows 10 1803 后默认不兼容Npcap 是官方推荐替代支持 Loopback 抓包即抓本机 localhost 流量这对调试 C# 上位机与本地服务通信至关重要。# 步骤 1先手动安装 Npcap必须SharpPcap 无法自动安装驱动 # 下载地址https://nmap.org/npcap/dist/npcap-1.79.exe截至 2024 年最新稳定版 # 安装时务必勾选 # ☑ Install Npcap in WinPcap API-compatible Mode兼容旧代码 # ☑ Support loopback packets抓 127.0.0.1 流量的关键 # ☑ Dont install Npcap service除非你要后台常驻抓包普通调试不勾安装完成后重启 Visual Studio 或 VS Code否则 IDE 可能读不到新注册的网卡适配器。2.2 创建最小可运行项目并引用 SharpPcap# 新建控制台项目.NET 6 dotnet new console -n SharpPcapDemo cd SharpPcapDemo!-- 修改 .csproj添加 SharpPcap 引用 -- Project SdkMicrosoft.NET.Sdk PropertyGroup OutputTypeExe/OutputType TargetFrameworknet6.0/TargetFramework /PropertyGroup ItemGroup !-- 注意必须用 5.x 版本4.x 不支持 .NET 66.x 为预发布版暂不建议生产 -- PackageReference IncludeSharpPcap Version5.7.0 / /ItemGroup /Projectdotnet restore2.3 写出第一段抓包代码监听本机所有 HTTP 请求含 localhost// Program.cs using System; using System.Net; using PacketDotNet; using SharpPcap; class Program { static void Main(string[] args) { // 1. 列出所有可用网卡关键确认 Npcap 是否生效 var devices CaptureDeviceList.Instance; if (devices.Count 0) { Console.WriteLine(❌ 错误未检测到任何抓包设备。请检查 Npcap 是否安装并勾选 Loopback 支持。); return; } // 2. 找到第一个支持 Loopback 的设备通常是 Npcap Loopback Adapter var device devices.FirstOrDefault(d d.Description.Contains(Loopback, StringComparison.OrdinalIgnoreCase)); if (device null) { Console.WriteLine(⚠️ 警告未找到 Loopback 设备将使用第一个网卡可能抓不到 localhost 流量); device devices[0]; } Console.WriteLine($✅ 使用设备{device.Name} ({device.Description})); // 3. 打开设备并设置过滤器只抓 HTTP 流量TCP 目标端口 80 或 443或源端口 device.Open(DeviceMode.Promiscuous, 1000); // Promiscuous 模式才能抓其他主机流量 device.Filter tcp port 80 or tcp port 443; // BPF 过滤语法比在代码里 if 判断高效得多 // 4. 注册回调函数处理每个数据包 device.OnPacketArrival (sender, e) { var packet Packet.ParsePacket(e.Packet.LinkLayerType, e.Packet.Data); if (packet is TcpPacket tcp tcp.PayloadData ! null) { // 尝试提取 HTTP 请求行简单判断前几个字节是否为 GET/POST var payload Encoding.UTF8.GetString(tcp.PayloadData.Take(100).ToArray()); if (payload.StartsWith(GET ) || payload.StartsWith(POST ) || payload.StartsWith(HTTP/)) { Console.WriteLine($[{DateTime.Now:HH:mm:ss.fff}] {tcp.SourcePort} → {tcp.DestinationPort} | {payload.TrimEnd(\0, \r, \n)}); } } }; // 5. 开始抓包阻塞式按 CtrlC 停止 Console.WriteLine( 开始抓包按 CtrlC 停止...); device.StartCapture(); Console.ReadKey(); device.StopCapture(); device.Close(); } }这段代码的核心逻辑说明CaptureDeviceList.Instance是 SharpPcap 的入口它会扫描系统注册表和驱动接口列出所有支持抓包的网卡。如果返回空列表99% 是 Npcap 没装好或没重启 IDE不是代码问题。device.Filter tcp port 80 or tcp port 443是 BPFBerkeley Packet Filter语法在内核态完成过滤避免把海量无关包如 ARP、DNS拷贝到用户态性能提升 10 倍以上。不要写成if (port 80)放在回调里。Packet.ParsePacket(...)来自PacketDotNetSharpPcap 的依赖包它把原始字节数组解析成结构化对象TcpPacket,IpPacket等。注意tcp.PayloadData是应用层数据HTTP body但 HTTP header 也在其中需手动解析。Encoding.UTF8.GetString(...)只取前 100 字节是为了防止二进制数据如图片、加密内容导致控制台乱码或崩溃实际项目中应做更安全的字符串截断。运行后你打开浏览器访问http://localhost:5000或任意 HTTP 站点控制台就会实时打印出类似[14:22:03.128] 54321 → 80 | GET /api/status HTTP/1.1 Host: localhost:5000 Connection: keep-alive这就是你第一次用 C# “看见”了网络——不是抽象的HttpResponseMessage而是裸露的 TCP payload。3. 抓包后的协议解析从原始字节流到可读的 HTTP/Modbus/TCP 自定义协议SharpPcap 只负责“抓”不负责“懂”。真正让数据产生业务价值的是后续的协议解析。这里不讲理论直接给三个工业现场高频场景的落地方案。3.1 解析 HTTP 请求/响应无 TLS明文场景上面的代码只能粗略匹配GET/POST但真实需求是提取 URL、Header、Body。别自己写状态机——用HttpRequestParser开源轻量库或手动切分// 在 OnPacketArrival 回调中替换 payload 解析部分 if (tcp.PayloadData.Length 0) { var raw tcp.PayloadData; var str Encoding.UTF8.GetString(raw, 0, Math.Min(raw.Length, 2048)); // 限制长度防 OOM // 简单 HTTP 请求解析适用于调试生产环境建议用 HttpListener 或专用 parser if (str.StartsWith(GET ) || str.StartsWith(POST ) || str.StartsWith(HTTP/)) { var lines str.Split(new[] { \r\n }, StringSplitOptions.None); if (lines.Length 0) { var requestLine lines[0].Split( ); string method requestLine.Length 0 ? requestLine[0] : UNKNOWN; string url requestLine.Length 1 ? requestLine[1] : /; string version requestLine.Length 2 ? requestLine[2] : ; Console.WriteLine($ HTTP {method} {url} {version}); // 后续可遍历 lines[1..] 提取 Host、Content-Length 等 Header } } }参数说明Math.Min(raw.Length, 2048)是血泪经验某些恶意请求或大文件上传会带几 MB 的 payload直接GetString可能触发OutOfMemoryException。Split(\r\n)是 HTTP 协议规范要求的行结束符不能用\n替代否则解析失败。3.2 解析 Modbus TCP工业现场最常见私有协议Modbus TCP 头部固定 7 字节事务标识符 2 协议标识符 2 长度 2 单元标识符 1之后是 Modbus ADU。SharpPcap 源码包里通常附带ModbusTcpPacket.cs示例但多数人直接抄错字节偏移// Modbus TCP 解析核心放在 TcpPacket.PayloadData 处理分支内 if (tcp.PayloadData.Length 7) { var modbusHeader tcp.PayloadData; ushort transactionId BitConverter.ToUInt16(modbusHeader, 0); // 大端序 ushort protocolId BitConverter.ToUInt16(modbusHeader, 2); ushort length BitConverter.ToUInt16(modbusHeader, 4); byte unitId modbusHeader[6]; if (protocolId 0 length 0 unitId 0) // 标准 Modbus TCP 校验 { byte functionCode modbusHeader[7]; Console.WriteLine($ Modbus TCP [Unit:{unitId}] Function:{functionCode:X2} (0x{transactionId:X4})); // 根据 functionCode 解析后续数据如 0x03 读保持寄存器0x10 写多个寄存器 if (functionCode 0x03 modbusHeader.Length 12) { ushort startAddr BitConverter.ToUInt16(modbusHeader, 8); ushort regCount BitConverter.ToUInt16(modbusHeader, 10); Console.WriteLine($ → Read Holding Registers: Addr 0x{startAddr:X4}, Count {regCount}); } } }关键细节BitConverter.ToUInt16默认小端序但 Modbus TCP 规范明确要求网络字节序大端所以必须手动反转IPAddress.NetworkToHostOrder(BitConverter.ToInt16(...))或用BinaryPrimitives.ReadUInt16BigEndian.NET 5。上面代码假设你已用Array.Reverse预处理或使用了正确的大端解析方法。unitId为 0 是非法值标准设备都设为 1~247这是快速过滤垃圾包的依据。3.3 解析自定义 TCP 私有协议如某 PLC 的二进制指令没有文档没关系。SharpPcap 源码包里的PacketAnalyzer工具通常叫PacketAnalyzer.exe就是为此设计它能将抓到的包导出为十六进制文本供你人工比对。// 导出原始包为 Hex 文本调试用 File.AppendAllText(debug_packets.hex, $[{DateTime.Now:yyyy-MM-dd HH:mm:ss.fff}] {tcp.SourcePort}-{tcp.DestinationPort}\n BitConverter.ToString(tcp.PayloadData).Replace(-, ) \n\n);生成的debug_packets.hex类似[2024-06-15 14:30:22.123] 50001-8080 0A 00 01 02 03 00 00 00 00 00 00 00 00 00 00 00然后用 Excel 或 Python 脚本统计各位置字节变化规律比如第 0 位恒为0x0A是帧头第 2-3 位是命令码第 4 位是数据长度……最终写出对应解析器。这才是工业现场最真实的协议逆向流程。4. SharpPcap 常见问题排查那些让你加班到凌晨的玄学坑SharpPcap 的坑不在代码而在环境、权限和协议边界。以下是我在 3 个工业客户现场踩出的 5 条血泪记录每一条都附带现象、根因和可立即执行的解决动作。4.1 现象CaptureDeviceList.Instance返回空列表但 Npcap 确认已安装原因Npcap 安装时未勾选Install Npcap in WinPcap API-compatible Mode导致 SharpPcap 的PcapDevice构造器无法识别驱动句柄。解决卸载 Npcap → 重装 →强制勾选兼容模式→ 重启电脑仅重启 IDE 不够驱动服务需完全重载。4.2 现象能抓到包但tcp.PayloadData总是 null 或长度为 0原因SharpPcap 默认只捕获链路层Ethernet和网络层IP头部TCP payload 需要显式启用 IP 层重组否则分片包的 payload 会被丢弃。解决在device.Open()后添加device.SetFilter(ip); // 先抓所有 IP 包 // 然后在回调中用 IpPacket.Parse() 获取完整 IP 数据报再交给 TcpPacket 解析4.3 现象抓不到127.0.0.1或localhost的流量但局域网其他机器流量正常原因Npcap 默认禁用 Loopback 抓包即使安装时勾选了选项也可能因 Windows Defender 或第三方防火墙拦截驱动加载。解决运行npcap-sysinfo.exeNpcap 安装目录下检查Loopback Adapter Status是否为Enabled若为Disabled以管理员身份运行netsh interface set interface Npcap Loopback Adapter adminenabled关闭 Windows Defender 实时防护 5 分钟再试。4.4 现象抓包程序运行几分钟后 CPU 占用飙升至 100%OnPacketArrival回调变慢原因SharpPcap 的OnPacketArrival是同步回调若你在回调里做了耗时操作如File.WriteAllText、Console.WriteLine、复杂 JSON 序列化会阻塞抓包线程导致内核缓冲区溢出驱动不断重传形成恶性循环。解决所有 I/O 和计算必须异步化用Task.Run(() { /* 耗时操作 */ })控制台输出改用ConcurrentQueuestring 独立线程批量刷屏设置device.CaptureLength 1500只抓前 1500 字节避免大包拖慢速度。4.5 现象在 .NET 6 WPF 项目中device.StartCapture()抛异常System.AccessViolationException原因WPF 的 Dispatcher 线程模型与 SharpPcap 的非托管回调冲突尤其在device.OnPacketArrival ...绑定后回调可能在非 UI 线程触发Console.WriteLine或控件更新。解决绝对禁止在回调里直接访问 UI 控件改用Application.Current.Dispatcher.BeginInvoke(...)或SynchronizationContext.Post(...)更稳妥做法用BlockingCollectionPacket作为生产者-消费者队列UI 线程定时TakeFromAny更新界面。5. 进阶技巧把抓包能力嵌入 C# 上位机实现“协议-界面-日志”三位一体SharpPcap 的终极价值不是写个控制台 demo而是成为你 C# 上位机的“网络感官”。我给某汽车产线 MES 系统做的方案把抓包、解析、可视化封装成一个NetworkMonitorService类现在每天稳定运行 18 小时故障率低于 0.1%。下面是核心设计和可直接复用的代码片段。5.1 构建线程安全的抓包服务类支持启停、过滤动态切换public class NetworkMonitorService : IDisposable { private ICaptureDevice _device; private readonly BlockingCollectionCapturedPacket _packetQueue new(); private Task _captureTask; private volatile bool _isRunning; public event ActionCapturedPacket PacketReceived; public void Start(string filter tcp) { var devices CaptureDeviceList.Instance; _device devices.FirstOrDefault(d d.Description.Contains(Loopback)) ?? devices[0]; _device.Open(DeviceMode.Promiscuous, 1000); _device.Filter filter; _device.OnPacketArrival OnPacketArrival; _isRunning true; _captureTask Task.Run(() { _device.StartCapture(); }); } private void OnPacketArrival(object sender, CaptureEventArgs e) { try { var packet Packet.ParsePacket(e.Packet.LinkLayerType, e.Packet.Data); if (packet is TcpPacket tcp tcp.PayloadData?.Length 0) { var captured new CapturedPacket { Timestamp e.Timeval.Date, Source ${tcp.SourceAddress}:{tcp.SourcePort}, Destination ${tcp.DestinationAddress}:{tcp.DestinationPort}, Payload tcp.PayloadData.Take(512).ToArray(), // 限制长度 Protocol TCP }; _packetQueue.Add(captured); PacketReceived?.Invoke(captured); } } catch { /* 忽略单包解析异常避免中断整个抓包 */ } } public IEnumerableCapturedPacket GetRecentPackets(int count 100) _packetQueue.Where(p p.Timestamp DateTime.Now.AddSeconds(-30)).Take(count); public void Dispose() { _isRunning false; _device?.StopCapture(); _device?.Close(); _packetQueue?.Dispose(); } } public class CapturedPacket { public DateTime Timestamp { get; set; } public string Source { get; set; } public string Destination { get; set; } public byte[] Payload { get; set; } public string Protocol { get; set; } }为什么这样设计BlockingCollection是 .NET 原生线程安全队列比ConcurrentQueue更适合“生产-消费”模型且支持GetConsumingEnumerable()阻塞式消费Take(512)是硬性保护防止某个异常大包吃光内存event ActionCapturedPacket让 WPF ViewModel 可直接订阅无需Dispatcher中转因为事件在抓包线程触发消费方自行决定是否切线程。5.2 WPF 界面绑定用 MVVM 实现实时抓包表格!-- MainWindow.xaml -- DataGrid ItemsSource{Binding Packets} AutoGenerateColumnsFalse Height400 DataGrid.Columns DataGridTextColumn Header时间 Binding{Binding Timestamp, StringFormatHH:mm:ss.fff} Width120/ DataGridTextColumn Header源地址 Binding{Binding Source} Width150/ DataGridTextColumn Header目标地址 Binding{Binding Destination} Width150/ DataGridTextColumn Header协议 Binding{Binding Protocol} Width80/ DataGridTemplateColumn Header负载 Width200 DataGridTemplateColumn.CellTemplate DataTemplate TextBlock Text{Binding Payload, Converter{StaticResource BytesToHexConverter}}/ /DataTemplate /DataGridTemplateColumn.CellTemplate /DataGridTemplateColumn /DataGrid.Columns /DataGrid// ViewModel.cs private ObservableCollectionCapturedPacket _packets new(); public ObservableCollectionCapturedPacket Packets _packets; private readonly NetworkMonitorService _monitor new(); public MainWindowViewModel() { _monitor.PacketReceived packet { Application.Current.Dispatcher.Invoke(() { _packets.Insert(0, packet); if (_packets.Count 1000) _packets.RemoveAt(_packets.Count - 1); }); }; _monitor.Start(tcp port 502 or tcp port 80); // Modbus HTTP }5.3 日志联动当抓到特定协议时自动触发诊断动作这才是上位机的灵魂——不是被动显示而是主动干预。例如抓到 Modbus 功能码0x04读输入寄存器失败响应异常码0x01就自动弹窗并记录到诊断日志// 在 PacketReceived 事件中追加逻辑 if (IsModbusExceptionResponse(packet.Payload)) { var logEntry $⚠️ Modbus 异常设备 {ExtractUnitId(packet.Payload)} 返回异常码 {ExtractExceptionCode(packet.Payload)}; _logger.Error(logEntry); // 触发 UI 提示WPF Application.Current.Dispatcher.Invoke(() MessageBox.Show(logEntry, Modbus 通信异常, MessageBoxButton.OK, MessageBoxImage.Warning)); // 同步触发硬件复位调用串口指令 _hardwareController.ResetPLC(); }这种“抓包→解析→决策→执行”的闭环才是 SharpPcap 在工业 C# 上位机里不可替代的价值。它让网络问题从“黑匣子”变成“透明流水线”故障定位时间从小时级降到秒级。我坚持在每个新项目里第一周就集成 SharpPcap 抓包模块——不是为了炫技而是给自己留一张“后悔药”。当客户说“你们软件连不上我们的设备”我不再需要猜是 IP 配错了、端口填反了、还是防火墙拦了打开抓包窗口30 秒内就能定位到是对方设备发了 RST 包还是我们发的 SYN 没回应。这种确定性是所有上位机工程师梦寐以求的底气。希望帮到你。本文还有配套的精品资源点击获取
