写这篇文章的时候，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^[1]

• 官网: https://ecapture.cc^[2]

参考资料

[1] 

https://github.com/gojue/ecapture: https://github.com/gojue/ecapture

致读者：当应用层的 Hook 工具（如 Xposed）在日益激烈的对抗中逐渐显露疲态，你是否渴望掌握一种更底层、更隐蔽的“上帝视角”？本文将带你深入 Android 的血管——Binder 机制，从内核边缘截获一切通信流量（包括设备指纹、DRM、甚至一切系统服务）。我们将以 android_id 为猎物，演示如何从 Java 层一路追踪到 Native 层，最终在 ioctl 处完成“致命一击”。

一、 前言：潜入深海

Android 的四大组件、系统服务、框架层，无一不依赖 Binder 进行通信。对于逆向工程师和安全研究员来说，Binder 就像是 Android 系统的“中枢神经”。

15年前，Android Binder 设计与实现^[1] 一文奠定了 Binder 的理论基础。实战中我们更关心：数据到底长什么样？在哪里拦截最致命？如何修改数据欺骗系统？

本文将抛开枯燥的概念，直接上“手术刀”，通过源码调试的方式，解剖 Binder 通信过程。我们将以移动安全中最敏感的 android_id 采集为例，演示如何实现底层级的流量拦截与篡改。

二、 军火库：环境准备

工欲善其事，必先利其器。为了深入骨髓地调试，我们需要一套能看到源码、能下断点的环境。

• 宿主机: Ubuntu 22.04 (推荐 Linux，编译调试一条龙)

• 源码: AOSP Android 13 (sdk_phone_x86_64-userdebug)

• IDE: ASfP (Android Studio for Platform) - 官方为 AOSP 打造的神器

• 调试目标: 模拟器 (Emulator)

2.1 编译与启动

# 编译源码
source build/envsetup.sh
lunch sdk_phone_x86_64-userdebug
m
# 启动模拟器
emulator

2.2 挂载调试器

使用 ASfP 导入 Framework 源码，通过 Run -> Attach Android Debugger To Process，你可以像调试普通 App 一样调试 system_server。

Hacker Tip: 如果发现无法调试某些进程，修改 Zygote.java 中的 applyDebuggerSystemProperty，强制开启全局调试：args.mRuntimeFlags |= Zygote.DEBUG_ENABLE_JDWP;

三、 侦察：追踪 android_id 的获取路径

常见的 android_id 获取代码：

Settings.Secure.getString(getContentResolver(), Settings.Secure.ANDROID_ID);

这行简单的代码背后，是一场跨进程的接力赛。

3.1 战术地图：Binder 通信全景

在深入代码前，先看一张全景图，理解数据是如何从 App 流向 System Server 的。

3.2 源码层面的蛛丝马迹

关键代码路径：

1. Client 端: mRemote.transact(IContentProvider.CALL_TRANSACTION, data, reply, 0);

2. Server 端: onTransact(code, data, reply, flags)

调试实录： 我们在 ContentProviderProxy.java 的 call 下断点。当 App 请求 android_id 时，app进程会被断下。此时，Parcel data 中已经包含了当前的请求数据（包名、方法名 GET_secure、参数 android_id）。

我们在 ContentProviderNative.java 的 onTransact 下断点。请求 android_id 后，系统服务进程会被断下。Parcel reply 中将包含返回给客户端的响应数据（android_id 的真实值）

四、 潜入深海：Native 层的 Binder 机制

Java 层的 transact 只是冰山一角，真正的黑魔法发生在 Native 层。

4.1 从 Java 到 C++ 的穿越

调用链如下： BinderProxy.transact (Java) -> android_util_Binder.cpp (JNI) -> BpBinder::transact (C++) -> IPCThreadState::transact。

最终，一切汇聚于 IPCThreadState。这是 Binder 通信在用户空间的“网关”。

4.2 核心协议：BINDER_WRITE_READ

在 IPCThreadState::talkWithDriver 中，数据被封装成 binder_write_read 结构体，并通过 ioctl 系统调用发送给内核驱动。

对于binder"请求数据"的结构如下：

对于binder"回复数据"的结构如下：

关键命令解析：

• BC_TRANSACTION: Client -> Kernel。我要发送请求！

• BR_TRANSACTION: Kernel -> Server。Server，你有新请求！

• BC_REPLY: Server -> Kernel。这是我的处理结果！

• BR_REPLY: Kernel -> Client。Client，这是你的返回值！

4.3 数据包解剖

我们在 IPCThreadState::writeTransactionData 处下断点，查看内存中的 binder_transaction_data。

Hex Dump 分析 (请求 android_id):

54 53 59 53 ... (TSYS - 标识)
61 00 6e 00 ... (android.content.IContentProvider - Interface Token)
...
73 00 65 00 ... (settings - Authority)
47 00 45 00 ... (GET_secure - Method)
61 00 6e 00 ... (android_id - Arg)

这正是我们在 Java 层看到的 Parcel 序列化后的样子！

五、 终极武器：Binder 拦截实战

既然所有 Binder 通信都要经过 ioctl，那么这里就是最佳的伏击地点。

5.1 拦截策略

我们不需要修改系统源码，只需在目标进程中 Hook ioctl 函数。

5.2 代码实现 (核心片段)

使用 Dobby 或其他 Hook 框架挂钩 ioctl：

// 1. Hook 入口
intmy_ioctl(int fd, unsignedlong request, void *arg){
// 只关心 Binder 通信
if (request != BINDER_WRITE_READ) return original_ioctl(fd, request, arg);
structbinder_write_read* bwr = (structbinder_write_read*)arg;
// 2. 拦截请求 (BC_TRANSACTION)
bool target_found = intercept_write(bwr); // 解析 write_buffer，寻找 "android_id" 字符串
// 3. 执行系统调用
int result = original_ioctl(fd, request, arg);
// 4. 篡改响应 (BR_REPLY)
if (target_found) {
        intercept_read(bwr); // 解析 read_buffer，定位 value 并修改
    }
return result;
}

5.3 数据解析与篡改

解析 Binder 数据就像剥洋葱。你需要手动实现一个简易的 Parcel 解析器：

1. 读取 Header: 验证 BUNDLE_MAGIC。

2. 遍历 Map: android_id 的结果通常封装在 Bundle 中。

3. 定位 Key-Value: 找到 Key 为 value 的字段。

4. 覆盖内存: 将真实的 ID (e.g., 91da8...) 替换为你想要的假 ID。

注意: 修改数据时要非常小心内存对齐和长度问题，否则会导致 App Crash。

六、 攻防对抗：上帝视角

Binder 拦截技术在移动安全对抗中处于什么地位？

6.1 防守方视角 (Blue Team)

• 设备指纹增强: 传统的指纹获取，很容易通过xposed 等hook绕过。如果在 Binder 层做校验，对比 Java 层 API 返回值和底层 Binder 数据是否一致，可以有效识别“应用层改机”。

• 全流量监控: 理论上可以监控 App 的所有行为（点击、网络请求、传感器），用于构建高精度的风控模型。

• 痛点: 性能损耗大，兼容性噩梦（不同厂商、不同 Android 版本 Parcel 结构可能不同）。

6.2 攻击方视角 (Red Team)

• 降维打击: 内核级改机（KernelPatch+ ioctl hook）对应用层是透明的，App 很难感知自己被“楚门的世界”包围了。

• 无痕爬虫: 内核层无痕改机，配合 eCapture 等 eBPF 工具，有效拦截应用数据

• 非 Root 改机: 利用应用漏洞注入 SO，在进程内部 Hook libc.so 的 ioctl，无需 Root 权限即可实现针对该 App 的改机。

6.3 攻防对抗全景推演

为了更直观地理解不同层级攻击手段的检测难度与防御策略的有效性，我们整理了如下的攻防对抗推演图：

七、 总结

Binder 是 Android 的灵魂。掌握了 Binder 拦截，就等于掌握了 Android 数据的咽喉。

本文从源码出发，展示了 android_id 在 Binder 驱动中的流转过程，并给出了 Hook ioctl 的实战思路。对于安全人员来说，这不仅仅是一次技术练习，更是理解 Android 信任体系脆弱性的一扇窗口。

参考文献

1. Android Binder 设计与实现 - 设计篇^[2]

2. Gityuan Binder 系列文章

3. AOSP 源码 (Android 13)

八、工作机会

公司部门介绍

美团信息安全部，城市可选北京、上海。 公众号留言，即可直接投递简历。

岗位名称

反爬蓝军对抗专家

岗位职责

1. 参与日常红蓝对抗演练活动，分析防守方薄弱点，以攻促防。

2. 研究反爬领域的对抗技术，从攻防视角设计方案，持续提高反爬水位。

3. 参与体系化对抗系统建设、自动化武器设计与对内部赋能。

4. 业界爬虫前沿对抗思路研究、探索、设计、落地。

岗位基本要求

1. 本科及以上学历，网络安全，计算机相关专业，熟悉android、iOS开发和调试。

2. 精通爬虫客户端对抗思路，包括不限于APP、浏览器、小程序等多客户端，了解客户端的指纹实现，会话认证机制，点击触摸模拟、人机识别（图形、语音）。

3. 精通反爬系统风控策略，从协议、行为模拟、真人化、好人化等多角度识别定位绕过防御系统。

4. 熟悉Android Hook原理，熟悉常见Xposed、LSPosed、Magisk、Frida等HOOK工具。

5. 掌握常见的动态静态分析技巧，熟练使用IDA、Ghidra、Jeb和Jadx等常用工具对程序进行分析。

6. 熟悉iOS客户端对抗知识，掌握软件静态分析、动态调试、协议抓包、HOOK技术原理、HOOK框架应用。

其他岗位

Java资深研发、模型算法等，可公众号留言。😝

参考资料

[1] 

Android Binder 设计与实现: https://blog.csdn.net/universus/article/details/6211589

目标样本： 某 iOS APP
对抗难度： ⭐⭐
关键技术： Frida检测 | 系统调用Hook | 字符串混淆破解

🗺️ 技术路径导航

本文展示了一个完整的iOS应用反调试绕过流程，从应用层到系统调用层的深入分析：

📍 分析路径
├─ 0x00 砸壳 (工具切换策略)
├─ 0x01 常规检测绕过 (C函数Hook) 
├─ 0x02 深入系统调用层 (SVC指令分析) ⭐ 核心技术点
├─ 0x03 弹窗拦路虎 (UI层绕过)
├─ 0x04 隐藏的彩蛋 (字符串混淆解密)
└─ 0x05 总结与思考 (攻防技术栈对比)

🔄 整体攻防流程图

0x00 砸壳

拿到样本第一件事当然是砸壳，老规矩掏出frida-ios-dump^[1]，结果……APP 直接给我来了个闪退暴击。

症状：

• 不执行 Frida：APP 正常启动 ✅ （弹窗提示越狱）

• 执行 Frida：闪退 ❌

果然，有Frida反调试检测。但没关系，咱还有Plan B。换用appdecrypt^[2]项目，基于调试器原理的静态砸壳工具，成功拿到脱壳二进制文件 🎉

于是我们就可以基于frida检测绕过做一次简单的分析。

0x01 常规检测绕过

首先通过一些常规检测手法作为锚点，定位一些反调试检测的代码片段，前面不执行frida时候，会弹窗提示越狱。所以把样本扔进 IDA ，将常规的越狱特征字符串一顿搜索，果然发现了一些代码：

🏗️ 检测层级架构

应用采用了多层次的检测策略，从上层C库函数到底层系统调用：

💡 分层防御策略：当C库函数被Hook后，syscall层仍可继续检测

发现的检测点

代码片段里大量使用access()和stat()函数检测这些路径：

/Applications/Cydia.app
/Applications/Sileo.app
/Applications/blackra1n.app
/Library/MobileSubstrate/MobileSubstrate.dylib
/usr/sbin/sshd
/bin/bash
/private/var/tmp/cydia.log
...

初步绕过尝试

写了个 Frida 脚本 Hook 这些文件操作函数，打印其参数，设置白名单过滤正常路径，关键代码如下：

functioniswhite(path) {
if (path == null) returntrue;
if (path.startsWith('/var/mobile/Containers')) returntrue;
if (path.startsWith('/System')) returntrue;
if (path.startsWith('/usr')) returntrue;
// ... 更多白名单规则
returnfalse;
}
Interceptor.attach(Module.findExportByName(null, "stat"), {
onEnter: function(args) {
if (args[0].isNull()) return;
var path = args[0].readUtf8String();
if (iswhite(path)) return;
console.log("stat " + path);
this.replace = 1;  // 标记需要替换返回值
    },
onLeave: function(retval) {
if(this.replace) {
            retval.replace(-1);  // 返回文件不存在
        }
    }
});
// 同样 Hook access、lstat 等函数...

运行效果

成功拦截到大量文件操作函数的调用：

stat /Applications/Cydia.app
stat /Applications/Sileo.app
stat /Library/MobileSubstrate/MobileSubstrate.dylib
stat /bin/bash
lstat /Applications
...

但是！APP 依然闪退 😅

分析： 显然对方不只是用高层 C 库函数，肯定还有更底层的检测手段。

0x02 深入系统调用层

🔍 SVC指令分析流程

定位SVC指令

由于app用了一些上层的文件操作函数进行特征检测，怀疑其也会使用系统调用的方式进行检测，那就从汇编层面入手。写了个 IDAPython 脚本扫描所有SVC指令（ARM64 的系统调用指令）：

import ida_bytes, ida_ida, ida_segment
import idaapi, idautils, idc
defgetAddrRange():
# 限定在 __text 段
for seg in idautils.Segments():
        seg = idaapi.getseg(seg)
        segName = ida_segment.get_segm_name(seg)
if"text"in segName:
return seg.start_ea, seg.size()
start, size = getAddrRange()
for addr in idautils.Heads(start, start+size):
    mnem = idc.print_insn_mnem(addr)
if mnem == "SVC":
        print(hex(addr), idc.GetDisasm(addr))

扫描结果

发现了100+ 处SVC 指令！继续输出它们的系统调用号（从X16寄存器获取）：

addr_list = [0x10009a330, 0x10009a500, 0x10009a534, ...]  # 100+ 地址
for i in addr_list:
    print(hex(i-8), idc.GetDisasm(i-4))  # 查看 MOV X16, #xxx 指令

解析系统调用类型

看到了这些系统调用号：

• 0x21→access()调用

• 0x159→statfs64()调用

• 0xC6→ptrace()调用

• ...

具体调用关系可以转成10进制后查看，apple提供了相关文档。📚 参考文档：Apple XNU syscalls.master^[3]

逐个Hook验证

对每个 SVC 地址进行 Hook，打印它们的入参：

// 💡 关键技术点：
// • base.add() - 计算实际内存地址（基址+偏移）
// • this.context.x0 - 获取第一个参数（通常为路径字符串指针）
// • readCString() - 读取C风格字符串
// • 通过修改返回值或参数值使检测失败
...
Interceptor.attach(base.add(0x1648acc), {
onEnter: function (args) {
console.log("syscall access 0x1648acc", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x16495a0), {
onEnter: function (args) {
console.log("syscall access 0x16495a0", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x1649b80), {
onEnter: function (args) {
console.log("syscall access 0x1649b80", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x164a33c), {
onEnter: function (args) {
console.log("syscall access 0x164a33c", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x164adb4), {
onEnter: function (args) {
console.log("syscall access 0x164adb4", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x164b314), {
onEnter: function (args) {
console.log("syscall access 0x164b314", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x164c090), {
onEnter: function (args) {
console.log("syscall access 0x164c090", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x164db20), {
onEnter: function (args) {
console.log("syscall access 0x164db20", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x164e400), {
onEnter: function (args) {
console.log("syscall access 0x164e400", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x24081c0), {
onEnter: function (args) {
console.log("syscall access 0x24081c0", this.context.x0.readCString());
    }
})
Interceptor.attach(base.add(0x2408c2c), {
onEnter: function (args) {
console.log("syscall access 0x2408c2c", this.context.x0.readCString());
    }
})
....

🎯 致命发现

在地址0x15f5328和0x2408c2c的 syscall 调用中，捕获到了这个入参：

/usr/sbin/frida-server

真相大白！原来是在 syscall 层直接检测 frida-server 进程路径。所以我们直接这个地址进行hook，传入一个虚假的path后，再次打开应用，应用不在闪退，证明成功饶过。

0x03 弹窗拦路虎

虽然不闪退了，但 APP 弹出"检测到越狱环境"的提示框，依然无法进入主界面。这说明还有其他的越狱检测点我没有绕过，但是由于应用不点击确认不会闪退，因此我们可以不去分析其他越狱特征，仅尝试饶过这个弹窗限制

Hook UIAlertView

var UIAlertView = ObjC.classes.UIAlertView['- show'];
Interceptor.attach(UIAlertView.implementation, {
onEnter: function(args) {
console.log('UIAlertView triggered!');
console.log(Thread.backtrace(this.context, Backtracer.ACCURATE)
            .map(DebugSymbol.fromAddress).join('\n'));
    }
});

追溯调用栈

通过堆栈回溯，定位到弹窗触发的业务逻辑函数：

代码逻辑很清晰，就是一个越狱状态判断 → 弹窗的流程。我们patch掉这个弹窗，成功在执行Frida的同时进入APP！

0x04 隐藏的彩蛋

在分析过程中发现一个困惑的点：在 IDA 的字符串列表里搜索frida-server，什么都没找到！但是在上面syscall 调用中却有这个入参。

定位检测地址，查看参数：

入参伪代码如下 ，原来是个简单的 XOR 混淆：

if ((byte_103C6B5BB[0] & 1) != 0) {
for (i = 0; i != 23; ++i)
        byte_104528523[i] = byte_103C6B5BB[i + 1] ^ (i + 100);
    byte_103C6B5BB[0] = '4';
}

解密逻辑

encrypted = [0x66, 0x72, 0x69, 0x64, 0x61, ...]  # 从二进制中提取
decrypted = ""
for i in range(23):
    decrypted += chr(encrypted[i] ^ (i + 100))
print(decrypted)  # 输出：/usr/sbin/frida-server

🔐 XOR混淆可视化流程

原始加密数据 (byte数组):
┌─────┬─────┬─────┬─────┬─────┬─────────┐
│ 0x66│ 0x72│ 0x69│ 0x64│ 0x61│   ...   │
└──┬──┴──┬──┴──┬──┴──┬──┴──┬──┴─────────┘
   │ XOR │ XOR │ XOR │ XOR │
   │  ↓  │  ↓  │  ↓  │  ↓  │  ↓
   │ 100 │ 101 │ 102 │ 103 │ 104  (密钥: i+100)
   └──┬──┴──┬──┴──┬──┴──┬──┴──┬──
      ↓     ↓     ↓     ↓     ↓
'/''u''s''r''/'   ... 
解密结果: /usr/sbin/frida-server

设计目的： 避免静态分析时被字符串搜索直接定位。

0x05 总结与思考

攻防技术栈对比

🛡️ 防护手段	⚔️ 绕过方案	🎯 难度
Apple Store应用加密	appdecrypt[4] 砸壳	⭐
文件操作函数检测越狱等基础风险特征	Hook C函数返回假值	⭐⭐
系统调用检测Frida特征	Hook SVC指令地址	⭐⭐⭐
越狱检测弹窗	Hook弹窗代码逻辑，绕过即可	⭐⭐
静态分析字符串加密	分析解密函数/动态调试	⭐⭐

防御者视角建议

1. 多层检测叠加： 仅靠单一层次的检测容易被针对性绕过

2. 关键逻辑加固： syscall 层检测应配合代码混淆、完整性校验

3. 行为分析为主： 静态特征检测终将被绕过，转向运行时行为监控

攻击者视角经验

1. 工具链冗余： Frida 被杀？试试其他调试工具！

2. 分层Hook策略： 从上到下逐层下探（ObjC → C → syscall → 内联汇编）

3. 动态调试优先： 字符串混淆、控制流混淆等静态难题，动态调试一览无余

4. 耐心是美德： 现代 APP 保护往往是10+ 种对抗手段的组合，慢慢攻克

0x06 后续研究方向 🔬

• 进一步分析其他反调试检测逻辑

• 研究其网络层是否有额外的设备指纹检测

免责声明： 本文仅供安全研究和技术交流，请勿用于非法用途。

0x07 工作机会

公司部门介绍

美团信息安全部，城市可选北京、上海。 公众号留言，即可直接投递简历。

岗位名称

反爬蓝军对抗专家

岗位职责

1. 参与日常红蓝对抗演练活动，分析防守方薄弱点，以攻促防。

2. 研究反爬领域的对抗技术，从攻防视角设计方案，持续提高反爬水位。

3. 参与体系化对抗系统建设、自动化武器设计与对内部赋能。

4. 业界爬虫前沿对抗思路研究、探索、设计、落地。

岗位基本要求

1. 本科及以上学历，网络安全，计算机相关专业，熟悉android、iOS开发和调试。

2. 精通爬虫客户端对抗思路，包括不限于APP、浏览器、小程序等多客户端，了解客户端的指纹实现，会话认证机制，点击触摸模拟、人机识别（图形、语音）。

3. 精通反爬系统风控策略，从协议、行为模拟、真人化、好人化等多角度识别定位绕过防御系统。

4. 熟悉Android Hook原理，熟悉常见Xposed、LSPosed、Magisk、Frida等HOOK工具。

5. 掌握常见的动态静态分析技巧，熟练使用IDA、Ghidra、Jeb和Jadx等常用工具对程序进行分析。

6. 熟悉iOS客户端对抗知识，掌握软件静态分析、动态调试、协议抓包、HOOK技术原理、HOOK框架应用。

参考资料

[1] 

frida-ios-dump: https://github.com/AloneMonkey/frida-ios-dump

eCapture旁观者^[1]是一个无需CA证书，无侵入的HTTPS/TLS明文抓包工具。可以在Linux 4.18以上版本使用，同时也支持Android arm64 5.5以上版本。在Github上共获取15000颗星。

eCaptue开源项目在eBPF官网https://ebpf.io/applications/^[2] 的新兴起项目中，排名第一。

今年以来，博主忙于工作，一直无暇开源社区，趁这个周末，加足马力，解决了一大批bug，增加了很多特性。eCapture 迎来了 v1.5^[3] 版本。这次更新不仅修复了多个关键 BUG，更带来了两个重量级的新特性：事件转发 API 和 远程配置更新 API。

与此同时，作为 eCapture 的官方可视化伴侣，eCaptureQ 也同步发布了 v0.3.0 版本，为用户提供了更强大的数据筛选能力。

🚀 新特性亮点

1. 远程配置更新 API：不重启，动态调整抓包策略

在以往的版本中，如果想修改抓包的过滤条件（比如更换目标进程或端口），必须停止并重启 eCapture。在生产环境中，这可能会导致瞬时的抓包中断。

eCapture v1.5^[4] 引入了 HTTP 远程配置更新 API。eCapture 启动后，默认会监听 http://127.0.0.1:28256。你可以通过发送 HTTP POST 请求，实时修改运行中的模块配置。

使用场景：

• 动态排查：发现异常流量后，通过脚本瞬间开启 Debug 模式或 Hex 导出。

• 精准定位：随时更新 target_process，只捕获特定应用的流量，减少干扰。

实战示例：动态修改 TLS 模块配置

假设你需要监控 nginx 和 curl 进程，同时排除 ecapture 自身：

bash

curl -v \
  -H "Content-Type: application/json" \
  -X POST \
  --data '{
    "pid": 0,
    "uid": 0,
    "debug": false,
    "filters": {
      "target_process": ["nginx", "curl"],
      "ignore_process": ["ecapture"]
    }
  }' \
  http://127.0.0.1:28256/tls

如果返回 {"code": 0, "msg": "RespOK", ...}，说明配置已即时生效。目前该 API 支持 Linux 平台下的 /tls, /gotls, /bash, /mysqld 等多个模块（Android 平台支持 TLS 相关模块）。

2. 事件转发 API：对接 Burp Suite 与大数据平台

v1.5.0 增强了事件输出能力，提供了基于 WebSocket + Protobuf 的 事件转发 API。

通过参数 --ecaptureq，eCapture 可以作为一个 WebSocket Server，将捕获到的明文数据、密钥日志（Keylog）以及程序运行日志，以结构化的 Protobuf 格式实时推送给客户端。

核心价值：

• 联动 Burp Suite：你可以开发一个简单的中间件，作为 WebSocket 客户端接收 eCapture 的流量，并将其转发给 Burp Suite 等抓包软件进行重放和深度分析。

• 集中化日志分析：在分布式部署场景下，可以将多台服务器的抓包数据统一汇总到 ELK 或其他安全分析平台。

启动方式：

# 开启 WebSocket 服务，监听 28257 端口
sudo ecapture tls --ecaptureq=ws://127.0.0.1:28257/

3. 🖥️ eCaptureQ v0.3.0：可视化与 SQL 过滤

作为事件转发 API 的最直接应用案例，eCapture 的官方可视化界面 eCaptureQ 也同步更新到了 v0.3.0。它完美展示了如何利用 WebSocket 接口构建一个现代化的抓包分析工具。

v0.3.0 变更日志 (Changelog)：

• 现在的你，可以使用类似 SQL 的语法在海量抓包数据中快速筛选出感兴趣的请求，分析效率倍增。

• ✨ 新特性 (Feat)

• 支持自定义 SQL 语法过滤数据包流 (add custom SQL filtering support for packet stream)。

• 🧹 优化 (Chore): 引入 Prettier 并规范化代码库 (add Prettier and format codebase)。

如果你想体验 eCapture 的可视化魅力，或者寻找二次开发的参考范例，eCaptureQ 是不二之选。

4. 兼容性升级：Android 16 与 OpenSSL 3.5

紧跟技术前沿，v1.5.0 增加了对最新环境的支持：

• Android 16：适配了 BoringSSL 在 Android 16 上的新特性（如结构体偏移变化）。

• OpenSSL 3.5：增加了对 OpenSSL 3.5.x 系列的 Hook 支持。

🛠️ 问题修复 (Bug Fixes)

为了提升稳定性，我们在 v1.5.0 中修复了以下关键问题：

• Kernel 4.19 兼容性修复：修复了在 Linux Kernel 4.19 版本上，由于 eBPF bytecode 中 .rodata map 处理方式差异导致的加载失败问题。现在旧内核用户也能顺畅运行了。

• 时间戳精度提升：修复了捕获事件的时间戳精度问题，现在可以精确到纳秒级，对于高并发场景下的流量时序分析更加准确。

📥 下载与升级

官方下载

你可以前往 GitHub Releases 页面下载最新版本的二进制文件： eCapture v1.5.1 下载（Github源）^[5]

国内加速下载 🚀

为了方便国内用户，我们提供了专属的下载站点，速度更快：  eCapture v1.5.1 下载（国内高速CDN）^[6]

结语

eCapture v1.5 标志着它从一个单纯的“命令行工具”向“可编程、可集成的 eBPF 抓包平台”迈进。无论是远程动态调优，还是通过 eCaptureQ 进行可视化分析，亦或是将数据输送给 Burp Suite，都为高级玩家提供了无限可能。

欢迎大家下载体验，如果有任何问题或二次开发的需求，欢迎在 GitHub Issue 中反馈！

工作机会

公司部门介绍

美团信息安全部，城市可选北京、上海。 公众号留言，即可直接投递简历。

岗位职责

1. 参与日常红蓝对抗演练活动，分析防守方薄弱点，以攻促防。

2. 研究反爬领域的对抗技术，从攻防视角设计方案，持续提高反爬水位。

3. 参与体系化对抗系统建设、自动化武器设计与对内部赋能。

4. 业界爬虫前沿对抗思路研究、探索、设计、落地。

岗位基本要求

1. 本科及以上学历，网络安全，计算机相关专业，熟悉android、iOS开发和调试。

2. 精通爬虫客户端对抗思路，包括不限于APP、浏览器、小程序等多客户端，了解客户端的指纹实现，会话认证机制，点击触摸模拟、人机识别（图形、语音）。

3. 精通反爬系统风控策略，从协议、行为模拟、真人化、好人化等多角度识别定位绕过防御系统。

4. 熟悉Android Hook原理，熟悉常见Xposed、LSPosed、Magisk、Frida等HOOK工具。

5. 掌握常见的动态静态分析技巧，熟练使用IDA、Ghidra、Jeb和Jadx等常用工具对程序进行分析。

6. 熟悉iOS客户端对抗知识，掌握软件静态分析、动态调试、协议抓包、HOOK技术原理、HOOK框架应用。

参考资料

[1] 

eCapture旁观者: https://ecapture.cc/

网络防火墙的“痛”与“痒”

大家好啊！ 咱们搞IT和安全的，谁没跟网络防火墙打过交道？但现在的攻击，真的让传统防火墙“压力山大”。

你想象过吗，网络攻击会给全球造成多大危害？根据Cybercrime Magazine的统计，到2025年，这个数字是10.5万亿美元 。这比一年内自然灾害的损失总和还多，甚至比全球所有主要非法毒品贸易的利润都高 。

为什么这么难防？我们认为可以简单的总结为2个关键痛点 ：

1. 识别发现难 ：现在的攻击早就不是针对单协议或者单漏洞的显式利用了 。它们玩的是利用端到端（End-to-End）复杂协议交互过程中出现的语义缺陷，进行跨协议渗透突破 。攻击呈现出跨域跨层、步骤多、隐匿性等特征 。你靠静态的特征匹配和对比检测方法（比如传统的IDS/IPS）难以识别，必须得有语义层面长上下文的推理和关联分析 。

2. 拦截阻断难 ：就算你（费了九牛二虎之力）识别出了一个隐蔽攻击，怎么拦？安全管理人员得去理解和提取攻击的关键步骤和特征，然后编写出准确的安全策略或规则 ，再将规则部署下发到合适的网络位置 。这一套流程下来，黄花菜都凉了。这个过程亟需自动化来实现 。

为了针对上述问题，PacketScope项目来了 。

今天我们为大家继续介绍PacketScope项目的Guarder功能 ，即一个大模型赋能的网络攻击栈内智能识别与防御方案 。它把大模型赋能的协议交互长上下文推理能力 与基于eBPF的内核级协议栈可编程能力 ，丝滑结合联动在一起 ，实现了隐蔽网络攻击的智能识别及栈内自动阻断 。

Guarder：一个“会思考”的内核防火墙

简单来说，你可以把Guarder理解成一个嵌在内核前端、由AI驱动的网络边界防火墙。

咱们熟悉的Snort/Suricata、nftables，甚至原始的XDP，核心都是基于规则（比如TCP五元组）进行识别和阻断。Guarder也干这个活儿，但它的杀手锏是：AI自适应规则生成。

Guarder的实现依赖于两项关键技术的结合：Linux内核的eBPF/XDP技术和外部的大语言模型（LLM）分析能力 。这套机制形成了一个从感知到决策再到执行的完整闭环 。

其工作流程可以分解为几个步骤 ：

• 感知 (eBPF/XDP)：Guarder利用eBPF程序直接挂载在网卡的XDP（eXpress Data Path）钩子上 。这是Linux内核中处理网络数据包的最早位置 ，实现了“零拷贝”的高效数据包捕获 ，几乎不会对系统本身造成性能负担 。此时，它会收集TCP/UDP连接的元数据、ICMP流量特征等信息 。

• 上报 (BPF Maps)：这些在内核态收集到的原始数据，通过BPF Maps这一高效的内核-用户空间通信桥梁 ，被安全地传递到运行在用户空间的Guarder主程序 。

• 决策 (LLM)：用户空间的AI分析模块开始工作 。它会整理、汇总这些实时流量数据 ，并根据预设的分析目标（例如“寻找异常出站连接”），将这些信息结构化后，通过API提交给一个大语言模型LLM 。

• 技术选型：这里很灵活，Guarder支持使用ChatGPT、DeepSeek、TrafficLLM等云端模型 ，也支持连接到本地部署的vLLM或Ollama等模型，以满足不同场景下的数据隐私和成本需求 。

• 规则自动生成：大语言模型在接收到数据和分析指令后，会利用其强大的模式识别和推理能力，对流量行为进行研判 。如果判断出存在恶意攻击，它会根据威胁的特征，自动生成一条或多条用于阻断该行为的eBPF过滤规则

• 执行 (XDP)：这些由AI生成的防御规则会被Guarder程序接收，并立即下发、更新到内核的XDP钩子上 。由于规则直接在内核网络路径的最前端生效，恶意的网络流量在消耗任何系统资源之前就被直接丢弃 ，从而实现了高效且及时的拦截 。

安装及演示

PacketScope 1.1 版本已在Ubuntu 24.04 （Linux内核环境 6.8）中完成了相关模块的测试部署 。Guarder模块经测试分析已经可以实现对常见典型攻击威胁的智能识别和栈内实时阻断 。

划重点！！！ PacketScope现在已经支持全系统的Docker环境部署和安装，轻松无忧、便捷用户一键安装和使用 。此外，我们在VPS上部署了安装好的PacketScope，供用户点击试玩，直接点击PacketScope Guarder^[1] 即可访问，欢迎大家体验试玩！

视频 1：安装教程 

图题：PacketScope全系统从0开始Docker环境安装部署完整视频

视频 2：演示教程 

图题：Guarder模块的演示教程

🛡️ 实战演练：防御ICMP Ping Flooding攻击

下面，我们以现实中最常见的ICMP Ping Flooding洪泛攻击为例，直观展示PacketScope的Guarder模块如何自动的识别和防御网络攻击的 ：

1. 攻击发生

首先，假设有一个远程攻击者向部署了PacketScope的服务器洪泛发送大量的ICMP Ping报文 ，企图消耗目标服务器的带宽资源 ：

2. AI分析启动

管理员在PacketScope的Guarder页面中，过滤器管理选项卡下，点击“AI智能生成”，对服务器的流量进行在线的实时分析 ：

3. 智能识别与报告

Guarder大模型会读取服务器的流量摘要，对服务器流量进行自动的分析识别，成功锁定和识别出刚才攻击者发送的ICMP攻击报文 ，输出安全分析报告 ：

4. 规则自动生成

Guarder大模型自动生成相应的eBPF过滤器规则 ：

5. 规则一键下发

管理员点击“应用选中规则(1)”，实时下发到服务器内核协议栈 ：

6. 攻击拦截成功

规则下发后，可以看到攻击者发送的ICMP报文会被PacketScope丢弃 ，无法继续实施攻击  (显示 100% packet loss)：

未来展望

PacketScope项目逐步揭开了端侧协议栈复杂交互的“黑盒” ，推动终端安全从隔离检测向内部认知与智能化防御演进 。作为其中的关键模块，Guarder尝试将大模型的分析决策能力与eBPF的高效内核执行机制结合 ，把复杂网络攻击的识别与实时阻断下沉至协议栈内部 ，从而引领主机安全迈向新阶段 。

未来，PacketScope项目将继续扩展相关功能模块 ，包括：

• 实现应用级协议的分析追踪

• 构建跨主机协同分析能力实现管理域内多主机内核协议栈的分布式追踪

• 开放更为灵活的编程接口便于专业人员自定义函数观测点及监控参数等

下一篇推送我们将继续通过攻防实例，展示如何利用PacketScope的交互图分析能力，检测隐蔽的TCP DoS攻击，敬请关注！

加入我们

我们期待与安全社区和互联网研究者一起携手交流，共同打造面向未来的协议栈安全基石。

P.S. 大家在安装或使用的过程中有任何问题，欢迎在Issues里面提问留言 ，作者们将在第一时间回复解答 。

• 项目介绍网站：https://internet-architecture-and-security.github.io/packetScope-website/

• 项目Github开源地址：https://github.com/Internet-Architecture-and-Security/PacketScope

欢迎感兴趣的小伙伴扫描下面的微信群二维码，加入我们的PacketScope技术和网络安全研讨社区！

参考资料

[1] 

PacketScope Guarder: http://82.156.141.213:4173/

嘿，eCapture 旁观者^[1] 的铁子们！

既然你摸到了这里，想必你也是 eCapture 这款“黑科技”的忠实粉丝了。能在 GitHub 上豪取 1.5万+ Star，成为网络抓包领域的明星项目，靠的就是它那不讲道理的硬核实力：不用装证书，不用搞中间人代理，直接在内核里把 TLS 明文给你安排得明明白白。这种感觉，就像开了“上帝视角”，爽！

eCapture 作为一款 CLI 工具，强大、纯粹，是极客的浪漫。但说实在的，浪漫归浪漫，当真正在炮火连天的生产环境或复杂的调试场景里干活时，我们都或多或少地被这“朴素”的命令行界面给“伤害”过。

CLI 的“甜蜜”烦恼：眼花缭乱，手忙脚乱

你是不是也对这些场景感同身受？

1. “信息瀑布”糊脸

   sudo ecapture tls 命令一敲，你的终端就变成了“信息瀑布”现场，日志刷得比瀑布还快。想在流量高峰期用肉眼找到某个特定的请求？祝你好运！这哪是抓包，这简直是考验眼速的极限挑战。

2. 玩“大家来找茬”游戏

   一个请求（Request）发出去，它的响应（Response）在哪儿呢？它可能在上面，也可能在下面，还可能被一堆其他日志夹在中间。你只能瞪大眼睛，在滚动的文本里玩“大家来找茬”的游戏，费时费力还容易看错行。

3. 跟 grep 和 awk 斗智斗勇

   想过滤一下？没问题，grep、awk、sed 三件套伺候。但每次想实现一个稍微复杂点的过滤，比如“找出来自 api.example.com 并且响应码是 500 的 POST 请求”，都得先跟一长串的正则表达式和管道符斗智斗勇一番。心累啊！

4. 只见树木，不见森林

   线性的文本输出，让我们很难对全局流量有个直观的认识。当前到底有几个域名在通信？哪个接口访问最频繁？哪些请求慢得像蜗牛？光看日志，一头雾水。

eCapture 已经帮我们搞定了从内核捞数据这个最硬核的活儿。但怎么把这些原始数据舒舒服服地看明白，一直是个“历史遗留问题”。

现在，是时候终结这一切了！隆重介绍 eCaptureQ！

在此，特别鸣谢Hugo^[2]同学， 他是eCaptureQ项目的主要推动者、设计者，感谢他为这个项目的贡献。

eCaptureQ：鸟枪换炮，体验起飞！

eCaptureQ^[3] 不是要取代 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 引擎配上它应得的酷炫驾驶舱吧！

下载地址

界面程序支持macOS、Windows、Linux等PC桌面系统，支持x86_64和aarch64两种CPU架构。

官方仓库：https://github.com/gojue/ecaptureQ/releases

参考资料

[1] 

eCapture 旁观者: https://github.com/gojue/ecapture

今天我给大家推荐一个基于eBPF的新项目：  PacketScope^[1] 项目。

公众号原文：PacketScope之协议交互“透视镜”

PacketScope是一种基于eBPF的TCP/IP协议栈通用防御框架。通过在协议栈处理路径上动态观测、实时感知每一个分组单元在系统内的处理轨迹，绘制协议交互全景图，再辅助以大模型分析，PacketScope实现了协议栈内核级别的分组可视化、安全性分析与零延迟防御。 

项目介绍：https://mp.weixin.qq.com/s/89P7rG9XeB_MYG8IxRa9Rw 

项目地址：https://github.com/Internet-Architecture-and-Security/PacketScope

项目中有四个大的模块，笔者比较感兴趣的是 Tracer模块，即网络协议交互的“透视镜”。

原文介绍

Tracer协议交互“透视镜”能够将底层协议栈中复杂的交互过程和信息、细粒度的直观呈现给用户，辅助用户理解网络分组在协议栈中经历的每一步处理及整个生命周期，同时洞察不同协议之间的调用链路与上下文依赖，及早发现潜在的性能故障点、异常行为和跨层风险。

一、协议交互：互联网通信的隐形脉络

在现代互联网架构中，TCP/IP 协议栈是端到端（End-to-End）数据可靠通信的核心载体。在一次看似简单的数据传输过程中（例如用户通过手机端的浏览器访问远程 web 服务器上的某个网站），往往要发生复杂的协议交互才能顺利完成数据的可靠传输。

什么是网络协议交互？

图1 端到端数据传输过程中的协议交互

• 我们可以用一个简化的例子来说明什么是协议交互。如下情景：当用户在浏览器地址栏输入一个网站地址并回车后，背后会发生一连串复杂的协议交互。

• 首先是域名解析（DNS over UDP/IP）。浏览器需要知道目标网站对应的 IP 地址，于是向本地 DNS 服务器发起一个基于 UDP 的 DNS 请求，随后通过 IP 层封装并传递。DNS 服务器返回结果，客户端获得目标服务器的 IP 地址；

• 然后是建立连接（TCP 三次握手 over IP）。有了目标 IP 后，客户端向服务器发起 TCP 连接：客户端发送带 SYN 标志的分组，服务器返回 SYN-ACK，客户端再回 ACK 确认，连接正式建立；

• 接着是数据传输（HTTP over TCP/IP）。浏览器通过已建立的 TCP 连接发送 HTTP 请求（如 GET /index.html），服务器将网页内容分片封装在 TCP 分组中返回。TCP 保证数据可靠、有序到达。

• ICMP、ARP、DHCP、Wi-Fi、5G、VPN、TLS 等协议在幕后参与。在这一过程中，还有诸多其他协议参与交互，完成错处处理、数据加密、秘钥分配、地址分配、数据帧封装等，最终协同实现 HTTP 消息从远端服务器顺利到达客户端。

结论：网络协议交互是指在计算机网络中，不同层级或不同类型的通信协议在完成某一特定网络任务时，通过消息交换、状态更新与语义依赖所形成的协作过程。单一协议通常只定义自身的消息格式与处理规则，而一次完整的网络通信往往需要多个协议共同参与。网络协议交互的本质是：各协议在分层架构下通过数据与控制信息的交换，形成一条跨层次、跨协议的因果链，从而共同实现端到端通信的目标。

透视网络协议交互的价值

• 协议交互的本质：各协议在分层架构下通过数据与控制信息的交换，形成一条跨层次、跨协议的因果链，从而共同实现端到端通信的目标。

• 图2 网络协议交互的透视分析

• 上述例子表明，即使一个“点开网页”的小动作，其背后也有 DNS、UDP、IP、TCP、HTTP、ICMP 等多种协议的复杂交互与协作。对协议交互的这一复杂过程进行全景透视与分析具有重要意义。

• 避免“黑箱”效应：每一个分组的生成、传递与响应，都是不同协议之间的交互。对用户来说，这一切都是“黑箱操作”；而对网络管理员而言，如果只依赖传统抓包或日志，往往只能看到零散的分组，难以理解背后的因果关系、进而还原出协议之间交互的完整因果链条。透视交互能将“黑箱”过程显性化，帮助管理员和用户从全局把握通信逻辑。

• 快速定位故障与性能瓶颈：网络传输异常时，问题可能出在不同协议的交互上，例如：路径 MTU 发现依赖的 ICMP 消息缺失会导致 TCP 长时间重传；DNS 解析延迟会拖慢整个 HTTP 请求。通过透视交互，可以准确定位是哪个协议、哪个环节出现异常，从而缩短排障时间。

• 识别潜在安全风险：越来越多的攻击利用协议交互中的“模糊和灰色地带”，例如伪造 ICMP 消息干扰 TCP 会话，或者通过跨协议的语义差异进行流量劫持。透视交互能帮助管理员发现这些异常路径与跨层耦合，及时阻断潜在威胁。

• 辅助网络优化与决策：在网络运维和系统优化中，理解协议交互可以为配置调整、策略部署提供数据支持。例如在 CDN、云环境中，通过透视交互可识别不同路径的效率差异，从而指导更优的路由或缓存策略。

二、基于 eBPF 的协议交互全景可视化

PacketScope 的 Tracer 功能利用 eBPF 技术，为用户提供前所未有的协议交互全景可视化能力。eBPF 允许在内核中安全、高效地插入探针，对网络协议栈中活跃的套接字和数据包进行实时监控，而无需修改操作系统内核或协议栈代码。通过这一机制，PacketScope 能够捕获数据包在内核协议栈中的完整处理路径，记录每一步的处理动作、状态变更及上下文依赖关系，就像一面“透视镜”，能够将底层协议栈中每一次分组的流动、每一个协议的调用、每一条跨层依赖关系，清晰、细粒度地呈现出来。

• 图3 基于 eBPF 的协议交互追踪与交互图绘制

• 网络接口数据包捕获：模块在网络接口上挂载 eBPF 探针，以捕获进入和离开网卡的数据信息，确保对数据包从链路层到网络层的入/出流动进行精确监控，为后续跨层追踪提供基础数据。

• 关键内核函数插桩：系统性筛选内核中与网络处理高度相关的函数集合，记录每次函数调用与返回的线程 ID 及时间戳，为构建函数调用链打下基础。

• 数据包与函数调用事件关联：定义起点函数，如 "icmp_push_reply", "rawv6_sendmsg" 等。Tracer 在起点函数调用与返回时，记录网络四元组、线程 ID 与时间戳，并追踪从起点函数调用到返回过程中所经过的所有函数。通过线程 ID 与调用连续性确认函数链的完整性，最终将函数调用链信息与数据包信息绑定，实现包级别的精细化函数调用分析。

• 跨层交互与性能量化：Tracer 梳理数据包在协议栈中的完整收发路径，在链路层、网络层和传输层识别关键函数作为插桩点。量化指标包括：

• 层流量：数据包流经该层插桩点的次数，反映该层的处理工作量；

• 跨层交互频率：数据包在各层关键函数之间交互的频率，衡量协议栈的跨层耦合程度；

• 跨层延迟：数据包在各层关键函数之间流转的处理时间，反映协议栈处理效率及潜在性能瓶颈。

通过上述设计，PacketScope 的 Tracer 模块不仅实现了对协议交互的可视化和精确追踪，还提供了性能与行为量化指标，为网络故障诊断、性能优化以及安全风险分析提供了基础依据。

三、PacketScope 及 Tracer 的安装及使用

网络安装教程

使用教程

四、关键流程与界面要点（简要概览）

结合图例，对协议交互分析过程中的关键步骤和功能简要说明如下：

Socket监控

当点击主界面左上角“开始监控”按钮后，系统将开始读取内核中的套接字列表，从而获取当前系统内所有活跃的网络连接信息。这些连接将根据五元组（源 IP 地址、源端口、目的 IP 地址、目的端口和协议类型）以及当前的协议状态（如 TCP 的 ESTABLISHED、LISTEN 等）进行分类和组织，并统一呈现在“总体套接字列表”中。

网络包查看

选中单个 Socket 进行监控（例如正在使用 TCP 通信的流），可以查看三个主要功能：

• 包分析器

• 函数调用链监控

• 协议栈监控

包分析器

提供类似于 tcpdump 的功能，可以获取该 socket 上经过的数据包，并给出基本数据包信息，例如时间戳、网口号、包方向和包长度等。

函数调用链监控器：

展示数据包在内核处理过程中经过的各个函数及其调用关系，用户可逐级展开调用链，追踪数据包在内核中的完整处理流程，并可看到跨层的调用关系与延迟分布，辅助定位网络性能瓶颈和潜在安全漏洞。

从下图可以看到，该TCP流进行收包时，会涉及到网络层的ip_rcv_core、ip_local_deliver等函数、涉及到传输层的tcp_v4_rcv、tcp_filter等函数）

除此之外，还提供了函数调用路径的可视化视图，即函数粒度级的网络协议交互图，通过可视化工具，将图形化的函数调用链路完整展示在用户面前。用户可以通过颜色深浅直观发现路径中的性能瓶颈，该函数执行耗时越多颜色越深，该函数调用次数越多连线越粗，起到瓶颈及风险函数高效定位的作用，为代码性能优化及攻击风险识别提供帮助，例如在一些网络侧信道攻击中，攻击者可能会频繁探测目标服务器状态，导致某些协议函数被反复调用执行，产生异常。下面两张图展示了选定一个TCP流的协议交互图，上图为完整协议交互图，下图为按照时延过滤后、仅保留高延迟函数节点的部分协议交互图。

协议栈监控：

对跨层交互性能进行实时监控，覆盖四个关键指标：分组数据流动数量、跨层延迟、跨层交互频率以及丢包率。该监控可帮助精准定位网络性能瓶颈，为资源分配与优化提供依据。例如，跨层延迟指标有助于识别协议栈中的耗时瓶颈层、分组数据流动数量与丢包率指标有助于定位通信故障点。

五、未来展望

PacketScope项目逐渐打开了端侧协议栈复杂交互的“黑盒”，推动终端安全从外部防御隔离向内部认知安全演进。

未来，PacketScope项目将继续扩展相关功能模块，比如实现应用级协议的分析追踪、构建跨主机协同分析能力实现管理域内多主机内核协议栈的分布式追踪、开放更为灵活的编程接口便于专业人员自定义函数观测点及监控参数等。

大家在安装或使用的过程中有任何问题，可以到原公众号文章 下留言，也可以在GitHub社区的Issues里面提问留言，作者们将在第一时间回复解答！

参考资料

[1] 

PacketScope: https://github.com/Internet-Architecture-and-Security/PacketScope

项目概述

AgentCPM-GUI^[1]是一款由清华大学THUNLP实验室与面壁智能联合开发的开源端侧智能体大模型，基于MiniCPM-V构建，总参数量为8B。该模型能够接收手机屏幕图像作为输入，并根据用户指令自动完成相应任务。这是一个专为中文环境优化的GUI智能体，能够操控安卓应用程序完成各种复杂交互任务。

核心特性

1. 高质量GUI基础能力：通过在大规模中英文Android数据集上预训练，模型对常见GUI控件（如按钮、输入框、标签、图标等）具备出色的定位与理解能力，为精确操作奠定基础。

2. 中文APP应用适配：作为首个针对中文APP精细优化的开源GUI Agent，模型支持高德地图、大众点评、哔哩哔哩、小红书等30余个主流中文应用，解决了中文界面交互的特殊挑战。

3. 增强的规划推理能力：通过强化微调技术（RFT），使模型在输出动作前进行详细的推理思考，显著提升复杂任务执行的成功率，使操作更加智能化。

4. 紧凑的动作空间设计：采用优化的动作空间和紧凑的JSON格式，平均动作长度仅9.7个token，大幅提升端侧推理效率，降低了资源消耗。

技术架构

AgentCPM-GUI建立在MiniCPM-V模型基础上，通过监督微调（SFT）和强化学习微调（RFT）两个阶段训练而成：

1. 监督微调（SFT）：使用包含屏幕截图和相应操作的大规模标注数据集，训练模型理解界面元素并生成正确的操作行为。

2. 强化微调（RFT）：通过自我探索和反馈机制，优化模型的思考能力和决策策略，提高复杂场景下的任务完成率。

3. 动作设计：采用JSON结构化输出，支持多种操作类型：

• POINT：点击屏幕指定位置

• to：从当前位置滑动（上、下、左、右或特定坐标）

• TYPE：输入文本

• PRESS：特殊按键操作（HOME、BACK、ENTER）

• 支持思考（thought）过程输出，增强可解释性

性能评估

AgentCPM-GUI在多个基准测试中表现卓越：

1. GUI元素识别（Grounding）：

• fun2point：79.1%（领先）

• text2point：76.5%（领先）

• bbox2text：58.2%（领先）

• 平均：71.3%（远超第二名44.3%）

2. 任务执行（Agent）：

• 在Android Control、GUI-Odyssey、AITZ等英文测试集上取得领先成绩

• 在中文APP测试集上表现尤为突出（TM 96.86%，EM 91.28%）

• 显著超越Qwen2.5-VL、UI-TARS等主流模型以及GPT-4o、Gemini 2.0等闭源大模型

MobileUse手机控制

功能描述

使用触摸屏与移动设备互动，并截取屏幕截图。

• 这是一个与带有触摸屏的移动设备交互的界面。您可以执行点击、输入、滑动等操作。

• 某些应用程序可能需要时间启动或处理操作，因此您可能需要等待并连续截取屏幕截图才能看到操作结果。

• 屏幕分辨率为 {self.display_width_px}x{self.display_height_px}。

• 请确保使用光标尖端点击按钮、链接、图标等元素的中心。除非另有要求，否则不要点击框的边缘。

工具列表描述

要执行的动作。可用的动作如下：

要执行的动作。可用的动作如下：

• key

  ：在移动设备上执行按键事件。

• 这支持 adb 的 

  keyevent

   语法。

• 示例："volume_up"（音量增大）、"volume_down"（音量减小）、"power"（电源键）、"camera"（相机键）、"clear"（清除键）。

• click

  ：点击屏幕上坐标为 (x, y) 的点。

• long_press

  ：按住屏幕上坐标为 (x, y) 的点指定秒数。

• swipe

  ：从起始点坐标 (x, y) 滑动到终点坐标 (x2, y2)。

• type

  ：在激活的输入框中输入指定的文本。

• system_button

  ：按下系统按键。

• open

  ：在设备上打开应用。

• wait

  ：等待指定的秒数以使更改发生。

• terminate

  ：终止当前任务并报告其完成状态。

应用场景

1. 智能手机自动化：替代传统脚本，通过自然语言指令完成日常操作任务

2. 无障碍辅助：帮助行动不便用户操控手机应用

3. 应用测试与QA：自动执行应用测试流程，发现潜在问题

4. 智能助手集成：为现有智能助手提供视觉交互能力

5. 教育引导：辅助新用户学习复杂应用的使用方法

部署与使用

模型支持多种部署方式：

1. Hugging Face推理：直接加载模型进行推理，支持本地GPU加速

2. vLLM服务部署：通过vLLM部署高性能推理服务，适合多用户场景

3. 自定义训练：开源了SFT和RFT训练代码，可根据特定需求进行调整和优化

未来展望

作为端侧GUI智能体的前沿实践，AgentCPM-GUI开启了多模态AI与手机交互的新范式，未来有望在以下方向持续发展：

1. 扩展到更多应用场景和平台（如iOS、桌面系统）

2. 增强跨应用任务规划和执行能力

3. 降低模型参数量，提升端侧部署效率

4. 增强个性化适应能力，根据用户习惯调整交互方式

看到这里，想必一些搞黑产、灰产的同学肯定早有动作了，那么作为防御方的你，又开始头疼了吗？

参考资料

[1] 

AgentCPM-GUI: https://github.com/OpenBMB/AgentCPM-GUI

大厂招聘：Java研发、逆向破解、图像识别

美团信息安全部招人，主管直招，没有中间商赚差价。多个职位，多个名额，北上可选，虚席以待。

优先条件

了解AI，掌握Prompt、RAG知识库、MCP、A2A、Multi Agent等智能体相关知识优先。

办公地点

1. 上海-杨浦-互联宝地

2. 北京-朝阳-望京东路

JAVA高级研发工程师

岗位职责

1. 主导并参与公司数据安全、反爬风控等业务的大型web后台系统

2. 深度掌握系统现状，识别在可用性、性能等方面存在的风险并优雅解决

3. 负责数据库扫描、敏感数据扫描与防护功能的架构设计、编码实现及性能调优。

4. 负责业务线需求支撑，按期高质量完成业务需求的研发工作，保障产品能力的持续演进

5. 主动发掘业务痛点，协同上下游团队，推动痛点解决，提升服务水位

6. 负责技术难点调研和攻关，解决系统中关键的设计、技术、流程优化等问题

7. 结合自身业务特点，推动新技术的探索、设计、落地

岗位要求

1. 一年以上Java开发经验，熟练掌握Spring、Spring Boot、MyBatis等主流技术框架。

2. 熟练掌握服务化系统架构，对服务治理、Zookeeper、Thrift、分布式事务有了解

3. 熟悉MySQL、Redis等数据库技术，掌握事务隔离级别、索引原理及性能调优方法。

4. 熟悉日志审计技术，了解ELK栈（Elasticsearch、Logstash、Kibana）日志分析工具、Hive等大数据处理工具，具备相关项目经验。

5. 熟悉TCP/IP、HTTP/HTTPS等相关网络协议

6. 掌握前端开发技术栈，包括HTML、CSS、JavaScript及Vue框架

7. 了解常见的水印、加密、脱敏、DLP等数据安全技术

8. 擅长高并发、高可用、高性能的系统架构设计，具备良好的抽象能力

9. 具备优秀的逻辑思维能力，业务敏感，有强烈的创新探索欲

10. 有责任感和主动性，面对复杂场景，可独立分析、归纳并使用创造性方案解决问题

岗位亮点

1. 参与百万级别扫描任务的调度系统开发，挑战高并发、高性能的系统设计

2. 参与高性能、高吞吐的网络请求转发系统开发，提升系统的整体性能

3. 深入参与千亿级别离线处理及百万级别实时计算的大数据业务场景，积累丰富的实战经验

反爬逆向对抗专家

岗位职责

1. 担任反爬蓝军角色，针对公司各系统进行爬取对抗

2. 负责实施基于爬虫行为的数据泄漏挖掘工作；

3. 研究反爬领域的对抗技术，能从攻防视角看问题，左右互搏，提升反爬水位；

4. 参与体系化对抗系统建设、自动化武器设计与对内部赋能；

5. 业界爬虫对抗思路研究，探索，设计，落地；

岗位要求

1. 精通爬虫客户端对抗思路，包括不限于APP、浏览器、小程序等多客户端，了解客户端的指纹实现，会话认证机制，点击触摸模拟，人机识别（图形、语音）。

2. 精通反爬系统风控策略，从协议、行为模拟、真人化、好人化等多角度识别定位绕过防御系统。

3. 有较好的资源对抗视野，了解设备指纹、IP资源、帐号资源等对抗机制。了解资源渠道、资源清洗、资源审计

4. 熟悉Web漏洞形成原理，有各大互联网SRC漏洞提交经验优先。

5. 熟悉Android Hook原理，熟悉常见Xposed、LSPosed、Magisk、Frida等HOOK工具。了解AOSP源码、Android系统架构，有Framework、ART、HAL开发经验，

6. 掌握常见的动静态分析技巧，熟练使用IDA、Ghidra、Jeb 和Jadx等常用工具对程序进行分析；

7. 熟悉iOS客户端对抗知识，掌握软件静态分析、动态调试、协议抓包、HOOK技术原理、HOOK框架应用。

图形识别算法工程师（风控反爬方向）

岗位职责

1. 负责验证码图形识别算法的研发与优化，包括但不限于字符识别、目标检测、图像分割等技术。

2. 研究并应对常见的验证码对抗技术（如扭曲、干扰线、噪声、动态背景等），提升识别准确率和鲁棒性。

3. 结合风控场景，设计反爬策略，识别和防御自动化工具（如爬虫、脚本）的攻击。

4. 跟踪业界最新图形识别与反爬技术，持续优化现有模型和算法。

5. 与风控团队协作，输出技术方案并推动落地。

6. 研发视频动态验证码的OCR识别技术，包括视频帧提取、动态文字追踪、多帧融合等。

7. 针对视频中的干扰（如模糊、抖动、动态背景）优化OCR模型，提升识别准确率。

8. 研究并应对视频验证码的对抗技术（如闪烁文字、随机位移、颜色变换等）。

9. 结合时序分析技术（如LSTM、3D-CNN）处理视频流中的文字识别问题。

10. 与团队协作，将视频OCR技术集成到风控系统中，防御自动化攻击。

任职要求

1. 学历背景：计算机科学、人工智能、图像处理等相关专业本科及以上学历。

2. 技术能力

• 熟练掌握Python/C++，熟悉OpenCV、TensorFlow/PyTorch等框架。

• 熟悉传统图像处理算法（如边缘检测、形态学处理）及深度学习模型（CNN、Transformer等）。

• 有验证码识别或对抗经验者优先（如破解或防御滑动验证码、点选验证码等）。

• 熟悉视频处理技术（如FFmpeg、视频帧提取）及OCR工具（Tesseract、PaddleOCR等）。

• 掌握时序模型（如CRNN、Transformer-based OCR）在动态文字识别中的应用。

• 有视频验证码破解或防御经验者优先（如抖音滑块、腾讯云验证码等）。

3. 领域知识

• 了解常见验证码的生成逻辑和对抗技术（如动态干扰、行为验证）。

• 熟悉爬虫与反爬机制，对风控系统有基本认知。

• 了解视频验证码的生成逻辑（如关键帧插入、时间维度干扰）。

• 熟悉视频爬虫与反爬技术（如动态Token、行为轨迹模拟）。

4. 其他

• 具备较强的逻辑分析能力和问题解决能力。

• 有视频超分辨率、去模糊等图像增强技术经验。

• 熟悉多模态融合技术（如结合语音、文本的验证码分析）。

• 具备高性能计算（如CUDA优化）或边缘部署（TensorRT）经验。

联系方式

公众号内留言，或加QQ群，群内联系。