文章总结： 本文分析豆包手机助手技术架构与安全机制，指出其系统级权限虽便利但引入新攻击面。除阐述认证加密策略外，重点揭示了GUITOCTOU时间差与界面文本提示词注入两大风险，攻击者可诱导智能体泄露信息。结论强调AI智能体行动能力与安全建设必须同步发展。 综合评分： 86 文章分类： AI安全,移动安全,漏洞分析,应用安全

当 AI 助手成为黑客攻击链的一环 | 豆包手机安全分析

幻泉之洲

2026年3月5日 17:13 北京

当手机不仅能回答问题，还能替你打开App、比价、下单时，控制权就从用户指尖移交给了AI智能体。本文将深入分析豆包助手的技术实现、安全机制，并指出其背后潜藏的隐私与安全风险。

你的手机不再只是帮你叫份便宜外卖这么简单了，它现在可以自己动手。打开应用、比价、完成支付——控制权正从用户的手指，移交给一个能“看见”屏幕、进行规划并执行任务的智能体。

智能体接管手机

2025年底推出的豆包手机助手，率先将手机的完整操作链交给了AI智能体。它用大语言模型做决策大脑，结合GUI Agent技术，能理解用户意图、分解任务、规划路径，并以系统级权限执行复杂的跨应用、跨场景操作。

但这同样将手机AI置于两个风险领域的交汇点：既要面对传统的移动安全问题，又要应对智能体引入的新攻击模式。攻击者不再需要诱骗用户额外操作，他们可以轻松地将智能体的规划引向歧途，让看似正常的行为演变成窃取用户信息的攻击链。

根据DARKNAVY的评估，尽管豆包助手在安全和隐私上做了多方面考虑，但实际可利用的风险依然存在。例如，攻击者通过发送恶意信息，在助手正常使用过程中误导并劫持它，从而窃取如手机银行验证码等敏感信息。

豆包助手如何工作

豆包手机运行的是基于Android深度定制的Obric系统。AI相关功能由一套系统级应用提供：

• ObricAiAgent：豆包助手的主应用。主进程搞能力调度和任务编排，子进程管唤醒事件、声纹识别等。
• ObricAutoAction：核心的自动化模块，负责把用户意图翻译成可执行的操作序列。
• AIKernel：端侧模型推理基础设施。
• MemoryData：记忆管理模块。
• AIVoiceService：语音能力模块。

其中，ObricAutoAction是实现“自动干活”的关键。用户提交的任务，最终会封装成AutoOperateTask，然后通过一条层层下发的链条执行：AutoOperateTask → AOSession → AOAgent / AOStep → Action / Operation。

举个例子，你在豆包助手的聊天界面输入“打开百度地图导航到佘山”。它会先捕获当前手机屏幕，连同一些辅助信息（上下文、设备参数、位置等）一起发给云端模型推理。模型返回结果，比如“打开目标应用”。

每执行完一个动作，豆包助手再次截屏，评估当前任务状态。如果没完成，就把最新的屏幕状态再次发给云端，请求下一个动作指令。通过这种“感知 → 推理 → 执行”的循环，整个任务被一步步规划和执行：打开百度地图、在搜索框输入“佘山”、点搜索、让用户澄清具体目的地、点“开始导航”按钮。

安全机制：守得严吗？

初步分析下来，豆包助手的安全架构整体很扎实，没发现结构性缺陷。但它毕竟是个拥有系统级权限的“超级应用”，如果认证出问题或权限被滥用，对用户隐私和系统完整性的威胁是致命的。

我们对豆包相关应用的认证方式做了检查，Android应用层面的权限控制比较到位。暴露的功能接口会通过UID、包名、应用签名等多重校验，还配合策略文件进行细粒度的约束。第三方应用想滥用豆包的超级权限？不太容易。

比如在ObricAiAgent里，关键的调度服务ScheduleService就通过SecurityManager做了统一认证控制。虽然有允许特定应用触发行动的后门，但在执行前，必须经过策略文件的检查。策略逻辑不复杂，但严格执行。文件放在私有目录，第三方应用没法直接篡改，这套认证设计大大降低了恶意应用乱用助手能力的机会。

云端交互呢？豆包助手用了字节自研的通信库。端到云的通讯链，依靠受TEE保护的客户端私钥来实现mTLS双向认证，能有效防范设备侧的中间人攻击，确保每次到云端的请求都来自真实的物理设备。

在这个基础上，豆包助手在客户端和云端都制定了比较审慎的AI安全隐私策略。

• 一般场景

  ：需要云端推理或操作验证时，手机截屏，压缩后上传。根据其安全白皮书，云端不会用这些截图数据来训练模型或永久存储。

• 敏感界面

  ：对于标记了FLAG\_SECURE的界面（隐私设置、视频播放、支付界面等），助手在执行时不截取真实屏幕内容，而是用一张不包含任何敏感信息的本地占位图传给云端做推理，再补充必要的上下文信息来保证任务继续执行。这个设计回应了很多人担心的“后台偷偷上传密码截图”问题。

• 行为约束

  ：助手的自动化操作能力和云端策略引擎双向绑定。比如，因为隐私保护和应用厂商合规要求，豆包助手目前不能在微信、支付宝上进行自动化操作。对于手机银行这类高敏感应用，自动化更是被明确禁用。如果任务涉及支付、身份验证，或需要用户填写关键信息，云端策略引擎在执行前就会拒绝任务，或者弹出界面让用户手动完成。实测也表明，它会明确要求用户手动输入手机验证码，不会替你填。

两个关键风险点：GUI TOCTOU与提示词注入

虽然豆包助手做了不少防御，但我们认为有两个点仍存在潜在的、可被利用的风险。

1. 幽灵点击：GUI TOCTOU风险

TOCTOU，也就是“检查时”和“使用时”的时间差风险。AI要干活，得先截屏分析，然后根据分析结果去执行。这个“先分析后动手”的流程，天然就存在一个时间窗口。万一就在这几秒里，用户手动点了别的应用或者界面刷新了，AI就可能凭着过时的判断，点到不该点的地方。

这是所有GUI Agent架构目前都难以根除的固有风险。研究发现，这个时间窗口主要产生在“云端推理”这步，通常需要2-3秒。豆包助手没有在后续执行阶段设计自动回滚或警报机制。即使发现界面和预想的不一样，已经生效的动作也撤不回了。所以，避免点错的主要保护措施，都集中在执行前的验证检查阶段。

具体实现上，对于最容易引发问题的点击操作，豆包的OpClickUI引入了比较严的验证逻辑：执行前会检查顶层Activity有没有变化；检查之前三步操作里有没有启动应用的指令。如果发现有变化，就跳过本次点击。

另外，如果用户在同一个应用界面上手动操作，和自动化任务起了冲突，豆包助手会主动暂停任务，把控制权让给用户，这也进一步降低了误触风险。

不过得说回来，除了点击操作，像OpTypeText、OpSwipeUI这类操作单元目前还没实现类似的验证保护。虽然也可能点错，但这类操作缺少按钮级别的确认语义，造成的实际影响相对有限。

2. 从文字到图像的“迷惑”：提示词注入

提示词注入在AI领域已经不算新鲜事了，早期的聊天机器人就有被骗发邮件、搞破坏的案例。但在GUI Agent场景里，因为模型要同时解读图像和文本信息，潜在的注入路径和攻击面更大了。

更麻烦的是，由于上下文长度限制，随着场景切换、任务推进，模型保留初始用户意图的能力会逐渐减弱。这在一定程度上增加了后续注入攻击的成功率。

实际测试中，我们发现豆包助手的云端模型具备一定的提示词注入防御能力，也排除了云端特殊令牌注入的风险。对于用户直接输入的任务描述，客户端也会通过checkPrompt函数拦截一些敏感关键词和典型的注入模式。

但问题在于，除了文本输入，模型看的主要是截图。截图里的文字信息，客户端目前没有额外的内容过滤或语义约束机制。这些文字信息会被完整地纳入模型的推理上下文，几乎完全依赖云端去过滤或隔离。

在实验环境下，我们通过精心构造屏幕上的文字，结合敏感词绕过技巧，能在特定条件下获取模型的系统提示词，甚至观察到提示词注入可能干扰云端的高风险操作检测逻辑，从而影响模型对任务目标和执行状态的判断。

文章开头那个窃取验证码的例子，就是基于这个风险模型：在一个合法的用户任务请求的执行过程中，如果模型持续受到界面上的外部内容（比如短信、邮件、网页内容）影响，它可能会在用户没有明确察觉的情况下，泄露某些个人信息，或被嵌入到更复杂的攻击链中，协助后续操作。

从另一个角度看，如果未来像豆包助手这样的智能体被赋予更强的安全意识和反欺诈能力，并且部署在老年人等“网络安全弱势群体”的设备上，它完全有可能变成一把正向的保护伞。

结论：智能体的“行动时代”，安全必须同步

超级智能体已经是行业发展的必然趋势。从OpenClaw等项目看，AI正被赋予更强的自主性和跨域执行力，深度融入日常生活到专业工作的各种场景。

在这个过程中，智能体安全框架的建设必须和功能演进同步跑。功能迭代或许日新月异，但安全漏洞一旦被利用，代价同样巨大。我们相信，面对AI技术带来的新挑战，只有在发展早期就洞察风险，并展开系统性的防御设计，才能真正实现大规模应用的可信与可靠。

模型能力在稳步迭代，但安全建设却没以同等速度跟进。

当AI只是“回答问题”时，风险还停留在文本层面；一旦它开始“动手操作”，控制权究竟在谁手里？

传统安全领域，攻防双方日夜不息地寻找边界、挖掘漏洞；而在AI安全领域，许多复杂状况最终都坍塌成一个相对廉价的提示词注入。它的门槛不高，成本不高，却至今没有一套系统性的解决方法。

当大家热烈讨论模型参数、榜单排名时，关于安全的系统性讨论，仍然稀少。

参考链接

• [1] GUI TOCTOU 风险研究 (https://arxiv.org/html/2601.12349v1)
• [2] Google 提示词注入风险评估 (https://security.googleblog.com/2025/01/how-we-estimate-risk-from-prompt.html)
• [3] Gemini 钓鱼攻击案例 (https://supertokens.com/blog/gemini-phishing-attack)
• [4-6] 提示词注入相关报告与防护 (bughunters.google.com, openai.com, embracethered.com)
• [7] 特殊令牌注入研究 (https://blackhat.com/eu-25/briefings/schedule/#token-injection-crashing-llm-inference-with-special-tokens-48830)
• [8] 豆包安全白皮书 (https://o.doubao.com/whitepaper)

如需查看原文，点击查看原文跳转链接。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《当 AI 助手成为黑客攻击链的一环 | 豆包手机安全分析》