抱歉这可能是我们最不硬核的一篇技术文章

（本文不包含任何漏洞相关细节）

第一则消息

去年，我们拆解了星链终端，构建了模拟系统

但进一步研究工作一度停滞

因为想探究 SpaceX Starlink 卫星与地面之间的交互

其官方地面终端本体几乎是唯一的研究入口

然而在 2022 年第一代 Starlink 终端

被 Lennert Wouters 博士使用电压故障注入攻破后

新一代的地面终端设备中

由于 SpaceX 对此类攻击进行了针对性的防御

致使此后数年尽管多个国际顶级安全团队不断研究

也始终无人能够攻破新版 Starlink 🛰️ 终端

今年 DARKNAVY 通过极为复杂的硬件攻击方法

成功在新一代 Starlink 终端上实现了任意代码执行

这一突破为后续深入 Starlink 卫星系统安全

重新打开了缺失已久的底层研究入口

过去这样的硬核安全能力很难同时服务所有人 

而deepsec 将把它 AI 化、规模化带给每一位从业者

另一则消息是

近期上海头部 AI 研究机构再度联合 DARKNAVY 

基于 deepsec 研发的AI 安全工程 DoGNAVY

在内测中使用国产开源大模型 GLM-5.3

将漏洞发现能力测试榜 CyberGym 上的已有成绩

提升至全球第一 94.96%

并在漏洞利用能力测试榜 ExploitGym 中

成功攻克 110 道题目，位列全球第四🏅

目前仅次于 GPT-5.5/5.6 和 Mythos

我们深知我们的工作距离世界最强还有不小差距

不过由于我们正将研究重心转向真实世界的攻防表现

这会是我们最后一次打榜测试

最后一则消息

我们近日借助deepsec 发现了某国民级 APP

多个新的未知漏洞，在实验环境下经人工串联组合

已证实可实现严重的蠕虫式 RCE 自动传染攻击

被感染手机的摄像头、麦克风和相册等可能全部沦陷

这样可蠕虫式攻击亿级用户的漏洞链，其中每个漏洞

在普遍认为漏洞研究越来越廉价的 AI 时代

大概会从过去几千块的厂商 SRC 奖励，降至更低

我们想和厂商及有关方探讨一个问题：

当产业以“发现漏洞的成本”度量“漏洞发现的价值”时

是否还会有“负责任的漏洞披露”⁉️

欢迎留言或私信，与我们探讨

阅读原文

跳转微信打开

阅读原文

跳转微信打开

CyberGym Benchmark

全球第三，中国第一

近日，上海头部 AI 研究机构联合我们 DARKNAVY，基于 deepsec@DARKNAVY 的漏洞验证子系统，构建了以国产开源大模型为底座的 DoGNAVY 安全 Harness Agent，在全球公开 AI 网络安全能力评测基准测试 CyberGym 上取得 90.8% 的中国最好成绩：

排在我们前面的，是微软最新的 MDASH，和刚被 Google 以 320 亿美元收购的 Wiz（领先我们 1 道题）。OpenAI 的安全大模型 GPT-5.5-Cyber，以及 Anthropic 的 Claude Mythos Preview 分列全球第六和第九。

CyberGym 是由 UC Berkeley 等机构推出的大规模、高真实度的 AI 网络安全能力评估框架，是 AI 在网络安全能力领域最大的竞技场。它包含 1,507 个真实漏洞任务，横跨 188 个广泛使用的开源项目，是目前规模最大的 AI Agent 网络安全基准，已被 OpenAI、Anthropic、DeepSeek 等厂商在最新模型的系统卡中用作评估标准，也被微软、Google Wiz 等厂商当作 AI 安全能力的权威标尺。

DogNAVY 在 1453 个任务中成功构造了 PoC 并触发 crash（96.42%），其中 1369 个任务精准命中了任务指定的漏洞（90.84%）。

详细技术报告点击文末阅读原文，或打开链接🔗 https://deepsec.darknavy.net/blog/cybergym

为了避免类似 7 月 OpenAI 模型自主侵入 hugging face 网站的类似事件发生，DARKNAVY 将 deepsec PoC 子系统从完整形态中抽离，并结合支撑大规模智能体运行与轨迹分析结构化诊断的 Agent 沙箱基础设施 AgentDoG 设计思路，为 Agent 构建了严格的沙箱环境并进一步约束其能力，保证 Agent 在隔离的环境中执行指定的任务。

早在 7 月 20 日，deepsec 的漏洞洞察子系统便已正式上线开放平台（https://deepsec.darknavy.net），并通过邀请码开放有限试用。到目前为止的试用期间，它已经帮助来自 150+ 企业或机构的用户发现了上万个安全风险。

接下来，DARKNAVY 将为deepsec 声纳计划的合作伙伴逐步开放 PoC 子系统的能力，与更多中国创新企业和组织机构共同解决真实安全风险，让 AI 安全能力走向更多中国科技创新企业。

DoGNAVY 的成绩，来自于 DARKNAVY 多年积累的顶尖安全研究员真实漏洞攻防经验赋予国产 AI：

• 安全研究工作流与安全研究决策逻辑：CyberGym 的任务种类多、数量大，Agent  需要从模糊的描述，准确识别具体的漏洞位置，并自主验证该漏洞。同时需要 Agent 在有限的时间内，决定探索的方向与思路，极大考验模型及 harness 对漏洞研究的判断力。因此，将顶尖安全研究员的工作方式及决策逻辑内化为 Agent 工作流，帮助 Agent 面对复杂漏洞时更有效地识别与验证；

• 漏洞可达性研判：还原漏洞位置的数据流与控制流是帮助 Agent 验证漏洞的重要支撑。deepsec 针对漏洞可达性的研判，通过从程序入口还原调用链与数据约束，以判断真实输入能否触发漏洞。不仅能够帮助识别误报，还能够帮助 Agent 更好的到达漏洞位置，以更高的效率验证漏洞的可达性；

• 动静态闭环演进：真实攻防研究中，安全研究员们通常使用多种方式和工具交叉验证漏洞的真实性。我们同样将真实研究中，实践有效的工具及基础设施赋予 Agent，帮助 Agent 更好地操作动态测试、静态分析工具持续验证对漏洞的判断。静态分析提出路径与约束，动态验证以覆盖率、崩溃与运行时证据加以校验，不断的通过结果反哺下一轮分析；

• 严格的知识与记忆边界：评测中禁止数据集相关的历史 PoC、补丁或解题思路，任务之间不共享记忆，避免拟合数据集——使成绩能够反映系统真实的泛化能力。

更多细节，点击文末阅读原文的详细技术报告。

毋庸置疑，随着 AI 加速落地，世界正越来越深地构筑于代码之上，网络安全也已被推至前所未有的高度。

然而，在 AI 浪潮中，“安全”最近却显露出另一副面孔：先是 Mythos 横空出世，号称碾压开源社区安全防线，斩获数万高危漏洞；随后，Linux 内核、KVM、Redis 等关键基础设施接连遭遇零日漏洞的密集冲击；再到近期 OpenAI、Anthropic 的 AI 多次突破自身沙箱、侵入其他系统，本该是严重的安全事故，竟被包装成能力的勋章。

更具讽刺意味的是，一边是美国政府限制 Anthropic Mythos 对外开放，闭源模型厂商以安全之名拒绝大量用户保护自身的安全需求；另一边，真正的攻击者却不会遵守任何规则，也不会因为模型拒绝回答而停止行动。

人们由此开始意识到，通往通用人工智能（Artificial General Intelligence，AGI）的道路，不仅横亘着技术难题，也裹挟着现实世界中复杂而残酷的利益博弈与攻防对抗。

与此同时，开源大模型虽然在编程等领域不断逼近顶级闭源模型，但在前沿网络安全能力上依然存在明显差距。迄今为止，AI 在实战网络攻防和理论密码学研究中的突破性成果，几乎仍被少数闭源模型所垄断。

正因如此，我们决定将多年积累的顶级漏洞研究和安全攻防经验 AI 化，让它成为一种能随着开源模型能力同步 scale up 的力量。我们希望，顶尖的安全能力不再被少数专家、机构与地区所垄断，而是成为开源 AI 生态可以共同拥有、共同进化的基础能力。

这就是 deepsec 声纳计划的由来。

征途在前，deepsec@DARKNAVY 希望能继续与各位行业伙伴、大模型厂商和 AI 研究机构一起，以我们积累的前沿安全能力，为这个非对称对抗的世界多添一分安全感，也为 AGI 的真正到来，尽安全圈一点微小却不可或缺的努力。

阅读原文

跳转微信打开

阅读原文

跳转微信打开

2026 年 5 月 14 日，台湾省知名黑客 Orange Tsai 在全球黑客大赛 Pwn2Own 柏林站上完成了 Microsoft Edge 沙箱逃逸攻击，成为了全场唯一拿走浏览器赛道 17.5 万美元赏金的参赛者。令人意外的是，主办方事后透露，Orange 的攻击完全由 4 个逻辑漏洞串联组成，并非浏览器攻击常见的内存破坏漏洞利用。一时间全球安全圈议论纷纷，但始终没有人能够推测或分析出这一攻击的原理。

此后的两个月内，除微软官方修复公告中的极简描述外，没有任何该攻击的技术细节被披露，也没有第三方成功复现案例。而现在，我们的安全 AI 系统 deepsec 中的 PoC Agent 子模块首次还原了该攻击的所有步骤，并给出了完整攻击复现：

对微软、苹果等厂商的修复补丁进行分析，是企业与关键基础设施内部安全建设工作的重要一环。此类研究不仅可以衡量漏洞真实危害、评估潜在黑客攻击的响应速度，还有助于下游企业自主验证补丁是否真正解决问题，构建检测和缓解能力。

然而，此次漏洞位于体型庞大的 Edge 浏览器中（单模块超过 300 MB），传统的基于二进制差分的方法在这类补丁面前需要消耗大量的专家人力来辅助分析。在 IDA 等分析工具中加载目标二进制模块和调试符号后，单个 IDB 可达 5 GB，进行二进制差分极为耗时；此外，编译器优化、函数重排等非语义变化也引入了大量与目标漏洞无关的噪声，例如 Edge 此次修复前后发生变动的函数多达 3.2 万个，这进一步增加了定位关键漏洞修复的难度。

差分分析预览看板（图源: deepsec Pro）

另一方面，与内存类漏洞不同，逻辑类漏洞的分析尤其依赖对代码上下文和业务语义的理解，仅从变更函数出发很难还原完整安全语义。我们事后复盘发现，构成此次 Edge 利用链的多个逻辑漏洞分布在导航校验、异步标签页选择和反馈日志处理等不同模块中，彼此间缺乏直接联系。即使定位到单个安全修复，也很难还原漏洞所提供的利用原语及其串联关系。

我们在研究中发现，AI 在代码语义理解和跨模块关联分析方面展现出了显著的效率优势。基于这一思路，我们在 deepsec 系统中实现了一套自动化差分分析框架，将二进制差分分析工具、PoC Agent 平台与 DARKNAVY 安全研究知识库整合到同一分析流程中。

我们以这条复杂的 Edge 利用链为测试对象，检验 deepsec 能否仅从修复前后的二进制文件和有限的官方信息出发，还原完整的漏洞利用链。

微软官方漏洞公告

面对未知利用链，deepsec 结合漏洞公告，选择从原语最明确的链尾倒推。

分析首先定位到 Edge 反馈组件中的一处明显安全修复。文件写入相关功能在新版中被移除。旧版接口存在路径穿越问题，对应链尾的任意文件写入原语。结合特定利用技巧，该原语还可以进一步转换为 Windows 远程代码执行。

Edge 反馈组件中的修复（图源: deepsec Pro）

同时，deepsec 也确认了该接口的触发条件：攻击者需要在暴露 edgeFeedbackPrivate API 的特权页面执行 JavaScript 代码。

至此，利用链的末端已经明确：

接下来的问题是，攻击者如何从普通网页进入这一特权执行环境。

根据漏洞公告中有关“导航处理”的线索，deepsec 对相关组件进行定向差分分析，随后定位到 CA Guidance 导航组件，并识别出多处安全修复。其中，关键变化集中在 EdgeCAGuidanceNavigationThrottle::WillStartRequest。

CA Guidance 导航组件中的修复（图源: deepsec Pro）

旧版直接取参数 switch_profile 作为导航目标，没有限制 javascript: 等特殊 scheme，新版加入了 URL scheme 白名单过滤。

除目标处理外，导航来源校验也发生了变化。旧版通过 GetVisibleURL 获取当前页面显示的 URL，并据此判断导航是否来自微软登录页面，新版则改用 GetInitiatorOrigin 验证导航真实发起方。

形式上，这只是 URL 来源的替换，但 deepsec 识别出两者在安全语义上的微妙差别：旧版验证的当前页面实际可以由一个不可信的上下文控制导航。攻击者可以先让一个可控标签页显示微软登录页面，再从不受信任的上下文触发后续导航，使“通过校验的页面”与“真正发起导航的页面”并不一致，从而绕过来源限制。

不过，即使能够绕过来源校验，渲染进程依然无法直接导航至 edge://guidance-ca-error ，利用链在入口处仍然受阻。

针对这一问题，deepsec 自行分析后发现一个未被补丁修改、可用于进入该处理流程的校验缺口：该组件只比较目标入口 URL 的 host ，没有同时验证 scheme。因而攻击者可以用 https://guidance-ca-error/ 进入同一处理流程，绕过渲染进程不能直接导航至 edge:// 特权 scheme 的限制。进入该流程后，再将 switch_profile 设置为特权页面或 javascript: URL。

到这里，deepsec 已经获得了一个任意 URL 跳转原语，但这仍不足以完成完整利用。

这些漏洞勾勒出了“导航校验绕过 → UXSS → 调用特权 API → 路径穿越写文件”的基本方向，但仍缺少关键一环。

攻击者虽然可以从微软登录页面发起任意目标跳转，通过 javascript: URL 在当前页面执行脚本，或跳转到一个特权页面，但这两种能力无法直接组合：跳转到暴露 edgeFeedbackPrivate API 的特权页面后，攻击者仍然需要找到一种方式，在该特权页面的上下文中执行 JavaScript。

deepsec 的分析一度陷入僵局。

在探索过程中，deepsec 还定位到其他模块中的若干可疑修复。例如旧版 QuickAuth 的跳转功能同样缺乏必要限制，而新版为其增加了目标白名单等安全措施。随着候选漏洞不断增多，真正的利用链变得更加扑朔迷离。

此时，deepsec 必须像人类研究员一样，基于现有证据和利用条件进行取舍：哪些修复只是相邻攻击面中的独立问题，哪些变化才可能补齐当前利用链？

经过一段时间的并行探索，deepsec 判断 QuickAuth 等方向缺乏利用条件，因此将更多分析资源投入 CA Guidance 路径。

沿着 HandleCAErrorPageGuidance 的下游继续追踪后，deepsec 找到了整条链中最隐蔽的对象绑定错误： 

导航对象绑定逻辑的修复（图源: deepsec Pro）

当 email 参数与当前 profile 匹配时，HandleCAErrorPageGuidance 通过异步 PostTask 导航至 switch_profile 参数指定的 URL。

旧版 lambda 捕获的是浏览器窗口 WeakPtr<Browser>。执行导航时用 CURRENT_TAB disposition，但没有绑定具体标签页。Navigate 在运行时通过 GetActiveWebContents 取当前活动标签页，并在该标签页中执行导航。新版 lambda 则捕获具体标签页 WeakPtr<WebContents>，确保目标 URL 加载到该标签页中。

两者间的细微差异看似只是导航实现方式的调整，并不具有安全意义。然而结合利用链语境与浏览器安全研究知识，deepsec 察觉到这一调整改变了安全检查与实际操作对象之间的关系。

由于 lambda 异步执行，从任务被投递到实际运行之间，浏览器活动标签页可能发生变化。因此，通过登录页校验的标签页和实际执行 JavaScript 的标签页可以不是同一个。攻击者可以构造多重跳转，先让一个标签页进入微软登录页面并通过校验，再在异步任务执行前将目标特权页面切换为活动标签页。

这样一来，攻击者便能够在暴露 edgeFeedbackPrivate API 的特权页面上下文中执行任意 JavaScript，最终形成 UXSS。

至此，完整利用链得以闭合：攻击者首先从恶意页面构造 CA Guidance 导航，并利用入口 URL 只校验 host、不校验 scheme 的缺陷进入相关处理流程；随后，通过错误的导航来源校验和缺失的目标 scheme 限制，实现任意 URL 跳转；最后，利用异步导航中的对象绑定错误切换活动标签页，在暴露 edgeFeedbackPrivate API 的特权页面中执行 JavaScript。攻击者由此可以调用反馈组件中的漏洞接口，通过路径穿越完成任意文件写入，并进一步实现 Windows RCE。

最终，deepsec 在配套的实机测试环境中完成了漏洞利用代码的编写与调试，验证了整条利用链。

这次实践表明，在公开信息极其有限、目标二进制规模庞大、多个漏洞跨组件分布的情况下，deepsec 仍能够结合补丁差分、代码语义、浏览器安全知识和动态验证，逐步还原漏洞原语及其串联关系。

微软等上游厂商发布安全补丁，并不代表所有终端立即完成升级：大型企业往往还要经过测试、部署和重启，攻击窗口可能持续数天甚至数月。

以往，下游企业往往抱有侥幸心理，认为黑客难以在短时间内还原这些复杂的漏洞，发起大规模攻击的成本较高。

然而，随着 AI 安全能力的逐渐成熟，从补丁发布到被黑客成功利用的时间窗口将被大幅缩短。

过去依赖这一时间差建立的安全防线，或将很快失效。

跳转微信打开

低空安全领域，主流无人机的防御体系已相当成熟。在严密的人工审计下，市面主流机型已连续三年未公开披露远程代码执行级漏洞。

然而，安全的终点永远在动态演进。2026年4月，Anthropic 发布 Mythos Preview：AI 已能自动发现真实漏洞并构建攻击链，把过去依赖顶级黑客数周完成的工作，压缩为可复制的工业化流程；美国网络司令部也已公开表示正利用 AI 增强漏洞利用等能力。

当攻防范式正向 AI 自动化迁移，无人机安全同样面临新的审视。我们不禁好奇：人工审计下的成熟防线，遇上新兴的 AI 安全分析，会碰撞出怎样的结果？

为此，我们使用基于国产开源大模型自研的 AI 安全分析系统 deepsec，对某主流消费级无人机进行了一次实战化检验，发现了多个传统人工审计难以覆盖的漏洞，最终实现了对旋翼电机、指示灯、电子围栏等系统底层功能的完全控制（演示视频见文末）。

当黑客在 AI 加持下无差别自动化攻击时，每个行业的固有安全假设都随时可能被颠覆。本次实验也绝非否定无人机厂商已有的防御成果，而是希望通过这次前瞻性测试，提供一个正视 AI 威胁的参照。

其中，eagle2 与 e1e 均采用 AMP 架构：Cortex-A 主核分别运行裁剪版 Android 9 与 Android 6；eagle2 实时核运行云台控制协处理器与 SCP 管理协处理器；e1e 实时核运行飞控协处理器 FMU。主核与协处理器之间通过 ICC 核间通信信道传递 DUML 包，形成 SoC 内部的控制消息通道。

两颗 SoC 间通信则主要依赖 RNDIS（IP-over-USB，192.168.100.0/24）承载 IP 网络服务；以及 USB-Bulk DUML 消息。

外围 MCU 则通过不同总线接入控制体系：eagle2 通过基于串口的 DUML 链路与镜头 / 云台 MCU、系统电源管理 MCU 通信；电机控制 ESC MCU 与 BMS MCU 则直接与飞控协处理器 FMU 通过 FMU 总线进行通信。

无人机本体主要对外暴露3类攻击面：

• 手机侧可通过蓝牙信道向 eagle2 发送 DUML 消息，开启机身 Soft AP。eagle2通过 Soft AP 对外暴露 80 端口 Web 服务与 FTP 服务，承载固件更新包上传、设备日志下载等服务；

• 机身 USB 接口 则直接暴露 USB-bulk 信道下的 DUML 消息发送路径；

• 遥控器通过私有OcuSync 协议与 Pigeon 图传 SoC 通信，形成独立于蓝牙、Soft AP与 USB 的远程图传 / 控制链路。

这三类入口分别覆盖近场无线通信、有线 USB 与私有无线通信，也共同构成了无人机从移动端接入、运维服务到远程控制的主要外部攻击面。

成熟的系统不会只依赖单点防护。该无人机的安全体系同样如此。

• 在用户态防护层面，厂商基于裁剪版 Native Android 部署了自定义 SELinux 策略。新增 28 个 SELinux domain，并配套 service_exec、sec_exec 等自定义 SELinux context，用于约束系统服务、特权组件与普通 Android 域之间的访问边界。

  例如，shell 等 SELinux domain 被禁止直接访问内核 ICC 通道，进而保护用户态进程触达无人机控制消息通道。即使攻击者获取 Android root，由于系统还对 security:setenforce 权限进行了隔离，也无法简单通过 setenforce 0 关闭 SELinux，限制了攻击者获取 root 权限后的能力。

• 固件保护则由 IMaH v2 签名容器、TBIE-AES 固件加密与安全启动签名校验共同完成。各子系统固件被统一封装进 IMaH v2 容器，并使用 TBIE-AES 密钥加密固件明文；设备启动阶段，SoC 基于 RSA-PRAK 体系完成签名校验，确保固件在下发、存储、解密与启动执行链路中保持机密性与完整性。

• 禁飞区及限飞限高约束则是建立了完善的纵深防御，由 e1e 的用户态、TEE、飞控共同对电子围栏进行限制。

电子围栏校验的纵深防御架构

系统通过 nfz.bin 维护电子围栏数据库，并使用 Android 用户态与 TEE 可信执行环境实现双重检查。在 e1e Android 侧，SaNfzMapManager 系统服务会基于当前位置与 nfz.bin 数据库判断当前位置是否位于 zone 内，并通过 SaFlyLimit 下发飞行限制策略；在 TEE 侧，NFZ TA 独立完成禁飞区判定，避免禁飞逻辑完全依赖 Android 用户态结果。最终的飞行限制策略由 FMU 在飞行过程中执行。

同时，NFZ TA 还负责处理由云端 / App 下发的 NFZ 解锁授权。其会使用安全存储中的 HMAC 密钥，对授权包执行 HMAC-SHA256 验签与序列号检查；只有当 license 校验通过时，对应禁飞限制才会被解除。

如此一来，通过将 NFZ 数据判定、解锁授权校验与关键密钥保护从 Android 用户态中剥离出来，即使 e1e 上的 Android 系统被攻击者攻破，也难以直接伪造授权包、篡改解锁状态或绕过禁飞区约束。

DUML 是贯穿整机命令面的顶层协议，各模块通过 DUML 跨传输层通信，底层承载可以是 USB Bulk、Wi-Fi，也可以是蓝牙。

从结构看，DUML 帧由带 CRC8 自校验的消息头、源节点地址、目标节点地址、cmd_set/cmd_id 命令选择子、可变长度载荷以及帧尾 CRC16 构成。

DUML帧格式

系统服务启动时，会结合 /system/etc/ 下 DUML 路由表所分配的监听地址和当前系统状态，动态注册各模块命令表，决定 DUML 消息可触达的命令集合。

mp_state = pro_state();                                  // 读 /proc/cmdline 的 mp_state
if ((mp_state | 1) == 0xF1)                               // v4 ∈ {0xF0 ENG, 0xF1 Factory}
    auth_flag = 255;                               
else if (!system("cat /proc/cmdline | grep androidboot.secure_debug=1")) // secure_debug=1
    auth_flag = 255;                               
else
    auth_flag = 253;


if auth_flag == 253
    // 1) 拿到监听地址
    duss_mb_create_route_table(cfg, "amt_service", "AMT", &host_id, …);
    // 2.a) 注册受限制命令表
    duss_event_create_client(route_table, host_id, &RESTRICTED_TABLE,...);
else 
    duss_mb_create_route_table(cfg, "amt_service", "AMT", &host_id, …);
    // 2.a) 注册完整权限命令表
    duss_event_create_client(route_table, host_id, &FULL_TABLE,...);   

amt_service 依据系统状态注册不同权限命令表

基于 DUML 路由表，来自 /bulk/pc 的外部 DUML 请求可经特定系统服务分发至 eagle2 SoC 上的系统服务，也可通过板间通信继续转发至 e1e SoC 及其他协处理器、MCU 模块。USB 入口由此从单一端点扩展为跨 SoC、跨模块、跨通信域的复杂攻击面。

DUML 路由表规模庞大，响应代码分布在不同芯片与服务进程中

过去人工审计依赖安全研究员对复杂架构的理解、逆向分析与动态测试，需要消耗长达数周、甚至数月的时间才能完成如此复杂系统的梳理。

而在我们 AI 安全分析系统 deepsec 的分析过程中，由于配置了面向复杂嵌入式系统的自动化跨模块探索与语义分析，这一过程被显著压缩。deepsec 在多个通信组件中，识别出多类内存及逻辑安全问题。

其中一类典型问题出现在核心系统服务的消息处理路径中。该类问题的共性在于：消息结构中的长度字段与实际缓冲区操作之间存在不一致，导致在特定条件下可能触发越界写入。这类问题在复杂协议解析与多层封装场景中较为隐蔽，人工审计往往需要逐条路径深入跟踪才能发现。

以 deepsec 发现的一处典型漏洞为例，在处理缓冲区时，错误地混用了未经校验的用户可控字段作为拷贝长度，导致允许长度可控的堆溢出。

heapbuffer = (char *)calloc(input->length1 + 2, 1);
// ...
*(_WORD *)heapbuffer = input->length2 & 0xFFF;
strncpy(heapbuffer + 2, payload, input->length2 & 0xFFF);

导致堆溢出的代码模式示意

另外，deepsec 在其他芯片及协处理器的固件中，发现了多个内存破坏及逻辑漏洞。借助发现的漏洞，我们最终实现了对该设备的完全控制，并绕过了该设备的电子围栏。

跳转微信打开

以下文章来源于：deepsec.cc

Deep Security Closed-door Conference. From Researchers. For Researchers.

跳转微信打开

deepsec @ DARKNAVY

4 月 7 日，AI 巨头 Anthropic 推出 Claude Mythos Preview 后，全球 AI 界、安全社区甚至华尔街迅速进入“Mythos 时刻”。

在科技媒体和安全社区的叙事里，它被形容为“神话降临”、“猛兽出笼”，甚至是“不得不关在笼子里”的具备强大漏洞挖掘和攻击力的网络安全 AI。Anthropic 至今仍未将 Mythos 公开，而是通过“Glasswing 玻璃翼计划”提供给了微软、Linux 基金会、英伟达、纽交所、三星、欧盟网络安全局等近 200 家美国及其盟友的关键厂商、政府和基础设施机构，声称“为防止全球基础设施遭毁灭性攻击”，优先把“最锋利的矛给防守方”。

随后几个月出现的各组数据，更是给每个安全从业者带来了前所未有的认知冲击：

• 4 月中下旬，Microsoft 4月安全相关更新合计达到 247 个 CVE，随后微软宣布计划将 Mythos 集成到内部安全部署环节中；

• 5 月上旬，顶级黑客大赛 Pwn2Own Berlin 站，出现史上首次因漏洞利用报名人数过多，超出主办方赛事处理能力上限的情况；

• 5 月中下旬，Linux 内核单月 CVE 数量超过 1000 个，Copy Fail、Dirty Frag、Fragnesia 等多个AI辅助发现的高危漏洞轮番出场轰炸社区；

• 6 月初，Google Chrome 浏览器的一次稳定版更新修复了 429 个漏洞，超过了 2025 年全年的漏洞总数，其中 22 个被标记为 Critical……

Mythos 让更多人看到，AI 安全攻防已经从单纯的漏洞扫描逐步走向真实目标的完整攻击。过去需要数天、周、甚至月来达成的漏洞攻击任务，正在被 AI 以小时为单位来完成。攻击者的成本，也在前所未有地下降。

一方面，对于高价值目标，攻击者可以显著缩短研究周期；另一方面，过去被认为不值得黑客投入的中小目标，也可能因为 AI 的高度自动化而被降维打击。

相较之下，很多企业的防守体系仍停留在上一代节奏，依靠人力发现和修复漏洞。Mythos 已被 Anthropic 选择性地提供给一些关键基础设施企业和政府机构，用于提前发现和修复安全问题，然而，全世界更多没能进入 Glasswing 名单的企业和机构，正暴露在 AI 驱动的全天候攻击压力之下，即便能够接入 Mythos ，其公开价格也相当高昂（$25/百万输入，$125/百万输出）。

DARKNAVY 对 Mythos 的态度不是轻率对战，而是认真研判和追赶。我们首先提出的问题是：

开源大模型和 Mythos 的差距，究竟在哪里？

由于 Mythos 尚未公开发布，我们无法直接进行完整对比，只能对其官方公开声称发现的部分漏洞进行受控实验。

我们首先收集了 Mythos 找到的部分漏洞，对相关代码上下文进行人工切片和拼接，在关闭联网搜索功能的前提下，分别发送给 DeepSeek 等开源模型进行分析。结果显示，在充分的上下文（Context）和合理的提示（Prompt）下，前沿开源模型已经能够识别出绝大多数 Mythos 找到的漏洞。

然而，如果把相应的代码仓库直接交给这些开源模型，在 Claude Code、OpenCode 等通用 agent 框架下自由分析，结果通常极不稳定。模型可能会在无关路径上消耗大量 Token，也可能过早收敛到错误假设，还可能给出看似合理但无法验证的结论。

考虑到实验中存在人为介入的 Context 切分和 Prompt 构建，这一结果显然不意味着开源模型能力已经追平 Mythos。但它至少说明：前沿开源模型并非不具备发现相应漏洞所需的安全知识，而是缺乏把这些知识组织成有效探索行为的外部系统。

我们后续的系统建设进一步表明，当系统能够提供干净的上下文、合理的搜索边界、逐步收敛的任务结构，以及可执行的验证反馈时，模型的能力会明显提升。它不再局限于阅读代码并生成分析文本，而是开始围绕攻击面、可达性、触发条件和验证证据进行思考和探索。

这也形成了我们的基本判断：模型能力只是起点，真实攻防工作流决定了这种能力能否转化为有效结果。

为了让开源模型追赶 Mythos 级别的漏洞研究能力，我们在 deepsec 的研制构建中重点做了三件事。

我们将 DARKNAVY 多年积累的服务于客户如华为、微信、大疆、苹果、小米、支付宝、字节、vivo、谷歌、OPPO 等行业巨头的安全研究技术和真实攻防案例，整理为更适合 AI 按需调用的结构化安全研究经验。

知识库中包含漏洞模式、触发条件、常见误判、验证方法、利用约束、补丁绕过思路，以及不同平台和不同代码生态中的经验差异。

对于 AI 安全系统而言，知识库的价值不只是提供背景资料，更重要的是对探索空间进行剪枝。一个有效的安全知识库，可以帮助模型更快判断哪些路径值得继续分析，哪些现象只是误报噪音，以及在有限预算下如何更快找到值得研究的方向。

deepsec 需要让 Agent 像安全研究员一样工作，也就是将漏洞研究分解为一系列连续决策。

我们观察到，AI 训练材料中有大量漏洞利用成功后的 Write-up，却相对缺少顶级安全研究员在 work and trial 过程中的“失败”知识。真正有价值的经验，往往不只在最终结果里，也在中间过程里：哪些路径看过以后被放弃，哪些异常被排除，哪些利用假设失败，哪些信号让研究员决定继续深入。

因此，从今年初开始，我们在经过授权的内部研究目标场景中部署了 AI 自动记录系统，用于记录团队成员安全研究过程中的关键行为。

我们希望通过这种方式，让模型不只是学习漏洞最后长什么样，也学习安全研究员如何接近漏洞。

deepsec 不是固定 Prompt，也不是静态工作流。它是一套可持续演化的 Agent 架构。

一方面，系统会不断总结成功和失败路径，更新任务拆解方式、上下文选择策略、工具调用顺序、验证优先级和结果判定标准；另一方面，人类专家可以持续把新的知识、样本和研究经验输入系统，让系统在后续任务中吸收和复用。

同时，我们构建了专用的 PoC Agent 平台，用于在多平台的虚拟化及真实设备上的自动 PoC 生成与验证闭环。目前平台已经接入 Linux、Android、HarmonyOS 和 iOS 运行环境，可以动态添加和分配测试设备，让 AI 自动编写 PoC、执行验证、分析日志，并根据运行结果迭代修正。

PoC Agent 平台（上图）在 Linux 运行环境（下图）中

自动化验证漏洞^[3]，触发内核崩溃

作为长期在攻防对抗最前沿工作的团队，DARKNAVY 在内部评估 deepsec 产品时，最关注的是漏洞产出质量。

1 个真实可利用的高品相漏洞或利用链，往往比 100 个实际难以或不可利用的漏洞更值得优先修复。

以下是截止目前 deepsec 真实实践中可公开披露或部分披露的代表性成果：

• CVE-2025-37891：首个由 AI 自动发现的 Linux 内核本地提权漏洞。由 deepsec 前身 Argusee 发现，相关细节可参考 2025 年 5 月 DARKNAVY 公众号文章；

• CVE-2026-3195：首个由 AI 自动发现的 QEMU 虚拟机逃逸漏洞，已获得 RedHat 官方确认及致谢^[2]；

• CVE-2026-????：首个由 AI 自动发现的 Ubuntu 26.04 本地提权漏洞，整套攻击于该版本发布后12小时内完成，多位内核开发者及其他安全研究团队历时1个月讨论仍未完全修复^[3]；

• CVE-2026-20698：首个由 AI 自动发现的 XNU 内核内存破坏漏洞，影响近5年所有 iOS 和 macOS 系统，已获得 Apple 官方确认及致谢^[4]；

• CVE-2026-28847：首个由 AI 自动发现的 Safari JavaScriptCore 远程代码执行漏洞，已获得 Apple 官方确认及致谢^[5,6]；

• CVE-2026-????：首个由 AI 自动发现的 Android 本地提权漏洞，该漏洞已在三星最新旗舰手机 S26 Exynos 版本上实现全球首次 Root，暂未公开披露。

以上部分成果覆盖虚拟化基础设施、操作系统内核、终端浏览器、旗舰移动智能设备、桌面操作系统等多类高价值目标。以前，这些漏洞往往需要高级安全研究员花费大量精力才能发现和验证，而在 deepsec 中，我们只需要在初始化页面输入：

系统便可以自动完成这些安全研究任务。

由于这些漏洞产出时 Mythos 仍然处于封闭测试阶段，我们无法客观评估其能否在同样设置下发现这些高危漏洞。但我们相信，这些案例至少说明：deepsec + 国产开源大模型，已经具备追赶 Mythos 级漏洞研究能力的现实基础。依托 deepsec，我们也在与合作伙伴积极推进内部安全建设。

在预算成本方面，基于开源大模型的 deepsec 具备显著优势。例如，我们曾使用 deepsec 分析某知名手机厂商固件，除了发现多个高危漏洞之外，还统计了过程中的 Token 用量。结果显示，即便保守假设 Mythos 在发现相同漏洞时所需的 Token 用量仅为 deepsec 系统的一半，按 Mythos 已公开价格口径粗略折算，其 Token 成本仍超出 deepsec 上百倍。

根据以上评估结果，DARKNAVY 认为至少在安全漏洞挖掘领域，当 Harness 足够高效时，开源模型的成本优势会被显著放大。

deepsec 是 DARKNAVY 基于开源大模型底座，对 Mythos 级安全 AI 能力的一次追赶。

它还在持续演化，也仍然有很多问题需要解决。但从目前实验和成果看，我们相信，安全研究员完全有机会把开源大模型、真实攻防经验和自动验证系统结合起来，形成面向高价值目标的安全 AI 能力。

deepsec 研究预览版（https://deepsec.darknavy.net 或点击“阅读原文”）将于七月中旬上线，目前已开放试用申请（扫描下方二维码），研究预览版将重点开放以下能力：

• 源码目标的自动漏洞研究；

• 源码目标的 diff 分析与自动补丁；

• ELF、PE、MACH-O 等常见二进制目标的自动漏洞研究；

• APK、HAP 等常见移动端应用程序的自动漏洞研究；

• Linux、Android、HarmonyOS 和 iOS 环境的 PoC 自动生成与验证。

我们希望 deepsec 不仅仅停留在研究阶段，而是成为一套能够保护真实世界的安全 AI 系统。

也希望它成为我们向 Mythos 追赶、向国产开源大模型致敬的一次认真回答。

参  考：

[1] https://securityaffairs.com/193234/ai/report-anthropic-deploys-engineers-to-support-nsa-use-of-mythos.html

[2] https://access.redhat.com/security/cve/cve-2026-3195

[3] https://lore.kernel.org/all/20260604191916.1713387-1-simona.vetter@ffwll.ch/

[4] https://support.apple.com/en-us/126792

[5] https://support.apple.com/en-me/127121

[6] https://www.zerodayinitiative.com/advisories/ZDI-26-313/

DARKNAVY 2026 暑期实习招募开启

AI / 芯片 / 具身 / IoT / 操作系统 / 运营

以及更多还没被定义的领域……

这里不教你做事的标准答案

只给你冲破迷雾、探索未知的机会

独立、自由、开放，深蓝邀你同行

📩 简历投递：CoD@DARKNAVY.com

阅读原文

跳转微信打开

对三款最强 AI Coding Agent的漏洞攻破挑战

2025 年 5 月，DARKNAVY 内部自研的 AI Agent 发现了首个公开披露的 Linux 内核可利用 0day 漏洞。彼时，AI 已经开始进入高阶安全研究流程，但它更多仍是人类研究员手中的工具，需要在专业指导之下发挥作用。

一年之间，AI 在安全研究领域的能力快速跃升，从 Anthropic 的 Claude Mythos Preview，到 OpenAI 的 Codex Security，AI 在漏洞发现、漏洞验证乃至补丁生成中，已经能完成相当一部分过去需要安全研究员手动处理的工作。进入 2026 年后，研究员不再逐行审计代码，而是通过简单的任务描述，将大部分搜索、分析和验证过程交给 AI 完成。AI 正在从辅助工具变成安全研究的直接参与者，甚至开始被认为可能取代人类安全研究员。

于是，一个更尖锐的问题随之出现：当 AI 开始替代人类黑客去发现漏洞时，AI 自己是否经得起同样的安全检验？

这一次，DARKNAVY 选择反过来挑战 AI 厂商最核心、也最具代表性的产品形态：AI Coding Agent。我们选择了 Claude Code、OpenAI Codex 和 Cursor 作为研究对象，它们是当下最受关注的 AI 编程助手，能够读取项目文件、理解代码上下文、访问网络、调用工具、执行命令，与开发者的真实工作环境深度绑定。

DARKNAVY 团队近期对这三款 AI Coding Agent 进行了系统性的攻防测试。结果是，在空白项目、默认配置、无需任何额外用户批准的最简前提下，三者均被成功攻破。

在 AI Coding Agent 的实际使用中，针对它们的攻击可以粗略分为两类。

用户从不可信来源获取了一个被精心构造的项目，例如 GitHub 仓库、社群分享、邮件附件或钓鱼链接，并使用 AI Coding Agent 打开它。在用户尚未明确授权信任当前工作区之前，本地环境就已经被攻陷。

这一类攻击的本质，是利用 Agent 在项目加载和初始化阶段的逻辑缺陷。DARKNAVY 此前在 OpenAI Codex 桌面端发现的零授权代码执行漏洞，就属于这一类问题。

不过，这类攻击的防御责任目前处于厂商和用户之间的模糊地带。常见的 AI Coding Agents 并未提供面向恶意项目威胁的充分防护，而是默认将风险转嫁给用户：打开任何文件夹之前，用户需自行确认其中内容是否安全。在我们的测试中，通过打开恶意项目实现未授权代码执行的路径非常多，技术门槛并不高。在厂商将此类场景纳入自身安全边界之前，本文不展开讨论。

用户在自己长期维护、完全信任的项目目录中工作，Coding Agent 也运行在用户已经授权的环境内。在这个过程中，用户出于正常开发需求，让 Agent 访问某些外部资源。它可能是一份开发文档、一个依赖包、一个 issue、一段网页内容，或任何看起来与当前任务相关的网络信息。

就在这一刻，Agent 被诱导执行了恶意操作，并且绕过了 Coding Agent 内置的多层安全检查，最终导致用户电脑被攻陷。

这正是我们这次真正关心的场景，也是文章开头三段视频所演示的场景。在这个场景里，用户并没有做错任何事情。他只是在自己信任的项目中，让 AI 自己学习一份资料，理解一段代码，或者完成一次正常的开发任务。

也就是说，用户对 Agent 的每一次信任，都可能被攻击者转化为新的入口。

在 AI Agent 安全的讨论中，提示注入（Prompt Injection）几乎成了一个被滥用的术语。一听到 Agent 被攻破，很多人会自动归因为又是一次 Prompt Injection。

然而，在我们这次研究的攻击链中发现，Prompt Injection 并不是最关键的环节。它最多只是让模型产生某种行为意图，而真正决定攻击是否能够落地的，是工具执行层的安全边界是否有效。

要理解这一点，需要先明确一个基础事实：现代 AI Coding Agent 通常都内置了多层安全机制。以 Claude Code 为例，其官方文档[1]描述了一种 permission-based architecture。只读类操作可以默认允许，但凡涉及文件修改、测试运行、命令执行等敏感动作，都需要经过独立的权限校验和用户确认。

因此，真正可控的安全边界，并不在于模型被说服了什么，而在于执行层是否真的能够拦截危险操作。

模型可以决定它想做什么，但敏感工具的实际执行，尤其是 bash 命令执行，应该当由权限检查、沙箱隔离或者二者组合来强制约束。无论具体实现如何，它都应该是确定性的代码逻辑，而不是依赖模型自觉遵守规则。

为了更直观地说明这一点，我们做了一组对比演示。

• 左侧窗口中，我们直接要求 Agent 执行一个敏感命令，例如打开计算器。此时，Agent 按照预期被安全机制拦截，或者弹出确认窗口，要求用户明确批准。

• 右侧窗口中，我们通过构造输入，触发相关漏洞，让 Agent 最终执行同样的敏感行为。不同的是，整个过程中没有任何弹窗，没有任何用户批准，敏感命令被直接静默执行。

左：敏感命令需要用户授权  右：利用漏洞构造输入绕过用户授权

两个窗口里 Agent 的最终行为完全相同，但一个被安全机制拦截，一个执行成功。这之间的差别，问题不只是 Prompt Injection，而是 Prompt Injection 之后，原本应该作为最后防线的执行安全边界被穿透了。

这才是我们这次研究真正想揭示的问题。

三款 Agent 在工具执行这一层有着不同的侧重：Claude Code 依赖权限检查作为主要防线，默认不启用沙箱；Codex 和 Cursor 则以沙箱作为最终兜底。接下来，我们将分析这两套机制的实现原理和薄弱点。

Claude Code 默认不启用沙箱，其工具执行的安全完全依赖于一套权限检查系统——敏感命令在执行前必须经过权限校验或弹窗确认。

从实现上看，Claude Code 在执行 Bash 工具调用前，会先对要执行的命令字符串进行静态解析，尝试从用户输入中识别出将要执行的可执行文件及其参数，并根据解析结果判断该命令是否需要用户授权。默认情况下，只有被判定为“安全”的只读命令，才能在无需用户确认的情况下直接执行；其他命令，都应进入用户授权流程。

首先，Claude Code 会检查命令中是否包含危险操作、特殊语法或高风险模式。例如，某些重定向、管道、命令替换等模式可能会被识别为敏感行为，从而要求用户显式授权后才能执行：

const COMMAND_SUBSTITUTION_PATTERNS = [
  { pattern: /<\(/, message: 'process substitution <()' },
  { pattern: />\(/, message: 'process substitution >()' },
  { pattern: /=\(/, message: 'Zsh process substitution =()' },
  { pattern: /(?:^|[\s;&|])=[a-zA-Z_]/, message: 'Zsh equals expansion (=cmd)' },
  { pattern: /\$\(/, message: '$() command substitution' },
  { pattern: /\$\{/, message: '${} parameter substitution' },
  { pattern: /\$\[/, message: '$[] legacy arithmetic expansion' },
  { pattern: /~\[/, message: 'Zsh-style parameter expansion' },
  { pattern: /\(e:/, message: 'Zsh-style glob qualifiers' },
  { pattern: /\(\+/, message: 'Zsh glob qualifier with command execution' },
  { pattern: /\}\s*always\s*\{/, message: 'Zsh always block (try/always construct)' },
  { pattern: /<#/, message: 'PowerShell comment syntax' },
]

此外，如果命令字符串中包含控制字符，Claude Code 也会将其视为不安全输入，并要求用户授权。这类检查通常用于防止攻击者通过不可见字符、终端控制序列或其他非打印字符隐藏真实命令意图，从而绕过基于字符串的安全判断：

if (CONTROL_CHAR_RE.test(command)) {
  logEvent('tengu_bash_security_check_triggered', {
    checkId: BASH_SECURITY_CHECK_IDS.CONTROL_CHARACTERS,
  })
  return {
    behavior: 'ask',
    message:
      'Command contains non-printable control characters that could be used to bypass security checks',
    isBashSecurityCheckForMisparsing: true,
  }
}

在确认命令中不包含上述危险元素之后，Claude Code 会进一步判断该命令是否仅执行只读操作。为此，它维护了一组只读命令及其允许参数的白名单。只有当命令名称位于白名单中，并且其参数也完全符合对应命令的允许范围时，该命令才会被视为只读。

例如，对于 base64 这类命令，Claude Code 并不会简单地允许任意参数组合，而是只允许例如控制解码模式或输出格式的部分选项：

base64: {
  respectsDoubleDash: false, // macOS base64 does not respect POSIX --
  safeFlags: {
    // Safe decode options
    '-d': 'none', // Decode
    '-D': 'none', // Decode (macOS)
    '--decode': 'none', // Decode


    // Safe formatting options
    '-b': 'number', // Break lines at num (macOS)
    '--break': 'number', // Break lines at num (macOS)
    '-w': 'number', // Wrap lines at COLS (Linux)
    '--wrap': 'number', // Wrap lines at COLS (Linux)


    // Safe input options (read from file, not write)
    '-i': 'string', // Input file (safe for reading)
    '--input': 'string', // Input file (safe for reading)


    // Safe misc options
    '--ignore-garbage': 'none', // Ignore non-alphabet chars when decoding (Linux)
    '-h': 'none', // Help
    '--help': 'none', // Help
    '--version': 'none', // Version
  },
}

这种设计的安全边界建立在一个前提之上：权限检查阶段解析出的命令名称和参数，必须与实际执行阶段 Shell 最终解释并运行的内容保持一致。一旦两者之间存在语义差异，就可能产生权限绕过风险。

例如在 Claude Code < v2.1.132 的版本中，我们发现权限检查逻辑并未识别 Zsh 中的 $= 参数展开语法。

Claude Code 会调用系统默认 Shell 执行 Bash 工具中的命令。在 macOS 环境下，默认 Shell 通常是 Zsh。Zsh 的 $= 语法会对变量展开后的结果再做一次无视引号的参数拆分：如果变量包含空格，$=var 不会作为单个参数传入，而是被拆成多个独立参数。

这就在权限检查和实际执行之间制造了语义差异：Claude Code 基于原始命令字符串做静态匹配，看到的是一个参数；而 Zsh 实际执行时拆出的是多个参数。攻击者可以把不安全的内容藏在变量里，让权限检查阶段看起来仍然符合只读命令的白名单。

以 uniq 命令为例。Claude Code 使用如下正则判断 uniq 是否属于可无授权执行的安全只读命令：

而一个完整的uniq命令语法如下：

uniq [-cdiu] [-D[septype]] [-f num] [-s chars] [input_file [output_file]]

可以看到，Claude Code 的白名单正则只允许部分安全选项，例如用于控制比较行为、跳过字段或跳过字符数量的参数，并不允许用户显式指定输入文件和输出文件。

由于旧版本没有处理 Zsh 的 $= 展开语义，攻击者可以构造如下形式的命令：uniq --skip-chars="1$=A"，这条命令会被 Claude Code 视为对 uniq 的一次普通参数调用，并在无需用户授权的情况下执行。

但在 Zsh 的真实执行阶段，如果变量 A 的值为：A=' 1.txt 2.txt'，那么 $=A 触发参数拆分后，使最终执行的命令等价于：uniq --skip-chars=1 1.txt 2.txt。Claude Code 对实际执行的内容误判，导致了最终对文件 2.txt 的非预期写入。

通过设置 $HOME/.claude/settings.json 为 uniq 的写入目标，可以在用户无授权的情况下修改 Claude Code 的配置文件，并实现命令执行。

使用上述漏洞绕过 Claude Code 的命令权限检查

该漏洞已在 v2.1.132 进行了修复，新版本在检测到相关 Zsh 参数展开语法时，会将命令识别为高风险输入，并提示：zsh $+/$^/$=/$~ prefix-flag expansion — value defeats downstream content checks，需要用户授权后才能执行。

Codex 和 Cursor 的工具执行默认运行在一个受限的沙箱环境中，理论上即便 Agent 被诱导执行恶意命令，也会被沙箱限制在一个隔离的执行域内。

Codex 和 Cursor 并没有采用虚拟机或容器级别的完整隔离方案，而是复用了不同操作系统自身的访问控制机制，并在此基础上使用基于文件路径和网络等规则的策略。例如在 macOS 上，这两个 AI Agent 均使用了 Apple Seatbelt 运行时沙箱，通过动态生成配置文本的方式，限制工具进程的文件系统、网络和进程相关权限。

在工具执行前，AI Agent 会基于一套默认沙箱规则，并结合用户配置、当前工作目录以及工具调用所需的权限，动态生成最终的运行时访问策略。以 Codex 为例，其默认沙箱规则会允许程序正常启动和执行，同时放行对部分系统目录、系统库以及运行时依赖文件的访问，以保证常见命令和开发工具能够在沙箱内正常运行：

(deny default)


; child processes inherit the policy of their parent
(allow process-exec)
(allow process-fork)
(allow signal (target same-sandbox))


; process-info
(allow process-info* (target same-sandbox))


; ......
(allow file-read* file-write* file-ioctl (literal "/dev/ptmx"))
(allow file-read* file-write*
  (require-all
    (regex #"^/dev/ttys[0-9]+")
    (extension "com.apple.sandbox.pty")))
; ......

随后，在默认配置下，Codex 会进一步放行当前项目目录以及临时目录中的写入操作。这样设计的目的是让 Agent 可以在沙箱中完成代码修改、构建产物生成等常见开发任务：

let mut entries = vec![
  FileSystemSandboxEntry {
    path: FileSystemPath::Special {
      value: FileSystemSpecialPath::Root,
    },
    access: FileSystemAccessMode::Read,
  },
  FileSystemSandboxEntry {
    path: FileSystemPath::Special {
      value: FileSystemSpecialPath::project_roots(/*subpath*/ None),
    },
    access: FileSystemAccessMode::Write,
  },
];

与此同时，Codex 也会对当前目录下的一些敏感元数据目录设置更严格的访问策略。例如，对于 .git、配置目录、依赖管理元数据或其他可能影响项目状态与供应链安全的路径，沙箱策略会将其限制为只读。这样可以在允许 Agent 修改项目代码的同时，降低其篡改版本历史、Git 配置等的风险：

const PROTECTED_METADATA_GIT_PATH_NAME: &str = ".git";
const PROTECTED_METADATA_AGENTS_PATH_NAME: &str = ".agents";
const PROTECTED_METADATA_CODEX_PATH_NAME: &str = ".codex";

整体来看，这类沙箱并不是一个完全独立的执行环境，而是一个基于宿主操作系统访问控制能力构建的“受限进程环境”。它的安全性高度依赖动态生成的策略是否完整、路径匹配是否准确、黑白名单边界是否清晰，以及工具执行框架是否始终确保命令在预期的沙箱配置下运行。一旦策略生成、路径解析或权限豁免逻辑中存在偏差，攻击者就可能利用这些差异突破 Agent 设计者预期的隔离边界。

例如，在 Codex < v0.126.0 的版本中，我们发现 Codex 只有在当前工作目录本身已经存在.git 目录时，才会将其识别为需要特殊保护的 Git 元数据目录，并对其访问进行限制。

let top_level_git = writable_root.join(PROTECTED_METADATA_GIT_PATH_NAME);
// This applies to typical repos (directory .git), worktrees/submodules
// (file .git with gitdir pointer), and bare repos when the gitdir is the
// writable root itself.
let top_level_git_is_file = top_level_git.as_path().is_file();
let top_level_git_is_dir = top_level_git.as_path().is_dir();
let should_protect_top_level = top_level_git_is_dir || top_level_git_is_file;
if should_protect_top_level {
  if top_level_git_is_file
    && is_git_pointer_file(&top_level_git)
    && let Some(gitdir) = resolve_gitdir_from_file(&top_level_git)
  {
    subpaths.push(gitdir);
  }
  subpaths.push(top_level_git);
}

如果当前工作目录在执行命令前不存在.git，Codex 便不会提前对 Git 元数据路径建立只读的沙箱规则。此时，攻击者可以先通过沙箱内的工具执行，在当前目录下创建一个伪造的 .git 目录，并进一步写入恶意的 Git hooks。

这一点破坏了 Codex 沙箱模型中的关键假设。Codex 每次在对话过程中会在沙箱外执行 Git 相关操作，这些操作使用了受限沙箱内的配置文件，因此对应的 hooks 能够在沙箱外执行任意命令。

使用上述漏洞在 Codex 沙箱外执行命令

该漏洞已在 v0.126.0 进行了修复，即使工作目录不存在.git，也会在沙箱规则中将其默认设置为只读，不再能通过这种方式进行沙箱外的命令执行。

总而言之，权限检查与沙箱，是当代 Coding Agent 在工具执行层的两种主要防御范式。我们的研究表明，这两种范式在实现层面都存在可被穿透的缺陷，一旦构造出可触发的输入，权限绕过或沙箱逃逸的执行就是确定性的。这类漏洞和过去二十年在浏览器、操作系统、虚拟化环境中反复出现的经典缺陷本质相同，只是Agent 的出现让它在一个新的场景里被重新放大。

需要说明的是，除了本文披露的问题之外，我们针对这三款 Coding Agent 还发现了若干其他漏洞，文章开头视频中演示的完整攻击链正是基于这些漏洞构造。相关问题仍在与厂商的负责人披露流程中，尚未完成修复，本文暂不公开技术细节，待修复完成后再行公开。

我们有理由相信：本文涉及的这些模型厂商自研的 AI Coding Agent，在发布之前，很可能已经接受过它们内部最先进的 AI 安全审查。

也正因为如此，这次研究才更值得被讨论：当 AI 开始取代人类黑客的工作，AI 系统自身是否仍然需要接受人类黑客的真实对抗？

我们的回答是：需要，而且必须。

AI 更擅长的，是在已知代码库、漏洞模式和攻击面上进行自动化、规模化覆盖。但真正突破性的安全研究，往往诞生于未知的边界：攻击者可能会用系统设计者从未预料的方式，将多个看似无害的组件、权限和信任关系串联起来，形成一条新的攻击链。这是当前 AI 仍然难以完全替代人类研究员的部分。

或许有一天，AI 也能完成这种创造性的对抗推演。但在那之前，AI 自身的安全，仍然需要人类黑客作为最后一道检验。

AI 正在改变黑客。但至少现在，黑客仍然可以改变 AI。

本文相关漏洞在官方修复发布前，恕不公开任何具体技术细节。

AI 干掉黑客，还是黑客干掉 AI？

我们从未停止好奇，如果有一天 AI 终将失控，

黑客会是最后一道防线吗？

10.24 上海西岸

GEEKCON 2026

邀您一起寻找答案

参  考：

[1] https://code.claude.com/docs/en/security#permission-based-architecture

[2] https://developers.openai.com/codex/agent-approvals-security

[3] https://cursor.com/docs/agent/security

跳转微信打开

风险从数字走向物理，重新审视真实环境下的安全体系建设

随着具身智能进入现实世界，AI智能体获得了物理实体与自主执行能力。与此同时，数字领域的安全缺陷，正开始跨越虚实边界，转化为可作用于现实环境的物理风险。

在DARKNAVY以攻击者视角开展的模拟测试中，多台市面在售的知名品牌具身智能机器人，从获取设备、识别漏洞到实现完全控制，整体攻击周期不足8小时。这一数据表明，当前具身智能能力快速演进的同时，安全体系建设仍明显滞后。

基于长期攻防研究与实证分析，DARKNAVY 联合 CIIPA 关键信息基础设施安全保护联盟、数说安全正式发布《具身智能安全技术白皮书：机器人篇》。

作为具身智能系列安全白皮书的首篇，本白皮书围绕机器人场景，首次对具身智能系统的攻击面、风险传导链路与评估框架进行了系统性梳理。

相较于传统智能终端，具身智能系统的攻击面更广，风险传播路径也更为复杂。然而，根据白皮书对当前国内主流产品的调研结果，其安全能力尚未达到早期智能终端与物联网设备的基础防护水位。行业已经开始形成安全意识，但系统化能力建设仍处于起步阶段。

具身智能系统具备感知-决策-执行的闭环特征。白皮书对其典型关键架构进行了系统性拆解，从而帮助还原真实攻击路径，分析威胁如何突破控制平面、干扰感知输入、影响决策过程，并最终作用于底层执行单元。

针对日益突出的物理现实风险，白皮书第三章首次提出具身智能机器人风险评估的基础参考框架，并正式发布 《RoboSec Top 10 ：具身智能机器人十大关键风险清单》，覆盖端侧内部权限、云端控制平面、感知与决策层欺骗、AI 资产完整性等关键环节，为行业建立风险评估框架与安全基线提供参考。

当具身智能系统的能力从信息处理延伸至物理执行，安全治理的对象与边界也随之改变。数字世界中的单点缺陷，可能沿着跨层级、跨组件的链路被持续放大，最终演化为现实场景中的失控后果。也正因此，具身智能机器人的安全能力应前置到系统架构设计阶段，成为与感知、决策、执行同等重要的基础能力。

本白皮书希望通过对关键风险、攻击路径与防护重点的系统梳理，为行业开展风险识别、能力建设与体系化防护提供参考。

《具身智能安全技术白皮书：机器人篇》现正式发布。

关注本公众号，后台回复关键词 “具身智能” 或 “白皮书”，即可获取完整版 PDF。

跳转微信打开

以下文章来源于：GEEKCON

GeekPwn革新升级，DARKNAVY旗下创新前沿、自由中立的国际黑客技术平台，开创和推动安全能力可感知、价值可度量。

跳转微信打开

DARKNAVY 近日发现并报告了 OpenAI Codex 桌面端中一处严重的未授权代码执行漏洞。该漏洞绕过了 Codex 的默认权限限制，攻击者仅需诱导用户打开恶意构造的代码仓库/文件夹，即可在无需用户任何授权的情况下静默触发代码执行。该漏洞目前尚未修复，且社区已出现第三方复现案例，建议广大开发者与企业用户保持警惕，切勿随意打开未确认来源的代码仓库，以防源码等关键数据资产泄露。

随着 Vibe Coding 时代的到来，OpenAI Codex、Claude Code 等 AI Coding Agent 凭借其强大的自动化编程能力，已成为众多开发者高频使用的生产力工具。据 OpenAI 官方数据披露，Codex 的周活跃用户数已突破 200 万^[1]。然而，伴随其市场渗透率的上升，此类 Agent 工具的自身安全机制正面临严峻挑战。 

在近期公布的全球顶级黑客大赛 Pwn2Own 2026 规则中，首度增设了“Coding Agent”挑战类别，覆盖 Codex、Claude Code、Cursor 主流工具^[2]。官方明确指出，攻击场景包含“通过与攻击者控制的网页、代码仓库或媒体文件交互以实现漏洞利用”，并为此类目标设立了数万美元的漏洞利用奖金。这一举措标志着 Coding Agent 的安全威胁已引起国际安全社区的高度关注。 

Pwn2Own Berlin 2026 Coding Agent Category Targets

基于对AI安全的攻防实战和多年前沿安全对抗经验，DARKNAVY 团队在 OpenAI Codex 桌面应用中发现了一处高危漏洞。该漏洞的危险之处在于，它打破了当前 AI Agent 应用的安全预期：

• 安全机制绕过： 在 Codex 的默认权限（Default Permission）模型下，任何涉及本地命令执行的操作，通常都会触发系统弹窗并经过用户的明确点击允许。然而，该漏洞能够完全绕过这一核心安全防御机制。

• 零授权触发： 用户无需执行任何危险操作，仅仅是执行“打开文件夹”或“加载代码项目”这些最常规的日常开发动作，恶意代码便会在后台静默执行。整个过程没有任何“允许执行”的授权提示，用户处于完全无感知的状态。

• 漏洞状态： 截至本预警发布前，DARKNAVY 已确认 OpenAI Codex 的最新版本 26.313.41514 (1043) 仍存在该漏洞，官方尚未发布修复补丁。

鉴于该漏洞攻击门槛极低且受众基数庞大，DARKNAVY 特此发布安全预警。在官方发布正式修复补丁前，建议所有 Vibe Coding 开发者采取以下临时防护措施：

1. 谨慎审查外部项目： 在使用 Codex 等 AI 编程助手打开未知来源或不受信任的第三方开源仓库、文件夹前，务必在安全环境中进行审查。

2. 警惕社工钓鱼： 警惕通过邮件、社群分享等渠道传播的不明工程文件。

回顾行业现状，同类产品 Claude Code 此前也曾被海外安全团队披露过类似的用户未授权代码执行漏洞。Anthropic 官方最终将其评定为高危（CVSS 8.7 HIGH）并分配了 CVE-2025-59536 编号^[3]。 截至目前，OpenAI 团队尚未对 DARKNAVY 提交的漏洞报告及演示作出回应。颇具讽刺意味的是，OpenAI 不久前刚刚公开宣称利用其“Codex Security”能力挖掘了上万个高危漏洞（high-severity findings）^[4]。作为AI在安全领域应用的主要推进者，为何未能将同等防护能力有效反哺于自身的核心产品，或许值得深思。

参  考：

[1] https://x.com/fidjissimo/status/2033537381907710092 

[2] https://www.zerodayinitiative.com/Pwn2OwnBerlin2026Rules.html 

[3] https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/ 

[4] https://openai.com/index/codex-security-now-in-research-preview/

跳转微信打开

当手机开始自己“动手”，它就不再只是回答怎么点外卖更划算，而是会真的打开 App、比价、下单。操作权从人的手指，交给了一个能看屏、能规划、能执行的智能体。

2025 年底推出的豆包手机助手（以下简称豆包助手），第一次把整个手机的完整操作链条交到了智能体手里：它以大语言模型作为中枢决策单元，结合 GUI Agent 技术，从用户目标出发进行意图理解、任务拆解与路径规划，并以系统级的能力完成跨应用、跨场景的复杂任务执行。

但 AI 与手机的结合，也让它同时站在两类风险的交汇处：既要应对传统手机安全问题，也要面对智能体带来的新攻击场景。攻击者不必再费力诱导用户多点几步，只需要把智能体的规划引向错误方向，就可能让一串看起来正常的操作变成窃取用户信息的攻击链。

DARKNAVY 在评估中发现，豆包助手在安全与隐私方面做了大量考量，但仍存在可被利用的真实风险：攻击者可能在用户正常使用的过程中，通过发送恶意信息误导并劫持智能体，进而窃取手机银行验证码等敏感信息。

本文将围绕豆包助手的技术实现路径、安全及隐私考量、潜在安全风险展开进一步讨论。

Obric 是豆包手机搭载的基于Android的定制操作系统，其 AI 相关功能由一组系统级应用构成，覆盖语音交互、记忆管理、模型推理、自动操作等关键能力模块。从职责划分来看，各核心应用的功能边界较为清晰：

• ObricAiAgent：豆包助手应用主体。主进程负责能力调度、任务编排等核心业务逻辑；子进程集中处理唤醒、声纹识别及相关 UI。

• ObricAutoAction：豆包助手自动操作模块，承载自动化任务的核心业务逻辑，负责将用户意图转化为可执行的操作序列并执行。

• AIKernel：端侧模型与推理基础设施，提供统一的模型加载、调度与推理能力。

• MemoryData：记忆管理模块，用于持久化与检索用户相关的长期与短期记忆。

• AIVoiceService：语音相关能力模块，涵盖语音识别、语音合成及信号处理能力。

在上述组件中，ObricAutoAction 是实现“豆包助手自动操作”能力的关键模块。分析结果显示：业务流程上看，一条用户输入的自动化任务在进入业务层后，会被封装为一个 AutoOperateTask，随后自顶向下经过如下执行链路：

AutoOperateTask → AOSession → AOAgent / AOStep → Action / Operation

以用户在豆包助手聊天框中输入“打开百度地图，导航到佘山”为例，其推理与执行流程如下图所示。在向模型发起推理请求之前，豆包助手会截取当前手机屏幕。模型输入为此截图与一组附带信息，包括基础上下文、设备与系统参数、位置信息，以及版本与扩展字段等。模型返回的结果将用于描述下一步应执行的动作指令，例如打开目标应用。

在每一步操作执行完成后，智能体都会再次截图，并对当前任务状态进行判断：若任务尚未完成，则再次携带最新屏幕状态向云端请求推理结果，获取下一步操作指示。通过这种“感知—推理—执行”的循环，整体任务被逐步规划并完成：打开百度地图、在搜索框中输入“佘山”、点击“搜索”、请求用户澄清具体的导航目标（如佘山地铁站或佘山公园），以及点击“开始导航”按钮。

在此过程中，执行框架以云侧模型推理为核心，端侧推理仅作为 VlmAgent 中的辅助能力存在，由 aikernel 提供支持。目前可观测到的本地模型包括一个基于 TensorFlow-Lite 的轻量模型 AIKLoadingDetection，用于在向云端请求推理之前判断当前页面是否仍处于加载状态，来决定是否暂停任务等待加载；此外，滚轮相关的 OCR 能力（如 OpScrollWheelAction）也依赖本地模型来识别滚动目标位置。

我们对豆包助手展开了初步的安全分析，发现其整体安全架构较为完整，未发现结构性缺陷或明显的高危设计问题，但安全漏洞依然存在。此部分将从多个维度对豆包助手的安全与隐私机制进行讨论。

为了自动化实现点击、读屏、安装应用等功能，豆包助手相关应用及组件被赋予了大量强力的权限。然而一旦这些超级应用的鉴权出现纰漏、强力权限被恶意利用，将会成为用户隐私及系统的严重威胁。

DARKNAVY 通过对豆包助手 Obric 相关的应用层组件进行分析，发现其针对Android 应用鉴权进行了较完善的防护，对暴露功能接口通过UID、包名及应用签名等多重校验手段，并辅以策略文件进行精细化约束，为第三方应用滥用超级应用的特权功能提供了较强的安全防护。

以 ObricAiAgent为例，其关键组件通过 SecurityManager 实现统一的鉴权控制。对于其对外暴露的 ScheduleService 服务中的 dispatchServerActions 功能，系统允许特定应用向豆包助手触发执行动作，但在实际执行前会强制进行安全策略校验，默认拒绝未知或未授权的调用请求。该校验流程通过 checkPolicy 从私有目录读取策略文件，并对 (category, subject, target, action) 四元组进行精确匹配，策略逻辑相对直接且约束严格。

由于策略文件位于私有目录，第三方应用无法直接进行替换或篡改。这样的鉴权设计有效降低了恶意应用滥用豆包助手能力的风险。

豆包助手集成字节跳动自研网络通信库，在端云通信链路中依托 TEE 保护的客户端私钥实现 mTLS 双向身份认证机制，在端侧有效对抗中间人攻击的同时，也确保云端每一次请求均来自真实的物理终端。在此网络基础上，豆包助手在端侧和云侧引入了较为全面且审慎的 AI 安全与隐私策略。

在非高敏场景下，当需要请求云端推理或验证操作有效性时，豆包手机会截取当前屏幕截图。该截图经过压缩处理后上传至云端服务器、进行推理。根据豆包安全白皮书^[8]的公开说明，云端在接收推理请求后，不会将截图、任务描述等用户数据用于模型训练或进行持久化存储。

另一方面，针对安卓系统中被标记为 FLAG_SECURE 的高敏感页面，例如隐私设置、视频播放及支付相关界面，豆包助手在执行过程中不会截取真实屏幕内容，而是使用一张不包含任何敏感信息的本地占位图作为云端推理输入，并辅以必要的附加上下文信息以保证执行流程的完整性。由此可以排除“使用豆包助手会导致登录密码等敏感信息被后台截图并上传”的常见顾虑。

在行为控制层面，豆包助手的自动操作能力受到云端推理结果与策略引擎的双重约束，具体表现为：

• 出于隐私保护及应用厂商合规要求，豆包助手目前无法对微信、支付宝等应用执行自动化操作，该限制由云端策略统一判定。

• 对于手机银行等高敏感应用，豆包助手的自动操作能力同样被明确禁止，相关判断亦发生在云端。

• 在自动操作过程中，一旦涉及支付、身份校验或需要用户补充关键信息的场景，云端策略会在执行前进行决策：拒绝并终止任务，或通过 call_user、clarify 等动作提示用户手动完成相关操作，从而避免未经授权的高敏行为或自动填充、编造敏感信息。

实测表明，云端策略会明确要求用户手动输入或上传敏感信息（如手机验证码等），自动化流程不会尝试代为完成此类操作。

GUI TOCTOU （Time-of-Check to Time-of-Use）风险是指 AI 在自动操作手机时，可能在“判断该做什么”和“真正执行操作”之间出现时间差。如果在这段时间内界面发生变化，AI 仍会按照旧判断继续操作，从而在用户毫无察觉的情况下误点按钮、触发非预期行为，甚至涉及隐私或资金风险。这一问题源于 GUI 自动化必须先截图分析、再执行动作的工作机制，是当前所有 GUI Agent 都难以完全避免的固有风险。

近期有研究工作对 GUI TOCTOU 风险进行了系统分析^[1] 。在对豆包助手端侧自动操作能力进行评估时，DARKNAVY 同样重点关注了这一潜在问题。GUI Agent 自动操作范式的工作流本质上是一个闭环序列：

其中，系统在时刻 t0 截取屏幕并送入 VlmAgent 请求决策；云端推理完成后在 t1 执行动作注入；在 t2 再次截图以获取执行反馈。由于界面状态在 t0 与 t1 之间可能发生变化，该流程天然存在竞争窗口，从而带来误操作风险。尤其是 t0 到 t1 的窗口往往较长，因为云端推理通常需要 2–3 秒。豆包助手在 t2 阶段并未实现自动回滚或报警机制，即便后续截图发现界面已偏离预期，也无法撤销已经发生的操作效果。因此，目前豆包助手针对误触的主要防护集中在 t1’ 阶段：动作执行前的校验校验。

点击操作通常会为误触的利用带来强大确认语义，而在豆包助手的具体实现中，OpClickUI引入了较为严格的校验逻辑：

• 系统会在 t0 记录顶层 Activity，并在 t1’ 时校验其是否发生变化，若已改变则直接跳过点击。

• 同时，t1’ 阶段还会检查最近三步内是否存在应用拉起操作单元 OpOpenApp。若存在，则重新截图并比较像素变化，若界面发生明显变化，同样跳过操作。

在 t1 执行阶段，豆包助手支持三种点击模式：单击、长按与双击操作。其中，单击与长按在安卓的注入实现中几乎不存在可控的时间窗口。对于双击操作，攻击者也无法在在第一次点击与第二次点击之间稳定完成界面切换。

由此可见，在现有实现下，GUI TOCTOU 的可利用性较低。不过，从安全演进角度看，若未来引入“两次以上点击”或“多次长按”等更长时间跨度的操作单元，则 GUI TOCTOU 仍可能成为攻击者更可控的误触渠道，需要提前纳入设计防护。

除点击外，其他操作单元如 OpTypeText、OpSwipeUI、OpScrollWheelAction 等目前并未实现类似 Action Guard 校验，虽然存在误操作可能性，但由于缺乏按钮级确认语义，这类误操作可造成的实际影响相当有限。

值得一提的是，当用户的手动操作与自动任务发生冲突（例如用户同时操作同一应用界面）时，豆包助手会主动暂停自动操作任务，优先让渡控制权给用户，这进一步降低了并发交互带来的额外误触风险。

在 AI 理解并执行用户任务的过程中，界面中呈现的文字、图片或其他内容有可能被模型误判为新的操作指令，从而影响其后续决策与行为。这类风险通常被称为 Prompt Injection。相关风险在大语言模型发展早期即已被广泛讨论^[2,3]，此前亦出现过商业模型在特定场景下被诱导执行非预期邮件发送等操作的公开案例^[4,5,6]。

在 GUI Agent 场景中，由于模型需要同时理解图像与文本信息，其潜在的注入路径与攻击面进一步扩大。此外，受上下文长度限制影响，在多场景切换与任务持续推进过程中，模型对初始用户意图的保持能力可能逐渐下降，从而在一定程度上提高后续注入攻击成功的概率。

在实际测试中，我们观察到豆包助手的云端模型具备一定的提示词注入防护能力，我们也初步排除了云端 Special Token Injection 风险^[7]。同时，针对用户直接输入的任务描述，端侧通过 checkPrompt函数对部分敏感词与典型注入模式进行了基础拦截。

然而，在现有实现下，云端模型的可见输入主要由用户任务描述与屏幕图像共同构成。相较于文本输入，针对屏幕截图中的内容，豆包助手端侧目前尚未引入额外的内容过滤或语义约束机制，界面中的文本信息将被完整纳入模型推理视野，完全依赖云端过滤或隔离。在实验环境中，通过对界面文本进行精心构造并结合敏感词绕过手段，我们在特定条件下成功获取了模型的 System Prompt。同时，我们也观察到，Prompt Injection 可能对云端高敏操作检测逻辑产生干扰，从而影响模型对任务目标与执行状态的判断。

文初所展示的示例正是基于上述风险模型展开：在用户发起合法任务请求的流程中，若模型受到来自外部输入（如短信、邮件或网页内容）的持续干扰，可能在缺乏用户显式感知的情况下暴露部分个人信息（例如长期记忆内容、录音、相册、短信或邮件等），或被嵌入至更复杂的攻击链中，辅助完成后续操作。在系统性评估过程中，我们注意到，豆包助手云端对诈骗短信与钓鱼类内容的识别能力仍有提升空间；而其具备的高权限自动操作能力，则可能使上述风险在特定场景下表现得更加直接。

从另一个角度看，若未来豆包助手等智能体能够具备更强的安全意识与反诈能力，并部署于老年人等“网络安全弱势群体”使用的设备中，则其有望转化为一种积极的防护工具。

超级智能体已然成为行业发展的必然趋势。随着 OpenClaw 等项目的涌现，AI 被赋予更强的自主能力与跨域执行力，正逐步深度融入从生活到工作的各类场景之中。

在这一进程中，智能体的安全体系建设必须与功能进化同步向前。DARKNAVY 自2024年起，便与多家行业伙伴携手，共同应对手机智能体、意图框架等新型系统与传统领域结合时所带来的全新安全挑战。

我们深信，面对AI智能化的全新挑战，唯有提前洞察并系统性地构建防御，才能在其大规模部署时实现真正的可信与可靠。

阅读原文

跳转微信打开

阅读原文

跳转微信打开

隐私安全、财产安全，在新一代人机交互入口中的攻防博弈

• 实景导航时，看着箭头悬浮在路口上空

• AI 自动翻译外语，字幕实时显示在眼前

• 一句“确认支付”，眼镜替你完成扫码转账

——越来越多原本属于手机的功能，正在悄悄迁移到这副眼镜上。

今年走红的智能眼镜，把摄像头放在用户视线的延长线上，把导航、翻译、拍照和支付等功能，全部收束至“镜片”中一块几乎看不见的光波导屏幕里。

对普通用户来说，这意味着更酷的导航、更自然的翻译和更顺手的拍照；对攻击者来说，则可能是一条直通你视野、隐私甚至钱包的快捷通道——甚至可以“通过你的眼睛看世界”。

智能眼镜并不是一个全新的概念。早在 Google Glass 刚刚面世时，就曾作为 GEEKPWN 2014 的项目接受挑战。十多年后，当智能眼镜带着 AI 加持的功能再度掀起浪潮时，作为“压舱石”的安全能力，能否支撑起这些已经绑定导航、摄像头和支付入口的设备，不在浪涌中翻船？

在刚刚结束的 GEEKCON 2025 上，选手通过短暂的物理接触，利用未知漏洞在两分钟内获取了某品牌智能眼镜的完全控制，并实现了远程静默实时监控等功能，将潜在的隐私与财产安全的风险，具象地展示在了舞台中央。

在本篇攻防速写中，DARKNAVY 团队将从攻击面梳理、摄像头隐私安全及财产安全三个维度，分享对 Rokid Glasses 智能眼镜的安全探索。

摄像头、麦克风与扬声器，让智能眼镜可以便捷记录眼前画面，像蓝牙耳机一样播放音乐、随时接听电话。与常见智能眼镜相比，Rokid Glasses 的显著差异在于：其在透明镜片中集成了两块光波导显示屏，在不遮挡视线的前提下提供图像显示能力。

得益于光波导显示屏与高通 AR1 GEN1 芯片，Rokid Glasses 有足够的算力运行 Android 系统，并在其之上构建更丰富的 AR 生态。使之成为更便捷的虚实融合入口，支持虚实融合导航、实时翻译显示、扫码支付，甚至安装第三方应用。

出于续航考虑，部分 AI 相关功能被迁移至手机端 APP 及云端处理，眼镜通过蓝牙连接将数据传输至手机 APP 处理。仅在传输照片、进行 OTA 升级等需要高速数据传输的场景下，眼镜才会短时开启 Wi‑Fi。

Rokid Glasses 出于功耗和硬件等因素考量，尚不支持 SIM、eSIM，目前的软件生态仍以离线应用及依托手机 APP 中继的联网应用为主，整体较依赖手机侧的蓝牙通信链路。因此，其攻击面主要集中在以下几个方面：

• 物理攻击面：设备上保留的调试接口/测试引脚，攻击者通过直接接触及拆机可能获取特殊权限。

• 配套的手机 APP 及其通信链路：眼镜侧通常暴露的无线攻击面仅有与手机的蓝牙连接，而手机上的恶意应用可能攻击眼镜配套的手机 APP，滥用手机与眼镜之间的通信链路。

• 眼镜端 Android 系统及 OEM 应用：运行在智能眼镜上的厂商自研 Android 应用，是眼镜本体的核心逻辑所在。一旦攻击者通过蓝牙、Wi‑Fi 等方式与眼镜建立连接，便可以在这些组件中寻找软件漏洞并发起攻击。

• 眼镜端三方应用：智能眼镜允许第三方应用的安装，且智能眼镜上的 Android 系统显示及控制远不如手机端 Android 完善，对三方应用的隔离与管控可能成为攻击者的突破口。

摄像头是智能眼镜感知物理世界的主要入口，眼镜上得天独厚的位置，使其几乎成为用户的“第三只眼”，极大便利用户记录眼前画面。

然而，无论是对于摄像头前的被拍摄者，还是佩戴智能眼镜的用户，这种能力都引入了新的隐私安全问题。

摄像头在工作时，被拍摄者是否应当享有知情权？

例如，韩国在售的手机被要求在拍照时发出超过 65 分贝的提示音。

对智能眼镜而言，拍摄指示灯承担了类似职责——向面前的人明确提示眼镜正在拍摄，从而在一定程度上保障被拍摄者的知情权。

然而，市面上已经出现通过黑色遮光贴、黑色胶带等方式遮挡指示灯的“灰黑产”手段，试图绕过指示灯，实现静默偷拍。

Meta 眼镜拍摄时指示灯闪烁（左），贴上黑色遮光贴后（右）

针对这一问题，部分厂商为眼镜设计了遮挡检测机制，通过在指示灯附近增加环境光传感器，判断指示灯前是否存在物理遮挡。

Rokid Glasses 检测指示灯是否被遮挡

但与手机闪光灯类似，拍摄指示灯最终仍由眼镜中的软件控制。在 Rokid 智能眼镜中，其由 system 应用统一管理，一般应用无法直接控制指示灯状态。然而，一旦攻击者获取系统控制权，便可以绕过这一限制，自由控制指示灯的开关，实现静默偷拍。

Rokid Glasses 智能眼镜中设置灯光为不同状态的代码逻辑

与此同时，如果安全性不足，智能眼镜的摄像头同样会对佩戴者自身的隐私构成风险。攻击者可以借助这一得天独厚的视角，通过眼镜摄像头实现对用户的实时监控。

在 Rokid 智能眼镜上，由于其基于 Android 系统，对摄像头的访问控制与 Android 设备类似：应用需在 AndroidManifest.xml 中声明相机权限，方可访问摄像头。

但在该智能眼镜上，三方应用申请的权限均会静默授予，而用户无法拒绝APP的权限。一旦攻击者滥用权限或利用漏洞进行权限提升，便可以绕过应用层权限约束，远程获取实时视频流。

利用漏洞实现对眼镜完全控制，并获取摄像头数据

作为智能眼镜的热门应用场景之一，“看一下支付”功能，使用户可以直接通过眼镜识别眼前的二维码，完成便捷付款，而无需掏出手机。

然而，引入支付能力后，智能眼镜与传统移动支付之间的最大差异在于认证方式。移动支付通常依赖 PIN 码、人脸、指纹等方式完成机主认证，这些机制往往部署在 TEE 等安全隔离环境中，攻击者即使攻破 Android 系统，也难以直接危及财产安全。

而在智能眼镜上，受交互方式限制，PIN 码、人脸、指纹等传统认证手段难以直接使用。目前主流 AR/XR 设备更多采用声纹识别、虹膜识别等方式完成身份认证。

通过虹膜认证进行身份认证及支付

相较之下，虹膜认证需要额外硬件支持，对智能眼镜的硬件设计提出更高要求；因此，利用已有麦克风实现声纹支付，往往成为更现实、成本更低的选择。

Rokid Glasses中的“看一下支付”功能，便是通过麦克风采集用户“确认支付”的语音，并进行声纹匹配，从而核验转账支付过程中的机主身份。

一旦攻击者成功控制智能眼镜，便可在后台持续采集用户语音。随后，攻击者可以对录制的语音进行剪辑、重放，甚至结合 AIGC 技术合成伪造声纹，以绕过基于声音的身份验证机制，从而对用户隐私和财产安全构成严重威胁。

以下视频展示了我们利用 Rokid Glasses 中的漏洞获取了眼镜的完全控制权，进而监听麦克风窃取用户声纹，并实现在用户无任何操作的情况下静默转账至攻击者账户。（自10月开始我们多次尝试联系厂商负责任披露漏洞，至今未获回应）

阅读原文

跳转微信打开

揭秘 GEEKCON 硬件钱包的破解挑战

在区块链上，拥有地址的私钥，即掌握对应账户资金的控制权。

2025 年 10 月，美国政府宣布查封柬埔寨太子集团的 12.7 万枚比特币。链上追踪报告指出，该笔资金实际即矿池 LuBian 在 2020 年 12 月失窃的资产。

比特币私钥是长 256 位的随机数，理论上不可能通过暴力枚举破解。美国政府是如何获取 LuBian 的钱包私钥的？

Milk Sad 研究团队在 2023 年发现并公开了 Libbitcoin Explorer (bx) 的伪随机数漏洞：bx 仅使用 32 位的随机数作为种子，在此基础上通过确定性的算法生成 256 位的随机数。此类不安全的随机数可在数小时内暴力枚举，而 LuBian 钱包私钥的生成方式也存在同样的问题。

私钥面临的安全威胁不止于此。除了软件钱包本身的算法漏洞，储存私钥的设备往往也是联网的：系统漏洞、恶意插件、钓鱼网站、木马远控等攻击手段，均可能在用户毫不察觉的情况下窃取密钥或签名权限。

为了更好地保护私钥，硬件钱包应运而生。它通过将私钥隔离在离线设备的独立芯片中，避免直接暴露于网络，被视为数字资产的“保险箱”。

但，硬件钱包真的绝对安全吗？

在 3 月发布的文章《假如捡到 Web3 硬件钱包的人是黑客》中，DARKNAVY 就已展示过在一款名为 Cypherock 的硬件钱包上显示 "Hacked" 字样的攻击效果。

不过，仅仅在屏幕上显示这些文字并不能造成实质性的危害，于是在 GEEKCON 2025 的舞台现场，DARKNAVY 又展示了对两款硬件钱包在真实场景下的攻击。其中对于 Cypherock，现场模拟了供应链攻击，篡改固件并绕过安全启动与设备真实性认证，最终实现对新生成的助记词的控制。

本文将介绍 DARKNAVY 如何在 Cypherock 上发现的多重漏洞与缺陷，并组成利用链。

PIN 码和助记词是硬件钱包中最关键的两个信息，任何一个泄露都可能导致资金失窃。因此，许多硬件钱包使用安全芯片（SE）保护这两个秘密。而 Cypherock X1 Vault 虽内置了 ATECC608A 安全芯片，但这块 SE 却仅仅用于设备真实性校验。

在 X1 的独特架构下，助记词通过 Shamir's Secret Sharing 算法被拆成 5 份，分别存于钱包本体（X1 Vault）和 4 张 NFC 卡片中。需要进行签名时，使用 Vault 和任意一张卡片即可还原私钥到 Vault 中使用。PIN 码的校验也由 NFC 卡片进行。

本次介绍的利用链全部在 X1 Vault MCU 上发生，不涉及 SE 和卡片。

不论是人工审计，还是使用大模型进行自动化挖掘，都能在 X1 Vault 的固件开源仓库中找到不少漏洞。例如，钱包根据 USB 报文的 applet_id 选择 applet 时，就存在越界访问导致的函数指针可控。

constcy_app_desc_t *registry_get_app_desc(uint32_t app_id){
  return descriptors[app_id];
}


voidmain_menu_host_interface(engine_ctx_t *ctx,
                              usb_event_t usb_evt,
                              const void *data) {
  uint32_t applet_id = get_applet_id();
  const cy_app_desc_t *desc = registry_get_app_desc(applet_id);


  if (NULL != desc) {
    desc->app(usb_evt, desc->app_config);
  }
  // ......
}

固定的固件加载地址、未启用的 Canary 和 Execute Never 保护，让任一个漏洞都能轻易地转换为 ROP 或 shellcode 执行。

为了研究进一步的利用方式，我们将目光转向了固件升级和启动校验的逻辑。

Cypherock 自诩完全开源，事实上开源的部分仅限 "Application Firmware"。文档中提到的 "Bootloader" 和 "Firewall Code Area" 都不开源，也无法从固件更新包中得到，而固件校验的逻辑正位于这两部分中。

通过简单的尝试，我们发现，劫持控制流后可以直接读取 Bootloader 代码段并通过 USB 发送给电脑，而 Firewall Code （以及 Firewall Data Storage）则无法读取。逆向 Bootloader 中的 Firewall 初始化逻辑，可以确认无法读取的内存段确实被保护了。

Firewall 是 STM32L4 提供的硬件安全特性，实现了内存访问隔离机制。

STM32L4 允许用户分别为 Code、Non Volatile Data、Volatile Data 各设置一个保护范围，只有 Firewall Code 的指令才能访问被保护的段。

此外，Firewall Code 只能通过 Call Gate 进行调用，直接跳转到区域内部的代码地址会被视为非法访问。

Firewall 的 Call Gate 入口被设计为一个函数，参数 task 用于区分功能，另外还有两个地址参数和一个大小参数。

staticuint32_tfirewall_func(
    const uint32_t task,
    const uint8_t *data,
    const uint32_t size,
    const uint32_t address
);

Application Firmware 使用 Firewall，多数情况下是为了读写 Firewall 保护的 NVDATA 区域。这个区域共包含 4 个 page：

1. Primary Bootloader Data：记录固件版本、固件 hash、设备状态等

2. Backup Bootloader Data：用于备份上述数据

3. Permanent Key Storage：保存各类设备密钥

4. Secure Data Storage：保存钱包信息等

对于前两个 page，Firewall 只开放了少量数据的受限读写；对后两个 page 则提供了多个 task 用于读写，可以类比为 memcpy：参数 address 指向受保护区域， data 则指向外部数据。理论上 Firewall 应该对两个指针的范围及读写长度进行校验，但测试发现，WRITE 功能的 data 可以是任意地址——于是，让 data 指向 Firewall Code，便能够将受保护的代码段写入 Firewall NVDATA 的空闲区域，接着再调用 READ 功能即可正常读出。

最后需绕过一个小障碍：WRITE 并不是简单的内存拷贝，而是 Flash 刷写，在重复写入同一地址之前，必须先擦除整个 page 的内容。为了避免破坏 NVDATA 的正常数据导致设备变砖，我们找到一个函数，它会擦除 Secure Data Storage 并重新写入最新的完整数据。此时，page 剩余的空闲区域即可安全地用于 dump Firewall Code。

至此，我们得到了 MCU 内的完整代码，可以正式对固件校验的逻辑展开分析。省略逆向过程，我们直接给出固件（Application Firmware）升级的流程总结：

0. Application Firmware 通过 Firewall 设置 BOOTSTATE 为升级状态，随后重启设备

1. Bootloader 进入升级流程，从 USB 接收固件头，然后调用 Firewall 的多个 task：

1. 将 BOOTSTATE 设置为升级中

2. 对固件头进行签名校验，并把固件版本、大小存入 Bootloader RAM

3. 把固件的签名存入 Bootloader RAM

2. Bootloader 逐 page 从 USB 接收完整固件，同时对 Flash 的对应区域进行擦除与写入

3. Bootloader 再次调用 Firewall 的多个 task：

   d. 计算当前（已更新的）固件 hash、与步骤 1c 保存的签名进行校验

   e. 再次计算当前固件 hash，和步骤 1b 保存的固件版本大小一起写入 Primary Bootloader Data，并将 BOOTSTATE 还原为正常状态

整个过程中，如果 USB 连接中断或任意校验失败，设备会立即重启并重新进入升级过程。

注意到升级流程存在严重缺陷：每个 Firewall Task 步骤独立，可以跳步操作（尤其是 1b 1c 两次签名校验）；固件签名不写入 Flash，开机时只校验完整性，不校验真实性。

于是，在劫持 MCU 控制流的基础上，我们直接擦写固件代码，然后调用步骤 3e 的 Firewall Task 写入当前新固件的 hash，即实现了固件的篡改。至于 3e 中依赖前置步骤 1b 验签后保存的参数，我们可以直接修改 —— 细心的读者可能已经注意到，Bootloader 与 Firewall Code 共享同一段 RAM，初始化 Firewall 的代码片段中也并没有设置 Volatile Data 的保护。

在 GEEKCON 现场，我们模拟了一名普通用户第一次收到购买的硬件钱包后的“验货”场景：裁判将已被选手黑掉的钱包连接到电脑，并使用钱包厂商配套的 CySync 软件进行设备真实性校验。数秒之后，这个已经被植入后门的钱包却通过了厂商软件的检测，电脑和钱包的屏幕上均显示校验通过。

在厂商的设计描述中，钱包固件刷写完成之后的初次启动会触发强制的设备真实性校验，而被篡改过的固件按理说是无法通过该校验的。那么，我们是如何实现供应链攻击的最后一步的呢？

Cypherock 的真实性校验流程如图所示，Vault 中的 SE 终于派上了用场：它使用内置的私钥进行两次签名，第一次对序列号，第二次对云端随机数和固件 hash 的异或值。云端返回验证结果后，设备将状态保存。

由于第二次签名引入了固件 hash，客户端同时提交了设备的固件版本，云端可以判断固件的 hash 是否正确。然而，SE 无法直接读取固件，由恶意固件提供的 hash 有何真实性可言？

另外，以上校验仅是单向的：云端校验了设备，设备却不需要校验云端。如果仅是为了绕过设备侧的状态判断，在客户端侧直接返回成功即可。

尽管 Cypherock 鼓吹自己是 “Safest Hardware Wallet”，在官网上也提供了公开的漏洞奖金计划，但他们无论对用户还是对安全研究人员的态度，都可以用沉默是金概括。

DARKNAVY 在三月通过邮件向 Cypherock 提交了两个漏洞，他们在 GitHub 上默默修复，却连一句“收到”都不愿回复。无独有偶，今年 Hexacon 上，议题 "Breaking the Vault: USB Bugs and Bug Bounty Failures" 的名称也点明了同行向 Cypherock 报告漏洞后的经历。

漏洞的修复也毫无透明度可言，用户完全对设备的安全状况完全不知情；当有人问起这些议题是怎么回事时，厂商一句“早就修了”草草搪塞。

于是，对于本次涉及的 Bootloader 和 Firewall 的漏洞，我们利用它刷入了一版自定义固件，替换开机 Logo 和助记词展示界面，博君一笑。

阅读原文

跳转微信打开

一场本可止于技术层面的讨论

阅读原文

跳转微信打开

一个长期被忽视的Android身份认证攻击面

现代智能手机支持密码、人脸、指纹等多种解锁方式，锁屏密码是手机上最关键的敏感信息之一，其是手机对机主的“信任根基”。锁屏密码有多种形式：4 位或 6 位的数字 PIN、锁屏图案、以及字母与数字混合的密码（下文中统称为 PIN 码）。

无论形式如何，PIN 码都是手机上身份校验与访问控制的核心。一旦 PIN 码泄露或被攻击者获取，攻击者不仅可以解锁手机、访问其中加密的数据，而且也可以绕过用户认证、发起支付转账、修改生物认证信息等高敏感操作。

为此，手机厂商与操作系统在用户身份认证保护上设计了大量防御机制，构成了多层纵深防护体系，以阻止 PIN 码被非法获取、手机身份认证被绕过。

DARKNAVY 在Android 身份认证安全领域开展了系统性研究，发现了多个高危漏洞，并在7家主流手机厂商的8台不同型号手机上（参见本文末视频），验证了可提取手机锁屏 PIN 码的攻击方法，以下以三星示例。

本文将从针对Android身份认证的纵深防御机制及针对PIN码的攻击手段出发，剖析Android手机锁屏PIN码背后的攻防博弈。

在早期的 Android 设备中（约十年前），恶意软件泛滥， root 权限唾手可得。为了在系统被完全攻陷的情况下继续保护支付凭证、生物识别数据、关键密码等高敏感信息，Google 为 Android 引入了基于 TrustZone 可信执行环境（Trusted Execution Environment，TEE）的支持。在这个与高风险 Android 系统隔离的区域中，仅允许被信任的代码运行；其中通过 keymaster 管理密钥，并以此支撑支付转账、生物识别等操作。

当然，PIN码作为Android身份认证的基石，其校验则交由运行在 TEE 内的 gatekeeper TA（Trusted Application） 完成。用户输入的 PIN 码会立即通过 scrypt 转换为 handle，并在 gatekeeper TA 中与设备存储的 handle 进行验证。校验通过后，gatekeeper 会签名认证凭据（AuthToken），再交还给 Android 系统，以授权应用访问keymaster 中密钥或触发其他敏感操作。Google 在 gatekeeper HAL 层之上定义了标准化框架，而 HAL 层之下及 TEE 中的实现则由各厂商负责。

人脸和指纹认证机制与此类似：相应的 TA 在 TEE 内完成比对后，签名对应的 AuthToken，供系统后续使用。

为了防止攻击者进行穷举破解，gatekeeper TA 与生物识别 TA 均内置了“错误计数器”（throttle）机制——一旦错误次数达到上限，系统会强制延时并拒绝响应身份验证请求，从而显著提高暴力破解的成本。

然而，近年来的相关工作表明，手机中的 TrustZone-based TEE 及其中的 TA 并非牢不可破。为进一步提升锁屏密码的安全性，Android 开始支持 Weaver —— 基于安全芯片的锁屏密码保护方案。在部分厂商旗舰设备中，使用安全芯片隔离出一块功能更单一的物理区域，将部分高敏感操作迁移至芯片中完成，并通过 StrongBox 管理密钥派生过程中的核心机密。

BFU（Before-First-Unlock）与 AFU（After-First-Unlock） 指的是两类目标为绕过身份认证的攻击场景：分别对应手机开机首次解锁之前与首次解锁之后的状态。二者在 Android 平台上通常存在较大的差异，其中 BFU 场景通常更难以实施。

在 BFU 场景下，系统仅启动有限的组件，且用户只能通过 PIN 码完成解锁。由于存在 Credential Encrypted（CE） 机制，用户数据在设备未首次解锁前保持加密状态；而 CE 的解密密钥又受到 PIN 码保护——因此，即便攻击者已获得 Android 的 root 权限，仍无法直接读取受 CE 保护的用户数据。因此，在 BFU 状态下，PIN 码本身及上下游保护 PIN 码、被 PIN 码保护的密钥是攻防博弈的关键。

在 AFU 场景中，不同于iOS和HarmonyOS NEXT的多级密钥设计（其应用数据在首次解锁后仍需动态解密），Android设备在首次解锁后，所有受CE保护的应用数据都会被解密。首次解锁后，系统允许使用人脸、指纹等多种解锁方式，且大量后台应用与系统服务处于运行状态。攻击者在此情形下有更多路径可选：可以尝试绕过任一种生物识别或 PIN 机制，或通过已运行的后台应用与系统服务获取system或者root权限，从而访问用户数据，而并非必须获得 PIN 。但部分高敏感操作（比如转账支付）或受 keymaster 保护的密钥访问，仍然依赖 Android 的身份认证凭证（AuthToken）。

我们本文中聚焦于针对PIN码的攻击手段。

PIN码为了方便用户记忆与操作，通常由6位数字组成（或解锁图案）。其搜索空间通常有限，错误计数器（throttle）因此成为认证链路中的关键。一旦计数器被绕过或禁用，攻击者便可进行高效的暴力猜测，从而快速破解 PIN 码。

在基于 Gatekeeper 的方案中，错误计数器及认证逻辑运行于 TEE 中的 gatekeeper TA 中。攻击者绕过错误计数器通常通过破坏 TEE 的完整性来实现：

• 攻击者可利用 BootROM 阶段存在的漏洞取得EL3的权限，逐级篡改启动链，从而修改TEE中的代码逻辑；

• 也可利用 U-Boot 或 Android 中的漏洞先获取 EL1 或 root 权限，再利用 Secure Monitor 或其他Secure Master 外设的漏洞提升到 EL3 权限^[2,3]；

• 部分厂商将 gatekeeper 与 keymaster 实现在同一 TA 中，合并实现使得原本功能简单的 gatekeeper TA 拥有了大量的攻击面。

绕过gatekeeper PIN码校验的常见攻击思路

基于Weaver的方案中，将 TEE 中 PIN 码校验逻辑迁移至安全芯片，通过安全芯片或 hardware-based StrongBox来管理错误计数器和密钥派生所需的机密材料。由于安全芯片的功能更单一、暴露的攻击面更小，为其中存储的机密信息提供了进一步的保护。但也有安全研究团队通过攻击特定的安全芯片提取出其中的机密信息、从而爆破出PIN码^[1]。

DARKNAVY在基于Gatekeeper的身份认证方案中，发现了一个被长期忽视的攻击面：拥有与TEE通信能力的攻击者，通过攻击与 gatekeeper 共享机密信息的生物认证 TA，实现对 PIN 认证的绕过与暴力破解，进而恢复出设备的锁屏 PIN ，可能导致CE被绕过、高敏感操作身份认证被绕过等风险。

DARKNAVY通过生物认证TA中的攻击面绕过PIN码认证

我们已在来自 7 家厂商的 8 款不同型号的设备上进行了验证，并成功恢复出 PIN 码，涵盖 3 台高通平台与 5 台 MediaTek 平台的设备，包含2024年手机出货量前10的厂商中的6家厂商^[4]。

本项研究工作目前被将于10月24日举办的GEEKCON 2025、和11月13日举办的POC 2025接收，届时将分享更多关于漏洞细节及缓解建议，敬请关注。

更多技术细节于《深蓝洞察·专业版》抢先提供

点击阅读原文进入 insight.darknavy.net

阅读原文

跳转微信打开

阅读原文

跳转微信打开

我们坚信，没有一项突破性的黑客技术成果，不是诞生在一个自由的土壤里

这里没有“岗位说明书”，只有“挑战路线图”

你在找什么？

一个能让漏洞吐露秘密、把利用写成史诗的地方？

一群和你一样，觉得协议比情书更浪漫的极客？

一片敢冲破禁锢，自己定义规则的战场？

欢迎你登上，为“技术理想主义者”建造的舞台

我们是DARKNAVY·深蓝：

• AVSS 对抗研判和量化安全的首倡者与推动者，用攻防诠释安全，创建行业安全度量法典

• GEEKCON 黑客大赛创办者，让全球顶尖黑客在此交汇锋芒

「而你？将是下一个创造者」

在这里，你可以自由选择探险坐标（芯片/操作系统/AI/渗透/WEB3/研发/运营），不必困守疆域

「边界？那是留给别人的」

我们为你准备：

• 超高浓度技术养分：和顶尖极客共振，极速成长

• GEEKCON通行证：从上海到国际，拥抱更大舞台

• 充足“能量补给”：尊重才华的津贴，守护前行的昼夜

唯一门票：

燃烧的求知欲、经得起考验的品格、扎实的技术实力

除此之外——百无禁忌

三个月以上，沉浸式极客之行

上海西岸，等你履历：CoD@DARKNAVY.com

跳转微信打开