Lezione8 SepticConvulsion solution

From UIC

Soluzione Lezione 8 for Newbie 2009

Infos
Author:	SepticConvulsion
Email:	septicconvulsion@gmail.com
Website:
Date:	12/12/2008 (dd/mm/yyyy)
Level:
Language:	Italian
Comments:

Introduzione

Bel tute quello di §-Death_Reaver-§. Ho iniziato a leggerlo sbruffoneggiando e sono finito a fare il crackme prendendomi due o tre attacchi di cuore. Cosi' imparo a fare il figo :P
Il codice che segue e' praticamente pieno di label ... che vi devo dire, io le uso sempre e penso aiutino molto :)

Tools

OllyDBG 1.10
Filemon 7
Regmon 7
Guida API

Link e Riferimenti

Questo è la soluzione del CrackmeLezione8 disponibile alla pagina Lezione_8_File_and_Registry_Keys

Essay

Come prima operazione e' saggio mettere una label sugli indirizzi di "fallimento". Ovvero: andare all'indirzzo in cui tutti i jump mandano quando un test e' fallito e metterci una bella label che vi ricordi che queste istruzioni non sono da eseguire. Questo vi permettera' di capire a priori quali sono i salti condizionali che NON vanno fatti e, di conseguenza, quali sono le condizioni da soddisfare per passare i vari test. Nel mio caso ho labellato le istruzioni 004001556 e 0040154A come "fine_check" e "closehandle_fine": saltare a queste istruzioni significa che il requisito 3 non era stato assolto. Nella figura seguente vedete come appaiono i jump che non vanno presi.

Iniziamo ad analizzare il codice come suggeritoci da §-Death_Reaver-§

Bene, il codice qui sopra consiste principalmente in 3 cicli for che mofidicano tutti i caratteri di "stringa3". Ognuno appare con una sintassi diversa, ma tutti e tre usano ECX come contatore dei cicli fatti e EAX per puntare alle varie entry dell'array. Notare che inizialmente stringa3 contiene dei valori che sembrano insensati.
Il primo for (00401297) usa EAX per puntare ogni elemento dell'array: la mette in DL, la nega, ci aggiunge uno e quindi lo riscrive. Il secondo prende un byte per volta e ci aggiunge 0F. Il terzo for (004012D0) sembra apparentemente diverso, ma in realta' il funzionamento e' sempre lo stesso! In questo caso viene utilizzato lo stack all'indirizzo "ESP+20" per fare puntare EAX alle entry dell'array.
Dopo aver analizzato bene questo codice, ci rendiamo conto che non c'e' necessita' intervenire qui: non c'e' nessuna possibilita' ne di alterare la stringa iniziale, ne possibilita' di fallimenti (infatti non ci sono jmp a inidirizzi di fallimento). Dobbiamo semplicemente fare eseguire questi tre cicli e, partendo da una sequenza di caratteri incomprensibili, ritroveremo in "stringa3" il seguente path "setup\texture.dat". In pratica i cicli serivano a decrittare la stringa originale! Andando avanti con il disassemblato troviamo:

I due memset servono ad azzerare i dati contenuti nei due buffer. In 0040130D abbiamo una chiamata alla funzione "trova_driver" seguita da un test sul valore restituito. Da qui e' gia' presumibile che la funzione debba restituire un valore diverso da zero se non si vuole causare la fine del test.

Analizziamo il codice di "trova_driver":

Si comincia controllando se la variabile "driver" sia uguale a 'Z'. In talcaso si restituisce 0 e finisce tutto li. Altrimenti si continua e si finisce nel ciclo for all'inirizzo 004015E4.

Il ciclo scorre tutte le lettere a partire da 'H:' a 'Z:' (incrementando "driver") e, tramite la API "GetDriveTypeA", ottiene in EAX la tipologia del drive corrispondente: se si tratta di un cd-rom (EAX==5) si passa alla seconda parte della funzione. Altrimenti, una volta giunti al driver 'Z:', la funzione restituisce 0 e il check fallisce.

Questa parte copia l'identificativo del drive cd-rom trovato in "path3_valido" e ci incolla dopo la stringa che e' stata decrittata da 00401297 a 004012F2 ("striga3"). Infine restituisce 1 (good!).
Riflettiamo su quanto si deve fare per passare questo check: lui cerca un drive cd-rom e, come vedremo dopo, cerchera' di leggerci qualche file. Quindi in teoria si dovrebbe avere un drive cd-crom assegnato ad una lettera da 'I:' a 'Z:' con dei dati scritti dentro. Il problema puo' essere risolto in molti modi (per esempio usare dei virtual drive, masterizzarsi dei cd), ma io da buon pigrone ho deciso semplicemente di modificare il programma nel seguente modo:

in

In questo modo al posto di partire da 'H:', noi forziamo il ciclo for ad iniziare da 'B:' (42h = 'B' in ascii), che poi verra' incrementato a 'C:' prima della chiamata a GetDriveTypeA. Ho scelto di sovrascrivere proprio quel CMP perche' era l'unica istruzione di una lunghezza adatta che si trovasse prima della chiamata a GetDriveTypeA. Poi ho noppato il JA all'indirizzo 004015DD (tanto senza il CMP non serve piu'). Infine, un' ultima modifica:

in

Con le precedenti modifiche la funzione cerchera' un hart-disk (codice 03) e, come primo tentativo, trovera' 'C:'. Cosi' posso tranquillamente lavorare sul mio hd normale senza tirare di mezzo cd e mazzi vari :) Quindi in "path3_valido" viene storato, nel mio caso, "C:\\setup\\texture.dat". Non so se andare a pathcare un crackme sia una cosa molto elegante, ma onestamente non avevo la minima voglia di tirare in mezzo cd e virtual drive e questa soluzione mi dava molto piu' controllo sul file da inserire.

Torniamo al codice principale.

Si richiama CreateFileA per aprire un file, il cui path e' salvato in "path3_valido". Se non trova nulla (EAX = -1) ci si fotte. Altrimenti in 0040134C si fa una ReadFile e si mette il contenuto in "buffer". La strlen seguente e il CMP fanno capire chiaramene che il file deve contenere almeno 16 caratteri (10h): metteteli!

A seguire ... un bellissimo delirio di test sulla stringa appena immessa! Nel codice seguente tutti gli indirizzi si riferiscono ad entry di "buffer". Io ho labellato ogni byte in oridine crescente, in modo da rendere piu' facile la lettura. Per es. bu12 = 12a entry di buffer. Con un po' di occhio si capisra' che, per ottenre un codice valido, non dobbiamo fare altro che risolvere un sistema di equazioni lineari: le incognite saranno le entry di "buffer" e le uguaglianze sono imposte dai vari CMP.

Un modo veloce per capire il valore corretto di ogni entri e' vedere i CMP. Questi ci dicono che:

Beeene, ora:

L'operazione fatta e':

Si inizia con EAX = bu9. Poi si prende l'indirizzo puntato da bu9-60h e lo si mette in ECX. ECX deve essere uguale a 0Fh. In pratica si fa

La sub fa in modo che:

Poi c'e' un for che fa la somma di tutti i valori contenuti in buffer: tale somma deve essere 64A.

Ci sono vari modi per risolvere questo sistema: uno e prendere tutte le equazioni, buttarle dentro un programma di soluzione matematica e vedere cosa ci dice. Molto probabilmente vi dira' che il sistema ha infinite soluzioni, in quanto ci sono diverse variabili libere (se non sbaglio sono 4 o 5). Se non sapete cosa vuol dire andate a farvi un giro su wikipedia. In ogni caso io una soluzione adatta l'ho trovata

Questo codice e' gia' stato praticamente spiegato nella lezione 7. In 00401443 apriamo la key "perche\\qualcuno\\le_ha\\colpite" con una chiamata a OpenKeyRegExA (il suo indirizzo e' salvato alla base dello stack). Poi chiamiamo RegQueryValueExA per leggere un valore dal registri: il nome del valore e' proprio la stringa che abbiamo messo in "buffer". Allora basta prendere i valori ascii di "buffer" e creare un valore (di tipo binario, vedi 00401487) con tale nome. Il contenuto del valore del registro verra' messo in buf_reg2. Con il mio codice, fatto apposta per avere tutti caratteri ascii validi, il valore si chiamera' "sofqipeXporXeper".

Bene, ora passiamo ai check sul contenuto del registro.

Orbene, questa parte di codice sposta gruppi di 6 byte da buf_reg2 alle varie locazioni identificate con buf_reg2_x. Se eseguidte direttamente a 004014D0 e fate un dump della memoria nelle vicinanze di buf_reg2_1, vedrete che ha semplicemente riscritto il contenuto di buf_reg2 spaziando ongi 6 byte con 2 byte a 00.

Ora si prendono tutti i gruppi di 6 byte e li si trasformano da stringhe di caratteri ascii a degli interi (usando atoi), e li si scrivono rispettivamente nelle DWORD atoiX (X tra 1 e 5). Se la stringa da trasformare non rappresenta un numero viene scritto 0.

Ok, qui si arriva effettivamente al controllo. 0040150D controlla che il trentesimo carattere (buf_reg2[29]) sia '\'. Vuol dire che il contenuto del registro deve essere di 29 caratteri piu' '\' finale. Dopo, il valore convertito dell'ultimo gruppo di 6 caratteri viene messo in "atoi5". Le istruzioni da 0040151D a 00401531 e da 00401539 a 00401541 ci dicono:

Anche in questo caso ci troviamo davanti ad un sistema lineare con molte soluzioni valide (quattro variabili su due equazioni). Io per pigrizia ho fatto scegliere

Atoi1 non viene controllata, quindi si puo' mettere quello che si vuole, cosi' come per atoi5, che conta solo che l'ultimo carattere sia '\'.

La parte seguente di disassemblato punta semplicemente a fare apparire i check nella finestra degli obbiettivi del programma. Quindi il crackme e' finito!

Note Finali

Se avete commenti e/o correzioni contattatemi pure via mail o in pm sul forum. Un grosso ringraziamento alla UIC per il corso: continuate cosi! Aspetto con impazienza le prossime lezioni.

Disclaimer