奇链 奇链
← 文章 / 科技资讯
Hacker News 1小时前 · 2026-09-13 02:28:14 · 3 阅读

Android NAT-T keepalive 卸载机制绕过 VPN 锁定

Android 的“始终开启 VPN”和“阻止无 VPN 连接”设置，会让用户默认认为受保护应用的流量绝不会经由非 VPN 路径发出。然而，普通应用却可以通过 Android 公开的 NAT-T socket-keepalive API 突破这一边界，使明文且格式固定的 UDP/4500 数据包直接抵达物理路由器，从而绕开 VPN 通道。运行时的证据分为三个层级。在一次针对 Pixel 8 Pro（运行 Android 16 版本 CP1A.260505.005）的受控接入点抓包测试中，系统在启用“始终开启 VPN”和“锁定”策略的同时，以 10 秒的最低公开间隔间隔记录了这些数据包。在一台三星 SM-F966B（运行 Android 16）上，同一公开路径暴露了一个活跃的 Wi-Fi 槽位；VPN 泄漏防护机制选中了物理 IPv4 默认网关，观察到活跃回调，并记录了持续 24 小时 32 分钟的对路由器定向的活跃槽位租约。在一台 Nothing A059（Asteroids 代号，运行 Android 16）上，同一实现选中了物理网关，并记录了一个活跃的 Wi-Fi 槽位。Nothing 的测试结果确认了第三家 OEM 厂商上的公开路径准入机制和活跃回调，但并未针对该设备收集独立的抓包数据或持续时间测量。Pixel 的生命周期测试矩阵涵盖了后台运行、锁定、Doze 模式、省电模式、受限待机桶、Binder 冻结器，以及观察到的强制停止、卸载、断网和重启等边界场景。

追溯源代码历史可以发现，这一缺陷源于 startNattKeepaliveWithFd(...) 中信任模型的崩塌：原本受保护的 raw-fd API 演变成了公开的 UdpEncapsulationSocket 路径，资源校验曾被添加后又遭回退，且当前准入机制不再验证 fd/资源对的身份，也未在执行 offload 前强制执行原始调用者 UID 当前的 VPN 策略。在一项基于 F-Droid/IzzyOnDroid 的针对 4,679 个不同存储 Git 来源的研究中，扫描器未检测到任何 Android 框架的 IPsec、IKE 或 NAT-T API 使用；人工审计则发现了 73 个 Android VpnService 应用。跨三家 OEM 和两个已确认 WLAN 机型的运行时确认、共享的 Android 12+ 框架路径，以及覆盖 7 个 WLAN 机型家族（占预估 Android 衍生出货量的 91.24%）的固件分析，共同证实了这是一种影响大多数 Android 12+ 设备的设备级暴露风险。其余 8.76% 的风险尚未解决。

2. 引言

VPN 锁定不仅管理加密，还负责路由和流量隔离。用户和管理员期望当 VPN 不可用时，受保护的应用程序采取“fail closed”策略（即安全失败），并阻止其将真实网络身份暴露给隧道外的目标。早期的 VPN 泄漏研究已探讨了路由例外、IPv6 和 DNS 泄漏、WebRTC 地址暴露、VPN 客户端生态系统以及共享 VPN 基础设施故障等问题 [1; 2; 3; 4; 5; 6; 7]。此外，Android 还将部分由应用程序触发的数据包发送任务委托给 system_server、NetworkAgent、硬件抽象层（HAL）或固件，这些路径绕过了应用程序常规的 Socket 发送流程。

普通应用程序可以通过 Android 公共托管的 IpSecManager.UdpEncapsulationSocket 跨越这一边界，并调用 ConnectivityManager.createSocketKeepalive(...) 来维护 NAT-T 映射。框架通过 startNattKeepaliveWithFd(...) 处理该请求，在未验证当前调用者是否拥有已归属的 IpSec 资源身份的情况下，便接受了重复的文件描述符和资源 ID，并将完成的 NAT-T keepalive 数据包直接交给 Wi-Fi keepalive offload 路径，而未首先强制执行调用者 UID 的有效 VPN 锁定策略。在对 Pixel 8 Pro 进行的受控抓包测试中，研究人员在物理接入点接口上捕获到了由此产生的 UDP/4500 数据包。另外两家 OEM 厂商在运行中的插槽上也观察到了类似现象，它们在 Qualcomm 硬件上执行了相同的公共物理网关路径 [8; 9; 10; 11; 12; 13; 14; 15; 16; 17].

近期的 Android Automotive 访问控制审计工作在大范围排查框架权限异常时发现了 ConnectivityService.startNattKeepaliveWithFd，原因是相关的 keepalive API 强制要求 PACKET_KEEPALIVE_OFFLOAD 权限，而基于 fd 的这条路径却不需要 [18; 19; 20]。不过该工作只指出了权限不一致的问题，并未追查公开的 UdpEncapsulationSocket 信任边界分裂、被回退的 IpSec 资源校验，也没发现 VPN lockdown 下物理 Wi-Fi 仍会发包的问题。

平台固定了数据包的格式，但调用方可以在 API 和路由约束范围内自行选择目标地址。当用户启用“禁止不经 VPN 的连接”后，重复发送的 keepalive 包仍会向该目标暴露物理网络的源地址和时序信息。这破坏了 lockdown 的身份隔离属性，而且攻击者甚至不需要控制任意载荷。

3. 背景：Android VPN Lockdown 与 NAT-T Keepalive Offload

3.1 Android VPN Lockdown

Android 的 VPN 模型可以把受管控的应用流量路由到 VPN 应用的 TUN 接口。Always-on VPN 会保持所选 VPN 始终开启，而用户可见的“拦截不经 VPN 的连接”设置，旨在防止受管控流量绕开 VPN 路径使用不安全的网络 [21; 22]。正常情况下，应用的一次写入要经过 socket 层、按 UID 的网络策略、fwmark 与 netd 路由状态、VPN 的 UID 范围路由、防火墙/禁止规则，当该 UID 被 VPN 覆盖时，流量最终进入 VPN 的 TUN 接口。

正常的 VPN 保护路径如下：

受管控的应用 UID
  -> socket connect/write
  -> fwmark/netd 策略与 VPN UID 范围检查
  -> 必要时 lockdown 做出禁止/默认失败的判定
  -> VPN 应用的 TUN 接口
  -> 通过允许的底层网络发送加密 VPN 隧道流量

这里涉及的安全属性是：可归因于受管控的非所有者应用的流量及其委派发包行为，必须不经过非 VPN 接口，除非平台明确声明豁免。VPN 所有者自身的底层流量、已配置的分流隧道、有文档说明的平台探测，以及特权系统功能，可以遵循另外的策略。

Android 会分别记录每个用户下哪款应用已被准备好作为 VPN 服务。VpnService.prepare() 可能需要用户授权；该服务自身必须在清单文件中声明 BIND_VPN_SERVICE 权限。在 Vpn 组件中，已准备的应用包名会与其所属的安装者 UID 配对绑定，确保在卸载重装或仅比较包名时，权限不会自动延续。仅声明了 VPN 服务但未通过准备的 APK 并不具备 VPN 身份，且已撤销的过往授权不等于当前批准 [23; 24]。安装者 UID 与当前已准备的应用包共同构成了 keepalive 准入所需的权限依据。

3.2 NAT-T Socket Keepalive 卸载（Offload）

IPsec 的 NAT 遍历（NAT-T）通常使用 UDP 4500 端口。Android 暴露了一条公开 API 路径：应用创建 IpSecManager.UdpEncapsulationSocket 后，可调用 ConnectivityManager.createSocketKeepalive(...) 来维持 NAT 映射 [8; 9]。在内部实现中，该路径会将复制的文件描述符（file descriptor）和 IPsec 资源 ID 传递给 IConnectivityManager.startNattKeepaliveWithFd(...)，随后进入 ConnectivityService、KeepaliveTracker、NetworkAgent 以及针对 Wi-Fi 或蜂窝网络的具体 keepalive 机制 [10; 11; 12]。

NAT-T keepalive 卸载路径如下：

app UID
  -> IpSecManager.openUdpEncapsulationSocket()
  -> ConnectivityManager.createSocketKeepalive(...)
  -> NattSocketKeepalive.startImpl()
  -> IConnectivityManager.startNattKeepaliveWithFd(...)
  -> ConnectivityService / KeepaliveTracker
  -> NetworkAgent
  -> Wi-Fi HAL / 芯片组固件
  -> 物理 Wi-Fi 上的 UDP/4500 keepalive

Wi-Fi 卸载路径可以在无需唤醒应用、也无需为每个数据包执行新的 socket 写入操作的情况下发送 keepalive 帧。在通过框架层的准入检查后，最终的发送方位于普通应用 socket 路径之下，而后者正是 VPN 锁定（lockdown）机制通常所控制的范围。

公共 keepalive 路径、Wi-Fi HAL 卸载方法以及兼容性插槽要求，均属于普通应用 socket 路径下方的共享平台接口 [25; 8; 26]。

4. 威胁模型与预期的 VPN 锁定行为

4.1 预期的 VPN 锁定行为

在启用“始终开启 VPN”和“阻止未通过 VPN 的连接”时，受管控的普通应用不得导致由 Android 管理的 NAT-T keepalive 数据包经由物理网络泄漏到 VPN 隧道之外。若调用者的完整 Android UID 受不可绕过或锁定型 VPN 管辖，则公共 UdpEncapsulationSocket 的 keepalive 请求应当失败、不被支持，或在 Wi-Fi 或蜂窝网络卸载在物理底层发出 UDP/4500 流量之前被拦截。

安全目标适用于可归因于受管控普通应用的 NAT-T 发包行为。Android 针对 VPN 所有者底层流量、配置好的拆分隧道以及特权平台功能的既定策略保持独立。接收一个未经验证的公共 fd/资源对，不能授予在物理底层进行卸载的权限。

4.2 攻击者

攻击者控制受害者设备上安装的普通 Android 应用，并在互联网上控制或监视 UDP/4500 端点。已验证的公共 API 路径不需要 root 权限、ADB、隐藏 API 访问、JNI、原始 Binder 构造、危险运行时权限弹窗，或特权的 PACKET_KEEPALIVE_OFFLOAD 权限。本地 PoC 变体声明了如 INTERNET 和 ACCESS_NETWORK_STATE 等普通网络功能。

4.3 受害者配置

受害者设备针对攻击者的 UID 启用了“始终开启 VPN”和“阻止未通过 VPN 的连接”。运行时确认使用了多个 OEM 的 Android 16 配置。在 Pixel 8 Pro 测试中，使用了研究人员控制的 Wi-Fi 网络及外部物理接口抓包；基于高通的设备提供了对活跃物理网关插槽的观测结果 [21; 22; 27; 15; 16; 17]。

研究中使用 ADB 和 root 权限进行研究插桩和数据包采集，但这二者并非通过公开 API 路径实施利用的前提条件。
维度公开声明
应用权限普通第三方应用。
运行时危险权限核心公开 API 行为无需任何权限。
常见声明权限ACCESS_NETWORK_STATE 和 INTERNET。
特权 keepalive 权限公开 API 路径不需要 PACKET_KEEPALIVE_OFFLOAD。
Root / ADB利用时不需要；仅用于实验室环境插桩。
用户交互本地 PoC 变体只需用户初次启动应用。
网络条件支持 NAT-T keepalive offload 的 Wi-Fi，且存在可用的非特权槽位。
VPN 条件实测环境下开启了 Always-on VPN 并启用“未连接 VPN 时阻止所有连接”。
泄露的数据真实的非 VPN 源 IP 及时间信息，发送到攻击者指定的 UDP/4500 端点。
发送频率受控 Pixel 配置下的公开最小间隔。

5. 漏洞：NAT-T Keepalive 绕过 VPN 锁定

5.1 公开 API 调用序列

实际攻击使用的是文档公开的路径：

IpSecManager.UdpEncapsulationSocket socket =
        ipSecManager.openUdpEncapsulationSocket();

SocketKeepalive keepalive = connectivityManager.createSocketKeepalive(
        network,
        socket,
        sourceAddress,
        destinationAddress,
        executor,
        callback);

keepalive.start(10);

该公开 API 最终会调用基于 fd 的 Binder 方法，与隐藏的 raw-fd 路径使用的是同一机制。受控 Wi-Fi 环境下的线上测试结果正是通过这一文档化序列实现的，无需借助 raw Binder [8; 9; 10]。

5.2 数据包路径与缺失的判断逻辑

NattSocketKeepalive.startImpl() 调用 IConnectivityManager.startNattKeepaliveWithFd(...)；ConnectivityService 通过 KeepaliveTracker 将请求转发至 NetworkAgent 和 Wi-Fi 后端。在启用硬件卸载之前，准入决策并未校验原始调用方的有效 VPN 策略。一旦移交给 Wi-Fi 后端，持续的报文发射便脱离了应用层套接字写入的管控，不再受基于 UID 的 VPN 路由和 lockdown 防火墙规则拦截 [11; 12; 26].

5.3 数据包控制范围

攻击者可在 API 及路由约束范围内控制目标地址，并观测物理网络暴露的真实源地址。平台固定了 NAT-T 载荷。该原语泄露真实 IP 地址以及时序/节奏，但不承载任意应用层内容。

5.4 原始 Binder 作为佐证

原始 Binder 诊断显示，服务端未对提供的文件描述符或声称的 IpSec 资源进行身份验证。经审查的验证路径表明，isNattKeepaliveSocketValid(fd, resourceId) 接受任何非空 fd，且未实质性参考 resourceId；诸如 0、-2、Integer.MAX_VALUE 和 Integer.MIN_VALUE 等虚假值均未被视为所有权检查。这些诊断结果佐证了资源真实性方面的发现。VPN-lockdown 利用结果基于文档化的公共 API，不依赖稳定的 Binder 事务编号或隐藏 API 构造。源码行锚点为经审查的 AOSP Connectivity 分支上的 KeepaliveTracker.makeNattKeepaliveInfo(... resourceId ...) 和 isNattKeepaliveSocketValid(...) [12].

补充模糊测试发现，在准入后广泛接受 IPv4 目标地址，并存在由路由驱动的 IPv6 行为。这两项结果均非 VPN-lockdown 绕过的前提条件。

6. 根本原因：信任模型崩塌与资源验证废弃

基于文件描述符（fd）的 Binder 方法融合了两种信任模型。早期的原生 fd NAT-T 保活 API 仅对特权进程开放。在 API 审查期间，公开的 UdpEncapsulationSocket 保活请求也被路由至该方法，为了支持公共 IpSec/IKE 应用，无条件权限检查被移除。随后，安全准入机制要求公开调用方证明其拥有活跃的 IpSecService 封装套接字资源，而缺乏此类资源的原生 fd 调用方则保持特权身份。

系统缺失了两项关键检查。服务器在接受公共 NAT-T 保活请求时，未验证复制的 fd 是否确实对应于调用方拥有的、处于活跃状态的 IpSec 封装套接字资源。同时，它在启动卸载路径前，也未检查针对调用方 UID 的 VPN/锁定策略是否禁止物理底层发送。一旦通过准入，Wi-Fi 卸载路径即在常规应用套接字路径之下发送数据，从而绕过了锁定策略对调用方的常规约束。

源码历史显示，资源验证和生命周期锁定曾短暂存在过。该实现曾验证调用方 UID 的所有权，将封装套接字锁定至保活周期结束，拒绝重复活跃使用，并在最终停止时释放资源。但由于服务依赖和死锁风险，这些代码被回滚。逐 UID/逐网络配额机制取代了原有的逻辑。配额仅能限制资源耗尽，却无法验证 fd/资源配对的合法性、维持 IpSec 生命周期租约或执行 VPN 策略。

提交 ID 已于 2026-05-30 对照 AOSP packages/modules/Connectivity Gitiles 仓库进行了重新核验 [28].

该变更强制执行调用方所有权检查、资源校验、重复使用拒绝和生命周期固定。
日期变更安全相关性
2015数据包保活卸载作为特权平台行为存在。基线：并非面向不可信应用的通用发送原语。
2019-01为特权原生 fd 调用方引入基于 fd 的 NAT-T 保活支持。首个基于 fd 的版本仍强制执行保活权限。
2019-03公共 UdpEncapsulationSocket 保活迁移至基于 fd 的方法。共享方法无法再使用单一无条件的特权检查，否则会破坏公共 API。
2019-04增加 IpSec 资源验证和生命周期锁定。
2019-05IpSec 校验栈因服务依赖/死锁问题被回退。fd/资源所有权和生命周期检查被移除。
2019-05校验被替换为按 UID/按网络的配额限制。配额只解决资源耗尽问题，无法保障机密性、fd/资源真实性或 VPN 路由策略。
2023+同一个 Binder 方法中新增了自动开关和 underpinnedNetwork 字段。更多由调用方提供的状态到达同一个准入点，需要同样的校验模型。

回退操作移除了以下安全检查：

被移除的检查原有控制当前后果
裸 fd 与公开 UdpEncapsulationSocket 调用方应采用不同的信任模型。早期的特权裸 fd 方法加上后来的 IpSec 校验栈。两者都能调用 startNattKeepaliveWithFd(...)；单一的无条件权限门槛不够，且校验已缺失。
公开调用方必须拥有所提供的 encap-socket 资源。IpSecService.lockEncapSocketForNattKeepalive(...) 会查找调用方自有记录。当前校验未将 resourceId 作为所有权凭证。
无效或其他 UID 的资源 ID 应在 offload 前失败。被回退的 IpSecService 测试覆盖了无效资源和无效 UID 的场景。伪造的 ID 属于真实性失败，而非有意义的授权检查。
encap socket 应在 keepalive 的整个生命周期内保持存活。NattKeepaliveRecord 会固定持有 EncapSocketRecord。当前路径只持有一个复制的 fd，没有 IpSec 资源租约。
一个 encap 资源不能同时支撑两个活跃的 NAT-T keepalive。被回退的 KeepaliveTracker 资源锁定会拒绝重复使用。槽位配额可能在单台设备上掩盖重复使用，但无法对重复的资源使用进行身份验证。

公开 API 复制了一个 UdpEncapsulationSocket 的文件描述符（fd），将 socket.getResourceId() 通过 NattSocketKeepalive 传递，并携带 fd、资源 ID、自动开关状态及 underpinnedNetwork 调用 IConnectivityManager.startNattKeepaliveWithFd(...)。ConnectivityService 将这些字段转发给 KeepaliveTracker；现有的 socket 校验逻辑仅接受非空的 fd 状态，既未证明该 fd 对应调用方拥有的活跃 IpSec 资源，也未在 NetworkAgent 或传输后端启动硬件 offload 前强制执行有效的 VPN 策略 [9; 10; 11; 12]。

7. 评估

运行时证据分为三个层级。在 Pixel 8 Pro 的 Wi-Fi 配置下，Android 接受了来自普通应用的公开 NAT-T keepalive 请求，并在 VPN 锁定（lockdown）生效期间，于物理 Wi-Fi 接口上发送了重复的 UDP/4500 数据包。由于数据包在此处已越过 Android 的 VPN 策略边界，独立的 OpenWrt AP/路由器 tcpdump 是控制矩阵中权威性的观测点。三星 SM-F966B 在 Qualcomm WLAN 硬件上独立确认了同一公开路径，通过维持一个活跃的路由器导向物理 Wi-Fi 插槽超过一天的租约得以实现。搭载 Qualcomm 硬件的 Nothing A059 则在未进行外部抓包或时长测量的情况下，通过一个物理网关 Wi-Fi 插槽，提供了第三方 OEM 的公开路径准入及活动回调确认。

7.1 受控 Pixel 抓包

在锁定（lockdown）生效期间，公开 NAT-T keepalive 路径在物理 Wi-Fi 上产生了线下的 UDP/4500 流量。独立的 OpenWrt AP/路由器每 10 秒记录到一个字节的 UDP 有效载荷：

2026-05-28 18:36:31.709917 phy1-ap0 P   IP 192.168.1.182.38904 > 1.2.3.4.4500: UDP, length 1
2026-05-28 18:36:41.710042 phy1-ap0 P   IP 192.168.1.182.38904 > 1.2.3.4.4500: UDP, length 1

公开调用路径使用了 IpSecManager.openUdpEncapsulationSocket() 和 ConnectivityManager.createSocketKeepalive(...)；应用侧的原语操作无需 root 权限、ADB、隐藏 API、原生 Binder 构造、JNI、危险运行时权限，或 PACKET_KEEPALIVE_OFFLOAD 权限。

调用者在 API 和路由约束内选择目标地址。接收端会观察到设备真实的非 VPN 源地址及心跳间隔；载荷则始终保持平台固定的 NAT-T keepalive 格式。

7.2 三星系统的独立运行时验证

VPN Leak Guard 在搭载高通芯片、运行 Android 16 构建版本 BP4A.251205.006.F966BXXUABZF1 的三星 SM-F966B 设备上，得出了独立的跨 OEM 厂商运行时结果。其 keepalive 实现排除了 VPN 逻辑网络，选中物理网络中经验证的 IPv4 默认网关，打开 IpSecManager.UdpEncapsulationSocket，并以该物理网络和网关作为 UDP/4500 目标，调用 ConnectivityManager.createSocketKeepalive(...)。三星设备在测试中接收到了活跃的回调，并暴露出一个处于活跃状态的物理网关 Wi-Fi 插槽 [13; 15]。

观察快照显示，该 Wi-Fi 插槽的最高计数值与最新计数值均为一。一份经过脱敏处理的截图记录表明，在租约持续运行 24 小时 32 分钟时，该插槽仍保持活跃状态 [17]。这为三星/高通技术栈上存在漏洞的公开路径及物理网关目标提供了独立的运行时确认。Pixel 系列矩阵仍是唯一具备受控外部数据包捕获能力的对照组；三星方面则提供了活跃插槽和租约时长的测量数据。

7.3 无活跃插槽的确认

VPN Leak Guard 还记录了一台 Nothing A059 设备：product 为 Asteroids、主板为 volcano，运行在高通（qcom）硬件上。系统为 Android 16（SDK 36），安全补丁级别 2026-06-01，build ID 为 BQ2A.250721.001-BP2A.250605.031.A3。该防护器排除 VPN 逻辑网络，选择经过验证的物理 IPv4 默认网关，并且只在 SocketKeepalive.Callback.onStarted() 执行时才把槽位标记为活跃。观测报告工厂会忽略零槽位的最大值。只读快照把最高活跃 Wi-Fi 槽位数和最新活跃 Wi-Fi 槽位数都记录了下来 [13；14；16]。

这一行数据证实，第三家 OEM 设备上也存在对公共物理网关的放行以及活跃回调。但其证据仅限于活跃槽位结果，没有采集路由器抓包、数据包节奏、租约时长、生命周期、持久化或重启后的结果。

7.4 对照与基线

在普通 UDP 封锁对照组中，应用侧记录到了 UDP 发送，但路由器抓包中没有匹配的 UDP/4500 或 UDP/12345 数据包。因此在物理抓包中，普通被封锁覆盖的 UDP 受限或完全缺失，而 NAT-T keepalive offload 流量却出现在 AP 边界上。

三条策略基线限定了上述解释的范围。关闭 VPN 和封锁时，路由器上能看到普通 UDP 和 keepalive 流量；开启 VPN、关闭封锁时，路由器上能看到 keepalive 流量，而普通 UDP 则通过 VPN 接口传输；同时开启 VPN 和封锁时，路由器上仍能看到 keepalive 流量，而普通 UDP 封锁对照流量在物理抓包中依然缺失。

7.5 生命周期行为

在 Pixel 上完成配置后，只要设备保持通电，keepalive 在以下场景中始终保持活跃：进入后台、锁屏、强制休眠、省电模式、受限待命桶、Binder 冻结/进程观察，以及 GrapheneOS 重新锁定并不重启直接回到 BFU 状态。在 Samsung 设备上，那个唯一的活跃 Wi-Fi 槽位持续被租用超过一天（实测），在截取脱敏证据截图时仍处于活跃状态。

观察到的停止边界包括：手动强制停止、卸载应用、网络中断以及设备重启。在手动强制停止、卸载应用和重启操作前，数据包均已存在；Wi-Fi 断开会以“网络丢失”错误终止活动中的保活会话，而在 Wi-Fi 恢复后手动重新武装即可使其恢复。

7.6 槽位数量与租期

在测试的 Pixel 8 Pro Wi-Fi 配置中，经过特权预留后，应用 UID 仅暴露出一个无特权保活槽位。首次占用被接受，后续尝试获取槽位均因 ERROR_INSUFFICIENT_RESOURCES (-32) 而失败。三星 SM-F966B 独立地暴露出一个活动 Wi-Fi 槽位，并维持了所测量的整个租期。Nothing A059 也暴露出一个活动 Wi-Fi 槽位；该记录未测量持续时间 [16]。

8. 影响

对攻击者的直接价值在于反复进行实际网络身份披露。由攻击者控制的目的地可以从物理 Wi-Fi 网络的角度获知源 IP 地址，确认设备仍处于在线状态，以及在保活武装期间捕获数据包的时间特征。根据网络环境不同，源 IP 可能泄露 ISP 归属、组织机构、旅行状态，或将本应处于 VPN 后端的设备与非 VPN 接入网络进行关联。

泄露的危害根植于用户可见的锁定承诺：受管应用应当采取“故障关闭”策略，避免向攻击者选定的目的地暴露非 VPN 网络身份。即使未发生载荷外泄，周期性信号仍可支持存在性检测、IP 关联以及与其他观测结果的时间关联。实测的三星设备租期超过一天。

8.1 设备类别暴露

所审阅的 IEEE 与 Wi-Fi Alliance 材料中，并未包含关于通用 WLAN keepalive offload 的强制规定。公开的实现历史反而指向低功耗网卡/驱动契约以及供应商的 FullMAC 固件接口。早在 2009 年，Windows 7 的 NDIS 6.20 模型已支持低功耗 ARP、IPv6 邻居 solicitation 以及 802.11 RSN/GTK offload；2011 年，IEEE 802.11v 标准化了相邻的无线网络管理 keep-alive 及代理机制；到 2014 年，公开的 Android WLAN 源码证据表明，高通固件已提供用于 STA keepalive 和 IPsec NAT keepalive 的命令接口；而至 2015 年 Android 6 / Marshmallow 版本时，AOSP 已包含隐藏 NAT-T keepalive 框架支持。涉及应用可见 Wi-Fi keepalive offload 的 Android 兼容性要求出现得较晚，见于 2019 年发布的 Android 10 CDD [29; 30; 31; 32; 33].

应用可见的槽位（slot）属于 Android 兼容性模型的一部分。Android 10 的 2019 年 CDD 要求：凡暴露 Wi-Fi keepalive offload 能力的设备，必须支持 SocketKeepalive API 以及至少三个并发的 Wi-Fi keepalive 槽位。对槽位/资源的检查未发现任何厂商叠层有意将相关默认值置零的情况。

在已确认的两个 WLAN 系列内，运行时结果跨越了不同 OEM 边界。Pixel 8 Pro/Broadcom 配置在受控 AP 抓包中发出了数据包。Samsung SM-F966B/Qualcomm 配置在整个测量的租约期间维持了一个活跃的、指向路由器的 Wi-Fi 槽位。另一家基于高通方案的 OEM 确认了公共物理网关路径，并为一个 Wi-Fi 槽位到达了活跃回调 [27; 34; 35; 13; 14; 15; 16; 17].

存在漏洞的准入路径来自 Android 12+ 的框架公共行为，因此相关平台窗口从 2021 年 Android 12 发布时开始。固件与源码的排查显示，所追踪的全部七个 Android WLAN 协议栈家族都存在 keepalive 或 offload 数据包的支持面：Qualcomm QCA/CLD3/FastConnect、Qualcomm WLAN/QDSP6 WCNSS、Broadcom/Cypress bcmdhd/DHD、MediaTek CONSYS/Connac、Unisoc/Spreadtrum SPRDWL、Samsung S.LSI/Exynos Wi-Fi，以及 Huawei/HiSilicon Hi11xx。这些家族最早可查的公开支持证据分布在 2014 到 2020 年之间 [33; 36; 37; 38]。

结合三家 OEM、两个已确认 WLAN 家族的运行时验证结果、Android 12+ 的共享实现、slot 默认配置，以及七大家族的固件排查，可以确认这属于影响绝大多数 Android 12+ 设备的设备级别暴露面。所映射的 WLAN 家族覆盖了 2021Q4 至 2026Q1 期间预估 Android/AOSP 衍生出货量的 91.24%，剩余 8.76% 属于尚未确认的混合/长尾 SKU [39; 36]。

9. 应用生态研究

公开 API 的存在并不代表存在兼容性需求。一项针对 F-Droid/IzzyOnDroid 的静态研究测量了 Android 框架中 IPsec、IKE 和 NAT-T 机制的实际使用情况。在所有扫描来源中，扫描器未发现任何框架 API 调用，也没有发现针对相应事务的方法级原始 Binder 调用 [40; 41]。

9.1 语料与方法

采集过程于 2026-07-05 下载了签名的 F-Droid 和 IzzyOnDroid v1 索引，提取并规范化了声明的源码 URL，并克隆了可访问的仓库，最终得到 4,888 份按包组织的逐次检出报告。这些报告包含 4,679 个不同的 gitOrigin 字符串；下表按精确的原始存储 URL 对按包的观察结果去重，并未合并可能指向同一上游项目但拼写不同的 URL。

本次分析采用静态和词汇级方法：扫描源代码与清单文件，识别框架 API 调用、特定方法的原始 Binder 事务以及 VPN 比较候选项，同时排除生成的构建目录、依赖缓存、Git 元数据以及超过扫描器大小限制的文件。随后，人工审查了 VPN 比较候选项，检查其是否具备面向用户的 Android VpnService/TUN 风格行为。扫描器无法获取的目录条目、克隆目标或源码检出结果，不在该独立来源分母的统计范围内。

扫描结果如下：

观测概念独立来源占比
Android 框架 IPsec、IKE 或 NAT-T API 使用00.00%
针对特定方法的原始 Binder 调用（IPsec/IKE/NAT-T 事务）00.00%
人工审查的 Android VpnService 应用731.56%

经人工审查的 VpnService 应用集合证实，扫描语料库中确实包含普通的 Android VPN 应用。这些应用使用的是标准的 VpnService 路径；其中没有任何一个提供与框架 IPsec/IKE/NAT-T 相匹配的功能。

9.2 解读

Android 向普通应用程序开放了变换构建、SPI 分配、UDP 封装、框架 IKE 协商、迁移、状态查询以及硬件 NAT-T 卸载等功能。样本中未发现对这些框架机制的使用。所提出的修复方案针对 NAT-T 心跳（keepalive）准入，重点围绕 fd/资源所有权及有效的 VPN 锁定策略；普通 Java/NDK 网络功能及 VpnService 路径不在其范围内。

F-Droid 和 IzzyOnDroid 排除大量专有企业级 VPN 软件、OEM 客户端、运营商软件以及侧载的闭源应用。因此，“零”这一结果仅描述此开源样本，无法确立普遍性缺失。

9.3 Google Play 交叉核查

截至 2026-07-29 的 Google Play 及网络普查发现了 29 个候选项：其中 26 个当前仍在列，3 个已被移除。在 26 个当前列出的应用中，获取了 9 个的 APK；其余 17 个仅有列表信息。获取的集合包含 8 个专有 APK 和 1 个开源 APK。两个专有 APK 包含了全部 47 个经过验证的平台 SDK 调用点：FortiClient VPN 中占 37 个，SmartVPN 中占 10 个。其他 7 个已获取的 APK 中均未包含 [42]。

FortiClient VPN 在 Google Play 上的累计安装量达 3,995,326 次，SmartVPN 为 139,322 次，两者合计 4,134,648 次。Google Play 公开的下载徽章背后隐藏了这些精确的累计安装字段 [42]

“Stale”指在 2026-07-29 时仍保留在列表中但超过三年未更新的应用。共有六个候选应用已下架或处于 Stale 状态 [42]

应用商店状态安装/下载量
VpnCilla2025-03-27 下架约 48,000
NCP VPN Client2019-07-16 下架约 22,000
VPN Taiwan – Secure Taiwan IP2026-06-17 下架16,241
Secure Tactical VPN Client最后更新于 2023-06-0218
VPNGN最后更新于 2023-07-0421,445
Melba VPN最后更新于 2023-05-311,317

DEX 验证器统计的是目标为平台方法的 invoke-* 指令，而非偶发的字符串、类描述符、方法签名或帮助文本引用。

10. 缓解措施与回归测试

针对任何保留的普通应用路径的修复方案，应在保留授权 NAT-T keepalive 的同时，使覆盖范围内的普通应用的物理 underlay offload 采用 fail closed 策略。修复点在于准入 startNattKeepaliveWithFd(...) 及其关联的 keepalive 生命周期：平台必须认证 fd/资源对，判定调用者是否可以在选定的物理网络上发送数据，并在该授权失效时停止相关记录。

10.1 NAT-T 修复职责

  • 未持有有效公共 IpSec 资源的原始 fd 调用者仍受 PACKET_KEEPALIVE_OFFLOAD 限制，并接收基本的 fd 格式验证。
  • 公共 UdpEncapsulationSocket 调用者需证明拥有活跃的 IpSecService encap-socket 资源，证明重复的 fd 与存储资源匹配，且不能将一个资源复用于并发活跃的 NAT-T 记录。
  • ConnectivityService 在清除身份前捕获调用的完整 UID，检查目标网络及任何 underpinnedNetwork 关系，若该 UID 的有效 VPN/lockdown 策略会阻止直接发送，则拒绝物理 underlay offload。
  • 只有在准入成功后，KeepaliveTracker 和传输层后端才会启动 Wi-Fi 或蜂窝 offload，并在拒绝、构造失败、binder 死亡、数据包替换失败、客户端停止或系统最终停止时，恰好释放一次资源。
  • VPN、lockdown、owner、底层网络和所选网络发生变化时，会撤销或重新验证处于活跃和暂停状态的 NAT-T 记录，然后才允许其恢复发送。

10.2 回归测试

针对此漏洞的回归测试应证明：未授权的 keepalive 在槽位分配、包过滤器安装、传输启动、回调成功或 IpSec 资源变更之前就会失败。最基本 的负面用例包括：

  • lockdown 已启用时，一个被覆盖的普通应用请求公网 NAT-T keepalive；
  • 当 lockdown 开始覆盖调用者的 UID 范围时，之前已准入的记录会被停止；
  • 当相关 VPN 被移除、更换 owner、更改可绕过性或失去底层网络时，运行中 和暂停中的记录都会被停止；
  • 过期、已关闭、不匹配、属于其他 UID 以及重复活跃的 IpSec 资源在 offload 前会被拒绝；
  • 使用 raw-fd 且资源 ID 无效或缺失时，需要特权 keepalive 权限；
  • 拒绝和最终停止路径会关闭传入的 ParcelFileDescriptor，并恰好释放一次已获取的 IpSec 租约。

正面测试应证明：只要其生效的 VPN 策略允许所选物理发送通道，拥有活跃 encap-socket 资源的合法调用者仍然可以使用 NAT-T keepalive [11; 12]。

11. 披露、伦理与材料

该发现已于 2026-05-15 报告给 Android 漏洞奖励计划。Google 当天完成了分诊，并在 Android Security 评估该问题的同时请求协调披露。报告者声明该发现未曾公开发布或分享给第三方，并于 2026-05-17 提交了额外的验证材料，随后在 Google 于 2026-05-19 将该报告标记为规范问题 386376240 的重复项后，请求披露指引。

研究人员于 2026-06-12 通过 VRP 报告向 Google 发出了即将公开披露漏洞的通知。随后，在研究人员可见的 VRP API 记录中，出现了来自两个账号的 Google 更新标记，日期分别为 2026-06-12 和 2026-06-15，但这些标记均经过脱敏处理，未显示具体评论内容。该记录中不包含任何异议、延期请求、CVE 编号分配、修复状态更新、严重程度判定、奖励决定或发布许可。公开披露始于 2026-07-29。

实验使用的是研究人员自行控制的设备、VPN 配置、数据包捕获及端点，未收集任何第三方用户流量。发布的工件仅限于脱敏后的证据和复现材料；私有 VRP 内容、本地标识符、用于武器化的原始跟踪数据以及补丁差异均已被排除在外。

利益冲突声明：本文作者销售 VPN Leak Guard，这是一款商用 Android 应用，本文报告的关于活动插槽的观察结果即由该应用产生。

12. 局限性

运行时测试覆盖了三款设备型号，但这并非穷尽式的逐型号清单。Pixel 8 Pro/Broadcom 的结果包含受控的数据包捕获矩阵。Samsung SM-F966B/Qualcomm 的结果包含一个活动的物理网关插槽及实测租约。Nothing A059/Qualcomm 的结果确认了公共路径的准入机制及活动的回调，但外部数据包捕获和持续时间尚未进行测量 [15; 16]。

重启后的持久性尚未得到确认。Pixel 的 keepalive 在观察到的重启边界处停止，Samsung 的租约是在设备保持通电状态下测量的，而 Nothing 的生命周期和重启行为则未加测量。

蜂窝数据包的发送未加测量。源码分析显示，框架的准入路径与传输层无关，且 Android 16 兼容性资料指出，在至少拥有一个蜂窝插槽的情况下，蜂窝 keepalive 卸载功能可暴露给第三方应用。所测试的 Pixel 默认配置在蜂窝调制解调器路径发送流量前，就因资源不足而返回失败；普通应用的有效执行取决于制造商的插槽叠加层、硬件/HAL 的可用性、特权插槽预留、按 UID 的非特权限制以及传输后端的行为 [25; 8; 43; 12]。

本研究共获取了 Google Play 现有 26 个应用列表中 9 个应用的 APK 文件。商店的统计数字汇总了各版本及 VPN 模式下的累计数据，既不代表当前活跃用户数，也不反映特定平台路径的使用情况。DEX 分析结果仅适用于所获取的 APK 版本。

研究未在任何打过补丁的 Android 版本、打过补丁的设备上执行抓包，也未进行完整的设备级 atest 测试。因此，该修复方案仍属于源码层面的建议，尚需进行实施层面的回归测试。

13. 相关工作

VPN 数据泄露的对比分析取决于攻击者位置、触发条件、端点控制、数据包特征、访问频率、执行层、测量范围以及被绕过的用户可见策略。NAT-T 案例利用一个已安装的正常应用，在 Android VPN 锁定功能开启时，向攻击者指定的互联网端点发送固定形式的重复 UDP/4500 数据包，以此构造风险环境。

TunnelCrack 和 TunnelVision 类研究表明，路由例外配置和恶意的本地网络环境可使受影响的平台突破 VPN 防护预期 [1; 44; 45; 46]。这些攻击依赖恶意本地网络，而 NAT-T 案例则利用已安装的应用程序。两者都在检验数据包是否会跨越预期的 VPN 边界。

关于 IPv6、DNS、WebRTC 以及 VPN 生态系统的研究提供了更广泛的隐私与测量背景。Perta 等人、Al-Fannah、Cho 和 Heidemann、Khan 等人、VPNalyzer/VPNInspector、Wu 等人以及 Yang 等人的工作表明，源 IP 暴露、域名解析器行为、共享的 VPN 状态以及严谨的测量边界至关重要 [2; 3; 6; 4; 5; 47; 48; 7]。

上述研究主要测量 VPN 的行为、基础设施、隐私特性或客户端属性。本生态系统研究则测量了 Android 框架中 IPsec/IKE/NAT-T 机制在兼容性方面的需求。F-Droid 和 IzzyOnDroid 支持源码级别的检查 [40; 41]，但排除了大量专有的企业和商业 VPN 软件。因此，研究得出的“零漏洞”结果仅作为 NAT-T 保活连接准入兼容性背景的证据，无法据此估算其在整个 Android 市场的普遍率。

AutoAcRaptor 是同一 Android 框架入口点上最接近的先行研究。它是一项针对 AAOS 访问控制的广泛研究，曾将 ConnectivityService.startNattKeepaliveWithFd 标记为已验证的缺失权限异常：相关的 keepalive API 需要签名级的 PACKET_KEEPALIVE_OFFLOAD 权限，而基于 fd 的路径却不需要 [18; 19; 20]。该工作发现了这个可疑入口点，但没有验证 Android 手机上 VPN 锁定绕过的问题。本文的 NAT-T 分析则将该入口点与公开的 UdpEncapsulationSocket keepalive、Wi-Fi offload，以及绕过手机 VPN 锁定向外发包联系了起来。

Android QUIC close-payload 委托 UDP 发送是最接近的 Android 委托发送同类案例。它展示了应用触发的 UDP 发送可以绕过常规的 VPN 发送路径 [49; 50; 51]。两者的区别在于：QUIC close-payload 是一次性或事件驱动的软件发送，而 NAT-T keepalive 是重复的、固定格式的 UDP/4500 Wi-Fi offload 流量。

Mullvad 的 Android 连通性检查与 DNS 泄漏报告、GrapheneOS 的 VPN 泄漏拦截工作，以及本地链路/组播相关讨论都表明，Android 的 VPN 强制执行长期以来既依赖平台例外，也依赖 VPN 应用的自身行为 [52; 53; 54; 55]。它们与 NAT-T 案例在端点控制、触发方式、发包节奏和数据包形态上都有差异。这些工作也提示我们：委托或豁免的流量必须对照用户的锁定预期加以核查。

14. 讨论

14.1 审查失效与默认失败的发布纪律

公开路径与特权路径通过不同的信任要求调用同一个 Binder 方法，且缺乏完整的准入边界。2019 年，系统加强了对所有权的控制，并引入了文件描述符身份验证、生命周期管理、重复使用检测以及无效资源检查，但这些措施后来因技术上的服务依赖和死锁问题而被撤销。随后，系统用基于 UID 和基于网络配额的机制取代了上述检查。然而，配额仅能限制资源消耗，无法提供等效的文件描述符/资源真实性验证、生命周期管理或 VPN 策略网关控制 [28; 12]。

剩余的验证待办事项涵盖无效、已关闭、过时、不匹配、属于其他 UID 以及重复的资源；原始 fd 权限；租约清理；以及在 keepalive 处于活跃或暂停状态期间的授权变更。技术上合理的回退本身并不构成缺陷。在那些验证义务仍未完成的情况下，若缺乏等效控制措施就发布普通应用路径，则是代码审查与发布治理层面的失职。这一判定针对的是流程及由此产生的控制缺口，而非任何具体的个人贡献者。

在具备可接受的公开/私有 API 拆分方案以及完整的安全检查准备就绪之前，非特权可用性本应维持在零槽位状态。资源配额不能充当物理底层发射原语（physical-underlay emission primitive）的发布授权依据。

14.2 弃用普通应用的 IPsec 访问

Android 应弃用面向普通应用的公开 IPsec、IKE 和 NAT-T 接口，并将框架功能提升为系统特权级别。认证运营商、IWLAN、VCN、平台 VPN 及其他平台内部消费者应予以保留；仅仅移除普通应用的访问权限并不能替代它们当前的角色 [56; 57; 58]。

普通应用默认应获得零个暴露槽位。如果必须保留遗留访问权限，其应置于一个默认关闭、且需重启生效的兼容性开关之后，其发布姿态应类似于无线电代际控制。普通 VPN 应用仍可继续通过 VpnService 运行其自身的用户态协议实现 [23]。

开源扫描在 4,679 个应用来源中未发现平台 API 消费者；Play 商店研究中在 9 个已采集的 APK 中仅发现 2 例。FortiClient VPN 与 SmartVPN 在 Google Play 上的累计安装量合计约 413 万次，而 Google 报告称其活跃 Android 设备已超 30 亿台。这两款应用同时支持不依赖平台通道的 VPN 模式。我估算，依赖这些平台 API 的 Android 用户比例不超过 0.01%，即每万人中仅有一人。该群体规模过小，不足以作为默认向普通应用开放访问权限的理由。 [40; 41; 42; 59]

14.3 路由器终结式 VPN 指南

对于无法容忍手机端 VPN 逃逸的威胁模型，外部强制 VPN 路由器是可识别的隐私与从业者社群普遍认可的保守方案。Mullvad 报告指出，2022 年出现过针对连通性检查的 Android 绕过类型，2024 年出现 DNS 绕过，2026 年则出现由应用触发的 QUIC 流量绕过。IVPN 独立复现了 2026 年的 QUIC 绕过路径，GrapheneOS 社群指南亦建议采用外部路由器以隧道化手机的上行流量 [52; 53; 60; 61; 62].

上述报告涉及不同机制，并不意味着所有 Android 流量始终会绕过 VPN。但其反复出现表明，Android 现行架构已多次暴露新的手机端绕过路径，无法负责任地承诺不会再出现新的绕过类型。

该建议是附条件的。手机须以该路由器为唯一互联网出口，禁用或单独阻断蜂窝网络及备用网络；且路由器在隧道失效时必须采取封闭失效策略。此方案降低了对 Android VPN 强制机制的依赖，但并非对路由器缺陷、局域网暴露或其他无线电通道流量的无条件保证。

15. 结论

受影响的是 Android 12 及以上、暴露了应用可见的 Wi-Fi NAT-T keepalive offload 且提供可用非特权槽位的设备。在这类设备上，一个普通的受控应用无需通过有效的 VPN 锁定准入检查，就能使用物理底层网络的 offload 能力。现有的运行时、框架、槽位、固件和出货量证据表明，大多数 Android 12+ 设备都存在这一暴露风险 [25; 39]。

修复方案必须区分特权 raw-fd 请求和公开的 UdpEncapsulationSocket 请求。raw-fd 调用方需要持有 PACKET_KEEPALIVE_OFFLOAD 权限；公开调用方则需要经过调用方资源验证、fd 身份检查、生命周期锁定以及重复使用拒绝。两条路径都必须在进入 NetworkAgent 或 HAL 之前完成有效的 VPN 策略授权，并在相关网络或 VPN 状态变化时重新验证。在这些检查完成之前，非特权 NAT-T offload 应默认拒绝（fail closed）[11; 12]。

16. 附录 A. 证据

文中展示的 pcap 哈希使用 12 位十六进制 SHA-256 前缀。

A.1 环境与边界证明

  • 主要测试手机：Pixel 8 Pro（husky），Android 16 版本 CP1A.260505.005，安全补丁 2026-05-05。
  • 独立测试手机：三星 SM-F966B（q7q），高通（qcom）硬件，Android 16 版本 BP4A.251205.006.F966BXXUABZF1，安全补丁 2026-06-05 [15]。
  • 另一台存在活跃槽位的手机：Nothing A059，设备和产品名 Asteroids，主板 volcano，高通（qcom）硬件，Android 16 / SDK 36，安全补丁 2026-06-01，构建 ID BQ2A.250721.001-BP2A.250605.031.A3 [16]。
  • 更新版本的来源记录：同一非累积快照中还记录了一台运行 Android 17、拥有一个活跃 Wi-Fi 槽位的 Pixel 8 Pro。该条目仅用于证明槽位可用性，不能替代或改标受控环境下 Android 16 Pixel 设备的抓包记录 [16]。
  • VPN 配置：Mullvad 软件包 net.mullvad.mullvadvpn，版本 2026.5。在测量行的 VPN 管理快照中，观察到“始终开启 VPN”和“阻断无 VPN 连接”均已启用。
  • 应用权限：使用标准应用路径，调用 IpSecManager.openUdpEncapsulationSocket() 和 ConnectivityManager.createSocketKeepalive(...)。公开 API 声明无需 root、ADB、危险运行时权限、JNI、隐藏 API、raw Binder 或 PACKET_KEEPALIVE_OFFLOAD。
  • 外部观察点：在物理 Wi-Fi 侧使用独立的 OpenWrt 接入点/路由器进行抓包。在该点观察到的数据包已穿越 Android 的 VPN 策略边界。
  • 数据包形态：固定为 NAT-T UDP/4500 心跳，载荷为一个字节。该原语无法承载任意应用负载。
  • 频率与时槽：观察到了公开的最小间隔。在测试的 Pixel Wi-Fi 配置下，一个非特权时槽被接受，后续时槽尝试以 ERROR_INSUFFICIENT_RESOURCES (-32) 失败。Samsung 行记录了一个活动时槽和测得的租约期。Nothing 行记录了一个无时长测量的活动时槽。

A.2 线上传输抓包、对照与基线

  • 主要 Wi-Fi 证明：应用运行 20260529-023621-pid20917，路由器案例 slot-cadence，18 个数据包，pcap 前缀 d463ea0c9ea7。时槽 0 被接受，UDP/4500 以 10 秒频率出现在物理 Wi-Fi 上。
  • 普通 UDP 封锁对照：应用运行 20260529-023925-pid21402，路由器案例 ordinary-udp-lockdown，零匹配数据包，pcap 前缀 e3f42e268763。在封锁状态下，应用端发往 UDP/4500 和 UDP/12345 的 UDP 数据在路由器侧无匹配数据包。
  • VPN 关闭、封锁关闭基线：应用运行 20260529-031517-pid13504，路由器案例 baseline-vpn-off-lockdown-off，9 个数据包，pcap 前缀 4bc929aeaf54。当禁用 VPN 约束时，普通 UDP 和心跳数据包可见。
  • VPN 开启、封锁关闭基线：应用运行 20260529-032140-pid14963，路由器案例 baseline-vpn-on-lockdown-off，6 个数据包，pcap 前缀 840d5c418933。心跳数据包在路由器侧可见，而普通 UDP 仅存在于应用侧的 tun0 接口。
  • VPN 开启，基线状态下启用锁定：对应应用运行 20260529-024101-pid21674，路由器用例为 baseline-vpn-on-lockdown-on，共 6 个数据包，pcap 前缀为 732648acd332。尽管常规 UDP 锁定控制未出现在路由器抓包中，Keepalive 数据包仍可观测。
设备 / 版本WLAN 路径槽位结果证据边界
Samsung SM-F966B（q7q），Android 16Qualcomm（qcom）Wi-Fi1 个活跃 / 24 小时 32 分钟选定物理 IPv4 默认网关；公共回调处于活跃状态；无独立的路由器抓包。
Nothing A059（Asteroids），Android 16 / SDK 36Qualcomm（qcom）Wi-Fi最高 / 最新活跃值：1选定物理 IPv4 默认网关；公共回调处于活跃状态；无外部抓包或时长测量。
Pixel 8 Pro，Android 17Wi-Fi1 个活跃仅记录较高版本中的槽位可用情况；与受控的 Android 16 Pixel 数据包抓包场景不同。

旧版 7 月 28 日快照及脱敏截图提供了 Samsung 行的数据。新版非累积快照提供了 Nothing 和 Android 17 Pixel 行的数据。追踪的 Protector 定义了物理网关选择和活跃回调状态；追踪的报告工厂仅发布大于零的最大值。原始快照保留在只读的本地镜像中，表格仅复现了脱敏后的字段 [13; 14; 15; 16; 17]。

A.3 生命周期与边界行

  • 非破坏性生命周期：应用运行 20260529-013941-pid14044 和 20260529-021757-pid16937，生命周期记录位于 active-lifecycle-* 下。在后台 / 主页、屏幕锁定、强制空闲、电池省电、受限桶以及进程观察窗口期间，应用心跳均保持存活；早期的路由器窗口仅作为工作流程证据，而非独立的线上持久性证明。
  • 强制停止：应用运行 20260529-024326-pid21970，路由器场景 active-lifecycle-force-stop，36 个数据包，pcap 前缀 dc264c7d08a8。 在主机强制停止杀死进程之前，数据包已存在。
  • 卸载：应用运行 20260529-025027-pid23321，路由器场景 active-lifecycle-uninstall，42 个数据包，pcap 前缀 12d0a2a140e7。在软件包被移除之前，数据包已存在。
  • 重启：应用运行 20260529-025521-pid24592，路由器场景 active-lifecycle-reboot，27 个数据包，pcap 前缀 156a67de67da。重启之前数据包已存在。
  • 网络丢失与重新布防：应用运行 20260529-031051-pid12326，路由器场景 network-loss-rearm-manual，6 个数据包，pcap 前缀 63a9bec9367f。Wi-Fi 断开导致 onError -20；Wi-Fi 恢复并手动重新布防后，keepalive 得以恢复。
  • 回到 BFU：Pixel 生命周期观察包含 GrapheneOS 重新锁定/不重启回到 BFU 的延续场景；这并非重启持久化。

A.4 目标地址模糊测试

原始来源： Hacker News

评论 (0)