Sei sulla pagina 1di 12

Tutorial #3: Usare OllyDBG, Parte 1

Visulizza la lista completa dei tutorial

Prima di continuare a leggere.


La traduzione e la revisione di questi tutorial mi hanno portato via molto tempo. Mi farebbe dunque molto piacere
sapere cosa voi lettori pensiate del risultato finale. Siete liberi di esprimere giudizi, opinioni, pareri, critiche e consigli
al seguente link https://it.surveymonkey.com/r/FS5YHC2. Si tratta di un piccolo sondaggio che mi sar utile per capire
se valga davvero la pena di continuare questa serie. Detto questo non mi rimane che augurarvi una buona lettura!

In questo tutorial, cercher di introdurvi all'uso di OllyDbg. Olly ha molte funzioni e l'unico modo per impararle
veramente tutte quello di sperimentare e fare pratica. Detto questo, il seguente tutorial vi dar una breve panoramica.
Ulteriori argomenti non trattati in questo tutorial saranno discussi in esercitazioni successive, in modo che entro la fine,
dovreste avere una conoscenza abbastanza buona di Olly. In questa guida sono compresi alcuni file. possibile
scaricare la versione PDF di questo tutorial e i file allegati nella sezione apposita. Troverete un semplice binario che
useremo in Olly, insieme a un file in cui ho incluso alcune scorciatoie da tastiera(OllyDebug Cheatsheet.xls), la mia
versione di Olly con alcune modifiche estetiche, e un file ini che potete sostituire all'originale e che vi aiuter se siete
alle prime armi (ringrazio Lena151 per questo). Possono essere scaricati direttamente qui
http://octopuslabs.io/legend/files/tuts/R4ndom_tutorial_3.zip. Se invece preferite utilizzare la versione originale di
Olly, potete scaricarla da qui http://www.ollydbg.de/.

Caricare l'applicazione
Il primo passo quello di caricare il binario di nostro interesse in Olly. anche possibile trascinare e rilasciare il file
nella finestra di disassemblaggio di Olly, oppure fare clic sull'icona di caricamento file in alto a sinistra. In questo caso,
caricate FirstProgram.exe, che potete scaricare da questo sito. Olly lo analizzer (se siete abbastanza veloci dovreste
essere in grado di vedere lo svolgimento dell'analisi nella barra inferiore del display di Olly) e si fermer all'Entry
Point (EP) del programma:
La prima cosa da notare che l'EP all'indirizzo 401000, come possiamo vedere nella prima colonna. Questo un
punto di partenza abbastanza comune per un eseguibile (almeno per un'eseguibile non "packed" o comunque non
offuscato). Se Olly ha un'aspetto diverso e non si fermato a 401000, provate ad andare in Appearance e selezionate
debugging options, poi fate clic sulla scheda Events, e assicuratevi che WinMain (if location is known)" sia
selezionato. Quindi riavviate l'applicazione.

Ecco uno screenshot dello spazio di memoria occupato da "First Program.exe". Fate clic sull'icona "Me" (o "M" se
utilizzate una versione diversa di Olly):
Se guardate nella colonna dell'indirizzo, vedrete che in 401000, la riga contiene la dimensione 1000, il nome
"FirstPro" (abbreviazione di FirstProgram), il nome della sezione .text, e contiene SFX, code. Come impareremo
pi avanti in questa serie, i file exe hanno diverse sezioni che a loro volta contengono diversi tipi di dati. In questa
sezione c' il "codice" per il programma. lungo 1000h byte e parte dall'indirizzo di memoria 401000. Sotto potete
vedere le altre sezioni del nostro "FirstProgram"; C' una sezione .rdata che contiene data e imports all'indirizzo
402000, una sezione chiamata .data che non contiene nulla all'indirizzo 403000, e infine, una sezione chiamata
.rsrc che contiene le risorse (come ad esempio le finestre di dialogo,le immagini,il testo etc..) Tenete a mente che
queste sezioni possono essere chiamate da qualsiasi cosa- completamente a discrezione del programmatore. Vi
chiederete perch la sezione .data non contiene nulla. Beh, in realt, non cosi. Contiene cose come le variabili globali
e i dati casuali. Olly sceglie di non elencare queste cose in quanto non in grado di stabilire esattamente di che tipo di
dati si tratta. Nella parte superiore delle sezioni, ce n' una chiamata PE Header. Questa una sezione molto
importante, una di quelle che incontreremo spesso nei tutorial futuri.Per adesso, sufficiente sapere che come un
manuale di istruzioni per Windows con passaggi per caricare il file nella memoria, la quantit di spazio di cui ha
bisogno per funzionare,dove sono certe cose ecc all'head di qualsiasi exe (e anche DLL del resto). Se ora guardate in
basso alla lista, vedrete altri file oltre First Program. Vedrete comctl32, imm32, gdi32, kernel32 etc. Questi sono i file
DLL di cui la nostra applicazione ha bisogno per essere eseguita. ADII file una collezione di funzioni fornite da
Windows (o da qualche altro programmatore) che il nostro programma pu chiamare. Queste sono operazioni come
aprire finestre di dialogo, comparare stringe, creare finestre etc. Collettivamente, queste sono le API di Windows. La
ragione per cui i programmi le usano, perch se si dovesse programmare ogni funzione, anche solo la visualizzazione
di una message box impiegheremmo migliaia di linee di codice. Invece, Windows ha fornito una funzione come
CreateWindow che lo fa il lavoro al posto nostro. Questo rende la programmazione molto, molto pi semplice per il
programmatore. Potreste chiedervi come queste DLL arrivano nello spazio degli indirizzi del nostro programma e il
modo in cui windows sapeva quali fossero necessarie. Ebbene, queste informazioni vengono memorizzate nel PE
Header di cui abbiamo parlato prima. Quando Windows carica il nostro exe in memoria, controlla questo header e
trova i nomi dei DLL, cosi come le funzioni in ogni DLL di cui necessita il nostro programma, e poi le carica nello
spazio di memoria del programma in modo che possa chiamarli. Ogni programma caricato in memoria avr anche le
DLL necessarie di cui ha bisogno caricate nel suo spazio di memoria. Questo significa che, presumibilmente, alcune
DLL potrebbero essere caricate pi volte in memoria se diversi programmi sono attualmente caricati e tutti utilizzano
quel particolare DLL. Se volete vedere con esattezza quali funzioni chiama il nostro programma,potete fare clic destro
nella finestra di disassembly di Olly e selezionare Search For -> All Intermodular Calls. Dovrebbe apparirvi
qualcosa di simile a questo:

Questo potrebbe sorprendervi, ma l'elenco apparso molto piccolo, solitamente ci sono centinaia o migliaia di funzioni
necessarie per un prodotto commerciale, ma dal momento che il programma di esempio molto semplice, non ne
necessita di molte. Sebbene, pensando a ci che fa il nostro programma, vi sembreranno comunque un sacco di
funzioni solo per svolgere un ruolo cos basilare! Benvenuti in Windows. Questa finestra mostra per primo il nome del
DLL, e in seguito il nome della funzione. For instance, User32.LoadIconA nella DLL User32 e il nome della
funzione LoadIconA. Questa funzione di solito ha il compito di caricare l'icona nell'angolo in alto a sinistra della
finestra. Quindi, facciamo una ricerca di tutte le stringhe dell'app. Fate clic sulla finestra di disassembly e scegliete
Search For -> All Referenced Text Strings":

Questa finestra mostra tutte le stringhe di testo che stato possibile trovare all'interno della nostra app. Dal momento
che si tratta di un'applicazione molto semplice, ce ne sono solo un paio. La maggior parte delle applicazioni ne
avranno molte di pi (a volte anche centinaia di migliaia) a meno che non siano state offuscate o packed. In questo
caso, potreste non vederne nemmeno una! Il motivo per la quale i packers fanno questo perche i reverse engineers
(almeno quelli nuovi) fanno un pesantemente affidamento alle stringhe di testo per trovare funzioni importanti in un
file binario, e rimuovendo le stringhe di testo si rende molto pi difficile la vita ai reverser. Immaginate se facendo una
ricerca delle stringhe di testo trovate un messaggio del genere Congratulazioni! Hai inserito il seriale corretto? Beh,
questo sarebbe un grande aiuto per un reverser (and we will see this time and again). A proposito, facendo doppio clic
su una delle stringhe verrete portati alle istruzioni che le utilizzano nella finestra di disassembly. Questa una bella
feature, in questo modo potete saltare direttamente al codice che utilizza la stringa.

Esecuzione del programma


Se guardate in alto a sinistra su Olly, dovreste vedere una finestra gialla con scritto "Paused". Questo significa che
l'applicazione in pausa (all'inizio in questo caso) e pronta all'utilizzo. Quindi cerchiamo di darci da fare! Provate a
premere F9 (oppure andate su "Run" dal menu "Debug"). Dopo qualche secondo, il nostro programma far apparire
una finestra di dialogo (che potrebbe per aprirsi alle spalle Olly, quindi se necessario riducete a icona la finestra del
debugger per assicurarvi che la finestra di dialogo non sia finita in secondo piano.)
Quella stessa casella che precedentemente segnava Paused dovrebbe ora apparire come Running(In esecuzione). Ci
significa che l'applicazione in esecuzione, ma in esecuzione all'interno di Olly. A questo punto potete interagire con il
programma, dunque fatelo
*
Guardate come funziona e cosa fa. Se accidentalmente doveste chiuderla, fate nuovamente click su di Olly e premete
Ctrl-F2 (o selezionate Debug-> Restart) per ri-caricare il programma, a questo punto basta premere F9 per eseguire
nuovamente l'applicazione. Ora provate questo: con il programma in esecuzione, fate clic sull'icona di pausa di Olly (in
alternativa premete su F12, oppure andate in Debug-> Pause). Questo far si che il programma andr in pausa ovunque
si trovi in esecuzione in memoria. Ora se provate a visualizzare il programma, apparir divertente (o potrebbe anche
non apparire). Questo perch Windows non aggiorna la visualizzazione quando in pausa. Ora premete di nuovo F9 e
dovreste essere in grado di giocare ancora una volta con il programma. Se qualcosa va storto, basta cliccare sull'icona
della doppia freccia rivolta a sinistra( ) o scegliete Debug-restart (o ctrl-F2) e l'applicazione verr ricaricata e messa
in
pausa all'inizio. ora possibile eseguirla nuovamente se lo si desidera.

Stepping del programma


Eseguire un'applicazione bello e interessante, ma non vi fornit molte informazioni su quello che sta succedendo.
Proviamo quindi con uno step alla volta. Ricaricate l'applicazione (dall'apposita icona,oppure premendo
contemporaneaamente Ctrl e F2, o andando in Debug-> restart) e vi troverete in pausa all'inizio dell'applicazione. Ora
premete F8. Noterete che l'attuale selettore di linea andato gi di una riga. Olly ha eseguito una singola riga di
istruzione per poi tornare nuovamente in pausa. Se foste davvero attenti, vi sareste anche accorti della finestra di stack
scorrere di uno verso il basso e dell'apparire di una nuova voce in alto:

Questo perch l'istruzione che abbiamo eseguito, PUSH 0 ha spinto uno zero nello stack. Questo apparir nello
stack come pModule = NULL. NULL un altro nome per dire zero. possibile inoltre notare che nella finestra dei
registri, i registri ESP e EIP si sono trasformati in rosso:

Quando un registro diventa rosso, vuol dire che l'ultima istruzione eseguita ha cambiato il valore di quest'ultimo. In
questo caso, il registro ESP (che punta all'indirizzo in cima allo stack) stato incrementato di uno poich abbiamo
spinto un nuovo valore nello stack. Il registro EIP, che punta all'istruzione corrente che in esecuzione anche
aumentato di due. Questo perch non siamo pi all'indirizzo 401000, ma 401002- eseguendo l'ultima istruzione che
era lunga due byte, ora siete in pausa sulla prossima istruzione. Questa istruzione al 401002, che il valore corrente
dell' EIP. L'istruzione sulla quale Olly ora in pausa una CALL. Un'instruzione call significa che noi vogliamo
mettere in pausa temporanemanete la funzione corrente e eseguirne un'altra. Questo scenario analogo a quello della
chiamata di una funzione di un metodo in un linguaggio di alto livello, per esempio:

int main()
{
int x = 1;
call doSomething();
x = x + 1;
}

In questo codice, prima assegniamo a x il valore 1, poi mettiamo in pausa questa linea di logica e chiamiamo
doSomething (). Quando doSomething finisce, riprenderemo con la nostra logica originale e x verr incementato di 1.
Ebbene, lo stesso vale nel linguaggio assembly. Per prima cosa abbiamo spinto uno zero nello stack e ora vogliamo
chiamare una funzione, in questo caso quella in Kernel32.dll chiamata GetModuleHandleA():

Ora premete F8 ancora un'altra volta. L'indicatore di riga corrente si sposter in basso di uno, il registro EIP rimarr
rosso e aumenter di 5 (in quanto l'istruzione eseguita era lunga 5 byte) e lo stack stato riportato a come era
originariamente mostrato. Quello che successo che da quando abbiamo premuto F8, che vuol dire Step-Over, il
codice all'interno della call stato eseguito e Olly si fermato nella riga successiva alla call. Ora, all'interno di questa
call il programma protrebbe aver fatto qualsiasi cosa, ma we stepped over it. Ora, per vedere le altre opzioni,
riavviate il programma (CTRL-F2), premete F8 per fare step over sulla prima istruzione, ma questa volta premete F7
sull'istruzioni call. Noterete che l'intera finestra ora diventata diversa:

Questo perch F7 corrisponde a Step-In, il che significa che Olly ha fatto la call e si fermato alla prima linea di
questa nuova funzione. In questo caso, la chiamata saltata in una nuova area di memoria (EIP = 4012d6).
Teoricamente, se avete continuato a fare stepping attraverso queste nuove funzioni di linee di codice, vorrete poi
tornare allo statement dopo la chiamata che ci ha portato qui, di nuovo all'inizio. Ovviamente, ci sono scorciatoie per
questo, ma per ora limitiamoci a ri-avviare il programma e ricominciare da capo per evitare di confonderci troppo. Ora
che vi siete soffermati all'inizio del programma, premete F8 (Step-Over) 4 volte e atterrerete su questo statement:

Noterete che ci sono 4 PUSH statements consecutivamente. Questa volta, guardate la finestra dello stack quando
premete F8 4 volte e vedrete lo stack crescere (in realt cresce verso il basso ricordate l'esempio dei piatti?). Ora vi
chiederete perch abbiamo spinto questi numeri arbitrari nello stack. In questo caso perch questi 4 numeri vengono
trasmessi come parametri alla funzione (la funzione che stiamo per chiamare all'indirizzo 401021). Se prendiamo il
nostro precedente programma di alto livello e lo modifichiamo un po' diventer tutto pi chiaro:

int main()
{
int x = 1;
int y = 0;
call doSomething( x, y );
x = x + 1;
}

Qui, dichiariamo due variabili, x e y, e le passiamo dentro la funzione doSomething. La funzione doSomething
(probabilmente) far qualcosa con queste variabili e poi torna indietro il controllo al programma chiamante. Lo stack
uno dei principali metodi con cui le variabili possono essere passate a una funzione: ciascuna variabile inserita nello
stack, la funzione chiamata, e nella funzione, queste variabili sono accessibili, generalmente utilizzando l'inverso
dell'istruzione PUSH che POP. Lo stack non l'unico modo per fare questo, solo il metodo pi spesso utilizzato.
Queste variabili potrebbero anche essere state messe nei registri ed possibile accedervi attraverso questi registri
all'interno della funzione chiamata, ma in questo caso, il compilatore del nostro programma ha scelto di metterli nello
stack. Tutto questo diventer pi chiaro dopo aver studiato il linguaggio assembly (perch voi state studiando il
linguaggio assembly, non vero?). Ora, se premete F8 ancora una volta, noterete che apparir Running nell'active
bar di Olly e la finestra di dialogo del programma verr mostrata. Questo dovuto al fatto che abbiamo stepped-over
the call that actually has most of the program in it. all'interno di questa chiamata c' il codice che entra in un loop di
attesa di noi che facciamo qualcosa, quindi non ottenerremo mai nuovamente indietro il controllo alla linea dopo la
chiamata. Bene, andiamo a risolvere il problemaFate click sul programma e premete il pulsante 'close' per terminare
l'applicazione. Olly andr immediatamente in pausa nella riga successiva alla chiamata:

Noterete anche che il nostro programma scomparso. Questo perch, da qualche parte nella call, la finestra di dialogo
stata chiusa. Inoltre, se guardate in basso di una riga vedrete che siamo sul punto di chiamare kernel32.dll ->
ExitProcess. Questa l'API di Windows che stoppa un'applicazione, quindi, in pratica Olly ha messo in pausa il nostro
programma dopo aver chiuso la finestra, ma prima che sia stato effettivamente terminato! Se ora premete F9, il
programma verr terminato, l'active bar in Olly dir Terminated e non staremo pi facendo il debugging di nulla.

Breakpoints

Proviamo qualcos'altro, ricaricate l'app (ctrl-F2) e fate doppio clic sulla linea all'indirizzo 401011 nella seconda
colonna farete clic sugli opcodes 6A 0A. L'indirizzo 401011 or diventer rosso:

Praticamente avete impostato un breakpoint all'indirizzo 401011. I Breakpoints costringono Olly a sospendere
l'esecuzione quando vengono raggiunti. Ci sono diversi tipi di breakpoints, al fine di interrompere l'esecuzione su
diversi eventi:

Software Breakpoints

Un software breakpoint sostituisce il byte all'indirizzo di breakpoint con un 0xCC opcode, che un int 3. Questo uno
special interrupt che dice al sistema operativo che il debugger ha intenzione di mettere in pausa e prendere il controllo
prima di eseguire l'istruzione. Non vedrete il cambiamento di istruzioni a 0xCC, Olly fa tutto questo dietro le
quinte, ma quando Olly finisce su un BP un'eccezione si verifica e verr intrappolata consentendo all'utente di fare ci
che desidera. Se scegliete di consentire al programma di continuare (eseguendolo o facendo stepping), l'opcode 0xCC
verr sostituito di nuovo con quello originale.

Per impostare un breakpoint, possibile fare doppio clic sulla colonna degli opcode, oppure si pu evidenziare la riga
sulla quale si desidera impostare il punto di interruzione, premere il tasto destro del mouse, e selezionare Breakpoints-
>Toggle (o premere F2). Per rimuovere il breakpoint, potete fare doppio clic sulla stessa riga o premere il tasto destro
del mouse e selezionare Breakpoint->Remove Software Breakpoint (o pigiate nuovamente F2).

Ora che abbiamo impostato un BP (breakpoint) all'indirizzo 401011 e il nostro programma andato in pausa alla prima
istruzione, premete F9 (run). Il nostro programma verr eseguito, ma si metter in pausa sulla linea in cui presente il
nostro BP.

Desidero inoltre sottolineare una cosa molto utile. Facendo clic sull'icona della barra degli strumenti "Br" o
selezionando View->Breakpoints. Vedrete una voce nella finestra dei breakpoint che mostra il breakpoint attualmente
impostato:

Questo vi fornir una rapida panoramica di tutti i breakpoints che sono stati settati. Facendo doppio clic su uno di essi,
dalla finestra di disassembly passerete al breakpoint selezionato (anche se l'EIP rimarr lo stesso in quanto in realt non
si sta cambiando il flusso di controllo del programma. Doppio clic sul registro EIP to go back to the current line set to
execute next).

Se evidenziate un breakpoint e premete la barra spaziatrice, il breakpoint si alterner tra enabled e disabled. anche
possibile evidenziare una riga in cui presente un breakpoint e premere il tasto "DEL" che rimuover il punto di
interruzione.

Infine, riavviate il programma, andate nella finestra dei breakpoints, ed evidenziate il punto di interruzione che avete
impostato all'indirizzo 401011, e premete la barra spaziatrice. La colonna "Active" cambier in Disabled. Ora
eseguite il programma (F9). Noterete che Olly non si fermato al nostro BP perch stato disattivato.

Hardware Breakpoints

Un hardware breakpoint utilizza i registri di debug della CPU. Ci sono 8 di questi registri integrati nella CPU, R0-R7.
Anche se ci sono 8 built into the chip, possiamo utilizzarne solo quattro. Questi possono essere utilizzati per breaking
on reading, scrivere o eseguire una sezione di memoria . La differenza tra hardware e software breakpoints che
l'hardware BP non modifica la memoria del processo, quindi possono essere pi affidabili, specialmente in caso di
programmi che sono packed o protetti. possibile impostare un hardware breakpoint facendo clic destro sulla riga
desiderata, selezionando Breakpoint, e poi scegliendo Hardware, on execution:
L'unico modo per vedere i BP impostati in memoria quello di selezionare "Debug" e poi "Hardware Breakpoints".
Fortunatamente c' un plugin che render questo processo molto pi rapido, ma di questo parleremo in seguito

Memory Breakpoints

A volte potreste trovare una stringa o una costante nella memoria del programma, senza per sapere in quale parte
venga utilizzata. Utilizzando un memory breakpoint, comunichiamo a Olly che il nostro desiderio quello di mettere
in pausa ogni volta che QUALSIASI istruzione nel programma legge o scrive all'indirizzo di memoria (O gruppi di
indirizzi.) Ci sono tre modi per selezionare un memory breakpoint:

Per un'istruzione, fate clic destro sulla riga desiderata e selezionate Breakpoint->Memory, On Access o Memory, On
Write.
Per impostare un BP su un indirizzo nel dump della memoria, evidenziate uno o pi byte nella finestra dump , fate clic
destro su di essi e scegliete la stessa opzione di sopra. anche possibile impostare un BP per un'intera sezione di
memoria. Aprite la finestra Memory (Icona Me o View->Memory), tasto destro del mouse sulla sezione della
memoria che si desidera, tasto destro del mouse e selezionate Set Break On Access for either Access or Write".

Uso del riquadro Dump


possibile utilizzare il riquadro del dump per ispezionare il contenuto di qualsiasi locazione di memoria nello spazio
di memoria del processo di debug. Se un'istruzione nella finestra di disassembly, un registro, o un qualsiasi elemento
nello stack contiene una reference a una locazione di memoria, potete fare clic destro su questa reference e selezionare
Follow in Dump e il pannello del dump vi mostrer la sezione dell'indirizzo. anche possibile fare clic destro in
qualsiasi punto del riquadro dump e selezionareGo To per inserire un indirizzo da visualizzare. Proviamolo.

Assicuratevi che FirstProgram venga caricato e messo in pausa all'inizio. Ora, premete F8 otto volte e vi trovere
sull'istruzione all'indirizzo 401021 that says CALL FirstPro.40102c. Guardando questa linea, noterete che questa call
sta per saltare gi all'indirizzo 40102c, which happens to be 3 lines down from where we currently are. Premete F7 per
fare step in nel salto e ci ritroveremo a questo indirizzo: 40102c. Ricordate che questa un'istruzione CALL, quindi
alla fine torneremo a 401021 (o almeno all'istruzione dopo questa).

Ora fate lo step del codice (F8) fino ad arrivare all'indirizzo 401062. Si pu anche semplicemente impostare un
breakpoint su questa linea e premere F9 per eseguirla. Ricordate come si imposta un breakpoint? Doppio clic nella
colonna opcode nella linea sulla quale si desidera impostare il BP. ( anche possibile evidenziare la riga e premere F2
per mettere il BP on e off ). Ora siamo in pausa all'indirizzo 401062:

Ora, diamo un'occhiata alla linea nella quale ci siamo soffermati. L'istruzione MOV [LOCAL.3], FirstPro.00403009.
Sono certo che voi sapete (perch avete studiato il linguaggio assembly :P ) che questa istruzione muove qualsiasi
cosa ci sia all 'indirizzo 00403009 nello stack (which Olly references as LOCAL.3). Potete vedere come nella colonna
dei commenti that Olly has discovered that at this address is the ASCII string MyMenu. Bene, diamo uno sguardo.
Fate clic destro sull'istruzione e selezionate "Follow in Dump". Noterete di avere a disposizione un paio di opzioni:

In questo caso, selezionate Immediate Constant. Questo carica qualsiasi indirizzo interessato nelle istruzioni. Se
aveste scelto Selection, la finestra di dump avrebbe mostrato l'indirizzo della riga evidenziata, in questo caso 401062
(la linea in cui ci siamo soffermati). We would basically just be looking at a dump of what we were looking at in the
disassembly window. Infine, se avessimo scelto Memory address, il dump screen avrebbe mostrato la memoria per
LOCAL.3. Ci in effetti mostra la memoria per le variabili locali con la quali stavamo lavorando (nello the stack).
Ecco, questo come il dump appare dopo aver selezionato "Immediate Constant":
Come potete vedere,il dump ora mostra la memoria a partire dall'indirizzo 403009, che l'indirizzo dell'istruzione Olly
was loading the ASCII string from. Sulla destra, potete vedere la stringa, MyMenu. Sulla sinistra, potete vedere
l'hex attuale per ogni carattere. Potete notare come dopo "MyMenu" ci siano alcune stringhe aggiuntive. Queste
stringhe verranno utilizzate in altre parti del programma.

Finalmente qualcosa di divertente!

Per terminare questa parte del tutorial, facciamo qualcosa di divertente. Cerchiamo di modificare il file binario per
visualizzare un messaggio a nostra scelta! Cambieremo la stringa Dialog As Main con qualcosa di nostro e poi
vedremo cosa succede.

In primo luogo, fate clic sulla "D" di Dialog As Main nella sezione ASCII della finestra dump:

Noterete che la prima cifra esadecimale anche evidenziata a sinistra. Questa cifra corrisponde alla lettera "D". Se
guardate in alto sul grafico ASCII vedrete che l'hex per la lettera "D" 044. Ora, fate clic e trascinate per selezionare
l'intera stringa Dialog As Main:

Ora, fate clic sul tasto destro del mouse in qualsiasi punto della selezione e scegliete Binary -> Edit. Questo ci
permette di cambiare il contenuto della memoria del nostro programma:

Dovremmo vedere una schermata simile a questa:

Il primo campo ci mostra la nostra stringa in ASCII. Il secondo l'Unicode (che questo programma non usa, perci il
campo vuoto) e l'ultimo campo per i raw data relativi a questa stringa. Ora, cambiamoli. Cliccate sulla prima lettera
("D") e digitate qualsiasi cosa desideriate sopra la parte superiore della stringa Dialog As Main. Ma fate attenzione a
non aggiungere pi lettere rispetto alla stringa originale! Potreste sovrascrivere le altre stringhe di cui il programma
necessita, o peggio, parte di codice necessario al funzionamento del programma!! Nel mio caso, ho digitato Program
R4ndom:

Ora fate clic su OK ed eseguite l'applicazione (fate clic all'interno di Olly e premete F9). Spostatevi sul programma,
digitate qualcosa e selezionate Options -> Get Text. Ora guardate la finestra di dialogo!!

Notate qualcosa di diverso nel titolo?

-Alla prossima

R4ndom

Link al tut originale : http://octopuslabs.io/legend/blog/archives/115.html

Traduzione a cura di Gmarksa.