AOTopsy

Un analizzatore di snapshot AOT Dart. Trasforma libapp.so — il codice Dart compilato all'interno di un APK Flutter release — in nomi di funzioni, layout delle classi, grafi delle chiamate, segnali comportamentali e pseudocodice leggibile. Nessuna Dart VM, nessuna compilazione SDK, nessun fallback runtime.

Nota sul fork: AOTopsy è un fork di unflutter di Anthony Zboralski, esteso con supporto x86_64, un decompilatore nativo, inferenza di tipi sull'intero programma, generazione di script Frida e documentazione completa. Ogni credito per il parser originale degli snapshot, il deserializzatore dei cluster, la pipeline di disassemblaggio ARM64 e l'integrazione con Ghidra/IDA va all'autore originale.

Cosa Recupera

Output	Cos'è
Nomi delle funzioni	Il nome Dart originale per ogni funzione compilata
Strutture delle classi	Nomi dei campi, offset in byte, catene di ereditarietà
Grafo delle chiamate	Archi di chiamata diretti (BL) e indiretti (BLR/dispatch) con provenienza
Riferimenti alle stringhe	Quali funzioni caricano quali stringhe letterali dal pool di oggetti
Segnali comportamentali	Classificazione per parole chiave: crypto, rete, gioco d'azzardo, SIM, posizione, WebView, blockchain
Pseudocodice	Output decompilato indipendente dall'architettura dal codice macchina ARM64 o x86_64

Supporta ARM64 e x86_64. Copre Dart 2.10 fino alla 3.12.

Avvio Rapido

make build
./aotopsy libapp.so                    # full pipeline
./aotopsy doctor libapp.so             # quick diagnostic
./aotopsy _debug decompile-native --lib libapp.so --find MyClass  # find a function

Vedi WORKFLOW.md per la metodologia passo-passo quando hai un APK grezzo e non sai da dove iniziare.

Come Funziona

AOTopsy tratta lo snapshot AOT di Dart come una grammatica binaria deterministica. Ogni byte ha esattamente un'interpretazione corretta date le giuste condizioni (struttura ELF, magic dello snapshot, hash di versione, tabella CID, codifica dei cluster). Il parser applica vincoli finché non sopravvive una sola interpretazione — nessuna euristica, nessuna supposizione.

La pipeline procede per fasi, ciascuna una funzione pura da byte a dati strutturati:

flowchart TD
    A[libapp.so] --> B[ELF parse]
    B --> C[snapshot region extraction]
    C --> D[version detection]
    D --> E[cluster alloc<br/>object census]
    E --> F[cluster fill<br/>field values, names, strings]
    F --> G[instructions table<br/>code ranges, stub boundaries]
    G --> H{architecture?}
    H -->|ARM64| I[ARM64 disassembly]
    H -->|x86_64| J[x86_64 disassembly]
    I --> K[CFG + call edges<br/>register provenance]
    J --> K
    K --> L[type inference<br/>BLR receiver type resolution]
    L --> M[signal classification<br/>behavioral keyword matching]
    M --> N[JSONL + HTML + DOT<br/>pseudocode output]

Due backend indipendenti condividono la stessa prima metà (da ELF a cluster fill), poi si dividono in base all'architettura: internal/disasm per ARM64, internal/disasm/x86.go per x86_64. Il decompilatore (internal/decompiler) gestisce entrambe le architetture tramite un IR unificato.

flowchart LR
    subgraph "Shared front half"
        A[elfx] --> B[snapshot]
        B --> C[cluster]
    end
    subgraph "ARM64 backend"
        C --> D1[disasm ARM64]
        D1 --> E1[callgraph]
        E1 --> F1[signal]
    end
    subgraph "x86_64 backend"
        C --> D2[disasm x86_64]
        D2 --> E2[callgraph]
        E2 --> F2[signal]
    end
    subgraph "Decompiler (both archs)"
        C --> G[decompiler IR]
        G --> H[pseudocode]
    end

Confronto con Blutter

flowchart LR
    subgraph Blutter
        direction TB
        B1[libapp.so] --> B2[Compile matching<br/>Dart SDK]
        B2 --> B3[Embed Dart VM]
        B3 --> B4[Deserialize via<br/>VM internal APIs]
        B4 --> B5[Perfect fidelity]
    end
    subgraph AOTopsy
        direction TB
        A1[libapp.so] --> A2[Parse binary format<br/>directly]
        A2 --> A3[No VM, no SDK]
        A3 --> A4[Version-specific<br/>format modeling]
        A4 --> A5[Portability + speed]
    end

Blutter incorpora la Dart VM per deserializzare lo snapshot attraverso i propri percorsi di codice. Fedeltà perfetta, ma richiede la compilazione di un Dart SDK corrispondente per ogni versione target.

AOTopsy analizza direttamente il formato binario. Nessuna VM, nessun SDK. Il compromesso: ogni modifica al formato tra le versioni di Dart deve essere modellata esplicitamente. Non c'è alcun runtime che lo gestisca automaticamente.

Comandi

Pipeline completa

aotopsy libapp.so              # disasm + call edges + signal + metadata (ARM64: + Ghidra/IDA)
aotopsy signal libapp.so       # same, skip metadata
aotopsy libapp.so --graph      # also build call graph DOT files

Flag: --out <dir> (default: <basename>.aotopsy/), --quiet, --strict, --max-steps <n>, --k <n> (profondità del contesto dei segnali, default 2).

Diagnostica

aotopsy doctor libapp.so       # Dart version, pointer size, support status, build features
aotopsy find-libapp --apk app.apk  # locate libapp.so inside an APK

Decompilatore (ARM64 + x86_64, senza bisogno di Ghidra/IDA)

aotopsy _debug decompile-native --lib libapp.so --find MyClass         # locate by name
aotopsy _debug decompile-native --lib libapp.so --func 0x1a92728       # one function at a VA
aotopsy _debug decompile-native --lib libapp.so --from-main --out out/ # reachability from app entry
aotopsy _debug decompile-native --lib libapp.so --all --filter MyClass # bulk, filtered

Attenzione: --all senza un --max ridotto può richiedere ~64GB di RAM su un'app reale. Preferisci --find/--func/--from-main.

Ghidra / IDA (solo ARM64)

aotopsy ghidra libapp.so        # headless Ghidra with metadata injection
aotopsy ida libapp.so           # headless IDA via idalib

Entrambi rifiutano input x86_64. Usa decompile-native per lo pseudocodice x86_64.

Generazione di script Frida

aotopsy _debug decompile-native --lib libapp.so --func 0x1a92728 --gen-frida --gen-frida-out hooks.js
frida -U -f com.example.app -l hooks.js --no-pause

Vedi FRIDA.md per la guida completa.

Riferimenti incrociati e tracciamento

aotopsy _debug strings --lib libapp.so --find "X-Signature" --xref   # which function loads this string?
aotopsy _debug ffi-trace --lib libapp.so --filter MyClass            # dart:ffi call sites
aotopsy _debug dispatch-table --lib libapp.so --filter MyClass       # dispatch table entries
aotopsy _debug fingerprint --lib libapp.so                           # build-id and version markers
aotopsy _debug funcdiff --old old.so --new new.so                    # function set diff
aotopsy _debug symbolmap --stripped lib.so --unstripped debug.so     # resolve stripped targets

Strumenti per corpus

aotopsy inventory --dir samples/                    # catalog APKs
aotopsy parity --samples samples/ --out out/        # cross-version parse report
aotopsy _debug thr-audit -lib libapp.so -out thr.jsonl  # THR access scan

Artefatti di Output

Struttura dei Pacchetti

cmd/aotopsy/          CLI entry point and command handlers
internal/
  elfx/               ELF validation and symbol extraction
  snapshot/           Snapshot region extraction, version profiles
  dartfmt/            Dart VM variable-length integer encoding
  cluster/            Two-phase snapshot deserialization (alloc + fill)
  disasm/             ARM64 + x86_64 decode, CFG, call-edge provenance
  callgraph/          Lattice graph builders for DOT rendering
  signal/             Behavioral string classification
  render/             HTML/DOT/SVG visualization
  output/             JSONL serialization
  decompiler/         Dart-AOT pseudocode decompiler (both architectures)
  typetrack/          Whole-program type inference for BLR resolution
  fingerprint/        Build-id and version marker identification
  funcdiff/           Function-set diffing between builds
  symbolmap/          Stripped-vs-unstripped symbol resolution
  ffitrace/           Static dart:ffi call-site tracing
  strxref/            String-to-function cross-referencing
  strutil/            Shared string utilities
  pipeline/           Pipeline orchestration and name resolution
tools/                Standalone utilities (THR table extractor)
ghidra_scripts/       Ghidra integration (Python)
ida_scripts/          IDA integration (Python)

Vedi ARCHITECTURE.md per l'analisi approfondita di ogni pacchetto.

Build

Richiede Go 1.25+.

make build      # build ./aotopsy
make install    # install to ~/.aotopsy/bin
make test       # run tests

I test di integrazione usano variabili d'ambiente (AOTOPSY_TEST_SAMPLE_*) per individuare i binari di esempio — vengono saltati automaticamente se non impostate.

Limitazioni

Solo AOT. Nessun supporto JIT.
La decompilazione Ghidra/IDA è solo ARM64. x86_64 viene rifiutato con un errore chiaro — usa decompile-native.
La decompilazione --all può mandare in crash l'host. Un'app reale a dimensione piena richiede ~64GB di RAM per un --all senza limiti. Usa le modalità mirate (--find, --func, --from-main) oppure limita con --max.
La dispatch virtuale è invisibile al raggiungimento di --from-main. I callback del ciclo di vita dei widget passano attraverso la dispatch del framework Flutter, non istruzioni di chiamata dirette. Un'euristica di "class-touch" ne recupera alcuni, ma è una sovra-approssimazione. Usa Frida per il resto.
Ogni cambiamento di versione di Dart deve essere modellato. Non c'è una VM che gestisca automaticamente i cambiamenti di formato.

Licenza

BSD-3-Clause. Le tabelle CID, gli offset dei campi THR e i nomi degli stub derivano dal Dart SDK (anch'esso BSD-3-Clause). Vedi LICENSE e NOTICE.

`functions.jsonl`	Nome, indirizzo, dimensione, proprietario, numero di parametri per funzione
`call_edges.jsonl`	Archi BL/BLR con target risolti e provenienza
`classes.jsonl`	Nomi dei campi, offset, dimensioni delle istanze per classe
`string_refs.jsonl`	Riferimenti alle stringhe dai caricamenti dal pool di oggetti
`signal.html`	Report dei segnali comportamentali con grafo di contesto
`flutter_meta.json`	Metadati unificati per Ghidra/IDA (solo ARM64)
`asm/*.txt`	Disassemblaggio annotato per funzione
`cfg/*.dot`	CFG per funzione (con `--graph`)

aotopsy

Più Popolari