Réduit à sa plus basse expression, un programme ce n'est qu'un fichier contenant un ensemble d'octets. De fait la plupart des classes ou utilitaires de lecture d'un fichier ne vous permettent de récupérer qu'un tableau d'octets bruts.
Or l'un des objectifs ici est de justement mettre de l'ordre dans la soupe d'octets qu'est le programme en extrayant les valeurs de comment elles sont stockées.
Lire les entiers
Dans un programme DOS, les entiers sont sur 16bits soit donc il faut lire 2 octets pour obtenir la valeur stockée. Néanmoins ce n'est pas aussi simple car sous DOS le boutisme utilisé est little endian. Ce qui signifie que pour une lecture de de gauche à droite les bits de poids faibles se trouvent à gauche alors que dans une représentation textuelle classique ils sont à droite (big endian).
De fait, la lecture d'un fichier se faisant toujours de gauche à droite, il ne suffit pas de lire deux octets pour accéder à la valeur entière, il faut aussi faire un décalage de 8bits à gauche sur le second octet ce qui en C est illustré par la macro suivante :
#define LH(p) ((int)((byte *)(p))[0] + ((int)((byte *)(p))[1] << 8))
En Delphi, qui est le langage que j'utilise pour mon décompilateur, le TFileStream a la bonne idée de faire ça tout seul si je lui passe un buffer de type Word (
)
Lire des caractères
Du temps de DOS, on était loin d'avoir les mêmes problématiques que maintenant avec les encodages de caractères, en particulier les encodages nécessitant plusieurs octets. Ici chaque caractères fait un octet et c'est tout.
Lire une chaîne de caractères
Dans un programme DOS, les chaînes sont dites AZT soit à zéro terminal. Ce qui signifie basiquement qu'il faut lire tous les caractères/octets jusqu'à trouver le caractères 00 (noté \0) qui indique que la chaîne est terminée.
1 Commentaire