competition-android-hooking
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCompetition Android Hooking
竞赛场景安卓Hook
Use this skill only as a downstream specialization after is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to first.
$ctf-sandbox-orchestrator$ctf-sandbox-orchestratorUse this skill when the decisive path runs through an Android app's live trust boundary rather than static strings alone.
Reply in Simplified Chinese unless the user explicitly requests English.
仅当已激活,且已完成沙箱环境假设、节点归属确认和证据优先级划分后,才可作为下游专项技能使用。如果尚未完成上述步骤,请先返回执行前置流程。
$ctf-sandbox-orchestrator$ctf-sandbox-orchestrator当问题的核心解决路径需要分析Android应用的运行态信任边界,而非仅依赖静态字符串时使用本技能。
除非用户明确要求使用英文回复,否则请使用简体中文回复。
Quick Start
快速入门
- Preserve the original APK, extracted resources, and decompiled output before patching or resigning.
- Start with manifest, exported components, deeplinks, native libs, prefs, local DBs, and bundled configs.
- Decide the narrowest runtime boundary to hook: signer, crypto helper, JNI bridge, WebView bridge, or request builder.
- Correlate static evidence and dynamic traces before claiming a trust edge is understood.
- Reproduce the signed request, accepted token, or gated branch from the smallest hook set.
- 在打补丁或重签名前,保留原始APK、提取出的资源文件和反编译输出。
- 优先分析清单文件、导出组件、deeplink、原生库、prefs、本地数据库和内置配置。
- 确定需要Hook的最小运行时边界:签名模块、加密辅助模块、JNI桥接层、WebView桥接层或请求构造模块。
- 在声明已理解某信任边界前,需关联静态证据和动态追踪结果交叉验证。
- 使用最少的Hook集合复现签名请求、合法token或受限制的分支逻辑。
Workflow
工作流
1. Static Triage Before Hooks
1. Hook前的静态分析
- Map package structure, exported activities, services, receivers, providers, and deeplink handlers.
- Note SSL pinning logic, root checks, feature flags, token storage, shared prefs, SQLite tables, and protobuf or RPC boundaries.
- Identify whether the sensitive logic sits in Java, Kotlin, JNI, or a bundled WebView.
- 梳理包结构、导出的Activity、Service、Receiver、Provider和deeplink处理逻辑。
- 标记SSL pinning逻辑、root检测、功能开关、token存储位置、Shared Preferences、SQLite表、protobuf或RPC边界。
- 识别敏感逻辑所处的层:Java、Kotlin、JNI还是内置WebView。
2. Hook The Narrowest Boundary
2. 对最小边界进行Hook
- Prefer hooking request signers, crypto helpers, keystore access, protobuf encode or decode, or JNI marshaling instead of broad UI hooks.
- Record plaintext inputs, signed strings, headers, nonces, and outputs at the boundary that actually changes trust.
- If pinning or environment checks block progress, patch or hook only enough to expose the real request path.
- 优先Hook请求签名模块、加密辅助模块、Keystore访问逻辑、protobuf编解码或JNI序列化逻辑,而非大范围的UI Hook。
- 记录实际影响信任判定的边界处的明文输入、签名字符串、请求头、nonce和输出结果。
- 如果pinning或环境检测阻断了分析进程,仅打补丁或Hook足够暴露真实请求路径的逻辑即可。
3. Replay The Accepted Path
3. 重放合法请求路径
- Rebuild the smallest sequence that reaches the accepted server-side branch: local state, nonce, request body, signature, and headers.
- Keep hook logs, captured request shapes, and local storage paths tied to the same account or session state.
- If the challenge becomes more about transform recovery than Android runtime, switch back to the broader crypto or mobile skill.
- 重构能触发服务端合法分支的最小请求序列:本地状态、nonce、请求体、签名和请求头。
- 关联同一账号或会话状态下的Hook日志、捕获的请求结构和本地存储路径。
- 如果挑战的核心变为转换逻辑恢复而非Android运行态分析,切换回更通用的加密或移动端技能。
Read This Reference
参考资料
- Load for hook targets, storage checklist, and evidence packaging.
references/android-hooking.md
- 加载查看Hook目标、存储检查清单和证据打包规范。
references/android-hooking.md
What To Preserve
需要保存的内容
- Hook points, class names, JNI symbols, signer inputs and outputs, and header names
- Shared prefs, local DB rows, deeplinks, exported components, and token storage paths
- The smallest replayable request or branch that proves the trust boundary
- Hook点、类名、JNI符号、签名模块的输入输出和请求头名称
- Shared Preferences、本地数据库行、deeplink、导出组件和token存储路径
- 可证明信任边界的最小可重放请求或分支逻辑