Corso UIC Newbies 08

From UIC

Soluzione all'8° corso newbies - Enabling!

Infos
Author:	AndreaGeddon
Email:	andreageddon@hotmail.com
Website:	http://andreageddon.8m.com
Date:	05/12/2000 (dd/mm/yyyy)
Level:
Language:	Italian
Comments:	Qualche mio eventuale commento sul tutorial :))) :-P uff... arr... Beh, mi duole ammetterlo ma hai fatto un bel lavoro brutto animale :)))

Introduzione

Vediamo come si abilitano pulsanti e voci di menù.

Tools

• SoftIce

• WDasm32

• Un hexedit (ehi, stavolta si può patchare!)

• Mouse e tastiera

• Un editor di risorse? Nope, non servirà a nulla :-P

Link e Riferimenti

Questo è il Corso UIC Newbies n°08 disponibile alla pagina Corsi UIC Newbies

Notizie sul programma

3 pulsanti, 1 voce di menu e 1 item di menù da abilitare.

Essay

Eccoci giunti ad un nuovo capitolo di corsi per la Uic. Questa volta si tratta di funzioni disabilitate. Potete scordarvi da subito di modificare con un editor di risorse i controlli disabilitati, tanto nella creazione sono attivi, vengono disabilitati a runtime. Anche il Customiser non sarà di aiuto più di tanto, visto che per ogni controllo abilitato ci sarà poi una verifica a runtime che ri-disabiliterà il controllo se non darà esito positivo. E non serve andare a cercare "Registered" tra le string reference del wdasm. Saremo soli soletti col nostro amato softice! Non è meraviglioso??? Via!

LIVELLO 1: IL PRIMO PULSANTE

Ebbene, dopo tante ciance vi accorgerete che il primo pulsante basta abilitarlo col Customiser per registrarvi. Ora prima che diciate "ma vaffanculo andrè" vi dico che per gli altri non sarà così facile. Tuttavia a noi piace l'approccio da reverser e non da lami che usano il customiser. Quindi vediamo di dare uno sguardo un po' più approfondito alla faccenda. Abbiamo il pulsante disabilitato, sappiamo che viene disabilitato a runtime, quindi la prima cosa che mi viene in mente è di intercettare la funzione che mi disabilita il pulsante per annichilarla. Come fare? Di solito per abilitare/disabilitare un controllo standard si usa EnableWindow che ha la seguente sintassi:

se però mettete un break su EnableWindow il sice popperà in continuazione. Per ovviare a questo piccolo inconveniente basta prendere il loader del softice, caricare come modulo il crackme e premere il pulsante 'run'. Il softice popperà sull'entry point. A questo punto abilitiamo il bpx EnableWindow ed iniziamo a steppare (solo con F10 mi raccomando!). Dopo aver passato GetModuleHandle vedremo che eseguendo la riga 00401E71 il softice ci sparerà nel modulo USER32 dicendoci di essersi imbattuto nel break. Premiamo UNA volta F12 e torneremo nel processo di MFC42, quindi eseguiamo il ret su cui ci troviamo (con F10 e non F12!) e torneremo al processo del crackme, sotto la call che ha chiamato EnableWindow tramite MFC. Ecco dove arriviamo:

abbiamo tre call a EnableWindow. Dalla sintassi vediamo che prima viene passato l'handle del controllo, e poi una variabile booleana (1 = TRUE, 0 = FALSE). Come scriviamo in ogni tutorial, i parametri vengono passati in ordine inverso a causa dello stack, quindi l'ultimo parametro passato è l'handle del controllo con le righe:

e il penultimo parametro passato è il parametro booleano (si, i tre PUSH 00!). Con quei push viene passato di volta in volta il valore FALSE, ed EnableWindow quindi disabilita i pulsanti. Ora da qui sappiamo come abilitare tutti e tre i pulsanti! Possiamo tranquillamente pathcarci il file cambiando i 6A00 in 6A01 (Push 01), così ogni volta ci ritroveremo i pulsanti abilitati. Bene, ora il primo livello è registrato. Ah, dimenticavo... Siamo passati anche sopra i tre SetDlgItemText che ci scrivono Unregistered, quindi potevamo cambiare il puntatore alla stringa per far scrivere Registered, ma questa non sarebbe stata una vera soluzione! Insomma, se lo scopo del crackme è di abilitare i controlli......

LIVELLO 2: IL SECONDO PULSANTE

Bene, dopo aver patchato il programma per attivare tutti e tre i pulsanti, abbiamo cliccato sul primo e ci siamo registrati! Ora clikkiamo sul secondo e sul terzo... Strunz! Si disabilitano!
Evidentemente c'è qualche operazione (nella funzione associata alla pressione del pulsante) che ci disabilita il pulsantino caro! Possiamo riciclare il metodo precedente e breakare su EnableWindow, però visto che siamo reversers (o almeno proviamo ad esserlo...) scegliamo un altro attacco! Stavolta l'idea è di esaminare tutto ciò che avviene a partire dalla pressione del pulsante in poi. Per farlo dovremo usare un break sul messaggio che viene inviato dopo la pressione del pulsante. Tale messaggio è WM_COMMAND. Però non possiamo settare un bpx WM_COMMAND, ma dobbiamo usare l'apposito BMSG. Per usare bmsg ci servirà l'handle del controllo che vogliamo esaminare. Come si ottiene?? Col crackme in esecuzione andiamo in softice, battiamo "hwnd ottavo" ed otterremo la lista degli handle per tutti i controlli e cavoli vari riguardanti il processo dell'ottavo:

e così via. Beh, visto che non c'è un bottone solo nell'applicazione, dovremmo cercare a culo qual èl'handle del pulsante che ci interessa (tutti gli handle della classe button sono buoni candidati). Per esempio facendo un paio di prove il secondo handle-button mi risulta relativo al pulsante del livello 1, mentre l'handle del pulsante del livello 2 è il 3°. Come facciamo a saperlo? Basta che usiamo in softice il comando

e di volta in volta proviamo su handle il valore dell'handle che ci siamo ricavati con hwnd. Gli handle cambiano ad ogni esecuzione, quindi se riavviate il programma non riusate gli handle settati prima! Settiamo di volta in volta un break su un x handle e premiamo il pulsante del livello 2. Se il sice poppa, abbiamo azzeccato l'handle, altirmenti proviamo il prossimo. Quindi trovato l'handle del pulsante del secondo livello breakeremo nel kernel.Premete F12 finché non sarete tornati al processo della libreria MFC42, quindi steppate qualche riga fino al RET e tornerete nel processo dell'ottavo a questo punto (00401846):

è chiaro che basta noppare il jump alla riga 00401826 per evitare di incappare nella call a MFC che si occupa di disabilitare il pulsante. Il compare alla linea 0040181D è il responsabile della funzione disabilitata: confronta eax con 1E240 e se sono uguali disabilita il bottone. Ovviamente per lo scopo del crackme tale valore non è modificabile esternamente (tipo cambiando la data o una chiave del registry), ma in un programma è importante capire cos'è che ha disabilitato la funzione. Bene, hurry to the next!

LIVELLO 3: IL TERZO PULSANTE

Anche qui dopo aver abilitato il terzo pulsante con il metodo descritto per il primo, notiamo che in seguito alla pressione otteniamo solo la sua disabilitazione. Come prima ci cerchiamo l'handle tramite HWND e mettiamo un bel bmsg per beccare la routine associata al pulsante. Nella lista degli handle del processo "Ottavo" dobbiamo prendere il quarto handle. Ora premiamo sul pulsante, e come prima arriveremo nel kernel. Premiamo F12 fino ad arrivare al processo di MFC, quindi steppiamo sul ret e torniamo al processo dell'ottavo alla riga 004018E2:

la situazione è quasi uguale a prima, solo che la condizione non è una sola, ma dai tre compare:

che sono legati da un'operazione di and e una di or. Potete patchare a piacimento, la via più pigra è quella di noppare tutti e tre i jump seguenti ai relativi compare e buonanotte. Anche qui ci siamo registrati. Ora per fortuna si cambia scena: passiamo ai menù!

LIVELLO 4: ITEM DI MENU

Spesso capita che un prog possa avere un menù disabilitato. Se il programma è stato scritto con il menù già disabilitato, allora basterà un editor di risorse per attivarlo. Se invece il programma disattiva il menù a runtime (ad esempio in seguito al controllo della data), allora dobbiamo cercare di intercettare la disabilitazione per fregarla. È il caso del crackme in questione. Stavolta non possiamo usare EnableWindow, ma dobbiamo cercare qualche funzione che ha a che fare con i menu. Basta dare una occhiata alla fida guida API e troviamo le funzioni tipo EnableMenuItem, ModifyMenu, SetMenuItemInfo, e qualcun'altra. Possono tutte essere usate per disabilitare i menu. Per scegliere quella giusta basta conoscere la pigrizia e lamanza dell'autore, e salta subito agli occhi che la funzione usata sarà EnableMenuItem (la più semplice da usare :-). Basta anche guardare nelle import del programma e la trovavamo bella bella in USER32. Ora che sappiamo dove colpire, colpiamo! Settate un bpx EnableMenuItem e lanciate il programma. Breakerete immediatamente. Premete F12 e finirete nel processo SHELL32, che non è quello che ci interessa, quindi premete F5 per continuare l'esecuzione. Ri-Break! Anche stavolta premiamo F12 e di nuovo incapperemo in SHELL32. Che palle. Continuate con F5 e poi F12 finché dopo il quarto/quinto break circa premendo F12 vi ritrovate nel processo dell'ottavo. Arriverete nel seguente codice:

facile no? Bastava seguire le string reference, ma noi non vogliamo essere lami giusto? La call ebx è quella che ci disabilita il menu. Vediamo la sintassi della funzione:

quindi entrambe le volte abbiamo un bel PUSH 01, che pusha il flag che determina il grigiore dei menu. Per inciso, il campo uEnable della funzione può contenere i seguenti parametri costanti:

MF_BYCOMMAND        =  0

MF_BYPOSITION         =  400

MF_DISABLED            =  2

MF_ENABLED             =  0

MF_GRAYED               =  1

possiamo quindi sostituire i due PUSH 01 con PUSH 00 per fargli arrivare il flag ENABLED. Quindi con un colpo solo abbiamo abilitato il livello 4 e 5. Ora però dobbiamo registrarci. Per il livello 4 la cosa sarà semplice. Anche i menù utilizzano il messaggio WM_COMMAND per notificare la selezione di un menu o di un item di menu, quindi di nuovo ricorriamo al bmsg. Avendo il crackme in esecuzione, andiamo in softice e ricaviamoci la lista degli handle con "hwnd ottavo", questa volta ci interessa il primo handle, quello che ha come class name "Dialog". Preso l'handle adesso settiamo il

questo è un break più generico, breakerà su ogni wm_command dell'applicazione, compresi quelli dei menu. Ora che il break è attivo andiamo nel crackme e premiamo il menu del livello 4. Apparirà il softice e vi ritroverete nel kernel. Per tornare al crackme dobbiamo fare parecchia strada, dobbiamo premere circa 13 volte il tasto F12, cioè fino a che non arriviamo nel processo delle MFC42. Una volta arrivati lì ci troveremo sopra un ret, non premete F12, ma F10, cioè steppate il ret e tornerete al processo dell'ottavo sulla riga 004019FD. Eccovi il listato della routine:

la routine è semplicissima, c'è un solo jump che ci rompe le scatole. Se lo noppiamo incappiamo in un'altra call a setDlgItemTextA e verremo registrati.

LIVELLO 5: VOCE DI MENU

Ci rimane l'ultimo pezzo di questo borioso crackme. Analogamente al precedente livello, settiamo il bmsg sull'handle del dialog, premiamo la voce di menu "Abilitami", e il softice popperà, e come prima ci ritroviamo nel kernel. Notiamo però che stavolta non è facile tornare al processo dell'ottavo. Se premiamo sempre F12 scorreremo i processi Kernel e User fino a tornare nel processo delle MFC. Ora se premiamo F12 usciamo da softice, se invece steppiamo fino al ret più vicino rimaniamo sempre impantanati nel processo delle MFC. Più precisamente dopo un po' di tracing arriviamo ad un ciclo, quello formato da PeekMessage, GetMessage, SendMessage, TranslateMessage etc. Questo è il ciclo vitale della finestra, cioè è il ciclo che rimane in continuo in esecuzione per processare e gestire i messaggi dell'applicazione. La fregatura è proprio questa, che i messaggi vengono gestiti da quelle katz di mfc e non dall'applicazione stessa, il che ci crea qualche problema nel tracing. Ora a prima vista sembra che non si possa tornare al processo dell'ottavo, però secondo logica ci deve tornare per forza. Insomma, le mfc gestiscono i messaggi, quindi ricevono il messaggio wm_command, capiscono quale controllo ha mandato il messaggio (nel nostro caso la voce di menu) e redirigono l'esecuzione alla funzione associata alla selezione della voce di menu. Tale funzione deve necessariamente trovarsi nel processo dell'ottavo, tutto sta a capire come arrivarci. Tale funzione viene processata da CallProc32W (la trovate tracciando un po' di kernel dal punto in cui breakate in poi), e poi anche in CallProc32w cercare di tracciare il codice che ci riporta alla funzione dell'ottavo è un incubo. Per tagliare le palle al toro ci inventiamo qualche trucco che ci permette di risparimare tempo (e fatica mentale :-). Visto che il processo dell'ottavo viene eseguito, e a quanto pare proprio sotto il nostro naso, allora settiamo un bel

e vaffanculo. Che vor dì? BPR è un BreakPoint on Memory Range. gli indirizzi 00401000 e 00403000 delimitano la sezione di codice del crackme. Per vedere le sezioni usate il comando

e avrete una cosa di questo genere:

la prima sezione (.text) è quella di codice, e si estende dall'indirizzo 00401000 a 00403000. Quindi, ricapitolando, quello che abbiamo fatto è stato quello di settare un breakpoint su qualsiasi lettura/scrittura di un qualsiasi byte contenuto nella sezione di codice, così appena il controllo tornerà al codice del crackme noi lo taneremo subito. Quindi settiamo prima un bel bmsg sull'handle del dialog, una volta breakato settiamo il bpr appena scritto, quindi cominciamo a premere F5. Ogni volta breakeremo su una riga dell'ottavo, ma principalmente ci ritroveremo o su una lista di JMP, o su un MOV/RET. Questa è tutta robaccia che non ci interessa, quindi premiamo F5 (parecchie volte) finché arriviamo alla linea 00401980:

anche questa è una routine banale, c'è un solo jump che decide se registrarci o meno. Per decidere se siamo registrati lui carica la stringa "èInArrivoLoStrainer", prende il 4° char (il carattere A) e lo confronta con un numero in edx. Se questo numero è maggiore, allora riamo unregistrati. Tale valore cambia da esecuzione ad esecuzione, quindi potrebbe in qualche caso essere minore di 41h (A) e registrarci automaticamente? Se andiamo in wdasm e cerchiamo la stringa 004041F0 (la locazione da cui prende il numerello), troviamo le seguenti righe:

quindi il valore del numerello è determinato da GetTickCount. Questa funzione restituisce il valore in millisecondi da quando è partito il windogs, quindi lo possiamo considerare un valore pseudo casuale, ed inoltre siamo sicuri che il crackme non si registrerà mai da solo al 5° livello perché è difficile che riusciamo ad eseguirlo entro i primi 41h millisecondi dall'avvio del win :-). E con questo abbiamo terminato il crackme. That's all folks!

Byex

AndreaGeddon

Note Finali

Ciauz a tutta la ML e a tutti quelli che rompono su crack-it, in particolare Nerds :-). Un salutino a GioCrackino che finalmente è venuto a seguire algoritmi! Poi il Quequerino che ancora non mi dà l'uicCd :-(. Bai bai.

Disclaimer

Queste informazioni sono solo a scopo puramente didattico. Avete a disposizione un periodo di 15 giorni per provare il crackme, dopodichè dovete comprarlo. L'autore si riserva il diritto di mandarvi la GdF a casa se un je mandate li sordi. AndreaGeddon®© is a registered TradeMark. Byeeeeee