Nell’informatica gira una battuta ricorrente: prima o poi DOOM girerà su qualunque cosa. Non come elogio del gioco, ma come sfida. Lo sparatutto del 1993 è già stato fatto funzionare su bancomat, stampanti, test di gravidanza, calcolatrici, un singolo mattoncino LEGO e la Touch Bar di un MacBook.
Nel gennaio 2025 uno studente delle superiori ha aggiunto una voce all’elenco. Ha fatto girare DOOM dentro un file PDF.
In breve
Uno studente delle superiori ha compilato DOOM in asm.js con una versione di Emscripten del 2020 e l’ha eseguito dentro un PDF, usando un campo modulo per ogni riga dello schermo: 320×200, sei toni di grigio, circa 80 millisecondi per fotogramma. Non è stata sfruttata alcuna vulnerabilità. Ogni funzione impiegata è una parte documentata della specifica PDF, che fa esattamente ciò per cui è stata pensata. È questo il punto interessante — e il motivo per dedicare dieci minuti, una volta, ai propri documenti.
È un lavoro splendido e una battuta riuscitissima. È anche la dimostrazione più chiara di una cosa che questo sito ripete da tempo e che è del tutto ragionevole faticare a credere: un PDF non è la fotografia di una pagina. È un contenitore capace di eseguire codice.
Come funziona davvero
Il progetto si chiama doompdf, firmato da uno sviluppatore che si fa chiamare ading2210. Il meccanismo è più interessante dell’impresa, e si compone di quattro parti.
Il PDF supporta JavaScript. Non come estensione né come plugin: fa parte del formato, ha una propria libreria standard e i browser lo implementano nei motori PDF integrati. Esiste perché i moduli possano validare ciò che scrivete e i documenti interattivi rispondano ai clic. Nessuno l’ha aggiunto pensando ai videogiochi.
Il codice sorgente di DOOM è pubblico — anche se la storia è più precisa di quanto la scorciatoia lasci intendere. id Software pubblicò il codice il 23 dicembre 1997, ma con una licenza che ne consentiva il solo uso didattico, ed era il codice della conversione per Linux, non dell’originale DOS, per via della licenza separata della libreria audio DMX. Il passaggio alla GPL arrivò quasi due anni dopo, il 3 ottobre 1999. È questa seconda data a contare: trasformò DOOM da qualcosa che si poteva leggere in qualcosa che si poteva legalmente ricostruire. Ecco perché il gioco continua a spuntare nei posti più improbabili.
A unire i due mondi è stato un compilatore volutamente obsoleto. ading2210 ha usato Emscripten 1.39.20 — una versione del 2020 — perché produce asm.js anziché WebAssembly. L’Emscripten moderno genera WebAssembly, e un PDF non ha un ambiente di esecuzione per WebAssembly. asm.js è un dialetto ristretto del normale JavaScript, quindi gira ovunque giri JavaScript. Ricorrere alla vecchia catena di strumenti non è stata nostalgia: era l’unica via d’ingresso.
Resta la visualizzazione, la parte che fa scoppiare a ridere. Un PDF non ha una tela, non ha un framebuffer, non ha niente su cui disegnare pixel. Ha però i campi modulo. Così l’uscita 320×200 del gioco viene resa con caratteri ASCII — un campo di testo per ogni riga dello schermo, in sei toni di grigio — e aggiornata alla velocità con cui quel testo può essere riscritto, cioè all’incirca 80 millisecondi per fotogramma. Anche i comandi passano di lì: campi e pulsanti che il motore PDF sa già gestire. Si gioca a DOOM, letteralmente, dentro un modulo da compilare.
È lento. È monocromatico. È perfettamente giocabile, è distribuito sotto GPL v2 come il codice da cui deriva, e si può provare in un browser basato su Chromium. La versione compilata permette perfino di inserire un proprio file WAD.
Poi ci ha avviato Linux
Qualche settimana dopo, lo stesso sviluppatore ha pubblicato linuxpdf: un kernel Linux completo che si avvia dentro un file PDF, compilando l’emulatore RISC-V TinyEMU con lo stesso trucco di asm.js. Il kernel impiega dai 30 ai 60 secondi ad avviarsi — l’autore lo quantifica in oltre cento volte più lento dell’hardware reale — e si comanda con una tastiera virtuale costruita con pulsanti PDF.
DOOM in un documento è una battuta. Una CPU emulata che avvia un sistema operativo dentro un documento è un argomento. Da qualche parte, tra i due, il discorso smette di riguardare DOOM.
La parte che non fa ridere
Ecco il pensiero su cui vale la pena fermarsi. Niente in doompdf è un exploit. Non è stata trovata alcuna vulnerabilità, non è stato forzato nulla, non è coinvolta alcuna falla di sicurezza. Ogni singolo elemento che utilizza è una funzione documentata e voluta della specifica PDF, che lavora esattamente come progettato.
Il che significa che la capacità che permette a un PDF di eseguire uno sparatutto del 1993 è presente anche nella fattura che aprirete domani. Non è in agguato, non è nascosta: è semplicemente lì, inutilizzata, perché la maggior parte dei documenti non ha motivo di servirsene.
Questa è la versione onesta della storia, e taglia da entrambi i lati. Lo stesso ragionamento che dice «un documento può eseguire codice, quindi attenzione» deve anche ammettere quanto sia angusto il mondo in cui quel codice si muove.
Che cosa può e che cosa non può fare uno script dentro un PDF
È qui che gran parte degli articoli su doompdf si fa vaga, quindi conviene essere precisi. La risposta dipende interamente da con che cosa avete aperto il file, e i due casi comuni sono molto diversi.
| Capacità | Visualizzatore del browser (Chrome, Edge, Firefox) | Adobe Acrobat Reader |
|---|---|---|
| Eseguire script all’apertura | Sì | Sì, se non disattivato |
| Leggere e scrivere i campi modulo | Sì | Sì |
| Leggere cookie o archiviazione del browser | No | Non applicabile |
| Raggiungere la pagina HTML circostante (il DOM) | No | Non applicabile |
| Effettuare richieste di rete | Molto limitato | Più ampio — è qui che sono vissuti i pixel di tracciamento e le fughe NTLM |
| Toccare file locali | No | Limitato, ma con una superficie di API assai maggiore |
| Avviare programmi esterni o allegati | No | Previa conferma — storicamente la via dei documenti malevoli |
Leggete la tabella nel verso giusto. Nel browser un PDF con script gira in una scatoletta piccola e noiosa: niente cookie, niente archiviazione, nessun accesso alla pagina intorno. È proprio per questo che doompdf è una curiosità e non un incidente, e che «DOOM gira in un PDF» non è una ragione per temere i PDF.
La colonna interessante è quella del lettore desktop. Dispone dell’intera API JavaScript descritta dalla specifica, perché è pensato per documenti aziendali veri. È l’ambiente in cui a un documento si può chiedere di farsi vivo nel momento in cui viene aperto, di comportarsi diversamente a seconda del lettore, o di proporre l’apertura di qualcosa che si portava dietro.
Tre cose, quindi, restano vere con qualunque programma, e sono quelle da interiorizzare.
- Un PDF può contenere istruzioni eseguite nel momento dell’apertura, prima che abbiate letto alcunché.
- Un PDF può comportarsi diversamente a seconda del software che lo apre: il file che vedete non è necessariamente quello che vede il vostro collega.
- Un PDF porta con sé più di quanto mostri: allegati, livelli nascosti, cronologia delle revisioni e metadati che non intendevate inviare.
Niente di tutto ciò rende i PDF pericolosi nel senso quotidiano. Ne aprirete decine questo mese e andrà bene ogni volta. Significa però che il modello mentale che quasi tutti portiamo con noi — «è solo un documento» — è sbagliato in un modo che ogni tanto conta.
L’impostazione che quasi nessuno conosce
Il consiglio classico è «disattiva JavaScript nel lettore PDF», ed è un buon consiglio. Da solo, però, è incompleto: la maggior parte delle persone non apre più i PDF in un lettore PDF. Li apre in una scheda del browser, e il browser ha un interruttore proprio, separato.
Firefox arriva con lo scripting nei PDF attivo. La preferenza si chiama pdfjs.enableScripting in about:config; è stata false fino a Firefox 87 ed è true da Firefox 88. L’interruttore generale javascript.enabled non la tocca: il visualizzatore PDF è un mondo a parte con un’impostazione a parte.
Chrome ed Edge non espongono alcun interruttore dedicato allo scripting nei PDF. Lo script di un PDF ricade sotto l’autorizzazione JavaScript del sito da cui proviene il file, disattivabile per singolo sito dai controlli nella barra degli indirizzi o globalmente in chrome://settings/content/javascript — uno strumento decisamente più grossolano.
Adobe Acrobat Reader ha l’interruttore a cui tutti pensano: Preferenze → JavaScript → Attiva JavaScript di Acrobat. È quello che conviene togliere, perché Acrobat è il lettore con l’API grande e quasi nessuno usa consapevolmente un PDF con script nel lavoro ordinario.
In pratica: disattivarlo in Acrobat e lasciare in pace il browser è una scelta ragionevole e proporzionata. Credere di averlo disattivato ovunque, quando lo si è fatto solo in Acrobat, non lo è.
Che cosa farsene di questa informazione
La risposta pratica è piccola e vale quei dieci minuti.
Disattivate JavaScript nel lettore desktop. In Acrobat Reader: Preferenze → JavaScript. Rimuove un’intera categoria di rischio e non costa nulla, tranne — va ammesso — la possibilità di giocare a DOOM in un campo modulo.
Tenete aggiornato il lettore. Lo scripting è una via d’ingresso. I difetti nel codice che decodifica caratteri e immagini sono un’altra, e sono quelli che gli aggiornamenti correggono — storicamente, per giunta, la via più battuta.
Trattate i documenti inattesi come inattesi. Una fattura da un’azienda da cui non avete mai comprato nulla merita un attimo di riflessione, in qualunque formato arrivi. Vale più di qualsiasi impostazione.
Notate che cosa hanno in comune i tre punti: nessuno chiede di rinunciare ai PDF o di diffidare dei documenti in generale. Equivalgono a chiudere a chiave la porta di casa: economico, noioso e sensato proprio perché il rischio è piccolo ma non nullo.
Perché questo progetto merita l’attenzione che ha ricevuto
Sarebbe facile archiviare doompdf sotto «curiosità di internet» e passare oltre. Sostengo che sia più utile di così, per una ragione che non ha nulla a che vedere con il teatrino della sicurezza.
La comprensione che quasi tutti hanno dei formati di file poggia interamente sull’uso che se ne fa. I documenti servono a leggere. I fogli di calcolo, ai numeri. Le immagini, a essere guardate. Quel modello funziona quasi sempre, ed è esattamente per questo che è così difficile da scalzare — e perché spiegare che «un PDF può contenere contenuto attivo» incontra di solito uno scetticismo cortese.
Un gioco funzionante dentro un documento fa in dieci secondi ciò che a un articolo costa mille parole. Sostituisce un’affermazione astratta con qualcosa su cui si può cliccare.
E il punto di fondo va ben oltre i PDF. I formati accumulano funzioni per decenni. Ogni aggiunta aveva senso per qualcuno che risolveva un problema reale: la validazione dei moduli è davvero utile, e lo è anche un documento capace di verificare i propri conti. Il risultato è che le cose ordinarie che ci scambiamo ogni giorno sanno fare molto più di quanto il loro nome suggerisca. E una capacità, una volta entrata in una specifica, è a disposizione di chiunque legga quella specifica.
Che cosa resta per l’uso quotidiano
Niente di tutto questo è un argomento contro il PDF. Resta il formato migliore per inviare un documento che appaia identico ovunque, su qualunque macchina, anche fra anni. È un problema davvero difficile, e il PDF l’ha risolto. Le funzioni che rendono possibile doompdf sono le stesse che rendono possibile un modulo fiscale compilabile.
È un argomento a favore del sapere che cosa si sta maneggiando. La stessa versatilità che consente a un documento di trasportare un gioco gli consente di trasportare script, allegati, livelli nascosti e metadati che non pensavate di inviare. Vale la pena capirli, e nessuno di essi è motivo di allarme.
È anche parte del motivo per cui PDF Manipulator funziona interamente sul vostro computer. Quando unite, dividete o convertite file, meno parti sono coinvolte meglio è — non perché i servizi online siano loschi, ma perché un documento che non ha mai lasciato la vostra macchina è molto più semplice da valutare di uno che è passato dal server di qualcun altro.
Lavora sui tuoi PDF completamente offline — PDF Manipulator è gratuito →
Fonti
- ading2210, doompdf su GitHub — codice sorgente e descrizione tecnica; Emscripten 1.39.20, uscita 320×200 in sei toni, ~80 ms per fotogramma, GPL v2
- ading2210, linuxpdf su GitHub — Linux su un emulatore RISC-V TinyEMU dentro un PDF, avvio in 30–60 secondi
- Versione giocabile (browser basati su Chromium)
- Eric Lawrence, Browser Security Bugs that Aren’t: JavaScript in PDF — che cosa i motori PDF dei browser consentono e che cosa no
- Adobe, Restrict JavaScript API access in Acrobat
- DoomWiki, Licences — pubblicazione del codice il 23 dicembre 1997, passaggio alla GPL il 3 ottobre 1999
- The Register, It’s Doom … running in a PDF file
- Ars Technica, This PDF contains a playable copy of Doom
