AOTopsy

Um analisador de snapshots AOT Dart. Transforma o libapp.so — o código Dart compilado dentro de um APK de release Flutter — em nomes de funções, layouts de classes, grafos de chamada, sinais comportamentais e pseudocódigo legível. Sem Dart VM, sem compilação do SDK, sem fallback em runtime.

Aviso de fork: AOTopsy é um fork do unflutter por Anthony Zboralski, estendido com suporte a x86_64, um decompilador nativo, inferência de tipos em todo o programa, geração de scripts Frida e documentação abrangente. Todo o crédito pelo parser de snapshot original, desserializador de clusters, pipeline de disassembly ARM64 e integração com Ghidra/IDA pertence ao autor original.

O Que Ele Recupera

Saída	O que é
Nomes de funções	O nome Dart original para cada função compilada
Estruturas de classes	Nomes de campos, offsets em bytes, cadeias de herança
Grafo de chamadas	Arestas de chamada diretas (BL) e indiretas (BLR/dispatch) com proveniência
Referências de strings	Quais funções carregam quais literais de string do object pool
Sinais comportamentais	Classificação por palavras-chave de cripto, rede, jogos de azar, SIM, localização, WebView, blockchain
Pseudocódigo	Saída descompilada neutra de arquitetura a partir de código de máquina ARM64 ou x86_64

Suporta ARM64 e x86_64. Abrange Dart 2.10 até 3.12.

Início Rápido

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

Consulte WORKFLOW.md para a metodologia passo a passo quando você tem um APK bruto e não sabe por onde começar.

Como Funciona

AOTopsy trata o snapshot AOT Dart como uma gramática binária determinística. Cada byte tem exatamente uma interpretação correta dadas as restrições certas (estrutura ELF, magic do snapshot, hash de versão, tabela CID, codificação de clusters). O parser aplica restrições até que apenas uma interpretação sobreviva — sem heurísticas, sem adivinhação.

O pipeline é executado em etapas, cada uma uma função pura de bytes para dados estruturados:

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]

Dois backends independentes compartilham a mesma metade frontal (ELF até o preenchimento de clusters) e depois se dividem por arquitetura: internal/disasm para ARM64, internal/disasm/x86.go para x86_64. O decompilador (internal/decompiler) lida com ambas as arquiteturas por meio de um IR unificado.

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

Comparação com o 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 a Dart VM para desserializar o snapshot por meio de seus próprios caminhos de código. Fidelidade perfeita, mas exige compilar um Dart SDK correspondente para cada versão alvo.

AOTopsy analisa o formato binário diretamente. Sem VM, sem SDK. O trade-off: cada mudança de formato entre versões do Dart precisa ser modelada explicitamente. Não há runtime para lidar com isso automaticamente.

Comandos

Pipeline completo

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

Flags: --out <dir> (padrão: <basename>.aotopsy/), --quiet, --strict, --max-steps <n>, --k <n> (profundidade do contexto de sinal, padrão 2).

Diagnóstico

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

Decompilador (ARM64 + x86_64, sem necessidade de 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

Aviso: --all sem um --max pequeno pode exigir ~64 GB de RAM em um aplicativo real. Prefira --find/--func/--from-main.

Ghidra / IDA (somente ARM64)

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

Ambos rejeitam entrada x86_64. Use decompile-native para pseudocódigo x86_64.

Geração de scripts 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

Consulte FRIDA.md para o guia completo.

Referências cruzadas e rastreamento

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

Ferramentas de 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

Artefatos de Saída

Estrutura de Pacotes

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)

Consulte ARCHITECTURE.md para o mergulho profundo em cada pacote.

Compilação

Requer Go 1.25+.

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

Os testes de integração usam variáveis de ambiente (AOTOPSY_TEST_SAMPLE_*) para localizar binários de exemplo — eles são ignorados automaticamente se não estiverem definidas.

Limitações

Somente AOT. Sem suporte a JIT.
A descompilação Ghidra/IDA é somente ARM64. x86_64 é rejeitado com um erro claro — use decompile-native em vez disso.
A descompilação --all pode travar o host. Um aplicativo real de tamanho completo precisa de ~64 GB de RAM para --all sem limite. Use modos direcionados (--find, --func, --from-main) ou limite com --max.
O dispatch virtual é invisível para o alcance de --from-main. Callbacks de ciclo de vida de widgets passam pelo dispatch do framework Flutter, não por instruções de chamada diretas. Uma heurística de contato com classes recupera alguns, mas é uma superaproximação. Use Frida para o restante.
Cada mudança de versão do Dart precisa ser modelada. Não há VM para lidar com mudanças de formato automaticamente.

Licença

BSD-3-Clause. Tabelas CID, offsets de campos THR e nomes de stubs são derivados do Dart SDK (também BSD-3-Clause). Consulte LICENSE e NOTICE.

`functions.jsonl`	Nome, endereço, tamanho, dono, contagem de parâmetros por função
`call_edges.jsonl`	Arestas BL/BLR com alvos resolvidos e proveniência
`classes.jsonl`	Nomes de campos, offsets, tamanhos de instância por classe
`string_refs.jsonl`	Referências de strings a partir de loads do object pool
`signal.html`	Relatório de sinais comportamentais com grafo de contexto
`flutter_meta.json`	Metadados unificados para Ghidra/IDA (somente ARM64)
`asm/*.txt`	Disassembly anotado por função
`cfg/*.dot`	CFGs por função (com `--graph`)

aotopsy

Mais Populares