Comprendre le code Assemblée

Question

Quelqu'un pourrait-il donner un aperçu du code assembleur suivant:

Plus d'informations:

Le bootloader est en fait une petite bootloader 16bit qui décodent en utilisant le déchiffrement Xor, un plus gros, un bootloader linux situé dans les secteurs 3 à 34. (1 secteur vaut 512 octets dans ce disque)

Le tout est un système de protection pour un exec fonctionnant sous Linux embarqué. La version où la protection a été supprimée a déjà été déchiffrée par le bootloader linux (nous avons pu l'inverser en utilisant IDA) donc nous supposons que la clé xor doit être faite uniquement avec zéro dans la version sans la protection. Si nous regardons le décalage 0x800 à 0x8FF dans la version avec la protection enlevée, il n'est pas rempli de zéro, donc cela ne peut pas être la clé sinon cette version ne pourrait pas être chargée, elle xortrait des données et ne chargerait rien.

les secteurs 3-> 34 sont chiffrés en version originale et en clair dans notre version (protection supprimée) mais le code MBR (petit prebootloader) est identique dans les deux versions.

Est-il possible qu'un petit détail dans le code d'assemblage du MBR modifie légèrement l'emplacement de la clé xor?

Ceci est simplement un exercice que je fais pour mieux comprendre les chargeurs de code d'assemblage et j'ai trouvé que celui-ci était plutôt difficile à passer. Je vous remercie pour votre contribution jusqu'à présent!

Answer 1

Eh bien, la lecture du code d'assemblage demande beaucoup de travail. Je m'en tiendrai à répondre d'où vient la «clé».

• Le BIOS charge le MBR à 0000: 7C00 et définit DL sur le lecteur à partir duquel il a été chargé. Tout d'abord, votre MBR établit une pile qui descend de 0000: 7C00.
• Ensuite, il se copie lui-même à 0000: 0600-0000: 07ff et fait le saut lointain que je suppose être à l'instruction suivante, cependant sur la version copiée, 0000: 061D. (EDIT: cette copie est une chose assez standard pour un MBR à faire, typiquement à cette adresse, il laisse l'espace d'adresse ci-dessus libre) (EDIT: il se copie entièrement, j'ai mal lu).
• Ensuite, il essaie 5 fois de lire le secteur 2 en 0000: 0700-0000: 08ff, et s'arrête avec un message d'erreur s'il échoue (loc_78).
• Ensuite, il essaie 5 fois de lire 32 secteurs à partir du secteur 3 en 2000: 0-2000: 3FFF (adresse absolue 20000-23FFF, soit 16ko à partir de 128ko).
• Si tout va bien nous sommes à loc_60 et nous savons ce que nous avons en mémoire.
• La boucle sur loc_68 utilisera comme destination le tampon contenant ces 32 secteurs.
• Il utilisera comme source le tampon commençant à 0000: 0800 (qui est le second 256 octets du tampon que nous lisons en 0: 0700-0: 08ff, le second 256 octets du secteur 2 du disque).
• A chaque itération, LODSW ajoute 2 à SI.
• Lorsque SI atteint 840, il est ramené à 800 par l'ET. Par conséquent, le tampon "clé" va de 800 à 83F, soit les 64 octets commençant à l'octet 256 du secteur 2 du disque.J'ai l'impression que le XOR est un octet court ... que CX aurait dû être réglé sur 4000h, pas sur 3FFF. Je pense que c'est un bug dans le code.
• Après que le tampon de 16 Ko à l'adresse physique 20000 a été XOR circulé avec ce tampon "clé", nous sautons dedans avec un saut lointain à 2000: 0.

À droite? Est ce que ça va? C'est la clé là?