Na informática circula a piada de que o DOOM acabará por correr em tudo. Não como elogio ao jogo, mas como desafio: já puseram o shooter de 1993 a funcionar em caixas multibanco, impressoras, testes de gravidez, calculadoras, uma única peça de LEGO e na Touch Bar de um MacBook.
Em janeiro de 2025 um aluno do secundário acrescentou mais um item à lista. Pôs o DOOM a correr dentro de um ficheiro PDF.
Versão curta
Um aluno do secundário compilou o DOOM para asm.js com uma versão do Emscripten de 2020 e pô-lo a correr dentro de um PDF, usando um campo de formulário por cada linha do ecrã: 320×200, seis tons de cinzento, cerca de 80 milissegundos por fotograma. Não houve qualquer vulnerabilidade envolvida. Todas as funcionalidades usadas estão documentadas na especificação do PDF e fazem exatamente aquilo para que foram pensadas. É esse o ponto interessante — e a razão para dedicar dez minutos, uma vez, aos seus documentos.
É um trabalho magnífico e uma piada excelente. É também a demonstração mais clara de algo que este site repete e que é razoável custar a acreditar: um PDF não é a fotografia de uma página. É um recipiente capaz de executar código.
Como funciona na verdade
O projeto chama-se doompdf, de um programador que assina ading2210. O mecanismo é mais interessante do que a proeza e tem quatro partes.
O PDF suporta JavaScript. Não como extensão nem como plugin: faz parte do formato, tem biblioteca-padrão própria e os navegadores implementam-no nos motores de PDF integrados. Existe para que os formulários validem o que se escreve e os documentos interativos respondam a cliques. Ninguém o acrescentou a pensar em jogos.
O código-fonte do DOOM é público — embora a história seja mais precisa do que o atalho sugere. A id Software publicou o código a 23 de dezembro de 1997, mas sob uma licença que só permitia uso educativo, e tratava-se do código da conversão para Linux, não do original para DOS, por causa da licença separada da biblioteca de som DMX. A passagem para a GPL só chegou quase dois anos depois, a 3 de outubro de 1999. É esta segunda data que conta: transformou o DOOM em algo que não só se podia ler, como reconstruir legalmente. Daí o jogo continuar a aparecer em sítios improváveis.
A ponte entre os dois foi feita por um compilador deliberadamente obsoleto. ading2210 usou o Emscripten 1.39.20 — uma versão de 2020 — porque gera asm.js em vez de WebAssembly. O Emscripten atual produz WebAssembly, e um PDF não tem ambiente de execução para WebAssembly. O asm.js é um dialeto restrito do JavaScript comum, portanto corre em todo o lado onde corra JavaScript. Recorrer à cadeia de ferramentas antiga não foi nostalgia: era a única porta de entrada.
Falta o ecrã, a parte que faz rir alto. Um PDF não tem tela, não tem framebuffer, não tem nada onde pintar píxeis. O que tem são campos de formulário. Por isso a saída 320×200 do jogo é desenhada com caracteres ASCII — um campo de texto por cada linha do ecrã, em seis tons de cinzento — e atualizada tão depressa quanto esse texto puder ser reescrito, o que dá cerca de 80 milissegundos por fotograma. Os comandos entram pelo mesmo caminho: campos e botões que o motor de PDF já sabe tratar. Joga-se DOOM, literalmente, dentro de um formulário preenchível.
Corre devagar. É monocromático. É perfeitamente jogável, é distribuído sob GPL v2 tal como o código de que deriva, e pode experimentar-se num navegador baseado em Chromium. A compilação permite até inserir o seu próprio ficheiro WAD.
Depois pôs Linux a arrancar dentro de um
Poucas semanas mais tarde o mesmo programador publicou o linuxpdf: um núcleo Linux completo a arrancar dentro de um ficheiro PDF, compilando o emulador RISC-V TinyEMU com o mesmo truque do asm.js. O núcleo demora 30 a 60 segundos a arrancar — o autor calcula mais de cem vezes mais lento do que hardware real — e controla-se com um teclado virtual feito de botões de PDF.
DOOM num documento é uma piada. Um processador emulado a arrancar um sistema operativo dentro de um documento é um argumento. Algures entre os dois, a conversa deixa de ser sobre o DOOM.
A parte que não tem graça
Eis a ideia que merece uma pausa. Nada no doompdf é um exploit. Não foi encontrada qualquer vulnerabilidade, nada foi quebrado, não houve falha de segurança envolvida. Cada elemento que usa é uma funcionalidade documentada e intencional da especificação do PDF, a trabalhar exatamente como foi desenhada.
O que significa que a capacidade que permite a um PDF executar um shooter de 1993 também está na fatura que vai abrir amanhã. Não está à espreita nem escondida: está simplesmente lá, sem uso, porque a maioria dos documentos não tem motivo para a usar.
Esta é a versão honesta da história, e corta para os dois lados. O mesmo raciocínio que diz «um documento pode executar código, portanto atenção» também tem de admitir quão estreito é o mundo desse código.
O que um script dentro de um PDF pode e não pode fazer
É aqui que a maioria dos artigos sobre o doompdf se torna vaga, por isso vale a pena ser concreto. A resposta depende inteiramente de com que abriu o ficheiro — e os dois casos comuns são muito diferentes.
| Capacidade | Visualizador do navegador (Chrome, Edge, Firefox) | Adobe Acrobat Reader |
|---|---|---|
| Executar script ao abrir | Sim | Sim, salvo se desativado |
| Ler e escrever campos de formulário | Sim | Sim |
| Ler cookies ou armazenamento do navegador | Não | Não aplicável |
| Chegar à página HTML em redor (o DOM) | Não | Não aplicável |
| Fazer pedidos de rede | Muito limitado | Mais amplo — foi aqui que viveram os píxeis de rastreio e as fugas de NTLM |
| Tocar em ficheiros locais | Não | Restrito, mas com uma API bem maior |
| Lançar programas externos ou anexos | Não | Mediante confirmação — historicamente a via dos documentos maliciosos |
Leia a tabela no sentido certo. No navegador, um PDF com scripts corre numa caixa pequena e aborrecida: sem cookies, sem armazenamento, sem acesso à página em redor. É precisamente por isso que o doompdf é uma curiosidade e não um incidente, e que «o DOOM corre num PDF» não é razão para ter medo de PDF.
A coluna interessante é a do leitor de secretária. Tem a API JavaScript completa descrita na especificação, porque foi feito para documentos empresariais a sério. É o ambiente onde se pode dizer a um documento para dar sinal de si assim que é aberto, comportar-se de forma diferente conforme o leitor, ou pedir para abrir algo que trazia consigo.
Três coisas continuam, então, verdadeiras seja qual for o programa, e são essas que vale a pena interiorizar.
- Um PDF pode transportar instruções executadas no momento em que o abre, antes de ter lido o que quer que seja.
- Um PDF pode comportar-se de forma diferente consoante o software que o abre: o ficheiro que vê não é necessariamente o que o seu colega vê.
- Um PDF transporta mais do que mostra: anexos, camadas ocultas, histórico de revisões e metadados que nunca quis enviar.
Nada disto torna os PDF perigosos no sentido do dia a dia. Vai abrir dezenas este mês e correrá tudo bem. Significa, porém, que o modelo mental que quase todos carregamos — «é só um documento» — está errado de uma forma que às vezes conta.
A definição que quase ninguém conhece
O conselho habitual é «desative o JavaScript no leitor de PDF», e é bom conselho. Por si só, no entanto, é incompleto: a maioria das pessoas já não abre PDF num leitor de PDF. Abre-os num separador do navegador, e o navegador tem o seu próprio interruptor, separado.
O Firefox vem com o scripting em PDF ligado. A preferência chama-se pdfjs.enableScripting, em about:config; esteve a false até ao Firefox 87 e passou a true a partir do Firefox 88. O interruptor geral javascript.enabled não lhe toca: o visualizador de PDF é um mundo à parte, com uma definição à parte.
O Chrome e o Edge não expõem qualquer interruptor dedicado ao scripting em PDF. O script de um PDF fica sujeito à permissão de JavaScript do site de onde o ficheiro veio, desativável site a site nos controlos da barra de endereço ou globalmente em chrome://settings/content/javascript — um instrumento bastante mais grosseiro.
O Adobe Acrobat Reader tem o interruptor em que toda a gente pensa: Preferências → JavaScript → Ativar JavaScript do Acrobat. É esse que vale a pena desmarcar, porque o Acrobat é o leitor com a API grande e quase ninguém usa conscientemente um PDF com scripts no trabalho normal.
Na prática: desativá-lo no Acrobat e deixar o navegador em paz é uma escolha sensata e proporcionada. Julgar que o desativou em todo o lado, quando só o fez no Acrobat, já não é.
O que fazer com esta informação
A resposta prática é pequena e vale esses dez minutos.
Desative o JavaScript no leitor de secretária. No Acrobat Reader: Preferências → JavaScript. Remove uma categoria inteira de risco e não custa nada, exceto — há que admitir — a possibilidade de jogar DOOM num campo de formulário.
Mantenha o leitor atualizado. O scripting é uma via de entrada. As falhas no código que descodifica tipos de letra e imagens são outra, e são essas que as atualizações corrigem — historicamente, aliás, a via mais frequente.
Trate documentos inesperados como inesperados. Uma fatura de uma empresa a quem nunca comprou nada merece um momento de reflexão, chegue no formato que chegar. Isto vale mais do que qualquer definição.
Repare no que os três têm em comum: nenhum exige deixar de usar PDF nem desconfiar de documentos em geral. Equivalem a trancar a porta de casa — barato, aborrecido e sensato precisamente porque o risco é pequeno mas não é nulo.
Por que este projeto mereceu a atenção que teve
Seria fácil arrumar o doompdf na gaveta das «curiosidades da internet» e seguir em frente. Defendo que é mais útil do que isso, por uma razão que nada tem a ver com teatro de segurança.
A ideia que a maioria das pessoas tem dos formatos de ficheiro assenta inteiramente naquilo para que os formatos servem. Documentos são para ler. Folhas de cálculo são para números. Imagens são para olhar. Esse modelo funciona quase sempre, e é exatamente por isso que é tão difícil de abalar — e por isso explicar que «um PDF pode conter conteúdo ativo» costuma ser recebido com ceticismo educado.
Um jogo jogável dentro de um documento faz em dez segundos o que um artigo custa a fazer em mil palavras. Substitui uma afirmação abstrata por algo em que se pode clicar.
E o ponto de fundo vai muito além dos PDF. Os formatos acumulam funcionalidades ao longo de décadas. Cada acrescento fez sentido a alguém que resolvia um problema real — validar um formulário é genuinamente útil, tal como um documento capaz de conferir as suas próprias contas. O resultado é que as coisas banais que trocamos todos os dias sabem fazer bastante mais do que o nome sugere. E uma capacidade, uma vez inscrita numa especificação, fica ao alcance de quem quer que leia essa especificação.
O que fica disto para o dia a dia
Nada aqui é um argumento contra o PDF. Continua a ser o melhor formato para enviar um documento que fique igual em todo o lado, em qualquer máquina, daqui a anos. É um problema genuinamente difícil, e o PDF resolveu-o. As funcionalidades que tornam o doompdf possível são as mesmas que tornam possível um formulário fiscal preenchível.
É um argumento a favor de saber com o que se está a lidar. A mesma versatilidade que permite a um documento transportar um jogo permite-lhe transportar scripts, anexos, camadas ocultas e metadados que nunca pensou enviar. Vale a pena compreendê-los, e nenhum deles é motivo de alarme.
É também parte da razão pela qual o PDF Manipulator corre inteiramente no seu computador. Ao juntar, dividir ou converter ficheiros, quantas menos partes envolvidas melhor — não porque os serviços online sejam sinistros, mas porque um documento que nunca saiu da sua máquina é muito mais simples de avaliar do que um que esteve no servidor de outra pessoa.
Trabalhe com os seus PDF totalmente offline — o PDF Manipulator é gratuito →
Fontes
- ading2210, doompdf no GitHub — código-fonte e descrição técnica; Emscripten 1.39.20, saída 320×200 em seis tons, ~80 ms por fotograma, GPL v2
- ading2210, linuxpdf no GitHub — Linux num emulador RISC-V TinyEMU dentro de um PDF, arranque em 30–60 segundos
- Versão jogável (navegadores baseados em Chromium)
- Eric Lawrence, Browser Security Bugs that Aren’t: JavaScript in PDF — o que os motores de PDF dos navegadores permitem e não permitem
- Adobe, Restrict JavaScript API access in Acrobat
- DoomWiki, Licences — publicação do código a 23 de dezembro de 1997, mudança para GPL a 3 de outubro de 1999
- The Register, It’s Doom … running in a PDF file
- Ars Technica, This PDF contains a playable copy of Doom
