Lezione6 zmaster solution

From UIC

Soluzione lezione 6

Infos
Author:	Zmaster
Email:	zmaster.adsl@gmail.com
Website:
Date:	27/09/2008 (dd/mm/yyyy)
Level:
Language:	Italian
Comments:	Azzua bel lavoro ndPnluck

Introduzione

Il compito per casa della Lezione 6 era decompilare una subroutine (cioè passare dal codice macchina al codice sorgente, in questo caso passando per l’asm come step intermedio).
Per fare questo ho utilizzato IDA come disassemblatore, ha il vantaggio di essere più completo di OllyDbg e permette man mano che si reversa il codice di rinominare variabili, costanti, ecc. ecc. con testi più significativi.

Tools

IDA 4.9 free

Essay

Iniziamo: apriamo l’eseguibile con IDA e andiamo a cercare la funzione all’indirizzo 401170:

Come è stato spiegato nella lezione questa subroutine è una nuova WindowProc che viene utilizzata per realizzare un SubClassing della Textbox dove si inserisce la password.
Questo ci dice che si tratta di una funzione che riceve i 4 parametri di tutte le WndProc.
Nel listato qui sopra ho già utilizzato la funzionalità di IDA “Create Function” per farmi analizzare l’uso dello stack e mostrarmi chiaramente l’utilizzo degli argomenti. IDA non ha riconosciuto il secondo parametro: aiutiamolo con un click destro su arg_4 e rinominiamolo in uMsg.

Iniziamo a dare un occhio all’assembly:

In pratica in queste righe viene copiato l’argomento uMsg in EDI e viene controllato se è uguale a 0x87. Se è diverso il programma salta più avanti, continuando l’esecuzione all’interno della funzione, altrimenti setta EAX a 4 e ritorna.
0x87 è il codice del messaggio WM_GETDLGCODE, win32.hlp ci spiega che viene usato da windows per chiedere ad un controllo che tasti è in grado di processare. Scrivere 4 in EAX significa ritornare DLGC_WANTALLKEYS.

Nel caso uMsg sia diverso l’esecuzione prosegue a 401186:

Viene controllato se il messaggio è 0x101, che sarebbe WM_KEYUP, se non lo è salta più avanti a 4011F4.
Se il messaggio è proprio WM_KEYUP l’esecuzione prosegue: viene chiamata GetWindowTextW per leggere il testo dalla Textbox in un buffer che si trova a 40AC90, dimensione massima 0x14 == 20 bytes. La funzione ritorna in EAX il numero di caratteri letti. La successiva ADD non fa altro che sommare un numero in complemento a 2, cioè un valore negativo. Anche qui IDA ci risparmia di tirare fuori la calcolatrice: un click sul tasto “Change sign” e scopriamo che il valore è -5.
Le istruzioni seguenti sono banali, nel complesso questo blocco di istruzioni significa:
Se (LunghezzaStringa-5) > 14 vai a 4011F4, altrimenti carica in ECX l’offset della stringa “CESARE” e in EAX l’offset della stringa letta dalla Textbox.

Segue un ciclo di istruzioni che come si può facilmente intuire andrà a confrontare le due stringhe.
L’unica cosa curiosa degna di nota è che il confronto viene fatto su due word per volta invece che una.
Se le stringhe corrispondono viene settato EAX=0.

Segue:

Se EAX == 0, cioè se la stringa nella Textbox è “CESARE”, viene visualizzata la MessageBox di password corretta.

Nell’ultimo pezzo viene chiamata la WindowProc base del controllo Textbox. Notare che la funzione base viene invocata sempre, tranne nel caso del messaggio WM_GETDLGCODE.

Ok, dopo aver fatto quest’analisi riporto l’assembly con i simboli rinominati in base alle mie interpretazioni, ora è più leggibile:

Ora non ci resta che fare l’ultimo passo: la traduzione in C dell’assembly. Tornare al codice sorgente originale in senso stretto non è possibile ma possiamo dire che da un punto di vista funzionale era qualcosa del genere:

Note Finali

C’è voluto più tempo a scrivere il tute che non a reversare la funzione :) Saluto tutti i membri della UIC, in particolare pnluck [mi chiamo Pnluck, azz! ndPnluck] che come dice Que ha prodotto in fretta e furia la Lezione 6.

Disclaimer