The Doom-in-a-PDF dev is back – this time with Linux
- Reference: 1739709487
- News link: https://www.theregister.co.uk/2025/02/16/dev_linux_pdf/
- Source link:
Yes, the humble PDF – thanks to its ability to run limited JavaScript – has been coaxed into booting a stripped-down 32-bit RISC-V Linux buildroot environment in a suitable PDF viewer. This is made possible by compiling the C-based [1]TinyEMU emulator into JavaScript, and then embedding that into a PDF so that it is executed by the document viewer, and it in turn runs the included small Linux distribution.
The person who managed the achievement also created DoomPDF, which The Register [2]reported last month.
[3]
GitHub user ading2210, who identifies themselves as a high school student interested in programming, web development, and cybersecurity, asked us to call him Allen. On the GitHub page for LinuxPDF, he [4]describes the project as working in a similar manner to DoomPDF.
[5]
[6]
"The full specification for the JS in PDFs was only ever implemented by Adobe Acrobat, and it contains some ridiculous things like the ability to do 3D rendering, make HTTP requests, and detect every monitor connected to the user's system," Allen wrote. "With this, we can do whatever computation we want, just with some very limited I/O [Input/Output]."
[7]
Try doing this in a Word doc! – click to enlarge
Limited is definitely true. As the coder notes, performance isn't great. It takes the Linux kernel up to a minute to boot inside a PDF, which is 100 times slower than normal, but Allen notes there's no way to fix this. As with the prior experiment, you need a Chromium-based browser to run LinuxPDF, though if you get it working in something else, more power to you.
Controls are clunky at best. LinuxPDF includes a full software keyboard and an optional text field for typing complex commands. Your physical Delete key won't work, nor will Enter. You are forced to rely on the virtual keyboard for everything except typing letters, numbers, and slashes.
And be careful with those – the software keyboard's Delete key refused to remove errant forward slashes, forcing this vulture to send the bad command and wait for the system to process it before starting over.
[8]Damn Small Linux returns after a 12-year gap
[9]'Maybe the problem is you' ... Linus Torvalds wades into Linux kernel Rust driver drama
[10]Can The Register run Crysis Remastered ? Yes, but we don't see why you would want to
[11]Open source maintainers underpaid, swamped by security, going gray
What's more, the Linux build in the PDF isn't persistent in terms of storage, not that you'd want to endure more than five minutes of this exercise in patience. Basic Linux commands – creating directories, navigating them, and adding blank text files – work as expected. But after saving, closing, and "rebooting" the PDF, all changes were lost.
Allen confirmed the lack of persistence, but told The Register there are still a lot of cool things you can do with his bare-bones Buildroot system.
[12]
Can you install applications? Sure, but "there's no networking, so any applications have to be downloaded and installed during the build process," Allen said.
"The emulator supports a video output, so you could run X11 and GUI programs," he noted. "Maybe you could even run a PDF reader in that, but considering how slow the emulator is, it'll take quite a long time."
For those with a particularly masochistic streak, a 64-bit RISC-V version of Alpine Linux is also available for compilation for LinuxPDF using Allen's instructions in the GitHub repository, though he notes that version "is about twice as slow." Given how sluggish the 32-bit buildroot version is, it's not recommended, but it does include additional tools beyond the Busybox set installed in that 32-bit iteration.
[13]
As we noted in our trial of DoomPDF, it's an impressive proof of concept. However, booting Linux inside a PDF serves as a reminder that Portable Document Format can easily be misused – and [14]often is .
Allen says he's not too worried about the security concerns of JavaScript in PDFs because while it increases the attack surface, most modern PDF engines have strong security measures.
"Embedding JS in PDFs is not new ... so when these features were implemented in PDF readers, the security risks were already taken into consideration," the coder said. "It's probably even safer than visiting a regular webpage."
He noted that both Chrome and Firefox, while using different JavaScript engines, don't allow JIT in these circumstances, and force their engine to interpret code instead, hobbling performance but significantly reduces security risks.
Regardless, the old rule of security hygiene still holds true. If you can't be sure the file is from a trusted source, don't open it.
As for what the PDF wizard has in mind for his next hack, Allen told us he doesn't have anything else in the pipe.
"One of my friends was working on porting a Gameboy emulator, though," he noted. If that ever emerges, rest assured we'll be trying it out and telling you all about it. ®
Get our [15]Tech Resources
[1] https://bellard.org/tinyemu/
[2] https://www.theregister.com/2025/01/14/doom_delivered_in_a_pdf/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/bootnotes&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z7IZzIV9VxBt4bCF0GpfQQAAAJg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://github.com/ading2210/linuxpdf?tab=readme-ov-file
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/bootnotes&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z7IZzIV9VxBt4bCF0GpfQQAAAJg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/bootnotes&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z7IZzIV9VxBt4bCF0GpfQQAAAJg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://regmedia.co.uk/2025/02/13/linuxpdf.png
[8] https://www.theregister.com/2024/02/14/damn_small_linux_returns/
[9] https://www.theregister.com/2025/02/07/linus_torvalds_rust_driver/
[10] https://www.theregister.com/2020/09/25/can_the_register_run_crysis/
[11] https://www.theregister.com/2024/09/18/open_source_maintainers_underpaid/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/bootnotes&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z7IZzIV9VxBt4bCF0GpfQQAAAJg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/bootnotes&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z7IZzIV9VxBt4bCF0GpfQQAAAJg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://www.theregister.com/2022/05/24/hp-pdf-phishing-malware/
[15] https://whitepapers.theregister.com/
Re: Coolness aside
They probably won't be.
We've basically hit the limit of single-thread performance using electricity. There is probably a 50% improvement available via things like moving the RAM nearer the CPU and dropping more parts of x86, but nothing like the multiple orders of magnitude we've previously enjoyed.
Nearly all recent improvements are by parallel computation of one form or another - more general purpose CPU cores, GPGPU, NPU, external preprocessing in ASICs etc.
Re: Coolness aside
Who said something about using electricity? Speed can improve dramatically with paradigm shifts.
The problem with "old us" is that we cannot imagine and cannot foresee the future in what "future older us" and "offspring of us" will use. We are terrible fortune tellers. What is sure is that the future will be different from the present and the past. "Different in what way" is just speculation for "old us".
Re: Coolness aside
Coolness? It's an abomination.
Call me a boring old fart, but the whole point of PDF was supposed to be that it was as immutable as a paper document, didn't run code in the background, and is pretty safe to open.
Re: Coolness aside
Unfortunately, you have been cruelly misinformed. Postscript (and, hence, PDF) has always been a complete language, and creating documents on the fly has always been a fun sideline.
After all, you can have a short PDF which contains all prime numbers - all infinitely many of them - and prints them all out if you want - just keep supplying paper and ink.
Re: Coolness aside
If I remember correctly, PS and PDF were Turing compatible languages.
Re: Coolness aside
... and they should be great for making colorful printouts of [1]Turing patterns too ... a possible next project for GitHub user Allen ading2210 ... (just gotta introduce a PDE solver into the PDF's JavaScript).
[1] https://knowablemagazine.org/content/article/living-world/2024/animal-patterns-spots-stripes-explained-turing-mechanism
Re: Coolness aside
‘Call me a boring old fart, but the whole point of PDF was supposed to be that it was as immutable as a paper document, didn't run code in the background, and is pretty safe to open.”
Oh dear sweet, sweet summer child… :-)
I have made quite a decent living over the last 12 years ago out of the fact that if you set out to design a file format specifically to act as a delivery vehicle for malware you’d be hard pressed to “improve” on PDF, and that’s just the documented bits working as designed before you consider the possibility of implementation flaws…
Seriously, have a very quick skim[1] through the specifications…
https://pdfa.org/resource/iso-32000-pdf/#pdf-1
https://pdfa.org/resource/iso-32000-pdf/
…and if it doesn’t make your blood run cold you’re either not looking properly or shouldn’t be working in the IT industry.
[1] Given the size of them more than the most cursory glance would be a big ask, but that should be enough.
Sadly Fabrice's TinyEMU only provides processor emulation support for RISC-V. The x86 emulator delegates the work to KVM which would be considerably more work to get running in a PDF ;)
Coolness aside
The slow can be fixed. Just wait a few years decades and our computers are fast enough to let this run at acceptable speeds. At that point, someone will probably think it is a good idea to build emulation of an emulator to emulate an emulator emulating the emulator emulating the emulator in emulation and actually write an emulator for it.