Salut kilo,
En fait ce qu'il faut bien comprendre, c'est que si l'on peut débugger les programmes eh bien c'est parce que l'Os nous laisse le faire.
Je vais essayer de vulgariser ça dans les très grandes lignes.
D'abord, tu l'auras compris, un programme c'est une suite d'instructions qui fait des calculs et manipule de la mémoire.
Pour ça il dispose principalement de sa mémoire justement, mais aussi de ses registres (eax, edx,
etc).
Comme effectuer des calculs sur de la mémoire est beaucoup plus lent que de manipuler des registres et que les processeurs x86 étant de type cisc n'en possèdent que très peu (des registres), et bien les programmes sont conçus de sorte à transvaser sans cesse des valeurs dans les registres le temps d'y effectuer des opérations puis de poursuivre.
Ensuite il faut savoir que l'exécution de chaque programme est constituée d'au moins un thread.
Chaque thread possède son propre contexte afin de permettre une execution parallèle.
Les registres, la pile, ainsi qu'un tas d'autres informations, constituent justement ce contexte.
Bon, une fois ça à l'esprit, voilà très grossièrement ce qu'il se passe lorsqu'un programme en debug un autre :
- Code: Tout sélectionner
A] Côté debugger :
- 1 / Le debugger demande à l'Os de lancer le debuggee en notant bien au passage que ce premier va debugger ce second
B] Côté Os :
- 2 / L'Os lance le programme en notant dans un coin qu'en cas d'exception le debugger est là
(Ensuite on boucle)
{
C] Côté debugger :
- 3 / Il attend que l'Os lui dise qu'il se passe quelque chose qui le concerne
D] Coté Os :
- 4 / L'Os exécute le programme
- 5 / Lorsqu'il rencontre un évènement qui déclenche une exception, il gèle tous les threads du programme et notifie le debugger qu'il se passe quelque chose en lui transmettant au passage des informations sur l'exception (type, etc), ainsi que le contexte du thread qui a déclenché la dite exception
- 6 / Il attend que le debugger lui dise qu'il a terminé de traiter l'exception
E] Côté debugger :
- 7 / Il fait ce qu'il veut de ces informations
- 8 / Il modifie éventuellement le contexte
- 9 / Il signale à l'Os que c'est bon il a fait tout ce qu'il voulait et qu'il peut reprendre l'exécution là où elle avait été interrompue (avec éventuellement un contexte modifié en étape 8)
}
Les exceptions se produisent lorsque quelque chose ne se passe pas comme prévu, c'est un 'bug', d'où le pourquoi on parle de debuggage.
Or les breakpoints (peu importe leur forme, cf
<ce post>) sont des exceptions particulières dont le seul but est de déclencher l'étape 5 à un endroit précis.
Lorsqu'il est en phase d'attente (étape 3), le debugger n'a absolument aucune idée de ce qu'il se passe dans le debuggee, d'autant plus que ça change constamment puisque le programme est en cours d'exécution ; d'où le pourquoi il ne peut rien t"indiquer.
Nb: S'il le souhaite, il peut toutefois décider à n'importe quel moment de se substituer à l'Os en réalisant lui-même l'étape 5 (c'est la pause), cependant le gèle aura lieu en l'état et donc à un emplacement non maitrisé.
Lorsqu'il est en phase de traitement d'exception (étape 7), libre à lui d'essayer de comprendre ce que faisait le programme, par exemple d'essayer de voir si la mémoire pointée par tel ou tel registre ou encore la pile ne contient pas par exemple une chaine, auquel cas il te l'indique.
Les appels d'api natives sont particulièrement faciles à interpréter puisque les prototypes sont connus.
Donc, ce qu'il se passe dans le cas du tuto 4, c'est que le reveser voit que l'api de comparaison de chaine lstrcmp est appelée.
Comme il souhaite voir ce qui est comparé il place un breakpoint sur l'appel de cette api.
Lorsque le debugger gèle le programme et transmet le contexte au debugger (étape 5), ce dernier connaissant le prototype de la fonction il sait exactement quoi et où regarder pour t'afficher les paramètres mis en forme (étape 7) et dans ce cas précis le password.
Voilà, je comptais répondre en dix minutes mais je me suis bien pris la tête à essayer de rendre ça compréhensible.
Comme c'est une question qui revient très souvent chez ceux qui commencent à s'intéresser au rce, j'espère que ça sera utile à ceux qui passeront par là.
++
