[GH-ISSUE #4194] [Scope] SSL unpinning support for Android TLS analysis (HTTP Toolkit/Frida composition) #1645

New issue

Open

opened 2026-10-16 21:08:23 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:08:23 +00:00

Owner

Originally created by @3QL on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4194

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Which level of SSL-unpinning support, if any, is acceptable in REA: docs-only composition of existing lanes, an assisted caller-authorized workflow, or built-in unpinning support?

Context and evidence

(There will be a pull request for HTTP Toolkit when this scope is reviewed)
Observed: REA inspects offline HTTP Toolkit HAR exports (HAR 1.2, incl. retained log._tlsErrors such as cert-rejected) and has separate ADB acquisition and general-purpose Frida instrumentation lanes (caller-authored scripts only).

Source-derived: the exporter's HAR profile was read from its published source (httptoolkit-ui src/model/http/har.ts); cause literals (cert-rejected, etc.) come from mockttp's TlsHandshakeFailure. No live export has been run through REA.

Proposed: a recorded path from a pinned, caller-owned app to an inspectable capture. Unknowns: whether any automation beyond docs fits REA's bypass exclusion; what target-ownership proof or per-run authorization would be required.

Expected interaction with targets

Read existing files or captured data, Launch or attach to a process, Inject instrumentation or run scripts/code, Not sure yet

Boundary details (optional)

Targets: caller-owned debug builds or explicitly authorized test apps only. Non-goals: third-party apps, DRM/license/anti-cheat bypass, credential theft, persistence, bulk workflows. No silent expansion of the Frida lane's existing mutation authority; options involving trust manipulation stay unimplemented until the decision covers them.

Options and tradeoffs

Docs-only composition (no new capability): ADB select/acquire + Frida lane with caller-authored script + separate HTTP Toolkit capture + HAR export + REA inspection. Cheapest, likely needs no decision beyond confirmation.
Assisted workflow: REA orchestrates caller-selected, explicitly authorized steps with per-step Evidence. More repeatable, but new orchestration authority to review.
Built-in unpinning: REA ships or automates pinning bypass. Most capable, most likely excluded — included so it can be declined explicitly.

Verification available so far

I have a prototype or observed results

Success criteria and open questions

Success: a recorded decision on options 1–3 with any conditions (ownership proof, authorization, device scoping). Open: does option 1 need any decision at all? What verification (self-owned fixtures, real-provider lane) would options 2–3 require?

References

REA Frida lane: docs/frida-instrumentation.md
REA ADB lane: docs/adb-device-analysis.md
REA capture support: docs/web-network-captures.md
REA scope: CONTRIBUTING.md (Contribution scope, Fail-closed integration)
HTTP Toolkit Android interception: https://httptoolkit.com/docs/guides/android/
HTTP Toolkit HAR export: https://httptoolkit.com/docs/reference/view-page
Exporter HAR source: https://github.com/httptoolkit/httptoolkit-ui/blob/main/src/model/http/har.ts

Originally created by @3QL on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4194 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Which level of SSL-unpinning support, if any, is acceptable in REA: docs-only composition of existing lanes, an assisted caller-authorized workflow, or built-in unpinning support? ### Context and evidence (There will be a pull request for HTTP Toolkit when this scope is reviewed) Observed: REA inspects offline HTTP Toolkit HAR exports (HAR 1.2, incl. retained log._tlsErrors such as cert-rejected) and has separate ADB acquisition and general-purpose Frida instrumentation lanes (caller-authored scripts only). Source-derived: the exporter's HAR profile was read from its published source (httptoolkit-ui src/model/http/har.ts); cause literals (cert-rejected, etc.) come from mockttp's TlsHandshakeFailure. No live export has been run through REA. Proposed: a recorded path from a pinned, caller-owned app to an inspectable capture. Unknowns: whether any automation beyond docs fits REA's bypass exclusion; what target-ownership proof or per-run authorization would be required. ### Expected interaction with targets Read existing files or captured data, Launch or attach to a process, Inject instrumentation or run scripts/code, Not sure yet ### Boundary details (optional) Targets: caller-owned debug builds or explicitly authorized test apps only. Non-goals: third-party apps, DRM/license/anti-cheat bypass, credential theft, persistence, bulk workflows. No silent expansion of the Frida lane's existing mutation authority; options involving trust manipulation stay unimplemented until the decision covers them. ### Options and tradeoffs 1. Docs-only composition (no new capability): ADB select/acquire + Frida lane with caller-authored script + separate HTTP Toolkit capture + HAR export + REA inspection. Cheapest, likely needs no decision beyond confirmation. 2. Assisted workflow: REA orchestrates caller-selected, explicitly authorized steps with per-step Evidence. More repeatable, but new orchestration authority to review. 3. Built-in unpinning: REA ships or automates pinning bypass. Most capable, most likely excluded — included so it can be declined explicitly. ### Verification available so far I have a prototype or observed results ### Success criteria and open questions Success: a recorded decision on options 1–3 with any conditions (ownership proof, authorization, device scoping). Open: does option 1 need any decision at all? What verification (self-owned fixtures, real-provider lane) would options 2–3 require? ### References - REA Frida lane: docs/frida-instrumentation.md - REA ADB lane: docs/adb-device-analysis.md - REA capture support: docs/web-network-captures.md - REA scope: CONTRIBUTING.md (Contribution scope, Fail-closed integration) - HTTP Toolkit Android interception: https://httptoolkit.com/docs/guides/android/ - HTTP Toolkit HAR export: https://httptoolkit.com/docs/reference/view-page - Exporter HAR source: https://github.com/httptoolkit/httptoolkit-ui/blob/main/src/model/http/har.ts

bsakaguchi added the

triage

enhancement

labels

2026-10-16 21:08:23 +00:00

bsakaguchi referenced this issue

2026-10-17 21:01:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi added

enhancement

and removed

enhancement