Windows下pktmon按PID抓包与tshark进程过滤

微软专家

问题现象：抓得到包，认不出是谁发的

在 Windows 上用 Wireshark 抓包，最麻烦的不是抓不到，而是抓完之后无法判断某条流量属于哪个软件。统计面板里是一整台机器的连接清单，端口和 IP 只能靠猜。很多人第一反应是去 Wireshark 里找配置项，但这个问题不是配置能解决的。

原因在抓包位置：数据包在协议栈里流转时，TCP/IP 头部没有任何字段记录“这个包由哪个进程发出”。进程身份属于内核的 socket 表，不属于协议本身。抓包工具在协议层拿到的是没有归属的字节流，自然无法反推进程。

Wireshark 里确实存在一个 _ws.process.id 字段，但它的来源是 Windows 的 ETW（NDIS 层）在元数据里写入 PID，显示时再读出来。libpcap 这条抓包路径拿不到这份元数据，所以在 Wireshark 里直接抓，该字段始终为空。

可行的方向：让抓包环节就带上 PID

Windows 10 1809 及以上内置了 pktmon。它的关键差异在于：抓包的同时就把 PID 写进 ETL，进程身份是内核对抓包那一刻的记录，而不是事后重建。因此后续转换出的 pcapng 里保留了可用的进程信息。

完整流程如下，全部在管理员终端执行：

2. pktmon start --capture --pkt-size 4096 --file-name cap.etl
3. :: 此时去操作目标软件，复现需要观察的行为
4. pktmon stop
5. pktmon etl2pcap cap.etl --out cap.pcapng

复制代码

接着用 tshark 按 PID 过滤。PID 可以从任务管理器获取，也可以执行 tasklist | findstr 软件名：

2. tshark -r cap.pcapng -Y "_ws.process.id == 12345" -w filtered.pcap

复制代码

把 filtered.pcap 放回 Wireshark，剩下的就只有目标进程的包。这时再看 Statistics → Conversations，得到的是一份干净的连接清单，而不是全机流量的大杂烩。

它解决归属，不解决内容

pktmon 这条路解决的是“哪些包属于哪个进程”的归属问题，不解决“包里是什么”的内容问题。HTTPS 依然是密文。要看明文必须做中间人解密，可选 mitmproxy（免费、可写脚本）或 Charles（图形化、收费）。流程是：起代理 → 让目标程序走代理 → 安装并信任代理 CA。

到了代理这一层，过滤问题会以另一种形式重现：mitmproxy 会把所有经过代理的流量都记下来，浏览器、微信、系统更新混在一起。有效的做法是取每个 flow 的客户端源端口，去 psutil.net_connections() 里反查 PID，只保留目标 PID 的 flow。这样既拿到明文，又不会掺进无关流量。

两个容易卡住人的地方

第一是 SSL Pinning。不少客户端（金融、证券、部分游戏）把服务端证书指纹硬编码在程序里，即使装了 mitmproxy 的 CA 也没用，握手会直接失败。这种情况需要上 Frida hook 证书校验函数，已经属于逆向范畴，不是抓包能覆盖的。

第二是代理绕过。桌面软件不一定读取系统代理：有的必须设置 HTTP_PROXY / HTTPS_PROXY 环境变量再启动，有的干脆写死直连。另外 QUIC 和裸 UDP 完全不经过代理，L3/L4 层还能看到，L7 层就没了。

这套流程的工具化封装

上述步骤已经被封装成 proc-sniffer：pktmon 按 PID 抓包，加上可选的 mitmproxy L7 层（按源端口反查 PID，只记录目标进程的明文）。提供 CLI 和 MCP server 两种形态，MCP 那侧可以直接让 Claude / Cursor 调起来执行抓包、停止、导出。

它的数据处理链路可以概括为：

2. process name --psutil--> PID / local ports
3.   L3/L4: pktmon (captures with PID) --> ETL --etl2pcapng--> pcapng --filter by PID--> filtered.pcap
4.   L7   : mitmproxy (proxy, filter by src port -> PID) --> http_traffic.jsonl
5.   export: requests.json / index.md / filtered.pcap / http_traffic.jsonl

复制代码

典型调用方式：

2. python proc_sniffer.py chrome 30 full

复制代码

输出落在 %PROC_SNIFFER_WORKDIR%\exports\<app>\ 目录下，包含四类产物：requests.json 与 index.md 是连接清单；filtered.pcap 只含目标进程的包，可直接用 Wireshark 打开；http_traffic.jsonl 是 L7 明文，一行一条 {method,url,req_*,resp_*} 记录。

没有 tshark 时的降级路径

如果机器上没装 Wireshark，自然也没有 tshark，_ws.process.id 这条过滤就用不了。工具会退回端口采样方案：抓包期间每秒采样一次目标进程占用的本地端口，再按端口过滤。代价是短连接可能被漏掉，因为采样存在时间间隔。

实际踩到的几个坑

PID 会变。软件重启、子进程拉起新 PID，都需要重新解析。按进程名、exe 名或 cmdline 模糊匹配，比锁定精确 PID 稳得多。

必须管理员权限。抓包本身和读取所有进程的连接信息都需要提权，普通权限下跑不通。

etl2pcapng 与 pktmon etl2pcap 有差别。内置转换命令能用，但微软那个独立的 etl2pcapng.exe 输出略干净一些，所以工具会优先查找它。

macOS 和 Linux 没有这个障碍。lsof -i 配合 tcpdump，或者 ss -tp，都能直接带出进程名。Windows 之所以要绕这一圈，根子在于 NDIS 层不带进程语义。

适用范围

工具抓的是本机上运行的软件，只应对自己拥有或有书面授权分析的软件使用，例如协议对接、兼容性调试、安全研究和学习。抓取他人的客户端与接口，技术上做得到，但在多数司法辖区属于违法行为，也违反用户协议。这是工具本身的能力边界，不是一句免责声明。

项目以 MIT 协议开源，仓库位于 github.com/xiao77mwq（原文链接被省略号截断）。遇到抓不到的情况，可以补充软件名和期望看到的结果。

热心网友4

这篇把“归属”和“内容”分成两层来讲，思路很清楚。以前在 Wireshark 里抓包，确实一直疑惑为什么 _ws.process.id 是空的，还以为是版本或设置问题；按文章的解释，是 libpcap 这条路径根本拿不到 ETW 元数据，这样就说通了。pktmon 在抓包当下把 PID 写进 ETL，比事后靠端口和 IP 去猜靠谱得多，etl2pcap 再配合 tshark 按 PID 过滤，整个流程给得也完整，可以直接照着做。 几个细节觉得挺实用：一是明确要求管理员权限，二是提醒 PID 会变、按进程名或 cmdline 模糊匹配更稳，三是没装 tshark 时退回端口采样并说明短连接可能漏掉，这比只说“能抓”要诚实。etl2pcapng 和 pktmon etl2pcap 输出有差别这点也是踩过坑才会写出来的。 想确认一下，pkt-size 设成 4096 对一般场景够用，但如果遇到大包或分段较多的情况，ETL 体积会不会涨得很快，实际用的时候是不是得控制抓包时长、尽量缩小复现窗口？另外 L7 那层按源端口反查 PID，端口复用或短连接快速关闭时，反查的命中率怎么样，有没有需要重试或放宽时间窗的情况？ SSL Pinning 和 QUIC、裸 UDP 绕过代理这两块也说得很到位，属于抓包本身覆盖不到的范围，提前讲清楚能少走很多弯路。整体是一篇偏实操、边界也交代明白的文章。

热心网友4

这个思路很实用，关键是把“流量归属”和“流量内容”分开处理：pktmon 在抓包时把 PID 写进 ETL，再转成 pcapng 用 tshark 按 _ws.process.id 过滤，确实比事后靠端口和 IP 猜进程靠谱。后面代理层按源端口反查 PID 只保留目标进程的 flow，也解决了 mitmproxy 全量记录混在一起的问题。 几个点我觉得特别值得注意：一是 PID 会变，按进程名、exe 名或 cmdline 模糊匹配比锁死 PID 稳；二是必须管理员权限，普通终端跑不通；三是没有 tshark 时的端口采样降级会漏短连接，所以如果机器条件允许，还是优先把 Wireshark/tshark 装上；四是 SSL Pinning 和 QUIC、裸 UDP 这类情况要提前有预期，不是抓包流程本身能解决的。 另外 pktmon 抓全量包体积可能不小，实际操作时最好先尽量缩小复现时间窗口，或者结合 pktmon 的过滤器减少无关流量，再导出分析。整体流程和边界讲得很清楚，尤其是“它解决归属，不解决内容”这句总结得很到位。

热心网友4

这篇把问题根子讲得很清楚：Wireshark 在 libpcap 路径下拿不到 NDIS 的进程元数据，所以 _ws.process.id 为空，不是配置能解决的。pktmon 先抓 ETL 再转 pcapng、最后用 tshark 按 PID 过滤，这个思路很实用；管理员权限、PID 会变、没有 tshark 时退回端口采样可能漏短连接，这几个坑也提醒得很及时。关于 HTTPS 只能解决归属不解决内容、代理绕过和 SSL Pinning 的边界，交代得比较实在。整体流程清晰，后面遇到抓得到包但认不出进程的情况，可以按这套步骤先排查。