序：一场“蓄谋已久”的折腾
做 Fatbeans（肥豆）到现在，不知不觉已经两年了。
回想起来，这个过程有曲折、有无奈，也有让人兴奋到睡不着的时刻。在如今这个 AI 遍地跑的年代，这也许是我这么多年软件职业生涯中，最后一个完全用“古法编程”（纯手写）写出来的软件了。
想着应该把这段时间的经历写下来，给自己留点纪念，也希望后来者能从中获得一些经验，少踩几个坑。
“有现成工具，你折腾个啥？”
当时我和同行聊起这个想法时，好些人都是这么和我说的。也是，抓包工具满大街都是，除了 Wireshark、Fiddler、Charles、小黄鸟、WPE 这些知名的，还有一堆不知名的抓包小工具，都很优秀，哪轮得着我动手？
确实，如果仅仅是 HTTP 协议的抓包分析，好用的工具很多。可如果是做 TCP 应用层（如果是底层协议分析，Wireshark 是绝对的王者）的数据分析，这么多年我还真没遇到非常顺手的。总是感觉在将就着用，麻烦就麻烦一点。
直到 2024 年 6 月的一个深夜——
被折腾得身心俱疲后，我瘫在椅子上缓了很久。脑子里突然冒出一个念头：做了这么多年开发，给别人做过那么多软件，为什么不能给自己做一个好用又顺手的抓包工具呢？
（ 嗯，当时的想法就是这么简单，只是没想到会折腾到现在，这个以后再说。）
我真正想要什么呢？
那晚我把需求写在纸上，来回划掉了好几版，最后只剩下几条最核心的“刚需”：
- 精准锁定：要能快速指定一个目标进程，抓到的包，不管什么协议，都只属于这个进程，其他的一律不要出现；
- 高效过滤：要能方便地筛选，过滤掉那些不想看到的噪音数据；
- 灵活导出：能批量导出成几种常见格式，比如 JSON、把 HEX 转成各类代码的定义；
- 清晰交互：要有一个清晰明了的 UI 界面，操作要顺手。
代理、注入、驱动，到底选哪条路？
确定基本需求后，接下来就要选技术方向了。
方案一：代理模式
我首先想到的是代理模式，这种方式是 HTTP 抓包的标配方案，Fiddler、Charles、小黄鸟都是采用的这条技术路线。
这玩意儿是真省事，可问题就一个：目标程序不配合你就抓瞎。有些进程根本不走系统代理，或者自己封装了网络层，你在这头等半天，它那头该直连还是直连。虽然有 Proxifier 这种神器能帮你把不走系统代理的包强制转发到代理端口，但显然还是太麻烦，这不是我想要的。
方案二：注入模式
然后我想是不是做注入方式，直接 hook 进程的网络函数，想拿什么拿什么，感觉一切尽在掌握。WPE 就是这种方式，记得 N 年前还用它抓过传奇的数据包。
但是它的问题也很明显：碰上校验严格或者带反调试的应用，容易把目标程序直接干崩。注入本身就像往人家家里硬闯，对方不跟你拼命才怪。
方案三：驱动模式
最后就只剩驱动模式这条路了。
它的好处是不碰你的目标进程，在网络层面就把流量截住了，想抓谁抓谁。Wireshark 和新版的 Proxifier 都是通过底层驱动在网络层直接抓包的。
不过难搞是真难搞——要装驱动、要过签名、还要处理各种兼容问题。
没有哪种方式是完美的，各有利弊。综合考虑之下，我选了驱动这个方向。当时的想法是长痛不如短痛，宁可前期多折腾，也要后期用得爽。
一个月之后……
从那天开始，我放弃了所有娱乐时间。
什么王者荣耀、吃鸡、魔兽世界、KTV、聚餐，一概与我无关。整个人进入了一种心流的状态。
一个月之后，终于完成了第一版。它已经基本满足了我给自己定的目标，用着也非常顺手。看着它，我在想，是不是该给它认真取个名字了？
上网一通搜、让 AI 取了一堆名字，就是没一个满意的。直到晚上吃饭时看到我的儿子，想起他的小名：肥豆。
哈哈，这不有个现成的吗？
于是，Fatbeans（肥豆）诞生了。自己的作品也真像是培养自己的儿子一样，想不断地让它变得更强。
刚出生的它长这样（可能很多人已早期见过）：
后面那些坑和料——怎么做 TCP 包的变长修改、推广过程中的趣事、HTTPS 和 WebSocket 怎么补、解密怎么搞——后续咱们慢慢讲。
PS: 你有没有和我一样有找不到称手工具的时候？你是怎么做的呢？欢迎评论区聊聊。
