分类：开源项目

旁观者eCapture：支持龙芯，text 模式看完整 HTTP

旁观者eCapture：支持龙芯，text 模式看完整 HTTP

关于新版本，笔者想聊聊两件事：跑上龙芯，以及更省心的 HTTPS 明文分析。龙芯用户，这次安排上了 v2.8.0 开始，eCapture 增加 Linux/LoongArch64 支持，发行包认准 linux-loong64，提供 tar.gz 和 deb 两种格式。龙芯用户也能沿用熟悉的 TLS 抓包方式，无需安装 CA 证书。龙芯要求 Linux 内核 6.6 及以上，下载前先用 uname -r 看看。目前已完成交叉构建和模拟启动检查，真机完整抓包仍待验证，欢迎有设备的同学反馈。适配说明 text 模式，少一点“人工拼包” 以前看 text 输出，一个 HTTP 请求可能拆成好几段，内容抓到了，排查还得自己拼，多少有点费眼睛。 v2.9.0 给 tls、gotls、gnutls 增加了 pcapng 数据源，依赖 ecapture_decryptor 实时解密，重组完整 HTTP 消息。时间、方向、两端 IP 和端口一起输出，HTTP/2 还有流标识，多连接交织时更容易定位。以 OpenSSL 为例： sudo ecapture tls -m text --text-source=pcapng -i eth0 'tcp port 443' 把 eth0 换成实际网卡，明文直接输出到终端。加上 --pcapfile capture.pcapng，还能留给 Wireshark 复查。 hook 仍是默认数据源；新链路目前支持 TCP 上的 HTTP/1.1、HTTP/2，尚不支持 HTTP/3。使用说明其他修复 pcapng：修复突发流量下因用户态队列造成的丢包，退出时排空待写入的网络包和密钥。配置与加载：重载时保留事件输出地址、轮转设置，统一 CO-RE/非 CO-RE 字节码选择。v2.8.0 记录 Android：v2.8.2 补回发行包中缺少的可执行文件，避免解压之后找不到程序。v2.8.2 记录 eCapture Decryptor，解密能力也能单独用前面提到的 ecapture_decryptor，就是这条实时解密链路的关键：eCapture 负责抓包、提取密钥，它负责解密、重组 HTTP 消息。下图能直观看到两种数据源的区别：它也能独立解密抓包文件，作为 Go SDK 接入自己的工具，示例提供 JSON/HAR 导出。做流量分析平台的同学，欢迎试试，也顺手点个 Star。新版下载：eCapture v2.9.0。

2026-10-31 0 0

eCapture v2 来了，AI Agent 写了 90% 的代码

eCapture v2 来了，AI Agent 写了 90% 的代码

写这篇文章的时候，eCapture 已经发布到 v2.2.1 了。从 v2.0.0 到现在，短短三个月内经历了 5 个版本迭代。趁着版本刚稳，笔者来认真梳理一下 v2 系列到底做了哪些事——不只是给用户看的 Feature，还有架构层面那些"没有功劳只有苦劳"的内功修炼。一、先说结论 v2 系列最核心的变化可以用一句话概括：把整个项目从"能用"变成了"可以持续演进"。表面上，你可能感知到的是：GoTLS 支持连接四元组了，pcap 写入更稳了，Android 的兼容性更好了。但水面以下，是整个内部架构的推倒重建——原来杂乱的 user/ 目录彻底删掉了，所有 8 个 Probe 被重新实现，工厂模式、观察者模式、模板方法模式，该用的设计模式全用上了。第一部分：面向用户 1. GoTLS 终于有四元组了很多同学用 eCapture 抓 Go 应用的 TLS 流量，一直有个痛点：抓到的明文没有连接信息，不知道这条流量来自哪个 IP、哪个端口。 v2.0.1 和 v2.1.0 里，@zenyanle 接连贡献了两个 PR（#947, #960），给 GoTLS Probe 加上了从 tls.Conn 里提取 fd、进而获取连接四元组的能力。现在抓到的 GoTLS 明文，连接的源/目 IP 和端口都有了。对于要做流量审计或安全分析的同学，这个功能很关键。 2. pcap 写入更可靠了 v2.0.0 引入了缓冲 pcapng 写入，带上了接口元数据；v2.2.0 修掉了一个 Close() 里的竞态条件——之前在高并发场景下，DSB keylog 写入会出现数据乱序或丢失的情况。现在写 pcap 文件，序列化保证了，关闭时也不会丢尾巴了。 3. Android 支持更成熟 BoringSSL Android 16 的 offset 更新（#885） Android 模拟器的 DNS 解析问题修复（#957） Android e2e PCAP 模式自动探测活跃网络接口（#976） Build tag 从 androidgki 统一改名为 ecap_android（#930）对于在 Android 上用 eCapture 做流量分析的同学，v2 系列的稳定性比 v1 强了不止一个量级。 4. 重新支持 --cgroup_path 参数 v2.0.0 的大重构里，tls 子命令的 --cgroup_path 参数被不小心砍掉了。v2.2.1 把它恢复了（#975）。用 cgroup 做隔离抓包的同学，可以放心升级了。 5. 全覆盖的 E2E 测试体系 v2.0.0 里加入了 72+ 个 E2E 测试场景，覆盖了 bash、tls、gnutls、gotls 全部模块，以及 pcap/keylog/text 三种抓包模式。这意味着每次发版前，核心路径都会被自动验证一遍。用户升级时踩到"老功能突然坏了"这种坑的概率，大幅降低。第二部分：面向开发者 Warning：以下是面向 eCapture 开发者或想给项目贡献代码的同学的内容，只是日常使用的话可以不用往下看。 1. 架构重构：user/ 目录彻底消失了 v1 时代，所有 Probe 的代码都堆在 user/ 目录下，随着支持的协议越来越多，这个目录越来越难维护——命名不统一、接口不一致、职责边界模糊。 v2.0.0 用 7 个 Phase 完成了完整的迁移：所有 8 个 Probe（Bash、Zsh、MySQL、Postgres、OpenSSL、GnuTLS、NSPR、GoTLS）完成了标准化迁移。每个 Probe 现在都有统一的文件结构： internal/probe/<name>/ config.go # 配置，嵌入 BaseConfig，实现 Validate() event.go # 事件结构，实现 DecodeFromBytes() register.go # init() 里调用 factory.RegisterProbe() <name>_probe.go # 嵌入 BaseProbe，实现 Initialize/Start/Stop/Close 2. 核心设计模式 v2 引入了三个设计模式，彻底解耦了各个组件：工厂模式：每个 Probe 在 register.go 的 init() 里自注册，CLI 命令通过 factory.NewProbe() 创建实例，互不依赖。模板方法模式：BaseProbe 实现公共流程，子 Probe 只需覆写差异化逻辑。观察者模式：事件通过 EventDispatcher 分发，Output Writer（file/pcap/keylog/websocket）作为订阅者，彼此完全解耦。 3. 事件流转全链路从 eBPF 内核态抓到数据，到最终写入文件或推送到远端，完整路径如下：这个链路在 v2 里被完整地标准化了。之前 v1 里部分 Probe 是直接写文件，绕过了 Dispatcher，导致远端推送（ecaptureQ 模式）下数据丢失——这个 Bug 在 v2.1.0 的 #964 里修掉了。 4. 破坏性变更备忘如果你有基于 eCapture 源码开发的二次开发代码，升级 v2 需要注意以下几点：变更项 v1 v2 Probe 代码位置 user/ internal/probe/ Build tag（Android） androidgki ecap_android eBPF bytecode 目录项目根 ebpfassets/ Probe 注册方式手动初始化 init() 自注册 + Factory 更丰富的官方文档 V2.0.0 里，官方网站也做了重构。除了官网首页，使用文档也经历了大幅度的扩充和重构，分为概述、架构设计、捕获模块、输出格式、开发指南等多个章节，覆盖了从用户入门到开发者贡献的全流程。番外：AI Agent 写了多少代码？最近 AI Agent 是个大热词，笔者被问到最多的问题就是：eCapture v2 里，到底有多少代码是 AI 写的？说个实际数据。从 v2.0.0 到 v2.2.1，GitHub 上合并了约 37 个 PR，分布如下：贡献者 PR 数量占比 @Copilot（GitHub Copilot AI Agent） 13 ~35% @cfc4n（笔者） 21 ~57% 社区贡献者（@zenyanle、@Carl Chen 等） 3 ~8% v2.0.0 那次大重构是 AI 参与度最高的版本：8 个 Probe 的标准化迁移、E2E 测试框架搭建，10 个 PR 直接由 @Copilot 提交，占当版 PR 总量的近 45%。再看代码行数。说实话，这个数字笔者自己都没料到会这么极端。v2 系列 90% 的代码是 AI 写的，笔者的角色更像产品经理加 Code Reviewer。贡献者新增行数删除行数新增占比 @Copilot（AI Agent） 28,426 10,392 ~90% @cfc4n（笔者） 2,097 781 ~7% 社区贡献者 1,082 96 ~3% 但聪明的同学一定想问：AI 是怎么知道该做什么的？答案是：每一个 AI PR 背后，都对应着笔者写的一个详细 Issue。任务描述写得越清楚，AI 出活越靠谱；描述含糊的，烂 PR 照样打回去重写。那段时间的工作流，基本是"笔者当产品经理+Code Reviewer，AI 当执行工程师"。 AI Agent 擅长的是模式清晰、重复度高的任务——比如"按照这个标准模板，把剩余 6 个 Probe 全部重构一遍"，这种活交给 AI 效率极高。但涉及 eBPF 内核行为的细节、并发竞态的根因分析，还是得靠人来兜底。 v2 这次实践下来，笔者的感受是：AI Agent 不是替代开发者，而是把开发者从重复劳动里解放出来，让人能把精力放在真正需要判断力的地方。最后 v2 是一次迟到很久的重构。老实说，v1 时代的 user/ 目录，笔者自己看着都头疼。这次借着 AI Coding Agent 的帮助，总算把欠的技术债还掉了大半。后面 v2.x 的迭代重心会放在功能上——更多 TLS 库版本支持、更丰富的过滤能力、更完善的远端推送协议。架构的活算是告一段落了。有问题欢迎到 GitHub 提 Issue，PR 更欢迎。 GitHub: https://github.com/gojue/ecapture 官网: https://ecapture.cc

2026-04-06 0 0

eCaptureQ：给1.5万星标的开源项目eCapture装个酷炫的驾驶舱！

eCaptureQ：给1.5万星标的开源项目eCapture装个酷炫的驾驶舱！

嘿，eCapture 旁观者的铁子们！既然你摸到了这里，想必你也是 eCapture 这款“黑科技”的忠实粉丝了。能在 GitHub 上豪取 1.5万+ Star，成为网络抓包领域的明星项目，靠的就是它那不讲道理的硬核实力：不用装证书，不用搞中间人代理，直接在内核里把 TLS 明文给你安排得明明白白。这种感觉，就像开了“上帝视角”，爽！ eCapture 作为一款 CLI 工具，强大、纯粹，是极客的浪漫。但说实在的，浪漫归浪漫，当真正在炮火连天的生产环境或复杂的调试场景里干活时，我们都或多或少地被这“朴素”的命令行界面给“伤害”过。 CLI 的“甜蜜”烦恼：眼花缭乱，手忙脚乱你是不是也对这些场景感同身受？ “信息瀑布”糊脸 sudo ecapture tls 命令一敲，你的终端就变成了“信息瀑布”现场，日志刷得比瀑布还快。想在流量高峰期用肉眼找到某个特定的请求？祝你好运！这哪是抓包，这简直是考验眼速的极限挑战。玩“大家来找茬”游戏一个请求（Request）发出去，它的响应（Response）在哪儿呢？它可能在上面，也可能在下面，还可能被一堆其他日志夹在中间。你只能瞪大眼睛，在滚动的文本里玩“大家来找茬”的游戏，费时费力还容易看错行。跟 grep 和 awk 斗智斗勇想过滤一下？没问题，grep、awk、sed 三件套伺候。但每次想实现一个稍微复杂点的过滤，比如“找出来自 api.example.com 并且响应码是 500 的 POST 请求”，都得先跟一长串的正则表达式和管道符斗智斗勇一番。心累啊！只见树木，不见森林线性的文本输出，让我们很难对全局流量有个直观的认识。当前到底有几个域名在通信？哪个接口访问最频繁？哪些请求慢得像蜗牛？光看日志，一头雾水。 eCapture 已经帮我们搞定了从内核捞数据这个最硬核的活儿。但怎么把这些原始数据舒舒服服地看明白，一直是个“历史遗留问题”。现在，是时候终结这一切了！隆重介绍 eCaptureQ！在此，特别鸣谢Hugo同学，他是eCaptureQ项目的主要推动者、设计者，感谢他为这个项目的贡献。 eCaptureQ：鸟枪换炮，体验起飞！ eCaptureQ 不是要取代 eCapture，恰恰相反，它是 eCapture 的“灵魂伴侣”和“官方指定驾驶舱”。它把 eCapture 强大的引擎能力，用一个现代化的图形界面给你呈现出来，让你从手摇拖拉机一步到位，坐进全景天窗的智能驾驶舱。 eCaptureQ 就是专为解决上面那些痛点而生的： 1. 从“刷屏”到“列表”，一目了然 eCaptureQ 做的第一件事，就是把 eCapture 吐出来的原始文本流，实时变成了一个结构化的请求列表。就像你天天在用的浏览器开发者工具一样。清爽！主机、方法、URL、状态码、耗时……所有关键信息整整齐齐地排列好，告别眼花缭乱。省心！请求和响应自动配对，再也不用玩“找茬”游戏了。 2. 告别命令行，指哪打哪忘掉那些复杂的 grep 命令吧，现在你只需要动动鼠标和键盘。随心搜：顶部的搜索框就是你的魔杖，输入域名、路径、状态码，列表瞬间过滤出你想要的结果。随便点：想看哪个请求的详情？点它！完整的请求头、请求体、响应头、响应体立刻呈现。JSON 自动格式化高亮，简直不要太贴心。任意排：想找最慢的请求？点一下“耗时”列头，一秒排序，性能瓶颈无所遁形。 3. 两种模式，怎么舒服怎么来我们懂你，eCapture 的用户遍布天下，工作姿势也千奇百怪。eCaptureQ 提供了两种模式，完美适配你的工作流。集成模式（单机版）如果你习惯在本地 Linux 或安卓上干活，这个模式最适合你。eCaptureQ 自带了 eCapture 核心程序，sudo 启动，点击 "Start"，开箱即用，一条龙服务。远程模式（客户端/服务端分离）这才是真正的王炸！我们知道，你的 eCapture 很多时候都跑在远端的服务器、虚拟机甚至 Docker 里。现在，你可以在服务器上用 --ecaptureq 参数启动 eCapture，它会开启一个 WebSocket 服务。然后，你就可以在自己的 Windows 或 macOS 笔记本上，悠闲地打开 eCaptureQ 客户端，远程连上它！这意味着什么？优雅！在你舒服的 Mac 上，用着精美的 GUI，分析远端 Linux 服务器的流量。安全！让需要 root 权限的脏活累活在远端服务器上跑，你在本地用普通用户愉快地分析，安全又省心。协同！多个小伙伴可以连到同一个 eCapture 实例上，一起围观分析，效率翻倍。使用方式启动eCapture 比如，先在Android等系统上开启eCapture的抓包： sudo ./ecapture tls --ecaptureq ws://0.0.0.0:28257 打开eCaptureQ查看在你的桌面系统中，打开eCaptureQ，你将在界面上看到被捕获系统上的TLS明文通讯消息。一句话总结 eCaptureQ 就是 eCapture CLI 的一次体验革命。它保留了 eCapture 100% 的硬核能力，同时把交互体验从“命令行时代”直接拉到了“图形化时代”。它就是你期待已久的那个现代化仪表盘，让你能真正聚焦于数据分析本身，而不是和工具较劲。别犹豫了，快去下载 eCaptureQ，给你的 eCapture 引擎配上它应得的酷炫驾驶舱吧！

2025-11-02 0 0

eCapture开源项目三周年， v1.0.0 稳定版发布

eCapture开源项目三周年， v1.0.0 稳定版发布

eCapture旁观者是一款基于 eBPF 技术的高级网络工具，专注于 SSL/TLS 协议的明文数据捕获与解密。凭借其强大的功能和丰富的特性，eCapture 已成为网络调试和安全分析领域的重要工具。自2022年3月发布至今三年，累计1.4万颗星。核心功能 1. 多协议支持加密库支持：兼容 OpenSSL、GnuTLS、BoringSSL 等多种加密库，支持 HTTP/2 和 QUIC 协议捕获。协议兼容性：涵盖 TLS 1.2 和 TLS 1.3，确保对最新协议的全面支持。 2. 智能数据捕获 eBPF 引擎：基于 eBPF 技术实现高效的网络数据捕获和协议解析。双栈支持：支持 IPv4 和 IPv6 的双栈模式，确保在不同网络环境中的灵活应用。四元组过滤：提供灵活的过滤功能，精准捕获目标流量。 3. 主密钥捕获自动化捕获：自动检测并捕获 TLS 1.2 和 TLS 1.3 的主密钥，实现加密流量的实时解密。 Wireshark 集成：生成与 Wireshark 兼容的流量文件，支持离线解密和分析。 4. 多种捕获模式 Pcap 模式：生成 Pcapng 格式的流量文件，便于后续分析。 Keylog 模式：捕获通信密钥，生成与 Wireshark 兼容的密钥日志文件。 Text 模式：实时输出明文数据，方便开发者快速调试和分析。 5. 跨平台支持操作系统：支持 Linux 和 Android 系统，确保在不同操作环境中的稳定运行。架构兼容：兼容 x86_64 和 ARM64 架构，适用于多种设备和服务器环境。 6. 自动化与智能检测智能模式选择：自动识别 CO-RE 和非 CO-RE 模式，优化运行性能。内存优化：提供灵活的内存配置选项，提升资源利用率和系统稳定性。 7. 高性能与兼容性高效处理：基于 eBPF 的高效数据处理，支持大规模并发和长时间抓包。稳定性提升：经过多次版本迭代和优化，v1.0.0 版本具有更高的稳定性和兼容性。 8. 灵活配置自定义过滤：支持灵活的数据过滤配置，精准捕获目标流量。多种输出格式：支持多种数据输出格式，满足不同场景的需求。日志管理：提供详细的日志记录，方便后续分析和审计。 9. 命令审计 Shell 审计：捕获 Bash 和 Zsh 命令行的输入和输出，支持实时监控和记录。数据库监控：监控 MySQL 和 PostgreSQL 的 SQL 查询，提供数据库操作审计功能。 10. Wireshark 插件支持流量分析：生成兼容 Wireshark 的流量文件，方便使用 Wireshark 进行深入分析。密钥日志集成：支持在 Wireshark 中加载密钥日志，实现加密流量的实时解密。技术特点 1. 模块化架构功能扩展：采用模块化设计，便于功能扩展和维护。灵活配置：支持多种配置选项，满足不同用户的需求。 2. 多语言开发内核空间：使用 C 语言实现内核空间功能，确保高效和稳定。用户空间：使用 Golang 和 CGO 实现用户空间功能，提升开发效率和代码维护性。 3. 交叉编译支持多架构支持：支持在 amd64 和 ARM64 两种架构下进行交叉编译，生成适用于不同平台的二进制文件。工具链支持：提供丰富的交叉编译工具链，方便用户根据需求进行编译和配置。版本更新 v1.0.0 版本新增功能支持 Docker 镜像，简化部署和使用。新增对 OpenSSL 3.4.0 和 GnuTLS 的密钥捕获支持。支持 IPv6 数据包捕获，扩展网络协议支持。增加 Zsh 命令审计功能，提升安全监控能力。关键修复修复 Ubuntu 24.04 系统上初始化脚本的兼容性问题。解决 ARM64 版本无法正常工作的问题。优化构建过程，提升整体稳定性和性能。社区与开发开源社区项目星数：自 2022 年 3 月创建以来，累计获得 14,000+ 颗星，社区活跃度高。贡献者：吸引了众多开发者参与贡献，共同推动项目发展。作者信息开发者：由陈驰（CFC4N）开发，详见其个人博客 www.cnxct.com。开源精神：秉持开源精神，欢迎更多开发者加入社区，共同改进和完善项目。部署与使用易用部署二进制文件：提供预编译的二进制文件，支持 Linux 和 Android 系统。 Docker 镜像：发布 Docker 镜像，简化部署和使用过程。文档支持：提供详细的使用文档和配置指南，帮助用户快速上手。总结 eCapture v1.0.0 是一款功能强大、技术先进的网络工具，凭借其多协议支持、智能数据捕获、跨平台兼容性和高性能，成为开发者和安全研究人员的得力助手。通过三年的不断开发和优化，eCapture 在网络调试和安全分析领域树立了良好的口碑。未来，随着社区的不断贡献，eCapture 将继续保持其技术领先，服务于更多用户。

2025-08-22 0 0

eCapture v0.9.0支持IPv6、GnuTLS密钥捕获、Zsh审计，国内CDN上线

eCapture v0.9.0支持IPv6、GnuTLS密钥捕获、Zsh审计，国内CDN上线

自上篇文章〔L4LB四层负载均衡IP伪造漏洞〕以来，已经快四五个月没更新，不是笔者太懒，而是实在太忙了，忙得连放屁的时间都没有。得益于社区朋友的贡献，增加了一些新特性，今天来分享给大家。 eCapture v0.9.0版本发布新功能: 支持Docker镜像拉取，添加对 OpenSSL 3.4.0 的支持，支持 gnutls 的 keylog 和 pcap 模式，允许捕获 IPv6 数据包，拆分日志记录器。错误修复: 修复了多个系统和功能的关键错误，包括在 Ubuntu 24.04 上的初始化脚本问题和 arm64 版本的兼容性问题。改进: 更新了日志记录器，优化了构建过程，添加了新的工作流和文档更新。科普：eCapture是什么 eCapture旁观者是一个无需CA证书，无侵入的HTTPS/TLS明文抓包工具。可以在Linux 4.18以上版本使用，同时也支持Android arm64 5.5以上版本。项目发布三年累计14000颗星。功能介绍 eCapture 有8个模块，分别支持openssl/gnutls/nspr/boringssl/gotls等类库的TLS/SSL加密类库的明文捕获、Bash、Mysql、PostGres软件审计。 bash 捕获bash、zsh命令行的输入输出 gnutls 捕获基于gnutls类库加密通讯的明文内容 gotls 捕获使用Golang语言编写的，基于内置crypt类库实现TLS/HTTPS加密通讯的明文内容 mysqld 捕获Mysqld的SQL查询，适用于数据库审计场景，支持Mysqld 5.6/5.7/8.0等 nss 捕获基于nss类库加密通讯的明文内容 postgres 支持postgres 10+的数据库审计，捕获查询语句 tls 捕获基于Openssl/Boringssl的加密通讯的明文内容，支持Openssl 1.0.x/1.1.x/3.x系列所有版本，支持BoringSSL所有发行版本你可以通过ecapture -h来查看这些自命令列表。重大更新支持Docker Image镜像启动，可以到Docker Hub下载。支持gnutls模块的keylog 和 pcap 模式对Gnutls TLS类库的密钥捕获、pcapNG格式文件存储；支持文本模式-m text下，HTTP 2.0的内容解码；支持IPv6 协议的网络包捕获；支持非Android的boringSSL库加密通讯的明文、密钥、pcapNG捕获；支持Zsh Shell的命令执行安全审计；支持OpenSSL模块的文本模式下，五元组关联数据；增加eCapture项目的国内下载地址：https://ecapture.cc/zh/download/ （自费CDN小水管，各位黑客大哥别把我帐号刷欠费了） Gnutls TLS类库捕获在eCapture的gnutls模块中，新增TLS加密通讯的密钥捕获，以及保存为pcapNG格式文件。目标进程类库确认以使用gnutls类库的git命令为例，当执行git pull时，会调用git-remote-http程序来访问远程仓库，该程序使用Gnutls类库 ldd /usr/lib/git-core/git-remote-http linux-vdso.so.1 (0x0000ffff9c6ff000) libcurl-gnutls.so.4 => /lib/aarch64-linux-gnu/libcurl-gnutls.so.4 (0x0000ffff9c550000) libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffff9c4b0000) ... 演示过程完整演示如下：首先，在终端中启动ecapture sudo ecapture gnutls -m pcapng -i ens160 -w gnutls-github.pcapng tcp port 443 之后，在另外一个终端拉取git仓库 git pull 演示结果 eCapture的结果输出： sudo ecapture gnutls -m pcapng -i ens160 -w gnutls-github.pcapng tcp port 443 2024-12-15T13:31:38Z INF AppName="eCapture(旁观者)" 2024-12-15T13:31:38Z INF HomePage=https://ecapture.cc 2024-12-15T13:31:38Z INF Repository=https://github.com/gojue/ecapture 2024-12-15T13:31:38Z INF Author="CFC4N <cfc4ncs@gmail.com>" 2024-12-15T13:31:38Z INF Description="Capturing SSL/TLS plaintext without a CA certificate using eBPF. Supported on Linux/Android kernels for amd64/arm64." 2024-12-15T13:31:38Z INF Version=linux_arm64:v0.9.0:6.5.0-1025-azure 2024-12-15T13:31:38Z INF Listen=localhost:28256 2024-12-15T13:31:38Z INF eCapture running logs logger= 2024-12-15T13:31:38Z INF the file handler that receives the captured event eventCollector= 2024-12-15T13:31:38Z INF listen=localhost:28256 2024-12-15T13:31:38Z INF https server starting...You can upgrade the configuration file via the HTTP interface. 2024-12-15T13:31:38Z INF Kernel Info=5.15.167 Pid=150461 2024-12-15T13:31:38Z INF BTF bytecode mode: CORE. btfMode=0 2024-12-15T13:31:38Z INF GnuTlsProbe init eBPFProgramType=PcapNG model=PcapNG 2024-12-15T13:31:38Z INF module initialization. isReload=false moduleName=EBPFProbeGNUTLS 2024-12-15T13:31:38Z INF Module.Run() 2024-12-15T13:31:38Z INF GnuTLS version found Version=3.7.3 2024-12-15T13:31:38Z INF GnuTLS binary path binaryPath=/lib/aarch64-linux-gnu/libgnutls.so.30 elfType=2 2024-12-15T13:31:38Z INF BPF bytecode loaded bytecode filename=user/bytecode/gnutls_3_7_3_kern_core.o 2024-12-15T13:31:38Z INF Hook type: Gnutls elf ElfType=2 IFindex=2 IFname=ens160 PcapFilter="tcp port 443" binrayPath=/lib/aarch64-linux-gnu/libgnutls.so.30 2024-12-15T13:31:38Z INF Hook masterKey function: gnutls_handshake 2024-12-15T13:31:38Z INF target all process. 2024-12-15T13:31:38Z INF packets saved into pcapng file. pcapng path=/home/cfc4n/gnutls-github.pcapng 2024-12-15T13:31:39Z INF perfEventReader created mapSize(MB)=4 2024-12-15T13:31:39Z INF perfEventReader created mapSize(MB)=4 2024-12-15T13:31:39Z INF module started successfully. isReload=false moduleName=EBPFProbeGNUTLS 2024-12-15T13:31:43Z INF CLIENT_RANDOM save success ClientRandom=8517a6741b2a67369079309c2eac84094aacecef39a5514c6da25da7e219401d TlsVersion=GNUTLS_TLS1_3 eBPFProgramType=PcapNG 2024-12-15T13:31:44Z INF packets saved into pcapng file. count=35 2024-12-15T13:31:46Z INF packets saved into pcapng file. count=2 ^C2024-12-15T13:32:15Z INF packets saved into pcapng file. count=37 2024-12-15T13:32:15Z INF Module closed,message recived from Context 2024-12-15T13:32:15Z INF iModule module close 2024-12-15T13:32:15Z INF bye bye. 可以清楚得看到TLS通讯协议是GNUTLS_TLS1_3，密钥的ClientRandom是8517a6741b2a67369079309c2eac84094aacecef39a5514c6da25da7e219401d。 Wirehark查看网络包如图，不光能看到网络包对应发起的进程信息，还能看到HTTPS的明文内容。 Docker Hub eCapture的Docker Hub仓库地址为：https://hub.docker.com/r/gojue/ecapture ，当前最新版为 v0.9.1 。 # 拉取镜像 docker pull gojue/ecapture:latest # 运行 docker run --rm --privileged=true --net=host -v ${宿主机文件路径}:${容器内路径} gojue/ecapture ARGS Zsh Shell审计启动命令sudo ecapture zsh，即可捕获zsh上运行的所有命令，对于安全审计场景，还是比较方便快捷的。其他更多功能，请查看项目变更日志。变更日志功能 feat: 在 gnutls 中支持 keylog 和 pcap 模式 feat: 移除 tcp 数据包限制 kern: 支持 openssl 最新版本（3.4.0, 1.1.1w 等） feat: 以文本模式解析 http2 数据 feat: 允许捕获 ipv6 数据包 kern: 在 ebpf TC hook 中支持 uid/pid 过滤 user: 拆分记录器，将其分为记录器和事件收集器 kern: 添加对非 Android boringssl 库的支持 kern: 调整密钥获取的时机，以区分 TLS feat: 支持捕获 zsh 命令 feat: 用远程地址信息丰富地址信息 feat: 支持新版本检测功能 Bug 修复 builder: 修复 init 脚本在 ubuntu 24.04 系统上无法运行的问题 #667 修复 uprobe 类型 hook 的参数错误问题修复 arm64 版本无法工作的 bug (#649) builder: docerk 构建错误：未找到头文件修复 Golang TLS 模块中读取函数返回值的问题 fix: 修复在调试模式下 make 时未声明标识符的错误 fix: 回退到默认版本并发出警告 fix: 创建 output.log 失败 pkg: 修复在关闭的通道上发送数据的问题 fix: HEAD 请求中的 DumpResponse 错误 fix: 截断的主体转储错误 user: 修复 #553，hashLen 不允许超过 64 字节 android 版本编译失败 user: 修复 #542，masterkey 被多次写入 pcapng fix: pcap 过滤器未按预期工作 fix: 修复 ecapture Docker 镜像 CVE-2024-24790 fix: 处理器打印 incoming chan is full 并退出改进 cli: 使用格式化记录器 rs/zerolog chore: 在构建过程中使用 -tags 'netgo' 以避免由于不同 Linux 发行版中的 glibc 版本不同而导致的 SIGSEGV 常量参数通知 cli: 更新 docker 使用说明添加可能的 Linux 内核配置路径 user: 在 gotls 模块中格式化 clientRandom 字符串 cli: 支持记录器级别使用 kprobe/__sys_connect 替代 uprobe/connect makefile: 优化内核头文件的生成机制添加 dockerfile BPF 名称应在 _core/_noncore 后附加 user: 为面向服务的架构做准备 docs: 修复日语翻译 chore: 在 rpmBuild.spec 中移除未使用的标志 BuildRequires workflows: 更新 Linux 源 tgz 文件版本 build(deps): 将 golang.org/x/crypto 从 0.23.0 升级到 0.31.0 feat: 检测 CAP_BPF pkg: 添加 http2 请求/响应单元测试 feat: 在销毁 socket 时清理映射 user: 调整内核版本显示的时机，避免过低感谢感谢社区小伙伴的贡献：Leon Hwang、SenberHu、yuweizzz、sancppp、Nadeshiko Manju、行旅途、w568w 等，一起继续为爱发电。

2024-12-26 0 0

eCapture v0.8.0：CO-RE、非CO-RE二合一，交叉编译amd64、arm64双版本

eCapture v0.8.0：CO-RE、非CO-RE二合一，交叉编译amd64、arm64双版本

eCapture是什么 eCapture旁观者是一个无需CA证书，无侵入的HTTPS/TLS明文抓包工具。可以在Linux 4.18以上版本使用，同时也支持Android arm64 5.5以上版本。项目发布共两年累计8200颗星。新手友好：CO-RE、非CO-RE二合一下载只下一个版本使用eBPF技术实现的软件，总会分不清CO-RE（一次编译，到处运行），在选择CORE、非CORE版本而烦恼吗？不知道系统是否支持，也不知道什么是CORE。下载一个android版的eCapture，不知道要下android-aarch64.tar.gz还是android-aarch64-nocore.tar.gz。这下你不用纠结了，eCapture 0.8.0起，实现了兼容，会自动选择CORE版本。而且，统一使用了面向产品化的CPU架构命名，分为amd64和arm64两种，下载时注意区分。使用自动探测BTF、自动选择在eCapture 0.8.0里，你只需要按照以往使用习惯，直接运行sudo ecapture tls等命令即可，无需关注系统是否支持BTF，eCapture会自动探测系统的支持情况，选择相应的eBPF字节码进行加载。手动指定BTF 如果你在使用时，出现加载出错的情况，那么你也可以尝试手动指定eBPF字节码类型，让eCapture来指定加载。参数为-b 或--btf，值为3种： 0：auto，自动探测、自动选择，即默认模式。 1：core，CO-RE模式，一般支持CO-RE模式的内核，也都会支持non-CO-RE模式。 2：non-core：非CO-RE模式，适用于CONFIG_DEBUG_INFO_BTF=n的情况。 sudo ./bin/ecapture -h NAME: ecapture - capture text SSL content without CA cert by ebpf hook. VERSION: linux_arm64:v0.8.0:5.15.0-105-generic OPTIONS: -b, --btf=0 enable BTF mode.(0:auto; 1:core; 2:non-core) Linux运行示例使用-b=2参数指定后，捕获curl https://ecapture.cc，把保存的ecapture.pcapng文件用Wireshark打开。可以看到，通过命令行参数-b=2指定后，加载的BPF bytecode模式为non-CORE，同时，加载的字节码文件也发生了变化。同时，eCapture也准确的捕获了TLS 1.3的加密密钥、明文，以及准确的捕获了网络包所属进程curl，进程的PID 85432 Android版的eCapture使用方式与Linux一致，也是-b参数。新版下载 eCapture v0.8.0 Github 下载 ecapture-v0.8.0-android-amd64.tar.gz ecapture-v0.8.0-android-arm64.tar.gz ecapture-v0.8.0-linux-amd64.tar.gz ecapture-v0.8.0-linux-arm64.tar.gz Warning 以下是面向eBPF开发者的内容，使用者可以不用看。交叉编译 Cross-compilation 内核头文件要交叉编译eCapture工具，您需要安装目标体系结构的内核头文件。需要安装linux-source软件包。 kernel_ver=`uname -r | cut -d'-' -f 1` sudo apt-get install -y linux-source-$kernel_ver cd /usr/src sudo tar -xf linux-source-${kernel_ver}.tar.bz2 cd /usr/src/linux-source-${kernel_ver} test -f .config || yes "" | sudo make oldconfig yes "" | sudo make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- prepare V=0 更多交叉编译配置可参考仓库的workflows 依赖环境在amd64架构下，交叉编译arm64架构的二进制文件，需要安装gcc-aarch64-linux-gnu工具链。同样，在arm64架构下，交叉编译amd64架构的二进制文件，需要安装gcc-x86-64-linux-gnu工具链。交叉编译器 amd64 : gcc-aarch64-linux-gnu arm64 : gcc-x86-64-linux-gnu 编译命令要在ubuntu amd64 系统上构建 arm64的产物，您可以设置 CROSS_ARCH环境变量来实现交叉编译。 CROSS_ARCH=arm64 make 产物构建（交叉编译）以Github Action中的release为例 - name: Release amd64 run: | make clean make env make -f builder/Makefile.release release SNAPSHOT_VERSION=${{ github.ref_name }} - name: Release arm64 (CROSS COMPILATION) run: | make clean make env CROSS_ARCH=arm64 make -f builder/Makefile.release release SNAPSHOT_VERSION=${{ github.ref_name }} 即可编译生成amd64、arm64两种CPU架构的eCapture二进制文件，包括Linux、Android两个系统版本。技术难点 eCapture项目是一个多语言实现的项目，内核空间代码使用C语言编写，用户空间代码使用Golang、CGO编写。其中eBPF加载器、eBPF Map读写是用纯Go实现。涉及到libpcap做cBPF转eBPF的包过滤功能，是使用纯C编写的。 Kernel Space 内核空间代码由于eCapture的大部分功能都是Uprobe，不太涉及内核的结构体。所以大部分情况下，都可以正常运行，只要解决编译问题。 CO-RE 头文件 CO-RE的版本，因为都支持重定位，只需要内置一个版本的vmlinux.h，能正常编译后，就可以放到支持CO-RE的内核上运行。 non-CO-RE 头文件 non-CO-RE版本，依赖编译时的内核头文件。在Ubuntu 22.04 Server上，只有当前CPU架构的完整头文件。如果需要交叉编译，则需要下载Linux 内核源码，重新生成目标CPU架构的头文件。这就是前面提到内核头文件预生成部分：make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- prepare。编译器 eBPF字节码的编译，完全使用llvm(clang)来编译，只需要编译参数中的-D__TARGET_ARCH_$(LINUX_ARCH)、-target $(TARGET_ARCH) 是对应目标CPU架构信息即可。 User Space 用户空间代码用户空间代码的核心功能是选择eBPF字节码，以及调用libpcap类库，将命令行参数转化解析编译成cBPF代码，再转化为eBPF字节码。再替换到过滤器中。 libpcap的交叉编译项目本身是支持交叉编译的，需要指定目标架构，以及编译器CC、打包器AR。在amd64、arm64的Linux上，较为常见的交叉编译、打包归档工具为x86_64-linux-gnu-gcc、x86_64-linux-gnu-ar，编译参数中指定即可： CC=$(CMD_CC_PREFIX)$(CMD_CC) AR=$(CMD_AR_PREFIX)$(CMD_AR) CFLAGS="-O2 -g -gdwarf-4 -static" ./configure --host=$(LIBPCAP_ARCH) CGO混合编译在golang的env里，默认的编译、打包工具是CC='gcc'和AR='ar'，及时你设定GOARCH=$(GOARCH) 来做Go层的交叉编译，但依旧无法完成CGO的交叉编译。所以，这里你需要重新设定他们为交叉编译的工具链，方法跟上面一致。 GOOS=linux GOARCH=$(GOARCH) CC=$(CMD_CC_PREFIX)$(CMD_CC) \ $(CMD_GO) build -tags $(TARGET_TAG) -ldflags "-w -s -X 'github.com/gojue/ecapture/cli/cmd.GitVersion=$(TARGET_TAG)_$(GOARCH):$(VERSION_NUM):$(VERSION_FLAG)' -linkmode=external -extldflags -static " -o $(OUT_BIN) 听上去很简单，可笔者确是折腾了好久，掉了不知道多少根头发才解决。希望笔者的经验可以帮助到你，让你不掉头发。社区新人从上篇文章eCapture v0.7.4发布支持Pcap Filter包过滤语法至今已经2个多月了，笔者一直没时间写。近期工作特别忙，花在eCapture上的时间也很少。在这段时间内，社区涌现了好多为新人，持续提issue、提PR做贡献，尤其是ruitianzhong和sancpp两位同学。他们在社区提了issue后，我觉得打字效率太低，为了节省时间，跟他们约了视频会议讨论。说来也巧，他们在群里开场介绍后，发现都是西安电子科技大学的，现在通过eCapture认识了，有了共同的话题，相谈甚欢，还打算一起参加全国大学生计算机系统能力大赛呢。希望他们能取得好的比赛成绩，也欢迎更多的人参与到开源项目建设中。

2024-05-06

2 0

ecapture v0.7.4发布，支持Pcap FIlter包过滤语法

ecapture v0.7.4发布，支持Pcap FIlter包过滤语法

eCapture是什么 eCapture旁观者一个无需CA证书，无侵入的HTTPS/TLS明文抓包工具。可以在Linux 4.18以上版本使用，同时也支持Android arm64 5.5以上版本。项目在2022年4月发布，目前7900颗星。超强特性：Pcap Filter 包过滤 eCapture v0.7.4版本发布支持Pcap Filter Syntax，你可以像tcpdump一样使用pcap filter表达式来过滤网络包。在tls或gotls模块中，当运行模式参数-m为pcap时，支持pcap filter表达式。在命令行最后的参数中设定，例如： sudo bin/ecapture tls -m pcap -i ens160 -w a.pcapng host 1.1.1.1 or src port 443 [sudo] password for cfc4n: tls_2024/02/25 07:23:27 ECAPTURE :: ecapture Version : linux_aarch64:0.7.3-20240222-f50b9de:[CORE] tls_2024/02/25 07:23:27 ECAPTURE :: Pid Info : 884394 tls_2024/02/25 07:23:27 ECAPTURE :: Kernel Info : 5.15.131 tls_2024/02/25 07:23:27 EBPFProbeOPENSSL module initialization tls_2024/02/25 07:23:27 ECAPTURE :: Module.Run() tls_2024/02/25 07:23:27 EBPFProbeOPENSSL: Pcapng MODEL tls_2024/02/25 07:23:27 EBPFProbeOPENSSL OpenSSL/BoringSSL version not found from shared library file, used default version:linux_default_3_0 tls_2024/02/25 07:23:27 EBPFProbeOPENSSL HOOK type: 2, binrayPath: /usr/lib/aarch64-linux-gnu/libssl.so.3 tls_2024/02/25 07:23:27 EBPFProbeOPENSSL PcapFilter: host 1.1.1.1 or src port 443 tls_2024/02/25 07:23:27 EBPFProbeOPENSSL Ifname: ens160, Ifindex: 2 tls_2024/02/25 07:23:27 EBPFProbeOPENSSL Hook masterKey function: [SSL_get_wbio SSL_in_before SSL_do_handshake] tls_2024/02/25 07:23:27 EBPFProbeOPENSSL target all process. tls_2024/02/25 07:23:27 EBPFProbeOPENSSL target all users. tls_2024/02/25 07:23:27 EBPFProbeOPENSSL: BPF bytecode filename:user/bytecode/openssl_3_0_0_kern.o tls_2024/02/25 07:23:27 EBPFProbeOPENSSL saving pcapng file: /home/cfc4n/project/ecapture/a.pcapng tls_2024/02/25 07:23:27 EBPFProbeOPENSSL: perfEventReader created. mapSize:4 MB tls_2024/02/25 07:23:27 EBPFProbeOPENSSL: perfEventReader created. mapSize:4 MB tls_2024/02/25 07:23:27 EBPFProbeOPENSSL module started successfully. tls_2024/02/25 07:23:27 ECAPTURE :: start 1 modules eCapture 指令图解很多同学对ecapture的使用方式不了解，eCapture的module模块、mode模式两个功能点经常混淆，运行出错后，文档不看，help命令也不看。遇到问题后，直接到公众号问我，弄得我很头大。这次也按照思维导图的方式，简单画个图解，以便更直观地熟悉eCapture。注在个别Android的发行版上，pcap filter过滤语法可能没有效果，未来会修复。技术原理本功能由Leon Hwang大神贡献，感谢他春节期间的付出。详情见：feat: Support pcap-filter expression for pcap mode #478 libpcap 编译 pcap filter 表达式的过滤内容为cbpf字节码 cbpf字节码转为ebpf字节码 ebpf字节码插入到eCapture的TC HOOK字节码中由内核加载全部eBPF字节码，实现表达式过滤依赖 elibpcap cbpfc ebpfmanager v0.4.5 (eBPF bytecode InstructionPatchers) 下载 eCapture v0.7.4 下载地址

2024-02-29 0 0

eCapture v0.7.3新版性能提升10倍，支持OpenSSL 3.2

eCapture v0.7.3新版性能提升10倍，支持OpenSSL 3.2

eCapture是什么 eCapture旁观者一个无需CA证书，无侵入的HTTPS/TLS明文抓包工具。可以在Linux 4.18以上版本使用，同时也支持Android arm64 5.5以上版本。年底打脸记得8月份时，在GitHub万星项目进度70%，eCapture旁观者7K Stars达成一文中吹牛说到，年底冲1万颗星，奈何平时工作特别忙，根本没时间堆新功能，年底一看，果然打脸了，只有7.8K星，不过，笔者也一直忙里偷闲地回复社区的问题，不停地修复程序bug。增加难度这不，有几个小朋友给我提出了新的挑战，在生产环境，上万QPS的7层负载均衡，启用eCapture，会有什么样的结果？性能扛得住吗？性能提升10倍有用户在社区反馈eCapture性能问题TLS 模式下，对被检测程序的性能影响，执行一千万次SSL_write写数据的场景，不开启eCapture耗时6秒，而开启eCapture后却要30秒，性能耗时增大5倍以上。这个数字就很尴尬，就在你潇洒的这两天，笔者全身心投入，用爱发电，翻阅OpenSSL源码，终于有了很大的进展。进步大源于起点底笔者分析了OpenSSL类库中，以Server和Client两种模式，分别选择合适的HOOK函数，减少SSL_write和SSL_read两个函数高频调用下的触发机制，最终把耗时从30秒降低到7秒。整体来看，进步特别大。但原来确实有偷懒，直接用了SSL_write函数。继续宠粉又有小朋友在社区提了issue：The SSL structure in openssl 3.2.0 has been modified，里面提到OpenSSL 3.2.0已发布了，而且核心ssl_st结构体发生很大变化，eCaptuer捕获TLS通讯密钥的功能无法使用。笔者确认了一下，OpenSSL 3.2.0是2023年11月底发布的，至今不过2个月时间，应该还没有多少大型应用使用，不过，笔者就是喜欢宠粉，立马给安排了。谁让这位小朋友的issue写得漂亮呢。新版下载无CA捕获TLS明文软件eCapture v0.7.3版发布，性能提升10倍，千万次调用增加2秒，支持openssl 3.2。 Warning 以下为技术原理，可以不用看。技术实现性能优化设计思路问题为了读取到TLS握手完成后的client_random等密钥，必需要选择一个合适的HOOK函数。 SSL_write\SSL_read时，TLS握手是建立完成的，但调用过于频繁，会带来性能问题，参见 #463 综合来看，合适的HOOK函数需要满足以下几个条件: 函数是在TLS握手完成后调用函数名在动态链接库的符号表中是导出状态函数是低频调用解决思路在 openssl 类库中，以客户端角色调用 SSL_connect 或者以服务端角色 SSL_accept ，最终都会进入 ssl/statem/statem.c 的 state_machine 函数进行TLS握手。所以，可选范围是在这个函数内以大写SSL开头的函数。当使用openssl的方式为同步调用时，TLS握手成功会返回1，也就是ret = 1，即需要在这个变量赋值后，被调用的函数，才能拿到符合要求的内存数据。 state_machine函数内符合要求的就只有SSL_get_wbio了。当使用openssl的方式为异步 (BIO)调用时，还需要增加SSL_in_before函数。 masterKeyHookFuncs = []string{ "SSL_get_wbio", // openssl client mode //"SSL_is_init", // boringssl client mode // 备用HOOK 函数 //"SSL_is_init_finished", "SSL_in_before", //openssl client mode "SSL_do_handshake", // openssl server mode } OpenSSL 3.2.0 无它，翻阅OpenSSL源码，分析差异，重新实现密钥提取代码，详情见 PR 472 。不过，新版里新增了对QUIC TLS的支持，eCapture暂时没支持，预计春节后安排。 // TODO 检查 ssl->type, 参考 ssl/ssl_local.h的 SSL_CONNECTION_FROM_SSL_int 宏 int type; if (type == SSL_TYPE_QUIC_CONNECTION) { // Reget the address of the ssl->tls as the address of the SSL_CONNECTION debug_bpf_printk("unsupported type: SSL_CONNECTION, coming soon.\n"); return 0; } 届时，eCapture就可以无需CA证书，即可捕获QUIC TLS的明文内容了，敬请期待。红包封面预告去年封面即将春节，送给大家一些手绘的红包封面，依旧由去年红包封面《烤火兔》的设计大师，外甥女S负责。今年封面本次春节红包封面《龙"码"精神》，依旧没有任何广告、品牌标识。仿版画风格，材质感更重。立寒冬，暖阳待雪，龙码精神！这款红包风格采用木质版画风格，五行之中黑色对应水，遇水则发～黑龙俯卧在金灿灿的摇钱树给大家送福啦！

2024-01-30

1 0

GitHub 7K星：eCapture新版支持Android 13、14

GitHub 7K星：eCapture新版支持Android 13、14

eCapture是一个无需CA证书，即可捕获HTTPS/TLS明文的抓包工具，常用语网络分析、故障定位等。最初定位是Linux上的抓包工具，在2022年9月支持了Android系统，在Android 12起，只要是Linux内核是5.5以上的ARM架构，都可以正常运行。支持TLS 1.2、TLS1.3版本的协议，只需要root，无需应用重启、更改等，很受大家欢迎。今天，eCapture v0.6.5 版本发布，支持了两个功能：支持所有端口的网络包、支持Android 13和Android 14。新版本近两年，Android也陆续发布了13、14版本，eCapture做了一些兼容更新，支持了Android 13、Android 14版本的BoringSSL类库的明文捕获。除此之外，去掉了捕获端口的限制，如果--port参数为0时，可以捕获所有端口的网络数据，并保存到pcapng中。否则则只捕获--port对应的端口数据，默认是443 端口。下载使用 eCapture v0.6.5 下载地址见GitHub仓库：https://github.com/gojue/ecapture/releases/tag/v0.6.5 使用方法，可参见以往教程eCapture旁观者：Android HTTPS明文抓包功能回顾 BoringSSL介绍自支持Android至今，已经有一年多，其程序使用的默认SSL动态链接库是BoringSSL，fork自OpenSSL。这个类库广泛使用在Google的的各种产品里，包括Chrome、Android等。但他们不是同一个版本，完全是独立维护的两个Git仓库。情况如下： Android上的BoringSSL： BoringSSL Android仓库非Android的BoringSSL：BoringSSL Github仓库更让人无法理解的是，即使在Android不同发行版里，不管BoringSSL代码如何更新，都不更类库的新版本信息，都是OpenSSL 1.1.1 (compatible; BoringSSL)， OPENSSL_VERSION_NUMBER是269488255。对使用者来说没影响，可对 eCapture来说就很头疼。SSL结构体的元素offset发生变化，很难根据版本号选择不同的offset值了。相对来说，OpenSSL就做得很好，只需要从动态链接库的ELF文件中读取openssl的版本号，再选择对应offset配置即可。在Android 14里，BoringSSL的很多结构体改动较大，必需要用单独的eBPF 字节码文件，笔者花了整个周六的时间，想出一个机智地、取巧地思路，给兼容了。捕获端口限制早期，eCapture的pcapng模式是限制了网络捕获包的端口，--port参数只能是80 、443 。技术上都已经实现，没有难点。默认没有捕获所有网络包，是因为有很多场景，主机的网络流量很大，eBPF的map写入太快，用户空间消费过慢，导致丢包的问题。虽然用户空间在创建eBPF map时，已经申请了BufferSizeOfEbpfMap大的内存，但仍然还存在网络包过多导致数据丢失的可能。而且，在Android上有内存大小限制，BufferSizeOfEbpfMap的值仅为1024，即PageSize*1024，一般情况下是4M。 rd, err := perf.NewReader(em, os.Getpagesize()*BufferSizeOfEbpfMap) 也就是说，如果你启用所有端口的网络捕获，则可能会发生网络包未成功捕获的情况。除此之外，你可以用eCapture来替换tcpdump使用，而且还多了HTTPS的明文捕获呢。相关文章如果你刚刚知道eCapture，对他的功能还不了解，你可以阅读本公众号的更多文章来了解。 eCapture旁观者支持Golang tls/https加密明文捕获 eCapture支持borgingssl TLS 1.3明文捕获 eCapture：无需CA证书抓https网络明文通讯招聘信息美团信息安全部长期招人，网络安全领域的研发方向，研发产品包括不限于HIDS/HIPS、RASP、EDR、WAF、零信任产品、NIDS等等，方向包括客户端软件、服务端后台，技术语言包括不限于C/C++、Golang、Java、Object-C、Swift等。欢迎公众包内发私信联系，其他方向的岗位笔者也可协助内推到对应岗位部门。

2023-11-14

1 0

eCapture支持流量转发的进展同步

eCapture支持流量转发的进展同步

大家好，eCapture项目距上次新版发布也已经过去2-3个月了，在这期间，社区论坛里很多网友提了一些问题以及需求，等我来解决。这几个月博主工作特别忙，一直没时间更新eCapture。这个周末特地抽时间解决了社区中反应的一些bug、优化点等。至于新功能，主要的就是流量转发功能，这个功能还是比较复杂的。今天，博主先把发布一个修复bug的版本，等过段时间博主不是那么忙了，再构思流量转发功能，分享给大家。新版发布功能介绍增加了Linux 5.2一下内核的异常提示移除了curl/wget等参数路径指定恢复了关联数据包目标IP功能。修复了Openssl FD总是为0的错误。其中，第二条可能会有影响，移除curl\wget路径参数，也顺带移除了自动搜索这两个软件所使用的Openssl动态链接库版本，以及所属路径问题。意味着大家需要自己检查期望被捕获的程序所用的SSL类库版本，并手动使用--libssl参数指定。下载下载地址：eCapture v0.6.2 流量转发流量转发功能有很多使用场景，包括测试、渗透、研发、运维等，国内外都有用户提到过这个需求。流量转发功能，必不可少的数据就是IP五元组，而这个问题，是eCapture最头疼的问题，拿不到远程地址的IP、端口数据。 eCapture实现介绍基于TC的流量包获取，使用Uprob eBPF来完成捕获捕获。借助于wireshark的pcapng模式，进行解析展示。基于uprobe hook，eBPF程序挂钩到libssl动态链接库文件中，针对 SSL_write 、SSL_read函数进行Hook，读取其参数、返回值。 uprobe hook也就是函数的调用hook，意味着只有这个函数触发时，才能执行eBPF的程序。并且是没法调用外部的SSL的外部函数的。 int SSL_write(SSL *s, const void *buf, int num) { // eBPF uprobe return ret; // eBPF uretprobe } int SSL_read(SSL *s, void *buf, int num) { // eBPF uprobe return ret; // eBPF uretprobe } 比如，eBPF uprobe代码是插入到SSL_write函数的入口点，可以读取SSL *s、const void *buf、int num这三个参数。也就是说，这里并没有关于这个数据包所属IP、port等信息的参数。要想拿到IP等信息，必需从这三个参数里读取。 eCapture的数据包关联IP实现 eCapture的实现，是根据SSL *s 的内存地址，再根据结构体中的偏移地址进行二次定位、三次定位等，查找最终的目标数值。但是，但是来了，SSL *s对应ssl_st结构体，里面并不存储IP\addr等信息。现在的实现是读取SSL *s里的rbio\wbio结构体，他们里面有个num字段，也就是FD信息。再hook connect函数， int __connect (int fd, __CONST_SOCKADDR_ARG addr, socklen_t len) 读取FD，以及addr信息存储到 eBPF manp里。 eCapture再根据进程PID、fd来关联addr信息。这样的实现有个缺点，就是__connect函数一般都在libpthread.so里，意味着除了hook libssl.so，还需要再多hook一个动态链接库，而且在部分Linux发行版或者Android中，还不确定会被放到哪个链接库下。缺陷在SSL_read时，是可以正常工作的。但在SSL_write时，fd可能读到0，是因为SSL_write函数它可能是一个异步的BIO实现。这就导致发送的包拿不到目标IP信息。未来做数据包转发时，目标代理软件就无法解析、无法关联到一个TCP会话中。难点只好另寻其他办法。但从libssl.so这一个文件来看，不管是Read还是Write函数，第一个参数是SSL *结构体，最好能从这个结构体中找到存储了远程IP端口的信息。但我读了很久的Openssl类库源码，也没找到哪里存了这个数据。取舍如果说，Hook一个函数的方式实现不了，只能回到前面的hook两个函数的方向上了。但区别是说，仍要保持只hook openssl这一个动态链接库，否则兼容成本太大。目前有一些思路，比如SSL_set_fd函数等。 int SSL_set_fd(SSL *s, int fd) int SSL_set_wfd(SSL *s, int fd) int SSL_set_rfd(SSL *s, int fd) 需要确认的是，每个TCP链接，都必须要在绑定FD时，调用一次SSL_Set_fd，或者SSL_set_wfd、SSL_set_rfd等函数，而这个是无法单从openssl的代码能确定的，而是取决于使用openssl类库的程序，可控性就很差。耐心等待是的，又到了你看不见工作量的需求上了，又需要博主拼命肝功能了，等我好消息。

2023-09-25

3 0

最新评论

jeffrey

支持抓取emqx的tls报文么？

w3b5h3ll

不抛弃，不放弃

Zz

可以认为是代理功能吗？最近也在调研这个功能。大鹅项目好像是有类似的逻辑，dns配置 fallback 默认走代理。《ht

CFC4N

参考： https://github.com/gojue/ecapture/discussions/308

Wayne

你好，安卓上想使用eCapture,需要linux内额版本>=5.5 ,目前手上设备只有pixel 5 ,看官方的