Je me souviens de ce hack comme étant écrit par Bob Smith, qui a fait les vieux DOS de l'ère gestionnaire de mémoire appelé 386MAX (ou "386 au Max"). Il ne faisait pas partie du produit, c'est un petit programme utilitaire il fouettée et posté quelque part. Cependant, sur le web, la seule référence à cette technique, je trouve, c'est un DDJ sans-papiers Coin de la colonne à partir de novembre 1996 par Robert Collins.
Le Problème
Avant Intel introduction de l' instruction CPUID, il a été difficile de vérifier le type exact et le niveau de révision de la CPU sur votre système. Il s'avère que dans la plupart des versions de l'386 et plus tard, il y avait vraiment une ID du CPU, mais c'est seulement visible à un moment: juste après le processeur a été remis à zéro dans le registre EDX. (Il a été supposé que le BIOS de l'ordinateur serait le seul logiciel légitimement intéressés par cette).
Problème: comment un programme normal de récupérer cette valeur de registre si nous ne sommes pas le BIOS?
Matériel De Fond
Ce hack invoqué six distinctes particularités de l'IBM PC compatible ordinateurs. Ils ont été comme suit:
- En commençant par IBM et plus tard, il y a un moyen de désactiver indépendamment de l'A20 ligne de l'adresse sur le bus.
- La plupart des ordinateurs n'ont pas de mémoire RAM installée sur très haut des adresses mémoire, juste en dessous de la ROM du BIOS.
- La plupart des IBM PC ordinateurs de bus de retour 0xFF lorsque vous lisez un emplacement de la mémoire qui n'a pas de mémoire qui y est installé.
- 0xFF 0xFF 0xFF etc illégale est une opcode sur les Processeurs Intel.
- Si vous installez un gestionnaire d'exception dans la mémoire, il doit survivre à un soft reboot sur la plupart des Processeurs de cette époque (386 à travers 486).
- Lors de la réinitialisation logicielle ou matérielle, les processeurs Intel saut à une adresse qui est au sommet de mémoire adressable, moins de 16 octets, qui est pourquoi la ROM du BIOS est placé là.
Le programme des connaissances combinées de tous ces morceaux de trivia pour atteindre l'objectif.
Le Hack
Le résultat a été une ligne de commande DOS programme, qui a réalisé les opérations suivantes:
- Installé illégale d'un opcode gestionnaire d'exception
- Éteint l'A20 ligne de l'adresse sur le bus
- Soft-redémarré le CPU (je crois que c'est par le biais d'un appel BIOS)
Lorsque le soft reboot s'est produite, le processeur va essayer de sauter vers le haut de la mémoire, moins de 16 octets, qui est l'endroit où la ROM code de démarrage est situé. Cependant, depuis l'A20 a été éteint, il serait en fait le saut vers le haut de la mémoire, moins de 16 octets de moins d'un mégaoctet. Sur la plupart des Ordinateurs, il n'y a pas de mémoire là. Alors qu'il allait chercher une série d'octets 0xFF de cette inexistante de RAM, et d'essayer de l'exécuter. Cela permettrait de créer un illégales opcode exception.
Son gestionnaire d'exception serait alors arracher la valeur de EDX (le CPUID) et à ranger quelque part qu'il pouvait trouver. Il serait alors nettoyer le gâchis (tour de l'A20 sur le dos, flip arrière du mode protégé en mode réel pour le DOS) et de contrôle de retour pour le code original.
Quand il travaillait, c'était génial à voir. Voilà, c'était une simple ligne de commande DOS programme qui vous donnent la CPUID valeur.
Bien sûr, il y avait inévitablement des Ordinateurs qui n'ont pas été "tout à fait compatible", qui se planter horriblement lors de l'exécution de cette. Ah bien.