MilkSU Hunternote

Appearance

0x01 - Android 架构演进：整体到模块化 ​

梳理 Android 从早期"整体式"到"解耦/模块化"的关键拐点（ART/SELinux、Treble、Mainline/APEX、GKI），并结合典型漏洞事件说明：攻击面暴露 → 修复路径/分发机制 → 架构演进之间的关系。

说明：本文面向安全研究做"机制与趋势"梳理。涉及模块化更新（Mainline/Google Play 系统更新）与某些新特性时，具体是否可用、是否由 Play 分发，依赖设备是否包含 GMS、厂商策略与 Android 版本；以对应版本的 AOSP 官方文档为准。

影响（研究与排障视角）：

  • 补丁分发链路变化：厂商 OTA → 月度安全公告/补丁节奏 →（部分组件）Google Play 系统更新
  • 边界更清晰：system/vendor 接口契约化（VINTF），组件拆分可独立更新（APEX/Mainline）
  • 版本维度增加：平台版本 + SPL + vendor 实现 + 模块版本（同版本设备差异变大）

早期 Android 架构：整体式结构 ​

Android 4 架构

在 Android 4 至 Android 7 期间，系统呈现高度集成的"整体式"（Monolithic）结构。这个阶段并非指某一个具体的 Android 版本，而是对 Android 8.0（Treble）之前，以整体耦合、更新困难为特征的系统架构的统称。

  • 核心特征：

    • 高度耦合：Android 框架、HAL 实现、厂商驱动紧密耦合在一起，系统升级需要所有组件同步更新。
    • 更新困难：大版本更新依赖硬件厂商提供匹配的驱动和 HAL 实现，导致系统碎片化严重。
    • 安全响应慢：漏洞修复需要通过完整的 OTA 更新推送，从漏洞披露到用户设备修复往往需要数月时间。
    • 单一版本维度：主要关注平台版本号，补丁级别（SPL）概念尚未完善。

  • 架构痛点：

    • 厂商依赖重：Google 无法独立更新 Android 系统，必须等待芯片厂商和设备制造商的适配。
    • 碎片化严重：不同设备运行的 Android 版本差异巨大，新版本覆盖率低。
    • 漏洞窗口期长：关键安全漏洞从修复到大规模部署周期长，用户设备长期暴露在风险中。

Android 4 (2011-2013)：经典的整体式架构 ​

在 Android 4 及以前，系统呈现高度集成的"整体式"（Monolithic）结构。

  • 架构特点：

    • 应用层 (Application / Application Framework)：开发者通过应用框架 API 与系统交互。
    • 系统运行库与核心库 (Libraries + Android Runtime)：包含 Bionic C 库、各种媒体库以及 Dalvik 虚拟机，后者负责执行应用的 dex 字节码。
    • 硬件抽象层 (HAL)：以 .so 动态库形式存在于 /system 分区，是厂商对硬件功能的具体实现，与 Android 框架紧密耦合。
    • Linux 内核 (Linux Kernel)：提供最基础的驱动、进程管理、内存管理（如 Ashmem）和核心 IPC 机制（Binder）。

  • 时代痛点：

    • 强耦合与高昂的更新成本：Android 框架的升级往往需要硬件厂商（Vendor）提供匹配的驱动和 HAL 实现，导致系统大版本更新缓慢且困难。
    • 较弱的隔离机制：虽然已有 UID/GID 的权限模型，但 SELinux 在 Android 4.3 才被引入，且在 5.0 之前普遍处于"宽容模式"（Permissive），使得系统进程权限过于宽泛，漏洞利用后的横向移动相对容易（展开见 SELinux on Android）。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响

Android 5 (2014)：ART 运行时与 SELinux 强制化 ​

  • 变革一：Dalvik 虚拟机被 ART (Android Runtime) 取代

    • 变动原因：为了提升应用执行效率和启动速度。Dalvik 采用的是即时编译（JIT），而 ART 引入了预编译（AOT），在应用安装时就将 dex 字节码转换为本地机器码（oat 文件）。
    • 影响：性能提升，系统响应更流畅；漏洞利用的复现性开始与具体的编译产物、设备配置和系统版本产生更强的关联。

  • 变革二：SELinux 进入"强制模式" (Enforcing)

    • 变动原因：为了引入更强大的强制访问控制（MAC）机制，限制进程的行为。
    • 影响：为每个系统服务和应用分配了特定的"安全域"（Domain），严格限制了它们可以访问的资源，极大地增加了漏洞利用后横向移动的难度。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响

Android 6 (2015)：运行时权限与安全基线强化 ​

  • 运行时权限模型：这是 Android 历史上一个里程碑式的变革。应用在安装时不再被授予所有权限，而是在首次需要访问敏感资源（如相机、联系人）时，通过弹窗动态向用户申请（展开见 Permission Model）。这赋予了用户对数据访问的直接控制权。

  • Doze 模式与 App Standby：引入了先进的功耗管理机制。当设备静止且未充电时，系统会进入 Doze 模式，延迟后台任务和网络访问；App Standby 则会限制不常用应用的后台活动，两者共同显著提升了电池续航。

  • 强制全盘加密：要求所有出厂搭载 Android 6.0 的新设备必须默认开启全盘加密（Full-Disk Encryption），为用户数据提供了强大的静态保护。

  • 原生指纹支持：提供了统一的指纹认证 API，使开发者可以方便地在应用中集成安全、一致的指纹识别功能。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响

Android 7 (2016)：引入文件级加密与 JIT 编译器回归 ​

  • 文件级加密 (File-Based Encryption, FBE)：取代了全盘加密，成为新的加密标准。FBE 对不同文件使用不同密钥加密，部分密钥与用户的锁屏密码绑定（相关的数据访问边界与行为变化见 Data Storage Isolation）。

  • 直接启动 (Direct Boot)：基于 FBE，允许设备在用户输入密码前启动到一个受限模式。在该模式下，电话、闹钟等核心应用可以运行，而大部分用户数据仍处于加密状态，兼顾了便利性与安全性。

  • JIT/AOT 混合编译：在 ART 中重新引入了 JIT 编译器，并结合 AOT 预编译。系统通过分析应用的实际使用情况（Profile-guided compilation），对热点代码进行 JIT 编译和优化，实现了应用安装速度与运行性能的平衡。

  • APK Signature Scheme v2：引入了新的应用签名方案，通过保护 APK 的整个文件内容来防止恶意篡改，并显著加快了应用安装时的验证速度。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响

现代 Android 架构：模块化的 culmination ​

现代 Android 架构

经过上述一系列的演进，我们得到了"现代 Android 架构"。这个概念并非指某一个具体的 Android 版本，而是对 Android 8.0 以来，由 Project Treble、Mainline 和 GKI 共同塑造的高度模块化、易于更新和强隔离性的系统架构的统称。

  • 核心特征：
    • 边界固定：通过 Treble/VINTF 明确了系统与供应商的边界。
    • 组件可更新：通过 Mainline/APEX 实现了核心组件的独立、快速更新。
    • 强隔离：通过强制化的 SELinux、组件化和严格的接口调用，实现了深度防御。
    • 多维版本矩阵：理解一台设备的状态需要综合分析其平台版本、SPL、GKI 版本和 APEX 模块版本。

Android 8 (2017)：Project Treble - 架构解耦的里程碑 ​

  • 变革核心：系统与供应商的解耦
    • 变动原因：厂商适配新版 Android 需要修改大量与硬件相关的代码，导致更新缓慢、碎片化严重。
    • 影响：通过定义稳定的供应商接口（HIDL/VINTF），使得 Android 框架可以独立于 HAL 实现进行更新。这为后续的快速补丁分发和模块化更新奠定了基础（展开见 HIDL 与 AIDL）。

Android 9 (2018)：强化隐私保护与硬件安全 ​

  • 限制后台应用访问：严格限制处于后台状态的应用访问摄像头、麦克风和传感器，防止用户在不知情的情况下被监听或追踪。

  • 加密备份与 DNS over TLS：支持使用用户锁屏密码对 Android 备份进行客户端加密。同时，原生支持 DNS over TLS，自动加密 DNS 查询，防止被窃听或篡改。

  • 统一的生物识别对话框 (BiometricPrompt)：提供了一个标准的系统级对话框，供应用调用指纹、面部或虹膜等生物识别认证，确保了体验的一致性和安全性。

  • Android 保护确认 (Android Protected Confirmation)：利用硬件安全环境（如 TEE），在屏幕上显示一个受保护的确认提示，让用户可以安全地批准敏感交易。

  • 引入 StrongBox Keymaster：支持将私钥存储在专用的、防篡改的安全芯片中，为密钥提供最高级别的硬件保护。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响

Android 10 (2019)：Project Mainline - 核心组件模块化与 APEX ​

  • 变革核心：将关键系统组件打包成可独立更新的模块（模块化更新链路的一个典型例子：WebView，见 WebView Security）

    • 变动原因：即使有了 Treble，一些关键的系统级安全漏洞仍需等待数月才能通过 OTA 推送到用户设备。Mainline 旨在通过 Google Play 商店直接更新这些核心组件。
    • 影响：引入 APEX 文件格式，用于打包和分发底层系统组件。关键漏洞可以像更新应用一样被快速修复，极大地提升了安全响应速度。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响

Android 11 (2020)：GKI - 统一内核 ​

  • 变革核心：推广通用内核映像 (Generic Kernel Image)

    • 变动原因：尽管 Treble 解耦了 HAL，但每个设备的 Linux 内核仍然高度定制化。GKI 旨在提供一个统一的内核基础，厂商只需开发特定于其硬件的模块。
    • 影响：将内核分为核心 GKI 部分和厂商模块，两者通过稳定的内核模块接口（KMI）交互，进一步简化了内核安全补丁的部署和更新（展开见 Android Kernel Overview）。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响

Android 12 (2021)：隐私控制与组件可更新范围扩展 ​

  • 隐私仪表盘 (Privacy Dashboard)：集中展示过去24小时内应用对位置、麦克风和相机的访问记录，提升透明度。

  • 麦克风与摄像头指示器：当应用使用麦克风或摄像头时，状态栏会显示明确图标，并提供快速关闭权限的开关。

  • 私有计算核心 (Private Compute Core)：创建一个安全隔离的环境，用于处理本地敏感数据和AI功能（如智能回复），数据不出设备。

  • ART 纳入 Mainline：Android 运行时 (ART) 成为一个可更新的 Mainline 模块，使得 Google 可以通过 Play Store 直接推送运行时和核心库的改进，加速安全修复。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响
2021Kernel Exploit[CVE-2021-1048](../../../cves/entries/CVE-2021-1048.md)Android kernel 漏洞，Google TAG 报告在野利用（内核提权链）。持续验证 GKI 统一内核的必要性，推动内核安全补丁的快速分发与统一更新机制。

Android 13 (2022)：细化权限与体验 ​

  • 照片选择器 (Photo Picker)：允许用户只授予应用访问特定照片或视频的权限，而无需暴露整个媒体库。

  • 通知运行时权限：应用在发送通知前必须明确请求用户授权，给予用户对通知的完全控制权。

  • 剪贴板自动清除：系统在短时间内自动清除剪贴板中的敏感内容（如密码、密钥），防止被意外读取。

  • Wi-Fi 权限分离：应用扫描附近 Wi-Fi 设备不再需要请求宽泛的位置权限，降低了不必要的数据暴露风险。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响
2022Dirty Pipe[CVE-2022-0847](../../../cves/entries/CVE-2022-0847.md)Linux kernel 漏洞，影响 Android 12 等设备（以当期补丁为准）。再次凸显内核层漏洞的长尾影响，推动 GKI 统一内核更新机制的持续优化与完善。

Android 14 (2023)：强化安全基线与 AVF ​

  • 限制安装旧版应用：为防止恶意软件利用旧版API漏洞，系统默认阻止安装面向过时 Android 版本（Android 5.1 及更早）的应用。

  • 更精细的数据共享控制：当应用试图与第三方共享位置数据时，系统会弹出额外通知，让用户决定是否批准。

  • 凭据管理器 (Credential Manager)：整合了多种认证方式，简化了登录流程，并为 Passkey 等现代认证标准提供原生支持。

  • 推进 64 位过渡：Google Play 要求应用提供 64 位支持；部分设备仅搭载 64 位 Zygote，但 AOSP 层面仍保留 app_process32 以兼容遗留应用。

  • AVF (Android Virtualization Framework)：引入 pKVM，将高敏感任务（如密钥管理、DRM）从主系统隔离到受保护的虚拟机中（展开见 AVF）。

  • MTE (Memory Tagging Extension)：硬件级内存安全检测，旨在从根源上终结 UAF 和 Buffer Overflow 等内存破坏漏洞（缓解/加固视角可对照 Kernel Mitigations）。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响
2023libwebp 0day[CVE-2023-4863](../../../cves/entries/CVE-2023-4863.md)libwebp 多平台在野利用；Android WebView/媒体链路常见关注点。验证 Mainline 模块化更新机制的价值，推动更多关键组件（如 WebView）通过 Google Play 系统更新快速修复。

Android 15 (2024)：隐私隔离与平台适配 ​

  • Private Space（私密空间）：以独立用户 profile 形式提供隔离区；锁定时从启动器/最近任务/通知/设置等入口隐藏；应用与数据与主空间分离。

  • Theft Protection（防盗保护）：Theft Detection Lock / Remote Lock / Offline Device Lock 等（落地与地区/设备/组件版本相关）。

  • 16KB page size 支持：提供 16KB 内存页模式（部分设备通过开发者选项切换），对 Native 兼容性、内存布局与性能/稳定性验证提出新要求。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响
2024WebView 0day[CVE-2024-29745](../../../cves/entries/CVE-2024-29745.md)Android System WebView 在野利用，被列入 CISA KEV。强调组件更新路径的重要性，验证 WebView 通过 Google Play 独立更新机制在应对 0day 时的响应速度优势。

Android 16 (2025)：平台侧安全/隐私强化 ​

  • Safer Intents（意图解析加固）：针对 Intent redirection 等问题的多阶段加固；面向 targetSdk=16 的行为变化与可选严格模式（manifest opt-in）（展开见 Intent System）。

  • Keystore Key Sharing API：新增跨 UID 的 Keystore key 授权/撤销与访问接口（面向需要安全共享密钥的场景）（相关能力与边界见 Hardware-backed Keystore）。

  • Privacy Sandbox / SDK Runtime：SDK 运行时隔离持续推进，第三方 SDK 与宿主 App 的数据边界更明确。

  • MediaStore version lockdown：MediaStore#getVersion() 对每个 app 返回独立版本标识，减少用于指纹识别的稳定属性。

  • 代表性安全漏洞

年份漏洞名称CVE描述对架构演进的影响
2025Android System 高危[CVE-2025-26443](../../../cves/entries/CVE-2025-26443.md)2025-06 ASB 高危案例（公开资料未见在野利用结论）。持续推动 Mainline 模块化范围扩展，优化 Play 系统更新覆盖率与响应时效；验证现代架构下多维修复路径的成熟度。

总结：攻击面的演进趋势 ​

从研究视角看，Android 的演进是一个**"收缩"**的过程：

  1. Framework 层：由于 Mainline 的存在，逻辑漏洞（如 Janus）的生命周期被极大缩短。
  2. Native 层：随着 Scudo 分配器和 MTE 的普及，传统堆利用难度指数级上升。
  3. Kernel 层：GKI 使得内核补丁同步变快，研究重心转向 GPU/NPU 等 Vendor 驱动。
  4. 新战场：虚拟化边界（pKVM）、硬件安全（TEE/Keystore）以及 ART 虚拟机的复杂逻辑漏洞。

参考（AOSP） ​

CCBYNC · © milksu (starneko)