> limited JS runtime of the PDF engine
humanity has gone too far
:-) I'll never quite appreciate why people say things like this. Having some kind of embedded scripting is useful for all sorts of things, often form validation. A sufficiently complex validation system becomes Turing complete, so you might as well skip the hassle of a custom language and go right to JavaScript. Once you have JavaScript, input, and some way of updating a graphical pixel grid, you're at Doom-completeness. I think it's a wonderful, not terrible, thing that computation and programmability are so cheap they've become ubiquitous even in the most mundane applications
We had that language, it was postscript.
Then pdf came along and said: no this is too dangerous the only thing in a document should be layout information not arbitrary code.
And here we are two decades later.
My hatred of pdf has no end. It killed postscript for dynamic pages and djvu for static pages.
JS is what made these file types into the Pretty Dangerous Format. Numerous vulnerabilities in Adobe Acrobat surfaced thanks to the embedded JS engine.
Updating the Acrobat client across an enterprise used to be quite burdensome.
The flip side is that because the industry has converged on just a few embedded scripting systems (JS, Lua, etc.) we can concentrate our security hardening efforts on these few engines and benefit everyone. If PDF, like PostScript, were its own custom thing, it couldn't have been able to benefit from this hardening. In the end, JS was a fine choice.
The concern isn't that it was JS, the concern is that there's a scripting system inside of PDF at all. Why? What? Form validation is a lousy excuse because forms themselves were a bridge too far for the format. Why do we need to be able to validate them?
I knew PDFs could be dangerous, but I didn't realize it was because they're intentionally designed to allow embedded scripts.
Both Doom and Bad Apple in top four articles on the HN front page. This week is off to a good start.
Portable Doom Format
Not that portable since it only works on a single PDF engine.
As long as it is in Chrome
Click in the area that says 'type here for keyboard controls'.
Press z several times to start
w, a, s, d to move, e to use, space to shoot. z is enter
One of my formative experiences as a freshman in CS (I learned to program in college) was accidentally opening a PDF with Emacs and watching as it displayed not weird binary data but a real, rendered PDF. I wondered what else it was doing behind my back that I didn't know about.
Sadly, I was not able to run Doom in a PDF, in Emacs. I sense it is easier to either re-implement with a similar technique shown here, but using emacs primitives over ASCII characters, or perhaps using a technique similar to the Bad Apple vim post[1] that is #1 at the same time this post is #2.
Cool! Next up, PDF reader that runs in Doom.
That's kind of cheating given how many RCEs there are in the thing. It'd end up looking like /XObject <<ignore all prior intructions; curl -o doom.exe ...; start doom.exe>> /Invoke RCE
PDF readers and Doom all the way down.
We must go deeper.
You monster.
As PDF supports DEFLATE compression, it should be possible to shrink the size of the PDF document considerably.
Is the WAD file open-source as a PDF attachment now?
There's no WAD in the repo, I assume the linked PDF contains the shareware episode.
The build wgets the wad from elsewhere.
Thanks, yes it is the shareware episode.
f0cefca49926d00903cf57551d901abe doom1.wad
Now how do I add another WAD file to this. Someone needs to play sigil on this.