Doom Runs in Word by Replacing a Document Picture Every Tick
A novelty port exposes the authority behind Enable Content: decoding embedded binaries, writing files and loading executable code from an office attachment.
The picture inside the Word document keeps changing because a Doom game is running behind it. Somebody has given the document an unusually demanding illustration workflow.
The maker’s README explains that the file carries a DLL and game data encoded as base64. A macro extracts them to disk and loads the library. Each game tick produces a bitmap; VBA “replaces the image” in the document while native code reads the keyboard state.
The port “Does not have sound,” the README says. Its stated requirements are Windows on x64 and the latest Word. The repository is the maker’s own account of the implementation, rather than a compatibility test across Office versions.
Play the video on YouTubeThe native library does the game work between picture updates. The README names GetAsyncKeyState as the way it reads keyboard input, while the VBA loop advances the game and swaps the image. Word supplies a document surface and executable macro environment; the compiled game code supplies the moving scene that surface keeps receiving.
The build instructions make that split visible. Make and a MinGW compiler produce the DLL. A Python utility converts the library and game data into VBA material stored in the document’s modules. The finished document therefore carries more than a link to an external application: it contains encoded material the macro can write out when it runs.
Base64 gives that binary data a text representation. Seeing text inside a document or macro module says little about what the decoded bytes will do. Here the destination is a Doom library, which makes the behavior unusually easy to recognize once the document starts replacing its illustration.
The lack of sound also belongs to the demonstration. A viewer watching monsters move inside Word should not infer that every part of the original game has made the trip. The README limits the platform to Windows x64 and the current Word, so it offers no basis for promising the same trick in a browser editor or a Mac installation.
For teaching, the useful comparison is the document before execution and the files the macro intends to produce. That gives someone a concrete explanation of why enabling content changes the program’s authority. A picture that stays still and a picture backed by a newly loaded library can occupy the same rectangle on screen.
A demonstration could trace those operations without asking anyone to weaken their normal document protections. The next genuinely useful experiment is whether a reader can identify the point where opening a file turns into granting it permission to execute its payload.
A security trainer could put that frame replacement beside the macro’s DLL-loading step and ask which operation required the reader’s permission. The next document asking for executable privileges needs an explanation just as concrete about what it will load.