Allegati: 3
[TUTORIAL] Android Reverse Engineering - il SO e le Applicazioni. Parte 2.
Bene ragazzi. Eccomi tornato.
Lo so che non scrivo nulla da tempo, ho i miei buoni motivi.
Da Luglio sono .-impegnato in una importante progressione di carriera e .-sono appena oggi diventato papà per la seconda volta.
Si cerca di fare molto ma poi il tempo rimanente è davvero esiguo.
Riprendiamo la seconda parte. Ho dato un'occhiata al link postato da xboxbs, da leggere in mia attesa ^_^. Un buon link, molto tecnico. Purtroppo a mio avviso non adatto a chi è alle prime armi. L'hack che presenta serve a rendere un POC (Proof of Concept) ma ricordate che, "Hello World" a parte, realizzare un code injection complesso all'interno di un apk (che faccia cose tipo: leggi la rubrica del malcapitato, i suoi contatti facebook, carpisci gli hash delle sue password e inviami tutto per e-mail, è decisamente un'altra cosa.)
Chiamiamo questa seconda parte:
APK Fundamentals. Debug e Disassembling Offline di applicazioni Android.
Perchè Offline? Perchè è possibile anche fare un debug online, real-time, dell'applicazione. Ma è qualcosa destinato a sviluppatori ed esperti.
Che tipo di limitazioni è possibile trovare nelle applicazioni?
Troviamo le versioni "Lite" o le versioni "Free" di programmi normalmente a pagamento che:
- Offrono l'utilizzo completo del programma per un periodo di tempo limitato (5 giorni, 15 giorni, 30 giorni)
- Impongono delle limitazioni su alcune funzioni dell'app, avvertendo che queste sono disponibili nelle versioni Pro/Premium
Detto questo, ecco qual'è il mio modo di operare:
- Non mi piace lavorare con i cavi quindi abilito l'ADB via rete.
- Creo una cartella apposita per i miei progetti.
Cos'è ADB?
Sta per Android Debug Bridge, ed è uno strumento a riga di comando che permette di connettersi al proprio dispositivo, sia in modalità wired che wireless per poter svolgere diverse operazioni (debug, come dice l'acronimo).
Come abilitare il Debug USB, necessario per poter utilizzare ADB? In "Impostazioni", dovreste trovare le "Opzioni Sviluppatore". Se non ci sono seguite questo semplice trucchetto. Andate in "Info Dispositivo" e poi su "Versione Build". A questo punto cliccate più volte sulla versione build. Vedrete un messaggio che dice "Ora ti mancano x passaggi per diventare uno sviluppatore" e dopo 10 tocchi, "Ora sei uno sviluppatore". Adesso dovreste avere il menu "Opzioni Sviluppatore".
Entrateci ad abilitate "Debug USB".
Per l'ADB via rete dovete necessariamente avere i diritti di root. Se non sapete cos'è il rooting, fatevi benedire dal vostro parroco di fiducia, leggete studiate e poi tornate qui.
Se invece avete una custom ROM, tipo Cyanogenmod, è possibile che abbiate l'opzioni nel Menu Sviluppatore. Se non l'avete basta scaricare un'applicazione apposta dal Playstore. Io utilizzo "WiFi ADB" e mi trovo benissimo. Semplice ed efficace.
A questo punto;
Aprite il vostro prompt dei comandi.
Entrate nella cartella dedicata ai vostri progetti.
Se volete utilizzare la connessione wired, quindi USB, collegate il dispositivo, poi verificate che sia effettivamente connesso con:
Il sistema dovrebbe rispondere così:
Codice:
List of devices attached:
xxxxxxxxxxxx Dispositivo Collegato
Se state utilizzando ADB via rete:
Codice:
adb connect (indirizzo IP del vostro dispositivo)
Verificate con "adb devices"
OK, siete connessi.
Adesso partiamo esaminando un classico APK che si può trovare sul Play Store.
Ho trovato, qualche tempo fa, per esempio una bella applicazione che è anche molto utile. Non vi dico il nome, visto che devo disassemblarla, ma vi dico ciò che fa.
Apre una connessione HTTP sul vostro dispositivo Android, in modo che potete accedervi comodamente dal vostro browser e caricare o scaricare file.
La versione Lite però ha una limitazione: Consente l'upload o il download di file non superiore a 5MB.
Noi vogliamo rimuovere questa protezione e poter avere la possibilità di utilizzarla fino al limite consentito dal dispositivo o da noi. Ad esempio io ho modificato l'app per consentirmi un trasferimento di max 10GB!!!
Ora, io cerco di essere sintetico. Per favore, dimostratemi che non siete delle capre. Documentatevi su ogni mio passaggio, perchè se pensate che poi ogni applicazione utilizzi gli stessi sistemi e quindi di utilizzare ESATTAMENTE lo stesso metodo, siete fuori strada.
Ah, dimenticavo, tutta questa manfrina è solo a scopo di ricerca e studio. L'autore non incoraggia nè permette, anzi condanna fermamente ogni forma di pirateria.
Fate quello che volete con le mie istruzioni, pubblicatele su Youtube o sul giornalino della scuola, tanto se poi non ci capite un C$$..il problema è vostro.
Quindi:
- Scarichiamo l'APK dal Play Store;
- Ora cerchiamo nel nostro dispositivo il nome completo della nostra APP. Ricordo che dovete avere i diritti di root per farlo:
- Apriamo una shell sul nostro dispositivo:
- Ci risponde il prompt dei comandi remoto. Acquisiamo i diritti di root.
- Andiamo nella cartella delle app utente.
- Enumeriamo i file con "ls"
- Fra questi file c'è il nostro pacchetto APK. Troviamolo e poi diamo "exit" tante volte quante sono necessarie per uscire dalla shell.
- Dal prompt di windows:
Codice:
adb pull /data/app/(nome APK)
- Se volete rinominatelo con un nome più breve.Non fa alcuna differenza.
- Dando per scontato che avete già l'apktool, dex2jar e JD-GUI, e che avete inserito i loro percorsi all'interno delle variabili ambiente per avere la comodità di lanciare il comando da qualunque cartella vi troviate:
- Disassembliamo l'APK:
Codice:
apktool d (nome apk)
- Decompiliamo l'APK (dex) in .JAR per leggerlo poi con JD-GUI:
Codice:
d2j-dex2jar (nome apk)
- apktool avrà creato una cartella che all'interno contiene il codice smali (disassemblato) della nostra App. I file sorgente hanno tutti estensione .smali e si trovano all'interno di una cartella "smali".
- dex2jar crea invece un altro file con lo stesso nome dell'APK ma con estensione JAR
Partiamo leggendo l'APK decompilato in JAR. Tramite JD-GUI. Il codice è molto più comprensibile rispetto allo .smali ottenuto con apktool.
E' necessaria una doverosa precisazione.
Aprendo il file decompilato vi potrete trovare di fronte due tipi di codice:
Normale pseudo-codice sorgente, come questo:
Allegato 16250
Oppure pseudo-codice sorgente offuscato, come questo:
Allegato 16251
La prima differenza la vedete da soli.
Nel primo caso il nome dei file sorgenti è per tutti in chiaro. Lo stesso vale per i metodi (o funzioni, come preferite chiamarli), all'interno dei file. Questo rende molto semplice il debug e la ricerca del codice che poi si dovrà modificare.
Proprio per rende più difficoltosa la comprensione del codice sorgente e quindi la sua modifica gli sviluppatori hanno iniziato da un pò di tempo a ricorrere all'offuscamento del proprio codice.
Come dice la parola stessa, è un processo con il quale il codice, prima in chiaro, viene passato ad un altro programma che ne offusca nomi di file e funzioni, per cui come potete vedere nella seconda immagine, i nomi sono per la maggior parte soltanto lettere. Le funzioni nel riquadro a destra sono tutte lettere, a differenza della prima immagine.
Perchè nel codice offuscato, comunque, alcuni file sorgente sono scritti in chiaro? Perchè alcuni file sono essenziali e non possono essere offuscati, come ad esempio il file principale (di solito chiamato "MainActivity"), altrimenti l'app non potrebbe avviarsi correttamente.
Modificare questi programmi è molto complicato e servono mente e mani esperte.
Volete sapere quali sono i file principali per l'avvio dell'app?
Andate nella cartella dell'APK disassemblato con apktool. Aprite il file "AndroidManifest.xml" e cercate le etichette che iniziano con "<activity" seguito da @app-name. Quelli sono i file primari che servono all'app per avviarsi.
Quindi, iniziamo l'analisi per vedere quali elementi ci vengono in aiuto:
1. E' lo sviluppatore stesso ad affermare che, nella versione Lite, non è possibile l'upload di file maggiori di 5 MB. Questo mi fa pensare che nel programma ci sia una stringa che riporti questo avviso invitando ad acquistare la versione Premium.
2. Avviando il programma e tentando di fare l'upload di un file più grande di 5MB si presenta un messaggio di errore che riporta: "Filesize xMB not allowed. Max is 5MB.Upgrade to the full version for unlimited uploads."
Quindi dovrete cercare nel codice decompilato questa stringa e saprete più o meno dove avviene il controllo sulla dimensione del file che poi genera l'errore.
Attenzione però, potreste trovarvi di fronte a questo:
Allegato 16252
Se capita vuol dire che il programmatore ha inserito nel suo codice una funzione che ha il compito di scoprire se è stato agganciato un debugger all'apk. In quel caso la funzione agisce rendendo il resto del codice incomprensibile (o meglio lo trasforma in assembly, molto più difficile da comprendere.)
E' il caso dell'app presa in esame.
Come agire allora?
Provate comunque con la funzione cerca di JD-GUI (Premete CTRL + F nella classe decompilata per la quale volete cercare la stringa di testo, oppure usare il Tab Search.
Il prossimo passo è comunque mettere mani al codice disassemblato.
Scaricate "Windows Grep". E' la trasposizione per Windows di un tool a riga di comando per Linux. Questo potentissimo strumento permette di cercare una stringa di testo in uno o più file, segnalando quante volte si ritrova il termine e in quale posizione. Lo trovate qui: [URL="http://www.wingrep.com/resources/binaries/WindowsGrep23.exe"]http://www.wingrep.com/resources/binaries/WindowsGrep23.exe[/URL]
Avviato il programma, inseriamo nel box di ricerca "5MB" oppure "Upgrade to full version".
Ed ecco che, al termine della ricerca, il programma ci dirà dove si trovano quelle stringhe. Con tutta probabilità, per l'app in esame è lì che dovremo cercare il codice che poi vorremo modificare per togliere la limitazione della dimensione del file.
Si continua però un altro giorno.
A presto.
