Claude Code entra nel BIOS HP: password reset e 55 opzioni nascoste

Un portatile HP bloccato da una password del BIOS, acquistato sul mercato dell’usato e apparentemente destinato a diventare un costoso fermacarte, è tornato pienamente utilizzabile grazie a un lavoro di reverse engineering assistito da Claude Code. Il caso riguarda un HP 15-dw1036ne con firmware F.68, macchina basata su processori Intel Core di decima generazione e commercializzata attorno al 2020. Il proprietario non ha semplicemente recuperato l’accesso alle impostazioni: ha modificato il firmware, neutralizzato un controllo crittografico RSA-2048 e reso visibili 55 opzioni che il produttore aveva nascosto.

L’episodio raccontato pubblicamente non dimostra che un chatbot possa sbloccare con pochi comandi qualsiasi computer. Dietro il risultato ci sono un programmatore SPI CH341A, numerosi tentativi di scrittura, strumenti di analisi binaria e una discreta conoscenza dell’architettura UEFI. Rende palese che i modelli generativi orientati alla programmazione stanno diventando assistenti credibili anche nelle attività di reverse engineering, un terreno che fino a poco tempo fa richiedeva lunghe sessioni manuali tra disassembler, strutture binarie e codice macchina.

Claude Code entra nel BIOS di un notebook HP

Il portatile utilizzato per l’esperimento presentava un blocco del BIOS del quale non conosciamo con certezza la natura. Potrebbe trattarsi di una password amministrativa, di una password di accensione oppure di una combinazione di restrizioni impostate dal precedente proprietario.

Sui notebook moderni, rimuovere la batteria tampone CMOS non basta quasi mai: le credenziali e le politiche di sicurezza possono risiedere nella memoria non volatile del firmware, in aree protette del chip SPI (piccola memoria saldata sulla scheda madre che conserva il firmware UEFI/BIOS; un programmatore esterno può leggerne o riscriverne direttamente il contenuto) o in strutture gestite dal produttore.

Il proprietario aveva però accesso fisico alla macchina e disponeva di un programmatore CH341A, dispositivo economico che consente di leggere e riscrivere direttamente diversi chip di memoria seriale.

Prima di iniziare ha creato un dump completo del firmware: senza una copia verificata del contenuto originale e senza la possibilità di programmare il chip dall’esterno, una modifica errata può lasciare il computer incapace di completare la prima fase di avvio (POST).

Il firmware F.68 di HP reagiva a qualsiasi alterazione mostrando il messaggio “BIOS Corruption Detected“: non trovando procedure già documentate per quel modello, il ricercatore ha fornito a Claude Code il dump del BIOS e gli strumenti necessari all’analisi. L’utente riporta di aver condotto una lunga interazione, utilizzando soprattutto Claude Opus 4.8 e, in alcuni passaggi, Sonnet 5. Sono serviti circa 18 tentativi di flashing prima di arrivare a un’immagine funzionante.

Come è stato analizzato il firmware UEFI

Un BIOS moderno non è un blocco monolitico di codice. Le implementazioni basate sulle specifiche UEFI Platform Initialization organizzano driver, moduli, dati e applicazioni in un Firmware Volume.

Per separare le varie componenti del BIOS UEFI sono stati utilizzati strumenti come UEFITool, UEFIExtract e UEFIFind. La suite permette di riconoscere volumi, file FFS, sezioni compresse, GUID e moduli eseguibili incorporati nell’immagine. Una semplice ricerca esadecimale non sarebbe bastata: il verificatore della firma si trovava infatti in un modulo compresso con LZMA e diventava visibile soltanto dopo l’estrazione.

L’analisi del codice è passata poi attraverso Ghidra, collegato tramite GhidrAssistMCP a Claude Code: il disassembler ha aiutato a ricostruire il flusso delle funzioni, individuare il codice responsabile del controllo crittografico e trovare la logica che nascondeva alcune sezioni dell’interfaccia. Script Python personalizzati hanno affiancato Ghidra nella ricerca di costanti, sequenze di istruzioni e chiamate che l’analisi automatica non aveva riconosciuto correttamente.

La procedura ha incluso anche Unicorn Engine, framework capace di emulare istruzioni di diverse architetture, e Capstone, usato per decodificare il codice macchina.

Il proprietario del PC HP ha così eseguito la funzione di verifica al di fuori del portatile, confrontando il comportamento con firme valide e firme alterate.

Nessuna violazione del controllo RSA-2048

No, l’AI di Claude Code non ha assolutamente “rotto” la cifratura RSA-2048. Nessuno ha fattorizzato una chiave RSA da 2048 bit, recuperato la chiave privata di HP o generato una firma valida per il firmware modificato: un attacco crittografico del genere, come abbiamo sottolineato a suo tempo nel nostro articolo, non è praticamente fattibile.

Studiando il firmware in questione, è emerso che il sistema proteggeva l’intero volume DXE compresso tramite una firma RSA-2048 separata. Il codice di verifica elaborava la firma, invocava la funzione incaricata di controllare il risultato matematico e decideva poi se continuare l’avvio. L’intervento ha colpito proprio questa decisione finale.

Nel codice, un salto condizionale autorizzava la prosecuzione soltanto quando la verifica restituiva esito positivo. La modifica applicata con l’aiuto di Claude Code ha trasformato quella decisione condizionale in un salto incondizionato. In altre parole, il calcolo RSA continuava a produrre un risultato, ma il firmware ignorava l’eventuale fallimento e seguiva comunque il percorso riservato alle immagini valide.

Si tratta quindi di un bypass della verifica della firma, non di una sconfitta dell’algoritmo RSA. La distinzione è importante anche sul piano della sicurezza: una firma robusta protegge un’immagine solo se il verificatore, la chiave pubblica e il processo che interpreta il risultato appartengono a una catena di fiducia non modificabile dall’attaccante.

Nel caso di specie, il portatile non utilizzava Intel Boot Guard per autenticare l’immagine prima dell’esecuzione. Boot Guard porta la radice di fiducia a un livello hardware e può impedire l’avvio di firmware non autorizzati anche quando alcune routine interne risultano manipolate. Se la piattaforma avesse applicato correttamente una verifica hardware del blocco iniziale, l’intervento potrebbe non aver condotto al risultato sperato.

Le 55 opzioni nascoste nel BIOS UEFI HP

Superato il controllo di integrità, Claude Code ha analizzato le strutture che descrivono l’interfaccia del BIOS.

Molti firmware UEFI memorizzano moduli e campi del setup tramite rappresentazioni IFR, acronimo di Internal Forms Representation. Le schermate visibili all’utente derivano da formulari che specificano etichette, variabili, valori ammessi e condizioni di visualizzazione.

Nel modulo SetupUtility erano presenti numerosi campi già compilati ma esclusi dall’interfaccia attraverso condizioni speciali: il lavoro ha individuato un totale di 55 campi nascosti. Cambiando il valore booleano associato, le opzioni sono riapparse nel menu: non significa però che tutte funzionino perché i produttori assemblano spesso il firmware partendo da basi comuni destinate a intere famiglie di schede; alcune voci restano nel codice anche quando l’hardware specifico non possiede il componente corrispondente.

Il proprietario ha citato, per esempio, un’opzione relativa al GPS su un notebook privo del modulo necessario. È un dettaglio che ridimensiona l’idea di un BIOS improvvisamente trasformato in una piattaforma per overclock: una voce visibile può non essere collegata ad alcuna periferica, oppure può impostare registri e variabili non validi per quella scheda.

Un caso interessante per il diritto alla riparazione, ma non solo

Il recupero di un portatile usato rimasto bloccato evidenzia un problema concreto. Password dimenticate, asset aziendali dismessi senza corretta procedura di deprovisioning e firmware non più supportati possono trasformare hardware funzionante in rifiuto elettronico. Da questo punto di vista, gli strumenti di analisi assistiti dall’AI possono aiutare tecnici e laboratori a comprendere piattaforme prive di documentazione pubblica.

La stessa capacità può però facilitare l’individuazione di controlli deboli nei firmware. L’esempio HP mostra quanto sia fragile una verifica crittografica quando il codice che interpreta il risultato risiede nella medesima area modificabile: chi sviluppa piattaforme moderne deve proteggere la catena di avvio fin dalle prime istruzioni, usare root di fiducia in hardware, limitare l’accesso in scrittura alla flash SPI e verificare ogni fase prima di trasferire il controllo a quella successiva.

Claude Code ha permesso di accelerare un’attività complessa, collegando disassemblaggio, emulazione, analisi delle strutture UEFI e generazione di script.