从 Stagefright 到零点击间谍软件：移动安全十五年攻防史

2010 年代初，手机安全的浪漫叙事是“越狱以后我就是系统的主人”；十五年后，现实给这句话补了一行小字：系统里还有安全处理器、基带、GPU、虚拟机、云端风控，以及一群彼此都不完全信任的主人。

先给全文一个结论：iOS 和 Android 都比十五年前难攻得多，但手机并没有因此变得不值得攻。 恰恰相反，它同时保存身份、支付凭据、位置、相册、麦克风、双因素验证码和完整社交图谱。PC 上要翻几个目录才能拼出的生活，在手机上往往只需要一份通知数据库。

安全演进也不是“旧漏洞修完，新漏洞变少”这么平滑。平台把 WebKit、媒体解析器和 App 关进沙箱，攻击者就去找沙箱代理；内核加上控制流完整性，攻击者就去研究 GPU 驱动；页表受保护，攻击者甚至能从另一个协处理器的 MMIO 通道绕回来。门确实越来越厚，施工队也确实越来越专业。

本文讨论公开研究、授权测试和个人设备自检。不要把逆向工具用于未授权账户、付费功能或他人设备。 会让你坐牢的不是技术深度不够，通常是法律常识下线得太早。

移动安全从2010年至2026年的攻防演进 — 安全机制没有让漏洞绝迹，它们主要改变了“一个漏洞能换来什么”以及“还要再买几个漏洞”。

先拆掉一个误解：手机不是缩小版 PC

桌面系统通常围绕“用户运行程序”设计，手机则围绕“外界持续向设备投递事件”运转。一台锁屏的手机仍在接收蜂窝信令、推送通知、即时消息、图片预览、蓝牙广播、Wi-Fi 帧和基带数据。为了让你点亮屏幕时一切已经准备好，很多数据必须在你碰它之前被解析。

这形成了移动安全最关键的四个特征：

入口常驻。 浏览器不是唯一入口，消息预览、字体、图片、视频、PassKit、基带和 GPU 都处理攻击者可控数据。
权限被切碎。 拿到一个解析进程的代码执行，通常还看不到相册或麦克风；必须继续跨越沙箱、IPC 和内核边界。
密钥绑定硬件。 屏幕锁、文件密钥、支付密钥和生物特征越来越多地由 Secure Enclave、TEE 或 StrongBox 管理，root 不再天然等于“导出所有密钥”。
补丁是一条供应链。 iOS 由 Apple 垂直交付；Android 则要经过 Google、芯片厂、OEM 和运营商。漏洞修复速度不只由代码决定，也由组织结构决定。

所以判断一个漏洞严重性，不能只问“能不能崩”。至少要问五遍：输入能否远程到达？能否稳定控制内存？当前进程有什么权限？下一层隔离怎么过？重启和取证之后还能剩下什么？

2010–2014：能拿到内核，就像拿到了总钥匙

早期 iOS 已有代码签名、沙箱和数据保护，Android 从一开始也用 Linux UID 隔离 App；它们不是裸奔，只是防线还没有今天这么纵深。

iOS：越狱链就是攻击链的公开课

iPhone 的安全启动从芯片内不可变的 Boot ROM 开始，逐级验证低级引导程序、iBoot 和内核签名。这个设计今天仍是根基，Apple 的硬件安全概览把它称为硬件信任根。问题在于：如果最早的 Boot ROM 本身有漏洞，系统更新无法替换已经烧进芯片的代码。

2019 年公开的 checkm8 之所以具有标志性，不是因为“又一个越狱工具”，而是因为它影响 A5 至 A11 一代芯片，修复必须依靠新硬件。它也提醒了一个常被混淆的事实：可在 DFU 阶段执行代码，不等于自动解开用户数据。 Secure Enclave 的口令尝试策略和文件密钥仍是另一条信任链；物理访问、启动链失守、数据解密是三个不同命题。

iOS 的 App 可执行页必须有有效签名，entitlement 决定它是否能访问特定系统能力，sandbox profile 再限制文件、Mach service 和 IPC 范围。Apple 的运行时进程安全说明还列出了 ASLR、不可执行内存与 W^X。早期越狱通常需要把浏览器或文档解析漏洞、沙箱逃逸、内核漏洞串起来，然后修改内核的代码签名与沙箱决策。越狱社区在公开环境里反复演练了后来商业间谍软件采用的同一种结构，只是目标不同。

Android：开放不是没有边界，而是边界更多由集成质量决定

Android App 安装后拥有独立 UID，Linux 内核先隔离进程和文件；Binder 驱动负责跨进程传递对象句柄，framework service 再做权限检查。Binder 很像一个带对象能力的总机：客户端拿到的不是对方地址空间，而是一个由内核转发的句柄。问题出在总机接线员数量很多，system_server 又承载大量高权限服务。一次漏掉调用者身份、错误导出组件或 confused deputy，都可能让低权限 App 借系统服务完成自己无权做的动作。

Android 4.3 开始引入 SELinux，随后逐步进入 enforcing。传统 Unix DAC 只问 UID 能否访问对象，SELinux 则按 domain/type 和策略再问一次；即使进程拿到 root UID，也未必能跨过 MAC 规则。AOSP 的系统与内核安全文档将 UID 沙箱、SELinux、Verified Boot 和加密视为叠加关系，而不是四个互相替代的功能。

早期 Android 的另一个现实是 Dalvik、系统库和厂商驱动更新绑在完整 OTA 上。Google 修好了上游，用户手机不一定立刻拿到。这里埋下了后来 Stagefright 引爆的补丁生态问题。

2015：Stagefright 把“收到消息”改写成攻击面

Stagefright 是 Android 原生媒体框架。消息 App 为了生成视频缩略图，会把攻击者提供的媒体交给系统组件解析；当解析器位于权限较高的 mediaserver，一个整数溢出、越界访问或 use-after-free 就不只是播放器崩溃，而可能成为远程代码执行入口。

Zimperium 在 2015 年披露的 Stagefright 系列问题影响巨大，后续一年回顾记录了一个比漏洞编号更重要的变化：Google 在 2015 年 8 月启动首轮 Android 月度安全公告，主要 OEM 随后建立固定补丁节奏。Stagefright 2.0 又说明攻击面不止 MMS；浏览器或其他 App 只要调用同一套媒体解析能力，也可能触发恶意 MP3/MP4 元数据（Zimperium）。

这里有三层原理值得保留：

自动预处理会把“用户没打开”变成“系统已经解析”。 零点击不是魔法，通常只是某个后台服务替用户先点了。
共享系统解析器会放大单点缺陷。 多个 App 使用同一原生库，修复容易统一，爆炸半径也容易统一。
降低解析器权限比追求零 bug 更现实。 后续 Android 拆分媒体组件、收紧 SELinux 域和 seccomp，目的就是让入口漏洞不直接兑换全部权限。

同一时期，iOS 端也在进入商业化攻击链时代。Citizen Lab 2016 年披露的 Trident 通过一条恶意短信链接触发 WebKit 漏洞，再串联内核信息泄露和内核内存破坏，安装 Pegasus（Million Dollar Dissident）。它仍需要点击，却已经展示了成熟链条的标准配方：入口漏洞负责落脚，提权漏洞负责扩权，持久化与采集模块负责赚钱。

2016–2019：系统开始要求攻击者“多买几张票”

iOS：SEP、文件密钥和 PAC 把 root 拆成多个问题

Apple 的 Data Protection 不是给整块闪存套一个静态密码。文件被分到不同 protection class，文件密钥进入分层 keybag，并与用户口令和设备硬件绑定；锁屏状态会改变可用密钥集合。Secure Enclave 拥有独立启动链和 AES 引擎，长期密钥不需要暴露给应用处理器或内核。Apple 的加密与数据保护概览和Secure Enclave 文档描述了这套分工。

这会产生一个经常被营销材料抹平的区别：

能力	攻击者实际获得什么	仍然缺什么
App 进程代码执行	当前沙箱内存、文件和 IPC 能力	其他 App 数据、内核、硬件密钥
沙箱逃逸	更多系统服务或文件可见性	稳定内核读写、SEP 内部密钥
内核代码执行	控制主系统、绕过大量策略	SEP 的独立执行与口令约束
设备已解锁时的完整链	大量实时数据与传感器访问	不一定有持久化，也不等于可导出全部硬件密钥

A12 时代引入的 Pointer Authentication Code（PAC） 给返回地址和函数指针附加基于秘密密钥与上下文的短认证码。攻击者即使能任意写，也不能随手把控制流改到任意地址；他需要复用合法签名指针、找到签名 oracle，或建立不依赖传统指针劫持的原语。PAC 不是内存安全，它更像给部分控制流指针盖章。

Page Protection Layer（PPL） 进一步限制页表和关键内核数据的修改，后续 SPTM/TXM 把相关职责下沉到更高特权级。Apple 的操作系统完整性说明列出了不同芯片代际采用的 PAC、PPL 与 SPTM。攻击者开始面对一种新现实：有内核 bug，不代表能把任意内存页改成可执行，也不代表能关闭所有保护。

Android：Verified Boot、FBE 与 Treble 解决“谁在运行”和“怎么更新”

Android Verified Boot（AVB）从硬件信任根验证 boot、system、vendor 等分区，dm-verity 在运行时用哈希树检查块完整性，并通过 rollback index 阻止降级到已知易受攻击版本。启动状态的绿、黄、橙不是皮肤主题，而是在告诉系统和用户：信任根是否官方、bootloader 是否解锁（AOSP boot flow）。

加密方面，Android 5–9 主要采用整盘加密；Android 7 引入 File-Based Encryption（FBE），把 Device Encrypted 与 Credential Encrypted 数据分开。设备可以在用户首次解锁前启动闹钟、电话和必要服务，但敏感用户数据仍等待凭据派生的密钥。Android 10 起新设备必须使用 FBE，Android 9 又加入 metadata encryption（AOSP encryption）。

Android 8 的 Project Treble 把 framework 与 vendor 实现通过稳定接口拆开。安全意义不只是“升级更快”：过去 framework 更新常被硬件 HAL 的私有 ABI 卡住；Treble 通过 HIDL/Binder、VNDK 和分区边界降低耦合。Android 10 的 Mainline 又把媒体、Conscrypt、DNS resolver、权限控制器、ART 等部分做成 APK/APEX 模块，使关键组件可以绕过整机 OTA 更新（AOSP Mainline）。

这没有彻底消灭碎片化。GPU、基带和其他 vendor driver 仍可能走自己的补丁路径；但“修一个媒体解析器必须等待整台手机升级”的局面，至少不再是唯一选项。

2019–2022：漏洞没少到看不见，攻击链长到看不懂

Project Zero 2019 年公开了在真实网站中使用的五条 iOS 攻击链，覆盖 iOS 10 到 12，共包含 14 个漏洞：7 个浏览器漏洞、5 个内核漏洞和 2 个沙箱逃逸（Project Zero）。这组数据的重要性不在数量，而在结构：真实攻击者已经把多版本适配、漏洞选择、设备指纹和 payload 交付做成工程。

BlastDoor：把消息解析器搬进防爆间

iOS 14 引入 BlastDoor，把 iMessage/IDS 收到的不可信内容放进强沙箱服务中解析、转码和验证。它减少文件系统与网络访问，并要求输出经过结构化校验后才交给其他服务（Apple Platform Security）。

BlastDoor 的正确理解不是“iMessage 从此没有漏洞”，而是：

入口解析器即使被打穿，攻击者先落在一个权限极低的房间。
向外传递的数据格式被收窄，减少把解析器变成任意系统代理的机会。
攻击链必须再找到 IPC、共享缓存或邻接服务边界上的第二个缺陷。

FORCEDENTRY：在图片格式里造一台计算机

2021 年的 FORCEDENTRY 是移动安全史上最漂亮也最阴冷的案例之一。攻击样本伪装成 GIF，实际让 CoreGraphics 进入 JBIG2 PDF 解码路径。一个整数溢出导致分配尺寸小于逻辑位图，随后产生越界写。

到这里还只是“解析器有 bug”。真正惊人的部分是，攻击者利用 JBIG2 的逻辑操作，把数万个位图段组织成寄存器、加法器和比较器，在解码器允许的数据变换里搭出一台足以搜索内存、执行运算的 weird machine。Project Zero 的深度分析形容它本质上像在一种古怪架构上运行计算，而不是简单堆 ROP gadget。

这件事推翻了“数据格式不是编程语言，所以很安全”的直觉。只要解析器提供足够丰富的状态与操作，攻击者就会把格式语义拼成计算能力。 正则表达式、字体、图像、压缩流、shader 和 eBPF 的安全审计，都应该带着这个问题：这套输入语言是否意外拥有了可编程性？

现代移动端攻击链的五个阶段 — 一个 CVE 往往只负责其中一格。昂贵的是把每一格都做成对目标版本稳定成立。

Android 的现代攻击链：为什么 GPU 成了新内核入口

Android App 沙箱越来越严，浏览器自身又有多进程隔离。攻击者从 Chrome renderer 起步后，需要逃出浏览器沙箱，再进入更高权限服务，最后才有机会控制内核。

Project Zero 对 2022 年 Samsung 设备在野攻击链的复盘展示了典型路径：Chrome 0-day 负责 renderer 代码执行，另一个已公开但目标设备未及时修补的 Chrome 漏洞负责沙箱逃逸；随后 Mali GPU 漏洞帮助触达 system_server，最后通过 ALSA compatibility 和另一个 Mali 漏洞建立内核读写。

GPU 驱动受到青睐有三个原因：

它必须处理复杂、攻击者可控的命令和共享内存。 图形 API 表面上在画三角形，底层却是用户态与高权限驱动之间的大型协议。
驱动代码量大、状态复杂，很多来自芯片供应商。 修复需要经过上游、SoC 厂和 OEM 多段传播。
少数 GPU 覆盖大量机型。 Project Zero 统计 2021 年 7 个 Android 在野 0-day 中有 5 个针对 Qualcomm Adreno 或 Arm Mali（Project Zero）。对攻击者来说，研究一个驱动可能比适配几十个 OEM framework 更划算。

另一个经常被忽略的入口是基带。它运行独立实时系统，负责蜂窝协议，主 Android/iOS 并不能像普通进程那样完全监督它。Project Zero 2023 年披露 Exynos modem 的 18 个漏洞，其中 4 个可在攻击者只知道电话号码时实现 Internet-to-baseband 远程代码执行，无需用户交互（Project Zero）。基带失守不必然等于应用处理器失守，但它能监听或篡改无线侧数据，并可能成为跨处理器攻击的起点。

攻击面不会凭空消失，只会迁移到仍然必须解析复杂输入、又比主系统更难更新的地方。

2023–2026：当页表上锁，攻击者从另一块硬件绕进去

Operation Triangulation：硬件缓解也依赖完整硬件地图

Kaspersky 的 Operation Triangulation 是理解当代 iOS 利用最好的公开样本。整条链包含 iMessage 零点击入口、JavaScriptCore 漏洞、内核物理内存读写、PAC 绕过和 PPL 绕过。研究者分析了约 1.1 万行混淆 JavaScript，最终发现最诡异的一环不是传统软件漏洞，而是一个未公开的硬件路径。

攻击者利用特定 MMIO 寄存器控制 GPU 相关协处理器的 cache 行为，让它直接写入受保护物理内存，从而修改页表。换句话说，PPL 正确保护了“CPU 通过正常路径修改页表”，但系统没有完整封死“另一个硬件单元替你写”。Apple 最终把相关 MMIO 范围加入受保护的 pmap-io-ranges。Kaspersky 将这部分称为整条链的“最后一个硬件谜团”（Securelist）。

它给防御者的教训很具体：

硬件安全边界不是一颗芯片，而是所有 DMA master、协处理器和可编程外设的总和。
内核页表保护需要配套 IOMMU 与 MMIO allowlist。 只审 CPU 指令路径不够。
“未文档化”不是访问控制。 攻击者有样本、时间和示波器；保密只能增加研究成本，不能形成安全属性。

MTE、Rust、pKVM 与 MIE：从阻止利用转向阻止 bug 成形

传统缓解机制往往允许内存破坏发生，再阻止它劫持控制流。新一代防线开始更早介入。

Arm Memory Tagging Extension（MTE） 给内存分配和指针附加小标签，访问时标签不匹配便报告错误。释放后重新分配若更换标签，悬空指针继续使用就更容易被抓住；越界指针跨到不同标签区域也会失败。Android 支持同步、异步和非对称模式：同步定位最准但开销高，异步更适合广泛部署，ASYMM 则对读精确、对写延迟报告（AOSP MTE）。标签位数有限，所以它不是数学上的绝对证明；它的价值是把稳定 exploit 变成概率更差、噪声更大的工程。

Shadow Call Stack（SCS） 把返回地址另存到普通栈之外，AArch64 用保留寄存器指向影子栈；栈溢出即使改掉普通返回地址，也要再找到影子栈位置并修改它（AOSP SCS）。CFI 则约束间接调用只能跳到类型兼容的目标。它们保护的是控制流，不会修复业务逻辑或数据对象被篡改。

Rust 的意义不是“Rust 没 bug”，而是默认所有权与借用规则消灭大量 use-after-free、double free 和迭代器失效。Google 报告 Android 内存安全漏洞占比从 2019 年的 76% 降至 2024 年的 24%，并把趋势与新代码转向内存安全语言联系起来（Google Security Blog）。这是 Google 对自家漏洞数据的统计，不该外推成全行业定律；但“停止继续制造同类 bug”显然比永远给 C/C++ 打补丁更接近根治。

Android Virtualization Framework / pKVM 把受保护虚拟机与 Android host 视为彼此不可信。pKVM 运行在更高异常级，限制 host kernel 访问 protected VM 内存；这为敏感工作负载提供一条不依赖“整个 Android 内核永远正确”的隔离边界（AOSP AVF security）。

Apple 在 iOS 15 推出类型感知的 kalloc_type，把不同类型对象隔离到随机化 bucket，降低 UAF 把一个对象替换成攻击者期望类型的可靠性；iOS 16 扩大了采用范围（Apple Security Research）。2025 年 A19 代设备的 Memory Integrity Enforcement（MIE） 又把 Enhanced MTE、类型安全分配器和标签机密性覆盖到内核及 70 多个用户态进程。Apple 称历史利用链无法在 MIE 下直接重建（Apple）；这仍是厂商自己的评估，但代表防御重心已经从“签一个指针”走向“让错误指针第一次解引用就暴露”。

iOS和Android从硬件启动到服务端设备证明的信任链 — 两套平台路径不同，终点一致：客户端证据只能提高置信度，真正的业务授权仍然属于服务端。

App 逆向到底在逆什么：从包格式到运行时

系统利用研究和 App 安全测试经常混在一起谈。前者试图跨越平台隔离，后者更多是在检查一个 App 是否把秘密、授权和信任错误地留给客户端。工具相似，威胁模型不一样。

Android：APK 不是源码压缩包

APK 本质上是 ZIP 容器，常见内容包括二进制 AndroidManifest.xml、编译资源、classes*.dex、不同 ABI 的 lib/*.so 和签名信息。AAB 是发布时的模块化输入，设备真正安装的是 Play 按配置生成的一组 split APK。

DEX 保存寄存器式字节码。ART 会在安装、运行和空闲维护阶段组合解释、JIT 与 AOT 编译，因此静态看到的方法不一定以同样形式存在于内存；热点代码可能进入机器码，JNI 又会把关键逻辑带进 ELF。加固壳常让壳 DEX 先启动，解密真实 DEX 后通过 ClassLoader 动态装载。于是分析重点从“哪个反编译器按钮更绿”变成：真正代码在什么时候出现，由谁加载，调用如何跨过 Java/JNI 边界。

看雪一篇Android 加固分析记录展示了研究者在运行时观察 ClassLoader、提取多份 DEX，并追踪 native 侧 dlsym 与线程创建的过程。原帖涉及付费功能绕过，不应照搬其用途；但其方法论是有效的：当静态包只剩启动壳时，沿“加载时机 → 内存映射 → 类解析 → JNI 注册”追踪，比盲搜字符串可靠。

iOS：代码签名让“改完再装”本身成为边界

IPA 同样是 ZIP，但核心是 Mach-O 可执行文件、framework、资源、embedded provisioning profile 与代码签名。Mach-O 的 load command 告诉 dyld 依赖库、段权限和入口；Objective-C metadata 会暴露类、selector 与协议，Swift 符号和反射信息也可能提供语义。系统库大量位于 dyld shared cache，反汇编时看到的跳板并不等于最终实现。

签名覆盖代码页及资源清单，entitlement 又与签名绑定。修改二进制后，原签名不再成立；在正常设备上重新安装需要合法开发签名，并且不能凭空获得 Apple 限制的 entitlement。这个约束让 iOS App 篡改与 Android 侧重签 APK 的成本结构不同，但不会自动保护硬编码 API key、客户端业务判断或已解密的运行时数据。 代码执行时必须能读取的数据，拿到该进程控制权的分析者通常也能观察到。

动态 Hook 的原理，以及为什么“检测到 Frida”不是终局

Frida 并不是一个会发光的万能按钮。它的核心是把 agent 注入目标进程，通过运行时 API 或 native interceptor 改写函数入口、调用目标或消息分发，并用 RPC 把数据送回控制端。

在 Android Java 层，Hook 常发生在 ART 方法解析和 trampoline 周围；进入 JNI 后，分析者会转向导出符号、RegisterNatives 注册表、PLT/GOT 或函数前几条指令。在 Objective-C 中，方法调用最终围绕 selector 与 IMP 解析，交换实现或替换 IMP 都能改变行为；Swift 直接调用和内联更多，常需要回到 Mach-O 符号与 native 指令。

防守方因此会检查：

/proc/<pid>/maps 是否出现可疑模块、匿名可执行页或代码页变脏；
本地端口、线程名、已加载 dylib/so 和启动参数是否异常；
GOT/PLT、函数 prologue、Objective-C IMP 是否偏离基线；
ptrace、调试标志、bootloader/jailbreak 路径、签名和硬件证明是否异常；
高价值动作前后的触摸、传感器、网络和账户行为是否互相矛盾。

看雪 2026 年一篇Android 运行时检测讨论把这些证据分成 maps、socket、模块、hook、匿名 RX 与 dirty page 等多类，方向比“搜一个 frida 字符串”成熟。另一篇iOS 越狱检测 CrackMe则包含路径、dyld image、URL scheme 和私有目录写入检查。它们共同证明了相反的一点：任何在同一客户端进程里执行的单一检查，都可能被同一进程里的攻击者改写返回值。

正确策略不是再加第 37 个路径，而是建立证据链：多个独立信号、不同采集时机、native 与系统服务交叉验证，结果送到服务端做风险评分；对普通异常降级或二次验证，对明确高风险才拒绝。否则一台开发者手机、辅助功能工具或 OEM 魔改 ROM，就能把风控现场变成客服团建。

OWASP MASTG 对 Frida agent、/proc maps 和运行时完整性检查有系统整理（MASTG-KNOW-0087）。它适合当测试基线，不适合当“通过清单等于安全”的证书。

网络层：TLS、Pinning、mTLS 和 Attestation 各自解决什么

这四个概念最容易被产品文档炖成一锅。

机制	证明什么	不证明什么
TLS	客户端连接到持有合法服务端私钥的一方，链路机密且完整	客户端 App 未被修改、用户请求合法
Certificate Pinning	服务端证书/公钥还符合 App 内额外约束	客户端本身可信；也不天然解决重放
mTLS	客户端还持有服务端认可的证书私钥	私钥一定没被导出、请求一定来自真人
App Attest / Play Integrity	App、安装来源、设备状态或硬件信号符合某些声明	设备绝对干净、业务动作绝对无欺诈

Pinning 能降低错误 CA 或本地代理造成的中间人风险，但把证书生命周期焊进客户端也可能制造全量断网。Cloudflare 对 pinning 的复盘强调证书轮换和恢复风险；这不是说“永远别 pin”，而是高风险场景应至少准备 backup pin、远程更新与灾难恢复。研究测试环境则应提供受控开关，而不是逼工程师在生产包里拆 TLS。

mTLS 对 B2B、设备注册和受管终端很有价值，但若把同一客户端私钥硬编码进所有 APK/IPA，它迟早会成为公开素材。Cloudflare API Shield 的设计说明也提醒嵌入式 bootstrap credential 只能用于首次换取短期、设备独立凭据。更好的路径是让设备在 Secure Enclave/StrongBox 内生成不可导出私钥，服务端通过 attestation 绑定公钥、App 身份和一次性 challenge。

Apple App Attest 让设备生成特殊密钥并由 Apple 证明，服务端保存公钥并验证后续 assertion；Apple 自己也明确说它不能确定一台设备的 OS 绝对未被攻破，应纳入整体风险评估（DeviceCheck）。Play Integrity 则提供 App 完整性、设备完整性、近期补丁、Play Protect、覆盖/控制类 App 与设备活动等 verdict（Android Developers）。

一个可靠的高价值请求至少应绑定：

server_nonce + account_id + action + canonical_request_hash + expiry

服务端验证 assertion 后，还要检查 nonce 是否使用过、时间窗是否合理、账户行为是否异常，并把“无法获取证明”和“证明明确失败”分开。Attestation 是昂贵的证据，不是把 if 语句搬到云端。

一套不会把自己测进事故报告的授权分析流程

下面这套流程面向自己的 App、靶场或有书面授权的项目。先建立可复现观察，再谈绕过；一上来就 root 真机、全局关闭证书校验，相当于为了测门锁先把整栋楼拆了。

1. 建立四格实验矩阵

一台未修改、补丁最新的真实设备，用于验证正常安全边界。
一台可重置的测试设备或研究设备，用于动态观测。
Android Emulator / iOS Simulator，用于快速测试 UI、URL scheme、Intent 和协议逻辑；不要把模拟器结果当硬件安全结论。
一个隔离测试账户与测试后端，禁止使用生产用户数据和真实支付凭据。

记录 OS build、security patch level、boot state、App hash、安装来源和测试时间。移动端漏洞高度依赖版本，“我这能复现”如果没有 build number，学术价值接近“我电脑刚才蓝了一下”。

2. 静态分诊：先看声明，再看代码

Android 先审 manifest 的 exported component、permission、intent filter、network security config、backup/debuggable 标志和最低版本；再看 DEX 调用图与 native 库。iOS 先看 entitlement、URL scheme、ATS 例外、Keychain access group、动态库与签名。

# 只对你拥有或获授权的安装包执行
unzip -l sample.apk
apkanalyzer manifest print sample.apk
jadx -d out sample.apk
readelf -W -l out/resources/lib/arm64-v8a/libtarget.so

unzip -l sample.ipa
codesign -d --entitlements :- Payload/Target.app
otool -L Payload/Target.app/Target

重点不是“反编译结果像不像源码”，而是标记 trust boundary：外部输入在哪里进入、敏感数据在哪里解密、权限在哪一层检查、native 边界在哪里、服务端是否重新验证。

3. 动态观测：先画时间线，再下 Hook

先用系统日志、代理、文件差异和进程列表记录冷启动、登录、支付、后台恢复等关键路径。然后只在最小范围插桩，验证某个假设：这个 token 在何时生成？这个 JNI 方法是否决定授权？这个 IPC response 是否经过调用者校验？

不要把“Hook 成功”写成漏洞。客户端函数当然能被改；真正漏洞是修改后能否让服务端接受未授权结果、读取本不该可见的数据，或跨越平台承诺的隔离边界。

4. IPC 与组件：把调用者身份当第一等输入

Android 要测试显式/隐式 Intent、嵌套 Intent、PendingIntent、ContentProvider URI permission 和 Binder 调用者。Android 16 默认加强 Intent redirection 防护，因为攻击者可把可控 nested intent 借受信任组件转发到私有组件（Android Developers）。服务端式思维同样适用：接收方必须验证最终调用上下文，不能因为请求经过“自己家的 Activity”就自动信任。

iOS 侧检查 URL scheme、Universal Link、pasteboard、App Group、Keychain group 和 XPC/Mach service entitlement。一个 broker 如果代客户端打开文件或访问传感器，必须验证 caller identity 与每个参数，不能只验证“调用来自本机”。

5. Native 内存：从 crash 到 primitive

复现 native crash 后按顺序回答：崩溃地址是否受控？对象生命周期是否可重复？分配布局是否稳定？ASLR 信息从哪里来？PAC/CFI/MTE/SCS 在哪一步终止？权限边界是什么？

使用 ASan/HWASan/MTE 的同步模式做开发测试，比在生产崩溃堆栈里猜 UAF 快得多。fuzzer 应围绕真实解析边界保留 corpus，并把 Binder/XPC 序列状态纳入输入；只 fuzz 单个函数，往往测不到跨消息状态机。

6. 报告：把“能做”翻译成“攻击者需要什么”

一份可修复的移动安全报告至少包含：受影响 build、入口条件、用户交互、所需权限、可见数据、跨越的信任边界、稳定复现率、日志/崩溃证据、最小 PoC、修复建议和回归测试。不要在报告里只放一张 Frida 控制台截图，然后让研发通过读心术定位权限模型。

OWASP 的 Mobile Application Security Testing Guide可以作为测试目录；平台官方文档负责解释安全承诺，论坛负责提供真实世界症状，三者不能互相代替。

普通用户与高风险用户：防御建议不是同一套餐

对绝大多数人，收益最高的动作很朴素：及时更新 OS 和 App，只从可信商店安装，删除长期不用的配置描述文件/VPN/根证书，限制辅助功能与设备管理权限，使用强锁屏密码和独立账户 MFA。恶意广告、仿冒登录和滥用辅助功能的风险，远比价值数百万美元的 0-click 更普遍。

Kaspersky 2025 年移动威胁遥测称其拦截约 1400 万次移动攻击，发现约 81.5 万个恶意安装包，其中广告软件仍占检测多数，银行木马包数量显著增长（Securelist）。这是单一厂商用户群与产品覆盖下的遥测，不代表全网普查，但足以提醒：多数攻击者没有必要购买内核 0-day，发一个像快递通知的钓鱼页便宜多了。

如果你是记者、活动人士、外交人员、政治人物或商业间谍高价值目标，威胁模型才需要升级：

iPhone 启用 Lockdown Mode。它限制消息附件、部分网页技术、未知邀请、锁屏有线连接和配置文件安装；Citizen Lab 在 BLASTPASS 案例中认为它阻断了当时的零点击链（Citizen Lab）。
收到 Apple/Google 威胁通知时，不要自行清理后再求助。先保全设备、通知邮件和时间线，联系有经验的取证团队。
重启可能清除部分无持久化内存 implant，却不是“每天重启即可免疫 Pegasus”。它也可能抹掉有价值的易失证据。
MVT 可检查 iOS backup、Android bugreport 或采集结果中的已知 IOC。Amnesty 明确提醒：未命中公开 IOC 不等于设备干净，新型间谍软件可能没有公开指标（Amnesty Security Lab）。

# 取证前先阅读官方文档；输出包含高度敏感的个人数据
mvt-ios --help
mvt-android --help
mvt-android check-bugreport /path/to/authorized-bugreport.zip

取证数据应加密保存、限制访问并记录 custody。不要把完整 sysdiagnose、AndroidQF 采集包或 iTunes backup 上传到随机“在线查毒”网站。免费不是商业模式缺席，有时你本人就是商业模式。

2026 年之后，真正值得盯住的六条前线

1. 内存安全从“减伤”转向“默认不生成同类 bug”

Rust、Swift 安全子集、类型隔离分配器、MTE/MIE 会继续组合。未来评估平台不能只数 CVE，还要看新代码中不安全语言比例、标签覆盖范围、同步/异步模式、硬件标签机密性和崩溃遥测闭环。

2. GPU、NPU、基带与安全处理器成为新的系统边界

主内核越来越硬，攻击者就更愿意研究共享内存、DMA、固件 RPC 和 vendor driver。手机上的 AI 加速器还会接收模型、tensor 与复杂图结构；它很可能重复 GPU 曾经走过的“先追性能，后补隔离”路线。

3. 虚拟化把高价值工作负载从大内核里搬出去

pKVM/AVF、受保护 VM 和更小 TCB 能隔离 DRM、密钥操作、私密计算或高风险解析器。收益来自减少可信代码量，不是因为 hypervisor 天生不会有 bug。虚拟机监控器、固件与设备直通会成为新的审计重点。

4. Attestation 会从“是否 Root”进化成连续风险证明

一次性设备完整性 verdict 很容易被重放或在检查后切换环境。未来会把 nonce、账户、动作、补丁时效、App 版本、设备行为和硬件密钥连续绑定，并允许服务端做分级响应。隐私挑战也会变尖锐：设备证明如果演变成跨服务追踪标识，安全就会顺手把匿名性一起修掉。

5. 零点击入口会继续被主动减功能

BlastDoor 与 Lockdown Mode 说明平台开始接受一个不太互联网的答案：对极高风险用户，少解析一点，比解析得更聪明更可靠。 消息预览、字体、WebAssembly/JIT、未知邀请和附件格式会出现更多可选收缩策略。

6. 后量子迁移先改变协议工程，不会先消灭手机木马

移动端会逐步采用混合后量子密钥交换与签名，但最常见失陷仍来自钓鱼、恶意 App、逻辑授权和内存破坏。Cloudflare 已在 WARP 的 iOS/Android 客户端部署后量子密钥协商，并规划抗降级阶段（Cloudflare）。它保护的是“今天截获、未来解密”的链路风险，不会让一个已经拿到通知权限的木马突然开始反省。

最后的判断

十五年前，移动安全常被描述成一场“拿 root / 守 root”的战争。今天 root 只是权限图中的一个节点：密钥可能在独立安全处理器里，敏感工作负载可能在受保护 VM 里，App 请求还要接受服务端 attestation 与行为判断。与此同时，消息解析器、GPU、基带和供应链又不断提供新的入口。

真正的进步不是平台终于没有漏洞，而是单个漏洞越来越难直接兑换全部能力。真正的风险也不是手机突然退回 2010 年，而是我们把越来越完整的人生交给一台永远联网、永远解析外界输入的设备。

移动安全的终局不会是“再也攻不破”。更现实的胜利是：每深入一层都要付新成本，每跨一次边界都可能留下证据，而最敏感的数据从一开始就不需要相信上一层永远正确。

参考资料与继续阅读

平台原理优先阅读 Apple Platform Security、Apple Security Research、Android Security 和 OWASP MASTG。攻击链细节可继续阅读 Project Zero 的 FORCEDENTRY、Samsung Android exploit chain 与 Kaspersky 的 Operation Triangulation。针对商业间谍软件与受害者取证，Citizen Lab、Amnesty Security Lab 的公开报告比二手新闻可靠得多。

中文实践方面，本文采用了可稳定访问并能与官方资料交叉验证的看雪帖子；吾爱破解相关页面缺少稳定公开索引，因此没有为了满足站点名称硬凑不可复核的引用。论坛最适合观察工具链与一线症状，平台安全承诺仍应回到官方设计文档，漏洞事实则应回到披露团队、CVE 与补丁说明。