En informática circula la broma de que DOOM acabará ejecutándose en todo. No como elogio al juego, sino como desafío: al shooter de 1993 ya lo han hecho funcionar en cajeros automáticos, impresoras, tests de embarazo, calculadoras, una sola pieza de LEGO y la Touch Bar de un MacBook.
En enero de 2025 un estudiante de secundaria añadió uno más a la lista. Consiguió que DOOM funcionara dentro de un archivo PDF.
La versión corta
Un estudiante de secundaria compiló DOOM a asm.js con una versión de Emscripten de 2020 y lo ejecutó dentro de un PDF usando un campo de formulario por cada fila de la pantalla: 320×200, seis tonos de gris, unos 80 milisegundos por fotograma. No intervino ninguna vulnerabilidad. Cada función que utiliza está documentada en la especificación del PDF y hace exactamente lo previsto. Eso es lo interesante — y el motivo para dedicar diez minutos, una vez, a los documentos.
Es un trabajo magnífico y una broma excelente. Es también la demostración más clara de algo que este sitio repite y que a la gente le cuesta creer con toda razón: un PDF no es la fotografía de una página. Es un contenedor capaz de ejecutar código.
Cómo funciona en realidad
El proyecto se llama doompdf y lo firma un desarrollador conocido como ading2210. El mecanismo es más interesante que la proeza, y tiene cuatro partes.
El PDF admite JavaScript. No como complemento ni como plugin: forma parte del formato, con su propia biblioteca estándar, y los navegadores lo implementan en sus motores de PDF integrados. Existe para que los formularios validen lo que se escribe y los documentos interactivos respondan a los clics. Nadie lo añadió pensando en videojuegos.
El código fuente de DOOM es público, aunque la historia es más precisa de lo que sugiere el resumen. id Software publicó el código el 23 de diciembre de 1997, pero bajo una licencia que solo permitía usos educativos, y era el código del port a Linux, no el original de DOS, por la licencia independiente de la biblioteca de sonido DMX. El cambio a la GPL llegó casi dos años después, el 3 de octubre de 1999. Esa segunda fecha es la que importa: convirtió DOOM en algo que no solo se podía leer, sino reconstruir legalmente. Por eso el juego sigue apareciendo en lugares improbables.
Ambos mundos los unió un compilador deliberadamente obsoleto. ading2210 usó Emscripten 1.39.20 — una versión de 2020 — porque genera asm.js en lugar de WebAssembly. El Emscripten actual produce WebAssembly, y un PDF no tiene entorno de ejecución para WebAssembly. asm.js es un dialecto restringido de JavaScript corriente, así que funciona allí donde funcione JavaScript. Recurrir a la cadena de herramientas antigua no fue nostalgia: era la única entrada.
Queda la pantalla, la parte que hace reír a carcajadas. Un PDF no tiene lienzo, ni framebuffer, ni nada sobre lo que pintar píxeles. Lo que sí tiene son campos de formulario. Así que la salida de 320×200 del juego se representa con caracteres ASCII — un campo de texto por cada fila de la pantalla, en seis tonos de gris — y se refresca tan rápido como pueda reescribirse ese texto, lo que da unos 80 milisegundos por fotograma. La entrada llega por el mismo camino: campos y botones que el motor de PDF ya sabe manejar. Se juega a DOOM, literalmente, dentro de un formulario rellenable.
Va lento. Es monocromo. Es plenamente jugable, se publica bajo la GPL v2 igual que el código en el que se basa, y se puede probar en un navegador basado en Chromium. La compilación incluso permite cargar tu propio archivo WAD.
Luego arrancó Linux dentro de uno
Pocas semanas después el mismo desarrollador publicó linuxpdf: un núcleo de Linux completo arrancando dentro de un PDF, compilando el emulador RISC-V TinyEMU con el mismo truco de asm.js. El núcleo tarda entre 30 y 60 segundos en arrancar — el autor lo cifra en más de cien veces más lento que el hardware real — y se maneja con un teclado virtual hecho de botones de PDF.
DOOM en un documento es una broma. Una CPU emulada arrancando un sistema operativo dentro de un documento es un argumento. En algún punto entre ambos, la cosa deja de ir sobre DOOM.
La parte que no tiene gracia
Aquí está la idea que merece un momento de reposo. Nada en doompdf es un exploit. No se encontró ninguna vulnerabilidad, no se rompió nada, no intervino ningún agujero de seguridad. Todo lo que utiliza es una función documentada e intencionada de la especificación del PDF, trabajando exactamente como se diseñó.
Lo que significa que la capacidad que permite a un PDF ejecutar un shooter de 1993 está también en la factura que abrirás mañana. No acecha, no está escondida: simplemente está ahí, sin usar, porque la mayoría de los documentos no tienen motivo para usarla.
Esa es la versión honesta de la historia, y corta por los dos lados. El mismo razonamiento que dice «un documento puede ejecutar código, así que cuidado» también tiene que admitir lo estrecho que es el mundo de ese código.
Qué puede y qué no puede hacer un script dentro de un PDF
Aquí es donde la mayoría de las coberturas de doompdf se vuelven vagas, así que conviene ser concreto. La respuesta depende por completo de con qué has abierto el archivo, y los dos casos habituales son muy distintos.
| Capacidad | Visor del navegador (Chrome, Edge, Firefox) | Adobe Acrobat Reader |
|---|---|---|
| Ejecutar script al abrir | Sí | Sí, salvo que se desactive |
| Leer y escribir campos de formulario | Sí | Sí |
| Leer cookies o almacenamiento del navegador | No | No aplica |
| Acceder a la página HTML que lo rodea (el DOM) | No | No aplica |
| Hacer peticiones de red | Muy limitado | Más amplio — ahí han vivido los píxeles de rastreo y las fugas de NTLM |
| Tocar archivos locales | No | Restringido, pero con una API mucho mayor |
| Lanzar programas externos o adjuntos | No | Con confirmación — históricamente, la vía de los documentos maliciosos |
Lee la tabla en el sentido correcto. En el navegador, un PDF con scripts se ejecuta en una caja pequeña y aburrida: sin cookies, sin almacenamiento, sin acceso a la página que lo rodea. Precisamente por eso doompdf es una curiosidad y no un incidente, y por eso «DOOM funciona en un PDF» no es razón para tener miedo a los PDF.
La columna interesante es la del lector de escritorio. Tiene la API de JavaScript completa que describe la especificación, porque está pensado para documentos de empresa reales. Ese es el entorno en el que a un documento se le puede pedir que avise a alguien nada más abrirse, que se comporte distinto según el lector, o que proponga abrir algo que traía consigo.
Así que tres cosas siguen siendo ciertas con cualquier programa, y conviene interiorizarlas.
- Un PDF puede llevar instrucciones que se ejecutan en el momento de abrirlo, antes de que hayas leído nada.
- Un PDF puede comportarse de forma distinta según el programa que lo abra: el archivo que ves no es necesariamente el que ve tu compañero.
- Un PDF lleva más de lo que muestra: adjuntos, capas ocultas, historial de revisiones y metadatos que nunca quisiste enviar.
Nada de esto hace peligrosos a los PDF en el sentido cotidiano. Abrirás decenas este mes y todos irán bien. Sí significa que el modelo mental que casi todos llevamos — «es solo un documento» — es erróneo de una manera que a veces importa.
El ajuste que casi nadie conoce
El consejo estándar es «desactiva JavaScript en tu lector de PDF», y es buen consejo. También es, por sí solo, incompleto: la mayoría de la gente ya no abre los PDF en un lector de PDF. Los abre en una pestaña del navegador, y el navegador tiene su propio interruptor, separado.
Firefox viene con el scripting de PDF activado. La preferencia es pdfjs.enableScripting en about:config; estuvo en false hasta Firefox 87 y pasó a true desde Firefox 88. El interruptor general javascript.enabled no la afecta: el visor de PDF es un mundo aparte con un ajuste aparte.
Chrome y Edge no ofrecen ningún interruptor específico para el scripting en PDF. El script de un PDF se rige por el permiso de JavaScript del sitio del que procede el archivo, que puedes desactivar por sitio desde los controles de la barra de direcciones, o globalmente en chrome://settings/content/javascript, una herramienta bastante más burda.
Adobe Acrobat Reader tiene el interruptor al que todo el mundo se refiere: Preferencias → JavaScript → Activar JavaScript de Acrobat. Ese es el que conviene desmarcar, porque Acrobat es el lector con la API grande y casi nadie usa a sabiendas un PDF con scripts en el trabajo normal.
En la práctica: desactivarlo en Acrobat y dejar el navegador en paz es una decisión razonable y proporcionada. Creer que lo has desactivado en todas partes cuando solo lo hiciste en Acrobat, no.
Qué hacer con esta información
La respuesta práctica es pequeña y vale esos diez minutos.
Desactiva JavaScript en tu lector de escritorio. En Acrobat Reader, Preferencias → JavaScript. Elimina toda una categoría de riesgo y no cuesta nada salvo, hay que reconocerlo, la posibilidad de jugar a DOOM en un campo de formulario.
Mantén el lector actualizado. El scripting es una vía de entrada. Los fallos en el código que decodifica fuentes e imágenes son otra, y esos los arreglan las actualizaciones; históricamente, además, son la vía más frecuente.
Trata los documentos inesperados como inesperados. Una factura de una empresa a la que nunca has comprado nada merece un segundo de reflexión, llegue en el formato que llegue. Esto vale más que cualquier ajuste.
Fíjate en lo que comparten los tres: ninguno exige dejar de usar PDF ni desconfiar de los documentos en general. Equivalen a cerrar la puerta con llave: barato, aburrido y sensato precisamente porque el riesgo es pequeño pero no nulo.
Por qué este proyecto merece la atención que recibió
Sería fácil archivar doompdf en «curiosidad de internet» y seguir adelante. Sostengo que es más útil que eso, por un motivo que nada tiene que ver con el teatro de la seguridad.
La comprensión que la mayoría tiene de los formatos de archivo se construye enteramente sobre para qué se usan. Los documentos son para leer. Las hojas de cálculo, para números. Las imágenes, para mirar. Ese modelo funciona casi siempre, y por eso cuesta tanto moverlo — y por eso explicar que «un PDF puede contener contenido activo» suele recibirse con escepticismo cortés.
Un juego jugable dentro de un documento hace en diez segundos lo que a un artículo le cuesta mil palabras. Sustituye una afirmación abstracta por algo en lo que puedes hacer clic.
Y la idea de fondo va mucho más allá del PDF. Los formatos acumulan funciones durante décadas. Cada añadido tuvo sentido para alguien que resolvía un problema real: validar un formulario es genuinamente útil, y también lo es un documento capaz de comprobar sus propias cuentas. El resultado es que las cosas corrientes que intercambiamos a diario pueden bastante más de lo que sugiere su nombre. Y una capacidad, una vez que está en una especificación, queda disponible para cualquiera que lea esa especificación.
Qué queda de todo esto para el día a día
Nada de lo anterior es un argumento contra el PDF. Sigue siendo el mejor formato para enviar un documento que se vea igual en todas partes, en cualquier máquina, dentro de años. Es un problema genuinamente difícil y el PDF lo resolvió. Las funciones que hacen posible doompdf son las mismas que hacen posible un formulario fiscal rellenable.
Es un argumento a favor de saber con qué se trabaja. La misma versatilidad que permite a un documento llevar un juego le permite llevar scripts, adjuntos, capas ocultas y metadatos que nunca pensaste enviar. Conviene entenderlos, y ninguno es motivo de alarma.
Es también parte de por qué PDF Manipulator funciona por completo en tu propio ordenador. Al unir, dividir o convertir archivos, cuantas menos partes intervengan, mejor — no porque los servicios en línea sean siniestros, sino porque un documento que nunca salió de tu máquina es mucho más fácil de razonar que uno que ha estado en el servidor de otro.
Trabaja con tus PDF completamente sin conexión — PDF Manipulator es gratuito →
Fuentes
- ading2210, doompdf en GitHub — código fuente y descripción técnica; Emscripten 1.39.20, salida 320×200 en seis tonos, ~80 ms por fotograma, GPL v2
- ading2210, linuxpdf en GitHub — Linux sobre un emulador RISC-V TinyEMU dentro de un PDF, arranque de 30–60 segundos
- Versión jugable (navegadores basados en Chromium)
- Eric Lawrence, Browser Security Bugs that Aren’t: JavaScript in PDF — qué permiten y qué no los motores de PDF de los navegadores
- Adobe, Restrict JavaScript API access in Acrobat
- DoomWiki, Licences — publicación del código el 23 de diciembre de 1997, cambio a GPL el 3 de octubre de 1999
- The Register, It’s Doom … running in a PDF file
- Ars Technica, This PDF contains a playable copy of Doom
