⏱️ Lectura: 13 min
Portar un firmware libre a una laptop antigua puede llevar de tres a seis meses de trabajo manual. Arthur Heymans, contribuidor de coreboot, lo resolvió en cuestión de días apoyándose en un modelo de lenguaje grande (LLM). La técnica, que él mismo llama ingeniería inversa con IA, abre una conversación incómoda y fascinante sobre cómo cambia el trabajo de bajo nivel.
📑 En este artículo
El objetivo era el ThinkPad x61, una de las pocas generaciones de esa familia que nunca tuvo soporte en coreboot. Sin documentación filtrada del chipset, la única vía era reconstruir el comportamiento del BIOS original desde cero.
TL;DR
- Arthur Heymans portó coreboot al ThinkPad x61 (northbridge GM965, southbridge ICH8) usando ingeniería inversa asistida por IA.
- Este tipo de port suele llevar de 3 a 6 meses; con un LLM el grueso se resolvió en días.
- Las herramientas: Claude Opus como asistente, Ghidra vía ghidra-cli, radare2, inteltool y bios_extract.
- El reto central fue reconstruir el raminit (init de RAM) del BIOS Phoenix, un módulo PE32 derivado del Intel MRC.
- Encontró al menos 3 versiones del raminit: un esquema A/B con copia de recuperación de solo lectura.
- La plataforma x61 nunca tuvo soporte en coreboot pese a intentos previos con SerialICE.
- El autor aclara que la IA acelera pero no reemplaza: el modelo necesitó muchísimo acompañamiento experto.
Qué pasó
Heymans es un nombre conocido en el ecosistema del firmware libre: contribuidor de coreboot y empleado de 9elements, llegó a ese mundo, como muchos, leyendo sobre software libre y queriendo liberar el último bastión cerrado de sus máquinas: el firmware. Con los años acumuló una colección considerable de ThinkPads (x60, x200, x201, x220, t480, R500), pero le faltaba una generación: el x61.
El x61 monta un northbridge GM965 y un southbridge ICH8. Sobre el papel no es territorio desconocido: el GM965 se parece al GM45 que ya corre en el ThinkPad x200, aunque solo soporta DDR2; y el ICH8 es primo cercano del ICH9, que coreboot ya maneja. El problema es que no existen documentos filtrados de esta plataforma. Intentos anteriores con SerialICE —una herramienta que ejecuta el firmware dentro de QEMU y reenvía las operaciones de E/S y MMIO al hardware real— nunca produjeron un port funcional.
En marzo de 2026, Heymans estaba experimentando con LLMs en su flujo de trabajo y decidió probar qué tan lejos podían llegar en una tarea tan especializada. Usó Claude Opus, el estado del arte en ese momento. Hizo una prueba sobre un BIOS de fabricante descargado, los resultados se veían prometedores, compró el equipo y terminó con el port funcionando.
Contexto: qué es coreboot y por qué importa el firmware libre
coreboot es un firmware de arranque de código abierto que reemplaza al BIOS o UEFI propietario que viene de fábrica. Su filosofía es minimalista: hacer lo mínimo indispensable para inicializar el hardware (CPU, memoria, buses) y luego ceder el control a un payload —puede ser SeaBIOS, GRUB, Tianocore o incluso un kernel de Linux directo—. El resultado típico es un arranque más rápido, auditable y libre de blobs innecesarios.
El firmware es, históricamente, el rincón más oscuro del software libre. Puedes correr un sistema operativo completamente abierto y aun así depender de un BIOS cerrado que ejecuta el primer código en tu máquina. Proyectos como libreboot (una distribución de coreboot sin blobs) nacieron precisamente para cerrar esa brecha en hardware donde es posible.
El cuello de botella de coreboot siempre ha sido el soporte de plataformas. Cada chipset necesita código específico de inicialización, y sin documentación del fabricante, ese código solo puede obtenerse por ingeniería inversa. Ahí es donde la ingeniería inversa con IA promete cambiar las reglas: si un asistente puede leer y entender binarios desensamblados, el costo de portar plataformas huérfanas baja drásticamente.
El reto: una plataforma sin documentación
Antes de tocar el firmware del fabricante, Heymans hizo lo que cualquier ingeniero de bajo nivel sensato haría: extraer todo el conocimiento posible de un sistema que funciona. Los valores conocidos como buenos son oro puro cuando algo falla: si la DRAM no entrena o el USB deja de responder, tener una referencia contra la cual comparar ahorra semanas.
Para eso usó las herramientas clásicas de coreboot. Un volcado completo de configuración y registros da pistas sobre el EC, las tablas ACPI, la configuración PCI, el pinout de GPIO y las tablas de verbos HDA del códec de audio.
# Vista general del espacio de configuración PCI y registros del chipset
inteltool -a
# Sanity check de cómo ve Linux la máquina
lspci -nnvv
# Volcado y decompilado de las tablas ACPI
acpidump > acpi.dump
acpixtract -a acpi.dump
iasl -d *.dat
# Lectura de la RAM y el comportamiento del Embedded Controller
ectool -iLos ThinkPad esconden muchos detalles específicos de la placa dentro del Embedded Controller (EC), así que inspeccionarlo con ectool fue clave. También guardó la información de la CPU y del códec HDA, datos fáciles de perder mientras uno se sumerge en el código del firmware.
📌 Nota: los valores de referencia de un equipo que funciona no son un lujo, son la red de seguridad. Sin ellos, depurar la inicialización de DRAM a ciegas es prácticamente imposible.
Cómo se hizo la ingeniería inversa con IA
El x61 usa un BIOS Phoenix, así que el primer paso fue separar la imagen en módulos independientes con bios_extract. Después, Heymans le dio al agente de IA un conjunto acotado de herramientas que podía invocar por su cuenta, sin que él manejara la interfaz gráfica todo el tiempo.
La pieza más útil fue ghidra-cli acompañada de su SKILL.md, un archivo que le explica al modelo cómo y cuándo usar la herramienta. Así el agente podía hacerle preguntas a Ghidra de forma programática. También configuró una skill de radare2, porque ese desensamblador resulta cómodo para las partes en modo real de 16 bits del firmware.
Esa distinción importa. La mayor parte del firmware es código de 16 bits en modo real, pero el raminit —la rutina que inicializa la RAM— es un módulo PE32 que parece provenir del Intel MRC (Memory Reference Code). Para esa parte, ghidra-cli funcionó mucho mejor, porque el código original probablemente era C y la salida del decompilador era realmente legible. Para el pegamento alrededor, radare2 le dio mejores resultados al agente.
# 1) Separar la imagen Phoenix en módulos
bios_extract vendor_bios.rom
# 2) El agente consulta Ghidra de forma programática (esquema conceptual)
ghidra-cli analyze raminit.pe32
ghidra-cli decompile --function FUN_raminit_main
# 3) Para el glue de 16 bits en modo real, radare2
r2 -a x86 -b 16 module_realmode.binUna sorpresa: encontró al menos tres versiones del raminit dentro de la imagen. Su hipótesis es que se trata de un esquema A/B con una copia de recuperación de solo lectura. La copia RO se salta buena parte del flujo normal de inicialización y solo busca recuperar la máquina lo suficiente para reflashear el resto del BIOS. Esto coincide con el comportamiento documentado de los ThinkPad de Lenovo, donde los 64 KB superiores del flash están protegidos contra escritura justamente con fines de recuperación.
graph LR
A["BIOS del fabricante"] --> B["bios_extract"]
B --> C["Modulos separados"]
C --> D["Ghidra / radare2"]
D --> E["LLM analiza el raminit"]
E --> F["Codigo coreboot"]
F --> G["Flash y prueba en hardware"]
El matiz honesto: la IA no hizo magia
El post incluye un giro que conviene leer con atención. Hay una sección donde Heymans describe un escenario idílico: el LLM extrajo toda la secuencia de inicialización, escribió el port en dos prompts, y funcionó al primer intento mientras él estaba en el gimnasio. Acto seguido aclara: todo lo anterior es mentira.
En la realidad, el modelo necesitó muchísimo acompañamiento. Heymans tiene conocimiento profundo de plataformas similares y un entendimiento íntimo de los detalles, y fue precisamente ese expertise el que guió al agente paso a paso. La IA aceleró el proceso, pero no sustituyó la pericia humana. Es una distinción crucial en un momento donde abundan los relatos de vibe coding que prometen resultados sin esfuerzo.
💭 Clave: el LLM no reemplazó al ingeniero; multiplicó su productividad. Sin la experiencia previa de Heymans en GM45/ICH9, el agente no habría llegado a buen puerto.
Datos y cifras
Los números ponen en perspectiva por qué esto importa para quienes trabajan en firmware:
- 3 a 6 meses — tiempo estimado para portar manualmente la plataforma GM965/ICH8 del x61.
- Días — tiempo en que se resolvió el grueso del trabajo con asistencia de IA.
- 3+ versiones del raminit — copias halladas en la imagen del BIOS (esquema A/B con recuperación RO).
- 64 KB — región superior del flash protegida contra escritura para recuperación en ThinkPads.
- 16 bits — modo real en el que está escrita la mayor parte del firmware; el raminit es la excepción en PE32.
- 10+ años — antigüedad de la afición de Heymans por liberar firmware de ThinkPads, desde su primer x60.
Impacto y análisis
Para LATAM, donde el hardware de segunda mano es parte central del ecosistema de desarrolladores y entusiastas, esta noticia tiene una lectura práctica. Los ThinkPad x60, x200 y x220 siguen siendo máquinas codiciadas por su reparabilidad, sus teclados y la posibilidad de correr firmware libre. Que la barrera de portar nuevas plataformas baje significa que más equipos viejos podrían recibir coreboot, prolongando su vida útil y reduciendo basura electrónica.
A nivel de industria, el caso es un ejemplo concreto de IA aplicada a una tarea que parecía blindada contra la automatización: leer binarios sin símbolos, sin documentación y en arquitecturas antiguas. La ingeniería inversa con IA no se limita a portar firmware libre; las mismas técnicas sirven para análisis de malware, auditoría de seguridad de dispositivos y descubrimiento de vulnerabilidades. Es una herramienta de doble filo que vale la pena entender bien.
El riesgo a evitar es el entusiasmo ciego. El propio relato de Heymans, con su falso final feliz, es una advertencia editorial: la IA acelera, pero la verificación experta sigue siendo obligatoria. Un raminit mal reconstruido no da un error de compilación elegante; da una máquina que no enciende o que corrompe memoria de formas sutiles.
⚠️ Ojo: confiar a ciegas en el código que produce un LLM para inicialización de hardware puede dejar un equipo inservible (brick). Siempre hay que tener un programador externo de flash y un respaldo del BIOS original.
Qué sigue
El siguiente paso natural es la integración del port en el árbol oficial de coreboot, donde la comunidad lo revisará y probará en más unidades del x61. También queda por ver qué tan reproducible es el método: si otros contribuidores con menos experiencia en el chipset pueden replicar el flujo con sus propias plataformas huérfanas, el impacto será mucho mayor.
Más allá del x61, el experimento sugiere un patrón de trabajo emergente: un ingeniero experto que orquesta agentes de IA equipados con herramientas especializadas (Ghidra, radare2) mediante archivos de skills bien escritos. No es el fin del trabajo de bajo nivel; es una nueva forma de ejercerlo, donde el cuello de botella deja de ser leer cada instrucción y pasa a ser saber qué preguntar.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es coreboot?
Es un firmware de arranque de código abierto que reemplaza al BIOS o UEFI propietario. Inicializa el hardware mínimo necesario y luego entrega el control a un payload como SeaBIOS, GRUB o Tianocore. Su ventaja es un arranque auditable, rápido y libre de blobs innecesarios.
¿La IA hizo el port sola?
No. El autor fue explícito en desmentir esa idea. El LLM aceleró la lectura y comprensión del firmware desensamblado, pero necesitó un acompañamiento constante de un ingeniero con conocimiento profundo de plataformas similares. La IA fue un multiplicador, no un reemplazo.
¿Qué es el raminit y por qué fue tan difícil?
El raminit es la rutina que inicializa la memoria RAM durante el arranque. En el x61 es un módulo PE32 derivado del Intel MRC (Memory Reference Code). Reconstruirlo es crítico porque sin una inicialización de DRAM correcta, la máquina simplemente no arranca.
¿Qué herramientas se usaron?
Claude Opus como asistente de IA, Ghidra a través de ghidra-cli, radare2 para el código de 16 bits en modo real, bios_extract para separar la imagen Phoenix, e inteltool, lspci, acpidump, iasl y ectool para volcar datos del sistema funcional.
¿Por qué importa este logro para usuarios de hardware antiguo?
Porque baja el costo de portar coreboot a plataformas sin documentación. Esto significa que más laptops antiguas, muy presentes en el mercado de segunda mano de LATAM, podrían recibir firmware libre, extendiendo su vida útil y mejorando su seguridad y privacidad.
¿Es seguro flashear coreboot en mi ThinkPad?
Conlleva riesgo de inutilizar el equipo (brick). Se recomienda usar un programador externo de flash, respaldar el BIOS original y seguir la documentación oficial de coreboot para tu modelo específico antes de intentarlo.
Referencias
- Arthur’s blog — Porting the ThinkPad x61 to coreboot — el relato original del proceso.
- coreboot.org — sitio oficial del proyecto de firmware libre.
- Documentación de coreboot — guías de soporte de plataformas y flasheo.
- Ghidra en GitHub — el framework de ingeniería inversa de la NSA.
- libreboot.org — distribución de coreboot enfocada en eliminar blobs propietarios.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios