Lavorando nell’ambito della consulenza mi capita di dover analizzare il funzionamento di app e programmi realizzati da terzi, come avevo già avuto modo di raccontare in un talk sul reverse engineering dei dispositivi IoT. Lo scopo di questo articolo è raccontarvi un esempio pratico di quanto mi è capitato a febbraio, spiegando la metodologia utilizzata e fornendovi alcuni spunti di approfondimento.

In realtà in questo caso non si è trattato di lavoro, ma di una scena quantomeno bizzarra accaduta al bar assieme ad altri membri del GrappaLUG. Un amico mi ha esposto il suo problema:

Andrea guarda, la banca ora non ci manda più gli SMS con comunicazioni e codici, ci hanno detto di installare questa app. Quando l’ho avviata mi ha detto di disattivare il debug USB, ora mi dice che ho il root. Ma io non l’ho mai fatto, né ho cambiato il software di sistema, uso il telefono così come l’ho comprato.

Un’applicazione problematica

L’app bancaria in questione è Notify, la quale ha ricevuto moltissime recensioni da 1 stella per malfunzionamenti vari. Molti dei commenti lamentano lo stesso problema trattato in questo post.

All’avvio l’app tenta di effettuare un paio di controlli di sicurezza, presumibilmente per proteggere gli utenti da potenziali furti di codici. Il problema è che si rifiuta totalmente di funzionare se pensa non siano stati superati. L’utente non viene avvertito, ma totalmente tagliato fuori dall’app.

• 

• 

Mentre il debug USB è molto semplice da disattivare, togliere il root è più complicato… specialmente se il telefono non è sbloccato ma la app si rifiuta lo stesso di funzionare!

Dopo aver ragionato per qualche minuto ho capito che il mio amico non aveva molte opzioni ed era necessario modificare l’app per rimuovere il controllo per poter continuare a usare il conto corrente.

Cosa dice la legge

A questo punto, se siete persone prudenti e magari anche fan dei film di Antonio Albanese, vi sarà sicuramente venuta in mente una citazione:

Sì ma, è legale questa cosa?

Cetto La Qualunque

Si tratta di una giusta osservazione, in quanto il reverse engineering di codice di terze parti potrebbe sembrare una potenziale violazione di copyright. Fortunatamente la “Direttiva 2009/24/CE del Parlamento europeo e del Consiglio, del 23 aprile 2009, relativa alla tutela giuridica dei programmi per elaboratore” è piuttosto esplicita su questo punto:

Possono comunque sussistere circostanze in cui tale riproduzione del codice e la traduzione della sua forma sono indispensabili per ottenere le informazioni necessarie per conseguire l’interoperabilità con altri programmi di un programma creato autonomamente. Si deve pertanto ritenere che, solo in tali limitate circostanze l’esecuzione degli atti di riproduzione e traduzione della forma del codice, da parte o per conto di una persona avente il diritto di usare una copia del programma, è legittima e compatibile con una prassi corretta e pertanto essa non richiede l’autorizzazione del titolare del diritto. Uno degli obiettivi di tale eccezione è di consentire l’interconnessione di tutti gli elementi di un sistema informatico, compresi quelli di fabbricanti differenti, perché possano funzionare insieme.

Problema risolto. Il mio obiettivo era proprio quello di rendere interoperabile l’app della banca con il sistema operativo Android del mio amico, nonostante ci fosse un piccolo bug che ne impediva il corretto caricamento.

Analisi e modifica dell’app

L’ultima volta che ho parlato di analisi di un’app Android, avevo fatto riferimento al fatto che è abbastanza facile decompilare un file APK e ottenere del codice Java che spesso è praticamente perfetto. Questo è estremamente comodo per leggere come funziona un’applicazione, ma si tratta di un problema se si vuole modificarla e creare un nuovo APK.

Infatti se il codice decompilato è “quasi” giusto ma non perfetto, ricompilarlo risulta impossibile. Quello che invece conviene fare è lavorare sul codice smali, che è praticamente l’equivalente di assembly per Dalvik, la macchina virtuale Java di Android.

La procedura per modificare un’app si suddivide quindi nei seguenti passi:

1. Estrarre il bytecode classes.dex dall’APK
2. Disassemblarlo in codice smali
3. Modificare il codice con attenzione
4. Riassemblare il codice
5. Rigenerare un APK con il codice modificato
6. Firmare digitalmente l’APK

Questo procedimento richiede l’uso di vari strumenti, tra cui apktool e dex2jar. Si tratta di passaggi semplici (a parte la modifica del codice), ma sono ripetitivi ed è meglio automatizzarli. A tale scopo sono nati vari progetti per tutte le piattaforme. Per esempio, su Linux si può usare Adus.

Mentre ero lì che cercavo qualche idea su come agire, ho casualmente scoperto APK Easy Tool, un programma per Windows molto pratico che fornisce poche icone a portata di mouse. Siccome volevo sbrigarmela in pochi minuti e avevo una macchina virtuale Windows sul portatile, ho deciso di provarlo.

Dopo aver reperito una copia dell’app da APKMonk, ho provveduto a caricarla e ho premuto il tasto Decompile. In breve tempo ho trovato il risultato nella cartella Decompiled APKs, con un bel po’ di file da analizzare.

Cercando la stringa Errore: ho trovato subito una corrispondenza nel file smali/it/phoenixspa/notify/MainActivity.smali, in particolare nel metodo ALY6W. Lo stesso metodo viene invocato al termine del metodo SKMXK e dal codice notiamo delle parti molto interessanti:

.method public SKMXK()V
    .locals 2
    new-instance v0, Lit/phoenixspa/notify/check/CheckerService;
    invoke-direct {v0}, Lit/phoenixspa/notify/check/CheckerService;->()V
    invoke-virtual {v0, p0}, Lit/phoenixspa/notify/check/CheckerService;->ELG2Z(Lit/phoenixspa/notify/MainActivity;)Ljava/lang/String;
    move-result-object v1
    const-string v0, "phone"
    invoke-virtual {p0, v0}, Lit/phoenixspa/notify/MainActivity;->getSystemService(Ljava/lang/String;)Ljava/lang/Object;
    move-result-object v0
    check-cast v0, Landroid/telephony/TelephonyManager;
    invoke-virtual {v0}, Landroid/telephony/TelephonyManager;->getDeviceId()Ljava/lang/String;
    move-result-object v0
    invoke-virtual {v1, v0}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
    move-result v0
    if-nez v0, :cond_0
    invoke-virtual {p0, v1}, Lit/phoenixspa/notify/MainActivity;->ALY6W(Ljava/lang/String;)V
    :goto_0
    return-void
    :cond_0
    invoke-virtual {p0}, Lit/phoenixspa/notify/MainActivity;->O2SHI()V
    goto :goto_0
.end method

Ho tolto le righe bianche per questioni di spazio. Il metodo richiama un CheckerService e il codice presente in smali/it/phoenixspa/notify/check/CheckerService.smali ha chiari riferimenti alla libreria rootbeer. Perciò verifica se lo smartphone ha i permessi di root.

Alla fine del codice c’è un controllo. Se il valore di v0 è uguale a 0, viene invocato ALY6W, dando un messaggio di errore. Altrimenti, l’esecuzione salta all’etichetta :cond_0 che invoca 02SHI e poi salta nuovamente a :goto_0 per restituire void.

Il flusso di esecuzione è abbastanza semplice e si dovrebbe capire leggendo lo smali, ma per renderlo più chiaro ho generato questo diagramma di flusso con androguard:

Il controllo si può aggirare rimuovendo l’if-nez e i relativi salti, invocando sempre 02SHI senza controllare v0. Ho modificato l’ultima parte in questo modo:

    invoke-virtual {v1, v0}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
    move-result v0
    invoke-virtual {p0}, Lit/phoenixspa/notify/MainActivity;->O2SHI()V
    return-void
.end method 

Tramite APK Easy Tool è bastato un click per ottenere un nuovo APK firmato automaticamente e pronto per essere installato. Per l’installazione, il modo più semplice è usare adb (va attivato il debug USB):

adb install it.phoenixspa.notify_2018-10-05.apk 

Ricordatevi che prima la versione originale deve essere rimossa, perché non abbiamo il certificato “vero” dello sviluppatore e perciò la nostra versione modificata è incompatibile con quella scaricata da Google Play.

Conclusioni

Tutto il lavoro di analisi e modifica ha richiesto circa 15 minuti, seduti al tavolo di un bar, senza conoscenze troppo approfondite di smali. Volendo si sarebbe potuto rimuovere anche il controllo sul debug USB, ma quello è facile da disattivare e non è un grosso problema.

Sono comunque rimasto perplesso dalla necessità di dover arrivare a tanto per colpa di una scelta di sviluppo poco attenta, che di fatto taglia fuori alcune persone dall’utilizzo del proprio conto corrente. Ho detto al mio amico:

Accidenti, ti rendi conto di cosa è stato necessario fare? Una persona “comune” cosa fa? O cambia smartphone, o cambia banca… è assurdo.

Se non altro ora ho una copia dell’APK che posso usare per aiutare eventuali altri conoscenti che usano la stessa banca. Mi è già capitato con un famigliare!

L’analisi delle applicazioni Android è un argomento molto affascinante, utile anche per testarne la sicurezza o effettuare analisi forensi relative al funzionamento interno dell’app e di come vengono gestiti eventuali dati memorizzati.

In questo post abbiamo visto un semplice esempio di come una piccola modifica possa essere risolutiva, ma l’argomento è molto vasto. Perciò vi vorrei segnalare alcune risorse interessanti per approfondire l’argomento:

• Yanick Frantantonio ha rilasciato delle challenge nell’ambito del corso di Mobile Systems and Smartphone Security all’EURECOM
• Kristina Balaam ha realizzato un videocorso in tre parti intitolato Reverse Engineering Android APKs
• Ivan Rodriguez invece ha pubblicato su GitHub il corso Reverse Engineering iOS Applications, dedicato ai dispositivi Apple