Un debug-mode secret découvert dans tous les processeurs AMD
Des 10 dernières années par un hacker
Le 2010-11-16 16:16:24, par Katleen Erna, Expert éminent sénior
Un debug-mode secret découvert dans tous les processeurs AMD des 10 dernières années par un hacker
Un hacker spécialisé dans le hardware vient de faire une découverte surprenante. Il a mis le doigt sur rien de moins qu'un debugging mode caché dans tous les processeurs AMD des dix dernières années, depuis le Athlon XP.
La fonctionnalité, protégée par un mot de passe, a surpris un grand nombre d'ingénieurs informatiques, qui ignoraient son existence et pour qui un tel mécanisme aurait pu s'avérer fort utile.
Et pourtant, le constructeur a gardé bien jalousement son secret.
Jusqu'à ce que le pirate Czernobyl vienne fourrer son nez dans ses circuits.
En examinant attentivement le CBID (Central Brain Identifier) d'une puce, il a trouvé des indices lui indiquant la présence éventuelle de modes cachés. Il a ensuite pu lancer les modes grâce à une attaque de force brute pour en casser la clé.
Et ces fonctions de debugging dépasseraient "largement le standard défini des capacités de l'architecture x86".
Pour passer un processeur en mode développeur, il faut entrer le mot de passe 9C5A203A dans le registre EDI du CPU. Ensuite, le debug mode est accessible.
Il semblerait qu'il ai été utilisé pendant le processus de programmation, puis désactivé avant que les puces soient expédiées pour être commercialisées.
Source : Les révélations de Czernobyl
A votre avis, à quoi pourrait servir ce mode caché ? Quelles utilisations en seront faites des possesseurs de machines, mais aussi par les hackers ?
Un hacker spécialisé dans le hardware vient de faire une découverte surprenante. Il a mis le doigt sur rien de moins qu'un debugging mode caché dans tous les processeurs AMD des dix dernières années, depuis le Athlon XP.
La fonctionnalité, protégée par un mot de passe, a surpris un grand nombre d'ingénieurs informatiques, qui ignoraient son existence et pour qui un tel mécanisme aurait pu s'avérer fort utile.
Et pourtant, le constructeur a gardé bien jalousement son secret.
Jusqu'à ce que le pirate Czernobyl vienne fourrer son nez dans ses circuits.
En examinant attentivement le CBID (Central Brain Identifier) d'une puce, il a trouvé des indices lui indiquant la présence éventuelle de modes cachés. Il a ensuite pu lancer les modes grâce à une attaque de force brute pour en casser la clé.
Et ces fonctions de debugging dépasseraient "largement le standard défini des capacités de l'architecture x86".
Pour passer un processeur en mode développeur, il faut entrer le mot de passe 9C5A203A dans le registre EDI du CPU. Ensuite, le debug mode est accessible.
Il semblerait qu'il ai été utilisé pendant le processus de programmation, puis désactivé avant que les puces soient expédiées pour être commercialisées.
Source : Les révélations de Czernobyl
-
rt15Membre éclairéJe viens de parcourir le lien, et fort est de constater que si la découverte est impressionnante, les "capacités de debug super secrètes" sont en fait une extension dans les possibilités de mise en place de breakpoints.
Sans connaître ce mode
Globalement, "avant cette découverte", on avait le droit de faire deux types de breakpoint.
-> Breakpoint sur une instruction. On donne une adresse d'instruction. Si le processeur tombe sur cette adresse (eip = cette adresse), hop, breakpoint. Cela correspond globalement à la commande bp dans les débuggueur MS.
-> Breakpoint sur une donnée. On donne une adresse. Si une instruction accède à cette adresse, hop, breakpoint. Cela correspond globalement à la commande ba dans les débuggueur MS.
En s'aidant du mode secret
Il y a 4 registres supplémentaires accessibles si EDI a la bonne valeur : Control, Address_Mask, Data_Match and Data_Mask (Le registre DR0 revient à une Address_Match).
Control permet globalement de passer du mode classique au mode secret.
Les "masks" permettent de définir quels bits des "matchs" doivent correspondre à ce qui est surveillé (instruction ou donnée).
=> Si ((Address_Match & Address_Mask) == (eip & Address_Mask)) alors breakpoint (Ou "&" est l'opérateur "et" binaire et eip contenant l'adresse de l'instruction qui va être exécutée).
-> Breakpoint sur une instruction. On peut utiliser Address_Mask. C'est un masque de bits classique que l'on applique pour comparer l'adresse du breakpoint et l'adresse en cours. On peut donc mettre un breakpoint non plus uniquement sur une adresse, mais sur une zone (De taille limitée par la taille du masque -> 4ko). Si le processeur exécute une instruction dans cette zone, hop breakpoint.
-> Breakpoint sur une donnée. On peut utiliser Address_Mask de la même manière que pour les breakpoints sur instructions, donc surveiller une zone de la mémoire (Idem, limitée à 4ko). De plus, on peut conditionner le breakpoint sur la valeur des données accédées à l'aide de Data_Match et Data_Mask dont on devine aussi aisément le fonctionnement. Il y a aussi possibilité d'inverser la condition sur Data_Match et Data_Mask en utilisant Control (Si les données sont différentes, alors breakpoint).
Bref, des possibilités supplémentaires sur les breakpoints, ce qui est plutôt très cool. Mais il s'agit bien de "capacités super secrètes", et non pas de "super capacités secrètes".le 17/11/2010 à 11:12 -
10_GOTO_10Membre expérimentéDonc, si je comprend bien, ça va devenir un jeu d'enfant de déplomber un logiciel: tu met le "breakpoint" processeur sur la zone mémoire correspondant au numéro de licence (par exemple), et ça permet de détecter immédiatement où est l'algorithme de vérification, et ceci sans débugger, donc totalement indétectable par le logiciel en question.
C'est gentil à AMD de penser aux pirates.le 17/11/2010 à 19:38 -
pmithrandirExpert éminentJe suis sur qu'il y a moyen d'améiorer encore le tout... Acceder a un debug, ca peut permettre de trouver des warning, erreurs intestable avant.le 16/11/2010 à 17:41
-
NekoMembre chevronnéje peux me tromper, mais un processeur, ça bosse avec des registres et de la mémoire, en aucun cas avec des variables proprement dites dans le sens où ya pas de nom. Juste des adresses.
De même un processeur n'émet pas de warning. Soit ça marche, soit il émet une interruption.
Par contre ce mode débug permet peut être d'écrire ou lire dans des zones mémoire où un programme donné tournant en mode user ne devrait pas avoir accès. Voir donc bypasser l'OS. Mais ça ne semble pas être le cas puisque comme écrit ce mode debug n'est accessible qu'en ring 0.le 16/11/2010 à 23:30 -
b_zakariaMembre avertile 17/11/2010 à 9:58
-
jimb2kMembre habituéBeh il est trop fort ce type là.
Je crois qu'il a passé beaucoup de temps afin de faire une telle découvertele 16/11/2010 à 16:36 -
ogabyMembre avertiCe mode caché aurait pu (peut-être) aider les ingénieurs de microsoft et de linux pour vérifier l'intégration des processeurs dans les noyaux. Mais bon maintenant c'est un peu tard. Tant pis.le 16/11/2010 à 16:55
-
Julien BodinMembre éclairéPour un novice comme moi, en quoi le ce mode debug aurait pu être utile ?le 16/11/2010 à 17:33
-
baxou087Membre habituéDans un premier temps, BRAVO à ce hacker.
Cependant, je ne sais pas si je suis le seul que ça choque, mais je trouve cela assez troublant. Corrigez moi si je me trompe, mais le fait d'avoir accès à un processeur en mode debugging, c'est donner accès au noms des variables, à leur contenu, mais aussi aux diverses données sensibles des processeurs (à savoir des warnings comme précisés plus haut par pmithrandir).
Je ne doute pas du fait que ce soit utile d'avoir accès à ce debugger, mais n'est-ce pas un danger pour les utilisateurs de machines équipées de processeurs AMD?
Car après tout qu'est-ce qui empêcherais quelqu'un de mal intentionné d'exploiter ces données à de mauvaises fins?
Dans ce cas, ne serait-ce pas la raison pour laquelle AMD le gardait secret?le 16/11/2010 à 20:52 -
Joker-ephMembre confirmé
On peut avoir un exemple parceque je ne vois pas bien là ? On peut déjà détecter les overflows et les divisions par zéro, tu vois quoi comme erreurs/warnings sur les opérations assembleurs ?le 17/11/2010 à 1:59