Lezione2 zmaster solution

From UIC

Soluzione lezione 2

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

Introduzione

Eccomi a fare il mio primo tute… da qualche parte bisogna pure iniziare, perciò ho pensato di farlo dall’inizio :)
Non ho considerazioni particolari da fare, questo primo reversing è molto semplice, immagino che sia stato compilato apposta per facilitare al massimo le cose.
Rileggendo il tute mi è venuto il dubbio di essere stato un po’ prolisso, il motivo è che ho cercato di non dare certe cose per scontate, secondo me chi si avvicina al mondo del reversing spesso ha bisogno di fare “il primo passo” e magari alcune cose è meglio ripeterle piuttosto che ometterle.

Tools

OllyDbg 1.10, beh questo mi sembra ovvio
Stealth64(plug-in di Olly), a me è necessario per poter usare OllyDbg 1.10 su Vista64.

Essay

Dunque, la consegna era di analizzare un po’ più nel dettaglio il funzionamento del programma allegato alla Lezione2, a tale scopo ci viene chiesto di brekkare nel punto di creazione della finestra principale del programma e dare poi un occhio alla DialogProc.

Iniziamo: avviamo Olly e carichiamo lezione2.exe. Olly in pochi istanti carica e analizza il tutto e ci posiziona all’Entry Point del programma, ovvero il punto da cui parte l’esecuzione.
Come richiesto settiamo un break alla chiamata di DialogBoxParam, per fare questo digitiamo nella command line:

bp DialogBoxParamA

e premiamo F9 per avviare l’esecuzione.
Olly brekka subito all’indirizzo 4010C5:

Notiamo che all’indirizzo 4010B0 è presente un $ che ci indica che si tratta di un indirizzo utilizzato da un CALL , e che dopo più avanti c’è un RET: si tratta rispettivamente di inizio e fine di una funzione. Chi ha preparato il programma per evitarci confusione ha avuto l’accortezza di fare la chiamata all’interno di una funzione e focalizzare la nostra attenzione su quelle poche righe.
Apriamo il menù contestuale con un click destro sulla riga con la CALL e scegliamo “Help on symbolic name” per avere informazioni su cosa fa questa funzione (bisogna aver settato il percorso di win32.hlp) . L’help spiega che la funzione fa apparire una Dialog prendendola dalle risorse del modulo.
Diamo una rapida occhiata agli argomenti che vengono passati attraverso delle PUSH nello stack, Olly ci aiuta scrivendoci nomi e valori nella 4° colonna:

hInst, è l’handle del modulo che serve alla funzione per recuperare la Dialog dalle risorse.
pTemplate = 0x6A, si tratta dell’ID della finestra nelle risorse. Se apriamo l’EXE con ResHack o un altro editor di risorse troveremo solo una finestra con ID 106 (106 == 0x6A).
hOwner = NULL, è l’handle della finestra genitore. Essendo NULL non ha genitore. .
DlgProc, questa è una cosa interessante: è la funzione che si occupa di gestire i messaggi della finestra. E’ qui che tra molto poco andremo a vedere cosa viene fatto..
lParam, è un parametro che viene passato all’init della Dialog, in questo caso non è importante..

Questo lo abbiamo capito nel giro di pochissimo tempo, come sarebbe stato senza gli aiuti di Olly? Ci sarebbe voluto un po’ più tempo… :S Hehe, spesso non ci si rende conto di quanto utile è una cosa finche non ci si trova senza. Mi è venuto in mente perché un paio d’anni fa devo aver provato ad usare Sice e non mi ricordo che fosse tutto così rose e fiori! :)

Ok ok, andiamo avanti. Andiamo all’indirizzo della DlgProc cioè 401000, per fare questo premiamo CTRL+G e inseriamo tale valore. Ecco la nostra funzione:

La funzione è decisamente più corposa della precedente ma tutto sommato non è poi tanto complessa. Se consultiamo win32.hlp alla voce DialogProc ci viene mostrato il prototipo di questa funzione. Non penso che sia il caso di mettersi a descrivere per filo e per segno il funzionamento di windows e dei messaggi alle finestre, questo tutorial riguarda l’uso di Olly. Diciamo solo la cosa più importante: la funzione viene chiamata per processare dei messaggi che vengono inviati in varie circostanze, nel codice c’è uno switch…case che a seconda del tipo esegue operazioni diverse, le istruzioni che saltano ai vari case sono situate tra 401012 e 401025.

In questa DialogProc vengono gestiti 3 messaggi, ognuno dei quali in un case riconosciuto ed evidenziato da Olly che associa al suo codice il nome. A 401027 viene processato WM_COMMAND, questo accade quando si clicca sul pulsante o si eseguono altre azioni sui controlli.
A 40106F viene processato WM_INITDIALOG, questo accade subito dopo la creazione della Dialog e dei suoi controlli, come dice il nome viene utilizzata per inizializzare il valore di questi ultimi.
A 401094 viene processato WM_CLOSE, questo accade premendo la X in cima alla finestra per terminare il programma o premendo ALT+F4.
Mettiamo un break ad ognuno di questi indirizzi con F2 ed eseguiamo il programma con F9 per vedere cosa succede quando vengono gestiti.

Il primo a brekkare è quello relativo a WM_INITDIALOG, come ci si poteva aspettare. Steppando pochi passi vediamo che vengono passati i parametri e chiamata la funzione MessageBoxA, e voilà, la prima messagebox appare! Mmm tutto ciò appare un po’ strano: stiamo creando la finestra principale del programma e invece ci ritroviamo il messaggio. Non doveva apparire PRIMA della finestra principale? E in effetti la finestra principale non è ancora visualizzata: cosa sta succedendo, non è già stata creata?
In effetti si poteva immaginare che la MessageBox fosse visualizzata chiamando l’opportuna API PRIMA della DialogBoxParam, qui invece viene fatto “durante” la chiamata alla DialogBoxParam. Se infatti scorriamo verso il basso lo Stack ci accorgeremo che sono state eseguite una miriade di CALL, ma siamo ancora all’interno di questa funzione, quindi l’esecuzione è stata bloccata dalla MessageBox e non proseguirà finchè l’utente non la chiuderà.
Consultando l’help della DialogBoxParam scopriamo che questa funzione:

• crea la finestra
• invia ad essa il messaggio WM_INITDIALOG
• visualizza la finestra creata ed inizializzata

Quindi ecco quello che succede: la finestra principale viene creata ma non è ancora visibile, viene mandato il messaggio WM_INITDIALOG e quindi viene visualizzata la MessageBox, quando l’utente la chiude l’esecuzione della DialogBoxParam prosegue e la finestra viene finalmente visualizzata.

Il programma è ora in esecuzione, se proviamo a fare qualcosa OllyDbg poppa subito sulla WM_COMMAND. Questo perché questo messaggio viene inviato per varie notifiche, se notiamo le prime tre righe fanno una comparazione ed eventualmente escono subito dal case. Questa comparazione non fa altro che controllare l’ID del controllo oggetto della notifica: significa “se il componente non ci interessa (cioè l’ID non è quello del pulsante) allora ignoralo”. Dato che vogliamo vedere cosa viene fatto premendo il pulsante posizioniamoci subito dopo queste tre istruzioni e riproviamo a scrivere qualcosa nella casella di testo. Questa volta tutto liscio, premiamo Ok ed ecco che Olly poppa! :)
Anche in questo caso è facile vedere quello che viene fatto: viene letto ciò che è stato scritto nella casella di testo con la GetDlgItemTextW e viene generata una MessageBox con lo stesso testo con la MessageBoxW... non occorrerebbe neanche steppare.

Ok, rimandiamo in esecuzione il programma premendo F9. Ora proviamo a chiuderlo premendo il tasto X in alto a destra della finestra: Olly poppa nel case della WM_CLOSE.
Anche qui nulla di particolare, viene chiamata la EndDialog che serve a far chiudere la finestra e a ritornare dalla DialogBoxParam.

In tutti i 3 case (e anche in quello di default, nel quale prosegue l’esecuzione dal case del messaggio WM_CLOSE) c’è una CALL a 4010D0 che è piuttosto misteriosa, a occhio mi verrebbe da dire che riguarda le eccezioni non gestite ma non ne ho ancora ben chiaro il funzionamento, debuggando ho potuto constatare che la funzione ritorna subito perché non viene mai effettuato il salto condizionale a 4010D6:

Ne consegue che la funzione non fa mai nulla ed è come non ci fosse.

Note Finali

Ecco conclusa la mia analisi della DialogProc, si tratta di un caso molto semplice ma che mi ha permesso di provare varie funzionalità di Olly. Non ho ulteriormente divagato per non appesantire il testo dato che le prove che ho fatto non avevano una finalità ben precisa. Tanto per citarne un paio trovo che siano molto utili le funzioni “Follow in Dump/Stack” e “Find references to”.

Colgo l’occasione per ringraziare tutti i docenti e studenti della UIC per dare a tutti quelli come me un “trampolino” da cui partire.

Disclaimer