Claude Code half dabei, eine HP-BIOS-Signaturprüfung zu umgehen, ohne RSA-2048 zu brechen
Anthropic geriet in eine ungewöhnliche Sicherheitsdebatte, nachdem Claude Code Berichten zufolge dabei geholfen hatte, das BIOS eines HP-Laptops zu modifizieren und 55 versteckte Einstellungen offenzulegen. Die Schlagzeile von Tom's Hardware legt nahe, die KI habe RSA-2048 besiegt – einen der kryptografischen Standards zur Authentifizierung von Firmware. Die Belege stützen eine engere, aber dennoch wichtige Schlussfolgerung: Claude Code fand einen Weg um die Entscheidungslogik einer bestimmten Implementierung herum.
Der Unterschied ist entscheidend. Laut dem Besitzer des Laptops half Claude Code dabei, Verifikationscode zu lokalisieren, komprimierte Firmware-Module zu analysieren, einen Patch zu testen und ein funktionsfähiges Image neu zu erstellen. Es ermittelte weder den Signaturschlüssel von HP, noch fälschte es eine gültige Signatur oder löste das mathematische Problem hinter RSA-2048.
Das Ergebnis setzt daher zwei vertraute Annahmen unter Druck. Laptop-Hersteller gehen davon aus, dass Firmware-Kontrollen für normale Besitzer praktisch nicht rückentwickelbar bleiben. KI-Anbieter gehen davon aus, dass sich Coding-Agenten sicher als Produktivitätswerkzeuge einordnen lassen, selbst wenn Nutzer sie auf sicherheitskritische Systeme ansetzen.
Das Experiment funktionierte Berichten zufolge auf einem HP 15-dw1036ne mit BIOS-Version F.68. Es wurde keiner unabhängigen technischen Prüfung unterzogen, und die Übertragbarkeit auf andere Systeme bleibt ungewiss. Dennoch zeigt der Ablauf, wie ein KI-Coding-Agent den Arbeitsaufwand für spezialisierte Firmware-Forschung senken kann.
Claude Code machte aus einem BIOS-Dump eine funktionierende Modifikation
Die wesentliche Veränderung war kein neuer kryptografischer Angriff. Sie bestand darin, einen schwierigen Reverse-Engineering-Workflow in einer einzigen nutzergesteuerten KI-Sitzung zu verdichten.
Ein Reddit-Nutzer mit dem Namen Reddit_2049 erklärte, sein HP-Laptop habe jede veränderte Firmware mit der Meldung „BIOS Corruption Detected“ abgelehnt. Für dieses exakte Modell sei nach Angaben des Nutzers kein bekannter Unlock veröffentlicht worden. Sie stellten Claude Code einen BIOS-Dump und mehrere etablierte Reverse-Engineering-Tools bereit.
Der beschriebene Workflow kombinierte Ghidra, UEFITool, UEFIExtract, UEFIFind, Unicorn Engine, Capstone, Python und eine Kryptografie-Bibliothek. Jedes Programm erfüllt bereits einen klar erkennbaren technischen Zweck. Der berichtete Beitrag von Claude Code bestand darin, sie zu koordinieren, ihre Ausgabe zu interpretieren und Skripte für weitere Analysen zu erstellen.
Ghidra disassemblierte Firmware-Module und legte den relevanten Kontrollfluss offen. UEFI-Werkzeuge zerlegten das Image in Komponenten. Unicorn Engine emulierte die extrahierte Verifikationsroutine außerhalb des physischen Laptops und verringerte damit das Risiko, jede Änderung durch einen echten Firmware-Flash testen zu müssen.
Die Kryptografie-Bibliothek erzeugte gültige Testsignaturen für die emulierte Routine. Dieses Detail ist wichtig, weil es dem Nutzer erlaubte, gültige und beschädigte Eingaben zu vergleichen. Sie erzeugte keine gültige HP-Signatur für die modifizierte Firmware.
Laut dem ursprünglichen Nutzerbeitrag identifizierte die Analyse drei Gruppen von Änderungen. Eine umging eine Prüfung zum Schutz eines komprimierten DXE-Firmware-Volumes. Eine weitere legte 55 Setup-Felder offen. Eine dritte machte die Registerkarten Advanced, Power, Debug und Boot sichtbar.
DXE, kurz für Driver Execution Environment, ist eine UEFI-Phase, die Geräte und Dienste initialisiert, bevor das Betriebssystem startet. Firmware-Code auf dieser Ebene arbeitet unterhalb von Windows oder Linux. Fehler können verhindern, dass der Computer eines der beiden Betriebssysteme erreicht.
Die 55 Felder bestanden Berichten zufolge aus 27 unterdrückten und 28 ausgegrauten Einträgen. Ihre Definitionen waren bereits in den Setup-Formularen der Firmware vorhanden. Kleine Änderungen an hartcodierten Bedingungen machten diese Felder sichtbar.
Das bedeutet nicht, dass jede offengelegte Option unterstützte Hardware steuert. Der Nutzer räumte später ein, dass einige Einträge für den Laptop offenbar irrelevant waren, darunter eine GPS-Einstellung. Hersteller teilen Firmware-Komponenten häufig über mehrere Produkte hinweg und lassen in einer gemeinsamen Oberfläche inaktive Felder zurück.
Die vier zusätzlichen Registerkarten folgten einem ähnlichen Muster. Die Firmware enthielt sie, aber ihre Oberflächenlogik verhinderte ihre Anzeige bei diesem Modell. Der Patch veränderte diese Entscheidung, statt vollständig neue Konfigurationsfunktionen hinzuzufügen.
Der Nutzer erklärte, das resultierende Image laufe auf seinem Laptop. Außerdem veröffentlichte er ein Python-Skript, das die Änderungen aus einem unveränderten Dump reproduzieren soll. Der Beitrag warnte jedoch, dass das Skript nur auf der genannten Maschine getestet worden sei und möglicherweise nur auf eng verwandten Modellen funktioniere.
Dies bleibt eine selbstberichtete Demonstration. Weder HP noch Anthropic haben das modifizierte Image, die Analyse oder die daraus resultierenden Konfigurationsoptionen öffentlich bestätigt. Kein unabhängiger Forscher hat eine vollständige Reproduktion auf demselben Laptop-Modell veröffentlicht.
Diese Verifikationslücke sollte jede Interpretation der Tom's-Hardware-Geschichte prägen. In den begleitenden Details des Nutzers erscheint eine glaubwürdige technische Darstellung, doch ein erfolgreiches persönliches Experiment ist keine allgemeine Fähigkeit zum Entsperren von BIOS-Systemen.
Die Tom's-Hardware-Schlagzeile übertreibt, was mit RSA-2048 geschah
Claude Code umging Berichten zufolge den Software-Zweig, der ein Verifikationsergebnis durchsetzte. Es besiegte nicht den RSA-2048-Algorithmus selbst.
Digitale Signaturen ermöglichen es einem Gerät zu prüfen, ob Firmware von einem autorisierten Herausgeber stammt und unverändert geblieben ist. Der Hersteller signiert zugelassene Daten mit einem privaten Schlüssel. Ein Verifizierer verwendet den entsprechenden öffentlichen Schlüssel, um diese Signatur zu bestätigen.
Ein Brechen von RSA-2048 würde ein tiefgreifendes kryptografisches Ergebnis bedeuten. Ein Angreifer könnte einen privaten Schlüssel wiederherstellen, Signaturen ohne Autorisierung erzeugen oder die zugrunde liegenden mathematischen Annahmen überwinden. Der Reddit-Account beschreibt keines dieser Ergebnisse.
Stattdessen sagt der Nutzer, Claude Code habe den Code gefunden, der für die Behandlung des Signaturergebnisses zuständig war. Die Modifikation habe diesen Code Berichten zufolge auf seinen Erfolgspfad gezwungen, unabhängig davon, ob die mathematische Verifikation bestanden worden war.
Eine nützliche Analogie ist ein Wachmann, der einen gültigen Ausweis prüft und das Ergebnis anschließend in einem Protokoll festhält. Die berichtete Modifikation stellte keinen gültigen Ausweis her. Sie veränderte, was geschah, nachdem der Wachmann eine Antwort zurückgegeben hatte.
Dieser Unterschied macht das Ergebnis nicht trivial. Das Auffinden des relevanten Verifizierers in komprimierter Firmware erforderte Dekompression, Reverse Engineering, Code-Tracing und eine sorgfältige Rekonstruktion des Images. Ein modifiziertes Binärformat musste zudem die Struktur bewahren, die für den Start der Maschine erforderlich war.
Die kryptografische Primitive verhielt sich jedoch weiterhin wie vorgesehen. Die berichtete Schwäche lag im umgebenden Durchsetzungspfad und in der offensichtlichen Bereitschaft des Systems, modifizierten Verifikationscode auszuführen.
Die Firmware-Leitlinien von Microsoft erklären, warum diese Trennung wichtig ist. Signierter Firmware-Code sollte vor der Ausführung validiert werden, und nicht autorisierte Komponenten sollten nicht laufen. Eine Verifikationsfunktion bietet wenig Schutz, wenn eine frühere Vertrauensebene diese Funktion selbst nicht schützt.
Der Besitzer des Laptops erklärte, er habe keine Intel-Boot-Guard-Strukturen gefunden, die erforderlich wären, um den betroffenen Code an eine hardwaregestützte Vertrauenskette zu verankern. Intel Boot Guard ist ein Plattformmechanismus, der frühe Boot-Komponenten authentifizieren soll, bevor die Haupt-Firmware fortfährt.
Diese Behauptung wurde für diese konkrete Maschine nicht unabhängig bestätigt. Sollte sie jedoch zutreffen, erklärt sie, warum das Bearbeiten des Verifizierers einen Neustart überstehen konnte. Die Implementierung vertraute darauf, dass in beschreibbarem Flash gespeicherter Code entschied, ob anderem Code vertraut werden sollte.
Dies ist die zentrale Umkehrung. RSA-2048 kann mathematisch sicher bleiben, während ein Produkt, das es verwendet, dennoch nicht autorisierte Firmware akzeptiert. Sicherheit hängt von der vollständigen Verifikationskette ab, nicht vom Namen oder der Schlüssellänge eines einzelnen Algorithmus.
Für diese Unterscheidung gibt es historische Präzedenzfälle. Forscher, die den Nintendo 3DS untersuchten, dokumentierten eine RSA-Signaturimplementierung, die wegen Parserfehlern nicht autorisierte Firmware akzeptierte. Ihre Boot-ROM-Forschung richtete sich darauf, wie Signaturen verarbeitet wurden, nicht auf die mathematische Härte von RSA-2048.
Die HP-Modifikation unterscheidet sich technisch davon. Der veröffentlichte Bericht beschreibt einen veränderten Kontrollfluss statt einer fehlerhaften Signatur, die einen Parser ausnutzt. Beide Fälle zeigen, warum „verwendet RSA-2048“ keine vollständige Sicherheitsausage ist.
Die Einordnung von Tom's Hardware droht außerdem, Claude Code zu viel Autonomie zuzuschreiben. Der Mensch stellte die Firmware bereit, wählte Werkzeuge aus, genehmigte Aktionen, testete die Ergebnisse und akzeptierte das Risiko, modifizierten Code zu flashen. Claude arbeitete innerhalb einer vom Nutzer entworfenen Forschungsumgebung.
Eine präzisere Schlagzeile würde sagen, dass Claude Code bei der Umgehung einer RSA-2048-Signaturprüfung auf einem HP-Firmware-Build geholfen hat. Das bleibt bemerkenswert, weil der Assistent Berichten zufolge ein Gebiet navigierte, das normalerweise beträchtliches Spezialwissen erfordert.
Die eigentliche Verschiebung ist KI-gestütztes Reverse Engineering
Das Experiment legt nahe, dass Coding-Agenten fortgeschrittene technische Workflows für ausdauerndere Nutzer zugänglich machen können, selbst wenn die zugrunde liegende Schwachstelle konventionell ist.
Firmware-Reverse-Engineering erforderte historisch Kenntnisse in Assembler-Code, Binärformaten, Kompression, Kryptografie, Hardware-Initialisierung und Wiederherstellungsverfahren. Kein einzelner Schritt im berichteten Workflow ist beispiellos. Die Koordination aller Schritte bleibt schwierig.
KI-Agenten verändern diese Koordinationskosten. Sie können Tool-Ausgaben untersuchen, die nächste Abfrage vorschlagen, kleine Analysewerkzeuge erzeugen, Hypothesen nachverfolgen und Skripte umschreiben, wenn ein Binärlayout von den Erwartungen abweicht. Diese Arbeit erforderte früher wiederholte Recherchen in Handbüchern, Foren und Quellcode-Repositories.
Claude Code agierte offenbar nicht als Hacking-Schaltfläche für einen einzelnen Klick. Der Bericht beschreibt stattdessen einen iterativen Prozess. Der Nutzer stellte Zugang zu Spezialwerkzeugen bereit, während das Modell Teilerkenntnisse über sie hinweg verband.
Dieses Muster ist wichtiger als die sichtbaren BIOS-Registerkarten. Ein Modell muss keinen neuen Exploit erfinden, um die Ökonomie der Sicherheitsforschung zu verändern. Es muss lediglich mehr Menschen helfen, vertraute Analysen schneller abzuschließen.
Der Fall zeigt auch, warum agentische Systeme sich von konversationellen Chatbots unterscheiden. Ein Agent kann Dateien untersuchen, Programme aufrufen, Code erzeugen und die Ergebnisse einer Aktion nutzen, um die nächste zu planen. Diese Schleife schafft Hebelwirkung bei Aufgaben, deren Fortschritt von Dutzenden kleiner technischer Entscheidungen abhängt. Anthropic beschreibt Claude Code als ein agentisches Coding-System, das Codebasen lesen, Dateien bearbeiten, Tests ausführen und mit externen Tools arbeiten kann.
Für Entwickler lautet die Lehre nicht, dass Claude Code zu einem autonomen Firmware-Experten geworden ist. Sie lautet, dass ein fähiger Nutzer ein temporäres Forschungsteam aus einem Modell und mehreren deterministischen Werkzeugen aufbauen kann.
Die bereitgestellten Werkzeuge lieferten wichtige Formen der Verankerung. Ein Disassembler legte Maschineninstruktionen offen. Ein Emulator ermöglichte isolierte Tests. Binärwerkzeuge bewahrten die interne Struktur der Firmware. Die Vorschläge des Modells wurden anhand von Programmausgaben geprüft, statt als bloßer Text akzeptiert zu werden.
Diese Kombination kann das Risiko von Halluzinationen verringern, aber nicht vollständig beseitigen. Ein Modell kann eine Adresse missverstehen, zwei Firmware-Phasen verwechseln oder einen unsicheren Patch empfehlen. In gewöhnlichem Anwendungscode fangen Tests solche Fehler häufig auf. Firmware-Fehler können dazu führen, dass ein Gerät nicht mehr startet.
That erhöht den Druck auf Anthropic und andere KI-Anbieter. Ihre Programmierprodukte operieren zunehmend in den Bereichen Sicherheitsforschung, Systemadministration und Hardwaresteuerung. Dieselben Fähigkeiten, die einem rechtmäßigen Eigentümer bei der Untersuchung eines Laptops helfen, können Angreifern auch dabei helfen, Firmware-Schutzmechanismen zu analysieren.
Der entscheidende Wettbewerb lautet daher Fähigkeit gegen Verifikation. Modelle können ehrgeizigere Änderungen vorschlagen, doch Nutzer benötigen weiterhin verlässliche Wege, diese Änderungen zu testen. Der HP-Besitzer nutzte Emulation und hielt Berichten zufolge einen Hardware-Programmer für die Wiederherstellung bereit.
Hier können auch persönliche Wissenssysteme technischen Teams helfen. Forschende müssen Tool-Ausgaben, Hypothesen, Hardware-Kennungen und Testergebnisse über lange Untersuchungen hinweg bewahren. Eine durchsuchbare Engineering-Wissensbasis kann diese Dokumentation unterstützen, ohne vorzugeben, die Firmware selbst zu validieren.
Die Branche insgesamt sollte erwarten, dass Coding-Agenten in ungewöhnlichere technische Umgebungen vordringen. Reverse Engineering, Embedded-Entwicklung, Treiber-Debugging und Protokollanalyse enthalten allesamt repetitive Aufgaben, die Modelle beschleunigen können.
Diese Ausweitung wird Fachwissen nicht überflüssig machen. Sie verändert, an welcher Stelle Fachwissen unverzichtbar wird. Nutzer verbringen möglicherweise weniger Zeit mit dem Schreiben von Hilfsskripten und mehr Zeit mit der Definition von Bedrohungsmodellen, der Überprüfung von Annahmen und dem Entwurf sicherer Tests.
Der Fall von Tom's Hardware fasst diesen Wandel prägnant zusammen. Claude Code übernahm Berichten zufolge genug analytische Arbeit, um einem Enthusiasten dabei zu helfen, eine Hürde zu überwinden. Die Verantwortung für die Folgen lag weiterhin beim Menschen.
Versteckte Einstellungen schaffen Vorteile für Eigentümer und Sicherheitsrisiken
Das Entsperren eines Geräts kann die Kontrolle des Eigentümers wiederherstellen, doch Experimente auf Firmware-Ebene haben Folgen, die ein KI-Assistent dem Nutzer nicht abnehmen kann.
Laptop-Hersteller verbergen BIOS-Einstellungen aus mehreren Gründen. Manche Optionen gelten nicht für die installierte Hardware. Andere können Arbeitsspeicher, Temperatursteuerung, Speicher, Energieverwaltung oder das Boot-Verhalten destabilisieren.
Gemeinsame Firmware liefert eine weitere Erklärung. Ein Hersteller kann ähnliche Setup-Codebasen über viele Modelle hinweg verwenden und dann nur die für jedes Produkt validierten Felder freigeben. Versteckte Optionen können daher ungenutzte Schnittstellenbestandteile darstellen, statt zurückgehaltene funktionsfähige Features.
Die berichtete GPS-Option veranschaulicht diese Einschränkung. Das Sichtbarmachen eines Menüeintrags schafft weder ein fehlendes Funkmodul, eine Antenne, einen Treiber noch eine Board-Verbindung. Ein angezeigtes Feld kann wirkungslos, irreführend oder unsicher sein.
Manche Nutzer haben dennoch legitime Gründe, tiefere Kontrolle zu suchen. Erweiterte Einstellungen können bei Virtualisierung, Speichermodi, Energieoptimierung, Debugging oder nicht unterstützten Betriebssystemen helfen. Auch Reparaturtechniker und Forschende benötigen möglicherweise Zugriff, den Verbraucherschnittstellen vorenthalten.
Die Spannung besteht nicht einfach zwischen Herstellersicherheit und Nutzerfreiheit. Es geht um validierte Konfiguration gegenüber unkontrollierten Experimenten. Hersteller tragen Support- und Garantiekosten, wenn nicht dokumentierte Kombinationen Ausfälle verursachen, während Eigentümer zu Recht Entscheidungsbefugnis über gekaufte Hardware erwarten.
KI verschärft beide Seiten. Sie kann Eigentümern helfen, undurchsichtige Firmware zu verstehen und Funktionen wiederherzustellen. Sie kann aber auch selbstsicher klingende Anweisungen für Kombinationen erzeugen, die auf dem Ziel-Board nie getestet wurden.
Der ursprüngliche Poster empfahl ausdrücklich, einen Chip-Programmer im Stil eines CH341A bereitzuhalten. Solche Hardware kann einen Flash-Chip direkt neu beschreiben, wenn der Laptop nicht mehr startet. Diese Warnung zeigt das tatsächliche Risikoniveau besser als die erfolgreichen Screenshots.
Selbst ein Programmer garantiert keine reibungslose Wiederherstellung. Der Zugriff auf den Chip kann das Öffnen des Laptops, die Identifikation des richtigen Gehäuses, die Kontrolle der Spannungspegel und die Sicherung eines Original-Dumps erfordern. Ein Fehler kann Hardware beschädigen oder gerätespezifische Daten löschen.
Firmware befindet sich zudem in einer hochprivilegierten Position. Bösartiger oder fehlerhafter Code kann vor dem Betriebssystem ausgeführt werden und normale Neuinstallationen überdauern. Sicherheitsforschende behandeln nicht autorisierte Firmware-Modifikationen daher anders als gewöhnliche Anpassungen von Anwendungen.
Jüngste wissenschaftliche Arbeiten argumentieren, dass statische Prüfungen allein nicht jede Firmware-Bedrohung beobachten können. Das Peacock-Framework schlägt Laufzeitüberwachung vor, weil Angreifer das Firmware-Verhalten nach anfänglichen Prüfungen manipulieren können. Diese Forschung unterstreicht die Notwendigkeit mehrschichtiger Schutzmaßnahmen.
Der berichtete HP-Fall belegt nicht, dass der Laptop aus der Ferne angreifbar wurde. Der Nutzer besaß die Maschine bereits, beschaffte deren Firmware und installierte absichtlich ein modifiziertes Image. Physischer Besitz und Absicht sind für dieses Szenario zentral.
Der Umgehungsweg wäre jedoch bedeutsamer, wenn ein anderer Pfad einem nicht vertrauenswürdigen Akteur das Schreiben in die betroffene Flash-Region ermöglichen würde. Die Kombination aus einer Schreibmöglichkeit und schwacher Boot-Durchsetzung kann eine lokale Modifikationstechnik in ein Persistenzrisiko verwandeln.
Im Quellenmaterial gibt es keine Hinweise darauf, dass für dieses Modell ein solcher Fernzugriffspfad existiert. Es wäre unverantwortlich zu behaupten, dass nun Millionen von HP-Laptops gefährdet seien. Der Befund betrifft ein Firmware-Image und eine berichtete Installation.
Die Übertragbarkeit ist eine weitere große Unsicherheit. Firmware verändert sich zwischen Modellen, Mainboard-Revisionen und BIOS-Versionen. Adressen verschieben sich, Module ändern sich, und stärkere Vertrauensmechanismen können denselben Ansatz ablehnen.
Der Nutzer sagte, eine Änderung zum Entsperren von Tabs sei bereits gescheitert, als sie für ein anderes HP-Board versucht wurde. Diese Rückmeldung widerlegt die Vorstellung eines universellen Skripts. Sie stützt auch eine interessantere Interpretation: KI kann helfen, maßgeschneiderte Forschung schneller anzupassen – ein Ziel nach dem anderen.
HP könnte mit künftigen Firmware-Updates, stärkeren Schreibkontrollen oder einer früheren verifizierten Boot-Komponente reagieren. HP erklärt, dass seine hardwaregestützte Sure Start-Technologie darauf ausgelegt ist, nicht autorisierte Firmware-Änderungen zu verhindern und kompromittierten BIOS-Code wiederherzustellen, doch das Quellenmaterial belegt nicht, dass dieser Verbraucher-Laptop diesen Schutz enthält. Der Besitzer des Laptops sagte, das letzte Firmware-Update sei 2024 eingetroffen. Ältere Verbrauchergeräte erhalten möglicherweise nie eine Neugestaltung ihrer Vertrauenskette.
Anthropic steht vor einer eigenen Frage zu Schutzmaßnahmen. Die Arbeit weist klare Dual-Use-Eigenschaften auf, das heißt, sie kann legitime Forschung ebenso wie schädliche Modifikationen unterstützen. Eine pauschale Verweigerung würde Eigentümer und Verteidiger blockieren, während uneingeschränkte Automatisierung die Hürden für Angreifer senken kann.
Eine sinnvolle Sicherheitsgrenze hängt von Kontext, Zugriff, Absicht und operativen Details ab. Zu erklären, warum eine Signaturprüfung fehlgeschlagen ist, unterscheidet sich davon, bei der Bereitstellung heimlicher Persistenz auf mehreren Geräten zu helfen. Modellanbieter müssen diese Szenarien unterscheiden, ohne jede Firmware-Aufgabe als böswillig einzustufen.
Ein erfolgreich entsperrter Laptop belegt keine allgemeine Fähigkeit
Die Demonstration ist als Fallstudie überzeugend, aber ein schwacher Beleg dafür, dass Claude Code moderne BIOS-Schutzmechanismen zuverlässig entsperren kann.
Die stärksten Belege stammen aus dem detaillierten Bericht des Nutzers. Er nannte den Laptop, die BIOS-Version, Tools, Firmware-Strukturen, entdeckte Felder und den allgemeinen Validierungsprozess. Zudem legte er Einschränkungen offen, statt universelle Kompatibilität zu behaupten.
Der schwächste Beleg ist die unabhängige Reproduktion. Kein separater Analyst hat öffentlich dasselbe Ergebnis mit einem sauberen F.68-Image auf einem anderen HP 15-dw1036ne dokumentiert. HP hat weder die Architektur bestätigt noch den berichteten Umgehungsweg bewertet.
Auch das sichtbare Ergebnis kann nicht jeden Schritt der Erklärung beweisen. Fotos neuer Menü-Tabs würden zeigen, dass eine modifizierte Oberfläche gestartet wurde. Sie würden nicht belegen, welcher Codepfad die Firmware akzeptierte oder ob ein anderer Schutz zuvor deaktiviert wurde.
Das veröffentlichte Skript liefert zusätzliches Material zur Prüfung, doch seine Ausführung ist für gewöhnliche Leser keine sichere Verifikationsmethode. Ein verantwortungsvoller Audit würde den Code untersuchen, binäre Transformationen offline reproduzieren und die Ausgabe mit unabhängig beschaffter Firmware vergleichen.
Forschende müssten außerdem das behauptete Fehlen einer Intel-Boot-Guard-Durchsetzung bestätigen. Diese Prüfung entscheidet, ob der berichtete Erfolg auf einer fehlenden hardwaregestützten Vertrauenswurzel beruhte. Sie begrenzt zudem Schlussfolgerungen zu neueren oder geschäftsorientierten Systemen.
Die Modellzuordnung bleibt unpräzise. Der Reddit-Nutzer sagte, er habe hauptsächlich Claude Opus 4.8 und gelegentlich Sonnet 5 über Claude Code verwendet. Die Dokumentation isoliert weder, welches Modell welches Element fand, noch wie stark menschliche Anleitung den endgültigen Ansatz prägte.
Der Prompt-Verlauf würde helfen, Entdeckung von angeleiteter Implementierung zu unterscheiden. Falls der Nutzer wahrscheinliche Modulnamen, bekannte Firmware-Muster oder Kandidatenzweige bereitstellte, unterscheidet sich Claudes Beitrag von einer weitgehend unabhängigen Suche.
Token-Zahlen, fehlgeschlagene Versuche und die verstrichene Zeit würden zusätzlichen Kontext liefern. Ein Workflow, der umfangreiche Eingriffe erforderte, hat weiterhin Wert, sagt aber weniger über autonome Leistung aus als ein reproduzierbarer Durchlauf von einem sauberen Ausgangspunkt.
Die Formulierung „KI besiegt RSA-2048“ besteht diesen Belastungstest nicht. Die berichtete Modifikation griff nicht den Schlüsselraum von RSA an. Sie umging einen Mechanismus zur Ergebnisbehandlung auf einem System, dem angeblich eine weitere Schicht fehlte, die diesen Mechanismus hätte schützen können.
Diese Korrektur sollte nicht zur Ausrede werden, die Arbeit abzutun. Den relevanten Code in komprimierter Firmware zu finden, kann erheblichen menschlichen Zeitaufwand erfordern. Das erneute Packen des Images, ohne Offsets oder Abhängigkeiten zu beschädigen, stellt eine weitere praktische Herausforderung dar.
Die wichtige Frage lautet, ob Claude Code diesen Aufwand konsistent reduziert. Eine einzelne Anekdote kann sie nicht beantworten. Eine sinnvolle Bewertung würde mehreren Forschenden mehrere Firmware-Ziele geben und Abschlusszeit, Genauigkeit sowie unsichere Empfehlungen vergleichen.
Solche Tests sollten geschützte und ungeschützte Plattformen umfassen. Ein Agent muss erkennen, wenn ein vorgeschlagener Patch eine hardwaregestützte Verifikationsstufe nicht überstehen kann. An einer falschen Theorie festzuhalten, könnte Zeit verschwenden oder ein Gerät beschädigen.
Forschende sollten außerdem messen, ob das Modell nicht belegte Bedeutungen für versteckte Einstellungen erfindet. Schnittstellenbeschriftungen allein beweisen nicht, dass ein Feature funktioniert. Das sicherste System würde zwischen „Feld entdeckt“, „Feld angezeigt“ und „Verhalten validiert“ unterscheiden.
Bis diese Tests existieren, gehört die Geschichte von Tom's Hardware in die Kategorie berichteter KI-gestützter Sicherheitsforschung. Sie demonstriert keinen universell einsetzbaren automatisierten BIOS-Exploit. Sie zeigt jedoch, dass spezialisierte Tool-Nutzung Nicht-Spezialisten näherkommt.
Drei Signale werden zeigen, ob dies eine Anekdote oder ein Wendepunkt war
Die nächsten Belege sollten aus Reproduktion, Herstelleranalyse und breiteren Agentenbewertungen stammen – nicht aus einer weiteren dramatischen Schlagzeile.
Das erste Signal ist die unabhängige Reproduktion auf demselben Modell und derselben Firmware. Ein glaubwürdiger Forscher müsste ein sauberes Image beschaffen, die relevanten Module bestätigen, die Änderungen reproduzieren und Vorsichtsmaßnahmen zur Wiederherstellung dokumentieren.
Eine erfolgreiche Reproduktion würde die Behauptung stärken, dass der technische Bericht den Vertrauenspfad des Laptops zutreffend beschreibt. Ein Fehlschlag würde nahelegen, dass ein nicht dokumentierter Gerätezustand, eine vorherige Modifikation oder ein fehlender Schritt das Ergebnis beeinflusst hat.
Das zweite Signal ist eine Reaktion von HP oder dem zugrunde liegenden Firmware-Lieferanten. Der Hersteller könnte bestätigen, ob das betroffene Volume voraussichtlich durch einen anderen Mechanismus geschützt sein sollte. Er könnte außerdem klarstellen, ob der Laptop das Ende des aktiven Firmware-Supports erreicht hat.
Ein Firmware-Update, das den Verifizierer über einen früheren Vertrauensanker schützt, würde die Sicherheitsrelevanz des Berichts bestätigen. Eine Herstellerfeststellung, dass die Modifikation uneingeschränktes physisches Flashen erforderte, würde ihre Bedrohungsimplikationen eingrenzen.
Das dritte Signal ist eine wiederholbare Leistung von KI-Agenten über verschiedene Firmware-Ziele hinweg. Forschende sollten beobachten, ob Claude Code vergleichbare Implementierungsfehler ohne zielsystemspezifische Anleitung finden kann. Sie sollten Fehlalarme und beschädigte Test-Images ebenso dokumentieren wie erfolgreiche Fälle.
Wiederholter Erfolg würde zeigen, dass KI-Agenten die Zugänglichkeit von Firmware-Reverse-Engineering verändern. Uneinheitliche Ergebnisse würden diesen Fall als beeindruckende Zusammenarbeit zwischen einem motivierten Nutzer und einem Modell einordnen – nicht als allgemein verfügbare Fähigkeit.
Leserinnen und Leser sollten außerdem darauf achten, wie KI-Unternehmen diese Systeme beschreiben. „Coding Assistant“ erfasst nicht mehr angemessen einen Agenten, der Disassembler, Emulatoren, Binärwerkzeuge und kryptografische Tests koordinieren kann. Produktsicherheitsversprechen müssen die Umgebungen berücksichtigen, die Nutzer rund um das Modell aufbauen können.
Für Entwickler und Sicherheitsteams lautet die praktische Antwort: disziplinierte Verifikation. Bewahren Sie Original-Images auf, isolieren Sie Tests, dokumentieren Sie Annahmen und verlangen Sie vor der Bereitstellung eine hardwarespezifische Prüfung. Von KI erzeugte Zuversicht ist kein Ersatz für einen Wiederherstellungsweg.
Wissensarbeiterinnen und Wissensarbeiter können daraus eine verwandte Lehre ziehen. Agenten werden nützlicher, wenn ihre Arbeit auf nachvollziehbaren Belegen beruht. Das Speichern von Prompts, Ausgaben, Binär-Hashes und Testbeobachtungen in einem strukturierten persönlichen Wissenssystem ermöglicht spätere Überprüfungen.
Die Schlagzeile von Tom's Hardware wird Aufmerksamkeit erregen, weil sie Claude Code gegen RSA-2048 stellt. Die dauerhafte Geschichte ist weniger filmreif. Ein Nutzer hat Berichten zufolge einen KI-Agenten mit Spezialwerkzeugen kombiniert, um eine Schwachstelle rund um solide Kryptografie zu finden.
Das ist dennoch folgenreich. Sicherheit scheitert häufig dort, wo Komponenten miteinander verbunden sind, und Coding-Agenten werden immer besser darin, diese Verbindungen nachzuverfolgen. Die nächste Frage lautet, ob unabhängige Forschende dieses Ergebnis reproduzieren können, ohne die Annahmen des ursprünglichen Nutzers zu übernehmen.
Bis dahin sollte die BIOS-Modifikation als technisch plausibler, sorgfältig beschriebener, aber nicht verifizierter Fall angesehen werden. Verfolgen Sie die Reproduktionen, prüfen Sie mögliche Reaktionen des Herstellers und unterscheiden Sie zwischen fehlerhafter Durchsetzung und gebrochener Kryptografie.
