MINI CORSO DI ASSEMBLER 8086

(tratto dal sito:http://www.giobe2000.it/Tutorial/Indice/Home.asp)
(versione dell' 8 gennaio 2010 - rev: 03/07/2012)

IL DEBUG DEL DOS

Nel linguaggio comune un bug è una cosa fastidiosa, un pidocchio, una cimice, una calamità. Gli anglosassoni sono molto immediati nel definire i concetti e spesso associano ad eventi tecnici un'immagine forte e molto colorata; così un errore di programmazione diventa un bug e lo strumento che consente di localizzare ed eliminare i bug è diventato Debugger, lo "spulciatore".

Se l'assemblatore ha ritenuto corretta la sintassi del sorgente e il linker ha generato senza errore l'eseguibile non è detto che il nostro programma "giri" come ci aspettiamo. Al contrario, sono spesso gli errori di concetto (semantici) che si manifestano di solito con devastante arroganza, bloccando tutto il computer e costringendoci a resettarlo (premere il pulsante di reset o chiudendo l'applicazione con Ctrl-Alt-Canc). Sono i cosiddetti errori di run-time.
In questi casi il modo migliore per capire dove abbiamo sbagliato è ricompilare il sorgente inserendo dei break-point, cioè dei punti in cui il programma è costretto a fermarsi.

I break-point di solito si fissano inserendo nel punto desiderato l'istruzione INT 03H (ricorda bene questo metodo!!); la loro presenza è del tutto irrilevante nell'esecuzione normale di un programma, ma se l'eseguibile è fatto girare sotto DEBUG esso si fermerà proprio nel punto previsto, consentendo l'esecuzione passo-passo delle successive istruzioni, consentendo la localizzazione di quella che ha creato l'errore run-time.

Dunque nella fase di collaudo e messa a punto (tuning) di un programma il Debug è uno strumento di lavoro particolarmente utile. Il debug(ger) si occupa del caricamento in memoria dell'eseguibile, in modo paragonabile a quello del loader del sistema operativo e, dopo aver preparato i puntatori (CS:IP) sulla prima istruzione  e (SS:SP) sulla prima locazione dello stack  cede il controllo a noi, manifestando la sua disponibilità con un trattino posto sulla riga successiva all'intestazione.

Con il Debugger è possibile aprire ed eseguire qualunque programma eseguibile. E' in grado di mostrarne il codice dissassemblato (molto vicino a quello sorgente originale) ed è facile scorrerne il contenuto, per cercare di capire o scoprire i trucchi del suo autore. (è quello che fanno i "crackatori" di professione).

Dopo essere entrati in Debug il comando ? mostra l'elenco dei comandi disponibili (tutti i comandi si danno digitandone la lettera corrispondente dopo il prompt del debug, cioè dopo il trattino).
Il Debug.exe in dotazione con il Dos (generalmente in c:\windows\system32) mostra questo help:

Il programma Debug è particolarmente utile quando apre e gestisce un determinato file. Per far questo basta digitare nella finestra DOS la scritta debug <nomeeseguibile>. Vediamo un esempio:

Va sottolineato che è possibile caricare un file anche senza specificarne il nome subito dopo il comando debug. Lo si può fare digitando 2 comandi (L e N <nomefile>) sul prompt del debug stesso:

Dopo aver digitato  N nomefile.ext ed aver confermato con Invio non sembra succedere niente; in realtà il gestore viene avvisato che dovrà cercare un programma con nome nomefile ed estensione ext.
Tramite il comando L (load), confermato da Invio, il debug è costretto a cercare il file e a caricarlo in memoria; solo se non lo trova segnalerà errore (File not found o Impossibile trovare il file).

Il DEBUG è uno strumento dedicato all'analisi del processore (i suoi registri) e della memoria e quindi ogni numero da esso presentato va inteso nella lingua del processore cioè in esadecimale e quindi è importante ricordare fin d'ora che i numeri esadecimali si possono trattare senza la "h" con DEBUG.

Il comando per uscire è Q (quit). Ogni operazione svolta fino a quel momento viene persa irrimediabilmente (dopotutto siamo in ram) e il controllo viene ceduto di nuovo al sistema operativo.

Cominciamo con il comando D (dump). Scriviamo quindi debug e poi il comando d

Analizziamo la videata ottenuta: sono 8 righe così strutturate:
- la parte di sinistra (in verde) mostra l'indirizzo segmentato della prima locazione di memoria che andremo ad ispezionare: il puntatore è in esadecimale.
- la parte centrale (in bianco) elenca il contenuto di 16 locazioni (byte) consecutive, a partire da quella indirizzata nella parte a sinistra espresso in esadecimale.
- la parte di destra (in giallo) cerca di tradurre in forma Ascii il contenuto delle medesime locazioni.

Nella zona verde abbiamo:
- l'indirizzo di segmento che è, per tutte le righe visualizzate, sempre lo stesso (nell'esempio 166C): il suo valore dipende esclusivamente da quello della prima zona di ram libera al momento del caricamento del debugger in memoria; questo ultimo riserva ai nostri esperimenti un intero segmento che comincia proprio da 0166C:0000.
- l'indirizzo di offset iniziale è 0100: il suo valore risente del fatto che Debug ha riservato per se stesso le prime 256 locazioni, per ospitare, nella logica dei programmi gestiti dal Dos, il proprio PSP [acronino di prefisso di segmento di programma]).
La zona bianca contiene la traduzione esadecimale di quello che debug ha effettivamente trovato: il loro valore è assolutamente imprevedibile e generalmente può essere cambiato in ogni momento, senza provocare alcun danno, come vedremo nelle prossime pagine.
La zona gialla contiene i caratteri Ascii corrispondenti ai valori esadecimali visualizzati nella parte centrale. Tutti i bytes che corrispondono a caratteri Ascii stampabili sono mostrati in chiaro per quello che sono, mentre tutti gli altri (da 00H a 1FH: caratteri di controllo - da 80H a FFH: caratteri ascii estesi) sono visualizzati con un punto.

Se il comando D viene dato di nuovo, viene mostrata a video la successiva "cestinata" di 128 bytes, e così ad oltranza.

Specificando l'indirizzo desiderato ci viene offerta la possibilità di verificare concetti ed idee maturate in altri ambiti di studio; per esempio possiamo verificare se la ram del video (modo testo) è effettivamente costituita da bytes alternati di carattere (ascii) e di colore (attributo).
Per verificarlo occorre pulire il video con il comando dos CLS e successivamente aprire il programma debug. Digitare il comando D seguito dall'indirizzo dell'area dedicata alla modalità testo ovvero B800:0000:

La prima sequenza di 8 righe ci dice che le prime 128 locazioni contengono 64 coppie consecutive di bytes 20h/07h. I primi 160 bytes (in figura su sfondo grigio) sono relativi alla prima riga del monitor che come si nota è vuota [in realtà sono spazi  (=20h) con colore bianco su sfondo nero (=07h)].  Le prime coppie diverse da 20h/07h sono visibili a partire dal 161° bytes (indirizzo B800:00A0) relativi alla 2° riga. La sequenza esadecimale 43 07 3A 07 5C 07 74 07-72 07 61 07 6E 07 73 07 3E 07 64 07 65 07 62 07-75 07 67 07 corrisponde alla stringa a video C:\trans>debug.

Un altro esempio di analisi della memoria è quello sottostante che mostra come visualizzare la data del BIOS.

Il comando F (FILL, riempi) nella prima sintassi si aspetta l'intervallo di indirizzi (espresso come Segmento:Offset) iniziale e finale (nell'esempio sottostante 100h e 17Fh) e la sequenza di valori da inserire. Bisogna stare attenti a non esagerare: se si cancellano le locazioni sotto l'indirizzo 005C oppure sopra E000 (valore indicativo) il debug potrebbe "piantarsi".

Il comando F è particolarmente versatile: il suo terzo parametro può essere di diverso tipo. Infatti la memoria può essere riempita con:
- singoli bytes,
- sequenze di bytes,
- caratteri Ascii  (delimitati da '),
- stringhe Ascii di qualunque lunghezza (delimitate da ').

Come in altri comandi del debug, il range degli indirizzi da coinvolgere può essere passato anche sotto forma di indirizzo iniziale e lunghezza (espressa con una L seguita dal valore esadecimale corrispondente al numero di locazioni da riempire [quindi occorre scrivere lA se si desiderano sovrascrivere 10 byte]). Vediamone un esempio:

Se i valori presenti in memoria sono particolarmente significativi può essere necessario confrontarli tra loro, sebbene questo evento sia poco probabile.

Il comando C (COMPARE, confronta) si aspetta 3 indirizzi (espressi come segmento:offset): quello iniziale e finale relativo alla prima area e quello iniziale della seconda area. Se le 2 aree di memoria contengono gli stessi bytes non viene mostrato alcun valore;

Naturalmente è possibile passare anche degli indirizzi completi (cioè con il valore del segmento). Se l'indirizzo specificato contiene solo l'offset i dati visualizzati si ritengono appartenenti al segmento puntato da DS (data segment);

La sintassi del comando C prevede come al solito 2 modi, sostanzialmente uguali. Il comando può essere dato passando l'indirizzo iniziale della prima area e la lunghezza (espressa con una L seguita dal valore esadecimale corrispondente al numero di locazioni da confrontare) seguito dall'indirizzo iniziale della seconda area:

Il comando M (MOVE, muovi) si aspetta 3 indirizzi (espressi come segmento:offset): quello iniziale e finale dell'area in cui sono contenuti i bytes da copiare e quello iniziale dell'area in cui si desidera copiarli.

Quindi più che di uno spostamento si tratta di una copia, dato che i bytes coinvolti saranno ancora presenti nelle locazioni sorgente. Vediamo un esempio

Il comando può essere anche dato passando l'indirizzo iniziale della prima area e la lunghezza (espressa con una L seguita dal numero esadecimale delle locazioni da copiare - ad esempio L10 per copiare 16 byte) seguito dall'indirizzo iniziale della seconda area:

Il comando S (SEARCH, cerca) si dimostra spesso utile, non tanto per cercare stringhe, per le quali è perfettamente abilitato, ma soprattutto per cercare determinate sequenze di bytes; l'esperienza dimostra che con esso è possibile trovare tutti i punti di un programma in cui viene, per esempio, chiamata una certa procedura di sistema.
Come è noto ogni istruzione è codificata con uno o più bytes: di solito un codice operativo ed un operando; a forza di ficcare il naso nei programmi eseguibili con il buon vecchio debug non ci vuole molto tempo per imparare i principali accoppiamenti tra istruzioni e relativi bytes.
Così, per esempio, può essere utile sapere in quali punti di un dato programma abbiamo l'istruzione INT 21H (servizi DOS) corrispondente alla coppia di byte: CD 21. Basta quindi utilizzare questo comando seguito dall'indirizzo iniziale e finale (espressi come segmento:offset) e dalla sequenza di bytes da cercare.
L'immagine seguente mostra il risultato della ricerca in una zona di memoria in cui è stato caricato il programma putciao.com che usa questa istruzione 4 volte: 

Se la sequenza di bytes cercata non viene trovata il comando non produce effetto: (vedi ultimo comando del riquadro precedente).
Il comando S è particolarmente versatile: il suo terzo parametro può essere di diverso tipo: infatti oltre alle sequenze di bytes possono essere cercate anche stringhe Ascii di qualunque lunghezza. La cosa è particolarmente utile quando si deve trovare, per esempio, la zona dei messaggi di un dato programma. Dagli esempi si evince che la ricerca per stringhe non è case sensitive e che non si può effettuare la ricerca in una zona di memoria superiore a 64K

Il comando E (ENTER, inserisci) consente di modificare il contenuto di una o più locazioni di memoria a partire dall'indirizzo (espresso come segmento:offset) passato come primo parametro; dopo di esso possono essere scritti uno o più valori esadecimali, separati da spazi o da virgole. Non appena il comando così strutturato viene confermato con Invio il primo valore va a sostituire quello della locazione indicata nel comando, il secondo sostituisce il contenuto della locazione successiva, e così via...

Il comando E può essere dato anche senza la sequenza di bytes. Questo metodo consente di modificare il contenuto della ram in modo più sicuro del precedente.
Infatti digitando E <indirizzo> e confermando con Invio viene mostrato l'indirizzo specificato seguito dal suo contento originale in esadecimale e da un punto. Se si digita un valore esadecimale esso andrà a sostituire quello visualizzato a sinistra. A questo punto possiamo seguire una delle due modalità possibili:
- se si preme il tasto Invio il processo di modifica viene confermato e riappare il prompt del debug (il trattino).
- se invece si preme lo spazio appare il contenuto della locazione successiva seguito ancora da un punto e il processo può continuare con le stesse modalità; i nuovi valori digitati andranno a sostituire i vecchi non appena si deciderà di dare la conferma finale (sempre con la pressione del tasto Invio).

Da notare che, se si conferma il byte mostrato con spazio senza aver digitato alcun numero sostitutivo, il byte originale non subisce variazioni, ma è ancora possibile intervenire sui valori successivi (sempre in attesa di confermare le eventuali modifiche con la pressione finale del tasto Invio):

Il comando R (Register, registri) senza parametri mostra il contenuto dei registri (a 16 bit) del processore; naturalmente si tratta di una simulazione o meglio del valore che avrebbero i registri CPU prima di cominciare l'esecuzione del programma.

Facciamo delle considerazioni in merito ai valori iniziali nei registri:

- I registri comuni (quelli utente AX, DX, e quelli indice DI e SI, con BP) hanno sempre un valore iniziale pari a 0000H. La cosa è ragionevole poiché il DEBUG simula le condizioni ottimali. Sebbene non sia indispensabile è bene pensare di iniziare l'esecuzione di un programma con i registri "puliti".

- Quando il comando DEBUG è eseguito senza argomenti abbiamo che:
> i registri CX e BX contengono il valore 0000h.
> i registri di segmento (CS, DS, SS e ES) hanno tutti lo stesso valore. Questo valore non è prevedibile e dipende esclusivamente dall'indirizzo della prima locazione libera in memoria nel momento in cui debug è stato allocato dal loader del dos.
> il puntatore di stack (SP) ha sempre un valore piuttosto elevato FFEEH.
> il puntatore di istruzione (IP) sarà lasciato sempre a 0100H. Abbiamo più volte sottolineato che il loader del Dos vuole per sè le prime 256 locazioni, per il Prefisso di Segmento di Programma (PSP)

- Quando il comando DEBUG è eseguito con un argomento relativo ad un eseguibile di tipo .com abbiamo che:
> i registri BX e CX vengono impostati con la dimensione in byte del file caricato. Il file di esempio (vedi figura successiva) video.com occupa 37 byte (25h in esadecimale) ed infatti BX=0000h e CX=0025h.
> i registri di segmento (CS, DS, SS e ES) hanno tutti lo stesso valore. Del resto i file .com sono monosegmento;
> il puntatore di stack (SP) ha sempre un valore piuttosto elevato FFFEH, solo 2 locazioni sopra la fine del segmento.
> il puntatore di istruzione (IP) è impostato a 0100H, esattamente come avviene nella realtà quando il programma sotto test è eseguito da solo senza la tutela del debugger.

- Nel caso il comando DEBUG presenti come argomento il nome di un eseguibile di tipo .exe abbiamo che:
> i registri BX e CX vengono impostati ad un valore correlato con la dimensione in byte del file caricato. Occorre ricordare che la parte di intestazione (header: pari a 512byte) di un exe (è usata dal loader per il caricamento del programma stesso) non contiene codice eseguibile e pertanto non viene caricata dal debugger. Prendendo come esempio il file ml.exe (vedi figura successiva) notiamo che la quantità di byte effettivamente caricata è la dimensione del file meno quella relativa all'header. Calcoli alla mano abbiamo quindi: 385.072 byte - 512 byte = 384.560 che in esadecimale è 5 DE30h e che corrisponde ai valori visibile nei registri BX e CX).
> I registri di segmento (CS, DS, SS e ES), il puntatore di stack (SP) e di istruzione (IP) sono impostati in base alle direttive indicate nell'header. L'intestazione di un programma EXE occupa almeno 512 bytes del programma EXE. Esistono alcune utility in grado di metterne in chiaro il contenuto dell'header. Una di queste è ExeMod distribuita con il pacchetto MASM.

Vediamo ulteriori esempi:

Di solito il comando R è utile per modificare il valore di un registro; per questo è necessario far seguire al comando la sigla del registro desiderato. Non appena si conferma con Invio viene proposto il vecchio valore e, sulla linea successiva, appare il segno dei 2 punti, dopo il quale è possibile digitare il nuovo valore, da confermare ancora con Invio:

Il comando R è usato ogni volta che si desidera ricominciare l'analisi e il collaudo di un programma. Infatti è necessario obbligare il processore a puntare sulla prima istruzione: non è dunque possibile fare a meno del comando R IP seguito dal valore 0100 (nel caso di un eseguibile COM)!

Una trattazione a parte merita la visualizzazione del registro dei flag. E' visualizzato in forma interpretata (zona gialla della figura precedente), cioè al posto dei bit significativi viene mostrata la sigla del valore attuale del flag corrispondente, in accordo con la seguente tabella:

Il comando L (LOAD, carica) carica in memoria un file di qualunque tipo; di solito viene dato senza parametri, dopo aver specificato il nome (con l'eventuale percorso) mediante il comando N, già visto in precedenza. Il file viene sistemato in memoria rigorosamente a partire dall'indirizzo CS:0100H (ad esclusione dei file EXE che vengono rilocati all'indirizzo indicato nel suo Header).

Il file caricato in memoria può essere di qualunque tipo (di testo TXT, di dati DAT, eseguibile COM o EXE) sebbene la potenza di debug sia meglio evidenziata nella gestione dei files eseguibili.
Se, dopo il comando L, è specificato un indirizzo (offset) esso rappresenta la locazione a partire dalla quale viene caricato il file; naturalmente questo ha senso solo se il file è diverso da EXE: infatti questa tipologia di file viene sempre  rilocata all'indirizzo specificato nel suo header!
Se l'indirizzo specificato è solo quello di offset i dati visualizzati si ritengono appartenenti al segmento CS.
Non dimenticare che, dopo la copia del file è disponibile un numero a 32 bit che esprime la quantità di bytes caricati in memoria, lasciato nella coppia di registri BX,CX, rispettivamente parte alte e parte bassa. Si noti che nell'esempio CX vale 407h che corrisponde alla dimensione del file prova.com pari a 1031 byte.

Il comando L (LOAD, carica) è spesso utile anche per caricare in memoria uno o più settori di una memoria di massa (hard disk o floppy disk).
In questo caso la sintassi è :

Dove:
- l'indirizzo [[CS]:offset] è dove travasare i bytes letti sul disco (le [] indicano l'opzionalità)
- IDDisco è un numero che indica il disco da cui prendere i dati:
    0 per il drive A,
    1 per il drive B,
    2 per il drive C, e cosi via...
- NrPrimoSettore indica il numero logico di settore del primo settore da caricare dal disco appena indicato;
- QuantiSettori indica il numero di settori da caricare; non è possibile leggere più di 80 settori, pari a 40k di memoria.

Vediamo che cosa si intende per numero logico di settore (LBA). Precisiamo che il settore è l'unità minima di informazione che può essere letta o scritta e varia, a seconda della capacità del disco, da 32 a 4096 byte (di solito sono 512). Si tratta di una numerazione progressiva che parte da 0 e raggiunge un valore massimo dato dalla seguente espressione: (N°Settori per Traccia) x (N°Tracce) x (N°Lati). La numerazione dei settori logici parte dal primo settore fisico (master boot record) e prosegue in sequenza sulla medesima traccia (Cylinder) del lato (Head) corrente. Si prosegue poi lungo tutte le tracce dello stesso cilindro passando prima sul lato opposto e poi su quelli successivi fino all'esaurimento di tutti i settori del cilindro più esterno. Si continua spostandosi sul cilindro interno adiacente e si ripete così il procedimento fino all'ultimo settore dell'ultima traccia dell'ultimo cilindro. Questo modo logico di numerare i settori di un disco è tipico del DOS ed è diverso da quello assoluto/fisico usato dal BIOS e costituito dalla terna di numeri detta sinteticamente CHS (Cylinder, Head, Sector). Così, per esempio, il primo settore fisico, il boot record, identificato dal numero CHS 0,0,1, corrisponde al settore logico 0. La numerazione logica dei settori da parte del DOS è estremamente efficace perché consente al Sistema Operativo di accedere a qualunque disco, indipendentemente dalle sue caratteristiche hardware.

La formula che lega la numerazione fisica (CHS (cylinder-head-sector) o BIOS) a quella logica (o DOS) è la seguente:

LBA = (S-1)+(H*k)+ C*k*f dove f è il numero di testine e k il nr di settori per traccia

La numerazione logica dei settori da parte del DOS è, per altro, estremamente efficace perché consente al Sistema Operativo di accedere a qualunque disco, indipendentemente dalle sue caratteristiche hardware.

La possibilità di leggere interi settori di un disco è senza dubbio una funzionalità di straordinaria potenza. Sebbene non comporti grandi rischi conviene agire con discrezione, sicurezza e competenza.

Il comando L, della figura, carica a partire dall'indirizzo 1000h, dal disco 2 (driver C) partendo dal settore n°0 (il primo) 1 solo settore (cioè 512 bytes). Nella figura successiva si può notare che la lettura diretta dell'Hard Disk non è permessa nei sistemi WIN recenti.

Il comando W (WRITE, scrivi) permette di creare un file (o di sovrascriverlo, se già esiste) nella cartella corrente del disco; di solito viene dato dopo aver specificato il nome (e l'eventuale percorso) del file con il comando N, già visto in precedenza. La sintassi in questo caso è la seguente:

Se l'indirizzo specificato è solo quello di offset i dati da scrivere si ritengono appartenenti al segmento CS.

Quando si usa il comando W per salvare il nostro lavoro in un file sul disco non bisogna dimenticare di caricare nei registri BX e CX la parte alta e bassa del numero a 32 bytes che indica la quantità di bytes da salvare!!

Il modo più semplice per calcolare il numero da mettere in BX,CX consiste nel prendere l'indirizzo di offset della locazione successiva all'ultima istruzione digitata e sottrarre da esso il numero 0100h.

Ad esempio se, abbiamo prodotto una codice eseguibile di 24 bytes, quando salviamo su disco dobbiamo eseguire, in sequenza, tutte queste operazioni:
- dare un nome al file da creare (o sovrascrivere)  tramite il comando N
- scrivere in BX il valore 0000H e in CX il valore 0018H (esadecimale di 24)
- finalmente confermare il salvataggio con il comando W:

Il comando W (WRITE, scrivi) è complementare al comando L, usato per caricare in memoria uno o più settori di una memoria di massa (hard disk o floppy disk); Quindi W serve anche per fare l'operazione opposta ovvero per scrivere direttamente un settore di disco.

La sintassi in questo caso è:

Dove:
- l'indirizzo [[CS]:offset] è dove prelevare i bytes da riversare sul disco (le [] indicano l'opzionalità)
- IDDisco è un numero che indica il disco da cui prendere i dati:
    0 per il drive A,
    1 per il drive B,
    2 per il drive C, e cosi via...
- NrPrimoSettore indica il numero logico di settore del primo settore da sovrascrivere del disco appena indicato;
- QuantiSettori indica il numero di settori da scrivere; non è possibile scrivere più di 80 settori, pari a 40k di memoria.

L'esempio successivo mostra come scrivere su un floppy 2Kb (4 settori da 512 byte) attualmente presenti a partire dall'indirizzo CS:1000H; il primo settore da sostituire è il 64h (valore esadecimale pari al decimale 100d) :

Il comando U (UNASSEMBLE, disassembla) ha senso solo dopo aver specificato il nome di un file eseguibile (con il comando N)  e averlo caricato in memoria (con il comando L), magari dopo aver pulito la memoria chiamata ad ospitarlo (con il comando F). Se viene dato senza parametri inizia a tradurre i bytes presenti in memoria a partire dall'indirizzo CS:0100H; il segmento di default è ovviamente quello del codice: CS.
E' facile capire la potenza di questo comando: con esso si possono analizzare le istruzioni di qualunque file eseguibile, in primis quelli da noi prodotti, in fase di messa a punto o di ricerca delle rogne.
Naturalmente la "traduzione" in chiaro di un sorgente non è priva di intoppi e malizie: è il prezzo che bisogna pagare all'esperienza e al colpo d'occhio.

Il comando U prova comunque a tradurre in assembly i bytes che trova; se per qualche ragione il programma contiene tabelle, dati o messaggi (cosa estremamente probabile!) il risultato sarà del tutto illogico, cioè verranno mostrate sequenze di istruzioni assurde e scorrelate. Bisogna quindi saper localizzare le aree dati di un programma, escludendole dall'indagine con U a beneficio di quella effettuata con il comando D.

Consideriamo a titolo d'esempio il seguente file sorgente:

.MODEL tiny
.code
   ORG 100H
INIZIO:  MOV AH,00H  ; Pulisci lo schermo
         MOV AL,03H  ; (ClearScreen)
         INT 10H   
         MOV AH,00H  ; Aspetta la pressione
         INT 16H     ; di un tasto
         INT 20H     ; Torna al dos
END INIZIO

Creiamo il file eseguibile utilizzando il macro assembler ML con il comando ML /AT CLSKEYP.ASM.

Disassembliamo il file .com così ottenuto:

Osserviamo con calma l'output del comando U:
- la pressione di U (ed ogni altra successiva) coinvolge almeno 16 bytes di memoria (nell'esempio al primo U 32 byte). L'indirizzo della locazione (se non specificato) è sempre dato dal valore corrente di CS:IP.
- I bytes di ciascuna riga visualizzata appartengono ad una ben precisa istruzione, ad insindacabile giudizio del debugger. Per ogni riga mostrata sono resi disponibili:
    > l'indirizzo logico (CS:Offset corrente) del primo dei bytes coinvolti.
    > la sequenza dei bytes associati all'istruzione riconosciuta; di essi il primo è certamente un codice operativo.
    > la loro interpretazione mnemonica:
- Il processo continua per tutti i bytes coinvolti, anche per quelli che non appartengono più al programma caricato in memoria; lo si può notare nelle ultime righe ottenute con la prima esecuzione del comando U dell'esempio precedente dove il codice, del tutto improbabile e illogico, non corrisponde più al sorgente che abbiamo compilato.

In certi casi è conveniente passare 2 parametri, l'indirizzo iniziale e il numero (preceduto da una L) di byte, in esadecimale, da dissassemblare. Conoscendo la lunghezza del programma è possibile quindi evitare la visualizzazione di istruzioni fasulle.
Vediamo un esempio di utilizzo mediante un file batch. Si consideri il seguente file di testo disasm.txt e l'eseguibile clskeyp.com che abbiamo appena creato. Poiché l'eseguibile è composto da 12 byte inserisco, dopo il parametro L, la rappresentazione esadecimale di 12 ovvero: C.

u 100 Lc
q

(ricordarsi l'invio finale)

Eseguiamo la sequenza di comandi qui sotto

Il file testuale ottenuto contiene la sequenza di istruzioni assembler del nostro programma. Chiaramente per poter svolgere questa operazione correttamente è necessario modificare DISASM.TXT in modo che sappia distinguere l'area codice (su cui applico U) dall'area dati dove devo usare il comando D.

Il comando A (ASSEMBLY, assembla) permette la creazione di programmi eseguibili anche in ambiente debug; si tratta di un esercizio senza futuro, al limite della paranoia, poco pratico e piuttosto complesso; la logica dei debugger (per esempio quella di richiedere numeri esadecimali senza la H finale) rende questo esercizio addirittura controproducente.
L'avvertimento appena evidenziato è per sottolineare di evitare l'uso proprio di questo comando per creare programmi. Anche l'uso per effettuare piccole correzioni locali è assurdo: si fa prima a tornare in editor, correggere, ricompilare e rientrare in debug con la nuova versione dell'eseguibile.
Volendo trovare per forza una occasione utile possiamo pensare all'uso in una esercitazione sulla scrittura di istruzioni poiché l'assemblatore del debug (cioè il comando A) è in grado di riconoscere gli errori, se la stringa digitata non è corretta viene segnalato errore.
 

Vediamo dunque come si usa Assembly: non appena si conferma con Invio il comando A, sulla riga successiva appare l'indirizzo puntato da CS:IP. Nella posizione dove lampeggia il cursore dovremo scrivere il codice mnemonico di una istruzione, confermando ogni volta con Invio.
Solo quando riteniamo di aver finito bisogna premere l'invio 2 volte di fila: si torna così al prompt del debug (il segno meno, a sinistra).

La verifica con il comando U 100 L8 (figura qui sopra) dimostra che in memoria sono stati effettivamente allocati i bytes corrispondenti alle istruzioni che abbiamo digitato:
 

I comandi più importanti del debugger sono certamente quelli illustrati qui di seguito: la loro azione è rivolta decisamente al collaudo di un programma, cioè alla sua esecuzione controllata.
Se il tuo programma fa i capricci, basta forzare l'esecuzione fino ad un certo punto sicuro (comando G) e poi procedere a piccoli passi (comando T) evitando di eseguire (comando P) le procedure personali (riconoscibili dalla mnemonica CALL) o di sistema (attivate dall'istruzione INT).

Il comando T (TRACE, traccia) esegue una o più istruzioni; di solito viene usato senza parametri, al fine di eseguire l'istruzione corrente (cioè quella puntata da CS:IP); subito dopo visualizza automaticamente la nuova situazione dei registri e le informazioni relative all'istruzione cha verrà eseguita al prossimo step (indirizzo logico, codici associati e stringa mnemonica).
La tecnica utilizzata da questo comando è nota come esecuzione passo-passo.
Questo comando consente l'uso di 2 parametri, entrambi poco pratici:
- il primo consente di specificare l'indirizzo della prima istruzione da eseguire (esempio: T = 0112, notare il segno "uguale", mai usato finora); anche volendo far partire l'esecuzione da un certo punto intermedio del programma l'effetto potrebbe essere diverso da quello ottenibile nell'esecuzione passo-passo dall'inizio: verrebbe a mancare infatti l'influenza sui registri di tutte le precedenti istruzioni.
- il secondo parametro è rischioso, se usato con sufficienza o scarsa attenzione; consente di eseguire di seguito più istruzioni, semplicemente indicandone il numero dopo il comando T (esempio: T 12). Il rischio è di entrare dentro le procedure e perdere il filo del programma, specialmente se si entra in una INT di sistema.

Osserviamo con calma cosa ci fornisce il comando T. In particolare possiamo seguire i cambiamenti dei registri dopo l'esecuzione dell'istruzione corrente; per esempio l'azione della prima T (esegue MOV AH,09) cambia il valore nel registro AH (si vede chiaramente che AX diventa 0900h)
l'azione della terza T è una cosa inutile e sbagliata perché ci obbliga a entrare nel codice di una procedura di sistema (INT 10) di cui diamo per scontata l'esattezza; in questi casi bisogna dare il comando P.

Notare come l'azione della terza T abbia cambiato drasticamente il registro IP rispetto ai prevedibili cambiamenti imposti nei due primi trace. Anche il valore del registro di segmento ha assunto un valore diverso rimarcando il fatto che non siamo più dentro il nostro programma (o meglio nel segmento ad esso riservato dal debugger). L'indirizzo fisico è ora 0C965H (CS=0C52h IP=0445h => C520h+445h=C965h) , molto diverso da quel 17DB5h da cui siamo partiti (CS=17CBh IP=0105h => 17CB0h+105h=17DB5h).
Se per errore entriamo all'interno del codice di una INT è poi laborioso ritornare nel nostro programma: bisogna riportare sia CS che IP ai valori originali, sperando di non essere andati troppo avanti, cioè di non averli persi di vista irrimediabilmente. Pertanto in presenza di un istruzione INT occorre usare il comando P

 Il comando P (PROCEED, procedi) esegue un'intera procedura, di solito rappresentata dall'istruzione CALL xxxx  o INT xyH: nel primo caso xxxx è un sottoprogramma sviluppato con il codice eseguibile sotto test, normalmente allocato nel medesimo segmento di codice dell'istruzione CALL.  INT rappresenta la chiamata ad una procedura di sistema, sempre esterna al segmento del nostro codice.
 
Vediamo alcune allocazioni di sistema standard:
- una funzione BIOS trova posto nella parte più alta del primo mega di memoria, nell'area fisica che va dall'indirizzo F000H, a meno che non sia stata "rilocata" da programmi di gestione, come drivers o applicativi residenti in memoria. Capita spesso che la scheda video si appropri del vettore INT 10h, mappandone i servizi dentro la sua rom, a partire dall'indirizzo C0000H
- una funzione DOS è collocata nella parte bassa della memoria: un indirizzo verosimile è per esempio 0E000H
- una funzione speciale (per esempio quelle del mouse, attivate con INT 33H) è allocata in posizioni non molto distanti da quelle del DOS, per esempio a 11000H

Quindi le istruzioni INT xyH non vanno mai tracciate con il comando T, ma eseguite in blocco con il comando P; il loro debug può essere interessante solo a fini didattici o di auto-istruzione, per vedere come sono fatte.

Il comando G (GO, vai!) esegue tutto il programma; se viene dato senza parametri inizia l'esecuzione di tutto il  programma presente in memoria a partire dall'indirizzo CS:IP; il segmento di default è ovviamente quello di codice, CS. Nei file .com IP = 100h
Naturalmente l'esecuzione "diretta" (senza parametri) del programma non ha senso: per fare questo basta lanciare l'eseguibile dal prompt del Dos, senza scomodare il debugger.
Lo scopo di G è quello di eseguire in blocco un certo numero di istruzioni, per poi proseguire passo-passo con il comando T o con il comando P; per fare questo è sufficiente aggiungere un indirizzo dopo la G, confermando con Invio; il programma sarà eseguito fino al punto indicato.
 

La sequenza di azioni consigliata per la ricerca di malfunzionamenti è la seguente:
- scorro con il comando U il codice disassemblato e dopo aver annotato l'indirizzo xyH dell'istruzione successiva a quella fino alla quale voglio eseguire il programma digito il comando G xyH e confermo con Invio. Vediamo un esempio:

Questo comando consente anche di eseguire in blocco le istruzioni ripetute (quelle con prefisso REP) e le istruzioni gestite da LOOP: in questo caso può essere conveniente alternare questa possibilità a quella offerta dal comando T, più adatto per cercare e trovare imperfezioni durante l'esecuzione di queste procedure iterative.

Quando si utilizza il comando G occorre fare molta attenzione a specificare l'indirizzo corretto, altrimenti si rischia di mandare in crash il computer!!

Il comando H (HEX, esadecimale) calcola e visualizza contemporaneamente prima la somma e poi la differenza dei 2 numeri esadecimali forniti dopo il comando; entrambi non possono essere più grandi di 4 cifre (e vanno specificati ovviamente senza la H finale).  I risultati negativi sono espressi in complemento a 2. Vediamo alcuni esempi:

Il comando I (INPUT, ingresso) esegue la lettura della porta specificata dal parametro e mostra, sulla riga successiva, il valore esadecimale letto.

Il comando O (OUTPUT, uscita) spedisce un byte alla porta specificata dal primo parametro; il byte da trasmettere è passato come secondo parametro.