Claude Code a aidé à contourner une vérification de signature BIOS HP sans casser RSA-2048

Anthropic s'est retrouvée au cœur d'un débat inhabituel sur la sécurité après que Claude Code aurait aidé à modifier le BIOS d'un ordinateur portable HP et à révéler 55 réglages cachés. Le titre de Tom's Hardware laisse entendre que l'IA a vaincu RSA-2048, l'une des normes cryptographiques utilisées pour authentifier les firmwares. Les éléments disponibles étayent une conclusion plus restreinte, mais néanmoins importante : Claude Code a trouvé un moyen de contourner la logique de décision d'une implémentation.

La distinction est importante. Selon le propriétaire de l'ordinateur, Claude Code a aidé à localiser le code de vérification, analyser des modules de firmware compressés, tester un correctif et reconstruire une image fonctionnelle. Il n'a pas récupéré la clé de signature de HP, forgé une signature valide ni résolu le problème mathématique sous-jacent à RSA-2048.

Le résultat remet donc en question deux hypothèses courantes. Les fabricants d'ordinateurs portables supposent que les contrôles du firmware restent trop complexes pour être rétro-ingéniérés par des propriétaires ordinaires. Les fournisseurs d'IA supposent que les agents de codage peuvent être présentés sans risque comme des outils de productivité, même lorsque les utilisateurs les orientent vers des systèmes sensibles sur le plan de la sécurité.

L'expérience aurait fonctionné sur un HP 15-dw1036ne exécutant le BIOS version F.68. Elle n'a pas fait l'objet d'un audit technique indépendant, et sa portabilité vers d'autres systèmes reste incertaine. Néanmoins, ce flux de travail montre comment un agent de codage IA peut réduire le travail nécessaire à une recherche spécialisée sur les firmwares.

Claude Code a transformé un dump de BIOS en modification fonctionnelle

Le changement majeur n'était pas une nouvelle attaque cryptographique. Il s'agissait de condenser un flux de travail difficile de rétro-ingénierie dans une seule session d'IA dirigée par l'utilisateur.

Un utilisateur de Reddit publiant sous le nom Reddit_2049 a déclaré que son ordinateur portable HP rejetait tout firmware modifié avec le message « BIOS Corruption Detected ». Selon cet utilisateur, personne n'avait publié de méthode de déverrouillage connue pour ce modèle précis. Il a fourni à Claude Code un dump de BIOS ainsi que plusieurs outils établis de rétro-ingénierie.

Le flux de travail rapporté combinait Ghidra, UEFITool, UEFIExtract, UEFIFind, Unicorn Engine, Capstone, Python et une bibliothèque de cryptographie. Chaque programme remplit déjà une fonction technique identifiable. La contribution rapportée de Claude Code consistait à les coordonner, interpréter leurs résultats et produire des scripts pour approfondir l'analyse.

Ghidra a désassemblé les modules du firmware et exposé le flux de contrôle pertinent. Les utilitaires UEFI ont séparé l'image en composants. Unicorn Engine a émulé la routine de vérification extraite hors de l'ordinateur portable physique, réduisant le risque de tester chaque modification par un véritable flashage du firmware.

La bibliothèque de cryptographie a généré des signatures de test valides pour la routine émulée. Ce détail est important, car il a permis à l'utilisateur de comparer des entrées valides et corrompues. Elle n'a pas créé de signature HP valide pour le firmware modifié.

Selon le post original de l'utilisateur, l'analyse a identifié trois groupes de modifications. L'un contournait un contrôle protégeant un volume de firmware DXE compressé. Un autre révélait 55 champs de configuration. Un troisième affichait les onglets Advanced, Power, Debug et Boot.

DXE, ou Driver Execution Environment, est une phase UEFI qui initialise les périphériques et les services avant le démarrage du système d'exploitation. Le code du firmware à ce niveau fonctionne sous Windows ou Linux. Des erreurs peuvent empêcher l'ordinateur d'atteindre l'un ou l'autre système d'exploitation.

Les 55 champs se composaient apparemment de 27 entrées masquées et de 28 entrées grisées. Leurs définitions existaient déjà dans les formulaires de configuration du firmware. De petites modifications de conditions codées en dur ont rendu ces champs visibles.

Cela ne signifie pas que chaque option révélée contrôle du matériel pris en charge. L'utilisateur a ensuite reconnu que certaines entrées semblaient sans rapport avec l'ordinateur portable, notamment un réglage GPS. Les fabricants partagent souvent des composants de firmware entre plusieurs produits, laissant des champs inactifs dans une interface commune.

Les quatre onglets supplémentaires suivaient un schéma similaire. Le firmware les contenait, mais sa logique d'interface empêchait leur affichage sur ce modèle. Le correctif a modifié cette décision plutôt que d'ajouter des fonctions de configuration entièrement nouvelles.

L'utilisateur a indiqué que l'image résultante fonctionnait sur son ordinateur portable. Il a également publié un script Python destiné à reproduire les modifications à partir d'un dump d'origine. Toutefois, le post avertissait que le script n'avait été testé que sur la machine indiquée et pourrait ne fonctionner que sur des modèles étroitement liés.

Il s'agit toujours d'une démonstration auto-déclarée. Ni HP ni Anthropic n'ont publiquement validé l'image modifiée, l'analyse ou les options de configuration qui en résultent. Aucun chercheur indépendant n'a publié de reproduction complète sur le même modèle d'ordinateur portable.

Cette lacune de vérification devrait guider toute interprétation de l'article de Tom's Hardware. Les détails fournis par l'utilisateur présentent un récit technique crédible, mais une expérience personnelle réussie ne constitue pas une capacité générale de déverrouillage de BIOS.

Le titre de Tom's Hardware exagère ce qui est arrivé à RSA-2048

Claude Code aurait contourné la branche logicielle qui appliquait un résultat de vérification. Il n'a pas vaincu l'algorithme RSA-2048 lui-même.

Les signatures numériques permettent à un appareil de vérifier si un firmware provient d'un éditeur autorisé et s'il est resté inchangé. Le fournisseur signe les données approuvées à l'aide d'une clé privée. Un vérificateur utilise la clé publique correspondante pour confirmer cette signature.

Casser RSA-2048 impliquerait une avancée cryptographique majeure. Un attaquant pourrait récupérer une clé privée, créer des signatures sans autorisation ou vaincre les hypothèses mathématiques sous-jacentes. Le compte Reddit ne décrit aucun de ces résultats.

L'utilisateur affirme plutôt que Claude Code a trouvé le code chargé de traiter le résultat de la signature. La modification aurait forcé ce code à suivre son chemin de réussite, que la vérification mathématique ait réellement réussi ou non.

Une analogie utile est celle d'un agent de sécurité qui contrôle un badge valide, puis consigne la réponse dans un registre. La modification rapportée n'a pas fabriqué de badge valide. Elle a modifié ce qui se passait après que l'agent avait rendu une réponse.

Cette différence ne rend pas le résultat anodin. Localiser le vérificateur pertinent dans un firmware compressé exigeait décompression, rétro-ingénierie, traçage du code et reconstruction minutieuse de l'image. Un binaire modifié devait également préserver la structure nécessaire au démarrage de la machine.

Pourtant, la primitive cryptographique s'est toujours comportée comme prévu. La faiblesse rapportée se situait dans le chemin d'application environnant et dans l'apparente disposition du système à exécuter du code de vérification modifié.

Les recommandations de Microsoft sur les firmwares expliquent pourquoi cette séparation est importante. Le code de firmware signé doit être validé avant son exécution, et les composants non autorisés ne doivent pas s'exécuter. Une fonction de vérification offre peu de protection si une couche de confiance antérieure ne protège pas cette fonction elle-même.

Le propriétaire de l'ordinateur portable a déclaré n'avoir trouvé aucune structure Intel Boot Guard nécessaire pour ancrer le code concerné dans une chaîne de confiance soutenue par le matériel. Intel Boot Guard est un mécanisme de plateforme conçu pour authentifier les composants du démarrage précoce avant que le firmware principal ne poursuive son exécution.

Cette affirmation n'a pas été confirmée indépendamment pour cette machine précise. Toutefois, si elle est exacte, elle explique pourquoi la modification du vérificateur pouvait survivre à un redémarrage. L'implémentation faisait confiance à un code stocké dans une mémoire flash inscriptible pour décider si un autre code devait être considéré comme fiable.

C'est le renversement central. RSA-2048 peut rester mathématiquement solide tout en permettant à un produit qui l'utilise d'accepter un firmware non autorisé. La sécurité dépend de la chaîne de vérification complète, et non du nom ou de la longueur de clé d'un seul algorithme.

Il existe des précédents historiques à cette distinction. Des chercheurs examinant la Nintendo 3DS ont documenté une implémentation de signature RSA qui acceptait un firmware non autorisé en raison de défauts d'analyse syntaxique. Leurs recherches sur la boot ROM visaient la manière dont les signatures étaient traitées, et non la difficulté mathématique de RSA-2048.

La modification HP est techniquement différente. Le récit publié décrit un flux de contrôle modifié plutôt qu'une signature malformée exploitant un analyseur. Ces deux cas montrent pourquoi « utilise RSA-2048 » ne constitue pas une déclaration de sécurité complète.

La présentation de Tom's Hardware risque également d'attribuer trop d'autonomie à Claude Code. L'humain a fourni le firmware, sélectionné les outils, approuvé les actions, testé les résultats et accepté le risque de flasher du code modifié. Claude opérait dans un environnement de recherche conçu par l'utilisateur.

Un titre plus exact indiquerait que Claude Code a aidé à contourner un contrôle de signature RSA-2048 sur une version de firmware HP. Cela reste frappant, car l'assistant aurait évolué dans un domaine qui exige normalement des connaissances spécialisées considérables.

Le véritable changement est la rétro-ingénierie assistée par IA

L'expérience suggère que les agents de codage peuvent rendre des flux de travail techniques avancés accessibles à des utilisateurs plus persévérants, même lorsque la vulnérabilité sous-jacente est conventionnelle.

La rétro-ingénierie des firmwares a historiquement exigé une maîtrise du code assembleur, des formats binaires, de la compression, de la cryptographie, de l'initialisation matérielle et des procédures de récupération. Aucune étape individuelle du flux de travail rapporté n'est sans précédent. Coordonner l'ensemble reste difficile.

Les agents IA modifient ce coût de coordination. Ils peuvent examiner la sortie des outils, proposer la requête suivante, générer de petits utilitaires d'analyse, suivre des hypothèses et réécrire des scripts lorsqu'une disposition binaire diffère des attentes. Ce travail nécessitait autrefois des recherches répétées dans des manuels, des forums et des dépôts de code source.

Claude Code n'a apparemment pas fonctionné comme un bouton de piratage instantané. Le récit décrit plutôt un processus itératif. L'utilisateur a fourni l'accès à des outils spécialisés tandis que le modèle reliait des conclusions partielles entre eux.

Ce schéma est plus important que les onglets BIOS visibles. Un modèle n'a pas besoin d'inventer un nouvel exploit pour modifier l'économie de la recherche en sécurité. Il lui suffit d'aider davantage de personnes à réaliser plus rapidement des analyses connues.

Ce cas montre aussi pourquoi les systèmes agentiques diffèrent des chatbots conversationnels. Un agent peut inspecter des fichiers, appeler des programmes, générer du code et utiliser les résultats d'une action pour planifier la suivante. Cette boucle crée un effet de levier dans les tâches où la progression dépend de dizaines de petites décisions techniques. Anthropic décrit Claude Code comme un système de codage agentique capable de lire des bases de code, modifier des fichiers, exécuter des tests et travailler avec des outils externes.

Pour les développeurs, la leçon n'est pas que Claude Code est devenu un expert autonome des firmwares. C'est qu'un utilisateur compétent peut constituer une équipe de recherche temporaire autour d'un modèle et de plusieurs outils déterministes.

Les outils ont fourni d'importantes formes d'ancrage. Un désassembleur a exposé les instructions machine. Un émulateur a permis des tests isolés. Les utilitaires binaires ont préservé la structure interne du firmware. Les suggestions du modèle ont été vérifiées par rapport à la sortie des programmes plutôt qu'acceptées comme du texte.

Cette combinaison peut réduire le risque d'hallucination, mais elle ne peut pas l'éliminer. Un modèle peut mal interpréter une adresse, confondre deux phases du firmware ou recommander un correctif dangereux. Dans le code d'application ordinaire, les tests détectent souvent ces erreurs. Les défaillances du firmware peuvent empêcher un appareil de démarrer.

Cela accroît la pression sur Anthropic et les autres fournisseurs d’IA. Leurs produits de programmation interviennent de plus en plus dans la recherche en sécurité, l’administration système et le contrôle matériel. Les mêmes capacités qui aident un propriétaire légitime à examiner un ordinateur portable peuvent également aider des attaquants à étudier les protections du firmware.

La véritable confrontation oppose donc capacités et vérification. Les modèles peuvent proposer des modifications plus ambitieuses, mais les utilisateurs ont toujours besoin de moyens fiables pour les tester. Le propriétaire du HP a utilisé l’émulation et aurait conservé un programmateur matériel à disposition pour la récupération.

C’est également là que les systèmes de connaissances personnels peuvent aider les équipes techniques. Les chercheurs doivent conserver les sorties d’outils, les hypothèses, les identifiants matériels et les résultats de tests au fil de longues investigations. Une base de connaissances d’ingénierie consultable peut soutenir cette documentation sans prétendre valider le firmware lui-même.

L’ensemble du secteur doit s’attendre à ce que les agents de programmation atteignent des environnements techniques plus inhabituels. L’ingénierie inverse, le développement embarqué, le débogage de pilotes et l’analyse de protocoles comportent tous des tâches répétitives que les modèles peuvent accélérer.

Cette expansion n’éliminera pas l’expertise. Elle modifie le point auquel celle-ci devient essentielle. Les utilisateurs pourraient passer moins de temps à écrire des scripts utilitaires et davantage à définir des modèles de menace, vérifier leurs hypothèses et concevoir des tests sûrs.

Le cas Tom's Hardware résume cette transition de façon concise. Claude Code aurait pris en charge suffisamment de travail analytique pour aider un passionné à franchir une barrière. L’humain restait responsable des conséquences.

Les paramètres cachés apportent des bénéfices de contrôle, mais aussi des risques de sécurité

Déverrouiller un appareil peut redonner le contrôle à son propriétaire, mais l’expérimentation au niveau du firmware entraîne des conséquences qu’un assistant IA ne peut pas assumer à la place de l’utilisateur.

Les fabricants d’ordinateurs portables cachent des paramètres BIOS pour plusieurs raisons. Certaines options ne s’appliquent pas au matériel installé. D’autres peuvent déstabiliser la mémoire, les contrôles thermiques, le stockage, la gestion de l’alimentation ou le comportement de démarrage.

Le firmware partagé offre une autre explication. Un fournisseur peut employer un code de configuration similaire sur de nombreux modèles, puis n’exposer que les champs validés pour chaque produit. Les options cachées peuvent donc représenter des composants d’interface inutilisés plutôt que des fonctions opérationnelles volontairement retenues.

L’option GPS signalée illustre cette limite. Rendre visible une entrée de menu ne crée pas une radio, une antenne, un pilote ou une connexion de carte absents. Un champ affiché peut être inactif, trompeur ou dangereux.

Certains utilisateurs ont néanmoins des raisons légitimes de rechercher un contrôle plus approfondi. Des paramètres avancés peuvent aider pour la virtualisation, les modes de stockage, l’ajustement de l’alimentation, le débogage ou des systèmes d’exploitation non pris en charge. Les techniciens de réparation et les chercheurs peuvent aussi avoir besoin d’un accès que les interfaces grand public refusent.

La tension n’oppose pas simplement la sécurité des fournisseurs à la liberté des utilisateurs. Elle oppose une configuration validée à une expérimentation non contrôlée. Les fournisseurs subissent des coûts de support et de garantie lorsque des combinaisons non documentées provoquent des défaillances, tandis que les propriétaires s’attendent raisonnablement à exercer une autorité sur le matériel qu’ils ont acheté.

L’IA intensifie les deux aspects. Elle peut aider les propriétaires à comprendre des firmwares opaques et à restaurer des fonctionnalités. Elle peut aussi produire des instructions assurées pour des combinaisons qui n’ont jamais été testées sur la carte ciblée.

L’auteur du message d’origine a explicitement recommandé de disposer d’un programmateur de puce de type CH341A. Ce matériel peut réécrire directement une puce flash si l’ordinateur portable ne démarre plus. Cet avertissement révèle mieux le véritable niveau de risque que les captures d’écran réussies.

Même un programmateur ne garantit pas une récupération sans difficulté. L’accès à la puce peut nécessiter d’ouvrir l’ordinateur portable, d’identifier le bon boîtier, de gérer les niveaux de tension et de conserver un dump d’origine. Une erreur peut endommager le matériel ou effacer des données propres à l’appareil.

Le firmware occupe également une position très privilégiée. Un code malveillant ou défectueux peut s’exécuter avant le système d’exploitation et persister après des réinstallations normales. Les chercheurs en sécurité traitent donc les modifications non autorisées du firmware différemment d’une personnalisation ordinaire d’application.

Des travaux universitaires récents soutiennent que les vérifications statiques seules ne peuvent pas observer chaque menace visant le firmware. Le framework Peacock propose une surveillance à l’exécution, car des adversaires peuvent manipuler le comportement du firmware après les vérifications initiales. Ces travaux renforcent la nécessité d’une protection en couches.

Le cas HP rapporté ne démontre pas que l’ordinateur portable soit devenu exploitable à distance. L’utilisateur possédait déjà la machine, a obtenu son firmware et a délibérément installé une image modifiée. La possession physique et l’intention sont au cœur du scénario.

Toutefois, le contournement aurait davantage d’importance si une autre voie permettait à un acteur non fiable d’écrire dans la région flash concernée. La combinaison d’une primitive d’écriture et d’une application faible du démarrage sécurisé peut transformer une technique de modification locale en risque de persistance.

Aucun élément du matériel source ne montre qu’une telle voie distante existe pour ce modèle. Il serait irresponsable de laisser entendre que des millions d’ordinateurs portables HP sont désormais exposés. La découverte concerne une image de firmware et une installation signalée.

La portabilité constitue une autre incertitude majeure. Le firmware varie selon les modèles, les révisions de cartes mères et les versions du BIOS. Les adresses changent, les modules évoluent et des mécanismes de confiance plus robustes peuvent rejeter la même approche.

L’utilisateur a indiqué qu’une modification de déverrouillage d’onglets avait déjà échoué lorsqu’elle avait été tentée sur une autre carte HP. Cette réponse affaiblit l’idée d’un script universel. Elle étaye également une interprétation plus intéressante : l’IA peut aider à adapter plus rapidement des recherches sur mesure, cible par cible.

HP pourrait réagir par de futures mises à jour du firmware, des contrôles d’écriture renforcés ou un composant de démarrage vérifié plus précoce. HP affirme que sa technologie Sure Start, soutenue par le matériel, est conçue pour empêcher les modifications non autorisées du firmware et restaurer le code BIOS compromis, mais le matériel source n’établit pas que cet ordinateur portable grand public bénéficie de cette protection. Son propriétaire a indiqué que sa dernière mise à jour de firmware remontait à 2024. Les anciens appareils grand public pourraient ne jamais recevoir une refonte de leur chaîne de confiance.

Anthropic est confrontée à une question distincte concernant les garde-fous. Ce travail présente clairement des caractéristiques de double usage, ce qui signifie qu’il peut soutenir à la fois la recherche légitime et les modifications nuisibles. Un refus général bloquerait les propriétaires et les défenseurs, tandis qu’une automatisation sans restriction peut abaisser les barrières pour les attaquants.

Une limite de sécurité raisonnable dépend du contexte, de l’accès, de l’intention et du niveau de détail opérationnel. Expliquer pourquoi une vérification de signature a échoué diffère de l’aide au déploiement d’une persistance furtive sur plusieurs machines. Les fournisseurs de modèles doivent distinguer ces scénarios sans présumer que toute tâche liée au firmware est malveillante.

Un ordinateur portable déverrouillé avec succès ne démontre pas une capacité générale

La démonstration est convaincante comme étude de cas, mais faible comme preuve que Claude Code peut déverrouiller de manière fiable les protections BIOS modernes.

Les preuves les plus solides proviennent du récit détaillé de l’utilisateur. Il a nommé l’ordinateur portable, la révision du BIOS, les outils, les structures du firmware, les champs découverts et le processus général de validation. Il a également révélé les limites au lieu de revendiquer une compatibilité universelle.

Les preuves les plus faibles concernent une reproduction indépendante. Aucun analyste distinct n’a publiquement documenté le même résultat à l’aide d’une image F.68 propre sur un autre HP 15-dw1036ne. HP n’a pas confirmé l’architecture ni évalué le contournement signalé.

Le résultat visible ne peut pas non plus prouver chaque étape de l’explication. Des photos de nouveaux onglets de menu montreraient qu’une interface modifiée a démarré. Elles n’établiraient pas quel chemin de code a accepté le firmware ni si une autre protection avait été désactivée plus tôt.

Le script publié fournit du matériel supplémentaire à examiner, mais son exécution n’est pas une méthode de vérification sûre pour les lecteurs ordinaires. Un audit responsable inspecterait le code, reproduirait les transformations binaires hors ligne et comparerait la sortie à un firmware obtenu indépendamment.

Les chercheurs devraient également confirmer l’absence alléguée de l’application d’Intel Boot Guard. Cette vérification détermine si le succès rapporté dépendait de l’absence d’une racine de confiance soutenue par le matériel. Elle limite également les conclusions concernant les systèmes plus récents ou orientés entreprise.

L’attribution au modèle demeure imprécise. L’utilisateur Reddit a déclaré avoir surtout utilisé Claude Opus 4.8 et parfois Sonnet 5 via Claude Code. Les éléments disponibles n’isolent pas quel modèle a trouvé chaque élément ni dans quelle mesure les directives humaines ont façonné l’approche finale.

L’historique des prompts aiderait à distinguer la découverte d’une mise en œuvre guidée. Si l’utilisateur a fourni des noms de modules probables, des modèles de firmware connus ou des branches candidates, la contribution de Claude diffère d’une recherche largement indépendante.

Le nombre de tokens, les tentatives échouées et le temps écoulé apporteraient davantage de contexte. Un flux de travail exigeant une intervention importante conserve sa valeur, mais il en dit moins sur les performances autonomes qu’une exécution reproductible depuis un point de départ propre.

L’expression « l’IA bat RSA-2048 » ne résiste pas à cet examen. La modification signalée n’a pas attaqué l’espace de clés de RSA. Elle a contourné un mécanisme de traitement du résultat sur un système qui aurait manqué d’une autre couche capable de protéger ce mécanisme.

Cette correction ne devrait pas devenir une excuse pour écarter le travail. Trouver le code pertinent dans un firmware compressé peut demander beaucoup de temps humain. Reconditionner l’image sans rompre les décalages ni les dépendances ajoute un autre défi pratique.

La question utile est de savoir si Claude Code réduit systématiquement cet effort. Une seule anecdote ne peut y répondre. Une évaluation utile confierait à plusieurs chercheurs plusieurs cibles de firmware et comparerait le temps d’exécution, la précision et les recommandations dangereuses.

Ces tests devraient inclure des plateformes protégées et non protégées. Un agent doit reconnaître lorsqu’un correctif proposé ne peut pas survivre à une étape de vérification soutenue par le matériel. Persister avec une théorie erronée pourrait faire perdre du temps ou endommager un appareil.

Les chercheurs devraient également mesurer si le modèle invente des significations non étayées pour les paramètres cachés. Les étiquettes d’interface seules ne prouvent pas qu’une fonctionnalité fonctionne. Le système le plus sûr distinguerait « champ découvert », « champ affiché » et « comportement validé ».

Tant que ces tests n’existent pas, l’histoire de Tom's Hardware relève de la catégorie des recherches de sécurité assistées par IA rapportées. Elle ne démontre pas un exploit BIOS automatisé et polyvalent. Elle montre que l’utilisation d’outils spécialisés se rapproche des non-spécialistes.

Trois signaux montreront s’il s’agissait d’une anecdote ou d’un tournant

Les prochaines preuves devraient venir de reproductions, d’analyses de fournisseurs et d’évaluations plus larges d’agents, et non d’un autre titre spectaculaire.

Le premier signal est une reproduction indépendante sur le même modèle et le même firmware. Un chercheur crédible devrait obtenir une image propre, confirmer les modules pertinents, reproduire les modifications et documenter les précautions de récupération.

Une reproduction réussie renforcerait l’affirmation selon laquelle le récit technique décrit fidèlement le chemin de confiance de l’ordinateur portable. Un échec suggérerait qu’un état non documenté de l’appareil, une modification antérieure ou une étape manquante a influencé le résultat.

Le deuxième signal est une réponse de HP ou du fournisseur de firmware sous-jacent. Le fournisseur pourrait confirmer si le volume concerné était censé être protégé par un autre mécanisme. Il pourrait également préciser si l’ordinateur portable a atteint la fin de sa période de support actif du firmware.

Une mise à jour du firmware qui protégerait le vérificateur par une ancre de confiance plus précoce validerait l’importance sécuritaire du rapport. Une conclusion du fournisseur selon laquelle la modification exigeait un flashage physique sans restriction limiterait ses implications en matière de menace.

Le troisième signal serait une performance reproductible d’agents d’IA sur des cibles de firmware non liées. Les chercheurs devraient vérifier si Claude Code peut identifier des failles d’implémentation comparables sans accompagnement spécifique à la cible. Ils devraient consigner les faux positifs et les images de test endommagées au même titre que les cas concluants.

Des réussites répétées montreraient que les agents d’IA modifient l’accessibilité de la rétro-ingénierie de firmware. Des résultats incohérents placeraient plutôt ce cas dans la catégorie d’une collaboration impressionnante entre un utilisateur motivé et un modèle, et non d’une capacité généralisable.

Les lecteurs devraient également surveiller la manière dont les entreprises d’IA décrivent ces systèmes. L’expression « assistant de codage » ne suffit plus à désigner un agent capable d’orchestrer des désassembleurs, des émulateurs, des utilitaires binaires et des tests cryptographiques. Les affirmations concernant la sécurité des produits doivent tenir compte des environnements que les utilisateurs peuvent construire autour du modèle.

Pour les développeurs et les équipes de sécurité, la réponse pratique consiste en une vérification rigoureuse. Conservez les images d’origine, isolez les tests, documentez les hypothèses et exigez une revue spécifique au matériel avant tout déploiement. La confiance générée par l’IA ne remplace pas une solution de récupération.

Les travailleurs du savoir peuvent en tirer une leçon connexe. Les agents deviennent plus utiles lorsque leur travail repose sur des éléments de preuve traçables. Conserver les prompts, les résultats, les hachages binaires et les observations de test dans un système personnel de gestion des connaissances structuré permet de faciliter les revues ultérieures.

Le titre de Tom's Hardware attirera l’attention parce qu’il oppose Claude Code à RSA-2048. L’histoire durable est moins cinématographique. Un utilisateur aurait combiné un agent d’IA à des outils spécialisés pour trouver un point faible autour d’une cryptographie robuste.

Cela reste lourd de conséquences. La sécurité échoue souvent là où les composants se rejoignent, et les agents de codage deviennent compétents pour suivre ces connexions. La prochaine question est de savoir si des chercheurs indépendants peuvent reproduire ce résultat sans reprendre les hypothèses de l’utilisateur d’origine.

D’ici là, considérez la modification du BIOS comme une étude de cas techniquement plausible, soigneusement décrite, mais non vérifiée. Suivez les reproductions, examinez toute réponse du fournisseur et distinguez un mécanisme d’application défaillant d’une cryptographie défaillante.