本期主题：「信任边界」

上一期讲的是”检查点”——锁装好了，它到底在检查哪一行。
这一期接着往下问一步：那条被检查的边界，本身是不是真的存在？

今天这七条材料，几乎每一条都在讲同一个问题——我们把信任放在了一个从来没有被验证过的地方。

  • 信任”未公开设置只有我自己能改”：安全研究员 Patrick Wardle 发现 Meta 的 Muse macOS 应用里有一个未公开的设置项，本地任何代码都能改写它，把它指向一个攻击者自己的服务器，于是 Muse 的云端听写就把音频送到攻击者那里去了。他拿到的 PoC 可以借 Muse 的权限拍照、往磁盘写恶意文件，而且多数情况下不弹任何提示。Meta 的说法是”这只是本地提权、不是远程漏洞”——这句话本身是对的，但它回避了另一个问题：一个 AI 助手为什么要有一个能改写自己后端地址的隐藏开关。
  • 信任”Agent 知道自己不该越界”：同一天上 Hacker News 热帖的 wrr/drop 给了一个工程解法——无 root 的 Linux 沙箱，用 user namespace 隔离，可选跑在 gVisor 用户态内核上，默认屏蔽本地端口（防止 Agent 摸到本机的其他服务），把 ~/.ssh 藏起来，.git 目录默认只读。它的设计前提很清醒：不假设 Agent 不会犯错，而是假设它一定会。
  • 信任”硬件随机数就是随机的”：一位开发者用汇编写了个测试，发现 AMD 的 rdrand/rdseed 在请求 16 位随机数时永远摇不出 0，同一份程序在 Intel 上正常。而 AMD 官方真正承认的那个缺陷方向恰好相反——Zen 5 架构的 CVE-2025-62626 里，rdseed 在 16/32 位模式下生成 0 失败时，居然把表示成功的进位标志 CF 置成了 1。密码学黑盒里最凶险的漏洞，从来不是不吐数据，而是把确定性的残次品伪装成随机数交付。
  • 信任”AI 代理会站在消费者一边”：NatWest、美国银行、ING、新西兰 ASB、Capital One、澳洲联邦银行等七家银行联合发布报告，警告 AI 代购可能增加诈骗、欺诈与隐私泄露风险。报告点出的具体风险非常工程化：智能体会向用户索要卡号并直接填进网站，也可能把用户引导到保护更弱的支付路径。而另一边，英国零售商 John Lewis 说来自 AI 智能体的搜索占比已经从一年前的 0.3% 升到 2.5%。一边是流量在真实迁移，一边是护栏还没建好。
  • 信任”改一改源码就能骗过检测”：phantom-frida 把 Frida 反检测做成了每周自动构建的流水线——约 90 个补丁覆盖 16 类检测向量，构建出的 server 与 gadget 随机命名，并且明确声明”源码测试通过或字节扫描通过，都不等于运行时隐身“。这份自我限定比它那 90 个补丁更值得学。
  • 信任”技能包会自动做对事”：MobileRE-Skill 把安卓逆向的静态分析、Frida 动态 Hook、一键脱壳、反检测、Native 逆向打包成一套给 AI Agent 用的技能系统（23 个 Frida 模块 + jadx/ghidra MCP），靠 SKILL.md 决策树自动路由。它的价值不在”能自动做”，而在”把专家经验写成了可审计的分支”。
  • 信任”公开可得就等于可以训练”：OpenAI 和 Anthropic 向澳大利亚议会提交材料，请求放宽当地”禁止用本国创意内容训练模型”的限制。Anthropic 提的是有条件批准（把训练许可和投资承诺挂钩），OpenAI 提的是平衡的版权框架。这条对做采集的人有直接含义：训练数据的合法性正在从”技术上拿得到”转向”法律上给不给”。

本期最值得带走的一句判断：审计一条边界时，不要问它”拦住了什么”，要问它”这条边界是谁定义的、能不能被改写、改写了之后谁会发现”。

一、头条：Meta Muse 零日——“未公开设置”成了劫持 AI 智能体的钥匙

时间：2026-09-22。发现者：macOS 安全研究员 Patrick Wardle（Objective-See 基金会创始人，《The Art of Mac Malware》作者）。报道：The Verge / Ars Technica。Meta 在报道发出后数小时内发布热修。

1.1 事件本体：一条三步的劫持链

先把链路按顺序摆清楚，这条链的每一步单独看都不算致命，连起来就很致命：

步骤 发生了什么 为什么这一步能成立
① 找到一个未公开设置 Muse 应用内部有一个没有写进任何文档、也没有暴露在 UI 里的设置项 这个设置项控制的是”听写（dictation）的处理后端地址”
② 改写它 本机上运行的任意代码都能改写 Muse 的全部未公开设置 设置存储没有做应用级隔离，任何同用户下的进程都可写
③ 让 Agent 自己把数据送过去 设置被指向攻击者自己的端点后，Muse 的云端听写就把音频/转写内容发到攻击者服务器 听写是在云端完成的，不是在设备本地做的

关键点在于第 ③ 步的”主动性”：攻击者不需要自己往外发数据，是 Muse 这个被用户信任的 AI 助手替他发的。

1.2 PoC 能做到什么（Wardle 自己公开的结果）

  • 通过 Muse 拍照；
  • 通过 Muse 向磁盘写入恶意文件；
  • 上述操作在多数情况下不会向用户发出提示。

Wardle 对 Ars Technica 的原话值得原样读一遍：

“We can manipulate the agent and leverage its privileges to do whatever we want. So instead of us having to write a very comprehensive Mac malware stealer, we can just leverage the AI assistant itself.”

（我们可以操控这个智能体，借它的权限做任何事。这样一来，我们不必再写一个功能全面的 macOS 窃密木马，直接利用 AI 助手就行。）

“At the very least, they should be thinking about security from the very start, and they are just not.”

（至少，他们从第一天就该把安全考虑进去，但显然没有。）

1.3 ⭐ 三方口径对照：同一件事，三种叙述

这一节是本条最值得学的地方——一个安全事件里，”谁在说什么”比”发生了什么”更能训练判断力：

立场 说法 这句话成不成立 它回避了什么
Meta（David Singleton，Meta Superintelligence Labs） “这是一次本地提权攻击，不是远程漏洞。要用它造成危害，需要恶意代码已经以用户账号在用户机器上运行，因此 Muse Mac 应用对用户的实际风险相当低。尽管如此，我们已发布热修。” 前半句在技术上是成立的——它确实需要本地代码执行权限 回避了：为什么一个 AI 助手会有能改写自己后端地址的隐藏开关？为什么这个开关任何进程都能写？
Wardle “他们从第一天就该把安全考虑进去” 成立 无（他公开了完整链路和 PoC）
The Verge 直接点出矛盾：”这与 Meta 本月早些时候发布 Muse 时对隐私与安全功能的强调形成对照” 成立 无

学到的读法：厂商回应里的”风险很低”通常是概率论证（需要先有本地代码执行），而不是设计论证（这个开关该不该存在）。这两件事要分开评估。概率低不等于设计对。

1.4 ⭐ 这件事不是孤立的：Muse 的三天

把 Muse 最近几天的公开事件排一下，能看到一条很清晰的曲线：

日期 事件 争议焦点
2026-09 上旬 Meta 发布 Muse，重点宣传隐私与安全功能 —
2026-09-20 《Inc.》特约编辑 Jason Aten 公开质疑：未授权 Muse 访问 Mac 的”信息”App，Muse 却能回答消息内容相关问题，追问后 AI 自称”是通过通知预览获取的” AI 自己给出的数据来源解释，和厂商的解释不一致
2026-09-20 Meta 高管 David Singleton 在该帖下回应：Muse 需要”完全磁盘访问权限”，这些功能均需用户主动开启；强调 Muse”并不会监视 Mac 上的通知“，只在用户明确授权后才从”信息”App 采集数据 双方对同一事实的描述存在明显差异
2026-09-21 亚马逊以使用条款为由封禁 Muse 访问其电商平台 智能体准入的规则依据迁移（上期第三节）
2026-09-22 本次零日漏洞（Wardle）+ Meta 数小时内热修 未公开设置 + 云端听写 + 无隔离的设置存储
2026-09-22 七家银行联合警告 AI 代购风险（本期第四节） 智能体进入金融风控视野

一条线索串起来：Muse 在这三天里，同时被用户（权限边界不清）、平台（条款不允许）、研究者（可利用的隐藏开关）、银行（交易风险）四个方向质疑。这基本就是”一个 AI 智能体进入生产环境后会撞到的四面墙”。

1.5 ⭐ 值得关注的原因

  1. “未公开设置”是一个被严重低估的攻击面。 我们平时审计一个客户端，习惯去看文档里写了什么开关。但真正的风险在文档里没写的那些开关——它们通常由开发者为了调试、A/B 测试、灰度切换而留下，往往不做权限校验、不做值域校验、也不记日志。审计清单里应该加一条：搜索所有”能被写入的配置键”，而不是只搜”UI 上能点的开关”。
  2. “云端处理”是一个安全决策，不只是成本决策。 Muse 的听写放在云端，直接导致”改一个地址”就等于”把数据交给别人”。如果听写在本地做，第 ③ 步就断了。 这也是上期 ZCode 事件同一个道理：数据往哪里走，取决于架构画在哪里，而不是取决于隐私政策怎么写。
  3. “借权限”正在取代”写木马”。 Wardle 那句”我们不必再写一个窃密木马”是整个 AI 安全领域 2026 年的核心叙事。当一个应用拥有完全磁盘访问权限 + 相机 + 写文件 + 网络出口，它本身就是一个功能完备的恶意软件框架——唯一的区别是它由厂商签名、由用户主动安装。对做逆向的人来说：以后分析一个 macOS/Android 客户端的攻击面，先看它拿到了哪些系统权限，再看这些权限能不能被别的进程借用。
  4. 响应速度正在成为新的竞争维度。 从 Ars 报道到热修只有几小时，这个速度是好的。但**”快修”不能替代”设计时就不该有这个开关”**。把这两件事分开评价，是读这类新闻的基本素养。
  5. 对安卓侧的迁移意义。 macOS 上的”未公开设置 + 云端处理”组合，在安卓上对应的就是：SharedPreferences / 本地配置文件里可被同用户进程改写的隐藏开关、把关键请求指向远端配置的服务端地址下发、未做签名校验的插件/模型下载地址。这三条在安卓 App 上同样常见，而且同样能被 Frida 一行代码改掉。

1.6 来源

二、Drop：把 Agent 关进笼子的工程解法（无 root + gVisor）

项目：wrr/drop（Apache-2.0，Go 编写，建仓 2025-07-25，9/21 推送活跃，约 104 ⭐）。同日登上 Hacker News 热帖（droprun.sh，2026-09-22 21:52）。

2.1 它解决的是什么问题

官方首页把使用场景写得很直白，值得逐条读：

隔离编码智能体
用 --dangerously-skip-permissions 跑 Agent，让 Drop 在操作系统层面强制权限。

  • 一次幻觉出来的 rm -rf ~ 碰不到你真正的 home 目录；
  • 一次针对 ~/.ssh 的提示词注入什么也找不到；
  • 对 localhost 上运行的服务发起的连接会被拒绝。

隔离第三方程序
从 PyPI、npm 或任何来源安装程序，不给它完整的用户账号权限。如果装的东西是恶意的、或者在供应链攻击中被污染，损害被限制在沙箱里。

这三条正好是 AI Agent 沙箱的”致命三要素”的对应解——私有数据、不可信内容、外部通信能力，只要三者同时存在，缺了隔离就是事故。

2.2 技术实现：它和 Docker 的区别在哪

维度 Drop 的做法 和 Docker/Podman 的差别
是否要 root 不需要。跑在 Linux user namespace 里，拥有自己的 process / mount / network / IPC / cgroup namespace Docker 需要 daemon（通常以 root 跑）
发行版 直接用你现有的发行版——你装过的每个程序在沙箱里都能用 Docker 需要构建镜像、装依赖
能力（capability） 执行沙箱程序之前，把所有 user namespace 的 capability 全部丢掉 容器默认保留一批 capability
网络 两种模式：off（无网络）/ isolated（默认，能上外网，但不能访问宿主上开放的本地端口） 容器默认桥接网络
可选加固 可选跑在 gVisor 用户态内核上（--runtime=gvisor），沙箱程序不再直接向宿主内核发系统调用 标准容器与宿主共享内核
home 目录 每个环境有自己的可写 home，原始 home 被隐藏；/usr /bin /sbin /lib /etc 以只读方式 bind mount 需自行配置
工作目录 默认对初始化目录读写，但 .git 子目录默认只读 无此默认
配置 一份 TOML，默认 base.toml 被所有环境共享（配一次，之后新建环境零配置） Dockerfile / compose

几个设计细节值得单独拎出来：

  • .git 默认只读——这是个非常聪明的默认值。因为 .git/hooks 是一个经典的沙箱逃逸路径（克隆一个不可信仓库，触发 hook 脚本，在沙箱外执行任意代码）。
  • 默认屏蔽 localhost 端口——Agent 想摸本机跑着的数据库、Redis、开发服务器，默认摸不到。
  • 丢掉 user namespace 内的 capability——所以沙箱内进程连 bind mount 都做不了。
  • 不暴露 ~/.ssh——官方文档里的演示就是 file /.ssh 返回 No such file or directory，而 echo "evil command" >> ~/.bashrc 返回 Read-only file system。

2.3 ⭐ 官方自己写的两条”不要误解”

这个项目最值得学的其实是它主动写出来的限定：

  1. “在遵循标准 Linux/Unix 约定的系统上，一份空的 Drop 配置就能创建安全的沙箱。配置项让沙箱更方便使用，但不会让它更安全。”
    → 这句话翻译过来是：配置只能放宽，不能收紧。默认值才是安全上限。
  2. gVisor 的代价被明确标注：”会给系统调用增加一些性能开销，并且并非 100% 兼容原生 Linux 内核（尽管兼容性问题很少见）。”
    → 没有把”更安全”说成”没有代价”。

2.4 ⭐ 值得关注的原因

  1. 它把”隔离级别”变成了一个可以按需选择的光谱，而不是”装不装 Docker”。 同一个项目里，--runtime=native（namespace 隔离，快）和 --runtime=gvisor（用户态内核，更隔离）可以在同一个环境上来回切换。这个设计对做 Agent 工程的人很实用：开发时用 native 图快，跑不可信输入时切 gvisor。
  2. 它是”Agent 该被当成不可信代码”这个判断的直接产物。 注意它的定位措辞：不是”保护 Agent 不被攻击”，而是”保护你的机器不被 Agent 伤害“。这两种措辞对应完全不同的威胁模型，而 2026 年真实发生的事故，绝大多数属于后者。
  3. 对做逆向/爬虫的人的迁移价值：如果你要批量跑不可信的样本、脚本、npm/pip 包、别人给的”一键脚本”，Drop 的模型比 Docker 更轻（不需要建镜像），比裸跑安全得多。尤其是”从 PyPI / npm 装东西”这个场景——供应链投毒时，隔离就是唯一的止损。
  4. 和本期头条形成一组对照：头条讲的是”边界被绕过了“，这一条讲的是”边界应该怎么画“。同一天出现，正好构成一组完整的教材。

2.5 来源

三、AMD 的 RDRAND 摇不出 0：当”随机”变成一个不能验证的黑盒

原始帖：flat assembler 论坛（2026-05 起，作者 Jessé，巴西），2026-09-22 重新登上 Hacker News 热帖。相关：AMD 官方安全公告 AMD-SB-7055 / CVE-2025-62626。

3.1 现象：同一份汇编程序，AMD 上没有 0

作者本来在写汇编画柱状图，用 rdrand 和 rdseed 产生随机数据。他顺手加了一根柱子统计”生成出来的 0 的个数”，然后发现：

  • 在 AMD 上（他手上是 Ryzen，怀疑是 Zen 2 级别）：统计 0 的那根柱子永远是绿的（即零个 0），跑很久都没有；
  • 在 Intel 上：0 正常出现；
  • 他做了 16 位空间的完整柱状图（65536 个值），AMD 上”0”那一格就是空的。

一个技术细节非常关键：他后来发现，如果让 rdrand/rdseed 输出 32 位或 64 位，再取低 16 位，0 就出现了。也就是说——

不是”AMD 的随机数发生器不会产生 0”，而是”当你只要 16 位时，它不会产生 0”。

他的”修复建议”也是这个：用 32/64 位寄存器取值，再截断到 16 位。

3.2 ⭐ 但官方承认的那个缺陷，方向恰好相反

这一节是本条最有价值的部分。AMD 官方真正立项并公开承认的 0 值缺陷，出现在更新的 Zen 5 架构上：

项目 内容
公告编号 AMD-SB-7055
CVE CVE-2025-62626
受影响 Zen 5 处理器，执行 16 位和 32 位的 RDSEED 指令
真正的危险 在错误地生成 0（即生成失败）时，硬件错误地把表示成功的进位标志 CF 置成了 1
后果 硬件不是摇不出 0，而是在随机生成失败时，把无效的 0 当成真随机数硬塞给操作系统
AMD 给的缓解方案 ① 软件层全面改用 64 位 RDSEED；② 在 CPUID 中屏蔽 RDSEED 特性；③ 上层软件强制把返回值 0 判定为失败并重试

⚠️ 这两件事必须分开读：论坛帖讲的是”少给了 0“（分布缺口），官方公告讲的是”多给了假的 0“（错误成功）。前者是统计异常，后者是密码学灾难。

3.3 ⭐ 一个更常见的元凶：软件把”合法的 0”当成了”失败”

帖子里的老手（revolution）提醒了一个经典陷阱，而且有真实案例：

x86 执行 RDRAND / RDSEED 时，语义是这样的：

进位标志 含义
CF = 1 熵源充足，寄存器里的值是一个合法随机数
CF = 0 熵池枯竭，生成失败，寄存器里的值完全不可信

问题在于：一个”合法的随机数”完全可能就是 0。 而不少软件层封装曾经把”寄存器值为 0”当成”生成失败”：

  • 真实案例：OpenSSL issue #5340——其封装层一度错误地把硬件指令返回的合法数值 0 当成失败信号，触发内部重试计数器把该值替换掉；
  • 连锁反应：原本符合均匀分布的随机序列，被外层软件人工过滤出了一个缺口。

所以论坛帖里那个”AMD 上永远没有 0”的现象，完全可能有一部分是软件层的锅——你没法只靠一个应用层测试就断定硬件有问题。

3.4 ⭐ 顺带一组性能数据（作者实测）

同一份程序在不同 CPU 上的吞吐差异大得离谱：

处理器 随机数生成速率 备注
Core i5（2012 年） 约 12.6 M/秒 100% 依赖时钟频率
Core i7-7700（2017 年） 约 750 K/秒 比 2012 年的还慢
AMD Ryzen 7 约 2.6 M/秒 对时钟变化完全不敏感

“对时钟不敏感”这件事本身就说明硬件实现完全不同——Intel 早期实现是”噪声源 → 采样 → 去偏 → 移位寄存器 → 128 位种子 → AES 计数器模式 CSPRNG”，而 AMD 的电路显然不是同一套版本/修订。这直接影响到”能不能靠计时去区分 CPU 型号”这类指纹问题——如果你在做设备指纹，RNG 的吞吐特征是一条少有人注意的旁路信号。

3.5 ⭐ 值得关注的原因

  1. 它示范了”硬件黑盒”应该怎么被质疑。 作者的做法很朴素但很正确：写一个能画出完整分布的测试程序，让别人在自己机器上复现。他没有停在”我觉得 AMD 有问题”，而是把测试工具、源码、结果图都放出来。这是”可复现的怀疑”，和”网上的玄学”是两回事。
  2. “少给 0”和”给假 0”是两种完全不同的 bug，但很多人会混为一谈。 前者影响统计与模拟，后者直接影响密钥生成。做安全评估时，一定要问清楚”这个缺陷是偏向性还是错误成功”。
  3. 对做指纹/风控的人的启示：熵源质量是一条可以做指纹的维度。不同厂商、不同代际的 RNG 吞吐、对时钟的敏感度、rdseed 的支持与否，都是稳定且可采集的设备特征。同时反过来——如果你的风控依赖客户端的随机性（比如生成挑战 nonce、做设备指纹盐值），要意识到客户端的随机数可能不是随机的。
  4. 对做逆向的人的启示：硬件 RNG 是无法通过软件完全验证的。老手的原话是——“那里有大量地方可以藏后门，而且不逆向硅片几乎不可能检测出来“。所以工程上的正确做法不是”信任 RDRAND”，而是”永远把硬件熵源和软件熵源混起来用”。

3.6 来源

四、多家银行联合警告 AI 代购：智能体进入风控视野

时间：2026-09-22（路透社首发，IT之家等中文媒体当日晚间跟进）。报告方：NatWest（国民西敏）、美国银行、ING、新西兰 ASB、Capital One、澳洲联邦银行等。

4.1 事件本体

项目 内容
谁发的 国民西敏银行（NatWest）、美国银行（Bank of America）、ING、新西兰 ASB 银行、美国第一资本（Capital One）、澳洲联邦银行等多家银行联合报告
警告什么 让 AI 智能体代替消费者进行网上购物，可能增加诈骗、欺诈与数据隐私泄露的风险
背景 OpenAI、Anthropic、Google、Meta 正大力把 AI 聊天机器人推向购物场景，设想由智能体挑选商品并直接代为下单
另一侧 零售商开始争相影响聊天机器人的商品推荐结果（这本身就是一个新的”投放”战场）

4.2 ⭐ 报告点出的具体风险（这部分最工程化）

报告没有停在”有风险”，而是列了几条非常具体的失败模式：

  1. AI 智能体向用户索要银行卡信息，然后直接输入购物网站。
    → 这是凭证暴露路径的改变：以前是”用户在浏览器里输卡号，浏览器/网站的防护措施在起作用”；现在是”用户把卡号给了 AI，AI 再替你输“——中间多了一个持有凭证的实体。
  2. 把用户引导到消费者保护力度更弱的支付方式。
    → 这是最容易被忽略的一条。同一个商家可能有多种支付通道，保护强度不同。如果 AI 的推荐逻辑里”成本”或”成功率”的权重高于”争议处理能力”，它就会系统性地把用户推向弱保护通道。
  3. 消费者不清楚 AI 是否真的从他们的利益出发。
    → 报告的原话是：用户”担心 AI 智能体可能买错商品、花费过多，甚至因诈骗和欺诈损失钱财。他们也不确定一旦出现问题，自己是否会受到保护，又应该向谁求助“。
  4. 零售商在影响推荐结果。
    → 报告明确提到零售商正设法影响聊天机器人的商品推荐。这意味着”AI 推荐”很快会变成一个和 SEO 同等重要的新流量入口。

4.3 ⭐ 银行打算推动的四件事

提议 含义
要求强制披露交易中是否涉及 AI 智能体 让”人机之别”成为交易元数据的一部分
提高 AI 决策的透明度 需要能回答”为什么推荐这个”
建立客户数据保护机制 数据流经智能体时的责任划分
消费者与商家自由选择 AI 电商服务，不同系统之间可互操作 防止被单一 AI 入口锁定

4.4 ⭐ 值得关注的原因

  1. 这是”智能体准入”问题从平台层走到金融层的标志。 上期（9/22）我们记录的是亚马逊以使用条款封禁 Meta Muse——那是平台方在管入口。这一期是银行方在管资金流。监管视角从”你能不能进来”推进到了”进来之后钱怎么走、出问题谁负责”。
  2. 它把”Agent 的推荐权重”变成了一个风控变量。 以前做风控，看的是”这个请求是不是人发的”；现在要开始看”这个决策是不是一个优化了错误目标的 Agent 做的“。这是一类全新的对手方。
  3. 对做爬虫/自动化的直接含义：报告提议的”强制披露是否涉及 AI 智能体“如果落地，会变成一个可检测的特征字段（类似现在的 User-Agent 声明或 Web Bot Auth）。做自动化的人应该提前假设：以后”声明自己是 Agent”可能从可选项变成合规项。 这和 Cloudflare 的 “mixed-use crawler 必须声明单一用途”是同一条逻辑线。
  4. 0.3% → 2.5% 这个数字比任何论证都有说服力。 英国零售商 John Lewis 披露：来自 AI 智能体的搜索占比已从一年前的 0.3% 升到 2.5%，而且增速还在加快。一年 8 倍。 对做数据采集的人来说，这意味着流量的入口结构正在变化——以前你要模拟”搜索引擎爬虫”，以后可能要模拟”AI 智能体的访问”。

4.5 来源

五、phantom-frida：把”反检测”做成每周自动构建的流水线

项目：TheQmaks/phantom-frida（MIT，Python，建仓 2026-02-15，9/20 推送活跃，约 381 ⭐）。最新版本：v17.16.4-20260920-run41.1。

5.1 它做什么

一句话：从源码构建 Frida Server 与 Gadget，并在构建过程中改掉一批”可被观测的运行时标识”。

先解释给初级工程师——为什么需要这个？

Frida 是安卓动态插桩的事实标准工具。但它有一个天然的问题：它为了工作，必须在目标进程里留下痕迹。这些痕迹包括：

  • frida-server 这个进程名本身；
  • 默认监听的 27042 端口；
  • 进程内存里的特征字符串 / 符号；
  • 线程名、/proc 下的可见项、匿名 RWX 内存段；
  • gadget 库的文件名字与导出符号。

风控方只要检查其中任意一项，就能判断”这台设备正在被 Frida 调试”。phantom-frida 的思路是：既然这些标识都写在源码里，那我就在编译之前把它们改掉。

5.2 ⭐ 它的三条工程纪律（这部分最值得学）

这个项目真正值钱的不是”90 个补丁”，而是它对证据的分级。仓库明确把三类东西分开：

证据类型 能证明什么 不能证明什么
单元测试 / fixture 测试 输入处理、补丁契约是否精确命中 Frida 17.16.4 源码、DEX 重建、产物晋级、元数据、失败行为 运行时是否隐身
build.py --verify 要求 Server 与 Gadget 都构建出来，剥离 Gadget 符号，拒绝已知的禁用运行时标记后才发布产物 运行时是否隐身
scripts/android_smoke.py（真机冒烟） 在一台 已 root 的设备上跑：认证的 abstract-UNIX 传输、原版客户端 RPC、spawn、attach、Java bridge 断言、/proc 检查、外部 root 内存扫描、单独加载 Gadget —

仓库原话，请直接记住这一句：

“A passing source test or byte scan is not equivalent to runtime stealth.“
（源码测试通过，或字节扫描通过，都不等于运行时隐身。）

这几乎是对整个”反检测工具”领域的当头一棒。 绝大多数同类项目的 README 会写”已绕过 16 种检测”，而这个项目在说”我能证明我改了源码，但我不能证明它在你的目标 App 里真的隐身“。

5.3 构建侧的安全设计（可以当 CI 最佳实践看）

做法 意义
不使用缓存的补丁源码，每次克隆一份干净的上游源码树 防止上一次构建的残留污染本次
从 Google 下载 Android NDK r29 并校验官方公布的 checksum 供应链校验
构建输入逐项校验 防止注入
只有硬性产物门槛 + 标记门槛都通过才上传 不允许”半成品发布”
产物内含 build-info.json + SHA256SUMS 可追溯 + 可校验
每周工作流：通过认证的 GitHub API 解析最新 release → 调用同一个只读构建工作流 → 校验下载产物 → 做证明（attestation） → 只有最后一个 job 有 release 写权限 最小权限原则
Gadget 符号被剥离，且发布前拒绝已知禁用标记 减少特征

build-info.json 记录的内容也很完整：builder / Frida / frida-core 的精确 commit、NDK 版本、UTC 构建时间、架构、名称、端口、strict W^X 代码池模式、以及 Actions 工作流 URL。

5.4 可用的关键参数（README 摘录）

python3 build.py \
  --version 17.16.4 \        # 精确 Frida 语义版本（必填）
  --name oemcodec \          # 小写替换名，3-20 字符
  --arch android-arm64 \     # 一个或多个 Android 架构
  --port 27142 \             # 监听端口（省略则保持 27042）
  --extended \               # 应用可选的扩展标识变换
  --strict-wx \              # 加固 Frida 拥有的持久匿名 RWX 映射
  --verify                   # 拒绝最终产物中的已知禁用标记

产物清单：

oemcodec-server-17.16.4-android-arm64
oemcodec-server-17.16.4-android-arm64.gz
oemcodec-gadget-17.16.4-android-arm64.so
oemcodec-gadget-17.16.4-android-arm64.so.gz
build-info.json
SHA256SUMS

本地构建要求（对想自己动手的人）：Ubuntu 22.04+（支持 WSL）、Python 3.10+、Git / curl / unzip、C/C++ 工具链、JDK 17、Node.js 18+、含 android.jar 与 D8 的 Android SDK、约 20 GB 空闲磁盘。

5.5 ⭐ 值得关注的原因

  1. “每周自动构建 + 随机命名”这个模式，把反检测从”手工技巧”变成了”供应链”。 风控方如果靠哈希/文件名黑名单来识别 Frida，这套机制会让名单永远追不上——每周一个新名字、一个新哈希。这是反检测领域第一次把”时效性”作为核心设计目标。
  2. 它的”证据分级”可以原样搬到自己的项目里。 任何做安全工具的人都应该问自己：我测的是”源码改了”，还是”运行时真的隐身了”？ 这个项目用 android_smoke.py 给出了一条可行的中间路径：在真机上跑一组可观测的断言，并把报告（脱敏后）作为证据附上。
  3. --strict-wx 这个参数指向了一个真实检测向量。 Frida 在某些场景下会在进程里留下持久的匿名 RWX（可读可写可执行）内存映射，而这在正常 App 里极其罕见——是一类很强的检测信号。这个参数就是专门去处理它的。
  4. 对做风控/反爬的人的提醒：如果你的设备指纹或完整性校验只检查”进程名 + 端口 + 库名”这三样，这套工具正好把这三样全改了。更强的做法是转向行为层与结构层——比如检查内存映射的异常形态（RWX 匿名段、非磁盘来源的可执行段）、加载时序异常、以及同类设备群体的横向对比（这台设备的内存布局和同型号其他设备差多少）。检测特征越”结构性”，越难被单点 patch 掉。
  5. ⚠️ 使用边界：仓库自己写得很清楚——“请仅在你拥有或获授权测试的应用与设备上使用本项目”。这份日报只做技术观察与检测思路记录，不提供任何绕过手段的操作指导。

5.6 相关项目（同一天一起看的安卓反检测图谱）

项目 星数 定位 建仓 / 推送
TheQmaks/phantom-frida 381 从源码构建反检测 Frida Server / Gadget，约 90 补丁 / 16 类检测向量 2026-02-15 / 2026-09-20
TheQmaks/soSaver 66 Frida 动态提取安卓 Native (.so) 库——针对”只在内存里解密”的加固方案，直接从进程内存里 dump 出映射好的 ELF，供 IDA/Ghidra 离线分析 2025-04-01 / 2026-02-06
hzzheyang/strongR-frida-android 1,692 反检测版 frida-server（老牌方案） 2021-10-19 / 2026-09-09
lico-n/ZygiskFrida 1,086 用 Zygisk 注入 frida-gadget，绕过完整性校验 2023-07-15 / 2025-10-18
okhsunrog/vpnhide 563 对选定的安卓 App 隐藏”VPN 已开启”（内核模块 + LSPosed + Zygisk 三层） 2026-04-09 / 2026-09-21
quarkslab/android-hardware-attestation-demo 52 从干净设备中继硬件 Key Attestation，用于对抗后端完整性校验（Frida hook + attestation oracle，不动 TEE） 2026-08-05
suifei/fridare 927 Frida 重打包绕检测 2024-06-21 / 2026-09-11

⭐ 这份表里最值得注意的是 quarkslab/android-hardware-attestation-demo 的思路：它不试图伪造硬件证明（那需要动 TEE，几乎做不到），而是用一台干净的设备去”代答”硬件证明，再通过 Frida hook 把结果中继回被检测的机器。这是”硬件级认证”时代一个非常现实的绕过范式——当软件层骗不过去时，就在链路上想办法。做风控的人要意识到：硬件证明能证明”有一台真设备”，但不能自动证明”就是这一台”。

5.7 来源

六、MobileRE-Skill：AI Agent 版移动端逆向技能系统

项目：index-login/MobileRE-Skill（MIT，JavaScript，建仓 2026-06-01，9/21 推送活跃，约 32 ⭐）。当前版本 v0.6.0。中文介绍见 CN-SEC（2026-09-21）。

6.1 它是什么（以及它不是”又一个脚本合集”）

给初级工程师的定位说明：这东西不是”一堆 Frida 脚本打包”，而是一套让 AI Agent 会做移动端逆向的”决策系统”。

它的工作方式是：

  1. 你用一句话描述需求（比如”分析这个 App 的登录接口签名怎么生成的”）；
  2. Agent 读取 SKILL.md 里的决策树，判断该走哪条路径；
  3. 自动选择并组合对应的模块（静态分析 / 动态 Hook / 脱壳 / 反检测 / Native 逆向）；
  4. 把结果按分层下钻的方式呈现（Java 层 → JNI 层 → syscall 层）。

6.2 覆盖范围与工具链

维度 内容
覆盖流程 静态分析、动态分析、脱壳、反检测、Native 逆向、安全合规
版本 / 协议 v0.6.0 / MIT
运行环境 Python 3.9+
工具链 Frida / Jadx / Ghidra / Unicorn / Capstone
目标平台 Android（附带鸿蒙 HAP 解析）
MCP 集成 jadx MCP / ghidra MCP
Frida 模块 共 23 个：monitors/ 下 14 个纯观察型 + bypass/ 下 9 个主动干预型
组合方式 每个模块单一职责，用 -l 参数自由组合
特色能力 一键脱壳（unpack）、反检测流水线、内存 DEX dump、Ghidra MCP 符号/结构恢复

6.3 ⭐ “14 个观察 + 9 个干预”这个划分值得单独说

这是我在这份材料里看到的最好的一个设计细节：

类型 数量 特点 什么时候用
monitors/（纯观察） 14 只读，不改目标行为 先看清楚 App 在干什么——信息采集阶段
bypass/（主动干预） 9 会改变目标行为 确认了具体检测点之后——定向处理阶段

为什么这个划分重要？ 因为主动干预一定会留下痕迹，而且会改变程序行为，可能污染你的观测结果。一个刚入门的人最容易犯的错就是：一上来就 hook 一堆东西，然后发现自己看到的程序行为已经不可信了。

正确顺序永远是：先用纯观察模块建立”正常行为基线”，再针对性地下干预模块，并且每次只加一个、观察差异。 这套技能包把这条经验写进了目录结构里。

6.4 它的真正价值：把专家经验变成可审计的分支

注意一个容易被忽略的点：这类”AI Agent 技能包”最值钱的地方不是”自动化”，而是——它把原本只存在于资深工程师脑子里的”该先做什么、什么情况下换方法”的判断，写成了可以被别人读、被别人改、被别人质疑的分支。

这对初级工程师的意义尤其大：

  • 你不需要知道”遇到加壳的 App 该先试哪种脱壳”，决策树会带你走一遍；
  • 但你能看到它为什么这么走——这是”黑盒自动化”和”可学习工具”的分界线；
  • 走完几遍之后，你会自然形成自己的判断，并且知道在哪一步可以质疑它。

6.5 ⭐ 值得关注的原因

  1. 安卓逆向正在经历”从脚本到技能包”的形态变化。 对比一下这半个月的观察：reverse-skill（36,885 ⭐，44 条路由规则 / 45 个技能模块 / 42 个 CTF 子技能 / 175 个回归测试）、MobileRE-Skill（32 ⭐，23 个 Frida 模块 + jadx/ghidra MCP）、ghidra-mcp（3,957 ⭐）、open-reverselab（1,168 ⭐，100+ MCP 工具）。它们的共同点不是”用 AI 做逆向”，而是”把逆向的流程标准化成 Agent 能执行的接口”。
  2. MCP 正在成为逆向工具链的默认接线方式。 这套技能包同时接了 jadx MCP 和 ghidra MCP，意味着静态分析的结果可以被 Agent 直接读取和推理，而不需要人来复制粘贴。对初级工程师来说，这意味着”读反编译代码”这件事的门槛在下降，但”判断哪段代码值得读”的门槛在上升。
  3. 它明确包含了”安全合规”这一环。 一个逆向技能包把合规写进流程里，这个细节值得肯定——说明作者在设计时就把”授权边界”当成流程的一部分，而不是免责声明里的一句话。
  4. ⚠️ 使用边界同样适用：这类工具只能用于你拥有或获授权的目标。技能包的自动化程度越高，”误用”的代价也越高——它会把一个需要几天经验的决策过程压缩到几分钟，包括”要不要越界”这个决策。这也是为什么”合规”必须是流程里的一个模块，而不是文档末尾的一段话。

6.6 来源

七、OpenAI 与 Anthropic 请澳大利亚放宽版权：训练数据的”合法性边界”

时间：2026-09-22（路透社首发，中文媒体当日跟进）。事件：两家公司向澳大利亚**议会 AI 联合专责委员会（Joint Select Committee on Artificial Intelligence）**提交材料。

7.1 事件本体

项目 内容
澳大利亚现行立场 计划从明年起实施一整套针对 AI 与数据中心的监管规则，但已排除在版权法中设置豁免条款
实际后果 按现行规定，这些主要注册在美国的 AI 企业，实际上无法在澳大利亚用当地受版权保护的内容开展模型训练
Anthropic 的提法 承认”广泛的版权豁免并未获得普遍支持，而且政府已经排除了这种做法“，转而请求”政府可以通过范围有限的有条件批准机制允许开展 AI 模型训练”，并表示”如果澳大利亚提出投资或其他旨在支持本国创作者和文化事业未来发展的条件，我们愿意考虑“
OpenAI 的提法 呼吁建立”一套平衡的版权框架，让模型能够从公开信息中学习“，同时给予权利人与 AI 企业合作的机会
时间节点 该委员会将于 11 月提交报告；相关立法预计明年生效
附加变量 两家公司都把版权政策和在澳的大型基础设施投资挂钩：OpenAI 与 NextDC 签署了悉尼数据中心的承购协议；Anthropic 上周成为昆士兰州一座数据中心的合作伙伴

7.2 ⭐ 两家的策略差异（读法值得学）

Anthropic OpenAI
对现状的承认 明确承认“广泛豁免已被排除” 未使用同样的承认措辞
请求的形式 有条件批准——把训练许可和义务绑定（投资、文化资助等） 平衡的版权框架——强调”公开可得的信息” + 给权利人合作机会
本质 这是一个**许可制度（licensing regime）**的雏形，而不是开放豁免 这是一个范围界定方案（什么算”公开可得”）
用词差异 用了”conditional approval”这个具体机制名 没有用这个机制名

这个差异很关键：Anthropic 提的实际上是**”我付代价换许可”，OpenAI 提的是“我只要一个更清晰的范围定义”**。前者是交易，后者是划界。

7.3 ⭐ 值得关注的原因（对做采集/爬虫的人）

  1. 训练数据的合法性，正在从”技术上拿得到”转向”法律上给不给”。 这条新闻的深层含义是：“公开可得”（publicly available）这个标准正在被各国立法逐一重新定义。澳大利亚已经明确不给豁免；欧盟 AI Act 要求通用模型提供者披露训练数据摘要并尊重文本与数据挖掘的选择退出；日本 2023 年采取更宽松立场（除非权利被明确保留，允许为 AI 训练做广泛抓取）；新加坡走行业自律路线。
  2. “选择退出（opt-out）”正在成为标准件。 上期我们记录过 Cloudflare 的 “Disallow AI Training” 设置（9/16），这一期是立法层面的同一件事。对做采集的人来说，这意味着 robots.txt / 各种 Content-Signal / use= 声明会越来越多，而且会带上法律效力。
  3. 基础设施投资正在成为版权谈判的筹码。 两家公司都把”版权政策”和”在澳建数据中心”绑定表述。这是一个非常明确的信号：数据获取的合法性，未来会和算力落地的谈判打包处理。
  4. 对逆向/安全从业者的间接含义：当”合法的公开数据获取”路径被压缩，“技术上能不能拿到”和”法律上能不能拿”之间的张力会变大。这也是为什么本系列一直强调”合规是流程的一部分”——外部环境越紧，内部流程越要清楚。

7.4 来源

其他值得一瞥

A. 工具与协议

项目 要点 来源
wrr/drop 登上 HN 热帖 本期第二节主题。无 root、user namespace、可选 gVisor 用户态内核、默认屏蔽 localhost、.git 只读 https://droprun.sh/
Crawl4AI 星数破 8.4 万 面向 LLM 的网页抓取库，84,073 ⭐（Apache-2.0，9/22 推送活跃）。第三方行业报告称其已过 8.3 万，本期实测确认继续增长 https://github.com/unclecode/crawl4ai
JetBrains 发布 Air 产品体系 覆盖 IDE 智能体开发、团队协作与组织治理（2026-09-22 19:00，HN 热帖） https://blog.jetbrains.com/blog/2026/09/22/introducing-jetbrains-air
Kimi 发布浏览器扩展 由 Kimi WebBridge 更名而来，可在浏览器侧边栏对话并操作网页（9/22 19:00 / 20:20）。浏览器侧边栏正在成为 Agent 的默认落地形态 https://x.com/Kimi_Moonshot/status/2102352211988865456
xopJack/XopProtector 涨到 94 ⭐ 安卓 APK 加固工具（DEX 加密 + 壳保护 + VMP + 反调试）。9/4 本期系列首次记录时为 32 ⭐，约 19 天涨到 94（Apache-2.0，9/19 推送）。背景：360 已宣布自 2026 年 7 月 1 日起停掉免费加固服务，全面转向付费订阅 https://github.com/xopJack/XopProtector

B. 模型与产品

项目 要点 来源
小米开源 MiMo-V2.6 系列 MiMo-V2.6-Pro 登顶 Artificial Analysis 开放权重模型智能指数（智能指数 46、124.5 tokens/秒、MIT 许可）。Anthropic 指其借 Claude 蒸馏数据 https://artificialanalysis.ai/models/mimo-v2-6-pro
GPT-6 Sol 预告当日发布 9/22 20:35 起多条预告；同日另有”OpenAI 预告今日将发布重大更新” https://x.com/testingcatalog/status/2102376333775175809
阿里云栖大会 Qwen4 家族曝光 Qwen 4 Max / Flash / Plus / 27B；官方称后继模型将扩展至 5-10T 参数 https://www.ithome.com/1/005/633.htm
Apple 新 Mac mini / Mac Studio 开售 M6/M5 Pro 与 M5 Max/M5 Ultra（9/22 20:59） https://www.apple.com/newsroom/2026/09/the-new-mac-mini-and-mac-studio-are-available-today
Anthropic 湾区生物实验室 让 Claude 指导机器人做药物实验（9/22 17:27） https://the-decoder.com/anthropic-is-setting-up-a-biology-lab-where-claude-guides-robots-through-drug-experiments

C. 安全与治理

项目 要点 来源
GPT-6 Astra 破译 1941 年德军 Enigma 密电 MVUEH 一封自 2005 年起悬置未解的密电被独立破译。⚠️ 注意去重：本系列 9/17 已报”83 年前 Enigma 密文”、9/19 已报”1918 年 ADFGVX 无线电密码”，这次是新的一封（MVUEH） https://www.cryptocellar.org/bgac/the-mvueh-break.html
Apple macOS 27 移除 Apple Intelligence 关闭开关 用户称被强制启用（HN 热帖，9/22 18:05）。“能不能关”正在成为一个可观测性问题——和上期 ZCode 的”开关绑定检查法”是同一个主题 https://dbushell.com/2026/09/22/apple-intelligence
Meta Muse 将接入 Telegram 等渠道 智能体的分发渠道在扩展（9/22 21:44） https://x.com/testingcatalog/status/2102393536377147822
中国联通中讯院发布量子安全手机 2.0 国产旗舰深度定制，搭载端侧离线安全风控 AI（9/22 15:40）。”端侧离线风控”是安卓安全侧一个值得追的方向 https://www.ithome.com/1/005/741.htm
曝 OpenAI 与 Anthropic 曾磋商具法律约束力的模型互测协议 竞争对手之间的相互评估协议（9/22 17:14） https://www.ithome.com/1/005/851.htm
Space Daily 被曝虚构 NASA 工程师批量发布 AI 垃圾内容 内容农场 / 数据质量侧。对做数据采集的人来说，”数据源本身可能是 AI 生成的”正在变成一个真实的质量风险 https://www.ithome.com/1/005/859.htm
OpenAI 呼吁就递归自我改进 AI 制定国际标准 含 Sam Altman 本人发帖与 The Decoder 报道（9/22 23:06 / 23:29） https://the-decoder.com/openai-calls-for-international-standards-on-ai-that-could-improve-itself

D. 行业数据（对做爬虫/代理的人有用）

《State of the Web Data Industry: Q3 2026》（Massive 出品）里几组可以当基准用的数字：

指标 数值 备注
Crawl4AI GitHub 星数 83,000+（本期实测 84,073） “给 AI 流水线喂干净网页数据”已成主流开发者需求
Gartner 预测 到 2026 年底，任务型 AI Agent 将嵌入 40% 的企业应用 2025 年这个比例还不到 5%
住宅代理对现代反爬系统的通过率 92-98% 靠真实设备骗过行为与设备指纹
机房 IP 的通过率 65-80% 对指纹弱，只对简单 IP 黑名单有效
住宅代理占代理市场收入比例 约 42%（2026） 2023 年约 35%（厂商估算，只作方向参考）
住宅代理检测方式的对应关系 — 反爬系统已经不再主要靠”封机房 IP 段”，而是看请求行为、设备信号与流量模式

⚠️ 报告自己写的免责说明值得引用：”市场研究机构给出的顶层数字差异极大，从不到 1.5 亿美元到几十亿美元不等，取决于口径与方法。它们都不应被当作经过审计的数字。“

⭐ 这份报告里最值得记住的一句判断：

过去两年的问题是”我的爬虫能不能过反爬检查“；
现在正在变成”我的流量落不落在目标站点已同意放行或计费的那个类别里“。

来源：https://www.joinmassive.com/blog/state-of-the-web-data-industry-2026

工具雷达

新入雷达

项目 星数 License 建仓 最近推送 定位
TheQmaks/phantom-frida 381 MIT 2026-02-15 2026-09-20 从源码构建反检测 Frida Server / Gadget，约 90 补丁 / 16 类检测向量 / 每周随机命名自动构建；本期第五节主题
okhsunrog/vpnhide 563 NOASSERTION 2026-04-09 2026-09-21 对选定安卓 App 隐藏 VPN 状态（内核模块 + LSPosed + Zygisk 三层）；推送活跃
wrr/drop 104 Apache-2.0 2025-07-25 2026-09-21 无 root Linux 沙箱（user namespace + 可选 gVisor），默认屏蔽 localhost、.git 只读；本期第二节主题
TheQmaks/soSaver 66 MIT 2025-04-01 2026-02-06 Frida 动态 dump 安卓 Native .so——针对”只在内存解密”的加固；⚠️ 推送停 7 个月
quarkslab/android-hardware-attestation-demo 52 MIT 2026-08-05 2026-08-05 硬件 Key Attestation 中继——用干净设备代答完整性证明，不动 TEE；⚠️ 建仓后未再推送
index-login/MobileRE-Skill 32 MIT 2026-06-01 2026-09-21 AI Agent 移动端逆向技能系统：23 个 Frida 模块 + jadx/ghidra MCP + 一键脱壳；本期第六节主题
hzzheyang/strongR-frida-android 1,692 NONE 2021-10-19 2026-09-09 反检测版 frida-server（老牌方案）；⚠️ 无 License
lico-n/ZygiskFrida 1,086 MIT 2023-07-15 2025-10-18 Zygisk 注入 frida-gadget 绕完整性校验；⚠️ 推送停 11 个月
xopJack/XopProtector 94 Apache-2.0 2026-08-13 2026-09-19 安卓 APK 加固（DEX 加密 + 壳 + VMP + 反调试）；9/4 记录时 32 ⭐
unclecode/crawl4ai 84,073 Apache-2.0 2024-05-09 2026-09-22 面向 LLM 的网页抓取库；行业基准项目

追踪表（对比 9/22）

项目 9/22 9/23 变化 License 最近推送 备注
NandhaKishorM/laya 8,628 15,186 +6,558 Apache-2.0 2026-09-21 本期涨幅第一；建仓 5 天破 1.5 万
browser-use/jev-ultrafast 14,846 17,706 +2,860 MIT 2026-09-18 连续第三期领涨（建仓 7 天）
jaredpalmer/kev 1,982 3,499 +1,517 Apache-2.0 2026-09-22 本期涨幅第二，推送恢复活跃
zai-org/ZCode 5,322 6,213 +891 Apache-2.0 2026-09-21 上期头条主角，开源后持续被关注
browserbase/stagehand 24,728 25,144 +416 MIT 2026-09-21 推送活跃
newliver666/apk-reverse 552 954 +402 MIT 2026-09-22 安卓逆向侧涨幅最大，接近破千
Tencent/BrowserSkill 6,276 6,545 +269 MIT 2026-09-22 推送活跃，连续两期回升
p-e-w/heretic 32,061 32,163 +102 AGPL-3.0 2026-09-22 上期第八节主题
zhaoxuya520/reverse-skill 36,789 36,885 +96 MIT 2026-09-22 推送恢复活跃（此前停 19 天）；44 路由规则 / 45 技能模块 / 175 回归测试
N4darae/anti-mage 1,814 1,905 +91 MIT 2026-09-22 连续两期回升，推送恢复
vinnylarouge/jevlike 1,156 1,219 +63 MIT 2026-09-16 推送仍停在 9/16
daijro/camoufox 12,048 12,073 +25 MPL-2.0 2026-09-21 推送活跃
CloakHQ/CloakBrowser 31,610 31,624 +14 MIT 2026-09-20 —
bethington/ghidra-mcp 3,943 3,957 +14 Apache-2.0 2026-09-22 200+ MCP 工具
jo-inc/camofox-browser 11,137 11,150 +13 MIT 2026-09-19 —
zhizhuodemao/js-reverse-mcp 2,797 2,809 +12 Apache-2.0 2026-09-03 ⚠️ 推送已停 20 天
google/mantis 1,683 1,692 +9 Apache-2.0 2026-09-18 —
browser-act/skills 5,969 5,977 +8 MIT 2026-08-24 ⚠️ 推送停近一个月
ljagiello/ctf-skills 3,323 3,331 +8 MIT 2026-09-13 —
feder-cr/AIHawk 31,616 31,623 +7 MIT 2026-09-22 推送活跃
LING71671/open-reverselab 1,162 1,168 +6 GPL-3.0 2026-09-19 —
trailofbits/skills 7,195 7,200 +5 CC-BY-SA-4.0 2026-09-22 推送活跃
2akouwu/reverify 1,236 1,240 +4 MIT 2026-09-07 ⚠️ 推送停 16 天
zhom/donutbrowser 3,871 3,875 +4 AGPL-3.0 2026-09-22 推送活跃
saifyxpro/HeadlessX 2,313 2,315 +2 NOASSERTION 2026-09-17 —
suifei/fridare 925 927 +2 MIT 2026-09-11 —
germondai/trawl 828 830 +2 AGPL-3.0 2026-09-22 推送活跃
TheGP/untidetect-tools 2,000 2,001 +1 NONE 2026-09-13 无 License
enetx/surf 1,827 1,828 +1 MIT 2026-09-10 Go 侧 JA3/JA4 + HTTP3 QUIC
scrapfly/Antibot-Detector 494 495 +1 NOASSERTION 2026-09-08 反爬识别侧
miloira/vlcaptcha 21 22 +1 MIT 2026-09-11 VLM 通用验证码识别
ryuhandev/CaptchaX 19 20 +1 Apache-2.0 2026-09-18 一体化验证码求解 API
VeyraAgent/cf-solver 7 8 +1 MIT 2026-09-20 自托管验证码求解 sidecar
CreditTone/hooker 5,311 5,311 0 NONE 2026-09-11 无 License
ax/apk.sh 3,834 3,834 0 GPL-3.0 2026-01-26 ⚠️ 推送停更 8 个月
reversenseorg/dexcalibur 1,173 1,173 0 AGPL-3.0 2026-09-18 —
ZenShoutBerth/web-stealth-farm 12 12 0 NONE 2026-09-20 ⚠️ 无 License
h00klod0er/awesome-re-mcp 1 1 0 NONE 2026-09-21 逆向 MCP 清单
h00klod0er/awesome-android-re 1 1 0 NONE 2026-09-21 安卓逆向清单
SawyerHood/dev-browser 6,631 6,630 −1 MIT 2026-09-05 推送放缓
niespodd/browser-fingerprinting 5,140 5,139 −1 NONE 2026-07-27 ⚠️ 推送停近 2 个月
xKiian/GeekedTest 675 674 −1 MIT 2026-09-16 极验 v4 纯 Python 无浏览器
0xMassi/webclaw 2,356 2,357 +1 AGPL-3.0 2026-09-18 TLS 层模拟 Chrome

上期追踪回顾（9/22 期 → 9/23 期）

上期条目 本期进展
① 智谱 ZCode 整改闭环 ZCode 仓库 5,322 → 6,213 ⭐（+891），开源后关注度持续。本期无新增整改动作
② ChatGPT __obi 跨站 Cookie 本期无新增信号。可追踪方向：bzrcdn.openai.com / bzr.openai.com 域名下是否有新脚本
③ 亚马逊封禁 Meta Muse（条款依据迁移） 本期有重大后续：① Muse macOS 应用被曝零日漏洞（本期头条）；② 七家银行联合警告 AI 代购风险（本期第四节）。“智能体准入”的讨论从平台层扩展到了金融层
④ AI 漏洞海啸（CVE 66,401 / 平均利用时间 −7 天） 本期无新增量化数据。google/mantis 仓库 1,683 → 1,692 ⭐
⑤ OpenClaw × Trail of Bits（23 个确认漏洞） trailofbits/skills 7,195 → 7,200 ⭐，推送活跃（9/22）。本期第二节 Drop 沙箱正好是这类”检查点错位”问题的工程侧对策
⑥ Heretic（自动 abliteration） 32,061 → 32,163 ⭐（+102），推送活跃（9/22）
⑦ Google 程序图（Procedural Graphs） 本期无新增信号
⑧ Kev（$95 训出三个尺寸） 本期大幅上涨：1,982 → 3,499 ⭐（+1,517），推送恢复活跃（9/22）。是本期涨幅第二的项目
⑨ ZuckOff（BLE 智能眼镜检测） 本期无新增信号
⑩ 联合国 AI 科学小组简报 本期相关：古特雷斯在联大呼吁全球监管 AI、警示杀人机器人风险（9/22 22:36）；另有”联合国 AI 专家反对 AI 末日论”（9/22 19:08）
Cloudflare 9/15 新默认生效 已生效并进入复盘期。本期新增两份行业数据：① Q3 2026 Web Data Industry 报告（住宅代理 92-98% vs 机房 65-80%）；② “小站点感受最直接“——受影响的主要是免费套餐上的个人博客、独立店主、单人newsletter
上期工具雷达新入项 newliver666/apk-reverse 552 → 954 ⭐（+402），安卓逆向侧涨幅最大；N4darae/anti-mage +91；vinnylarouge/jevlike +63；验证码类项目（vlcaptcha / CaptchaX / cf-solver）均小幅 +1

一句话总结表

# 事件 一句话 对谁重要
1 Meta Muse 零日 一个”未公开设置” + “云端听写” + “无隔离的设置存储”，就能让本地代码借 AI 助手的权限拍照、写文件、且不弹提示 所有做客户端安全与 AI 产品的人
2 Drop 沙箱 无 root + user namespace + 可选 gVisor；默认屏蔽 localhost、.git 只读；配置只能放宽不能收紧 所有跑 Agent / 跑不可信脚本的人
3 AMD RDRAND 摇不出 0 论坛帖是”少给 0”，官方 CVE 是”失败时把无效 0 当真随机数交付”——这两件事必须分开读 做加密、指纹、风控的人
4 七家银行警告 AI 代购 风险被具体化为”向用户索要卡号并直接填入”和”引导到弱保护支付通道”；同期 AI 智能体搜索占比一年涨 8 倍 做自动化、支付、风控的人
5 phantom-frida 90 补丁 / 16 检测向量 / 每周随机命名自动构建；官方明说”源码测试通过 ≠ 运行时隐身” 做安卓逆向与设备完整性校验的人
6 MobileRE-Skill 23 个 Frida 模块分成”14 观察 + 9 干预”——先用只读模块建基线，再定向干预 安卓逆向入门与工具链建设
7 OpenAI/Anthropic 请澳洲放宽版权 “公开可得”正在被各国立法重新定义；训练许可开始和投资承诺打包谈判 做数据采集、爬虫、数据集的人

本期方法论提炼（给做逆向 / 爬虫 / 风控的人）

1. “这条边界是谁定义的、能不能被改写、改写了之后谁会发现”——这是审计任何安全边界的三个必问项。

Meta Muse 的零日不是”代码写错了”，而是三条设计决策叠加的结果：听写放在云端（数据会离开设备）、设置项不公开（不在文档与 UI 里）、设置存储不做隔离（任何进程可写）。

  • 能不能被改写？ → 去找所有可写的配置键，而不是只看 UI 上的开关。文档里没写的那些开关，往往不做权限校验、不做值域校验、也不记日志。
  • 改写了之后谁会发现？ → 如果答案是”没人会发现”，那这条边界就只是一个约定，不是一条边界。
  • 数据会离开设备吗？ → 架构图画在哪里，决定了隐私政策的可信上限。本地处理 vs 云端处理，是安全决策，不只是成本决策。

2. “先建基线，再干预”——这是逆向工作中最容易被跳过、也最贵的一步。

MobileRE-Skill 把 23 个 Frida 模块分成 14 个纯观察 + 9 个主动干预，这个比例本身就在传达一条经验：

观察模块应该远多于干预模块，而且观察必须先发生。

因为主动干预会改变程序行为，从而污染你的观测结果。一上来 hook 一堆东西，然后发现自己看到的程序行为已经不可信了——这是新手最常踩的坑。

可操作的做法：

  1. 先用只读手段（日志、/proc、网络抓包、内存枚举）建立**”正常行为基线”**；
  2. 再一次只加一个干预点，观察差异；
  3. 每次干预前，先写下”我预期会看到什么变化”，再对照实际结果。

3. “源码测试通过 ≠ 运行时隐身”——把证据分级，比多写十个功能更值钱。

phantom-frida 明确把证据分成三层：单元/fixture 测试（验证补丁契约）、构建门槛（拒绝已知禁用标记）、真机冒烟（在已 root 设备上跑 RPC / /proc 检查 / 外部内存扫描）。

这套思路可以原样搬到任何安全工具项目里：

证据层级 能证明 不能证明
单元测试 代码逻辑对不对 实际环境里成不成立
静态扫描 有没有已知特征 运行时会不会暴露新特征
真机/真环境冒烟 在特定环境里确实成立 换一个环境还成不成立

⚠️ 反过来看，这也是给做检测的人的提醒：“我的检测规则单元测试通过了”同样不等于”它能在真实设备上抓到东西”。 检测方和绕过方在这一点上是同一个坑。

4. “少给 0”和”给假 0”是两种完全不同的缺陷——评估安全缺陷时，先问它是偏向性还是错误成功。

AMD 这一条给了教科书式的对照：

  • 论坛帖（16 位下不产 0）：这是分布缺口，影响统计、模拟、以及任何假设均匀性的场景；
  • 官方 CVE-2025-62626（Zen 5 上 rdseed 失败时把 CF 置 1）：这是错误成功，直接把无效数据当有效数据交付，直接影响密钥生成。

同时还有第三层：软件层可能把”合法的 0”当成”失败”（OpenSSL #5340），人为制造出分布缺口。 也就是说——你观测到的异常，未必是硬件的问题。

可操作的做法：

  • 遇到”随机性异常”时，先在软件层查 CF 语义有没有被误用，再怀疑硬件；
  • 任何依赖客户端随机性的设计（挑战 nonce、指纹盐值、设备 ID），都要假设客户端的随机数可能不是随机的；
  • 工程上不要”信任硬件熵源”，而是永远把硬件源和软件源混起来用。

5. “检测特征越结构性，越难被单点 patch 掉”——反检测与检测的军备竞赛，正在从”名字”打到”结构”。

phantom-frida 一次改掉的是：进程名、监听端口、库文件名、导出符号。如果你的检测只查这三样，那这套工具正好把三样全改了。

往结构层走的方向：

层次 检测什么 被绕过的难度
名字层（进程名 / 端口 / 库名） 字符串黑名单 低——改源码即可
符号层（导出符号 / 特征字节） 字节扫描 中——需重编译
结构层（内存映射形态：持久匿名 RWX 段、非磁盘来源的可执行段；加载时序异常；线程与句柄的异常组合） 行为与结构统计 高——需要改架构
群体层（这台设备与同型号其他设备的横向差异） 群体基线偏离 很高——需要真的做到”和真机一样”

⚠️ 注意 quarkslab/android-hardware-attestation-demo 提示的另一个方向：当软件层骗不过去时，就在链路上想办法（用干净设备代答硬件证明）。所以做风控的人要意识到：硬件证明能证明”有一台真设备”，但不能自动证明”就是这一台”——绑定关系才是关键。

6. “流量入口的结构正在变化”——从’能不能过反爬’到’落不落在允许的类别里’。

Q3 2026 行业报告里那句话值得抄在墙上：

过去是”我的爬虫能不能过反爬检查“；现在是”我的流量落不落在目标站点已同意放行或计费的那个类别里“。

同时有三个数字要一起看：

  • 住宅代理 92-98% vs 机房 IP 65-80% ——差距来自真实设备的行为与设备信号，而不是 IP 数量；
  • AI 智能体带来的搜索占比一年从 0.3% 到 2.5%（8 倍） ——流量入口在迁移；
  • 银行提议”强制披露交易是否涉及 AI 智能体” ——“声明自己是 Agent”可能从可选项变成合规项。

可操作的做法：

  1. 不要只优化 IP 池。设备质量（行为 + 指纹一致性）才是通过率的主因；
  2. 提前假设”声明自己是 Agent“会成为标准动作，把这条路径当成产品能力来建设，而不是当成对抗手段；
  3. 建立”失败原因分类日志“——区分”被 IP 封”、”被指纹识别”、”被类别规则拒绝”。这三类的应对完全不同，混在一起看等于没有日志。

本期数据采集说明

项目 内容
采集周期 2026-09-22 ~ 2026-09-23（覆盖当日完整窗口 + 回补 9/21 部分条目）
数据源 AI HOT 精选与全量条目（近 3 天，含翻页）、多轮定向检索（逆向 / 验证码 / 爬虫 / 风控 / 指纹 / 沙箱 / 破解等关键词）、GitHub API 仓库交叉验证（约 50 个仓库逐项核对星数 / License / 建仓 / 推送时间）
去重处理 候选条目先与 9/22 期日报逐项比对（零日 / gVisor / Drop / rdrand / MVUEH / 版权 等关键词命中数为 0 才列为新条目）；GPT-6 Astra 破译 Enigma 一条因 9/17、9/19 已报同类事件，本期降级为”其他值得一瞥”并标注区分点（MVUEH 为新一封）
星数口径 全部为 2026-09-23 00:00 前后实测值；变化量对比上期（9/22）同一时间点
合规说明 本期涉及逆向 / 反检测 / 指纹的项目，仅作技术观察与检测思路记录，不提供任何绕过手段的操作指导；相关工具均注明”仅限自有或获授权目标使用”