手机无线调试：27B量化模型自主完成中间人攻击

我只做了两件事

我只做了两件事：

在手机上启用了无线调试。

将测试服务器和手机连接到同一个网络。

之后，我就只和 xAgent 沟通了。我没有登录服务器去安装任何东西，也没有自己去组装 ADB、代理或 Frida 命令。

工具确实被安装上了

xAgent 首先检查了手机型号、Android 版本、无线 ADB 端点以及配对状态，然后开始连接服务器和手机。剩下的步骤可以直接对照截图验证：

mitmproxy 11.0.2 被部署到了服务器上。

Frida 17.17.0 被准备到了服务器和手机上。

无线 ADB、反向端口转发、Android 全局代理以及服务器网络规则都已连接。

抓包日志持续写入，设备连接详情被保留供后续 Session 使用。

第一轮结束时，工具版本、部署位置、代理路径和日志位置都列得清清楚楚。这个真实案例中的界面以中文显示。

看到进程在运行、端口在监听已经很令人鼓舞了。但那只能证明命令生效了，还不能证明真实手机流量被捕获到了。

接下来的检查更重要

xAgent 继续进行，读取了实际的 mitmproxy 日志。结果很快分成了三组：

手机浏览器的主要 HTTPS 请求返回了 200 OK，可以被解密，说明浏览器或 WebView 信任了用户 CA。

浏览器使用的部分后台组件返回了 certificate unknown，说明它们没有使用相同的用户证书信任路径。

其他原生应用的 HTTPS 连接只暴露了 TLS 握手，没有暴露请求内容。

第二个结论来自 mitmproxy 日志，不是基于进程状态猜测得出的。这个真实案例中的界面以中文显示。

最终的边界很清楚。HTTP、浏览器流量以及部分 WebView 流量是可读的。不信任用户证书的原生应用只暴露了连接和 TLS 握手。超出这个范围的工作就需要针对特定应用、Root 权限或系统证书了。xAgent 还清理了上游证书处理和代理的持久化日志。

Android 很快碰到了自己的边界

手机没有 Root。自 Android 7 起，应用默认不再自动信任用户安装的 CA。一个应用是否接受用户证书，取决于它的网络安全配置、网络栈以及证书锁定等机制。

因此，证书在浏览器或部分 WebView 中生效，并不意味着所有原生应用都能被解密。xAgent 没有把这称为配置失败，也没有告诉我一切都被完全拦截了。它停在了设备当前状态下实际能做到的地方。

这一点对我很重要。安装工具是一回事。看到结果并承认边界更难。

这就是 27B INT4 能做到的程度

这次运行没有使用最大的闭源模型。它用的是 Qwen3.8-27B AWQ INT4。模型理解了任务并决定下一步尝试什么，而 xAgent 持续向它提供服务器、终端、设备连接、执行结果和之前的状态。失败的命令可能导向另一种方法，新的日志条目可能改变下一个决策，而不需要每轮都重新解释一遍。

抓包工作正常后，我问手机能否 Root。它检查了芯片组、引导程序、系统版本和地区，然后列出了可行的路径。它也标明了哪些无法远程完成：下一阶段至少需要一次物理 USB 连接，解锁可能会擦除手机并影响保修，不成功的尝试可能使手机无法使用。

当时页面显示的当前上下文为 123k / 160k tokens。在整个 Session 中，它记录了约 35.97M tokens、约 23.32M 缓存 tokens 和 612 次工具调用。这些是累计的 Session 统计数据，不是抓包这个孤立操作的代价。

这些数字并不意味着 tokens 越多就越好。它们说明这不是三轮对话就能完成的。Session 中已经包含了大量的工具输出，当前上下文已达到 123k，而模型仍在追踪同一个设备和同一个目标。

一个案例不是基准，也不能证明每个 27B 模型都会表现相同。不过在这个案例中，一个 27B 4-bit 模型没有停留在告诉我该做什么。它把工作推进到了一个我可以验证的结果。

更多案例，更少功能列表

xAgent 的核心现在已基本稳定。在此基础上，我更愿意记录它在真实环境中完成了什么、在哪里卡住了，而不是再发一篇冗长的功能列表。

这是"xAgent 实战"系列的第一篇文章。后续会遵循相同的格式：我提供了什么、xAgent 做了什么、我是如何检查结果的、以及它做不到什么。

参见 AI Agent Model Requirements 来准备模型环境，或者从 Complete Your First Task with xAgent 开始验证一个多步骤工作流。

Originally published on xAgent.