La spiegazione di questo risiede nel desiderio naturale degli sviluppatori di guadagnare qualche soldo in più con la soluzione proposta, ma alcuni di essi si spingono oltre, creando un’applicazione che non serve ad altro, se non recare disturbo visualizzando messaggi pubblicitari.
Una di queste è, senza dubbio, la famiglia di applicazioni Shedun, che in realtà non sono altro se non adware/malware aggressivi, così come sono stati identificati dagli Avira Protection Labs.
Ogni giorno rileviamo circa 1500-2000 utenti infetti da tale famiglia di adware/malware.
In questo articolo esamineremo una di queste applicazioni, osservando che cosa contiene, che cosa la compone e che cosa fa effettivamente.
Sebbene la struttura interna del pacchetto che andiamo ad analizzare oggi possa variare (nomi diversi, attività impostate, immagini, video, ecc. ), il “comportamento” di tali applicazioni rimane invariato. L’applicazione installata non sembra all’apparenza dannosa, ma è veramente così? Ne dubito.
Inizieremo la nostra analisi con la struttura interna di un’app.
Come qualsiasi altra app per Android “pulita”, è costituita da classes.dex, AndroidManifest.xml, cartella delle risorse, ecc., ma ci occuperemo soprattutto della cartella “assets”. La sua struttura è la seguente:
Innanzitutto desta sospetto il fatto che questo APK abbia altri due APK al suo interno. Se proviamo ad aprirli non ci riusciremo perché sono codificati. (Infatti solo l’header del file è codificato con chiave XOR variabile).
Diamo un’occhiata a AndroidManifest.xml, perché anch’esso è molto interessante.
Come puoi vedere, ci sono molte attività (com.pronclub.GdetailActivity, com.pronclub.GwebActivity, etc.), che non appartengono all’applicazione originale (org.gro.jp.QZycJlsdApp) per cui il codice, che verrà eseguito in queste attività, viene caricato dinamicamente da un’altra applicazione. Se proviamo a decompilare il file classes.dex dall’applicazione principale, vedremo che il codice utilizza la tecnica di riflessione Java per creare il caricatore dex e caricare dinamicamente il codice, da uno degli APK. Dopo aver decodificato tutte le stringhe all’interno del file classes.dex scopriremo cose molto interessanti su questa app.
Per prima cosa l’applicazione crea cartelle separate per le librerie e per gli APK che verranno estratti successivamente e caricati in modo dinamico. Questo è ciò che succede qui:
Abbiamo rimosso una grande quantità di “codice spazzatura” che non serve a niente. In questo pezzo di codice l’applicazione acquisisce la mappa thread dell’attività principale delle applicazioni dei pacchetti correnti, crea un caricatore di classe per l’APK aggiuntivo e sostituisce il valore di questo caricatore di classe con un caricatore di classe personalizzato.
Un altro interessante pezzo di codice si trova all’interno del metodo onCreate, che sostituisce l’applicazione corrente con un’applicazione appena avviata:
In sostanza qui succede quanto segue: l’applicazione accede al thread dell’applicazione corrente, acquisisce i dati delle informazioni e li sostituisce con le informazioni sui dati di un’altra applicazione, quindi rimuove i dati creati per primi dal registro globale e crea una nuova applicazione, dopo di che sostituisce l’applicazione iniziale del thread dell’attività con l’applicazione appena creata. Ciò significa che all’avvio dell’applicazione si crea un’altra app e la prima si “autodistrugge”, per così dire. Questo spiega perché in AndroidManifest abbiamo una descrizione così strana dei tag Activity.
A questo punto esamineremo più da vicino altri componenti che sono memorizzati nella cartella assets.
Partiamo da import.apk, che è, di fatto, una libreria di riproduzione video che fornisce la funzione di riproduzione dei video.
Protect.apk è ancora più interessante. È principalmente costituito da diversi framework pubblicitari e non serve ad altro se non a mostrare all’utente un annuncio che scarica da Internet. Ciò si rileva facilmente analizzando i dati TCP/IP. Infatti stabilisce delle connessioni e visualizza gli annunci di FACEBOOK e Amazon e propone di scaricare immagini e video da Internet. La parte più interessante di questo APK si trova nel pacchetto com.qq, che viene utilizzato per creare un nuovo file nella cache dell’applicazione e scaricarne il contenuto. L’immagine che segue mostra in modo relativamente semplice questa procedura:
Così in questo pezzo di codice si crea una nuova connessione HTTP e il file verrà scaricato nel pacchetto nascosto “.p.apk”. Questo pacchetto ha semplicemente un file DEX in più, così l’applicazione prova a modificare le sue autorizzazioni e a installare l’app nascosta appena scaricata nella cartella /system/app/ .
In questo pezzo di codice vediamo chiaramente che l’applicazione sta caricando un file DEX appena scaricato e, utilizzando la tecnica di riflessione Java con argomenti specifici, esegue il metodo executeRoot nel pacchetto cn.engine.RootPerApi che infatti sta modificando le autorizzazioni /sytem/app e rimontando l’intera cartella di sistema per abilitare la scrittura in essa. Ciò consentirà al pirata informatico di posizionare i suoi binari all’interno delle sottocartelle /system/ ed eseguirli con privilegi root .
Adesso esaminiamo da vicino che cosa fa cn.engine.RootPerApi . Quando traduciamo questo codice di classe in SMALI notiamo alcuni metodi particolarmente interessanti in questa classe.
Approfondiamo l’inizializzazione della classe:
Durante l’inizializzazione di questa classe noteremo la creazione di due file nascosti nella cartella/system/xbin/. Il loro contenuto verrà scaricato e posto in quei due file. Entrambi sono chiaramente malware. Il primo di questi file .ext.base è un’applicazione demone, oltre al fatto che richiede autorizzazioni root e che verrà lanciata dal secondo file nascosto .b. Entrambi sono naturalmente binari ARM compressi in UPX.
Esaminiamo più da vicino il file .b decompresso. La sua struttura interna e il suo comportamento possono essere illustrati nella figura seguente.
Il file .ext.data decompresso legge i comandi di configurazione dal file.
Dopodichée crea un socket e attende il collegamento; una volta stabilito il collegamento, .ext.data attende i dati in ingresso dal client e li esegue utilizzando il terminale root /dev/ptmx.
L’intero processo può essere illustrato con il diagramma seguente:
Così, nel complesso, questa applicazione in background lascia cadere i pacchetti scaricati, estrae da essi i binari e cerca di avviarli con privilegi root sul dispositivo, cosa che chiaramente non farebbe una normale applicazione. Queste sono le azioni veramente dannose di questa app.
Sulla base della ricerca svolta, va ricordato che oggigiorno i creatori di malware producono un numero sempre maggiore di software sofisticati, incorporandoli nei diversi package indirizzati a dispositivi e piattaforme specifiche. In questo esempio ho voluto mostrare ciò di cui potrebbe essere costituita una cosiddetta applicazione “pulita”, ciò che effettivamente cerca di fare e quanto bene possano essere nascosti i reali motivi.
