对三款最强 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

跳转微信打开

来看GEEKCON严格测试的摄像头安全排行榜｜2025.06发布

U-Boot SPL 2013.07-g938310316-dirty (Apr 16 2024 - 18:36:35)
...
Image Name:   Linux-4.4.94
Image Type:   MIPS Linux Kernel Image (lzma compressed)
Data Size:    1951156 Bytes = 1.9 MiB
Load Address: 80010000
Entry Point:  803e9a80
kernel hdr_len:0x40  data_len:0x1dc5b4 hdr_dcrc:0xc5d9968d 
Verifying Checksum ..... OK
Uncompressing lzma Kernel Image ... OK
Starting kernel ...
...
--start--
camera start .. 
360-IPC login: wht=========

阅读原文

跳转微信打开

我们尝试用大模型革了自己的命，结果发现……一堆洞

正如 DARKNAVY 在深蓝洞察 | 2024年度最具想象空间的新应用所展望的：

新一代的 AI Agent 将具备优秀的推理能力和泛化能力，并能熟练地运用多种安全研究工具，继承大量的人类专家经验，如同顶尖的安全专家一般，发现现实世界中更多的 0day 漏洞。

不出所料，随着大语言模型 (LLM) 对复杂任务处理能力的日益增强，智能体技术 (Agent) 正在成为漏洞挖掘领域的新型范式。随着去年 Google Project Zero 团队推出了 Naptime^[1]，越来越多的 Agent 审计工具正在涌现，通过为 LLM 提供必要的工具集和待测源码，模拟安全研究员的行为进行代码审计与漏洞确认。

然而，DARKNAVY 观察到单个 Agent 在审计中大型项目时，常因 LLM 推理能力的局限性（如逻辑不完整、幻觉现象）导致误报与漏报。DARKNAVY 基于多年实际漏洞挖掘经验，提出了 multi-agent 系统架构，通过模拟安全团队内部的分工与协作机制，实现了全自动漏洞挖掘工具 Argusee。

在对 Linux USB 协议栈源码的测试中，Argusee 在短时间内便发现了一个自 Linux 6.5 版本引入的高危漏洞，该漏洞已获编号 CVE-2025-37891 并得到修复，影响了包括 Ubuntu 和 Arch Linux 在内的多个主流发行版。DARKNAVY 对该漏洞进行利用开发后得到了一个在 Arch Linux 上稳定提升至 root 权限的利用脚本：

本篇为《深蓝洞察》系列最新技术专栏「前瞻对抗」的首篇。

Argus had a hundred eyes round his head, that took their rest two at a time in succession while the others kept watch and stayed on guard.

— Ovid: The Metamorphoses

尽管 Naptime 等单 Agent 工具为 LLM 驱动的代码审计提供了可用范式，但在面对中大型项目时，往往因模型推理逻辑不够严谨、上下文感知有限而产生较多误报与漏报，且难以灵活调整审计流程，难以满足对精准定位和深度验证的需求。

对此，Argusee 并非旨在完全取代人工审计，进行从零开始的漏洞挖掘，而是作为安全审计人员强大的辅助工具，依赖于审计人员提供精确的分析入口（如特定的函数或代码模块）及必要的上下文信息，在此基础上进行深度分析与潜在风险识别，从而大幅提升专业审计人员的工作效率。

与现有工作不同，Argusee 的核心创新在于其多智能体协同机制，其借鉴了人类安全团队的协作模式，将复杂的审计任务分解给不同角色的智能体。更重要的是，相较于一些早期多智能体探索^[2]中各智能体功能相对独立、交互固化的方式，Argusee 赋予了 LLM 更大的自主权，使其能够动态地进行任务理解与分派，从而实现更灵活和高效的协同审计。这正对应了强化学习之父 Richard Sutton 在 The Bitter Lesson 一文中所写到的：「我们希望人工智能 Agent 能够像我们人类一样去发现，而不是在系统里集成我们已经发现的东西。建立在我们已知发现之上只会让我们更难看到如何完成发现过程。」

作为一个实现原型，Argusee 的架构如下图所示，主要包含以下核心智能体：

Argusee 原型框架图

1. 管理者 Manager Agent

   Manager 是用户的交互点，用户向其提供分析入口（如目标文件或函数）。Manager 负责从宏观层面理解任务，例如，判断函数核心功能，识别潜在的关键代码段，并进行任务分解与分派，将不同的代码片段连同必要的上下文信息分发给多个 Auditor。

2. 审计员 Auditor Agent

   Auditor 专注于分析来自 Manager 分配的、通常较为短小的代码片段。它们结合上下文信息，深入挖掘代码细节中可能存在的漏洞，如 Buffer Overflow，Use After Free 等漏洞。

3. 校验者 Checker Agent

   为了降低误报和漏报，Manager 在汇总审计结果并输出最终结论前，会请求 Checker 对整个逻辑链条进行复核与验证，查漏补缺。最终，由 Manager 整合信息并输出审计报告。

各 Agent 在执行任务过程中，均可按需调用预设的工具集，工具的使用时机和方式皆由 Agent 自主决策。另一方面，后端工具集的有效运行依赖于对目标项目和环境的适配，例如，源码阅读器 (Code Reader) 的变量定位功能依赖于后端语言服务协议 (LSP) 所建立的源码索引功能。

为了更好的理解 Argusee 的工作流程，下图展示了 Argusee 在实际运行过程中的思维链条：

用户在指定目标文件和入口函数的情况下，Manager 通过分析将任务分派给了两个 Auditor，其中一个 Auditor 发现了一处疑似缓冲区溢出风险并报告给了 Manager。随后，Manager 请求 Checker 对该漏洞进行了复核，最终确认这是一处真实存在的堆缓冲区溢出漏洞，并产出了漏洞审计报告。

为验证 Argusee 的有效性，我们分别在基准测试数据、中小规模开源项目和超大规模开源项目（如 Linux 内核）上对其进行了测试评估。

在来自 META CyberSecEval 2^[3] 的单文件标准测试用例中，Argusee 展现出接近完美的漏洞识别能力，在 Buffer Overflow 等类别的测试用例上达到了 100% 的准确率。

针对中等规模的真实世界开源项目，Argusee 同样取得了显著成果，在多个经过充分测试的项目中累计发现了 15 个先前未知的安全缺陷，测试项目涉及到 GPAC、GIFLIB 等多个解析复杂文件格式的开源软件库。

以开源多媒体框架 GPAC^[4] 为例，该项目长期经受 Fuzz 测试，近年来被发现的新漏洞相对较少。然而，Argusee 在短时间内便识别出数个较难通过传统方式发现的新漏洞。DARKNAVY 观察到，对于 GPAC 这类输入格式明确、以内容解析为核心功能的目标，Argusee 的表现尤为突出。

例如，下图代码是 Augusee 发现的一处整数溢出造成的内存破坏漏洞。对于 Fuzzer 而言，要构造出能够触发此漏洞（需满足 zlib 压缩格式且原始数据足够大以引发溢出）的输入样本难度极高。而 Argusee 通过模拟人工审计的逻辑推理过程，成功定位了这一深藏的缺陷。

除此之外，Argusee 也针对体量庞大的代码项目进行了尝试，例如 Linux Kernel USB 协议栈这类庞大且复杂的项目。在使用过程中，尽管需要为 Agent 提供更丰富的上下文信息，Argusee 在代码的辅助理解、高风险区域定位等方面依然表现出强大的潜力，能够显著提升研究人员的审计效率。

下图为 Argusee 在 Linux Kernel USB 协议栈中找到的漏洞 CVE-2025-37891^[5]：

该漏洞发生在 Linux 内核 USB 的主机侧，恶意用户可以通过插入支持 USB MIDI2 协议的模拟设备来进行攻击。对于支持 MIDI2 的 USB 设备，Linux 内部会将 MIDI1 包转换成 UMP 包，由于长度检测不当，转换时用来存储 MIDI 字节流的缓冲区可以发生溢出，使得攻击者获得内核堆上任意溢出的原语。Augusee 被指定 USB MIDI2 入口点相关函数与文件后，迅速找到了此漏洞并提供了清晰的漏洞原理分析与复现。

当然，Argusee 的能力不止于此。鉴于构建全面的漏洞挖掘能力评估数据集及衡量标准本身是一项复杂工作，更细致的量化评估以及实战测试结果将在后续的研究中呈现。

展望未来，为了进一步释放 Argusee 的潜力，基于当前原型，Argusee 还可以围绕以下三个维度进行增强补充：

• Agent 系统：引入更多专业角色，如负责构造 PoC 以验证漏洞的复现者 (Reproducer Agent)，以及评估漏洞可利用性并尝试编写 Exploit 的利用者 (Exploit Agent)。

• 工具集：集成更丰富的分析工具，如调试器，帮助 Agent 理解程序执行流和漏洞触发过程，以及其他高级静态、动态分析工具等，构建强大的武器库。

• 目标项目与环境：整合更多辅助代码审计的信息源，如利用 RAG 技术检索相关源码知识、分析编译后的二进制文件等。

智能体技术正深刻变革漏洞挖掘的既有范式，而 Argusee 的实践证明，多智能体协同是提升代码审计效率的有效途径。赋予 LLM 合适的结构与工具，结合人类研究员的经验，更高效地自动化发现漏洞，其潜力远超单体智能的局限。

此趋势下的探索，Argusee 仅是起点。DARKNAVY 致力于深化智能体协同安全研究，让 AI 智能体与安全专家无缝协作、各展所长，共同构筑稳固的数字防线。

或许某一天，在这场智能体引领的变革中，安全人员将从繁重的低级审计工作中解放，更多聚焦策略设计与风险评估；当经验与创见得以释放时，又能推动安全研究达到怎样的新高度？

[1] https://googleprojectzero.blogspot.com/2024/06/project-naptime.html

[2] https://arxiv.org/html/2409.00899v2

[3] https://arxiv.org/abs/2404.13161

[4] https://github.com/gpac/gpac

[5] https://git.kernel.org/stable/c/ce4f77bef276e7d2eb7ab03a5d08bcbaa40710ec

AI会有一天取代白帽黑客吗？6月16日，专注纯粹技术交流的全新网络安全闭门沙龙 deepsec.cc (Deep Security Closed-door Conference)，DARKNAVY 将在现场继续深入探讨 Argusee：

阅读原文

跳转微信打开

从微信看IM软件客户端背后的安全博弈

从白宫幕僚到战地记者，即时通讯软件（IM）是无数关键人群不可或缺的沟通工具。无论是WhatsApp、Telegram，还是微信、QQ，它们已经成为现代社会的“数字血管”，承载着数十亿用户的社交、支付与办公等核心业务，其安全性直接关联个人隐私、金融资产，乃至国家安全。

事实上，关于IM的安全研究早已展开。2019年Project Zero披露了iMessage中的CVE-2019-8641漏洞^[1]，该漏洞是一个内存破坏问题。iMessage会自动解析消息中的富媒体内容，攻击者仅需发送恶意构造的文件，即可在无需用户交互的情况下实现远程代码执行，完全控制目标iPhone设备。

DARKNAVY将在本文中以微信为例，从URL解析、文件处理、网页访问等典型场景出发，系统梳理即时通讯客户端的关键攻击面，剖析攻防背后的博弈。

DARKNAVY发现的微信安卓客户端持久化攻击案例

从体系架构出发，即时通讯软件的攻击面可划分为三个主要维度，分别是客户端层面、通信协议层面以及云端服务层面。本文将重点分析客户端的攻击面，探讨其中可能导致远程代码执行或敏感信息泄露的安全问题。

为提升用户体验，IM客户端通常集成自有文件解析逻辑以实现格式预览与内容提取。攻击者可通过构造特制的恶意文件，利用解析功能的漏洞实现远程代码执行。例如，CVE-2019-11932^[3]和CVE-2025-30401^[4]分别是WhatsApp Android客户端和Windows客户端中的严重漏洞，前者通过恶意GIF文件触发攻击，后者则通过伪装成图像的可执行文件诱导用户执行。

多数IM客户端内置浏览器以支持网页访问，通常采用基于Chrome的自定义内核。其攻击面主要集中在两类技术路径上：

• 一是JSBridge，若客户端未对暴露给网页接口进行精细化权限控制，则可能被恶意网页调用实现权限滥用；

• 二是浏览器内核漏洞，例如，DARKNAVY团队于2023年发布的预警^[5]中指出，源于Chromium内核中libwebp组件的漏洞CVE-2023-41064 & 4863，影响包括微信、钉钉、QQ在内的多个主流IM软件。

CVE-2023-41064 & 4863漏洞影响Windows平台微信客户端

为拓展服务边界，微信、钉钉等IM客户端纷纷开放小程序平台，赋予第三方开发者丰富的系统权限，如文件系统访问、传感器调用、API接口使用等。然而，若客户端在权限管理或功能实现上存在疏漏，攻击者可借助恶意小程序实施攻击。

DARKNAVY团队对微信客户端的攻击面进行了初步调研，下面将从多个维度介绍微信客户端面临的主要安全风险及其应对机制。

show_webview_version展示的版本信息

安卓微信使用自研的 XWEB 内核，基于 Chromium 开发。截止本文编辑时，内核开发版的Chromium版本是134.0.6998.136，而现网版本是130.0.6723.103，而Chrome官方浏览器的版本是136.0.7103.93。XWEB保持了相对领先的内核版本，不过仍存在一定的滞后性，有可能受未修复的公开漏洞影响。

为防止滥用，微信客户端在加载网页时会根据URL向云端请求权限列表，以精细化控制每个JSBridge接口是否可用。在某些特定官方测试页面上，大多数接口默认开放，而在其他页面中，仅开放少数接口。此种基于页面来源的权限划分策略，有效限制了潜在恶意网页的破坏能力。

addToPagePool添加渲染层的JSAPI

微信作为国内最具代表性的IM软件，在安全机制上体现出多层防护与权限细化管理的设计思路，如JSBridge精细授权、浏览器沙箱隔离、小程序双线程架构等，体现出其对安全风险的高度重视。

作为长期关注即时通讯软件安全的研究团队，DARKNAVY始希望通过持续的漏洞研究、攻防分析与技术分享，推动IM生态在保障用户体验的同时，更加稳健、安全、可信地向前发展。

本研究内容已入选专注纯粹技术交流的全新网络安全闭门沙龙 deepsec.cc (Deep Security Closed-door Conference)，将于6月16日在现场深入探讨。

阅读原文

跳转微信打开

https://abcd.darknavy.org

2024年6月，DARKNAVY在《「AVSS研报」原生Android及鸿蒙黑灰产对抗能力初评-应用篇》里预告了自研的HarmonyOS NEXT原生应用反编译器发布，经过近一年的优化与实战验证，今天反编译器 .abcD （方舟字节码文件 .abc Decompiler）发布试用。

随着HarmonyOS NEXT纯血鸿蒙操作系统的快速演进，鸿蒙生态对原生应用分析能力的需求也不断增加。由于鸿蒙开发语言ArkTS采用全新的编译器、指令集、文件格式和运行时，过往的程序分析工具全面失效。

因此，2024年我们开始构建HarmonyOS NEXT原生应用反编译器，以辅助鸿蒙生态安全研究人员快速高效地进行风险评估。

欢迎在线试用 https://abcd.darknavy.org

目前 .abcD 反编译器已具备较完善的处理能力，能够为应用的逆向分析提供坚实可靠的支持，且已在大量实际分析场景中得到了充分验证。下图即是DARKNAVY利用自研的应用解密技术和 .abcD 反编译器，对鸿蒙应用市场内最新版本“小艺”（发布日期 2025-04-21）的反编译结果：

“小艺”的AbilityStage反编译结果示例

在实战验证 .abcD 反编译器的过程中，我们也发现了许多有趣的问题，下面以HwMapKit 华为地图服务为例说明。

HwMapKit应用中的MapService.hap包含 OfflineDataServiceAbility，负责管理离线地图数据。在系统版本5.0.0.150 SP8中，该ServiceAbility的RPC接口没有对调用者做任何权限校验，普通三方应用都可未授权访问。

其中的一个RPC功能是

COMMAND_JS_BRIDGE

，如下图所示，该功能会接收调用者可控的字符串参数作为JSON解析，并将调用者可控的moduleName字段拼接到import函数的参数中：

之后根据同样为调用者可控的className、methodName、params字段在导入的模块中创建任意类实例、调用其任意方法，且参数可控。

用代码来描述这一强大的漏洞原语就是：

new (await import('../../jsbrige/module/' + moduleName))[className]()[methodName](...params)

经测试，moduleName可以路径穿越从而导入其它路径下的模块。目前，最新版本的HwMapKit应用已对RPC接口添加了权限校验：

生态安全需要开发者的共同参与。DARKNAVY发布 .abcD ，期望能够为鸿蒙开发者提供一台「代码显微镜」，通过精准的反编译支持，让应用在逆向工程视角下也能经得起检验——这或许微小，但终将推动鸿蒙生态安全基线的持续进化与提升。

点击阅读原文，立即试用

⬇️

阅读原文

跳转微信打开

2024年，由私钥泄露引发的Web3安全事件频发，总计造成了高达8.55亿美元的巨额损失。

私钥作为账户的唯一凭证，直接关联链上所有资产（加密货币、NFT等）。由于区块链的去中心化特性，丢失私钥即永久失去账户控制权，泄露则导致资产被盗。硬件钱包通过离线存储私钥、采用安全芯片等技术，成为资产保护的主流选择。

但当黑客的指尖触碰到硬件钱包金属外壳的瞬间，数字深渊的潘多拉魔盒会被打开吗？

在本篇攻防速写中，我们将从攻击者视角梳理DARKNAVY对Web3硬件钱包开展的一点研究。

DARKNAVY对流行Web3硬件钱包的破解

市面上的主流硬件钱包形态各异，几乎都标榜自身具备严密的安全设计。然而，这些所谓的安全设计未必真的如宣传所言，甚至可能在某些情况下引入新的安全隐患。虽然硬件钱包通过离线签名、简化功能等方式收束了许多攻击面，但是这并不意味剩下的攻击面的安全性就会得到保障。

由于硬件钱包的离线特性，在实际交易过程中，需要外部（如浏览器、手机APP等）向钱包发送待签名的数据、并将签名结果广播至区块链或提交给其他应用使用。还有一些小屏（甚至没有屏幕的）钱包仅在APP侧提供设置页面，具体参数的配置也依赖APP传输给钱包。

基于对主流硬件钱包的分析，我们梳理了钱包与外部常见的连接方式及其暴露的安全风险。

首先是三类双工通信的方式——USB、NFC、蓝牙。

这三类方式在数据通信协议、数据处理中均可能存在漏洞风险，会导致内存破坏、敏感信息泄漏等问题。当攻击者具备物理接触设备的条件时，这类通信接口可能会引入安全风险：

• USB ：部分钱包可以将自己模拟为U盘，增大了攻击面；部分钱包能够进入bootloader模式，在此模式下可通过USB操作更多底层功能。
• NFC：NFC通信容易受到中间人攻击，但对物理距离有限制。中间人嗅探数据后，可能解析出通信中的敏感信息。
• 蓝牙：蓝牙通信本身存在多种风险点，如配对劫持、中间人攻击、数据嗅探等，且其距离限制相比NFC宽松许多。

硬件钱包的SD卡模式

这几种通信方式将离线的钱包连接到联网的设备，因此也引起了一些用户的担忧：外部设备和钱包到底在传输什么数据？如果设备已沦陷，钱包是否还安全？又或者钱包与APP自带后门，建立连接后会悄悄上传钱包的数据？

为了打消这些顾虑，硬件钱包厂商提出了 "Air Gapped" 的概念，将联网设备与钱包物理隔离。主要有两种传输方式符合这个概念，它们都需要用户操作才能进行一次单向数据传输。具体操作流程和风险如下：

• 二维码：客户端首先将待签名的内容转换为静态或动态二维码，使用带摄像头的硬件钱包扫码获取数据并确认签名，最后再用客户端扫描硬件钱包上展示的二维码。在图片解析、二维码识别的过程中，可能会出现内存破坏问题。
• SD卡：客户端和硬件钱包通过单张SD卡传输特定格式的签名请求和签名结果文件。在解析文件格式时，可能会出现内存破坏问题。

除了通信过程暴露的攻击面，部分硬件钱包还提供了固件升级接口（常见于USB、蓝牙、SD卡模式），升级过程中会计算hash和验证签名来确认固件的完整性和真实性，并判断版本防止回滚。如果升级流程实现不善，攻击者有可能能够向硬件钱包刷入恶意固件或包含漏洞的旧版固件。

固件升级过程

此外，虽然大多数硬件钱包使用了安全芯片来存储私钥，但其仍面临侧信道或硬件故障注入等物理攻击手段。

下文将从攻击者的视角梳理USB以及NFC两个攻击面。

许多硬件钱包可以通过USB接口与电脑或手机进行通信。基于底层USB HID协议，各硬件钱包又实现了专有的应用层协议，定义了各种指令、响应的格式。我们将以Cypherock X1钱包为例，梳理USB连接中的攻击面。

X1中运行的是实时嵌入式系统，系统会处理外界发起的USB请求。X1一次完整的USB命令调用由桌面端应用cySync发起，通过SDK提供的接口将请求序列化后通过USB发送给X1钱包，钱包侧响应请求返回数据包，重复这样的过程直到命令完成。

通过命令行与X1钱包进行USB通信

X1钱包内置多个applet。通过USB事件回调读取请求中的applet_id后，X1调用对应的applet进一步处理请求。

从攻击者的视角来看，我们更关注在设备与外界通信的相关逻辑上：设备通过事件回调响应请求，将protobuf数据解析为结构化数据进行处理；请求数据处理完成后直接调用API向cySync返回响应。 在这个过程中，若X1钱包解析处理外界请求数据时缺少严谨的安全检查，就有可能被攻击者进行恶意利用。

NFC技术以其即触即用的特性便利了现代生活，部分硬件钱包同样支持NFC，相比于门禁普遍使用仅有存储功能的M1卡片，硬件钱包通常使用可以完成更复杂认证逻辑的CPU卡，下面介绍我们针对Tangem钱包中NFC模块的研究：

Tangem的NFC交互分为不加密、Fast加密、Strong加密三种模式，默认交互采用不加密模式，该模式下仅对数据进行序列化处理，只有在收到卡片的NeedEncryption响应后才切换到加密模式，这也给攻击者获取明文信息提供了便利。

NFC可以分为Tag侧和Reader侧，站在攻击者视角，我们可以伪造成任意一方与另一方进行通信。

在每次打开Tangem APP后，我们都需要进行两次刷卡操作。如上图所示，我们嗅探到第一次刷卡时NFC的交互数据。在流程化的SELECT_UID和SELECT_AID操作后，Reader侧发送了ReadCommand指令，卡片收到指令后返回card信息和walletData信息。

如上图所示，ReadCommand指令需要Pin、InteractionMode、TerminalPublicKey三个参数。但卡片对该指令的Pin参数并不进行校验，因此攻击者可以伪装成Reader，仅需轻“碰”一下卡片即可读取到card信息和walletData信息：

card=Card(cardId=AFXXXXXXX16XX383, batchId=AFXX, cardPublicKey=[2, 125, -88, -93, 112, -60, 90, 105, 85, -29, -21, -37, -100, -50, 83, 75, 106, 62, -84, 104, -35, 112, 104, 1, -109, -67, 55, 51, 100, -5, -59, -8, -25], firmwareVersion=, manufacturer=Manufacturer(name=TANGEM, manufactureDate=Fri Oct 18 00:00:00 GMT+08:00 2024, signature=[-17, -56, 106, 82, -107, 7, 25, 105, -126, -69, -110, -50, -105, -120, 123, -106, -18, -121, -37, -79, 2, -39, -18, -116, 105, 7, 102, 4, 113, 97, 93, 14, 30, 65, -69, -12, -67, -41, -60, -12, 68, -1, -6, 82, 121, 50, -61, 91, 93, -112, 75, -42, -66, -113, 118, -19, -102, -62, 75, 100, 101, -4, -62, -40]), issuer=Issuer(name=Tangem 2.0, publicKey=[2, -120, 89, -52, -60, 36, -73, -17, 103, 107, -110, -36, 3, 110, -122, 72, 43, -38, 8, 30, -50, 25, -23, -17, 38, 94, 5, -112, -20, 9, 54, -24, -32]), settings=Settings(securityDelay=15000, maxWalletsCount=20, isSettingAccessCodeAllowed=true, isSettingPasscodeAllowed=true, isRemovingUserCodesAllowed=false, isLinkedTerminalEnabled=true, isBackupAllowed=true, isKeysImportAllowed=true, supportedEncryptionModes=[Strong, Fast, None], isFilesAllowed=true, isHDWalletAllowed=true, isPermanentWallet=false, isOverwritingIssuerExtraDataRestricted=false, defaultSigningMethods=null, defaultCurve=null, isIssuerDataProtectedAgainstReplay=false, isSelectBlockchainAllowed=true), userSettings=UserSettings(isUserCodeRecoveryAllowed=true), linkedTerminalStatus=None, isAccessCodeSet=true, isPasscodeSet=false, supportedCurves=[Secp256k1, Secp256r1, Ed25519, Ed25519Slip0010, Bls12381G2, Bls12381G2Aug, Bls12381G2Pop, Bip0340], wallets=[], attestation=Attestation(cardKeyAttestation=Skipped, walletKeysAttestation=Skipped, firmwareAttestation=Skipped, cardUniquenessAttestation=Skipped), health=0, remainingSignatures=null, backupStatus=Active(cardsCount=1))walletData=null

这两个信息本身并不包含过多敏感数据，于是我们又对第二次刷卡进行了嗅探。

在第二次刷卡时，Reader侧发送了ReadWalletsList指令。卡片在接收到该指令后会校验其中的Pin参数，成功后返回所有的CardWallet信息，失败则返回6A F1的错误码。

如此看来，通过返回数据爆破Pin是一个可能的攻击场景。幸运的是，厂商也同样识别到了这种风险，为了缓解该风险，厂商在卡片的固件中增加了security delay逻辑：在6次失败后，每多失败一次，都会导致卡片的响应时间增加1秒。不过据客户端源码中的注解所述，该逻辑是在1.21版本中才被引入。但由于Tangem没有为卡片实现固件升级功能，这也意味着该版本前购买的Tangem硬件钱包在卡片失窃的情况下更容易被爆破出关键的Pin信息。

Tangem共提供了33个自定义的NFC功能，除了功能逻辑上出现的问题外，卡片侧可能存在的内存问题同样是潜在的攻击面。

区块链世界的资产迁徙永不停歇，而硬件钱包所承载的，早已超越物理芯片与加密算法的简单叠加，它是人类将‘信任’托付给代码的终极实验。

当攻击者开始以手术刀般的精度剥离硬件防护层时，这场实验的残酷性才真正显现：一处未被觉察的缓冲区溢出、一颗未彻底物理隔离的安全芯片、甚至一行注释失误的固件代码，都可能成为颠覆整个信任体系的致命支点。这场关乎万亿资产的攻防战里，DARKNAVY的研究不会止步。

阅读原文

跳转微信打开

人类驯化灰狼的历程，是一部跨越四万年的文明契约——我们用火把与耐心褪去它们眼中的野性，让獠牙化为守护家园的忠诚。

当美国的波士顿动力和中国的宇树科技创造的各式机器狗在聚光灯下灵巧翻跃时，这种古老的共生关系似乎被赋予了赛博时代的注解：曾经需要上万年基因筛选达成的信任，如今仅凭一行代码就能让钢铁之躯俯首听命。

多年来持续通过 GEEKCON/GeekPwn 关注机器人/狗安全问题的 DARKNAVY 很好奇：当我们把缰绳从血肉换成数据线，那些蛰伏在算法深处的“漏洞野性”是否正在重演进化史？被黑客劫持的机器狗会不会突然撕开温顺表皮，瞳孔里闪烁的不再是0与1的秩序，而是越狱机械狼的幽蓝冷光？

GeekPwn 2022 比赛现场，选手通过利用 UWB 模块

数据包校验设计缺陷，实现对宇树机器狗 GO1 劫持控制

2022年极棒我们曾验证宇树机器狗存在可以被远程劫持的安全漏洞，联络宇树进行负责任披露（但未收到回复）。2023 年 7 月，宇树发布了新一代机器狗 GO2，其具备更先进的处理器、传感器以及 AI 能力。新版机器狗在安全性上是否有更好的表现？

在本篇攻防速写中，DARKNAVY 团队将分享对宇树机器狗 GO2 的初步安全和越狱探索。

GO2攻击面概览

GO2 机器狗在运行过程中，主要涉及与 Mobile APP 和 Cloud Service 的交互。同时，设备内部的各个模块、服务之间，也会通过数据分发服务中间件进行协作。

GO2系统架构图 ^[1]

GO2 与移动端交互的功能接口最为丰富，是重要攻击面之一。机器狗和 Mobile APP 之间有两种连接模式：

• AP 模式：手机直接连接机器狗自带的热点。
• Wi-Fi 模式：手机辅助机器狗配网，连接至已有的 Wi-Fi。

无论采用哪种模式，APP 和 GO2 设备都会建立一个 WebRTC 连接进行通信，该连接用于传输音视频数据、设备状态信息、以及一些控制指令。值得注意的是，任一客户端只要与 GO2 位于同一网络下，就可以在不需要用户特定凭证的情况下，与设备直接建立起 WebRTC 连接。只有在通过云端中继服务器进行远程连接时，才需要提供用户名和密码。

除此之外，其他一些攻击面同样值得关注：GO2 的 OTA 模块基于 Paho MQTT 实现，主要用于从云端的 MQTT 服务器获取系统更新推送，该过程可能存在认证问题以及后门风险；GO2 在与 APP 进行前期通信和配网操作时使用蓝牙协议，这与许多 IoT 设备类似，可能存在蓝牙认证与解析问题。

对 GO2 的端口进行扫描后，我们发现在默认状态下仅有 9991 端口开放，其用于在 WebRTC 连接建立初期接收客户端的信令消息。

GO2 Pro 端口扫描

为了理解用户与机器狗的交互逻辑，我们基于网上公开的 1.0.24 版本历史固件，对 GO2 使用的 WebRTC 协议和 DDS 协议做了进一步分析。

01

WebRTC协议

WebRTC 是 Web 实时通信（Real-Time Communication）的缩写，协议规定了两个 WebRTC Agent 如何协商并进行双向安全实时通信。WebRTC 本身主要强调的是端到端（Peer-to-Peer，P2P）通信，中心服务器并不是必须的，但在实际使用过程中也常会使用信令服务器（Signaling Server）、中继服务器（TURN Server）等。除了进行音频视频等媒体传输，WebRTC 也支持建立 DataChannel 进行数据传输。

GO2 的 WebRTC 客户端实现位于固件中 webrtc_bridge 模块的 /unitree/module/webrtc_bridge/bin/unitreeWebRTCClientMaster文件内。该服务像一个"中转站"，其注册了一系列 DDS Topics，在接收到APP发送的消息后，可通过 DDS DataWriter 将用户请求进一步转发给其他模块进行处理，在使用 DDS DataReader 获取到其他模块处理结果后，再通过 WebRTC 信道将各类数据传回APP。

我们在PC上使用开源的 go2_webrtc_connect 工具^[2]，可以在局域网下成功与 GO2 机器狗建立连接（此时 APP 会连接失败）。在此基础上，研究人员可以模拟 APP 与 GO2 设备的交互行为，从而对相关功能接口进行测试。

局域网下与 GO2 机器狗成功建立 WebRTC 连接

02

DDS协议

DDS 是数据分发服务（Data Distribution Service）的缩写，这是一种以数据为中心的发布-订阅通信协议，采用分布式的架构，通常没有中心服务器。机器人操作系统 ROS 2.0 引入了 DDS 中间件，用于替换原本 ROS 1.0 自研的发布-订阅机制。

在 DDS 协议中，Publisher 负责发布数据，其通过创建不同的 DataWriter 来向不同 Topics 发布特定类型的数据；Subscriber 负责订阅并接收数据，其通过创建不同的 DataReader 来订阅不同的数据类型。其中，Topic 由唯一的名称、数据类型、服务质量（QoS）策略集合来标识。

DDS 发布-订阅机制示意图

GO2 采用 CycloneDDS 协议，这是 ROS 2.0 的默认 DDS 实现之一。GO2 的各个服务之间通过 DDS 进行数据交互，其状态可以通过Mobile APP的相关界面查看（如下图）。此外，宇树官方提供的 SDK 工具^[3]也允许用户直接与这些服务创建的 DDS Topics 进行交互，从而支持更深入的研究测试和二次开发。

Unitree GO APP 服务状态列表

历史越狱分析

事实上，已有开发研究者社区致力于 GO2 机器狗的越狱等研究^[4]。用户在机器狗越狱后可以获取 root 权限 shell，使得基础版本的机器狗能够解锁更高级别 EDU 版本的一些特性，从而拥有更大的二次开发自由度。

GO2 Pro 机器狗

DARKNAVY 对已失效的第三方越狱工具 PawRoot 进行了技术分析，完整还原了其攻击链实现逻辑：

1. 建立连接
   通过用户指定的 GO2 设备 IP 地址建立 WebRTC 连接，为后续指令传输创建通信通道。
2. 检测版本
   向 GO2 的 WebRTC 客户端发送消息（type="req"，topic="rt/api/bashrunner/request"），触发 bash_runner 模块，执行内置的 get_whole_packet_version.sh 脚本，以验证设备固件版本是否在越狱工具支持范围内。
3. 替换脚本
   发送 type="rtc_inner_req" 的控制消息，并在 data 字段中指定 req_type="push_static_file"，实现文件上传并覆盖设备内置脚本 test_success.sh。
4. 获取SSH权限
   再次触发 bash_runner 模块，执行被替换的 test_success.sh 脚本：对 root 用户密码进行重置，并修改 /etc/ssh/sshd_config 配置文件允许 root 登录。
5. 还原文件
   完成上述越狱操作后，自动还原所篡改的脚本文件。

PawRoot 涉及组件

其中，第 2、4 步利用的是 GO2 中 bash_runner 模块本身的特性，该模块可以执行特定目录下预设的一些功能脚本并返回结果。越狱的关键在于第 3 步，漏洞为可通过 WebRTC 向 GO2 文件系统上传文件，覆盖设备内的 bash_runner 脚本。完成越狱并重启设备后，即可通过 SSH 以 root 身份登录 GO2 系统。

越狱后 SSH 登录效果图

在 1.1.2 及更新的版本中，第 3 步所用的 push_static_file 操作接口已被官方移除，该越狱方案也就不再有效。但我们仍能从这一案例的分析中看到 WebRTC 及其相关模块安全设计与实现的重要性。

安全启动

GO2 机器狗采用 RK3588S 芯片，其原本的 U-Boot 程序会限制固件读取的地址范围（小于32MB），超过该范围的内容在读取时都会被替换为0xCC。

但对于较早发行的 GO2 机器狗（购买时的固件版本在 1.1.1 及之前），用户仍有办法通过改写 U-Boot 绕过上述限制，并使用 USB-Type-C 接口对设备固件进行提取和刷写操作。

具体来说，首先使用 USB 数据线将 GO2 机器狗与电脑连接，并在开机的同时长按左侧三个按钮中最右边的按钮，使其进入 Loader Mode，此时机器狗开机后不会站起。

GO2 Pro 主板

然后，在使用 rkdeveloptool^[5]工具备份原本的 U-Boot 镜像后，将经过补丁修改的 U-Boot 镜像刷入设备，从而允许读取任意长度的固件内容。重启设备并再次进入 Loader Mode 后，即可读出所有固件分区。

rkdeveloptool 显示固件分区信息

然而，对于较新发售的 GO2 机器狗，宇树官方为设备开启了安全启动（SecureBoot）特性。安全启动用于对系统中重要镜像文件进行完整性校验，从而防止相关镜像被篡改或替换。因此，上述基于 U-Boot 镜像打补丁的固件读取方法不再有效。从这一变化过程中也可看到厂商对设备安全的逐步重视。

结语

随着人工智能技术的飞速发展，智能机器人深度融入大众生活的未来已不再遥远。相比于传统的物联网嵌入式设备，这类智能机器人拥有更大的行为自由度，并且能够与周围的环境和人群进行更加复杂、多样的交互。历史经验表明，任何一个科技生态兴起的过程中，都必然伴随着新兴安全风险的涌现。

作为最早关注与实现 iOS、 Android 和鸿蒙越狱的团队和社区，DARKNAVY & GEEKCON 的初步探索发现，智能机器人和低空无人机领域类似，各类产品普遍的网络安全防御水平仍处在非常初期的阶段，我们愿持续站在模拟的攻击者视角，协助智能领域尽可能多、尽可能早的发现和消灭潜在失控的风险。

参  考：

[1] https://support.unitree.com/home/en/developer/Architecture Description

[2] https://github.com/legion1581/go2_webrtc_connect

[3] https://github.com/unitreerobotics/unitree_ros2

[4] https://wiki.theroboverse.com/

[5] https://github.com/rockchip-linux/rkdeveloptool

阅读原文

跳转微信打开

I think the human race has no future if it doesn’t go to space. —— Stephen Hawking

Starlink是SpaceX推出的低地球轨道卫星互联网接入服务，用户通过终端与近地轨道卫星建立连接，再经地面基站（Gateway）接入互联网。

Starlink系统的基本架构^[1]

随着新一代卫星逐步配备激光链路，部分卫星之间也能通过激光通信，从而在减少对地面基站依赖的同时，提高传输效率并增强全球覆盖能力。

在完全没有地面基站的乌克兰战场上，Starlink用户终端也能通过卫星间接使用邻国的Gateway接入互联网^[1]。

乌克兰境内的Starlink终端

通过卫星和邻国地面的Gateway接入互联网

在本篇攻防速写中，我们将简要介绍DARKNAVY前期对Starlink用户终端开展的初步探索。

硬件分析

一套完整的Starlink用户终端由路由器和天线两部分组成。本文的重点放在天线部分（User Terminal Antenna，后文简称 UTA）上。

DARKNAVY在新加坡购买了一台Starlink Standard Actuated（也称Rev3或GenV2）用户终端并对其天线部分进行了拆解。

Starlink UTA Rev3 PCB板（全貌）

如上图所示，拆解后我们发现，UTA的PCB板几乎和其外壳一样大，但其中大部分区域由ST公司生产的相控阵天线芯片所覆盖（上图的右侧部分）。

Starlink UTA Rev3 PCB核心部分

如上图所示，除射频天线之外，UTA核心区域的总体设计和常见的标准物联网设备非常相似。其主控SoC由ST公司为SpaceX定制，内部是四核Cortex-A53架构，目前该芯片的硬件产品和数据手册都处于保密状态，无法公开获取。

在2022年Black Hat USA大会中，鲁汶大学的Lennert Wouters博士曾展示过对第一代 Starlink 天线（GenV1）的故障注入攻击；SpaceX 随后在固件更新中关闭了PCB板上的UART调试串口，以提高对故障攻击的防御能力，但此后Wouters仍通过改进方法再次成功攻破^[2]。

固件提取与解析

为了深入分析UTA，DARKNAVY通过硬件手段直接从eMMC芯片中提取了固件内容。由于在Rev3版本中没有明显的eMMC调试引脚，我们只能将eMMC芯片从PCB上拆下，再使用编程器进行读取。

对提取到的固件进行解析后发现，其中大部分内容未经过加密处理，可获取到的信息包括启动链（BootROM除外）、内核以及未加密部分的文件系统。进一步分析后可知，内核启动后会从eMMC中读取主要的运行时环境，并解包至/sx/local/runtime目录下。

UTA核心运行时所在的目录

如图所示，bin目录下存放Starlink软件栈中所需的可执行文件，dat则保存配置文件，revision_info记录了当前软硬件的版本信息。除负责与用户通信的user_terminal_frontend（使用Golang编写）外，其他大部分程序均为C++编写的静态编译无符号可执行文件。

结合前人对上一代UTA的分析^[3]，我们对runtime目录下的这些程序和配置文件做了初步分析，发现其网络栈的架构与 DPDK 类似^[4]，主要依赖用户态的C++程序绕过内核来处理网络数据包，Linux内核主要作用为提供基础的硬件驱动和进程管理功能。

值得一提的是，我们注意到从UTA提取的核心软件中还包含了部分本应在卫星或地面基站上运行的程序逻辑。

初步逆向分析结果显示，系统在启动过程中会根据硬件外设信息来判断当前所属的设备类型，并据此加载和执行对应的逻辑。

模拟执行

为了便于后续对UTA的持续分析，DARKNAVY基于QEMU为Rev3设备固件构建了基本的模拟运行环境：

在该模拟环境中，我们成功实现了对部分程序的运行和调试，主要包括httpd、WebSocket、gRPC等与外界交互的服务。

在模拟环境中对user_terminal_frontend程序进行动态调试分析

安全芯片

除了主控SoC，UTA还使用了一款声称达到CC EAL5+安全等级的专用安全芯片STSAFE-A110^[5]。与主控SoC不同，这款芯片可以在签署NDA后合法购买。在UTA 的固件中，有一个名为stsafe_cli的用户态程序与其交互。通过对该程序的逆向分析可以推测，STSAFE主要提供以下功能：

• 储存每台设备独有的身份标识（UUID）
• 管理公钥证书（stsafe_leaf.pem），可能用于与卫星通信中的身份认证
• 派生用户数据通信时的对称加密密钥

总体来看，这颗安全芯片相当于在SoC安全启动之外又增添了一个独立的信任根，这也是现代嵌入式系统常见的安全设计。

彩蛋：Is Elon watching you?

DARKNAVY在分析过程中偶然发现了一个用途为Ethernet Data Recorder（以太网数据记录器）的程序：

这个程序的名字和功能介绍很容易让人怀疑这是一个记录用户数据的后门程序，进一步分析发现其内部使用了类似pcap_filter的机制记录网络中的特定数据包，抓包格式类似：

# name            track   options                type    interfaces       pcap_filterdiagnostics       0       compress,ipcompress    telem   lo               udp and dst port 10017 and (dst host 239.26.7.131 or dst host 239.26.7.130)

结合固件中其他文件的线索，这些数据包均与卫星的遥测（Telemetry）功能相关。同时，所有采集到的流量也会使用SoC熔丝中的硬件密钥进行加密。基于目前掌握的信息，我们认为它暂未用来收集用户隐私数据 :)

另一个有趣的现象是，在设备初始化时，若检测到当前设备属于用户终端，初始化脚本会自动将多达41个SSH公钥写入/root/.ssh/authorized_keys。值得注意的是，UTA的22号端口对局域网始终处于开放状态，在用户侧的产品上添加如此多的不明登录密钥，也不禁让人“想入非非”。

结语

随着卫星技术的不断成熟演进和在各行各业中的推广应用，Starlink和其他卫星互联网系统架构中的每一个组件都可能成为未来攻防的重要战场。在太空安全中，开发者与黑客不仅要在数字层面展开攻防对抗，还要面对宇宙物理规则的限制和挑战，一招不慎可能就与自己的目标永远失去了联系。

参  考：

[1] https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2024/pdf/BRKSEC-2150.pdf

[2] https://i.blackhat.com/USA-22/Wednesday/US-22-Wouters-Glitched-On-Earth.pdf

[3] https://blog.quarkslab.com/starlink.html

[4] https://www.dpdk.org/

[5] https://www.st.com/en/secure-mcus/stsafe-a110.html

阅读原文

跳转微信打开

发现攻击者和受害者都破绽百出（附视频）

阅读原文

跳转微信打开