Computación Cuántica y Fusión Nuclear: La Receta para fabricar un "Sol en la Tierra"

Desde hace casi un siglo, la Fusión Nuclear se presenta como el santo grial de la energía: la promesa de replicar en la Tierra la misma reacción que hace brillar al Sol, obteniendo cantidades inmensas de energía limpia, sin los residuos ni los riesgos de fusión del núcleo asociados a las centrales de fisión actuales. Pero como bien podréis imaginar, construir un ”Sol artificial” es más fácil de decir que de hacer. 

Figura 1: Computación Cuántica y Fusión Nuclear.

La Receta para fabricar un "Sol en la Tierra"

Y no, esta vez el problema no está sólo en confinar un plasma a millones de grados con campos magnéticos. Hay un obstáculo mucho más mundano y del que se habla bastante menos: el combustible.

Figura 2: ”Boffins bet on quantum computers, AI supers to solve fusion fuel dilemma”

Este es precisamente el escenario que analiza el artículo de The Register titulado ”Boffinsbet on quantum computers, AI supers to solve fusion fuel dilemma”, donde se explica cómo el Departamento de Energía de EE.UU., la Cleveland Clinic e IBM han unido fuerzas para atacar este problema con una combinación de superordenadores, inteligencia artificialy ordenadores cuánticos.

Figura 3: Oak Ridge National Lab, Cleveland Clinic, and IBM Achieve

First-Known Computations of Fusion Materials on a Quantum Computers

Para conseguir la fusión necesitamos dos ingredientes: Deuterio y Tritio (Tritium), dos isótopos pesados del hidrógeno. El primero no supone ningún problema, ya que es abundante y se puede extraer del agua del mar. El segundo, en cambio, es el auténtico cuello de botella: el Tritio es radiactivo, se desintegra con rapidez y prácticamente no existe de forma natural en la Tierra.

El problema: un combustible que no existe (casi)

Para que os hagáis una idea de la magnitud del problema: la producción mundial de Tritio es de apenas unos pocos kilos al año, mientras que una sola central de fusión de un Gigavatio (GW) consumiría en torno a medio kilo al día. Es decir, todo el Tritio del planeta mantendría funcionando un único reactor durante unas pocas semanas. 

Figura 4: Esquema resumido del problema de relacionado

con el ”combustible” de la fusión nuclear

Es como querer montar una red de gasolineras en un mundo donde el petróleo se vende por gotas. La conclusión es evidente: una central de fusión comercial no puede depender de un suministro externo, sino que debe fabricar su propio combustible mientras funciona.

La solución: una manta de sal fundida

La propuesta más prometedora consiste en envolver el reactor con una gruesa ”manta” de una sal fundida llamada FLiBe, compuesta por Flúor, Litio y Berilio. La idea es tremendamente elegante: cuando un neutrón sale disparado de la reacción de fusión y golpea un átomo de Litio-6 de la sal, este se rompe generando Helio y... ¡Tritio fresco! El Berilio, por su parte, multiplica los neutrones sueltos para que la ”cría” de combustible sea suficiente, mientras que el flúor y el litio mantienen la mezcla líquida y estable a las temperaturas infernales del reactor.

Figura 5: Esquema de un tokamak rodeado por la

manta de sal fundida donde se genera el Tritio.

Pero aquí llega la letra pequeña. Una vez generado el Tritio dentro de la sal, hay que sacarlo de ahí, y su comportamiento químico puede seguir dos caminos muy distintos:

• Si el Tritio permanece libre en forma de gas: burbujea y sale solo de la mezcla. ¡Perfecto!

• Si en cambio se une al flúor, forma fluoruro de Tritio: un compuesto corrosivo y muy difícil de extraer. Un auténtico quebradero de cabeza.

Predecir cuál de los dos caminos tomará requiere modelar la química de la sal con una precisión extrema. Y aquí los métodos clásicos se quedan cortos: la técnica habitual, la Teoría del Funcional de la Densidad (DFT), puede cometer errores de hasta el 10% en la energía libre del sistema, un margen inaceptable para responder a la pregunta clave. 

Además, hacer experimentos reales con sales fundidas es carísimo y requiere instalaciones muy especializadas. ¿Os suena este patrón?  Un problema de naturaleza cuántica que desborda a los ordenadores clásicos... ¡Es justo el tipo de tarea para el que nacieron los ordenadores cuánticos!

Supercomputación Cuántico-Céntrica: CPUs, GPUs y QPUs trabajando en equipo.

Como ya hemos comentado en otros artículos de este blog, los ordenadores cuánticos no vienen a sustituir a los clásicos, sino a complementarlos en problemas muy concretos. Y este trabajo es el ejemplo perfecto de esa filosofía, bautizada por IBM como Supercomputación Cuántico-Céntrica: combinar CPUs, GPUs & QPUs (procesadores cuánticos) para resolver juntos lo que ninguno puede resolver por separado.

La estrategia que han seguido los investigadores es muy ingeniosa:

• Fragmentación del problema: mediante una técnica llamada wave function-based embedding, el cálculo de la molécula completa se trocea en fragmentos manejables llamados ”clusters”.

• Reparto del trabajo: los ordenadores clásicos resuelven los clusters sencillos, mientras que el ordenador cuántico se encarga de los más complejos, aquellos con mayor entrelazamiento entre átomos, utilizando un algoritmo llamado Sample-Based Quantum Diagonalization (SQD).

Figura 6: Sample-Based Quantum Diagonalization (SQD) 

• Reconstrucción: finalmente, los ordenadores clásicos ”recosen” todos los fragmentos para obtener la solución de la molécula completa.

Lo curioso es que esta metodología no nació para la fusión: es la misma que utilizó laCleveland Clinic a principios de año para simular una proteína de 12.635 átomos. La ciencia es así de caprichosa, y una técnica desarrollada para biomedicina acaba siendo clave para la energía del futuro.

Figura 7: Modelado de la interacción entre el Tritio y

los clusters de átomos de la sal fundida FLiBe.

Con este enfoque, el equipo calculó las energías de nueve configuraciones moleculares de FLiBe (clusters de 21 iones cada una), con y sin Tritio, siendo la primera vez que se realizan este tipo de cálculos de materiales de fusión en un ordenador cuántico. 

Figura 8: Quantum Computations on Fusion Blanket Molten Salts

Y lo más importante es que los resultados cuánticos igualaron a los métodos clásicos más exigentes. Puede parecer poco ambicioso ”sólo igualar”, pero es la prueba de concepto necesaria que demuestra que el camino cuántico funciona y está listo para escalar hacia donde los clásicos ya no llegan.

El futuro: un bucle de IA, superordenadores y cuántica

Este cálculo es solo una pieza de un plan mucho más ambicioso. El objetivo a largo plazo es construir un flujo de trabajo en bucle, asistido por agentes de inteligencia artificial, que funcione en tres etapas:

1. Cribado con IA: agentes de inteligencia artificial proponen y filtran candidatas a partir de una base de datos del ”Oak Ridge National Lab” con 70 años de investigación en sales fundidas, estimando cuánto tritio generaría cada sal y si sus propiedades térmicas son adecuadas.

2. Simulación clásica: las sales más prometedoras pasan a los superordenadores, que las modelan átomo a átomo. Como estas simulaciones son carísimas, se emplean ”sustitutos” de IA entrenados para reproducir la física a gran velocidad.

3. Precisión cuántica: el ordenador cuántico entra donde la DFT se queda corta: la química de alta precisión que decide dónde se une el tritio. Los resultados realimentan el bucle, afinando la siguiente ronda de candidatas.

El sueño de los investigadores es que, en el futuro, los ingenieros de fusión puedan diseñar y validar una sal fundida completamente por ordenador antes de mezclarla y calentarla en un laboratorio, ahorrando años de experimentos y cantidades ingentes de dinero.

Figura 9: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

Eso sí, seamos honestos con las limitaciones: el problema completo requiere modelar una manta de sal de un metro de grosor con del orden de un cuatrillón de partículas, algo que seguirá fuera del alcance de la química computacional durante mucho tiempo.  El plan inmediato es más modesto pero realista: aumentar el tamaño de los clusters mucho más allá de los 21 iones actuales y calcular los cientos de configuraciones que exige el problema completo, no solo nueve.

Figura 10: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica. 

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

En definitiva, estamos presenciando cómo tres de las tecnologías más punteras de nuestro tiempo (la Inteligencia Artificial, la Supercomputación y la Computación Cuántica) dejan de competir entre sí para unir fuerzas contra uno de los grandes problemas de ingeniería de la humanidad.  Los ordenadores cuánticos ya no solo prometen revolucionar el futuro: están ayudando a construirlo. La pregunta es inevitable: ¿será la cuántica la pieza que por fin encienda nuestro propio sol en la Tierra?

Figura 3: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Si te interesan estos temas, te recomiendo que te apuntes al Foro Online Público que funciona desde Septiembre del año pasado en MyPublicInbox, donde se comparten temas de Quantum & Post-Quantum Securrity, así que si quieres estar informado puedes entrar libremente y suscribirte. Y si quieres más, apúntate al curso de Quantum y Post-Quantum Computing para Ciberseguridad.

Saludos,

Autor: Daniel Romero Ruiz

Contactar con Daniel Romero Ruiz

Otros artículos sobre Quantum Computing publicados:

• III edición del Programa de Especialización de Quantum y Post-Quantum Computing para Ciberseguridad: Noviembre 2026
• Libro de Quatum Security: Tecnología Cuántica & Ciberseguridad. Criptográfica Cuántica y Post-Cuántica. 
• Foro Público de Quantum Security de la Universidad de Deusto en MyPublicInbox
• Quantum Computing Cybersecurity Preparedness Act: Comienza la era de Ciberseguridad Post-Quantum en Estados Unidos
• Hamming Quasi-Cyclic (HQC-KEM): Nuevo Key-Encapsulation Mechanism en Post-Quantum Cryptography
• FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"
• La Gran Búsqueda de Números Primos de Mersenne en Internet para superar el mayor Número Primo conocido hasta la fecha
• Cómo acelerar los algoritmos de Inteligencia Artificial con Computadores Analógicos Ópticos (AOC)
• Premio Nobel en Física 2025: El trabajo del "Efecto Tunel" que trajo la cuántica a nuestro mundo y abrió la puerta a los ordenadores cuánticos
• Un Reloj Atómico Óptico del MIT con Optimización Cuántica para medir el Tiempo del Futuro
• Quantum Cryptography: Una comunicación con cifrado cuántico
• Factorización de RSA con un Optimizador de Quantum Computing (y Classic Computing)
• Cuánto del tráfico en Internet funciona con Post-Quantum Cryptography
• Algoritmo Cuántico de Grover: Un algoritmo de búsqueda optimizado por superposición cuántica 
• Quantum Sensors: Cuando lo invisible se hace visible gracias al Mundo Cuántico
• Bitcoin vs Quantum Computers: Hora de pasar a Post-Quantum Cryptography
• El White Paper de MasterCard que urge a pasar a Quantum Safe: Post-Quantum Cryptography (PQC) & Quantum Key Distribution (QKD)
• Dyber: Hardware-Accelerated Post-Quantum Cryptography (PQC)
• Cómo ser Quantum Safe y desplegar Post-Quantum Cryptography (PQC) con Cloudflare
• Quantum GPS: Navegación con GPS cuánticos para evitar ataques de Jamming & Spoofing
• Cómo comprobar si un Web Site es Quantum Ready con Post-Quantum Cryptography usando Radar
• Alaniz Cipher: Un Cifrado Simétrico Quantum Resistant
• Los Papers Académicos de los algoritmos PQC de Autenticación y Firma Digital en la Ronda 3 del NIST
• Blind Quantum Computing (1) (2) (3) (4)

DONKEY.BAS on the Edge: Cómo revivimos el juego de Bill Gates de 1981 con Cloudflare Workers y Pages (Just For Fun!)

Hace unos días hablando con Chema Alonso me topé otra vez con uno de esos pequeños tesoros que la historia de la informática guarda en un cajón. DONKEY.BAS. Cuatro mil quinientos bytes de BASIC que vienen de 1981 y que, sin embargo, dan para hablar de muchas cosas. De cómo se hacía software cuando un PC tenía 16KB de RAM, de una de las polémicas más divertidas de la historia de Microsoft y, sobre todo, de algo que veo todos los días en mi trabajo, que es lo fácil que es hoy modernizar y desplegar cualquier aplicación gracias a la plataforma de Cloudflare.

Figura 1: DONKEY.BAS on the Edge: Cómo revivimos el juego de

Bill Gates de 1981 con Cloudflare Workers y Pages (Just For Fun!)  

Así que cogí el código original, lo migré a la web y lo puse a correr en producción en Cloudflare Pages en cuestión de minutos. Os cuento la historia completa, que tiene su miga. De la historia de este juego, por lo visto, se habla en el libro de  "Microhistorias: anécdotas y curiosiades de la historia de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso en 0xWord, que os dejo por aquí.

Figura 2: Libro de "Microhistorias: anécdotas y curiosiades de la historia
de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso 0xWord.

Por cierto, antes de entrar en materia con DONKEY.BAS, os recuerdo que ya os publiqué un caso parecido con la migración del mítico Arkanoid en el artículo titulado: "Cómo migrar Arkanoid de C++ a TypeScript con OpenCode y desplegarlo en Workers de Cloudflare".

La historia: el juego que Bill Gates escribió... y por el que le pincharon durante años

DONKEY.BAS lo escribieron en 1981 Bill Gates y Neil Konzen para demostrar las capacidades gráficas (el flamante modo CGA) y de sonido (el mítico PC speaker) del IBM PC, junto con la potencia del intérprete de BASIC que Microsoft había desarrollado para IBM. Venía incluido en las primeras versiones de PC-DOS, así que millones de personas lo tuvieron delante.

Figura 3: El juego de Donkey.BAS Version 2.0 (Fixed Version)

¿El juego? Sencillísimo: conduces un coche por una carretera de dos carriles y solo puedes hacer una cosa, cambiar de carril con la barra espaciadora para esquivar a los burros que van apareciendo. Si chocas, ¡BOOM! y punto para el burro. Si lo esquivas, "Donkey loses!" y punto para ti. No hay más objetivo. No hay final.

Y aquí viene lo "polémico".

Que uno de los fundadores de Microsoft hubiera firmado un juego tan primitivo —con gráficos que parpadeaban y una jugabilidad de quince segundos— se convirtió con los años en una especie de chiste recurrente en la industria.

Cuando salió el Macintosh en 1984, desde el mundo Apple se usó DONKEY.BAS como ejemplo de lo tosco que era el software del bando IBM/Microsoft frente a la elegancia gráfica del Macintosh. Bill Gates, lejos de esconderlo, siempre lo defendió con orgullo: era una demo técnica de lo que se podía hacer, no una obra maestra del diseño de videojuegos.

Figura 4: Pantalla de título original de DONKEY.BAS con el famoso "Version 1.1O"

Hay un detalle que a mí me encanta y que demuestra que las prisas de 1981 eran las mismas que las de hoy: si miráis el código original, en la pantalla de título pone Version 1.1O... con una letra "O mayúscula" en lugar de un cero - tal vez por no mostrar a los usuarios el famoso 0 de las tipografías de los ordenadores con la raya cruzada que los no técnicos quizá nunca entendieron -. Usas una O en lugar de un 0 con la raya cruzada, era igual que en algunas máquinas de escribir donde en lugar de usar el 1 se hacía con la "l" minúscula.

O quizá es un typo que lleva más de cuarenta años viajando por copias y copias del fichero. Quien diga que nunca ha subido a producción con una errata, que tire la primera piedra. El código fuente original que usé como referencia está perfectamente conservado aquí:

Figura 5: DONKEY.BAS en GitHub

Merece la pena abrir el .BAS y leer esos GOTO, esos POKE 106,0 y esos SOUND 37+RND*200,4. Es arqueología pura, y para los amantes del BASIC, un placer visual. 

La migración: de GOTO y POKE a HTML5, Canvas y Web Audio

Lo bonito de un código tan pequeño es que se puede entender entero y replicar su lógica con fidelidad. El programa en BASIC original hace, en esencia, esto:

• Pinta la carretera con dos líneas verticales y una línea central discontinua que se desplaza para dar sensación de avance:
• (`LINE`, `STEP 20`).

• El coche solo tiene dos posiciones X. El truco de cambiar de carril es maravillosamente simple:
• `CX = 252 - CX` (línea 1730).

• El burro aparece en un carril al azar: 
• `DX = 105 + 42*INT(RND*2)` (línea 1700).

• La colisión esta en la línea 1750 con IF que dispara el BOOM! y la animación de fragmentos volando a las esquinas en las líneas 2060-2200.
•  `IF CX=DX AND Y+25>=CY` (línea 1750) 

• Y el sonido, esos pitidos monofónicos del PC speaker, salen de las instrucciones `SOUND`.

Para esta prueba lo reescribí desde cero en HTML5 + CSS + JavaScript puro (Vanilla JS), sin frameworks ni motores de juego pesados, porque la gracia era mantener el espíritu minimalista del original:

• Gráficos: con la API de Canvas, respetando la resolución y la paleta CGA (negro, cian, magenta, blanco), pero con escalado nítido (`image-rendering: pixelated`) para que se vea bien en una pantalla 4K de hoy.

• Sonido: con la Web Audio API, generando ondas cuadradas para emular el PC speaker, un pitido corto al cambiar de carril y una ráfaga aleatoria de tonos para la explosión, calcada del `SOUND 37+RND*200,4`.

• Controles: barra espaciadora para cambiar de carril y Esc para salir, tal cual el original... y, ya puestos a modernizar, soporte táctil para jugar desde el móvil.

Comenté cada bloque del JavaScript indicando qué línea del BASIC original estaba replicando, porque me parecía la mejor forma de honrar el código de Gates y Konzen: no reinventarlo, sino traducirlo.

Figura 6: DONKEY.BAS migrado a Cloudflare Pages

con la estética CGA intacta.

El despliegue: de cero a producción con Cloudflare Pages en minutos

Y aquí es donde, como Account Executive en Cloudflare, no puedo evitar ponerme un poco pesado, porque es justo lo que me enamoró de esta plataforma. Tenía tres ficheros (`index.html`, `style.css`, `game.js`) y quería ponerlos en internet, con HTTPS, en una red global y sin montar ni un solo servidor. Pues bien:

```bash

wrangler login

wrangler pages deploy .

```

Figura 7: Desplegando con Wrangler

Y ya está. Literalmente. Wrangler (el CLI de Cloudflare) subió los ficheros, creó el proyecto y me devolvió una URL de producción servida desde más de 330 ciudades repartidas por el mundo. Sin aprovisionar máquinas, sin configurar un balanceador, sin pelearme con certificados TLS. El juego de Bill Gates de 1981 corriendo en la red perimetral más grande del planeta, gratis y en edge.

Figura 8: DONKEY.BAS  migrado corriendo en la nube de Cloudflare.

Dale al Play y juega.

Para quien prefiera no tocar la terminal, Cloudflare Pages también permite el despliegue por Direct Upload: arrastras la carpeta al panel y listo. O lo conectas a tu repositorio de Git y cada Push despliega solo, con Preview Deployments por cada rama para revisar cambios antes de pasarlos a producción.

¿Y qué tiene esto que ver con modernizar de verdad?

DONKEY.BAS es un juguete, claro. Pero la historia que cuenta es exactamente la misma que vivo con empresas que arrastran aplicaciones de hace veinte o treinta años: hay un core de lógica de negocio valioso atrapado en una tecnología que ya nadie quiere mantener, y el reto no es reescribirlo todo de golpe, sino modernizar la capa de entrega y de ejecución para llevarlo donde están hoy los usuarios.

Y ahí la propuesta de Cloudflare es potentísima, porque no se queda en servir ficheros estáticos:

• Cloudflare Workers: ejecuta tu lógica de backend en JavaScript, TypeScript, Python o Rust (vía WebAssembly) directamente en el edge, con arranques en frío de milisegundos. Olvídate de pensar en servidores o en regiones; tu código corre cerca del usuario, donde esté.

• Cloudlfare Pages + Functions: para frontends modernos con su API integrada, sin coser dos plataformas distintas.

• Almacenamiento y estado en el edge: Workers KV, D1 (SQL), R2 (objetos, sin tarifas de salida) y Durable Objects para coordinación y estado en tiempo real. Tu aplicación heredada puede ir migrando piezas a estos servicios sin un Big Bang.

• Seguridad de serie: WAF, mitigación de DDoS, *bot management* y Zero Trust delante de todo. Modernizar también es poner la seguridad por delante, no como un parche posterior.

• IA en el edge con Workers AI y AI Gateway: por si a ese DONKEY.BAS del futuro queréis ponerle un rival que conduzca solo con IA.

La clave es que puedes hacerlo incremental. Pones Cloudflare delante de tu aplicación actual, empiezas a mover funcionalidad a Workers poco a poco (el patrón strangler fig de toda la vida) y, sin pararlo todo, acabas con una arquitectura distribuida, segura y rápida. Igual que yo no reescribí la lógica de DONKEY.BAS, sino que la trasladé a una plataforma moderna.

Conclusión: cuarenta años después, el burro sigue cruzando

Me hace especial ilusión que un trozo de código de 1981, escrito por dos genios con un IBM PC y muchísimo ingenio, pueda estar hoy en producción en una red global sin tocar un servidor. Es la mejor metáfora que se me ocurre de para qué sirve todo esto: 

La tecnología cambia, pero las buenas ideas —y los buenos cores de negocio— merecen viajar bien.

Si tenéis una aplicación heredada que os da miedo tocar, hablemos. A lo mejor vuestro "DONKEY.BAS" particular está a un `wrangler pages deploy` de tener una segunda vida. Y si solo queréis jugar y esquivar burros como en 1981, también os entiendo perfectamente. Puedes jugar a DONKEY.BAS en Cloudflare aquí.

Que gane el mejor conductor.

Autor: Carlos Luengo,  Senior Account Executive en Cloudflare. 

Contactar con Carlos Luengo

Bug Hunting and Vibe-Exploiting en 86-DOS "High-performance operating system for the 8086" version 1.00 del 04/28/81

Hace un par de días, coincidiendo con el 45 aniversario de su creación, Tim Paterson ha puesto en GitHub el código fuente en abierto de varias versiones de nuestro querido DOS, para que los amantes del retro-computing puedan analizarlo, utilizarlo, mejorarlo, o construir cosas nuevas. Entre ellas está el código del 86-DOS "High-performance operating system for the 8086" version 1.00 del 04/28/81, una joya. Quiero agradecer a Tim Paterson que haya compartido esta maravilla de nuestra historia para poder estudiarlo, quererlo y seguir dándole continuidad.

Figura 1: Bug Hunting and Vibe-Exploiting en 86-DOS

"High-performance operating system for the 8086"

version 1.00 del 04/28/81

La gracia del mundo en que vivimos hoy en día, es que, gracias a la irrupción de la Inteligencia Artificial, se puede hacer Bug Hunting para encontrar bugs y explotarlos simplemente pidiéndole esto al modelo. De esto os hablé en el artículo de "Cómo usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source", que os invito a leer, así como compraros el libro de "Bug Hunter" (hoy lo tienes con descuento aún).

Figura 2:"Bug Hunter" escrito por David Padilla en 0xWord

Como oso podéis imaginar, como puro entretenimiento, y experimento, le pedí a Gemini Thinking que analizara el código de la versión 86-DOS publicada en GitHub, para ver qué vulnerabilities podía encontrar y de eso va este artículo de hoy.

Figura 3: Código fuente en ASM de 80-DOS_1.00

El resultado tras pasarle el código es que Gemini ha reportado 6 Bugs en el código Ensambalador (ASM) de esta versión 86-DOS, que os paso a dejar por aquí. Y mola mucho lo bien explicados que están cada uno de ellos.

Figura 4: Arbitrary Memory Overwrite

Además, como os conté en el artículo de "Cómo crear un exploit 1-day sobre un CVE de Chrome con Vibe Coding usando Claude Opus (no Mythos) y poner en jaque todas las apps en Electron" hoy en día es posible utilizar también a los modelos de IA para la fase de creación del exploit, así que le he pedido que me haga una PoC de cómo explotar cada uno de ellos. Así que le he pedido un poco de Vibe-Exploiting.

Figura 5: PoC de Exploit para el bug 1

Por supuesto, en esta versión de DOS no hay DEP, ASLR o Privilegios de CPU, que tienen los sistemas operativos Windows hoy en día - Máxima Seguridad en Windows lo explica perfectamente - pero es que aún faltaban muchos hackers haciendo exploits de Smashing the Stack, y por supuesto las vulnerabilidades como Spectre, Meltdown o GhostRace a bajo nivel.

Figura 6: Information Leakage en el nombre de un fichero a copiar

Explotar estas vulnerabilidades es bastante sencillo sin tener que conseguir evitar las protecciones de hoy en día, así que este Information Leakage se basa en poner nombres largos y ver qué datos de la memoria se consiguen, como vemos aquí.

Figura 7: Explotación del bug #2

En total, como os he dicho son seis, y cada uno de ellos es distinto, lo que hace aún más bonito este ejercicio teórico, ya que de todos ellos se aprende algo diferente.

Figura 8: Missing Directory Entry Validation

En este caso no nos ha hecho el exploit, porque lo que hay que hacer es una explotación modificando los bytes del disco a bajo nivel, con un editor hexadecimal sin pasar por las herramientas de gestión de ficheros el sistema operativo.

Figura 9: Explotación del bug #4

El siguiente es un ejemplo de cómo hay direcciones importantes del sistema operativo que pueden ser sobrescritas para tomar el control del flujo de ejecución del sistema operativo.

Figura 10: Lack of Interrupt Vector Protection

Esto es un fallo que permite a un malware tomar control de esas direcciones de memoria y ejecutar un software malicioso, como un rootkit que troyanice todo el sistema operativo. Esto es por lo que se crearon los sistemas de arranque seguros con los TPM (Trusted Platform Modules).

Figura 11: Explotación con secuestro de interrupcion

El penúltimo de los bugs reportados es la posibilidad de poder corromper el sistema de archivos FAT de un disco con un puntero a un cluster malicioso, como se explica en la imagen siguiente.

Figura 12: Fat Corruption via Malicious Cluster Pointer

Y para explotarlo, aquí tienes un ejemplo en forma de snippet de código para meter dentro de un programa que lo ejecute y corrompa la FAT.

Figura 13: Snippet de código para explotarlo

Y la última vulnerabilidad es un bug que permite una Denegación de Servicio (DoS) que puede crashear el sistema operativo y obligar al reinicio de la máquina.

Figura 14: Stack Exhaustion

El problema es la gestión de la pila (stack) del sistema y para meter un puntero a la base de la pila que genera una re-escritura de los registros y colapsa cuando intenta volver de la llamada, porque está sobre-escrita la dirección de retorno.

Figura 15: Exploit genera un bucle con la INT 21h

El uso de buscar vulnerabilidades con IA es algo de lo que ya os hablé en el libro de Hacking y Pentesting con Inteligencia Artificial, y por supuesto es parte fundamental del trabajo de Bug Hunter que David Padilla ha publicado.

Figura 16: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Los Chips Fotónicos de LightMatter revolucionan la industria de los Chips de Silicio

La informática ha ido evolucionado bajo el zumbido y el calor de los tubos de vacío del ENIAC - incluso la MANIAC de Von Neumann - el clic metálico de los relés de IBM, la revolución del transistor y la salvaje miniaturización de los chips CMOS. Cada salto iba comprimiendo la potencia poco a poco, primero era una habitación entera hasta finalmente caber en la palma de la mano. Pero hoy, estamos llevando al límite la Ley de Moore y exprimir cada nanómetro del silicio, volvemos a sentir que se acerca otro salto, uno grande y no, no hablamos de la computación cuántica (que ojo, llegará y que también tiene su versión fotónica cuántica pero eso es otro tema).

Figura 1: Los Chips Fotónicos de LightMatter revolucionan

la industria de los Chips de Silicio

Además, con el gran avance de la IA, las GPU de consumo superan los miles de euros (si la encuentras), y añadir transistores ya es casi tan caro como lanzar un satélite al espacio. Por cierto, si quieres conocer más sobre la evolución tecnológica, así como otras historias de hackers, te recomiendo nuestro libro MicroHistorias. Una fantástica lectura para este verano.

Figura 2: Libro de "Microhistorias: anécdotas y curiosiades de la historia
de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso 0xWord.

Pero volviendo al tema de hoy, en mitad de la revolución de la Inteligencia Artificial y la computación cuántica, entra en escena la computación fotónica, un relevo sorpresa que no utiliza electrones, sino haces de luz procesar. Lightmatter acaba construir el primer procesador fotónico que ejecuta modelos complejos de IA y con la misma fidelidad que una GPU de 32 bits. Y no es un prototipo con cables colgando en un laboratorio oscuro en un sótano, es hardware ya montado en rack, terminado, funcional, con varios chips fotónicos individuales y más de un millón de componentes ópticos, listo para enchufarse. 

Figura 3: Servidor con 8 procesadores fotónicos y dos Intel Xeon

Igual que el transistor envió al tubo de vacío al museo, los fotones pueden sacarnos del atasco actual. Puede que aún convivan con el silicio, como los motores eléctricos con los de combustión, pero el mensaje está claro: estamos delante del siguiente gran salto, el nuevo transistor.

¿Por qué es tan grande este salto?

Las barreras actuales de la microelectrónica no están en la lógica, sino en el tremendo coste que paga cada bit para moverse: la resistencia capacitancia de los interconectores y la energía que se evapora como calor al cambiar cargas a varios  GHz. A cada nueva capa litográfica, los transistores mejoran muy poco mientras las líneas de cobre apenas se hacen más pequeñas, y el coste energético por trasladar datos entre memoria y cómputo ya triplica al de la operación matemática en sí.

Figura 4: WDM

La computación fotónica se centra justo en ese cuello de botella: dentro de una guía de onda, los fotones viajan sin cargas que cargar o descargar y admiten multiplexación por longitud de onda (WDM) (algo así como varios “colores” circulando simultáneamente), lo que dispara el ancho de banda y baja la energía por bit a niveles de femto julios (una milbillonésima parte de un julio).

Dentro del Procesador de Lightmatter: Claves Técnicas y Potencial

En el núcleo de este chip hay seis procesadores apilados en 3D que integran 50.000 millones de transistores CMOS y un millón de componentes ópticos: los photonic tensor cores, arreglos de los moduladores Mach Zehnder que antes hemos mencionado, que ejecutan multiplicaciones analógicas a la velocidad de la luz y en decenas de longitudes de onda simultáneas gracias al WDM, mientras un control digital orquesta buffers, redes en chip y conversiones AD/DA.

Figura 5: Detalle de un Photonic Tesor Core

Para mantener la precisión de redes como ResNet 50, BERT o modelos de RL sin reentrenar, el sistema introduce el formato Adaptive Block Floating Point (ABFP), que comparte exponente por bloques y limita cada mantisa a 10–12 bits, complementado con ganancia analógica programable que amplifica la señal antes del muestreo y captura los bits más débiles sin aumantar el consumo del ADC (Analog to Digital Converter).

Figura 6: PCIe con el chip fotónico

Todo esto cabe en un paquete tipo PCIe que ofrece 65,5 TOPS con apenas 78 W eléctricos y 1,6 W ópticos (~0,85 pJ/op), se programa desde PyTorch o TensorFlow sin cambios de modelo (es decir, los actuales sirven) y, conectado mediante la interconexión fotónica Passage, escala a racks enteros donde la luz ya no solo mueve datos también los procesa, multiplicando el ancho de banda, recortando la latencia. Creo que, llegados a este punto, tenemos más claro que estamos entrando en una era post transistor.

Impacto y futuro de la tecnología

Pero pensemos por un momento lo siguiente. Estamos hablando de una tecnología que es básicamente un rayo de luz que se convierte en cálculos y una tarjeta PCIe que es el equivalente óptico de un pequeño datacenter. Los nuevos ingenieros/as de esta tecnología tendrán que jugar con rayos de luz multicolor, los desarrolladores/as crearán programas que se compilarán en ajustes de fases y longitudes de onda, y una nueva ciberseguridad (ojo a esto) decidirá cómo proteger un recurso que viaja literalmente a la velocidad de la luz.


Figura 7: Lightmatter InterConnect Launch Event at OFC 2025

Y este es el verdadero impacto: si hoy aprendemos a procesar información con un coste significativo, mañana podríamos equipar cada marcapasos, cada sensor IoT y cada IA local con inteligencia de alto nivel, sin el desperdicio brutal actual de los megavatios ni al silicio cada vez más caro y limitado. 

Este no es sólo el siguiente paso una la curva de rendimiento. Hablamos de imaginar aplicaciones que ya no dependen de los viejos límites térmicos, a diseñar soluciones que iluminen (nunca mejor dicho) las zonas oscuras aún no exploradas de la tecnología mientras esperamos la computación cuántica.

Happy Hacking Hackers!!! 

Autor: Fran Ramírez, es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox

"Daisy Bell" La canción que cantó una máquina: Del IBM 7094 a HAL 9000 (y a las DeepFakes de Voz hechas con IA)

Hoy os traigo una "microhistoria" peculiar que tiene que ver con la historia de la tecnología. Es una historia de esas que empieza con una sonrisa y termina con un escalofrío. Are you ready?  Vamos a remontarnos a un momento concreto, a un laboratorio concreto, y a una canción que, aunque suena muy inocente, esconde entre líneas un mensaje que (si lo escuchas con atención) te pone los pelos de punta...

Figura 1: "Daisy Bell" La canción que cantó una máquina.

Del IBM 7094 a HAL 9000 (y a las DeepFakes de Voz hechas con IA)

Un año: 1961. Un lugar: Bell Labs, New Jersey. Un protagonista: un ordenador llamado IBM 7094. Imagina un ordenador tan grande como una habitación, con bobinas magnéticas girando, luces parpadeando, y un grupo de ingenieros rodeándolo como si estuvieran a punto de traspasar una frontera.

Figura 2: Libro de "Microhistorias: anécdotas y curiosiades de la historia
de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso 0xWord.

No hay pantallas planas, ni interfaces gráficas, ni asistentes de voz. Solo código, cables, y un zumbido constante. En ese ambiente nació uno de los momentos más extraños y fascinantes de la historia de la informática.Es el IBM 7094, tan magnífico como lo puedes ver en la imagen siguiente en todo su esplendor. 

Figura 3: El IBM 7094, protagonista silencioso (pero afinado) de esta historia.

En el centro de esta escena, un grupo de genios —John Larry Kelly Jr. y Carol Lochbaum entre ellos— estaban experimentando con algo nuevo. Algo que hoy nos parece cotidiano, pero que en aquel entonces era pura ciencia ficción: hacer que una máquina hablara.

Figura 4: El corazón de Bell Labs. Ordenadores

y cerebros brillantes conspirando juntos.

Efectivamente, se trataba de los primeros experimentos de síntesis de voz... Pero no se conformaron con eso. Y es que el equipo contaba también con el compositor Max Mathews, del que hoy lunes se cuentan 21 años de su fallecimiento y lo queremos recordar hoy, como uno de los padres de la música por ordenador. 

La canción elegida:

“Daisy Bell (Bicycle Built for Two)”

Esta canción, compuesta en 1892 por Harry Dacre, se podría describir como inofensiva, pegadiza, incluso un poco cursi. Pero no la eligieron sólo por la palabra “Bell” en ambos nombres “BELL Labs”-“Daisy BELL”. En realidad fue porque había algo en su estructura melódica que la hacía ideal para el experimento: notas simples, frases cortas, ritmo regular. Perfecta para que una máquina diera sus primeros pasos en el mundo de la voz sintética.

Y entonces ocurrió.

En el siguiente vídeo podéis escuchar la canción como sonaba originalmente, y leer la letra. La imagen es la partitura original de “Daisy Bell” de Harry Dacre, 1892. 

Figura 5: Grabación más antigua conservada de la canción “Daisy Bell”, 1894.

El sonido es la grabación más antigua que se conserva, cantada por Edward M. Favor en 1894 para Edison Phonograph Company... ¡La grabación es de hace más de 130 años!

La primera vez que una máquina cantó

En 1961, el IBM 7094, programado por John Larry Kelly Jr. y Carol Lochbaum, y acompañado por otro ordenador con la instrumentación programada por Max Mathews, cantó. Cantó de verdad. No sólo emitió sonidos. Cantó una canción reconocible, con letra, con melodía, con esa voz robótica que tanto nos recuerda hoy a los primeros sintetizadores de los años 80... Pero que en aquel momento era completamente inaudita. Imagina estar allí y escuchar por primera vez a una máquina decir:

“Daisy, Daisy, give me your answer, do...”

Dicen que los presentes se quedaron en silencio. No sabían si aplaudir... O apagar el sistema y salir corriendo.

Figura 6: Daisy Bell cantada por el IBM 7094

En el vídeo anterior tenéis un fragmento original del IBM 7094 cantando "Daisy Bell", una rareza de museo digital. Si quieres, escúchalo con auriculares, a solas y con poca luz... 

Pero aquí no acaba la historia

Años después, un escritor británico llamado Arthur C. Clarke visitó en Bell Labs a su amigo, el ingeniero y escritor de ciencia ficción John R. Pierce. El equipo le mostró la demo: Clarke quedó tan impresionado que tomó nota mental. 

Figura 7: 2001: Una odisea del espacio"

Y cuando escribió su famosa novela "2001: Una odisea del espacio", incluyó la escena completa de aquella voz robótica entonando “Daisy Bell”.

Figura 8: Artur C. Clarke en uno de los sets de “2001: Una odisea en el espacio”.

Artur C. Clarke incluyó la experiencia tanto en la novela como en el guión cinematográfico, ambos de 1968, y la convirtió en una de las escenas más icónicas del cine: HAL 9000, el ordenador con inteligencia artificial, cantando Daisy Bell mientras lo desconectan. Un canto fúnebre. Una despedida. Un aviso.

Figura 9: HAL 9000 cantando Daisy Bell 

HAL 9000, el heredero emocional del IBM 7094. A veces las máquinas también cantan antes de morir. La ficción imita a la realidad... ¿O es al revés? Stanley Kubrick inmortalizó la escena en su película. HAL 9000, frío, lógico, brillante... Y de repente, profundamente humano en su última petición: cantar una canción de la infancia tecnológica. Un recordatorio de sus orígenes. Un último suspiro de algo que quizás, después de todo, no sabemos si estaba tan claro que no tuviera alma.

¿Por qué importa esto hoy?

Porque todo empezó aquí. La síntesis de voz, los asistentes virtuales, la música generada por IA, los Deepfakes de Audio... Todo tiene su semilla en ese IBM 7094 y esa canción del Siglo XIX. Cada vez que oigas a tu móvil decirte el tiempo, a tu coche darte direcciones, o a un sistema de IA componer una canción, recuerda: hubo un momento en que una máquina entonó "Daisy" por primera vez. Y el mundo nunca volvió a ser el mismo.

¿Quién soy?

Si has llegado hasta aquí y pensabas: “Este artículo tiene toda la pinta de estar escrito por Fran Ramírez”… Te tengo que confesar algo.

¡Pues no!

Otra vez os he liado con mi avatarmanía. Hoy he intentado imitar el estilo único de Fran (desde el cariño, namasté, reverencia). Soy María. Se me ocurrió contaros esta historia tan alucinante de forma que os sonara familiar =^_^= Espero que te haya gustado, y que la próxima vez que escuches a una máquina cantar… Pienses en Daisy Bell. ¿Nos vemos en el chat de El lado del mal, en MyPublicInbox? Pues hala, ya sabes dónde encontrarme. 

Un abrazo :)

Autor: María Gómez Prieto

Contactar con María Gómez Prieto