CloudPhoneRiskKit深度解析：从特征匹配到物理约束验证

前言：
此前发过一篇粗糙的介绍，收到不少反馈说"太浅了"。这次我代码狠狠更新了一遍维护者只有我，claude cursor，把每个设计决策背后的"为什么"都写出来。面向有一定逆向和内核基础的安全研究者，后续视反馈继续更新项目，详细可以看项目

声明：本文所述检测逻辑仅在 iPhone 6s 上做过基础验证，未覆盖全部机型和场景。具体使用时的表现仍需在实际环境中进一步验证。

项目地址：803K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4y4o6V1@1x3K6R3&6y4e0p5$3i4K6u0r3j5$3I4G2N6h3c8H3K9r3!0F1k6g2)9J5k6s2u0A6M7$3E0Q4x3X3c8V1k6i4c8W2j5%4c8G2M7R3`.`.

第零章：从"特征匹配"到"物理约束验证"——设计哲学
传统方案的本质困境
打开 IOSSecuritySuite 的源码，你会发现它的核心结构是这样的：一张越狱路径列表，一张可疑进程名列表，再加几个 fork() 返回值的检查。Guardsquare 在其官方博客中直言不讳地指出："两种攻击可以轻松击败它"——Hook stat()/access() 让路径检查失效，或者直接用 Trollstore 绕过沙盒，让这套基于文件系统可见性假设的检测完全失效。
这类方案的本质是黑名单维护：Cydia 出现了，就加 /Applications/Cydia.app；Sileo 出现了，再加 /Applications/Sileo.app；checkra1n 出现了，再加一条。攻击者和防御者之间永远差一个时间窗口——新越狱发布的那几天，所有基于特征匹配的 SDK 都是盲的。
这是一场注定不对称的战争：攻击者只需要发布一个新工具，防御者就要重新更新规则库、走 App 审核流程、等待用户升级。周期上，攻击者永远领先至少几周。
云手机的结构性矛盾：
云手机（包括模拟器、数据中心裸金属 vPhone）和真实用户设备之间存在若干物理层面的结构性矛盾，这些矛盾不是通过更新攻击工具能绕过的：
重力与 MEMS 传感器的不可伪造性

真实用户手持设备时，MEMS 加速度计会持续产生随机噪声：低频振动（呼吸、手抖）、高频尖峰（点击屏幕的冲击）、重力矢量随姿态变化的慢漂移。机架上固定安装的设备，加速度矢量长时间锁定在 [0, 0, -9.8] 附近，几乎没有噪声。这不是软件层面的问题，是物理定律。
热熵的不可伪造性

手机在用户手中会因散热不畅而积累热量，热状态会在 nominal → fair → serious → critical 之间自然转移。机房设备通常接工业冷却，热状态长期锁死在 nominal，且变化熵极低。
基带与 SEP 状态的不可伪造性

真实 iPhone 有蜂窝基带、Face ID/Touch ID 的 Secure Enclave。云手机为了降成本，通常阉割了蜂窝模块（CTCarrier 返回空），或者 Face ID 硬件根本不存在（LAContext 报告 biometryNotAvailable），或者根本没有用户录入生物特征（biometryNotEnrolled）。这些是硬件能力的缺失，不是可以伪造的软件状态。
DRM 等级的不可伪造性

Apple 的 FairPlay DRM 分为多个等级，真实 Apple Silicon 设备能跑最高等级解码。数据中心的 vPhone 通常运行在降级的 DRM 环境下，AVContentKeySession 的能力探测会暴露这一点。
设计哲学的升级
CloudPhoneRiskKit 的核心设计思路是：不要问"它安装了什么软件"，要问"它是否符合物理现实"。
传统思路（黑名单）：是否有 /Applications/Cydia.app？
↓ 攻击者 Hook stat() → 检测失效
新思路（物理约束）：重力向量是否在合理范围内飘动？
热状态是否在过去 5 分钟有过转移？
Haptic Engine 是否真实存在？
↓ 这些无法通过软件 Hook 伪造

即使攻击者注入了 Frida、Hook 了所有 libc 函数，它依然无法让机架设备产生符合真人手持特征的 MEMS 噪声，也无法让没有蜂窝模块的设备伪造出合法的运营商信息。这是结构性矛盾，不是版本迭代能解决的问题。
这一哲学体现在 SDK 的四层信号设计里：Layer1 负责硬件指纹，Layer2 负责反篡改，Layer3 负责行为熵，Layer4 负责服务端聚合——前三层全部在端侧完成，且越往深层，越依赖物理约束而非特征匹配。

第一章：SDK 整体架构
1.1 三层调用栈
整个 SDK 的调用模型可以抽象为三层：
┌─────────────────────────────────────────────────────────┐
│ 业务应用层 (App) │
│ CPRiskKit.shared.evaluate(config:, scenario: .payment)│
│ setExternalServerSignals(...) │
│ applyGraphRiskFeedback(...) │
├─────────────────────────────────────────────────────────┤
│ RiskDetectionEngine（决策引擎层） │
│ 场景策略 → 决策树 → ComboRule强制规则 │
│ SignalWeights → RiskScorer → CompressedVerdictRule │
│ 安全地板强制（enforceSecurityFloor） │
│ HMAC-SHA256 签名 → ReportEnvelope │
├──────────┬──────────┬──────────┬──────────────────────┤
│ Layer 1 │ Layer 2 │ Layer 3 │ Layer 4 │
│ 硬件指纹 │ 反篡改 │ 行为熵 │ 服务端聚合 │
│ Provider │ Detector │ Provider │ Provider │
└──────────┴──────────┴──────────┴──────────────────────┘

业务层负责场景化调用，告诉 SDK "我现在在做支付"或"我在做登录"。不同场景的阈值策略不同——支付场景对云手机的容忍度更低，登录场景相对宽松。
决策引擎层是大脑，负责把各路信号聚合成一个 RiskVerdict，输出三种动作：allow（放行）、challenge（挑战验证）、block（拦截）。enforceSecurityFloor() 是这一层的护城河——在 Releas

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-290309.htm