用途：该技能是 ctf-sandbox-orchestrator 的下游专项能力，仅当该编排器已激活、并已确定沙箱假设、节点归属与证据优先级后才可使用；否则应先回到 ctf-sandbox-orchestrator。适用于关键路径必须依赖 Android 应用运行时信任边界、而非仅静态字符串的场景。
主要能力与用法：先保留原始 APK、解包资源与反编译产物，再进行补丁或重签名；从清单、导出组件、deeplink、原生库、prefs、本地数据库与内置配置入手。选择最窄的运行时边界进行 hook，如签名器、加密辅助、JNI 桥、WebView 桥或请求构造器。将静态证据与动态跟踪相互印证，再判断信任边界；用最小 hook 集合复现被接受的签名请求、令牌或受限分支。若遇 SSL pinning 或环境检查阻碍，只做暴露真实请求路径所需的最小 patch 或 hook。
工作流程：一、静态初筛，梳理包结构、导出活动/服务/接收器/提供者与 deeplink 处理器，标注 pinning、root 检查、特性开关、令牌存储、SQLite 表及 protobuf/RPC 边界，判断敏感逻辑位于 Java、Kotlin、JNI 还是 WebView。二、hook 最窄边界，记录明文输入、签名字符串、头部、nonce 与输出。三、复现被接受的路径，重建本地状态、nonce、请求体、签名与头部的最小序列，并保持日志、请求形状与存储路径对应同一账号或会话。若题目转向变换还原而非 Android 运行时，应切回更合适的密码学或移动技能。
需保留：hook 点、类名、JNI 符号、签名器输入输出与头部名；shared prefs、本地库行、deeplink、导出组件与令牌存储路径；可证明信任边界的最小可复现请求或分支。详细 hook 目标、存储清单与证据打包参见 references/android-hooking.md。除用户明确要求英文外，应使用简体中文回复。