Discussion :

[Katleen Erna]

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 ?

[jimb2k]

Beh il est trop fort ce type là.

Je crois qu'il a passé beaucoup de temps afin de faire une telle découverte

[ogaby]

Ce 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.

[Julien Bodin]

Pour un novice comme moi, en quoi le ce mode debug aurait pu être utile ?

[pmithrandir]

Ce 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.

Je 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.

[baxou087]

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?

[taha1]

J'ai un pc équipé d'un AMD 64bit lol (dommage que c'est le seul pc que j'ai sinon j'aurai tenté l'aventure et passer en mode debug , mais comme je suis novice vaut mieux pas jouer avec ça lol )

[Neko]

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?

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.

[Joker-eph]

Je 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.

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 ?

[Joker-eph]

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).

Ne confonds-tu pas avec les débogueurs logiciels ? Ça n'as pas grand chose à voir... Un programme doit être compilé spécialement pour embarquer des infos exploitable par un débogueur. On est complètement à un autre niveau quand on parle d'instructions processeur.

Par contre des instructions matérielles de breakpoints pourraient aider à améliorer les débogueurs existants, surtout en terme de performance.

[pmithrandir]

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 ?

Je dis juste que si un mode d'introspection existe qui permet de tracer plus précisément des actions que l'on ne pouvait que supposer auparavant, on devrait je pense avoir des bonnes surprises dans les prochains mois.

Je ne pourrais jamais croire que des développeurs a l'aveugle ont fait aussi bien que si ils avaient pu y voir plus clair.

Exemple imagé.
On supposait pour le driver précédent d'après la doc que arrivé à un point A, on avait le choix entre le chemin 1 et le chemin 2. Le chemin 1 paraissait plus indiqué. Finalement, on s'aperçoit que le chemin 2 fait la même chose en moitié moins d'instruction... bingo.

Après, ca parait quand même étonnant que AMD n'ait pas communiqué sur ce module, quel était le risque si ce n'est améliorer les drivers existants ?

[b_zakaria]

Beh il est trop fort ce type là.

Je crois qu'il a passé beaucoup de temps afin de faire une telle découverte

ou peu de temps s'il bosse chez AMD

[rt15]

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".

[jacqueline]

Il y a au moins vingt ans que je sais que les designers de microprocs ont mis un mode debug, quand ils ont commencé à devenir plus complexes ( puisqu 'on ne peut pas aller brancher un oscilloscope ou un analyseur logique à l'intérieur ) pour pouvoir analyser, localiser et rectifier rapidement une erreur, avant de lancer la commercialisation.

Le secret et le mdp, sont justifiés comme secret de fabrication vis à vis de la concurence

[Mat.M]

mais aussi aux diverses données sensibles des processeurs (à savoir des warnings comme précisés plus haut par pmithrandir).

iun CPU n'émet aucun warning.
Si tu mets une valeur dans le registre EAX par exemple et que tu fasses un DIV avec une division par zéro alors l'indicateur "division par zéro" ( ou Zero Flag) est à 1.
Les variables sont rangées dans des registres EAX,EBX,ECX,EDX pour l'architecture i386.
Il y a aussi un registre,EDI, qui pointe sur une zone mémoire indexée , comme les tableaux dans un langage "évolué"

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?

Absolument ;cette faille pourrait être exploitée par des services secrets
Par exemple une partie des processeurs Intel est fabriquée...en Israel

[Mat.M]

Pour un novice comme moi, en quoi le ce mode debug aurait pu être utile ?

cela n'est d'aucune utilité sauf si tu veux faire ton propre OS.
Ce mode debug comme le dit si bien mon prédecesseur c'est utile au fabricant de CPU pour mettre au point la conception du composant..

[10_GOTO_10]

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.

[Invité]

C'est gentil à AMD de penser aux pirates.

Il est fort probable que ce mode existe aussi chez Intel ...