Claude Code Ajudou a Contornar uma Verificação de Assinatura de BIOS da HP sem Quebrar o RSA-2048

A Anthropic entrou em um debate de segurança incomum depois que Claude Code teria ajudado a modificar a BIOS de um laptop HP e revelar 55 configurações ocultas. A manchete da Tom's Hardware sugere que a IA derrotou o RSA-2048, um dos padrões criptográficos usados para autenticar firmware. As evidências apontam para uma conclusão mais limitada, mas ainda importante: Claude Code encontrou uma forma de contornar a lógica de decisão de uma implementação.

A distinção importa. Segundo o proprietário do laptop, Claude Code ajudou a localizar o código de verificação, analisar módulos de firmware comprimidos, testar um patch e reconstruir uma imagem funcional. Ele não recuperou a chave de assinatura da HP, forjou uma assinatura válida nem resolveu o problema matemático por trás do RSA-2048.

O resultado, portanto, pressiona duas premissas conhecidas. Fabricantes de laptops supõem que os controles de firmware continuam sendo pouco práticos para proprietários comuns fazerem engenharia reversa. Fornecedores de IA supõem que agentes de programação podem ser apresentados com segurança como ferramentas de produtividade, mesmo quando usuários os direcionam para sistemas sensíveis à segurança.

O experimento teria funcionado em um HP 15-dw1036ne executando a BIOS versão F.68. Ele não passou por uma auditoria técnica independente, e sua aplicabilidade a outros sistemas continua incerta. Ainda assim, o fluxo de trabalho mostra como um agente de programação com IA pode reduzir o trabalho necessário para pesquisas especializadas de firmware.

Claude Code Transformou um Dump de BIOS em uma Modificação Funcional

A mudança significativa não foi um novo ataque criptográfico. Foi a compressão de um fluxo de trabalho difícil de engenharia reversa em uma sessão de IA conduzida por um usuário.

Um usuário do Reddit, que publicou como Reddit_2049, disse que seu laptop HP rejeitava qualquer firmware alterado com a mensagem “BIOS Corruption Detected”. Ninguém havia publicado um desbloqueio conhecido para aquele modelo exato, segundo o usuário. Ele forneceu a Claude Code um dump da BIOS e diversas ferramentas consolidadas de engenharia reversa.

O fluxo de trabalho relatado combinou Ghidra, UEFITool, UEFIExtract, UEFIFind, Unicorn Engine, Capstone, Python e uma biblioteca de criptografia. Cada programa já tem uma finalidade técnica reconhecível. A contribuição relatada de Claude Code foi coordená-los, interpretar sua saída e produzir scripts para análises adicionais.

O Ghidra desmontou módulos de firmware e expôs o fluxo de controle relevante. Os utilitários UEFI separaram a imagem em componentes. O Unicorn Engine emulou a rotina de verificação extraída fora do laptop físico, reduzindo o risco de testar cada alteração por meio de uma gravação real de firmware.

A biblioteca de criptografia gerou assinaturas de teste válidas para a rotina emulada. Esse detalhe importa porque permitiu ao usuário comparar entradas válidas e corrompidas. Ela não criou uma assinatura HP válida para o firmware modificado.

Segundo a publicação original do usuário, a análise identificou três grupos de alterações. Um contornava uma verificação que protegia um volume de firmware DXE comprimido. Outro expunha 55 campos de configuração. Um terceiro revelava as abas Advanced, Power, Debug e Boot.

DXE, ou Driver Execution Environment, é uma fase do UEFI que inicializa dispositivos e serviços antes de o sistema operacional iniciar. O código de firmware nesse nível opera abaixo do Windows ou Linux. Erros podem impedir que o computador alcance qualquer um dos sistemas operacionais.

Os 55 campos consistiam, segundo o relato, em 27 entradas suprimidas e 28 entradas esmaecidas. Suas definições já existiam nos formulários de configuração do firmware. Pequenas alterações em condições codificadas diretamente tornaram esses campos visíveis.

Isso não significa que cada opção exposta controle hardware compatível. O usuário reconheceu posteriormente que algumas entradas pareciam irrelevantes para o laptop, incluindo uma configuração de GPS. Fabricantes frequentemente compartilham componentes de firmware entre vários produtos, deixando campos inativos dentro de uma interface comum.

As quatro abas adicionais seguiram um padrão semelhante. O firmware as continha, mas sua lógica de interface impedia sua exibição nesse modelo. O patch alterou essa decisão, em vez de adicionar recursos de configuração inteiramente novos.

O usuário afirmou que a imagem resultante funcionou em seu laptop. Ele também publicou um script Python destinado a reproduzir as alterações a partir de um dump original. No entanto, a publicação alertava que o script foi testado apenas na máquina mencionada e poderia funcionar somente em modelos estreitamente relacionados.

Isso continua sendo uma demonstração relatada pelo próprio autor. Nem a HP nem a Anthropic validaram publicamente a imagem modificada, a análise ou as opções de configuração resultantes. Nenhum pesquisador independente publicou uma reprodução completa no mesmo modelo de laptop.

Essa lacuna de verificação deve orientar toda interpretação da história da Tom's Hardware. Uma narrativa técnica plausível aparece nos detalhes apresentados pelo usuário, mas um único experimento pessoal bem-sucedido não representa uma capacidade geral de desbloqueio de BIOS.

A Manchete da Tom's Hardware Exagera o Que Aconteceu com o RSA-2048

Claude Code teria contornado o ramo de software que impunha um resultado de verificação. Ele não derrotou o algoritmo RSA-2048 em si.

Assinaturas digitais permitem que um dispositivo verifique se o firmware veio de um publicador autorizado e permaneceu inalterado. O fornecedor assina dados aprovados usando uma chave privada. Um verificador usa a chave pública correspondente para confirmar essa assinatura.

Quebrar o RSA-2048 implicaria um resultado criptográfico profundo. Um atacante poderia recuperar uma chave privada, criar assinaturas sem autorização ou derrotar as premissas matemáticas subjacentes. A conta do Reddit não descreve nenhum desses resultados.

Em vez disso, o usuário afirma que Claude Code encontrou o código responsável por tratar o resultado da assinatura. A modificação teria forçado esse código a seguir seu caminho de sucesso, independentemente de a verificação matemática ter sido aprovada.

Uma analogia útil é um segurança verificando um crachá válido e registrando a resposta em um log. A modificação relatada não fabricou um crachá válido. Ela alterou o que acontecia depois que o segurança retornava uma resposta.

Essa diferença não torna o resultado trivial. Localizar o verificador relevante dentro de firmware comprimido exigiu descompressão, engenharia reversa, rastreamento de código e reconstrução cuidadosa da imagem. Um binário modificado também precisou preservar a estrutura necessária para a máquina inicializar.

Ainda assim, a primitiva criptográfica se comportou como projetado. A fraqueza relatada estava no caminho de imposição ao redor dela e na aparente disposição do sistema de executar código de verificação modificado.

As orientações de firmware da Microsoft explicam por que essa separação importa. O código de firmware assinado deve ser validado antes da execução, e componentes não autorizados não devem ser executados. Uma função de verificação oferece pouca proteção se uma camada de confiança anterior não proteger a própria função.

O proprietário do laptop disse não ter encontrado estruturas do Intel Boot Guard necessárias para ancorar o código afetado a uma cadeia de confiança respaldada por hardware. Intel Boot Guard é um mecanismo de plataforma projetado para autenticar componentes iniciais de inicialização antes que o firmware principal continue.

Essa afirmação não foi confirmada de forma independente para esta máquina específica. No entanto, se estiver correta, explica por que editar o verificador poderia sobreviver a uma reinicialização. A implementação confiava no código armazenado em memória flash gravável para decidir se outro código deveria ser confiável.

Esta é a inversão central. O RSA-2048 pode continuar matematicamente sólido enquanto um produto que o utiliza ainda aceita firmware não autorizado. A segurança depende de toda a cadeia de verificação, não do nome ou do tamanho da chave de um algoritmo.

Há precedentes históricos para essa distinção. Pesquisadores que examinaram o Nintendo 3DS documentaram uma implementação de assinatura RSA que aceitava firmware não autorizado devido a falhas de analisador. Sua pesquisa sobre boot ROM teve como alvo a forma como as assinaturas eram processadas, não a dificuldade matemática do RSA-2048.

A modificação da HP é tecnicamente diferente. O relato publicado descreve fluxo de controle alterado, em vez de uma assinatura malformada explorando um analisador. Ambos os casos mostram por que “usa RSA-2048” não é uma declaração completa de segurança.

O enquadramento da Tom's Hardware também corre o risco de atribuir autonomia excessiva ao Claude Code. O humano forneceu o firmware, selecionou ferramentas, aprovou ações, testou resultados e aceitou o risco de gravar código modificado. Claude operou em um ambiente de pesquisa concebido pelo usuário.

Uma manchete mais precisa diria que Claude Code ajudou a contornar uma verificação de assinatura RSA-2048 em uma compilação de firmware HP. Isso continua marcante porque o assistente teria navegado por um domínio que normalmente exige conhecimento especializado considerável.

A Mudança Real É a Engenharia Reversa Assistida por IA

O experimento sugere que agentes de programação podem tornar fluxos de trabalho técnicos avançados acessíveis a usuários mais persistentes, mesmo quando a vulnerabilidade subjacente é convencional.

A engenharia reversa de firmware historicamente exigiu fluência em código assembly, formatos binários, compressão, criptografia, inicialização de hardware e procedimentos de recuperação. Nenhuma etapa individual do fluxo de trabalho relatado é inédita. Coordenar todas as etapas continua sendo difícil.

Agentes de IA mudam esse custo de coordenação. Eles podem inspecionar a saída de ferramentas, propor a próxima consulta, gerar pequenos utilitários de análise, acompanhar hipóteses e reescrever scripts quando um layout binário difere das expectativas. Esse trabalho antes exigia buscas repetidas em manuais, fóruns e repositórios de código-fonte.

Claude Code aparentemente não operou como um botão de hacking de uso único. O relato descreve, em vez disso, um processo iterativo. O usuário forneceu acesso a ferramentas especializadas, enquanto o modelo conectava descobertas parciais entre elas.

Esse padrão é mais importante do que as abas visíveis da BIOS. Um modelo não precisa inventar um novo exploit para alterar a economia da pesquisa de segurança. Ele só precisa ajudar mais pessoas a concluir análises conhecidas com mais rapidez.

O caso também mostra por que sistemas agentes diferem de chatbots conversacionais. Um agente pode inspecionar arquivos, chamar programas, gerar código e usar os resultados de uma ação para planejar outra. Esse ciclo cria alavancagem em tarefas nas quais o progresso depende de dezenas de pequenas decisões técnicas. A Anthropic descreve Claude Code como um sistema de programação agêntico que pode ler bases de código, editar arquivos, executar testes e trabalhar com ferramentas externas.

Para desenvolvedores, a lição não é que Claude Code se tornou um especialista autônomo em firmware. É que um usuário capacitado pode montar uma equipe temporária de pesquisa em torno de um modelo e de várias ferramentas determinísticas.

As ferramentas forneceram formas importantes de fundamentação. Um desassemblador expôs instruções de máquina. Um emulador permitiu testes isolados. Utilitários binários preservaram a estrutura interna do firmware. As sugestões do modelo foram verificadas em relação à saída dos programas, em vez de aceitas como texto.

Essa combinação pode reduzir o risco de alucinações, mas não pode eliminá-lo. Um modelo pode interpretar incorretamente um endereço, confundir duas fases de firmware ou recomendar um patch inseguro. Em código comum de aplicações, testes frequentemente detectam esses erros. Falhas de firmware podem deixar um dispositivo incapaz de inicializar.

Isso aumenta a pressão sobre a Anthropic e outros provedores de IA. Seus produtos de programação operam cada vez mais em pesquisa de segurança, administração de sistemas e controle de hardware. As mesmas capacidades que ajudam um proprietário legítimo a inspecionar um laptop também podem ajudar invasores a estudar proteções de firmware.

A disputa relevante é, portanto, entre capacidade e verificação. Os modelos podem propor mudanças mais ambiciosas, mas os usuários ainda precisam de formas confiáveis de testar essas mudanças. O proprietário do HP usou emulação e, segundo relatos, manteve um programador de hardware disponível para recuperação.

É também nesse ponto que sistemas pessoais de conhecimento podem ajudar equipes técnicas. Pesquisadores precisam preservar saídas de ferramentas, hipóteses, identificadores de hardware e resultados de testes ao longo de investigações extensas. Uma base de conhecimento de engenharia pesquisável pode apoiar esse registro sem fingir validar o próprio firmware.

O setor em geral deve esperar que agentes de programação alcancem ambientes técnicos mais incomuns. Engenharia reversa, desenvolvimento embarcado, depuração de drivers e análise de protocolos contêm tarefas repetitivas que os modelos podem acelerar.

Essa expansão não eliminará a especialização. Ela muda o ponto em que a especialização se torna essencial. Os usuários podem passar menos tempo escrevendo scripts utilitários e mais tempo definindo modelos de ameaça, verificando premissas e projetando testes seguros.

O caso da Tom's Hardware capta essa transição de forma concisa. Segundo relatos, o Claude Code executou trabalho analítico suficiente para ajudar um entusiasta a ultrapassar uma barreira. O ser humano continuou responsável pelas consequências.

Configurações Ocultas Criam Benefícios de Propriedade e Riscos de Segurança

Desbloquear um dispositivo pode restaurar o controle do proprietário, mas a experimentação em nível de firmware traz consequências que um assistente de IA não pode assumir pelo usuário.

Fabricantes de laptops ocultam configurações de BIOS por vários motivos. Algumas opções não se aplicam ao hardware instalado. Outras podem desestabilizar a memória, os controles térmicos, o armazenamento, o gerenciamento de energia ou o comportamento de inicialização.

O firmware compartilhado oferece outra explicação. Um fornecedor pode usar código de configuração semelhante em muitos modelos e expor apenas os campos validados para cada produto. Portanto, opções ocultas podem representar componentes de interface não utilizados, e não recursos funcionais retidos.

A opção de GPS relatada ilustra essa limitação. Tornar visível uma entrada de menu não cria um rádio, uma antena, um driver ou uma conexão de placa inexistentes. Um campo exibido pode ser inerte, enganoso ou inseguro.

Alguns usuários ainda têm motivos legítimos para buscar controle mais profundo. Configurações avançadas podem ajudar com virtualização, modos de armazenamento, ajuste de energia, depuração ou sistemas operacionais não compatíveis. Técnicos de reparo e pesquisadores também podem precisar de acessos que as interfaces de consumo ocultam.

A tensão não é simplesmente segurança do fornecedor versus liberdade do usuário. Trata-se de configuração validada versus experimentação descontrolada. Os fornecedores enfrentam custos de suporte e garantia quando combinações não documentadas causam falhas, enquanto os proprietários razoavelmente esperam autoridade sobre o hardware adquirido.

A IA intensifica ambos os lados. Ela pode ajudar proprietários a compreender firmware opaco e recuperar funcionalidades. Também pode produzir instruções confiantes para combinações que nunca foram testadas na placa-alvo.

O autor da publicação original recomendou explicitamente ter disponível um programador de chips no estilo CH341A. Esse hardware pode regravar diretamente um chip de memória flash se o laptop deixar de iniciar. Esse aviso revela melhor o nível real de risco do que as capturas de tela bem-sucedidas.

Mesmo um programador não garante uma recuperação tranquila. Acessar o chip pode exigir abrir o laptop, identificar o encapsulamento correto, gerenciar níveis de tensão e preservar um dump original. Um erro pode danificar o hardware ou apagar dados específicos do dispositivo.

O firmware também ocupa uma posição altamente privilegiada. Código malicioso ou defeituoso pode ser executado antes do sistema operacional e persistir após reinstalações normais. Por isso, pesquisadores de segurança tratam a modificação não autorizada de firmware de forma diferente da personalização comum de aplicativos.

Trabalhos acadêmicos recentes argumentam que verificações estáticas, por si só, não conseguem observar todas as ameaças de firmware. O framework Peacock propõe monitoramento em tempo de execução porque adversários podem manipular o comportamento do firmware após as verificações iniciais. Essa pesquisa reforça a necessidade de proteção em camadas.

O caso relatado da HP não estabelece que o laptop tenha se tornado explorável remotamente. O usuário já possuía a máquina, obteve seu firmware e instalou deliberadamente uma imagem modificada. A propriedade física e a intenção são centrais para o cenário.

No entanto, o bypass teria maior relevância se outra via permitisse que um agente não confiável gravasse a região flash afetada. A combinação de uma primitiva de escrita e uma aplicação fraca de inicialização pode transformar uma técnica de modificação local em um risco de persistência.

Nenhuma evidência no material de origem mostra que essa via remota exista para esse modelo. Seria irresponsável insinuar que milhões de laptops HP estão agora expostos. A descoberta diz respeito a uma imagem de firmware e uma instalação relatada.

A portabilidade é outra grande incerteza. O firmware muda entre modelos, revisões de placa-mãe e versões de BIOS. Endereços mudam, módulos são alterados e mecanismos de confiança mais fortes podem rejeitar a mesma abordagem.

O usuário afirmou que uma alteração para desbloquear abas já falhou ao ser tentada em outra placa HP. Essa resposta enfraquece a ideia de um script universal. Ela também sustenta uma interpretação mais interessante: a IA pode ajudar a adaptar pesquisas sob medida mais rapidamente, um alvo por vez.

A HP poderia responder por meio de futuras atualizações de firmware, controles de escrita mais fortes ou um componente de boot verificado mais antecipado. A HP afirma que sua tecnologia Sure Start, apoiada por hardware, foi projetada para impedir alterações não autorizadas de firmware e recuperar código de BIOS comprometido, mas o material de origem não estabelece que este laptop de consumo inclua essa proteção. O proprietário do laptop disse que sua última atualização de firmware chegou em 2024. Dispositivos de consumo mais antigos talvez nunca recebam um redesenho de sua cadeia de confiança.

A Anthropic enfrenta uma questão separada sobre salvaguardas. O trabalho possui características claras de uso dual, o que significa que pode apoiar pesquisas legítimas e modificações prejudiciais. Uma recusa generalizada bloquearia proprietários e defensores, enquanto a automação irrestrita pode reduzir barreiras para invasores.

Um limite de segurança sensato depende de contexto, acesso, intenção e detalhes operacionais. Explicar por que uma verificação de assinatura falhou é diferente de ajudar a implantar persistência furtiva em várias máquinas. Os provedores de modelos precisam distinguir esses cenários sem presumir que toda tarefa de firmware é maliciosa.

Um Laptop Bem-Sucedido Não Estabelece uma Capacidade Geral

A demonstração é convincente como estudo de caso, mas fraca como prova de que o Claude Code pode desbloquear proteções modernas de BIOS de forma confiável.

A evidência mais forte vem do relato detalhado do usuário. Ele nomeou o laptop, a revisão da BIOS, as ferramentas, as estruturas de firmware, os campos descobertos e o amplo processo de validação. Também revelou limitações, em vez de alegar compatibilidade universal.

A evidência mais fraca é a reprodução independente. Nenhum analista separado documentou publicamente o mesmo resultado usando uma imagem F.68 limpa em outro HP 15-dw1036ne. A HP não confirmou a arquitetura nem avaliou o bypass relatado.

O resultado visível também não pode provar cada etapa da explicação. Fotos de novas abas de menu mostrariam que uma interface modificada foi inicializada. Elas não estabeleceriam qual caminho de código aceitou o firmware ou se outra proteção foi desativada anteriormente.

O script publicado fornece material adicional para revisão, mas executá-lo não é um método seguro de verificação para leitores comuns. Uma auditoria responsável inspecionaria o código, reproduziria transformações binárias offline e compararia a saída com firmware obtido de forma independente.

Os pesquisadores também precisariam confirmar a alegada ausência da aplicação de Intel Boot Guard. Essa verificação determina se o sucesso relatado dependeu da falta de uma raiz de confiança apoiada por hardware. Ela também limita conclusões sobre sistemas mais novos ou voltados a empresas.

A atribuição ao modelo continua imprecisa. O usuário do Reddit disse que usou principalmente Claude Opus 4.8 e, às vezes, Sonnet 5 por meio do Claude Code. O registro não isola qual modelo encontrou cada elemento nem o quanto a orientação humana moldou a abordagem final.

O histórico de prompts ajudaria a distinguir descoberta de implementação guiada. Se o usuário forneceu nomes prováveis de módulos, padrões de firmware conhecidos ou ramificações candidatas, a contribuição do Claude difere de uma busca amplamente independente.

Contagens de tokens, tentativas fracassadas e tempo decorrido forneceriam mais contexto. Um fluxo de trabalho que exigiu intervenção extensa ainda tem valor, mas diz menos sobre desempenho autônomo do que uma execução reproduzível a partir de um ponto de partida limpo.

A expressão “IA derrota RSA-2048” não resiste a esse teste rigoroso. A modificação relatada não atacou o espaço de chaves do RSA. Ela contornou um mecanismo de tratamento de resultados em um sistema que supostamente não possuía outra camada capaz de proteger esse mecanismo.

Essa correção não deve se tornar uma desculpa para descartar o trabalho. Encontrar o código relevante dentro de firmware comprimido pode consumir um tempo humano significativo. Reempacotar a imagem sem quebrar offsets ou dependências acrescenta outro desafio prático.

A questão valiosa é se o Claude Code reduz esse esforço de forma consistente. Uma anedota não pode respondê-la. Uma avaliação útil daria a vários pesquisadores múltiplos alvos de firmware e compararia tempo de conclusão, precisão e recomendações inseguras.

Esses testes deveriam incluir plataformas protegidas e desprotegidas. Um agente deve reconhecer quando um patch proposto não consegue sobreviver a uma etapa de verificação apoiada por hardware. Persistir em uma teoria falsa poderia desperdiçar tempo ou danificar um dispositivo.

Pesquisadores também deveriam medir se o modelo inventa significados sem suporte para configurações ocultas. Rótulos de interface, por si só, não provam que um recurso funciona. O sistema mais seguro separaria “campo descoberto”, “campo exibido” e “comportamento validado”.

Até que esses testes existam, a história da Tom's Hardware pertence à categoria de pesquisa de segurança assistida por IA relatada. Ela não demonstra um exploit de BIOS automatizado de propósito geral. Ela demonstra que o uso de ferramentas especializadas está se aproximando de não especialistas.

Três Sinais Mostrarão se Isso Foi uma Anedota ou um Ponto de Virada

As próximas evidências devem vir de reprodução, análise do fornecedor e avaliações mais amplas de agentes, não de outra manchete dramática.

O primeiro sinal é a reprodução independente no mesmo modelo e firmware. Um pesquisador confiável precisaria obter uma imagem limpa, confirmar os módulos relevantes, reproduzir as mudanças e documentar precauções de recuperação.

Uma reprodução bem-sucedida reforçaria a alegação de que o relato técnico descreve com precisão o caminho de confiança do laptop. Uma falha sugeriria que um estado não documentado do dispositivo, uma modificação anterior ou uma etapa ausente influenciou o resultado.

O segundo sinal é uma resposta da HP ou do fornecedor subjacente de firmware. O fornecedor poderia confirmar se era esperado que o volume afetado fosse protegido por outro mecanismo. Também poderia esclarecer se o laptop chegou ao fim do suporte ativo de firmware.

Uma atualização de firmware que proteja o verificador por meio de uma âncora de confiança anterior validaria a relevância de segurança do relatório. Uma conclusão do fornecedor de que a modificação exigiu gravação física irrestrita restringiria suas implicações de ameaça.

O terceiro sinal é um desempenho repetível de agentes de IA em alvos de firmware não relacionados. Pesquisadores devem acompanhar se o Claude Code consegue localizar falhas de implementação comparáveis sem orientação específica para cada alvo. Devem registrar falsos positivos e imagens de teste danificadas juntamente com os casos bem-sucedidos.

O sucesso repetido mostraria que os agentes de IA estão mudando a acessibilidade da engenharia reversa de firmware. Resultados inconsistentes enquadrariam este caso como uma colaboração impressionante entre um usuário motivado e um modelo, e não como uma capacidade generalizável.

Os leitores também devem observar como as empresas de IA descrevem esses sistemas. “Assistente de programação” já não descreve adequadamente um agente capaz de coordenar desmontadores, emuladores, utilitários binários e testes criptográficos. As alegações de segurança dos produtos precisam considerar os ambientes que os usuários podem montar em torno do modelo.

Para desenvolvedores e equipes de segurança, a resposta prática é uma verificação disciplinada. Preserve as imagens originais, isole os testes, documente as premissas e exija revisão específica de hardware antes da implantação. A confiança gerada por IA não substitui um caminho de recuperação.

Os profissionais do conhecimento enfrentam uma lição relacionada. Os agentes tornam-se mais úteis quando seu trabalho se baseia em evidências rastreáveis. Manter prompts, resultados, hashes binários e observações de teste em um sistema pessoal de conhecimento estruturado torna possível uma revisão posterior.

A manchete da Tom's Hardware atrairá atenção porque coloca o Claude Code contra o RSA-2048. A história duradoura é menos cinematográfica. Um usuário teria combinado um agente de IA com ferramentas especializadas para encontrar um ponto fraco em torno de uma criptografia sólida.

Isso ainda é relevante. A segurança frequentemente falha onde os componentes se conectam, e os agentes de programação estão se tornando habilidosos em rastrear essas conexões. A próxima questão é se pesquisadores independentes conseguem reproduzir esse resultado sem herdar as premissas do usuário original.

Até lá, trate a modificação da BIOS como um estudo de caso tecnicamente plausível, cuidadosamente descrito, mas não verificado. Acompanhe as reproduções, examine qualquer resposta do fornecedor e diferencie uma aplicação de regras quebrada de uma criptografia quebrada.