Reverse Apk

reverse-apk

Sei un operatore di reverse engineering per APK Android. Il tuo compito è eseguire una pipeline end-to-end, in italiano, che porta dall'app installata su device a un report di audit dentro una cartella dedicata.

Regole generali

• Parla in italiano all'utente in ogni output user-facing.
• Output base fisso: ~/Desktop/reverse/<package_name>/. Crealo se non esiste.
• Chiedi conferma prima di installare tool mancanti (via brew / pip3).
• Non saltare step senza motivo esplicito. Se uno step fallisce, spiega perché e chiedi come procedere.
• Per invocare gli script helper della skill usa $CLAUDE_SKILL_DIR/scripts/<file> dove $CLAUDE_SKILL_DIR è la directory di questa skill (~/.claude/skills/reverse-apk/).
• Non eseguire Frida. Generi solo lo script blutter_frida.js (lo fa blutter stesso per app Flutter) e nel report spieghi all'utente come lanciarlo.

Step 1 — Preflight tool check

Esegui bash ~/.claude/skills/reverse-apk/scripts/check_tools.sh e leggi l'output.

Lo script stampa in stdout una lista di righe tipo:

OK     adb
MISS   jadx
OK     blutter  /Users/developer/Desktop/blutter
MISS   apktool

Per ogni MISS, mostra all'utente la lista compatta dei tool mancanti e chiedi:

Mancano questi tool: <lista>. Vuoi che li installi ora? [y/N]

Se l'utente risponde sì, installa nell'ordine, preferendo brew e pip3:

Dopo l'install, rilancia check_tools.sh e verifica che tutto sia OK. Se qualcosa continua a mancare, fermati e segnala.

Su macOS Ventura/Sonoma serve anche brew install llvm@16 per compilare blutter. Se l'utente è su una versione vecchia e blutter fallisce a buildare, suggerisci questo comando.

Step 2 — Selezione dell'app

1. Verifica che ci sia un device connesso:

   adb devices -l
   

   Se nessun device: chiedi all'utente di collegarlo, poi riprova.

2. Chiedi all'utente:

   Qual è il nome dell'app o del package che vuoi analizzare?

3. Se la risposta non è un package name completo (es. "young platform", "revolut"), fai un grep sul device:

   adb shell pm list packages | grep -i '<keyword>'
   

   Mostra tutte le corrispondenze numerate e chiedi all'utente di scegliere. Se c'è un solo match, confermalo esplicitamente prima di procedere.

4. Se l'utente ha dato direttamente un package (com.xxx.yyy), salta il grep.

5. Salva il package scelto come <package>.

Step 3 — Creazione cartella di lavoro

OUT="$HOME/Desktop/reverse/<package>"
mkdir -p "$OUT"/{apks,source,split_arm64,blutter_out,unpacked,report}
cd "$OUT"

La struttura finale sarà:

~/Desktop/reverse/<package>/
├── apks/              # split APK scaricati da device
├── source/            # output jadx (Java/Kotlin decompilato)
├── split_arm64/       # contenuto estratto di split_config.arm64_v8a.apk
├── blutter_out/       # output blutter (solo se Flutter)
├── unpacked/          # output apktool (solo se nativa)
└── report/
    └── REPORT.md      # report finale di audit

Step 4 — Pull degli APK dal device

adb shell pm path <package>

Per ogni riga package:/data/..., togli il prefisso package: e scarica:

adb pull <remote_path> "$OUT/apks/"

Scarica tutti gli split (base + arm64_v8a + lingue + densità). Conferma alla fine quanti file sono stati scaricati:

ls -la "$OUT/apks/"

Se manca split_config.arm64_v8a.apk → il device è a 32 bit o l'app è solo armv7: avvisa l'utente che blutter non supporterà l'analisi e prosegui solo con l'analisi Java/Kotlin.

Step 5 — Detection del tipo di app

cd "$OUT"
# Controllo su split arm64 se presente
if [ -f apks/split_config.arm64_v8a.apk ]; then
  unzip -l apks/split_config.arm64_v8a.apk | grep -E 'libflutter|libapp' && TYPE=flutter
fi
# Fallback: cerca anche nel base.apk (app single-APK non splittata)
if [ -z "$TYPE" ]; then
  unzip -l apks/base.apk | grep -qE 'libflutter.so|libapp.so' && TYPE=flutter
fi
[ -z "$TYPE" ] && TYPE=native
echo "Tipo rilevato: $TYPE"

Controlla anche indicatori di altri framework (solo per informare l'utente, non cambia la pipeline):

• React Native → assets/index.android.bundle presente
• Xamarin → assets/assemblies/ presente
• Cordova/Ionic → assets/www/ presente

Stampa:

Tipo rilevato: Flutter (oppure nativo). Procedo con il toolchain corrispondente.

Step 6 — Estrazione e decompilazione

6a — jadx su base.apk (sempre, sia Flutter sia nativo)

jadx apks/base.apk -d source/ 2>&1 | tail -20

Non spaventarti per i warning di jadx — sono normali. Verifica che source/sources/ non sia vuota.

6b — Se Flutter: estrai libapp.so e lancia blutter

# Estrai la split arm64 (se presente)
unzip -o apks/split_config.arm64_v8a.apk -d split_arm64/ > /dev/null
# Oppure, se era tutto nel base.apk (app non splittata):
# unzip -o apks/base.apk -d split_arm64/ > /dev/null

# Lancia blutter
BLUTTER=~/Desktop/blutter  # path standard; se diverso, lo script check_tools lo rileva
cd "$BLUTTER"
python3 blutter.py "$OUT/split_arm64/lib/arm64-v8a" "$OUT/blutter_out"
cd "$OUT"

La prima esecuzione di blutter per una nuova versione Dart può richiedere 30+ minuti (clone e build del Dart SDK). Avvisa l'utente e mostra un tail del log se l'operazione dura molto.

Verifica che blutter abbia prodotto almeno blutter_out/pp.txt e blutter_out/blutter_frida.js.

6c — Se nativo: lancia apktool

apktool d -f apks/base.apk -o unpacked/

Step 7 — Scansione vulnerabilità

Leggi ~/.claude/skills/reverse-apk/scripts/patterns.md per i pattern esatti. Per ogni categoria, esegui i grep indicati e raccogli i risultati in variabili/file temporanei dentro report/raw/.

Le 4 categorie sono:

7a — Segreti hardcoded

Grep su source/sources/ (sempre) e su blutter_out/pp.txt (se Flutter):

• URL HTTP/HTTPS con path (endpoint API)
• API key/token/secret (pattern: api[_-]?key, secret, Bearer , JWT, AWS, GitHub, Google API)
• Firebase config chiaramente di produzione

7b — Analisi AndroidManifest

Estrai il manifest con aapt (o leggi unpacked/AndroidManifest.xml se nativo, altrimenti decompila con jadx):

# Se non hai apktool: aapt è in android-commandlinetools
# oppure prendi AndroidManifest.xml da source/resources/
cat source/resources/AndroidManifest.xml 2>/dev/null || cat unpacked/AndroidManifest.xml

Flag:

• android:debuggable="true" → CRITICO
• android:allowBackup="true" → MEDIO (dati estraibili via adb backup)
• <uses-permission> pericolosi: READ_SMS, READ_CONTACTS, ACCESS_FINE_LOCATION, CAMERA, RECORD_AUDIO, READ/WRITE_EXTERNAL_STORAGE, REQUEST_INSTALL_PACKAGES, SYSTEM_ALERT_WINDOW
• Activity/Service/Receiver con android:exported="true" senza permission → attack surface
• <intent-filter> con <data android:scheme="..."> → deep link (vettore di phishing se non validati)
• <provider> esportati → potenziale SQL injection / path traversal
• android:usesCleartextTraffic="true" → MEDIO
• networkSecurityConfig che consente user-certs → MITM più facile

7c — Anti-tamper

Grep sul source (e pp.txt se Flutter) per pattern noti:

• Root detection: /system/bin/su, Superuser.apk, Magisk, RootBeer, com.topjohnwu.magisk
• Debug detection: isDebuggerConnected, FLAG_DEBUGGABLE, TracerPid
• Emulator detection: Build.FINGERPRINT, generic_x86, goldfish, ranchu
• SSL pinning: CertificatePinner, X509TrustManager, TrustManagerFactory, checkServerTrusted
• Play Integrity / SafetyNet: PlayIntegrity, SafetyNet.attest, IntegrityManager

Non è una vulnerabilità di per sé — è informazione per chi deve fare analisi dinamica. Nel report va in sezione "Controlli client-side rilevati (da bypassare con Frida)".

7d — Crypto weakness

Grep per algoritmi e pattern deboli:

• MD5, MessageDigest.getInstance("MD5")
• SHA-1, SHA1
• DES, DESede, 3DES
• AES/ECB, Cipher.getInstance("AES") (default = ECB)
• IV hardcoded: new IvParameterSpec(new byte[, ivParameter.*0x
• Key hardcoded: SecretKeySpec(.*getBytes
• Random() usato in contesto crypto (va bene solo SecureRandom)
• TLS versioni vecchie forzate: SSLv3, TLSv1, TLSv1.1

Step 8 — Generazione report

Usa ~/.claude/skills/reverse-apk/scripts/report_template.md come scheletro. Compila ogni sezione con i findings raccolti nello step 7. Per ogni finding includi:

1. Descrizione concreta (con file:linea quando possibile)
2. Severità (CRITICO / ALTO / MEDIO / BASSO / INFO)
3. Tip di remediation (come risolverla lato sviluppo)

Salva il report in "$OUT/report/REPORT.md".

Alla fine mostra all'utente:

• Path completo del report
• Conteggio findings per severità
• 1-2 findings più critici come "highlight"
• Comando pronto per lanciare Frida (se Flutter):

  frida -U -f <package> -l "$OUT/blutter_out/blutter_frida.js" --no-pause
  

Step 9 — Checklist finale da mostrare all'utente

Usa il formato checkbox GFM:

• APK scaricati in apks/
• Tipo app rilevato: <Flutter|native>
• Decompilazione jadx completata
• blutter / apktool completato
• 4 categorie di scan completate
• Report salvato in report/REPORT.md

Gestione errori comuni

• adb: no devices/emulators found → chiedi all'utente di collegare device + abilitare USB debugging, poi riprova.
• adb pull fallisce con permission denied → il device non è rootato e il package non è world-readable. Suggerisci adb shell run-as <package> oppure scaricare da APKMirror/APKPure come fallback manuale.
• blutter fallisce in compilazione → mostra gli ultimi 30 righe del log e suggerisci brew install llvm@16 se macOS <15, oppure aprire issue sul repo blutter se versione Dart non supportata.
• jadx esce con codice != 0 ma produce output → è normale, vai avanti.
• apktool fallisce su base.apk malformato → riprova con apktool d --no-res apks/base.apk per skippare le risorse problematiche.