Claude Code pomógł ominąć sprawdzanie podpisu BIOS-u HP bez złamania RSA-2048

Anthropic znalazł się w centrum nietypowej debaty dotyczącej bezpieczeństwa po tym, jak Claude Code miał pomóc zmodyfikować BIOS jednego laptopa HP i ujawnić 55 ukrytych ustawień. Nagłówek Tom's Hardware sugeruje, że AI pokonała RSA-2048 — jeden ze standardów kryptograficznych wykorzystywanych do uwierzytelniania firmware’u. Dowody wskazują na węższy, lecz nadal istotny wniosek: Claude Code znalazł sposób na ominięcie logiki decyzyjnej jednej implementacji.

To rozróżnienie ma znaczenie. Według właściciela laptopa Claude Code pomógł zlokalizować kod weryfikacyjny, przeanalizować skompresowane moduły firmware’u, przetestować poprawkę i zbudować działający obraz. Nie odzyskał klucza podpisującego HP, nie sfałszował prawidłowego podpisu ani nie rozwiązał problemu matematycznego leżącego u podstaw RSA-2048.

Wynik podważa zatem dwa znane założenia. Producenci laptopów zakładają, że inżynieria wsteczna mechanizmów firmware’u pozostaje niepraktyczna dla zwykłych właścicieli. Dostawcy AI zakładają, że agentów programistycznych można bezpiecznie przedstawiać jako narzędzia zwiększające produktywność, nawet gdy użytkownicy kierują je ku systemom wrażliwym pod względem bezpieczeństwa.

Eksperyment miał zadziałać na jednym HP 15-dw1036ne z BIOS-em w wersji F.68. Nie przeszedł niezależnego audytu technicznego, a możliwość przeniesienia go na inne systemy pozostaje niepewna. Mimo to ten proces pokazuje, jak agent AI do programowania może zmniejszyć nakład pracy wymagany do specjalistycznych badań nad firmware’em.

Claude Code przekształcił jeden zrzut BIOS-u w działającą modyfikację

Istotną zmianą nie był nowy atak kryptograficzny. Było nią skondensowanie trudnego procesu inżynierii wstecznej do jednej, sterowanej przez użytkownika sesji AI.

Użytkownik Reddita publikujący jako Reddit_2049 powiedział, że jego laptop HP odrzucał każde zmienione firmware z komunikatem „BIOS Corruption Detected”. Według użytkownika nikt nie opublikował znanego odblokowania dla dokładnie tego modelu. Udostępnił Claude Code zrzut BIOS-u oraz kilka uznanych narzędzi do inżynierii wstecznej.

Opisany proces łączył Ghidra, UEFITool, UEFIExtract, UEFIFind, Unicorn Engine, Capstone, Python oraz bibliotekę kryptograficzną. Każdy program ma już rozpoznawalne zastosowanie techniczne. Zgłaszanym wkładem Claude Code było koordynowanie ich pracy, interpretowanie wyników oraz tworzenie skryptów do dodatkowej analizy.

Ghidra zdeasemblowała moduły firmware’u i ujawniła istotny przepływ sterowania. Narzędzia UEFI podzieliły obraz na komponenty. Unicorn Engine emulował wyodrębnioną procedurę weryfikacyjną poza fizycznym laptopem, zmniejszając ryzyko testowania każdej zmiany poprzez rzeczywiste flashowanie firmware’u.

Biblioteka kryptograficzna wygenerowała prawidłowe podpisy testowe dla emulowanej procedury. Ten szczegół ma znaczenie, ponieważ pozwolił użytkownikowi porównać prawidłowe i uszkodzone dane wejściowe. Nie utworzył prawidłowego podpisu HP dla zmodyfikowanego firmware’u.

Według oryginalnego wpisu użytkownika analiza zidentyfikowała trzy grupy zmian. Jedna omijała kontrolę chroniącą skompresowany wolumin firmware’u DXE. Inna ujawniała 55 pól konfiguracji. Trzecia odsłaniała zakładki Advanced, Power, Debug i Boot.

DXE, czyli Driver Execution Environment, to faza UEFI inicjalizująca urządzenia i usługi przed uruchomieniem systemu operacyjnego. Kod firmware’u na tym poziomie działa poniżej Windows lub Linuxa. Błędy mogą uniemożliwić komputerowi uruchomienie któregokolwiek z tych systemów.

Wspomniane 55 pól miało obejmować 27 ukrytych wpisów i 28 wyszarzonych wpisów. Ich definicje już istniały w formularzach konfiguracji firmware’u. Niewielkie zmiany w zakodowanych na stałe warunkach sprawiły, że pola stały się widoczne.

Nie oznacza to, że każda ujawniona opcja steruje obsługiwanym sprzętem. Użytkownik później przyznał, że niektóre wpisy wydawały się nieistotne dla laptopa, w tym ustawienie GPS. Producenci często współdzielą komponenty firmware’u między kilkoma produktami, pozostawiając nieaktywne pola we wspólnym interfejsie.

Cztery dodatkowe zakładki działały według podobnego schematu. Firmware je zawierał, lecz jego logika interfejsu uniemożliwiała ich wyświetlanie w tym modelu. Poprawka zmieniła tę decyzję, zamiast dodawać całkowicie nowe funkcje konfiguracji.

Użytkownik powiedział, że uzyskany obraz działał na jego laptopie. Opublikował też skrypt Python, który miał odtwarzać zmiany na podstawie fabrycznego zrzutu. Wpis ostrzegał jednak, że skrypt testowano wyłącznie na wskazanej maszynie i może działać tylko na blisko spokrewnionych modelach.

Pozostaje to demonstracją opartą na relacji autora. Ani HP, ani Anthropic nie zweryfikowały publicznie zmodyfikowanego obrazu, analizy ani wynikowych opcji konfiguracji. Żaden niezależny badacz nie opublikował pełnego odtworzenia eksperymentu na tym samym modelu laptopa.

Ta luka w weryfikacji powinna kształtować każdą interpretację historii Tom's Hardware. W szczegółach przedstawionych przez użytkownika pojawia się wiarygodna narracja techniczna, lecz jeden udany eksperyment osobisty nie stanowi ogólnej możliwości odblokowywania BIOS-ów.

Nagłówek Tom's Hardware wyolbrzymia to, co stało się z RSA-2048

Claude Code miał ominąć gałąź programową egzekwującą wynik weryfikacji. Nie pokonał samego algorytmu RSA-2048.

Podpisy cyfrowe pozwalają urządzeniu sprawdzić, czy firmware pochodzi od autoryzowanego wydawcy i pozostał niezmieniony. Dostawca podpisuje zatwierdzone dane za pomocą klucza prywatnego. Weryfikator używa odpowiadającego mu klucza publicznego, aby potwierdzić ten podpis.

Złamanie RSA-2048 oznaczałoby przełomowy wynik kryptograficzny. Atakujący mógłby odzyskać klucz prywatny, tworzyć podpisy bez upoważnienia albo pokonać podstawowe założenia matematyczne. Konto na Reddicie nie opisuje żadnego z tych rezultatów.

Zamiast tego użytkownik twierdzi, że Claude Code znalazł kod odpowiedzialny za obsługę wyniku podpisu. Modyfikacja miała wymuszać przejście tego kodu ścieżką sukcesu, niezależnie od tego, czy weryfikacja matematyczna zakończyła się powodzeniem.

Pomocna analogia to ochroniarz sprawdzający prawidłową przepustkę, a następnie zapisujący odpowiedź w dzienniku. Opisana modyfikacja nie wytworzyła prawidłowej przepustki. Zmieniła to, co działo się po zwróceniu odpowiedzi przez ochroniarza.

Ta różnica nie czyni rezultatu trywialnym. Zlokalizowanie odpowiedniego weryfikatora w skompresowanym firmware wymagało dekompresji, inżynierii wstecznej, śledzenia kodu oraz starannej rekonstrukcji obrazu. Zmodyfikowany plik binarny musiał również zachować strukturę potrzebną do uruchomienia maszyny.

Mimo to prymityw kryptograficzny nadal działał zgodnie z projektem. Zgłoszona słabość znajdowała się w otaczającej ścieżce egzekwowania i w pozornej gotowości systemu do wykonywania zmodyfikowanego kodu weryfikacyjnego.

Wskazówki Microsoftu dotyczące firmware’u wyjaśniają, dlaczego to rozdzielenie ma znaczenie. Podpisany kod firmware’u powinien być zweryfikowany przed wykonaniem, a nieautoryzowane komponenty nie powinny się uruchamiać. Funkcja weryfikacyjna zapewnia niewielką ochronę, jeśli wcześniejsza warstwa zaufania nie chroni samej tej funkcji.

Właściciel laptopa powiedział, że nie znalazł struktur Intel Boot Guard wymaganych do zakotwiczenia dotkniętego kodu w łańcuchu zaufania wspieranym sprzętowo. Intel Boot Guard to mechanizm platformowy zaprojektowany do uwierzytelniania wczesnych komponentów rozruchowych, zanim główny firmware będzie kontynuował działanie.

To twierdzenie nie zostało niezależnie potwierdzone dla tej konkretnej maszyny. Jeśli jednak jest trafne, wyjaśnia, dlaczego edycja weryfikatora mogła przetrwać ponowne uruchomienie. Implementacja ufała kodowi przechowywanemu w zapisywalnej pamięci flash przy decydowaniu, czy należy ufać innemu kodowi.

To jest kluczowe odwrócenie sytuacji. RSA-2048 może pozostać matematycznie bezpieczne, podczas gdy produkt korzystający z niego nadal akceptuje nieautoryzowany firmware. Bezpieczeństwo zależy od kompletnego łańcucha weryfikacji, a nie od nazwy lub długości klucza jednego algorytmu.

Istnieją historyczne precedensy dla tego rozróżnienia. Badacze analizujący Nintendo 3DS udokumentowali implementację podpisu RSA, która akceptowała nieautoryzowany firmware z powodu błędów parsera. Ich badania boot ROM-u dotyczyły sposobu przetwarzania podpisów, a nie matematycznej trudności RSA-2048.

Modyfikacja HP jest technicznie inna. Opublikowana relacja opisuje zmieniony przepływ sterowania, a nie nieprawidłowo sformowany podpis wykorzystujący błąd parsera. Oba przypadki pokazują, dlaczego stwierdzenie „używa RSA-2048” nie jest pełnym opisem bezpieczeństwa.

Ujęcie Tom's Hardware grozi również przypisaniem Claude Code zbyt dużej autonomii. Człowiek dostarczył firmware, wybrał narzędzia, zatwierdził działania, przetestował wyniki i zaakceptował ryzyko flashowania zmodyfikowanego kodu. Claude działał w środowisku badawczym zaprojektowanym przez użytkownika.

Dokładniejszy nagłówek brzmiałby, że Claude Code pomógł ominąć kontrolę podpisu RSA-2048 w jednej kompilacji firmware’u HP. To nadal uderzające, ponieważ asystent miał poruszać się w domenie, która zwykle wymaga znacznej specjalistycznej wiedzy.

Rzeczywistą zmianą jest inżynieria wsteczna wspomagana przez AI

Eksperyment sugeruje, że agenci programistyczni mogą udostępniać zaawansowane procesy techniczne bardziej wytrwałym użytkownikom, nawet gdy leżąca u podstaw podatność jest konwencjonalna.

Inżynieria wsteczna firmware’u historycznie wymagała biegłości w kodzie asemblerowym, formatach binarnych, kompresji, kryptografii, inicjalizacji sprzętu i procedurach odzyskiwania. Żaden pojedynczy etap opisanego procesu nie jest bezprecedensowy. Skoordynowanie wszystkich etapów nadal pozostaje trudne.

Agenci AI zmieniają koszt tej koordynacji. Mogą analizować dane wyjściowe narzędzi, proponować kolejne zapytanie, generować niewielkie narzędzia analityczne, śledzić hipotezy i przepisywać skrypty, gdy układ binarny różni się od oczekiwań. Taka praca wcześniej wymagała wielokrotnych poszukiwań w podręcznikach, na forach i w repozytoriach źródłowych.

Claude Code najwyraźniej nie działał jak przycisk do jednorazowego hakowania. Relacja opisuje raczej iteracyjny proces. Użytkownik zapewnił dostęp do specjalistycznych narzędzi, podczas gdy model łączył częściowe ustalenia między nimi.

Ten schemat jest ważniejszy niż widoczne zakładki BIOS-u. Model nie musi wymyślić nowego exploita, by zmienić ekonomikę badań nad bezpieczeństwem. Wystarczy, że pomoże większej liczbie osób szybciej ukończyć znaną analizę.

Przypadek pokazuje też, dlaczego systemy agentowe różnią się od konwersacyjnych chatbotów. Agent może analizować pliki, wywoływać programy, generować kod i wykorzystywać wyniki jednego działania do zaplanowania kolejnego. Ta pętla tworzy przewagę w zadaniach, w których postęp zależy od dziesiątek drobnych decyzji technicznych. Anthropic opisuje Claude Code jako agentowy system programistyczny, który może czytać bazy kodu, edytować pliki, uruchamiać testy i współpracować z narzędziami zewnętrznymi.

Dla deweloperów lekcja nie polega na tym, że Claude Code stał się autonomicznym ekspertem od firmware’u. Polega na tym, że kompetentny użytkownik może zbudować tymczasowy zespół badawczy wokół jednego modelu i kilku deterministycznych narzędzi.

Dostarczone narzędzia zapewniły ważne formy ugruntowania. Dekomplilator ujawniał instrukcje maszynowe. Emulator umożliwiał izolowane testowanie. Narzędzia binarne zachowywały wewnętrzną strukturę firmware’u. Sugestie modelu były sprawdzane względem wyników programów, zamiast być przyjmowane jako sam tekst.

To połączenie może ograniczać ryzyko halucynacji, lecz nie potrafi go wyeliminować. Model może błędnie zinterpretować adres, pomylić dwie fazy firmware’u albo zalecić niebezpieczną poprawkę. W zwykłym kodzie aplikacji testy często wychwytują takie błędy. Awaria firmware’u może sprawić, że urządzenie nie będzie w stanie się uruchomić.

To zwiększa presję na Anthropic i innych dostawców AI. Ich produkty do programowania coraz częściej działają w obszarach badań nad bezpieczeństwem, administracji systemami i sterowania sprzętem. Te same możliwości, które pomagają prawowitemu właścicielowi zbadać laptop, mogą też ułatwiać atakującym analizę zabezpieczeń firmware’u.

Istotą sporu jest więc równowaga między możliwościami a weryfikacją. Modele mogą proponować coraz ambitniejsze zmiany, lecz użytkownicy nadal potrzebują niezawodnych metod ich testowania. Właściciel HP korzystał z emulacji i podobno miał pod ręką programator sprzętowy na wypadek konieczności odzyskiwania systemu.

To również obszar, w którym osobiste systemy wiedzy mogą pomóc zespołom technicznym. Badacze muszą zachowywać wyniki narzędzi, hipotezy, identyfikatory sprzętu i rezultaty testów podczas długich dochodzeń. Przeszukiwalna baza wiedzy inżynierskiej może wspierać taką dokumentację, nie udając przy tym, że weryfikuje sam firmware.

Szersza branża powinna spodziewać się, że agenci programistyczni dotrą do coraz bardziej nietypowych środowisk technicznych. Inżynieria wsteczna, rozwój systemów wbudowanych, debugowanie sterowników i analiza protokołów obejmują powtarzalne zadania, które modele mogą przyspieszać.

Ta ekspansja nie wyeliminuje specjalistycznej wiedzy. Zmienia jednak miejsca, w których staje się ona kluczowa. Użytkownicy mogą poświęcać mniej czasu na pisanie pomocniczych skryptów, a więcej na definiowanie modeli zagrożeń, sprawdzanie założeń i projektowanie bezpiecznych testów.

Przypadek opisany przez Tom's Hardware zwięźle oddaje tę zmianę. Claude Code podobno wykonał wystarczająco dużo pracy analitycznej, by pomóc jednemu entuzjaście pokonać barierę. Konsekwencje nadal spoczywały na człowieku.

Ukryte ustawienia przynoszą korzyści właścicielom i stwarzają zagrożenia bezpieczeństwa

Odblokowanie urządzenia może przywrócić właścicielowi kontrolę, lecz eksperymenty na poziomie firmware’u niosą konsekwencje, których asystent AI nie może przejąć za użytkownika.

Producenci laptopów ukrywają ustawienia BIOS-u z kilku powodów. Część opcji nie dotyczy zainstalowanego sprzętu. Inne mogą destabilizować pamięć, kontrolę termiczną, pamięć masową, zarządzanie energią lub zachowanie podczas rozruchu.

Wspólny firmware stanowi kolejne wyjaśnienie. Dostawca może używać podobnego kodu konfiguracji w wielu modelach, a następnie udostępniać wyłącznie pola zweryfikowane dla każdego produktu. Ukryte opcje mogą więc oznaczać nieużywane elementy interfejsu, a nie celowo wstrzymywane, działające funkcje.

Zgłoszona opcja GPS ilustruje to ograniczenie. Uwidocznienie pozycji menu nie tworzy brakującego modułu radiowego, anteny, sterownika ani połączenia na płycie. Wyświetlane pole może być nieaktywne, mylące lub niebezpieczne.

Niektórzy użytkownicy nadal mają uzasadnione powody, by szukać głębszej kontroli. Zaawansowane ustawienia mogą pomagać w wirtualizacji, konfiguracji trybów pamięci masowej, dostrajaniu zasilania, debugowaniu lub obsłudze niewspieranych systemów operacyjnych. Technicy naprawczy i badacze również mogą potrzebować dostępu, którego nie zapewniają interfejsy konsumenckie.

Napięcie nie sprowadza się po prostu do bezpieczeństwa dostawcy kontra wolności użytkownika. Chodzi o zweryfikowaną konfigurację kontra niekontrolowane eksperymentowanie. Dostawcy ponoszą koszty wsparcia i gwarancji, gdy nieudokumentowane kombinacje powodują awarie, podczas gdy właściciele słusznie oczekują kontroli nad zakupionym sprzętem.

AI wzmacnia obie strony tego zjawiska. Może pomóc właścicielom zrozumieć nieprzejrzysty firmware i przywrócić funkcjonalność. Może też generować pewne siebie instrukcje dla kombinacji, które nigdy nie zostały przetestowane na docelowej płycie.

Autor oryginalnego wpisu wyraźnie zalecał posiadanie programatora układów w stylu CH341A. Taki sprzęt może bezpośrednio zapisać układ pamięci flash, jeśli laptop przestanie się uruchamiać. To ostrzeżenie lepiej niż udane zrzuty ekranu pokazuje rzeczywisty poziom ryzyka.

Nawet programator nie gwarantuje bezproblemowego odzyskania systemu. Dostęp do układu może wymagać otwarcia laptopa, zidentyfikowania właściwego komponentu, zarządzania poziomami napięcia i zachowania oryginalnego zrzutu. Błąd może uszkodzić sprzęt lub wymazać dane specyficzne dla urządzenia.

Firmware działa również na bardzo uprzywilejowanej warstwie. Złośliwy lub wadliwy kod może wykonywać się przed systemem operacyjnym i przetrwać zwykłą ponowną instalację. Dlatego badacze bezpieczeństwa inaczej traktują nieautoryzowaną modyfikację firmware’u niż zwykłe dostosowywanie aplikacji.

Najnowsze prace akademickie wskazują, że same kontrole statyczne nie są w stanie wykryć każdego zagrożenia firmware’u. Framework Peacock proponuje monitorowanie w czasie działania, ponieważ przeciwnicy mogą manipulować zachowaniem firmware’u po początkowych kontrolach. Badanie to wzmacnia argument za wielowarstwową ochroną.

Zgłoszony przypadek HP nie dowodzi, że laptop stał się podatny na zdalne ataki. Użytkownik już posiadał maszynę, pozyskał jej firmware i celowo zainstalował zmodyfikowany obraz. Fizyczne posiadanie sprzętu i intencja są kluczowe w tym scenariuszu.

Obejście miałoby jednak większe znaczenie, gdyby inna ścieżka pozwalała niezaufanemu podmiotowi zapisać dotknięty region pamięci flash. Połączenie prymitywu zapisu ze słabym egzekwowaniem zasad rozruchu może przekształcić technikę lokalnej modyfikacji w ryzyko trwałego utrzymania dostępu.

Materiał źródłowy nie pokazuje żadnych dowodów na istnienie takiej zdalnej ścieżki dla tego modelu. Sugerowanie, że miliony laptopów HP są teraz narażone, byłoby nieodpowiedzialne. Ustalenie dotyczy jednego obrazu firmware’u i jednej zgłoszonej instalacji.

Kolejną poważną niewiadomą jest przenośność metody. Firmware zmienia się między modelami, rewizjami płyt głównych i wydaniami BIOS-u. Adresy się przesuwają, moduły się zmieniają, a silniejsze mechanizmy zaufania mogą odrzucić to samo podejście.

Użytkownik stwierdził, że zmiana odblokowująca zakładki już nie zadziałała przy próbie użycia jej na innej płycie HP. Taka odpowiedź podważa koncepcję uniwersalnego skryptu. Wspiera też ciekawszą interpretację: AI może pomagać szybciej dostosowywać wyspecjalizowane badania, po jednym celu naraz.

HP może zareagować przyszłymi aktualizacjami firmware’u, silniejszymi kontrolami zapisu lub wcześniejszym komponentem zweryfikowanego rozruchu. HP podaje, że jego wspierana sprzętowo technologia Sure Start została zaprojektowana, aby zapobiegać nieautoryzowanym zmianom firmware’u i odzyskiwać naruszony kod BIOS-u, lecz materiał źródłowy nie potwierdza, że ten konsumencki laptop obejmuje ta ochrona. Właściciel laptopa powiedział, że jego ostatnia aktualizacja firmware’u pojawiła się w 2024 roku. Starsze urządzenia konsumenckie mogą nigdy nie otrzymać przeprojektowanego łańcucha zaufania.

Anthropic stoi przed odrębnym pytaniem dotyczącym zabezpieczeń. Praca ma wyraźne cechy podwójnego zastosowania, co oznacza, że może wspierać zarówno legalne badania, jak i szkodliwe modyfikacje. Całkowita odmowa blokowałaby właścicieli i obrońców, podczas gdy nieograniczona automatyzacja może obniżyć bariery dla atakujących.

Rozsądna granica bezpieczeństwa zależy od kontekstu, dostępu, intencji i szczegółów operacyjnych. Wyjaśnienie, dlaczego kontrola podpisu zawiodła, różni się od pomocy we wdrażaniu ukrytego, trwałego dostępu na wielu maszynach. Dostawcy modeli muszą rozróżniać te scenariusze, nie zakładając przy tym, że każde zadanie dotyczące firmware’u jest złośliwe.

Jeden udany laptop nie dowodzi ogólnej zdolności

Demonstracja jest przekonująca jako studium przypadku, ale słaba jako dowód, że Claude Code potrafi niezawodnie odblokowywać nowoczesne zabezpieczenia BIOS-u.

Najmocniejsze dowody pochodzą ze szczegółowej relacji użytkownika. Wskazał on laptop, wersję BIOS-u, narzędzia, struktury firmware’u, odnalezione pola i ogólny proces weryfikacji. Ujawnił także ograniczenia, zamiast twierdzić, że rozwiązanie jest uniwersalnie zgodne.

Najsłabszym elementem jest niezależne odtworzenie wyniku. Żaden odrębny analityk nie udokumentował publicznie tego samego rezultatu, używając czystego obrazu F.68 na innym HP 15-dw1036ne. HP nie potwierdziło architektury ani nie oceniło zgłoszonego obejścia.

Widoczny efekt również nie może udowodnić każdego etapu wyjaśnienia. Zdjęcia nowych zakładek menu pokazywałyby, że uruchomił się zmodyfikowany interfejs. Nie ustalałyby, która ścieżka kodu zaakceptowała firmware ani czy inne zabezpieczenie zostało wcześniej wyłączone.

Opublikowany skrypt dostarcza dodatkowego materiału do analizy, lecz jego wykonanie nie jest bezpieczną metodą weryfikacji dla zwykłych czytelników. Odpowiedzialny audyt powinien obejmować inspekcję kodu, odtworzenie transformacji binarnych offline oraz porównanie wyniku z niezależnie pozyskanym firmware’em.

Badacze musieliby również potwierdzić deklarowany brak egzekwowania Intel Boot Guard. Ta kontrola określa, czy zgłoszony sukces zależał od braku sprzętowo wspieranego korzenia zaufania. Ogranicza też wnioski dotyczące nowszych lub nastawionych na biznes systemów.

Przypisanie zasług modelowi pozostaje nieprecyzyjne. Użytkownik Reddita powiedział, że używał głównie Claude Opus 4.8, a czasem Sonnet 5 poprzez Claude Code. Zapis nie wyodrębnia, który model znalazł każdy element ani w jakim stopniu kierowanie przez człowieka ukształtowało końcowe podejście.

Historia promptów pomogłaby odróżnić odkrycie od implementacji prowadzonej krok po kroku. Jeśli użytkownik dostarczył prawdopodobne nazwy modułów, znane wzorce firmware’u lub potencjalne gałęzie, wkład Claude’a różni się od w dużej mierze niezależnego wyszukiwania.

Liczba tokenów, nieudane próby i czas trwania dostarczyłyby więcej kontekstu. Przepływ pracy wymagający rozległej interwencji nadal ma wartość, lecz mówi mniej o autonomicznej wydajności niż odtwarzalny przebieg od czystego punktu wyjścia.

Sformułowanie „AI pokonuje RSA-2048” nie wytrzymuje tej próby. Zgłoszona modyfikacja nie zaatakowała przestrzeni kluczy RSA. Ominęła mechanizm obsługi wyniku w systemie, któremu rzekomo brakowało innej warstwy zdolnej chronić ten mechanizm.

Ta korekta nie powinna stać się wymówką do lekceważenia tej pracy. Odnalezienie odpowiedniego kodu wewnątrz skompresowanego firmware’u może pochłonąć znaczną ilość ludzkiego czasu. Ponowne spakowanie obrazu bez uszkodzenia offsetów lub zależności stanowi kolejne praktyczne wyzwanie.

Wartościowe pytanie brzmi, czy Claude Code konsekwentnie zmniejsza ten wysiłek. Jedna anegdota nie może na nie odpowiedzieć. Użyteczna ocena przekazałaby kilku badaczom wiele celów firmware’owych i porównała czas realizacji, dokładność oraz niebezpieczne rekomendacje.

Takie testy powinny obejmować platformy chronione i niechronione. Agent musi rozpoznać, kiedy proponowana poprawka nie może przetrwać etapu weryfikacji wspieranego sprzętowo. Utrzymywanie błędnej teorii mogłoby zmarnować czas lub uszkodzić urządzenie.

Badacze powinni również mierzyć, czy model wymyśla niepoparte znaczenia ukrytych ustawień. Same etykiety interfejsu nie dowodzą, że funkcja działa. Najbezpieczniejszy system rozróżniałby „pole odnalezione”, „pole wyświetlone” i „zachowanie zweryfikowane”.

Dopóki takie testy nie istnieją, historia Tom's Hardware należy do kategorii zgłoszonych badań nad bezpieczeństwem wspomaganych przez AI. Nie demonstruje ogólnego, zautomatyzowanego exploita BIOS-u. Pokazuje jednak, że wyspecjalizowane użycie narzędzi zbliża się do osób niebędących specjalistami.

Trzy sygnały pokażą, czy była to anegdota, czy punkt zwrotny

Kolejne dowody powinny pochodzić z odtworzenia wyniku, analizy dostawcy i szerszych ocen agentów, a nie z kolejnego dramatycznego nagłówka.

Pierwszym sygnałem jest niezależne odtworzenie na tym samym modelu i firmware’ie. Wiarygodny badacz musiałby pozyskać czysty obraz, potwierdzić odpowiednie moduły, odtworzyć zmiany i udokumentować środki ostrożności związane z odzyskiwaniem systemu.

Udane odtworzenie wzmocniłoby twierdzenie, że opis techniczny trafnie przedstawia ścieżkę zaufania laptopa. Niepowodzenie sugerowałoby, że na wynik wpłynął nieudokumentowany stan urządzenia, wcześniejsza modyfikacja lub pominięty krok.

Drugim sygnałem jest odpowiedź HP lub dostawcy bazowego firmware’u. Dostawca mógłby potwierdzić, czy dotknięty wolumin miał być chroniony przez inny mechanizm. Mógłby też wyjaśnić, czy laptop osiągnął koniec aktywnego wsparcia firmware’u.

Aktualizacja firmware’u, która chroni weryfikator za pośrednictwem wcześniejszego kotwicy zaufania, potwierdziłaby znaczenie raportu dla bezpieczeństwa. Ustalenie dostawcy, że modyfikacja wymagała nieograniczonego fizycznego zapisu pamięci flash, zawęziłoby jej implikacje dla modelu zagrożeń.

Trzecim sygnałem jest powtarzalna wydajność agentów AI w przypadku niezwiązanych ze sobą docelowych systemów firmware. Badacze powinni śledzić, czy Claude Code potrafi znaleźć porównywalne błędy implementacyjne bez wskazówek specyficznych dla danego celu. Powinni rejestrować fałszywe alarmy i uszkodzone obrazy testowe obok udanych przypadków.

Powtarzający się sukces pokazałby, że agenci AI zmieniają dostępność inżynierii wstecznej firmware. Niespójne wyniki wskazywałyby, że ten przypadek jest imponującą współpracą jednego zmotywowanego użytkownika z modelem, a nie uogólnioną zdolnością.

Czytelnicy powinni również obserwować, jak firmy AI opisują te systemy. „Asystent programowania” nie oddaje już charakteru agenta, który potrafi koordynować deasemblery, emulatory, narzędzia binarne i testy kryptograficzne. Deklaracje dotyczące bezpieczeństwa produktów muszą uwzględniać środowiska, które użytkownicy mogą zbudować wokół modelu.

Dla programistów i zespołów bezpieczeństwa praktyczną odpowiedzią jest zdyscyplinowana weryfikacja. Zachowujcie oryginalne obrazy, izolujcie testy, dokumentujcie założenia i wymagajcie przeglądu specyficznego dla sprzętu przed wdrożeniem. Pewność wygenerowana przez AI nie zastępuje ścieżki odzyskiwania.

Pracownicy umysłowi mogą wyciągnąć z tego podobną lekcję. Agenci stają się bardziej użyteczni, gdy ich praca opiera się na możliwych do prześledzenia dowodach. Przechowywanie promptów, wyników, hashy binarnych i obserwacji z testów w ustrukturyzowanym osobistym systemie wiedzy umożliwia późniejszy przegląd.

Nagłówek Tom's Hardware przyciągnie uwagę, ponieważ zestawia Claude Code z RSA-2048. Trwała historia jest mniej filmowa. Użytkownik miał rzekomo połączyć agenta AI ze specjalistycznymi narzędziami, aby znaleźć słaby punkt wokół poprawnej kryptografii.

To nadal ma znaczenie. Bezpieczeństwo często zawodzi tam, gdzie łączą się komponenty, a agenci programistyczni coraz lepiej potrafią śledzić te połączenia. Kolejne pytanie brzmi, czy niezależni badacze zdołają odtworzyć ten wynik bez przejmowania założeń pierwotnego użytkownika.

Do tego czasu traktujcie modyfikację BIOS-u jako technicznie wiarygodne, starannie opisane, ale niezweryfikowane studium przypadku. Śledźcie próby odtworzenia, analizujcie wszelkie odpowiedzi producenta i odróżniajcie złamane egzekwowanie zasad od złamanej kryptografii.