[Tuto] Debug

DEBUG

Ok, Debug c'est une antiquité dépassée, mais il présente 2 avantages pour le débutant.

1) On le trouve partout, et normalement y a pas besoin de le télécharger. Faut voir dans Windows\Command, ou un truc dans le genre. Pour ceux qui en aurait été privé (ou qui n'aurait pas trouvé debug.exe), cf la partie telechargement.

2) C'est simple à utiliser et ce programme offre quelques possibilités intéressantes par redirection des entrées/sorties du DOS.


Utiliser debug pour reinitialiser les options du bios

Pour un bios award
debug
-o 70 17
-o 71 17
-q

pour un bios phoenix
debug
-o 70 ff
-o 71 17
-q

Utiliser debug pour efffacer un mot de passe oublié

debug
-o 70 2 E
-o 71 ff
-q



Principales commandes

Lorsque Debug est prêt à recevoir des ordres, il le montre en affichant un signe moins.
Toutes les instructions sont monolettres, donc y a pas grand chose à retenir à chaque fois.
Y a aucune différence entre les majuscules et les minuscules, sauf dans les chaînes de caractères (logique). Debug affiche tous les chiffres en héxadécimal, et en format fixe. (on rajoute des 0 [zero]devant si nécessaire)

Pour quitter, on tape q (pour QUIT). La line de commande doit ressembler à ça:
-q

Pour voir le contenu de la mémoire, on tape d (pour DUMP)(le contenu sera différent chez toi) On obtient (version coupée en largeur):
-d
14FA:0100 00 00 00 00 00-00 00 00 00 00 ..........
14FA:0110 00 00 00 00 00-00 34 00 E9 14 ......4...
14FA:0120 00 00 00 00 00-00 00 00 00 00 ..........
14FA:0130 00 00 00 00 00-00 00 00 00 00 ..........
14FA:0140 00 00 00 00 00-00 00 00 00 00 ..........
14FA:0150 00 00 00 00 00-00 00 00 00 00 ..........
14FA:0160 00 00 00 00 00-00 00 00 00 00 ..........
14FA:0170 00 00 00 00 00-00 00 00 00 00 ..........
-
Le - signifie qu'il attend de nouveau tes ordres.

Qu'est-ce-qu'on voit ?

A gauche l'adresse du début de la zone inspectée, sous la forme segment:offset. La zone concernée fait 16 octets de longueur, chaque ligne en représente une.
Au milieu, le contenu de la zone, en 2 groupes de 8 octets séparés par un -. Les octets sont séparés les uns des autres par un espace.
Enfin, à droite, le contenu de la mémoire sous forme de caractères.

Remarque importante: les caractères affichés à droite ne correspondent pas toujours avec la valeur réelle des octets qu'ils sont censés représenter. Ainsi les 0 sont matérialisés par des points, mais le point n'a pas pour code 0. Pourquoi? Les caractères de 0 à 31 sont dits caractères spéciaux et ne sont pas imprimables.

Ceux de 128 à 255 font partie du jeu ASCII étendu, et ne sont pas reconnus par Debug.
Dans l'exemple précédent, seul le 4 a été exactement représenté.
Bon, suffit pour la représentation numérique, passons aux instructions. Debug permet de désassembler un programme, et d'assembler des instructions en direct.

Pour désassembler, on tape u (pour UNASSEMBLE):
-u
14FA:0100 0000 ADD [BX+SI],AL
14FA:0102 0000 ADD [BX+SI],AL
14FA:0104 0000 ADD [BX+SI],AL
14FA:0106 0000 ADD [BX+SI],AL
14FA:0108 0000 ADD [BX+SI],AL
14FA:010A 0000 ADD [BX+SI],AL
14FA:010C 0000 ADD [BX+SI],AL
14FA:010E 0000 ADD [BX+SI],AL
14FA:0110 0000 ADD [BX+SI],AL
14FA:0112 0000 ADD [BX+SI],AL
14FA:0114 0000 ADD [BX+SI],AL
14FA:0116 0000 ADD [BX+SI],AL
14FA:0118 0000 ADD [BX+SI],AL
14FA:011A 0000 ADD [BX+SI],AL
14FA:011C 3400 XOR AL,00
14FA:011E E91400 JMP 0135
-
V'la aut' chose! La série d'octets de l'exemple précédent s'est transformée en une liste d'instructions! Eh oui, ce que nous montre Debug, c'est qu'en assembleur instructions et données partagent la même mémoire, et qu'il vaut mieux faire la distinction. Cet exemple appelle 2 commentaires :

1) Les zéros ne sont pas innocents, et lancer l'exécution de cette séquence n'est pas anodine (voir la remarque su l'instruction NOP).

2) Certains programmes, et qui fonctionnent, contiennent des données au milieu de leurs instructions. Le hic, c'est que lorsqu'on tente de les désassembler, Debug ou même WinDAsm n'y voient que du feu. Et voilà une série d'instructions incongrues qui déboule. Heureusement, c'est pas trop dure de les repérer, un peu de bon sens permet de remarquer que c'est complétement idiot d'écrire 14 fois de suite la même instruction, mais gare aux cas vicieux.

Passons à la manipulation des registres.
Tapons r, et voyons ce qui sort:
-r
AX=0000 BX=0000 CX=0000 DX=0000
SP=FFEE BP=0000 SI=0000 DI=0000
DS=14FA ES=14FA SS=14FA CS=14FA
IP=0100 NV UP EI PL NZ NA PO NC
14FA:0100 0000
ADD [BX+SI],AL
DS:0000=CD

Debug est un programme DOS 16 bits, alors inutile de vouloir accéder aux registres 32 bits.

On a donc uniquement accés aux 16 bits. Décorticons ce bazar:

Debug affiche d'abord les registres de travail, puis ceux de la pile, pour finir avec les registres d'adresses. C'est tout pour la première ligne. Sur la deuxième, on trouve les registres de segments (et encore les quatre de base seulement), le pointeur d'instruction IP, et enfin les indicateurs. Suit la prochaine instruction à exécuter. donc Variante de la commande r: initialisation d'un registre
-r ip

IP 0100
:0123

-r
AX=0000 BX=0000 CX=0000 DX=0000
SP=FFEE BP=0000 SI=0000 DI=0000
DS=14FA ES=14FA SS=14FA CS=14FA
IP=0123 NV UP EI PL NZ NA PO NC
14FA:0123 0000
ADD[BX+SI],AL
DS:0000=CD

Ceci marche avec tous les registres.

Après avoir vu comment on désassemble des instructions, voit le contenu de la mémoire et des registres, intéressons-nous à l'assemblage en ligne. Pour ça, il faut taper:
-a
(pour ASSEMBLE, on s'en serait douté) Là, Debug affiche l'adresse où il commence à écrire en mémoire. On tape ses instructions, avec un >Entrée< entre chacune sinon,on se fait jeter. Après chaque instruction, l'adresse de la suivante s'affiche. Pour terminer, on appuie sur >Entrée<.
Et si on veut changer la valeur d'une variable? On place l'adresse dans CS:IP (donc on n'oubliera pas de les restaurer avec leurs valeurs originelles, sinon ça va partir en couille lors de l'exécution), on tape a, et comme instruction, on utilise DB ou DW. Debug se contente de placer en mémoire la valeur fournie en argument, sans poser de question.

Tracer un programme:

Une option intéressante pour les débutants, qui voudraient voir l'effet d'une instruction sans pour autant écrire un programme pour afficher le résultat à l'écran (dans les 200 lignes, donc à éviter sauf si on a une lib sous la main). On tape t (pour TRACE).
-t
AX=0000 BX=0000 CX=0000 DX=0000
SP=FFEE BP=0000 SI=0000 DI=0000
DS=14FA ES=14FA SS=14FA CS=14FA
IP=0123 NV UP EI PL NZ NA PO NC
14FA:0123 0000
ADD [BX+SI],AL
DS:0000=CD
-
L'instruction suivante affichée est celle qui sera exécutée. Le reste est classique et ne devrait plus poser de problème.

Utilisation avancée de Debug:

Les possibilittés de Debug sont très limitées, mais on peut les étendre quelque peu, en utilisant quelques astuces.

1) Utiliser la ligne de commande lors du lancement:
Debug peut inspecter la mémoire, et désassembler son contenu. On peut s'en servir pour y mettre ses créations, mais quand on l'aura fermé, tout aura disparu. A ma connaissance, il n'existe aucune commande de sauvegarde.
Par contre, on peut charger un fichier .exe ou .com (un format antédiluvien) en mémoire pour travailler dessus avec Debug. Pour cela, il faut taper (dans une fenêtre DOS):
C:\WINDOWS\COMMAND\>debug NomDuFichier.exe

Non seulement le fichier est chargé, mais CS et IP sont initialisés au début du programme.
Joli, mais bon, on ne peut toujours pas sauver son travail. C'est précisément la solution qu'apporte la seconde astuce.

2) Redirection de la sortie standart:
Sous DOS, il existe une fonctionnalité très pratique qui consiste à réaffecter les périphériques d'entrée et de sortie, et ce de façon transparente pour le programme qui tourne. Il suffit de taper:
C:\WINDOWS\COMMAND\>debug >FichierDeSortie
Et alors là, tout ce qui s'affiche normalement à l'écran est enregistré dans le fichier FichierDeSortie. Et voilà comment produire un dead listing avec Debug. Pour que ce soit intéressant, il faudrait pouvoir charger un fichier à désassembler.
Les deux astuces peuvent être utilisées en même temps. Si on tape:
C:\WINDOWS\COMMAND\>debug >FichierDeSortie NomDuFichier.exe
Voici ce qui se passe:

1) Le DOS interprète la commande. Il charge le programme Debug.exe en mémoire, puis analyse ce qui suit.

2) il rencontre le symbole < qui indique une redirection des sorties vers ce qui suit, ici un fichier dont on donne le nom. On peut aussi essayer LPT1: si on a une imprimante sur ce port (là on va imprimer les sorties du programme).

3) L'instruction de redirection étant destinée au DOS sans que le programme appelé ait à le savoir, le DOS transmet seulement la ligne de commande suivante à Debug lorsqu'il le lance: NomDuFichier.exe ... On connaît la suite.

Remarque importante:

Debug étant très primitif, il lit les caractères au clavier un par un puis les écrit à l'écran (enfin sur la sortie standart). Et alors? Quand on tape une commande et que l'on a redirigé la sortie, rien n'apparaît à l'écran, car tout est redirigé. Autant dire qu'il faut être sûr de soi et savoir où l'on va avant d'utiliser cette méthode.

Merci de votre attention !!