competition-android-hooking

竞赛 Android Hooking

仅在 $ctf-sandbox-orchestrator 已处于活动状态，并已建立沙箱假设、节点归属和证据优先级之后，才将此技能作为下游专项使用。如果尚未发生，请先回到 $ctf-sandbox-orchestrator。

当决定性路径依赖 Android 应用的实时信任边界，而不仅仅是静态字符串时，请使用此技能。

除非用户明确要求英文，否则请用简体中文回复。

快速开始

1. 在修补或重新签名之前，保留原始 APK、提取的资源和反编译输出。
2. 从 manifest、导出组件、deeplink、原生库、prefs、本地 DB 和捆绑配置开始。
3. 决定要 hook 的最窄运行时边界：签名器、加密辅助程序、JNI 桥、WebView 桥或请求构建器。
4. 在声称理解某个信任边界之前，将静态证据和动态跟踪关联起来。
5. 用最小的 hook 集复现已签名请求、被接受的令牌或受控分支。

工作流

1. Hook 前的静态分诊

• 梳理包结构、导出的 activity、service、receiver、provider 和 deeplink 处理器。
• 记录 SSL pinning 逻辑、root 检查、功能开关、令牌存储、shared prefs、SQLite 表以及 protobuf 或 RPC 边界。
• 确定敏感逻辑位于 Java、Kotlin、JNI 还是捆绑的 WebView 中。

2. Hook 最窄的边界

• 优先 hook 请求签名器、加密辅助程序、keystore 访问、protobuf 编码或解码，或 JNI 编组，而不是宽泛的 UI hook。
• 在真正改变信任的边界处记录明文输入、已签名字符串、header、nonce 和输出。
• 如果 pinning 或环境检查阻碍进展，只做最小程度的修补或 hook，以暴露真实请求路径。

3. 重放被接受的路径

• 重建到达服务端被接受分支的最小序列：本地状态、nonce、请求主体、签名和 header。
• 让 hook 日志、捕获的请求形态和本地存储路径与同一账号或会话状态绑定。
• 如果挑战变得更侧重变换恢复而不是 Android 运行时，请切回更广泛的加密或移动技能。

阅读此参考

• 加载 references/android-hooking.md 以了解 hook 目标、存储检查清单和证据打包。

需要保留的内容

• Hook 点、类名、JNI 符号、签名器输入和输出以及 header 名称
• Shared prefs、本地 DB 行、deeplink、导出组件和令牌存储路径
• 证明信任边界的最小可重放请求或分支