CPU-Z passe à la version 2.19. Cet outil de diagnostic fait le point sur l’équipement de votre matériel et s’intéresse surtout au processeur embarqué avant de décliner son expertise autour de la carte mère, de la mémoire vive et du chipset graphique. Proposant dans un second temps un outil d’analyse et de validation.
CPU-Z a été percuté de plein fouet par l’affaire des faux processeurs Ryzen qui ont réussi à le berner. Faisant sans problème passer les puces Ryzen 5 5500U pour des Ryzen 5 7430U d’une autre génération. L’outile n’y voyait que du feu.
Chaque puce s’identifie avec un PNS, bienvenue dans le monde des acronymes, pour Processor Name String. Ce PNS indique au système quelle puce est à son bord. Le BIOS va lire ce PNS au travers d’un protocole d’AMD appelé MSR pour Model Specific Registers. Mais le BIOS peut sans difficulté retranscrire ensuite la référence qu’il veut au système jouant ici le rôle de traducteur. et un traducteur peut être fort peu scrupuleux si on lui graisse la patte.

CPU-Z 2.18 lit « Ryzen 7 7430U » sur le ChuwiBook Plus.
Sur les machines de Chuwi, le BIOS allait donc lire le PNS du processeur, qu’il s’agissait d’un Ryzen 5 5500U mais traduisait ensuite volontairement au système que la puce était un Ryzen 7 7430U de génération plus récente. CPU-Z, comme le reste du système, lisait les informations en provenance du BIOS, comptant sur la bonne foi du fabricant. Le fait que la majorité des autres informations relevées d’une génération à l’autre soient identiques renforçait ensuite la crédibilité de l’échange.
Il fallait se pencher sur certains détails comme la fréquence d’horloge du processeur, la quantité de mémoire cache L3 pour déceler des erreurs. C’ert là que le problème réside d’ailleurs. Comme la foule de processeurs en activité est énorme, même selon la préfecture, il est impossible de connaitre sur le bout des doigts l’ensemble des chiffres qui les caractérisent. Du coup, le serpent se mord la queue : les spécialistes font justement appel à CPU-Z pour vérifier quelle puce est à bord de chaque machine…
Ce maquillage prouve au passage la volonté très claire des constructeurs de matériel et des développeurs de BIOS de faire passer une puce pour une autre. Cela ne peut pas être une erreur ou une coïncidence, pas plus qu’un changement de puce dans la chaine d’approvisionnement. Le maquillage du BIOS pour tromper les outils de diagnostic procède d’une volonté claire de tromper le client final.

CPU-Z 2.19 affiche désormais deux puces distinctes sur le Ninkear A15 Pro qui semble touché par le même problème.
CPU-Z passe à la version 2.19 et ne se laisse plus tromper
Piquées au vif, les équipes de développeurs de CPU-Z ont donc changé leur fusil d’épaule. Si le logiciel continue de lire les informations données par le BIOS directement, ils vont au passage également vérifier quelle puce est embarquée en allant lui réclamer son identification par le PNS. Faisant ainsi apparaitre sur l’interface le nom de la puce tel que signalé par chacune des sources.
Sur la capture ci-dessus, deux processeurs sont donc identifiés. En haut le Ryzen 5 5500U est correctement remonté directement par l’interrogation de la puce elle-même. En dessous c’est le processeur signalé par le BIOS qui est affiché. Les deux valeurs sont contradictoires, celle du haut n’est pas falsifiable.

Chuwi indiquait donc que les personnes ayant une des machines concernées par ces faux Ryzen pouvaient les contacter pour se faire rembourser. Un des soucis était qu’il fallait d’abord authentifier si celle-ci posait problème ou non. Or, en l’absence d’outil logiciel, cette identification passait par l’ouverture des machines et le démontage des systèmes de refroidissement. Une opération très rafraichissante en effet, la majorité des propriétaires de Chuwi étant refroidis par cette première étape. Désormais il sera possible de contrôler son processeur directement avec CPU-Z en téléchargeant la version 2.19 sur leur site.

Tableau d’identification des processeurs fourni par AMD en 2022 pour la sortie des Zen3
Le Ryzen 5 7430U reste un « drôle » de processeur
Je voudrais d’ailleurs mettre l’accent sur un élément que j’avais identifié lors de la présentation du Chuwi Ubox 7430U également dans la tourmente. AMD a fait un drôle de choix en créant le Ryzen 5 7430U car cela va à l’encontre de ses propres éléments d’identification et de référence. L’image ci-dessus montre comment sont construites les références des processeurs AMD. Chaque chiffre correspond à une référence précise et permet d’identifier « facilement » les puces.
Le Ryzen 7430U est donc, si on lit le code ci-dessus, une aberration. En analysant ce code dans le désordre. Le premier chiffre nous indique une puce de 2023, année des « 7 ». Il est construit avec des cœurs Zen 3 comme l’indique le 3 de son « architecture ». Le « 0 » indique la révision de la puce. Les Zen3, par exemple, sont des « 0 » et les Zen3+ qui sont des versions révisées et améliorées des mêmes cœurs sont des « 5 ». Ce dernier chiffre permet de différencier les versions révisées des puces.

Reste le chiffre 4, le second de la liste. Celui-ci indique qu’un Ryzen 5 7430U est censé être en réalité un Ryzen 3. Et pourtant AMD l’a classé comme un Ryzen 5. Un choix qui m’avait étonné à l’époque et qui pose aujourd’hui problème. Le Ryzen 5 7430U aurait dû, en toute logique et en suivant les éléments indiqués par AMD lui-même, être un Ryzen 3. Est-ce qu’AMD a choisi de le changer de catégorie pour des histoires de marketing ? Est-ce que les ingénieurs de la marque, s’apercevant des bonnes performances de la puce, ont décidé de lui faire sauter une classe ? Si un Ryzen 3 avait montré des performances trop élevées, cela aurait pu être problématique pour le reste des processeurs de la marque ?
Il n’est pas impossible que des constructeurs se soient engouffrés dans cette brèche en repérant que ce processeur spécifique, avec son nom qui ne correspond pas à son état, soit une cible idéale pour brouiller les pistes. Je ne sais pas si un seul constructeur aurait eu envie de glisser un Ryzen 3 7430U à la place d’un Ryzen 5 5500U dans une machine. Peut-être que la volonté d’AMD d’outrepasser ses propres règles a donné des idées à certains.
Source : Notebookcheck que l’on peut applaudir pour son investissement dans cette affaire.
Le Chuwi Corebook X pris en flagrant délit de falsification processeur
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |






Très joli le coup de la préfecture.
PS : coquille
L’outilE n’y voyait que du feu
Je ne sais pas si le mini book X (N100 vs N150) est touché
C’est surtout que CPU-z aurait dû aller chercher les infos au plus bas niveau possible, car demander au bios relevait de la flemme pour un programme devant identifier au plus près du matériel ce qu’il est.
CPU-z doit donc plutôt se sentir complice, et réparer son image également à travers ce correctif ?
Bravo à l’équipe de CPU-Z,
Ils vont grandement simplifié la chasse
@Gepp: C’est une vision assez déprimante et pessimiste de la chose. En informatique, tu te dois de faire confiance un minimum dans la marque choisie. Tout simplement parce que le processeur est dépendant en amont de l’usage des bons composants sur le PCB. Si tu n’as pas confiance dans ton fabricant, alors tu ne dois pas t’arrêter au processeur mais faire un audit complet de l’ensemble du matériel, composant par composant. Ce que font les militaires et certaines entreprises, par exemple.
Si tu condamnes pour complicité chaque outil informatique parce qu’il laisse passer des détails techniques dans sa manière de fonctionner, c’est comme si tu condamnais un douanier parce que de la contrebande parvient quand même à circuler. Le contrôle des frontières est de sa responsabilité mais c’est tout de même très différent d’en faire un complice s’il ne voit pas une cartouche de cigarettes non déclarée cachée au fond d’un camion de plusieurs tonnes.. Il faudrait également accabler les testeurs pour complicité.
Si un fabricant veut tricher, il trouvera bien un moyen de le faire. Comme le jeu n’en vaut que rarement la chandelle, la preuve ici avec Chuwi qui vient de perdre toute crédibilité et des années d’investissement en image publique en quelques jours, tu n’es pas supposé imaginer qu’on puisse vouloir te tromper.
Chercher les infos « au niveau le plus bas » était-il seulement possible et envisageable ? Cela fait des années que des faux résultats sortent sur Geekbench avec une validation basée sur le PNS/CPUID. Des années que des constructeurs comme des internautes jouent à falsifier ces résultats a chaque nouvelle génération de puces. Jamais cela n’a été corrigé parce que, semble-t-il, cela n’émouvait personne. Est-ce que, face à cette histoire de falsification, CPU-Z a été contacté par AMD pour avoir les clés permettant de se renseigner directement au niveau du CPU ? Je n’en sais rien mais résoudre un problème vieux de plusieurs années en quelques jours ne m’apparaît pas forcément comme de la flemme mais plutôt comme une nouvelle approche.
Ce que tu juges être « paresseux » est en réalité assez complexe. Récupérer les infos via le BIOS est certes facile et peu fiable mais cela reste la méthode la plus courante pour les raisons évoquées au-dessus de crédibilité des marques.
Il existe bien un moyen d’être certain de la qualité d’une puce en analysant tout ce qu’elle liste (cache, instructions, fréquences, watts.) mais cela suppose une gigantesque base de données qu’il faut constamment mettre à jour. Les seules choses simples à réaliser sont l’identification du Pedigree des puces : marque et génération. Pas son ADN complet.
Le seul outil qui permet de vérifier chaque puce qui soit fiable est HWinfo à ma connaissance. Mais cela ne fonctionne pas forcément sur tous les matériels car ses processus n’utilisent pas les standards d’AMD et Intel. Sur des produits comme les Chuwi et autres machines du genre, HWinfo est souvent aux fraises.
CPU-Z n’est pas un bon outil de bench, pour plein de raisons à mon sens, mais cela reste un bon outil d’analyse, lisible et gratuit. Je serais bien mal inspiré de vouloir leur jeter la pierre.
@FlyDutch
Intel N150 chez moi, en version 2.18 et 2.19
Je serais curieux de savoir ce que répond un « cat /proc/cpuinfo » sous Linux pour voir si il se fait berner (par le BIOS) également.
@Gepp:
Assez d’accord et visiblement ils ne sont pas les seuls. CPU-Z étant un truc windows, pour avoir une vérification indépendante de l’OS (en environnement EFI) sachez que memtest86+ (avec le +, la version memtest86 source clos de PassMark on peut pas vérifier) ne se ferait pas beurrer les lunettes non plus:
https://github.com/memtest86plus/memtest86plus/blob/main/system/x86/cpuinfo.c
C’est dans determine_cpu_model() ligne 616 pour tout processeur pas trop antédiluvien qui renvoie directement la chaîne de caractères sortie par le processeur via le cpuid… Il n’y a que des références anciennes ou on se base sur family/model pour y coller un nom.
De toutes manières, memtest86+ date (et conserve la capacitè à les utiliser) du BIOS d’avant l’UEFI et ne se repose donc pas sur les services UEFI (juste pour le reset dans ce cadre), recodant tout en dur et sans dépendance, peine que d’autres se sont visiblement évité.
@yann: cpuinfo utilises CPUID pour déterminer quelle puce est montée sur une machine… Exactement comme CPU-Z donc avec le même risque de se faire bananer.
tu as le détail de la méthode pour tromper une machine ici :
https://www.reddit.com/r/pcmasterrace/comments/1orc6jl/my_friends_and_i_accidentally_faked_the_ryzen_7/
@yann:
Mais pour qui te prends-tu ? Tu n’apprécierais probablement pas le même genre de remarque sur ton travail.
L’équipe de CPU-Z fournit un outil gratuit et très apprécié, cela depuis des années. De plus, leur réactivité a été exemplaire. Et tu trouves quand même le moyen de les dénigrer ?
@Pierre:
Ils n’ont qu’alteré la sortie du pseudo fichier qui mets en forme le résultat du cpuid avec un montage bind.
Sous les unices tout est fichier et les procfs ou sysfs on leur beurre les lunettes si on est root.
Exactement ce qu’ils ont fait et Passmark qui récupère les PV de bench s’est fait avoir!
Mais une instruction processeur ne ment pas elle, sauf errata.
@jle: Je me prends pour un développeur bas niveau, option démarrage processeurs, qui n’a pas trop à ce stade l’opportunité de se reposer sur autre chose que le matériel… et qui même au delà évite toute dépendance evitable (qui posera de pb de maintenance ensuite).
Quand on fait des outils de bench matériel il ne paraîtrait pas déconnant d’adopter cette approche.
En tout cas montrer les 2 et l’incohérence éventuelle devrait calmer ce type de fraude et c’est positif.
@yann: Oui, et cela a suffi à tromper toute la planète hardware pendant un bon moment… Avant qu’ils se dénoncent.
Encore une fois, je n’ai pas assez de billes pour jeter la pierre à qui que ce soit d’autre que le premier responsable de cette gabegie : Chuwi.
Je me garde bien de mettre en accusation un éditeur de logiciel fourni à titre gracieux qui a, depuis, corrigé le tir. C’est un peu trop facile à mon goût de venir chercher des coupables alors que personne n’avait vu la faute auparavant. Je comprends parfaitement l’amertume mais je ne crie pas au loup.
désolé j’ai du mal m’exprimer :
ce n’est pas du tout un reproche que je fais à l’équipe de cpuz, bien au contraire vu leur réaction rapide et efficace.
Mon précédent commentaire était une tentative (manifestement maladroite) d’explication sur ce qui a pu en partie motiver leur grande réactivité : on utilise ce genre de programme pour avoir de l’info au plus près du matériel, et si celui-ci retourne une chaine de caractère générique émise par le bios ou l’OS, son utilité devient limité car accessible dans le bios et dans l’OS directement, et que ça a dû jouer dans l’urgence qui les a fait réagir.
Je trouve le com de jle assez agressif out of nowhere, je vois que le sujet semble très sensible et nous avons tous nos moment de fatigue. On peut peut être continuer échanger calmement et fraternellement ? Et s’accorder sur le fait qu’on peut au besoin se questionner et critiquer des développements hardware ou software sans que cela soit pris personnellement; Ce qu’en plus il ne me semble pas que le com’ de yann et le mien faisaient.
Pareil que yann et gUI : je me demande bien ce que retournaient les hwinfo, lscpu and cie sous linux ? Si qq un a un Chuwi sous la main, ce serait instructif ce retour, car probablement que l’ancienne méthode de cpuz doit être commune à plusieurs approches open source.
@gep: Ok, pas de soucis, cela ne te ressemblait pas.
Je ne sais pas exactement comment tous ces outils fonctionnent mais les discussions que j’ai pu avoir cet après-midi et hier sur le sujet m’ont clairement fait comprendre que ce n’est franchement pas simple de dialoguer avec le matériel. Surtout les produits « exotiques ». Et, très vite, cela dépasse mes compétences techniques. On ne va pas se mentir, c’est de la programmation très « bas niveau ».
Merci Chuwi, pour une fois on parle d’autre chose que d’IA. Beaucoup s’en rendront compte plus tard : il y a plein de façons de se tirer une balle dans le pied dans monde la tech autrement qu’en ratant le dernier virage à la mode.
[…] bord. Le fait que le BIOS ait été altéré pour masquer la réalité du composant AMD embarqué aux logiciels de contrôle comme CPU-Z ne laisse pas de place à l’inattention ou à l’erreur involontaire. Le fabricant a bel […]