The Doom-in-a-PDF dev is back – this time with Linux

What's next, Crysis-in-a-CSV?

First came Tetris, then Doom – and now a bare-bones Linux instance that boots inside a PDF.

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 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 reported last month.

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 describes the project as working in a similar manner to DoomPDF.

"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]."

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.

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.

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.  

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 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. ®