Claude Code ayudó a eludir una comprobación de firma de BIOS de HP sin vulnerar RSA-2048

Anthropic entró en un inusual debate de seguridad después de que Claude Code supuestamente ayudara a modificar la BIOS de una laptop HP y a revelar 55 ajustes ocultos. El titular de Tom's Hardware sugiere que la IA derrotó RSA-2048, uno de los estándares criptográficos utilizados para autenticar firmware. Las pruebas respaldan una conclusión más acotada, aunque igualmente importante: Claude Code encontró una forma de sortear la lógica de decisión de una implementación.

La distinción importa. Según el propietario de la laptop, Claude Code ayudó a localizar código de verificación, analizar módulos de firmware comprimidos, probar un parche y reconstruir una imagen funcional. No recuperó la clave de firma de HP, no falsificó una firma válida ni resolvió el problema matemático detrás de RSA-2048.

Por tanto, el resultado pone presión sobre dos supuestos conocidos. Los fabricantes de laptops asumen que los controles de firmware siguen siendo poco prácticos de revertir mediante ingeniería inversa para propietarios comunes. Los proveedores de IA asumen que los agentes de programación pueden presentarse con seguridad como herramientas de productividad, incluso cuando los usuarios los dirigen hacia sistemas sensibles desde el punto de vista de la seguridad.

El experimento supuestamente funcionó en una HP 15-dw1036ne con BIOS versión F.68. No ha recibido una auditoría técnica independiente y su aplicabilidad a otros sistemas sigue siendo incierta. Aun así, el flujo de trabajo muestra cómo un agente de programación con IA puede reducir el trabajo necesario para una investigación especializada de firmware.

Claude Code convirtió un volcado de BIOS en una modificación funcional

El cambio significativo no fue un nuevo ataque criptográfico. Fue la compresión de un difícil flujo de trabajo de ingeniería inversa en una sesión de IA dirigida por el usuario.

Un usuario de Reddit que publicó como Reddit_2049 afirmó que su laptop HP rechazaba cualquier firmware alterado con el mensaje “BIOS Corruption Detected”. Según el usuario, nadie había publicado un desbloqueo conocido para ese modelo exacto. Le proporcionó a Claude Code un volcado de BIOS y varias herramientas consolidadas de ingeniería inversa.

El flujo de trabajo descrito combinó Ghidra, UEFITool, UEFIExtract, UEFIFind, Unicorn Engine, Capstone, Python y una biblioteca de criptografía. Cada programa ya cumple una función técnica reconocible. La contribución atribuida a Claude Code fue coordinarlos, interpretar su salida y producir scripts para análisis adicionales.

Ghidra desensambló módulos de firmware y expuso el flujo de control relevante. Las utilidades UEFI separaron la imagen en componentes. Unicorn Engine emuló la rutina de verificación extraída fuera de la laptop física, reduciendo el riesgo de probar cada cambio mediante una grabación real de firmware.

La biblioteca de criptografía generó firmas de prueba válidas para la rutina emulada. Ese detalle importa porque permitió al usuario comparar entradas válidas y corruptas. No creó una firma de HP válida para el firmware modificado.

Según la publicación original del usuario, el análisis identificó tres grupos de cambios. Uno eludía una comprobación que protegía un volumen de firmware DXE comprimido. Otro exponía 55 campos de configuración. Un tercero revelaba las pestañas Advanced, Power, Debug y Boot.

DXE, o Driver Execution Environment, es una fase de UEFI que inicializa dispositivos y servicios antes de que se inicie el sistema operativo. El código de firmware en este nivel opera por debajo de Windows o Linux. Los errores pueden impedir que la computadora llegue a cualquiera de los dos sistemas operativos.

Los 55 campos supuestamente consistían en 27 entradas suprimidas y 28 entradas atenuadas. Sus definiciones ya existían en los formularios de configuración del firmware. Pequeños cambios en condiciones codificadas de forma rígida hicieron visibles esos campos.

Eso no significa que todas las opciones expuestas controlen hardware compatible. El usuario reconoció más tarde que algunas entradas parecían irrelevantes para la laptop, incluida una configuración de GPS. Los fabricantes suelen compartir componentes de firmware entre varios productos, dejando campos inactivos dentro de una interfaz común.

Las cuatro pestañas adicionales siguieron un patrón similar. El firmware las contenía, pero su lógica de interfaz impedía que se mostraran en este modelo. El parche alteró esa decisión en vez de añadir funciones de configuración completamente nuevas.

El usuario afirmó que la imagen resultante funcionó en su laptop. También publicó un script de Python destinado a reproducir los cambios a partir de un volcado original. Sin embargo, la publicación advirtió que el script se probó solo en la máquina indicada y que podría funcionar únicamente en modelos estrechamente relacionados.

Esto sigue siendo una demostración autoinformada. Ni HP ni Anthropic han validado públicamente la imagen modificada, el análisis ni las opciones de configuración resultantes. Ningún investigador independiente ha publicado una reproducción completa en el mismo modelo de laptop.

Esa brecha de verificación debería orientar toda interpretación de la historia de Tom's Hardware. Los detalles de apoyo del usuario presentan una narrativa técnica creíble, pero un experimento personal exitoso no constituye una capacidad general para desbloquear BIOS.

El titular de Tom's Hardware exagera lo que ocurrió con RSA-2048

Claude Code supuestamente eludió la rama de software que imponía un resultado de verificación. No derrotó el algoritmo RSA-2048 en sí.

Las firmas digitales permiten que un dispositivo compruebe si el firmware procede de un editor autorizado y se ha mantenido sin cambios. El proveedor firma los datos aprobados con una clave privada. Un verificador utiliza la clave pública correspondiente para confirmar esa firma.

Vulnerar RSA-2048 implicaría un resultado criptográfico profundo. Un atacante podría recuperar una clave privada, crear firmas sin autorización o derrotar los supuestos matemáticos subyacentes. La cuenta de Reddit no describe ninguno de esos resultados.

En su lugar, el usuario afirma que Claude Code encontró el código responsable de gestionar el resultado de la firma. La modificación supuestamente forzó ese código hacia su ruta de éxito, independientemente de si la verificación matemática había sido aprobada.

Una analogía útil es la de un guardia de seguridad que comprueba una credencial válida y luego registra la respuesta en un libro. La modificación descrita no fabricó una credencial válida. Alteró lo que ocurría después de que el guardia devolviera una respuesta.

Esa diferencia no vuelve trivial el resultado. Localizar el verificador relevante dentro de un firmware comprimido exigió descompresión, ingeniería inversa, rastreo de código y una cuidadosa reconstrucción de la imagen. Un binario modificado también tuvo que preservar la estructura necesaria para que la máquina arrancara.

Sin embargo, la primitiva criptográfica siguió comportándose según lo previsto. La debilidad descrita se encontraba en la ruta de imposición circundante y en la aparente disposición del sistema a ejecutar código de verificación modificado.

La guía de firmware de Microsoft explica por qué esta separación importa. El código de firmware firmado debe validarse antes de ejecutarse, y los componentes no autorizados no deben ejecutarse. Una función de verificación ofrece poca protección si una capa de confianza anterior no protege esa función.

El propietario de la laptop afirmó que no encontró estructuras Intel Boot Guard necesarias para anclar el código afectado a una cadena de confianza respaldada por hardware. Intel Boot Guard es un mecanismo de plataforma diseñado para autenticar componentes de arranque tempranos antes de que continúe el firmware principal.

Esa afirmación no ha sido confirmada de forma independiente para esta máquina específica. Sin embargo, si es correcta, explica por qué la edición del verificador pudo sobrevivir a un reinicio. La implementación confiaba en código almacenado en memoria flash modificable para decidir si debía confiarse en otro código.

Esta es la inversión central. RSA-2048 puede seguir siendo matemáticamente sólido mientras un producto que lo utiliza aún acepta firmware no autorizado. La seguridad depende de toda la cadena de verificación, no del nombre o la longitud de clave de un solo algoritmo.

Existen precedentes históricos para esta distinción. Investigadores que examinaron Nintendo 3DS documentaron una implementación de firma RSA que aceptaba firmware no autorizado debido a fallos del analizador. Su investigación sobre la ROM de arranque se centró en cómo se procesaban las firmas, no en la dificultad matemática de RSA-2048.

La modificación de HP es técnicamente diferente. El relato publicado describe un flujo de control alterado, en lugar de una firma malformada que explota un analizador. Ambos casos muestran por qué “utiliza RSA-2048” no es una afirmación de seguridad completa.

El enfoque de Tom's Hardware también corre el riesgo de atribuir demasiada autonomía a Claude Code. El humano proporcionó el firmware, seleccionó las herramientas, aprobó las acciones, probó los resultados y aceptó el riesgo de grabar código modificado. Claude operó dentro de un entorno de investigación diseñado por el usuario.

Un titular más preciso diría que Claude Code ayudó a eludir una comprobación de firma RSA-2048 en una compilación de firmware de HP. Sigue siendo llamativo porque el asistente supuestamente se desenvolvió en un dominio que normalmente exige un conocimiento especializado considerable.

El cambio real es la ingeniería inversa asistida por IA

El experimento sugiere que los agentes de programación pueden hacer accesibles flujos de trabajo técnicos avanzados a usuarios más persistentes, incluso cuando la vulnerabilidad subyacente es convencional.

La ingeniería inversa de firmware ha exigido históricamente dominio de código ensamblador, formatos binarios, compresión, criptografía, inicialización de hardware y procedimientos de recuperación. Ningún paso individual del flujo de trabajo descrito es inédito. Coordinar todos los pasos sigue siendo difícil.

Los agentes de IA cambian ese coste de coordinación. Pueden inspeccionar la salida de herramientas, proponer la siguiente consulta, generar pequeñas utilidades de análisis, seguir hipótesis y reescribir scripts cuando un diseño binario difiere de lo esperado. Este trabajo antes exigía búsquedas repetidas en manuales, foros y repositorios de código fuente.

Al parecer, Claude Code no operó como un botón de hackeo de una sola pulsación. En cambio, el relato describe un proceso iterativo. El usuario proporcionó acceso a herramientas especializadas mientras el modelo conectaba hallazgos parciales entre ellas.

Este patrón es más importante que las pestañas de BIOS visibles. Un modelo no necesita inventar un nuevo exploit para alterar la economía de la investigación de seguridad. Solo necesita ayudar a que más personas completen análisis conocidos con mayor rapidez.

El caso también muestra por qué los sistemas agénticos difieren de los chatbots conversacionales. Un agente puede inspeccionar archivos, ejecutar programas, generar código y utilizar los resultados de una acción para planificar otra. Ese ciclo genera ventaja en tareas cuyo progreso depende de decenas de pequeñas decisiones técnicas. Anthropic describe Claude Code como un sistema de programación agéntico que puede leer bases de código, editar archivos, ejecutar pruebas y trabajar con herramientas externas.

Para los desarrolladores, la lección no es que Claude Code se haya convertido en un experto autónomo en firmware. Es que un usuario capaz puede construir un equipo temporal de investigación en torno a un modelo y varias herramientas deterministas.

Las herramientas aportaron formas importantes de fundamentación. Un desensamblador expuso instrucciones de máquina. Un emulador permitió pruebas aisladas. Las utilidades binarias preservaron la estructura interna del firmware. Las sugerencias del modelo se comprobaron frente a la salida de los programas, en lugar de aceptarse como texto.

Esta combinación puede reducir el riesgo de alucinaciones, pero no puede eliminarlo. Un modelo puede interpretar mal una dirección, confundir dos fases de firmware o recomendar un parche inseguro. En el código de aplicaciones convencional, las pruebas suelen detectar esos errores. Los fallos de firmware pueden impedir que un dispositivo arranque.

Eso aumenta la presión sobre Anthropic y otros proveedores de IA. Sus productos de programación operan cada vez más en ámbitos de investigación de seguridad, administración de sistemas y control de hardware. Las mismas capacidades que ayudan a un propietario legítimo a inspeccionar una laptop también pueden ayudar a atacantes a estudiar las protecciones del firmware.

Por tanto, la competencia relevante es entre capacidad y verificación. Los modelos pueden proponer cambios más ambiciosos, pero los usuarios siguen necesitando formas fiables de probarlos. El propietario de la HP utilizó emulación y, según se informó, mantuvo disponible un programador de hardware para la recuperación.

Aquí es también donde los sistemas personales de conocimiento pueden ayudar a los equipos técnicos. Los investigadores deben conservar la salida de herramientas, hipótesis, identificadores de hardware y resultados de pruebas a lo largo de investigaciones extensas. Una base de conocimiento de ingeniería con capacidad de búsqueda puede respaldar ese registro sin pretender validar el firmware en sí.

La industria en general debería esperar que los agentes de programación lleguen a entornos técnicos más inusuales. La ingeniería inversa, el desarrollo embebido, la depuración de controladores y el análisis de protocolos contienen tareas repetitivas que los modelos pueden acelerar.

Esa expansión no eliminará la experiencia. Cambia el punto en el que la experiencia se vuelve esencial. Los usuarios podrían dedicar menos tiempo a escribir scripts utilitarios y más a definir modelos de amenazas, comprobar supuestos y diseñar pruebas seguras.

El caso de Tom's Hardware resume esa transición de forma concisa. Según se informó, Claude Code realizó suficiente trabajo analítico como para ayudar a un entusiasta a superar una barrera. El humano siguió asumiendo las consecuencias.

Las configuraciones ocultas aportan beneficios de propiedad y riesgos de seguridad

Desbloquear un dispositivo puede devolver el control al propietario, pero la experimentación a nivel de firmware conlleva consecuencias que un asistente de IA no puede asumir por el usuario.

Los fabricantes de laptops ocultan configuraciones de BIOS por varias razones. Algunas opciones no se aplican al hardware instalado. Otras pueden desestabilizar la memoria, los controles térmicos, el almacenamiento, la gestión de energía o el comportamiento de arranque.

El firmware compartido ofrece otra explicación. Un proveedor puede usar código de configuración similar en muchos modelos y exponer únicamente los campos validados para cada producto. Por tanto, las opciones ocultas pueden representar componentes de interfaz sin utilizar, en lugar de funciones operativas retenidas.

La opción de GPS reportada ilustra esta limitación. Hacer visible una entrada de menú no crea una radio, antena, controlador o conexión de placa inexistentes. Un campo mostrado puede ser inactivo, engañoso o inseguro.

Algunos usuarios sí tienen motivos legítimos para buscar un control más profundo. Las configuraciones avanzadas pueden ayudar con virtualización, modos de almacenamiento, ajuste energético, depuración o sistemas operativos no compatibles. Los técnicos de reparación e investigadores también pueden necesitar acceso que las interfaces de consumo retienen.

La tensión no es simplemente seguridad del proveedor frente a libertad del usuario. Es configuración validada frente a experimentación sin control. Los proveedores afrontan costes de soporte y garantía cuando combinaciones no documentadas causan fallos, mientras que los propietarios esperan razonablemente tener autoridad sobre el hardware adquirido.

La IA intensifica ambos lados. Puede ayudar a los propietarios a entender firmware opaco y recuperar funcionalidades. También puede producir instrucciones seguras de sí mismas para combinaciones que nunca se probaron en la placa objetivo.

El autor original recomendó explícitamente tener disponible un programador de chips tipo CH341A. Ese hardware puede reescribir directamente un chip flash si la laptop deja de arrancar. Esa advertencia revela mejor el nivel real de riesgo que las capturas de pantalla exitosas.

Incluso un programador no garantiza una recuperación sin dificultades. Acceder al chip puede requerir abrir la laptop, identificar el encapsulado correcto, gestionar los niveles de voltaje y conservar un volcado original. Un error puede dañar el hardware o borrar datos específicos del dispositivo.

El firmware también ocupa una posición altamente privilegiada. El código malicioso o defectuoso puede ejecutarse antes que el sistema operativo y persistir tras reinstalaciones normales. Por ello, los investigadores de seguridad tratan la modificación no autorizada del firmware de manera distinta a la personalización ordinaria de aplicaciones.

Trabajos académicos recientes sostienen que las comprobaciones estáticas por sí solas no pueden observar todas las amenazas de firmware. El marco Peacock propone monitorización en tiempo de ejecución porque los adversarios pueden manipular el comportamiento del firmware después de las comprobaciones iniciales. Esa investigación refuerza la necesidad de una protección por capas.

El caso reportado de HP no establece que la laptop se volviera explotable de forma remota. El usuario ya poseía la máquina, obtuvo su firmware e instaló deliberadamente una imagen modificada. La posesión física y la intención son fundamentales en este escenario.

Sin embargo, la omisión tendría mayor relevancia si otra vía permitiera a un actor no confiable escribir en la región flash afectada. La combinación de una primitiva de escritura y una débil aplicación del arranque puede convertir una técnica de modificación local en un riesgo de persistencia.

No hay evidencia en el material fuente de que exista tal vía remota para este modelo. Sería irresponsable insinuar que millones de laptops HP están ahora expuestas. El hallazgo se refiere a una imagen de firmware y una instalación reportada.

La portabilidad es otra gran incertidumbre. El firmware cambia entre modelos, revisiones de placa base y versiones de BIOS. Las direcciones se desplazan, los módulos cambian y mecanismos de confianza más sólidos pueden rechazar el mismo enfoque.

El usuario afirmó que un cambio para desbloquear pestañas ya había fallado al intentarlo en una placa HP distinta. Esa respuesta debilita la idea de un script universal. También respalda una interpretación más interesante: la IA puede ayudar a adaptar investigación a medida con mayor rapidez, un objetivo a la vez.

HP podría responder mediante futuras actualizaciones de firmware, controles de escritura más sólidos o un componente de arranque verificado anterior. HP afirma que su tecnología Sure Start, respaldada por hardware, está diseñada para prevenir cambios no autorizados de firmware y recuperar código BIOS comprometido, pero el material fuente no establece que esta laptop de consumo incluya esa protección. El propietario de la laptop indicó que su última actualización de firmware llegó en 2024. Los dispositivos de consumo más antiguos podrían no recibir nunca un rediseño de su cadena de confianza.

Anthropic afronta una cuestión distinta sobre salvaguardas. El trabajo presenta características claras de doble uso, lo que significa que puede respaldar investigación legítima y modificaciones dañinas. Una negativa generalizada bloquearía a propietarios y defensores, mientras que una automatización sin restricciones puede reducir las barreras para los atacantes.

Un límite de seguridad sensato depende del contexto, el acceso, la intención y el detalle operativo. Explicar por qué falló una comprobación de firma es distinto de ayudar a desplegar persistencia sigilosa en varias máquinas. Los proveedores de modelos deben distinguir esos escenarios sin asumir que toda tarea de firmware es maliciosa.

Una laptop exitosa no establece una capacidad general

La demostración resulta convincente como estudio de caso, pero débil como prueba de que Claude Code puede desbloquear de forma fiable las protecciones modernas de BIOS.

La evidencia más sólida proviene del relato detallado del usuario. Mencionó la laptop, la revisión de BIOS, las herramientas, las estructuras de firmware, los campos descubiertos y el proceso general de validación. También reveló limitaciones en lugar de afirmar compatibilidad universal.

La evidencia más débil es la reproducción independiente. Ningún analista independiente ha documentado públicamente el mismo resultado utilizando una imagen F.68 limpia en otra HP 15-dw1036ne. HP no ha confirmado la arquitectura ni evaluado la omisión reportada.

El resultado visible tampoco puede demostrar cada paso de la explicación. Las fotos de nuevas pestañas de menú mostrarían que una interfaz modificada arrancó. No establecerían qué ruta de código aceptó el firmware ni si otra protección se desactivó antes.

El script publicado proporciona material adicional para revisión, pero ejecutarlo no es un método de verificación seguro para lectores comunes. Una auditoría responsable inspeccionaría el código, reproduciría las transformaciones binarias sin conexión y compararía la salida con firmware obtenido de forma independiente.

Los investigadores también tendrían que confirmar la supuesta ausencia de aplicación de Intel Boot Guard. Esa comprobación determina si el éxito reportado dependió de la ausencia de una raíz de confianza respaldada por hardware. También limita las conclusiones sobre sistemas más nuevos o enfocados a empresas.

La atribución al modelo sigue siendo imprecisa. El usuario de Reddit afirmó que utilizó principalmente Claude Opus 4.8 y, en ocasiones, Sonnet 5 mediante Claude Code. El registro no aísla qué modelo encontró cada elemento ni cuánto orientó el humano el enfoque final.

El historial de prompts ayudaría a distinguir el descubrimiento de la implementación guiada. Si el usuario proporcionó nombres probables de módulos, patrones de firmware conocidos o ramas candidatas, la contribución de Claude difiere de una búsqueda en gran medida independiente.

Los recuentos de tokens, los intentos fallidos y el tiempo transcurrido aportarían más contexto. Un flujo de trabajo que requirió una intervención extensa sigue teniendo valor, pero dice menos sobre el desempeño autónomo que una ejecución reproducible desde un punto de partida limpio.

La frase “la IA derrota RSA-2048” no supera esta prueba de rigor. La modificación reportada no atacó el espacio de claves de RSA. Omitió un mecanismo de gestión de resultados en un sistema que presuntamente carecía de otra capa capaz de proteger ese mecanismo.

Esa corrección no debería convertirse en una excusa para desestimar el trabajo. Encontrar el código relevante dentro de firmware comprimido puede consumir mucho tiempo humano. Reempaquetar la imagen sin romper desplazamientos ni dependencias añade otro desafío práctico.

La pregunta valiosa es si Claude Code reduce ese esfuerzo de manera consistente. Una anécdota no puede responderla. Una evaluación útil asignaría a varios investigadores múltiples objetivos de firmware y compararía el tiempo de finalización, la precisión y las recomendaciones inseguras.

Estas pruebas deberían incluir plataformas protegidas y no protegidas. Un agente debe reconocer cuándo un parche propuesto no puede superar una etapa de verificación respaldada por hardware. Persistir en una teoría falsa podría desperdiciar tiempo o dañar un dispositivo.

Los investigadores también deberían medir si el modelo inventa significados no respaldados para configuraciones ocultas. Las etiquetas de interfaz por sí solas no prueban que una función funcione. El sistema más seguro diferenciaría entre “campo descubierto”, “campo mostrado” y “comportamiento validado”.

Hasta que existan esas pruebas, la historia de Tom's Hardware pertenece a la categoría de investigación de seguridad asistida por IA reportada. No demuestra un exploit automatizado de BIOS de propósito general. Sí demuestra que el uso de herramientas especializadas se está acercando a personas no especialistas.

Tres señales mostrarán si esto fue una anécdota o un punto de inflexión

La próxima evidencia debería provenir de la reproducción, el análisis del proveedor y evaluaciones más amplias de agentes, no de otro titular dramático.

La primera señal es la reproducción independiente en el mismo modelo y firmware. Un investigador creíble tendría que obtener una imagen limpia, confirmar los módulos relevantes, reproducir los cambios y documentar las precauciones de recuperación.

Una reproducción exitosa reforzaría la afirmación de que el relato técnico describe con precisión la ruta de confianza de la laptop. Un fallo sugeriría que un estado no documentado del dispositivo, una modificación previa o un paso ausente influyó en el resultado.

La segunda señal es una respuesta de HP o del proveedor de firmware subyacente. El proveedor podría confirmar si se esperaba que el volumen afectado estuviera protegido por otro mecanismo. También podría aclarar si la laptop ha llegado al final de su soporte activo de firmware.

Una actualización de firmware que proteja el verificador mediante un ancla de confianza anterior validaría la importancia de seguridad del informe. Un hallazgo del proveedor de que la modificación requirió una programación física sin restricciones acotaría sus implicaciones de amenaza.

La tercera señal es un rendimiento repetible de los agentes de IA en objetivos de firmware no relacionados. Los investigadores deberían seguir si Claude Code puede localizar fallos de implementación comparables sin orientación específica para cada objetivo. Deberían registrar los falsos positivos y las imágenes de prueba dañadas junto con los casos exitosos.

El éxito repetido demostraría que los agentes de IA están cambiando la accesibilidad de la ingeniería inversa de firmware. Los resultados inconsistentes situarían este caso como una colaboración impresionante entre un usuario motivado y un modelo, no como una capacidad generalizada.

Los lectores también deberían observar cómo las empresas de IA describen estos sistemas. «Asistente de programación» ya no refleja a un agente capaz de coordinar desensambladores, emuladores, utilidades binarias y pruebas criptográficas. Las afirmaciones sobre la seguridad de los productos deben tener en cuenta los entornos que los usuarios pueden configurar alrededor del modelo.

Para los desarrolladores y equipos de seguridad, la respuesta práctica es una verificación disciplinada. Conserven las imágenes originales, aíslen las pruebas, documenten las suposiciones y exijan una revisión específica del hardware antes de la implementación. La confianza generada por la IA no sustituye una vía de recuperación.

Los trabajadores del conocimiento afrontan una lección relacionada. Los agentes se vuelven más útiles cuando su trabajo se fundamenta en evidencia rastreable. Conservar prompts, resultados, hashes binarios y observaciones de prueba en un sistema personal de conocimiento estructurado permite realizar revisiones posteriores.

El titular de Tom's Hardware atraerá atención porque enfrenta a Claude Code con RSA-2048. La historia duradera es menos cinematográfica. Según se informa, un usuario combinó un agente de IA con herramientas especializadas para encontrar un punto débil alrededor de una criptografía sólida.

Eso sigue siendo significativo. La seguridad suele fallar donde se conectan los componentes, y los agentes de programación están adquiriendo habilidad para rastrear esas conexiones. La siguiente pregunta es si investigadores independientes pueden reproducir este resultado sin heredar las suposiciones del usuario original.

Hasta entonces, consideren la modificación de la BIOS como un caso de estudio técnicamente plausible, cuidadosamente descrito, pero no verificado. Sigan las reproducciones, examinen cualquier respuesta del proveedor y distingan entre una aplicación defectuosa y una criptografía defectuosa.