Windows Phone 7 - Dotfuscator XAP Reversing

From UIC

Windows Phone 7 - Dotfuscator XAP Reversing
Author:	IndieAlex
Email:
Website:
Date:	26/11/2010 (dd/mm/yyyy)
Level:
Language:	Italian
Comments:	Il mio primo tutorial

Introduction

Il recente rilascio del nuovo OS Mobile targato Microsoft porta con se, tra le tante novità, anche vecchi problemi. La natura autodescrittiva degli assembly .NET ha portato indubbi vantaggi (uno su tutti, la fine del DLL Hell) ma anche qualche svantaggio. Decompilazioni e disassemblati perfettamente leggibili sono stati terreno fertile per il proliferare di offuscatori di codice. Ma è davvero sufficiente offuscare il proprio sorgente per nasconderlo ad occhi indiscreti? L'infrastruttura .NET implementata nel nuovo Windows Phone 7 come si comporta da questo punto di vista? Farà eccezione? Cerchiamo di dare una risposta a tutti questi quesiti nel seguente tutorial (o almeno ci proviamo).

Tools

ExplorerSuite

Simple Assembly Explorer

• .NET Reflector 6.5.0.135

Notizie sul Programma

Programma offuscato con Dotfuscator 4.9 Pro. Tutte le opzioni di offuscamento attivate tranne Linking e Removal. Richiede il Windows Phone Developer Tools. Per testare il crackme avviare Application Deployment, caricare il file .xap, selezionare l'emulatore nel Target e cliccare su Deploy.

Per seguire il tutorial potete scaricare il CrackMe da qui.

Un'altra versione dello stesso CrackMe ma con offset diversi (nel caso voleste provare da soli a deoffuscare il codice) e con SupportedOrientations="PortraitOrLandscape" (tanto per fare figo) potete scaricarla da qui.

Essay

In realtà sarebbe stato più corretto intitolarlo "Deoffuscare Dotfuscator" ma suonava male così ho cercato un pretesto, come il nuovo OS Mobile di MS, per parlare un po' di deoffuscazione del codice .NET. A mia discolpa però c'è da dire che gli offuscatori di codice .NET più rognosi attualmente in circolazione, che usano tutti quei bei tricks che fanno crashare Reflector, Ildasm, OllyDbg, ecc., difficilmente potranno essere usati su WP7 attivando le opzioni di offuscamento più avanzate. Per farla breve, attualmente Dotfuscator rappresenta la soluzione più stabile su WP7 quindi analizzeremo questa cercando di offrire un approccio diverso al problema rispetto a tutte quelle informazioni che già si trovano in rete e che offrono soluzioni impacchettate e deoffuscamenti automatizzati tramite tool sviluppati da terzi. Ma veniamo al dunque, un programma per WP7 consiste in una dll contenente codice, risorse e metadata. Il compilatore impacchetta questa dll, insieme alle eventuali risorse esterne dell'applicazione, in un file con estensione .xap. Come si può esaminare questo formato? Niente di più facile... come per i vecchi file .cab usati per distribuire applicazioni Windows Mobile basta aprire il file .xap con Winzip, Winrar, o il programma di archiviazione per file compressi che preferite. E' confortante sapere che anche patchando la dll poi basta ricostruire l'archivio .xap perchè tutto funzioni senza problemi. Ora, estraiamo la dll ed esaminiamola con Reflector. La classe che ci interessa è MainPage (WP7 lavora con le pagine e non con le Form). Essendo un piccolo crackme trovare il metodo che genera il seriale non presenta particolari difficoltà ma in programmi più corposi la ricerca potrebbe richiedere certamente più tempo... comunque Reflector ci semplifica non poco la vita da questo punto di vista. Dunque, selezionando il metodo bool a(string A_0) Reflector ci mostra questo:

quindi passiamo alla visualizzazione del codice IL. Reflector ci mostra tutto il codice del metodo. A questo punto il tutorial potrebbe anche finire qui perchè, nonostante il codice offuscato, basta seguirne il flusso e calcolarsi il seriale senza neanche sporcarsi le mani. Prima di guardare il codice del metodo sottolineo che, per comodità e per migliorare la leggibilità, ho usato il listato disassemblato con Simple Assembly Explorer (SAE d'ora in poi) che converte gli offset in numeri di riga. Quindi, in questo caso, quando parliamo di numeri di riga in realtà stiamo parlando di offset. Ancora, per migliorare la leggibilità ho usato un controllo PasswordBox così da distinguere meglio la nostra key con il product code conservato nel TextBlock. Ma vediamo il listato:

La banalità del codice che genera il seriale è del tutto irrilevante dato che, come abbiamo già spiegato, la natura autodescrittiva degli assembly .NET permette di avere listati perfettamente leggibili ed inoltre, quando si ha a che fare con applicazioni .NET, spesso l'obbiettivo è la decompilazione dell'essembly o del metodo interessato. Decompilazione appunto, e se volessimo decompilare il metodo? In realtà non è difficile, basta eliminare tutte le istruzioni iniziali inutili compreso lo switch e tutte le istruzioni tipo

inutili rimbalzi che consultano lo switch per poi proseguire alla riga successiva. Si può fare il tutto manualmente con Reflexil (plugin di Reflector) o SAE che offre molte più funzionalità ed è anche più comodo. Ma se dovessimo trovarci di fronte ad un metodo con centinaia o migliaia di istruzioni? In questo caso sarebbe meglio usare un tool che ci permetta di automatizzare il tutto. CFF Explorer è adatto a questo scopo grazie alla possibilità di caricare i nostri script che andranno a patchare l'assembly. Quindi, per prima cosa, dobbiamo segnarci gli opcode che vogliamo eliminare. A questo scopo possiamo usare lo stesso CFF Explorer (o Ildasm). Per quanto riguarda le istruzioni iniziali fino allo switch (compreso) possiamo dire a CFF Explorer che vogliamo eliminare tutte le istruzioni a partire dall'offset del corpo del metodo fino all'offset dello switch. Entrambi i valori li troviamo guardando il metodo che ci interessa disassemblato in CFF Explorer. Quindi, la prima cosa che scriviamo nel nostro script è:

che nopperà tutte le istruzioni fino allo switch. In seguito guardiamo gli opcode dei rimbalzi. Abbiamo due tipi di blocchi diversi da eliminare. Il primo del tipo:

l'altro del tipo:

ora segnamoci la dimensione del metodo (che troviamo sempre in CFF Explorer) perchè la sommeremo all'offset del metodo così da rimanere nello scope dello stesso durante la ricerca. Nel nostro script:

Apriamo l'assembly patchato con reflector o SAE. Ora è molto più facile individuare i blocchi da eliminare. Rimuoviamo tutti i nop (evitando i pop dopo StringBuilder::Append) e TA DAAAAAAAAA: This item is obfuscated and can not be translated. Ma Porc... Eh si, il flusso del codice è talmente incasinato che è impossibile per Reflector riuscire a decompilarlo. Dobbiamo fixarlo e renderlo appunto un flusso invece di quel ping pong tra blocchi di istruzioni che è adesso. Si noterà che ci sono parecchie istruzioni di salto (condizionato e non) accoppiate, non va bene. Innanzitutto possiamo eliminare quel blocco inutile:

Ora dobbiamo risistemare il blocco IF che confronta il carattere preso dalla stringa ad ogni ciclo con 'A', '0' e '-' perchè è davvero inguardabile.

Come si può notare l'istruzione alla riga 34 prende il char, lo confronta prima con 0x41 ('A'), poi salta alla riga 23 e lo confronta con 0x30 ('0'), salta alla riga 45 e lo confronta con 0x2d ('-'). Quindi con SAE selezioniamo le istruzioni da 23 a 26, click destro/Move e selezioniamo la riga 39 (Type: After), click su Ok e il primo mini-blocco è andato. Eliminiamo l'istruzione di salto alla riga 35 (ex 39) che ora è inutile e proseguiamo. selezioniamo le righe da 44 a 47 (non guardate più il listato sopra, ormai dopo aver spostato il primo mini-blocco gli opcode sono ad offset differenti), click destro/Move e selezioniamo la riga 38 (Type: After), click su Ok. Eliminiamo l'istruzione di salto alla riga 38 e adesso possiamo constatare che è tutto molto più ordinato. Apriamo con Reflector e questa volta TA DAAAAAAAAAA: Ok, Reflector lo decompila ma che roba è...? Bisogna sistemare ancora qualcosina. Vediamo un pò:

L'istruzione alla riga 22 salta alla riga 42 per caricare l'intero V_5, incrementarlo e ritornare alla riga 23, rimbalzo senza senso. Selezioniamo le righe da 23 a 27, click destro/Move e selezioniamo la riga 46 (Type: After), click su Ok. Eliminiamo i salti alle righe 41 e 46 ormai inutili. Ora, lasciamo stare Reflector perchè ci sono un paio di altre cose da sistemare:

Ora nel nostro ciclo se il char è 'A', '0' o '-' il flusso salta alla riga 9 solo per inserire il char per poi proseguire alla riga 37. Anche questo non ha senso dato che l'istruzione callvirt StringBuilder::Append alla riga 11 è all'interno del blocco IF (il char è 'A', '0' o '-') e non verrà mai chiamata prima che il blocco IF stesso abbia completato il confronto. Selezioniamo le istruzioni dalla riga 9 alla riga 13, click destro/Move e selezioniamo la riga 36 (Type: After), click su Ok. Eliminiamo li salto alla riga 36 (ex 13) ormai inutile. Lasciamo da parte ancora una volta Reflector, tanto avrete già capito che bisogna sistemare l'altro StringBuilder::Append che sarebbe il blocco ELSE (il char non è 'A', '0' o '-').

L'altro StringBuilder::Append si trova alla riga 15 e, ancora una volta, non ha alcun senso averlo in quella posizione (sopra il blocco IF) dato che dovrebbe trovarsi all'interno del blocco ELSE (il char non è 'A', '0' o '-') . Selezioniamo le istruzione dalla riga 9 alla riga 17, click destro/Move e selezioniamo la riga 31 (Type: After), click su Ok. Eliminiamo li salto alla riga 22 (ex 31) ormai inutile. Bene, ora Reflector dovrebbe mostrare il codice perfettamente decompilato.

Note Finali

Dotfuscator è uno degli offuscatori più semplici da reversare ma è anche il più stabile ed il più utilizzato dagli sviluppatori per proteggere il proprio codice .NET. Ci sono offuscatori molto più ostici a dire il vero e, in un prossimo tutorial magari, non sarebbe male vedere alcune delle tecniche di offuscamento più avanzate, come implemetarle nei nostri programmi e come fixarle o eluderle. Per il momento, aver dato una occhiata al codice MSIL è stato un buon allenamento. Ringrazio quequero per l'incoraggiamento e per la disponibilità, Ntoskrnl per aver creato un tool favoloso come il CFF Explorer e tutta la UIC (così non dimentico nessuno ;p).

Disclaimer