[GH-ISSUE #2809] Proposal: bring-your-own Dart/Flutter AOT reconstruction provider (Blutter) — scope check before implementation #1002

New issue

Open

opened 2026-10-15 18:30:15 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:30:15 +00:00

Owner

Originally created by @scadastrangelove on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2809

Context

REA already identifies and fingerprints Flutter AOT snapshots — src/flutter/FlutterPayloadScan.ts finds the Dart snapshot magic + version hash, and src/flutter/DartElf.ts parses libapp.so and the _kDartVmSnapshot* symbols. That answers "is this Flutter, which engine build?".

It does not appear to reconstruct the Dart program semantics from the AOT snapshot — the class hierarchy, method bodies/dispatch, and the string/object pool. That reconstruction is usually what an analyst wants from a Flutter target, and the generic native decompilers REA already wraps don't cover it well, because the Dart calling convention, object model, and pool layout are snapshot-version-specific.

Proposal

Add a bring-your-own Dart-AOT reconstruction provider — the same shape as the existing Ghidra/IDA/Hopper/JADX providers — wrapping Blutter (MIT, C++, a Flutter-specific tool that rebuilds Dart classes/methods/strings from libapp.so + the matching engine). It would:

reuse the existing FlutterPayloadScan/DartElf output to select the target and engine version;
invoke a user-supplied Blutter install (bring-your-own, like IDA/Hopper — REA would only locate/validate it, never download or build it), read-only and bounded;
surface the reconstructed classes/functions/strings as REA Evidence, preserving the observations/derivations/inferences/unknowns + limitations framing rather than raw tool output.

Open questions (I'd like your scope decision before writing substantial code)

In scope at all, or is Flutter deliberately detect-only today?
Bring-your-own vs managed — I'm assuming strictly BYO (REA locates/validates, never installs/builds), consistent with "installers must not install unrelated software". Right?
Version coupling / build — Blutter reconstructs by building against the matching Dart SDK version's source (per engine hash), a heavy per-target build dependency. How would you want that modeled — a precondition REA checks and reports as a limitation, a cache, or out of scope?
Output → Evidence mapping — what level of abstraction fits REA's evidence model best (symbol table + pseudocode? class graph? strings only?) to preserve provenance and omission/uncertainty like your other providers?
Security posture — the provider only reads the target and runs the user's local Blutter (same trust posture as your other engines; it does not execute the target). Anything extra you'd require?

Happy to follow up with a small exploratory draft PR purely to resolve (3) and (4), with the explicit understanding (per AGENTS.md) that a draft does not authorize integration. Blutter is MIT, so integration would be BYO invocation, not vendoring; I'd add the appropriate THIRD_PARTY_NOTICES entry if you accept a prototype.

Originally created by @scadastrangelove on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2809 ## Context REA already **identifies and fingerprints** Flutter AOT snapshots — `src/flutter/FlutterPayloadScan.ts` finds the Dart snapshot magic + version hash, and `src/flutter/DartElf.ts` parses `libapp.so` and the `_kDartVmSnapshot*` symbols. That answers "is this Flutter, which engine build?". It does not appear to **reconstruct the Dart program semantics** from the AOT snapshot — the class hierarchy, method bodies/dispatch, and the string/object pool. That reconstruction is usually what an analyst wants from a Flutter target, and the generic native decompilers REA already wraps don't cover it well, because the Dart calling convention, object model, and pool layout are snapshot-version-specific. ## Proposal Add a **bring-your-own Dart-AOT reconstruction provider** — the same shape as the existing Ghidra/IDA/Hopper/JADX providers — wrapping **[Blutter](https://github.com/worawit/blutter)** (MIT, C++, a Flutter-specific tool that rebuilds Dart classes/methods/strings from `libapp.so` + the matching engine). It would: - reuse the existing `FlutterPayloadScan`/`DartElf` output to select the target and engine version; - invoke a **user-supplied** Blutter install (bring-your-own, like IDA/Hopper — REA would only locate/validate it, never download or build it), read-only and bounded; - surface the reconstructed classes/functions/strings as REA **Evidence**, preserving the observations/derivations/inferences/unknowns + limitations framing rather than raw tool output. ## Open questions (I'd like your scope decision before writing substantial code) 1. **In scope at all**, or is Flutter deliberately detect-only today? 2. **Bring-your-own vs managed** — I'm assuming strictly BYO (REA locates/validates, never installs/builds), consistent with "installers must not install unrelated software". Right? 3. **Version coupling / build** — Blutter reconstructs by building against the matching Dart SDK version's source (per engine hash), a heavy per-target build dependency. How would you want that modeled — a precondition REA checks and reports as a `limitation`, a cache, or out of scope? 4. **Output → Evidence mapping** — what level of abstraction fits REA's evidence model best (symbol table + pseudocode? class graph? strings only?) to preserve provenance and omission/uncertainty like your other providers? 5. **Security posture** — the provider only reads the target and runs the user's local Blutter (same trust posture as your other engines; it does not execute the target). Anything extra you'd require? Happy to follow up with a small exploratory draft PR purely to resolve (3) and (4), with the explicit understanding (per AGENTS.md) that a draft does not authorize integration. Blutter is MIT, so integration would be BYO invocation, not vendoring; I'd add the appropriate `THIRD_PARTY_NOTICES` entry if you accept a prototype.

bsakaguchi added the

labels

2026-10-15 18:30:15 +00:00

bsakaguchi referenced this issue

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

[PR #988] [MERGED] refactor(process): separate capture implementation from analyst workflows #2557

bsakaguchi referenced this issue

2026-10-17 21:07:44 +00:00