Android Accessibility、录屏和远程控制风险，应该如何与 APP 加固一起处理？
APP 加固不能阻止另一款恶意 App 获得系统授予的 Accessibility 权限，但可以保护自身代码、完整性和关键运行路径；金融业务还需要结合 Play Integrity App Access Risk、Play Protect、设备环境证据与服务端高价值动作策略。正确的模型不是“发现无障碍就封禁”，而是把捕获、控制、覆盖层、应用完整性、账号会话和业务动作放在同一条可解释的 Release Gate 中。
摘要
Zimperium 在 2026 年 9 月公开的 RatHat 研究展示了一类跨层移动威胁：恶意 APK 可能通过社会工程诱导用户授予敏感能力，再组合 Accessibility、无线调试/ADB、Native 组件、覆盖层、输入或屏幕获取以及 AI 辅助的界面操作。该研究涉及银行、支付和一次性验证码等高价值场景，但它不应被改写成“Android 平台已经允许任意 App 直接控制设备”，也不应被用来宣称御盾能够自动阻断某个木马。Zimperium RatHat 研究
Google Play Integrity 的 App Access Risk 为服务端提供另一类环境信号：CAPTURING 表示存在可能捕获屏幕或输入输出的运行中 App，CONTROLLING 表示存在可能控制设备并影响当前 App 输入输出的 App，OVERLAYS 表示存在可能在当前 App 上方显示覆盖层的 App。KNOWN_ 与 UNKNOWN_ 表示安装来源语义，不是安全等级；Work Profile 等跨 Profile 场景也可能使结果使用 UNKNOWN_ 前缀。Google App Access Risk verdict
本文不声称御盾已经完成 RatHat 样本、真实银行 App、无线调试或 App Access Risk 的动态测试。候选包、Play Integrity、Accessibility、录屏、控制、覆盖层、账号和服务端决策字段均为 NOT_TESTED，文章提供的是公开安全的工程判断与金融高价值动作门禁方法。
读者对象
本文面向金融、支付、钱包、游戏、企业协作和高价值会员业务的 Android 研发、安全、风控、QA 与发布团队。读者需要区分 App 自身保护、设备上其他 App 的环境风险和服务端业务裁决，避免把 Accessibility、Root、ADB 或单个 Play Integrity 字段包装成“整台设备绝对可信”。
如果需要了解平台完整性、Key Attestation 与 APP 加固的分层边界，可阅读Android 设备完整性、Play Integrity 和 APP 加固；如果需要了解金融业务如何把客户端信号交给后端，可阅读金融 APP 加固与反欺诈边界；Work Profile 和多实例的消歧可参考Work Profile 应用克隆安全。
核心结论
- Accessibility 本身不是恶意。辅助功能、屏幕阅读器、企业工具和自动化测试都可能合法使用相关能力；风险要看当前是否存在能够捕获、控制或覆盖高价值界面的运行环境。
- App Access Risk 描述的是“其他运行中 App 可能具备的能力”，不是已经确认某个 App 是木马，也不是对当前用户作出的欺诈结论。
KNOWN_*与UNKNOWN_*是安装来源语义。UNKNOWN_*可能与侧载、跨 Profile 或非 Play 来源有关，但不能直接等同于恶意；KNOWN_*也不等于绝对安全。- 御盾负责 DEX/SO、二次打包、客户端完整性、运行时 Hook/Debug 风险和关键逻辑保护；它不能阻止另一款 App 获得系统权限，也不替代 Play Integrity 或 Play Protect。
- Android 的 Restricted Settings、Play Integrity、设备完整性和 Play Protect 属于平台层证据；账号、会话和支付/转账是否放行仍应由服务端按照业务价值决定。
- 高价值动作应采用观察、二验、挑战、要求关闭风险 App、临时限制或人工复核等分层策略，不应把一个布尔值作为全量封禁开关。
事实依据与脱敏证据
| 编号 | 官方或已发布来源 | 可确认事实 | 对发布验收的意义 | 不能推出的结论 |
|---|---|---|---|---|
| 1 | Zimperium RatHat 研究 | 公开研究描述了 Accessibility、无线调试/ADB、Native 组件、覆盖层和 AI 辅助 UI 操作的组合风险 | 金融 App 需要把设备环境与高价值动作一起建模 | 御盾已经阻断该样本 |
| 2 | Google App Access Risk verdict | CAPTURING、CONTROLLING、OVERLAYS 是环境信号 |
服务端可将捕获、控制和覆盖层作为风险输入 | 任一信号都等于恶意软件 |
| 3 | Google App Access Risk verdict | KNOWN_* 和 UNKNOWN_* 表示 Play/系统来源与其他来源语义 |
安装来源需要进入解释和复核 | KNOWN 等于安全、UNKNOWN 等于恶意 |
| 4 | Google App Access Risk verdict | 跨 Profile 运行的 App 可能使用 UNKNOWN_ 前缀 |
Work Profile 需要单独记录 Profile 语义 | UNKNOWN 直接证明发生攻击 |
| 5 | Google Play Integrity 概览 | 服务端可按请求和业务动作解释 Integrity verdict | 高价值动作可以采用分层响应 | 整个 App 只能允许或拒绝 |
| 6 | Android 17 CDD | 侧载 App 使用 Accessibility 等敏感能力受到 Restricted Settings 与用户确认约束 | 安装链和权限授予链需要一起验收 | Android 已经无法被社会工程影响 |
| 7 | ADB Wi-Fi 2.0 | ADB 是合法开发调试工具，Android 17 改善了无线调试体验 | ADB 状态可以作为环境字段，但要区分开发与生产 | 开启 Wireless Debugging 就是恶意 |
| 8 | 御盾金融 APP 边界 | 客户端环境信号不应单独形成最终欺诈结论 | 服务端需要结合账号、会话和动作价值 | 客户端单点检测可以取代后端 |
平台事实与工程影响（Report Fact Mapping）
本节把公开平台资料和公开威胁研究转成发布工程问题，不把研究描述写成御盾已经完成的动态测试。
| 平台/威胁事实 | 工程影响 | 建议动作 | 当前状态 |
|---|---|---|---|
| 恶意软件可能组合 Accessibility、ADB、覆盖层与 UI 自动化 | 单个权限开关不能代表整个环境安全 | 将捕获、控制、覆盖层和设备完整性放入风险模型 | NOT_TESTED |
App Access Risk 提供 CAPTURING、CONTROLLING、OVERLAYS |
服务端可以围绕高价值动作做分层处置 | 绑定请求、账号、会话和业务动作 | NOT_TESTED |
KNOWN_*/UNKNOWN_* 是来源语义 |
来源差异需要调查，不能直接变成安全等级 | 记录安装来源、Profile 和分发路径 | NOT_TESTED |
| 经过增强审核的合法 Accessibility 服务可被排除 | 只要检测到 Accessibility 就封禁会误伤 | 保留合法辅助服务和企业工具的策略例外 | NOT_TESTED |
| Android 17 对侧载敏感设置加强 Restricted Settings | 安装链、用户确认和权限授予需要联动 | 在 Release Gate 中记录安装来源和授权结果 | NOT_TESTED |
| ADB Wi-Fi 是合法调试能力 | 开发工具和生产风险需要消歧 | 将 Developer Options、Wireless Debugging 作为环境证据 | NOT_TESTED |
| 御盾保护 App 自身代码和运行时 | 设备上其他 App 的系统权限不属于加固直接控制面 | Original → Basic → Target → Final 对照 | NOT_TESTED |
report_evidence:
report_date: 2026-09-19
rathat_dynamic_test: NOT_TESTED
play_integrity_app_access_risk: NOT_TESTED
capturing_signal: NOT_TESTED
controlling_signal: NOT_TESTED
overlays_signal: NOT_TESTED
accessibility_service_context: NOT_TESTED
wireless_debugging_context: NOT_TESTED
yudun_original_candidate: NOT_TESTED
yudun_basic_candidate: NOT_TESTED
yudun_target_candidate: NOT_TESTED
backend_sensitive_action_policy: NOT_TESTED
production_credentials: CUSTOMER_CONTROLLED_NOT_SHARED
动态时间线与字段时间线
| 阶段 | 记录字段 | 责任主体 | 当前状态 |
|---|---|---|---|
| 平台版本复核 | Android、SDK、Play Integrity Library、Security Patch | Android 研发/安全 | 已有公开文档，非项目测试 |
| 安装链复核 | 来源、Play 许可、Profile、MDM/企业策略 | 发布/设备管理团队 | NOT_TESTED |
| 环境信号请求 | request hash、时间窗、App Access Risk、Play Protect | 客户后端 | NOT_TESTED |
| App 候选基线 | Original、包名、签名、版本、候选摘要 | 御盾与客户 | NOT_TESTED |
| 高价值动作 | 登录、改密、绑卡、支付、转账、提现、权益领取 | 业务/风控团队 | NOT_TESTED |
| 服务端处置 | OBSERVE、REAUTH、STEP_UP、RESTRICT、MANUAL_REVIEW、ALLOW | 客户后端 | NOT_TESTED |
| 回滚复核 | 原始 Release、上一个候选、策略版本和事件原因 | 发布/运维团队 | NOT_TESTED |
技术拆解：环境风险与 APP 加固的边界
Accessibility 是能力，不是风险等级
Android 无障碍服务帮助用户阅读屏幕、完成辅助操作，也可能被恶意软件滥用来观察界面和自动提交输入。安全策略应关注当前 App 是否存在能捕获、控制或覆盖它的其他运行中 App，而不是看到无障碍服务列表就直接阻断所有登录。Google 对经过增强审核的合法 Accessibility 服务提供排除语义，正说明来源与服务类型需要进入解释。
App Access Risk 不是杀毒扫描
该 verdict 描述的是运行环境中的能力信号：哪些 App 可能查看屏幕、控制输入或显示覆盖层。它不负责判断某个包是否已经实施欺诈，也不替代 Play Protect 的恶意软件判断。服务端应该验证请求细节和时效，再把环境信号与账号历史、会话、版本、支付目的和设备证据合并。
UNKNOWN_* 需要结合 Profile 与分发链
Google 明确说明，另一个 Profile 中运行的 App 可能以 UNKNOWN_ 前缀返回，即使该 App 在自己的 Profile 中来自 Play。Work Profile、企业工具、侧载和第三方商店都可能改变解释路径。因此 UNKNOWN_CAPTURING 应被记录为“存在需要调查的捕获能力”，而不是直接写成“发现木马”。
ADB 与 Wireless Debugging 要消歧
ADB 是合法的开发和测试工具。开发设备可以在授权网络中使用无线调试，生产设备也可能因用户设置或企业政策出现不同状态。Release Gate 应记录 Developer Options、Wireless Debugging、设备管理模式和构建渠道，而不是把 ADB 开启单独升级成恶意结论。
御盾保护自身候选
御盾负责 DEX/SO 保护、二次打包和重签名闭合、客户端完整性、运行时 Hook/Debug 风险与关键业务逻辑保护。它不能控制设备上另一款 App 是否被授予 Accessibility，也不能修复 Android 平台权限边界。御盾证据应和 Play Integrity、Play Protect、设备环境与服务端策略分层记录。
金融高价值动作门禁
推荐把动作分为不同风险等级，而不是所有入口共用一个开关：
| 动作 | 低风险环境 | 存在捕获 | 存在控制 | 存在覆盖层 |
|---|---|---|---|---|
| 首页浏览 | 观察 | 观察 | 观察 | 观察 |
| 普通登录 | 正常 | 二次验证 | 挑战 | 二次验证 |
| 改密/绑卡 | 二次验证 | 要求关闭风险 App 或增强认证 | 强挑战 | 强挑战 |
| 支付/转账 | 允许 | 暂停并复核 | 限制或人工复核 | 强挑战 |
| 提现/高价值权益 | 强证据 | 暂停 | 暂停 | 暂停 |
上表是工程示例，不是所有客户的通用策略。服务端还要考虑账号历史、用户是否处于 Work Profile、合法辅助服务、Play 许可、设备完整性、网络故障、误报申诉和回滚对象。任何 NOT_EVALUATED 或空 verdict 都不能被无条件解释为安全或攻击。
攻防视角：只保留防守方法
RatHat 研究不应被复刻成公开操作教程。防守方真正需要的是：缩短敏感界面的暴露时间、减少客户端保存的长期秘密、使用 App Access Risk 保护高价值动作、让 Play Integrity 和 Play Protect 结果在服务端可审计，并在候选包发布前验证完整性和回滚链。
APP 加固的价值是增加攻击者分析和篡改自己的 App 的成本，减少关键逻辑与敏感材料被直接修改的机会；它不是设备管理、无障碍权限管理或远程控制检测的万能替代。客户后端仍应保存账号、会话、业务动作和历史证据，最终决定观察、二验、挑战、临时限制、人工复核或放行。
工程落地：金融 App Sensitive Action Gate
版本与请求门
- 固定 Android、Security Patch、Play Integrity SDK 和业务版本。
- 每个请求绑定服务端 request hash 或等价的新鲜请求上下文，并在服务端检查包名、版本与时间窗。
- 记录 Play Integrity、Play Protect、设备完整性、App Access Risk 和 Profile/分发信息的来源与时间。
- Original、Yudun Basic、Yudun Target、Final Signed Release 必须使用同一业务版本逐级比较。
业务与处置门
- 登录、改密、绑卡、支付、转账、提现和权益领取分别配置策略。
CAPTURING、CONTROLLING、OVERLAYS只作为风险输入，不直接改写账号状态。- 合法 Accessibility、企业工具、Work Profile 和授权测试设备要有可解释的例外或复核路径。
- 处置结果写入服务端事件记录，并绑定回滚版本、策略版本和人工复核结果。
发布与回滚门
- 签名、包名、版本、候选摘要和分发渠道进入同一份 Release Record。
- App Access Risk 未评估、网络失败和客户端集成错误不能混写成恶意风险。
- 没有证据时保留
NOT_TESTED；出现异常时保留上一个已验收候选和可回滚动作。
服务端还应把每次决策的依据写清楚：当风险来自 UNKNOWN_CONTROLLING 时，记录 Profile、安装来源和当前业务动作；当风险来自 KNOWN_OVERLAYS 时，记录是否为系统或企业工具；当 verdict 为空时，记录是设备条件、Play 许可、库版本、请求参数还是网络导致未评估。这样安全团队才能区分真实风险、合法辅助能力与接入故障。
对于支付、提现和高价值权益，建议把风险信号绑定到一次性业务上下文，而不是长期缓存一个“设备安全”布尔值。业务动作完成、会话变化、版本变化或证据过期后，应重新请求并重新解释。任何降级都要有时间范围和回滚条件，避免临时容错长期变成绕过门槛。
最终报告应明确责任层，不把平台事实、御盾证据和客户裁决写在同一列。
没有服务端回执时，不应写成已通过。
发布前还要复核误报申诉与回滚路径。
策略变化应保留版本记录。
客户可据此复核每次放行。
证据缺失时保持保守状态。
所有结论绑定具体版本。
不使用无依据的全量兼容承诺。
审计记录保持可追溯。
版本与策略同时留档。
异常结论允许回滚。
结果必须可解释。
审计口径保持一致。
发布证据不得外推。
按候选核对。
逐项记录。
不省略状态。
留存依据。
可追溯。
可审计。
Release Gate 与测试边界
建议保存以下字段：
Android Version
Security Patch Level
App Candidate
Package / Signing
Play Integrity
App Access Risk
Play Protect
Capture / Control / Overlay
Profile / Distribution
Yudun Runtime Evidence
Account / Session
Business Action
Server Decision
Test Date
Rollback Release
本轮没有执行真实 RatHat 样本或金融业务测试。后续如获得授权，可使用无敏感 Demo 分别测试正常环境、合法录屏工具、合法 Accessibility 工具、Work Profile 和原始/基础/目标候选，并把每个格子写成 PASS、FAIL、NOT_EVALUATED 或 NOT_TESTED。不应使用“已防 RatHat”作为没有证据的宣传结论。
测评目标与非目标
本轮主目标是建立 App Access Risk、APP 加固候选与金融高价值动作之间的公开 Release Gate；非目标是执行 RatHat、复现恶意控制链、验证真实银行账户或声称御盾已阻断某个恶意样本。
| 测评目标 | 本页处理方式 | 状态 |
|---|---|---|
解释 CAPTURING、CONTROLLING、OVERLAYS |
引用 Google verdict 定义并提供矩阵 | 已完成说明 |
区分 KNOWN_* 与 UNKNOWN_* |
说明来源语义、跨 Profile 与限制 | 已完成说明 |
| 设计金融高价值动作策略 | 提供观察、二验、挑战、限制和复核示例 | NOT_TESTED |
| 比较 Original/Basic/Target/Final 候选 | 定义版本、签名、运行证据与回滚字段 | NOT_TESTED |
| 验证真实 App Access Risk 回执 | 需要授权 Demo、Play 条件和服务端配置 | NOT_TESTED |
| 复现 RatHat 或发布绕过步骤 | 不执行、不发布 | NOT_PERFORMED |
没有真实回执时，不能把方法表写成通过结果。后续每个环境、每个业务动作和每个候选都必须单独记录，避免一次普通启动成功被外推成金融交易链已通过。
风险边界
- Accessibility 开启不等于恶意，
KNOWN_*不等于安全，UNKNOWN_*不等于恶意。 - App Access Risk 不等于杀毒结果，也不证明已经发生资金盗窃。
- ADB/Wireless Debugging 是合法开发能力，状态异常需要结合设备管理和业务环境解释。
- 御盾不能修复 Android 系统漏洞、阻止另一款 App 获得系统权限或替代 Play Protect。
- 服务端不能把单一布尔值当成所有业务的放行/拒绝开关。
NOT_TESTED、NOT_EVALUATED和FAIL必须保持不同含义。
常见误区
检测到 Accessibility 就应该禁止登录吗？
不应该。Accessibility 既有合法辅助用途，也可能被滥用。应结合 App Access Risk 的捕获、控制和覆盖层信号，再按登录、改密、支付和提现等动作分层处置。
UNKNOWN_CONTROLLING 就是木马吗？
不是。它表示存在来源为 UNKNOWN 的 App，可能具备控制当前 App 输入的能力；跨 Profile、侧载和第三方分发都会影响前缀语义，需要结合账号、设备、版本和业务行为调查。
APP 加固能防止另一款 App 录屏或控制吗？
不能直接阻止。御盾保护的是自身 App 的代码、完整性和运行路径；录屏、覆盖层和控制风险要由平台信号、设备策略和服务端高价值动作门禁共同处理。
ADB 开启就是生产攻击吗？
不是。ADB 是合法开发工具。应记录设备管理状态、开发者选项、无线调试、安装来源和业务环境，避免把授权测试设备误伤。
发现风险后能否直接封禁整个账号？
不建议。Google Play Integrity 的设计支持按动作做分层响应。低风险访问可以观察，高价值操作可以要求关闭风险 App、增强认证或进入人工复核。
FAQ
Play Integrity App Access Risk 能检测什么？
它可向服务端提供其他运行中 App 可能捕获屏幕/输入、控制设备输入或显示覆盖层的风险信号，并区分部分安装来源语义。它不是完整恶意软件扫描器，也不是最终业务裁决。
合法 Accessibility 服务会被全部判为风险吗？
Google 对经过增强审核的合法 Accessibility 服务提供排除语义，但具体结果仍取决于请求、设备、应用版本和 Play 条件。企业不应自行假设所有服务都一定被排除或一定被识别。
Work Profile 为什么可能返回 UNKNOWN_？
Google 文档说明，另一个 Profile 中的 App 可能无论原始安装来源如何都使用 UNKNOWN_ 前缀。因此 Work Profile 需要单独记录 Profile、分发和业务策略。
御盾能否声明已经防住 RatHat？
没有针对该样本的授权测试和证据时，不能这样声明。可以说明御盾保护 App 自身代码、完整性和运行时路径，并协助建立 App Access Risk 与高价值动作的联合 Release Gate。
金融 App 最少应该保护哪些动作？
至少应分别评估登录、改密、绑卡、支付、转账、提现、OTP/二次认证和高价值权益领取；每个动作都应绑定账号、会话、环境证据、版本集合和服务端处置。