If you’ve ever poked at one of my CTF challenges, you’ve probably noticed a pattern - I love hiding payloads in TXT DNS records. I stash the malicious code in a TXT record, have the implant query for it at runtime, and now suddenly the payload is being delivered by the same infrastructure that resolves grandmas-cookie-recipes.com. It’s trivially easy to set up and surprisingly annoying to catch forensically, because who’s flagging the historic contents of TXT records?

I’ve always suspected the technique could go further than staging shellcode. TXT records are just arbitrary text fields with no validation. If you can store a payload, you can store a file. If you can store a file, you can store a program. And if you can store a program… well, it can probably run DOOM.

WTF is DNS

For the blissfully uninitiated, DNS is the system that turns domain names into IP addresses. You type google.com and DNS tells your browser where to go. It’s one of the oldest protocols on the internet and it is deeply, profoundly boring.

But DNS also supports TXT records, these little text fields originally intended for things like email authentication. The key word there is “intended.” Nobody actually validates what you put in them. You can write whatever you want - a love letter, a recipe, or in this case base64-encoded binary data.

Each TXT record can hold about 2,000 characters of text. A single DNS zone can support thousands of records. Public DNS is also globally distributed, cached at edge nodes all over the world, and publicly queryable by anyone with an internet connection. It is (if you squint hard enough) a free, worldwide, serverless key-value store.

Naturally, I wanted to store my movie collection in it.

Duck.jpg

The proof of concept was shockingly easy. Take a file, Base64-encode it, split it into chunks, and upload each chunk as a TXT record. Add a metadata record so the reassembly script knows how to put it back together, and that’s it.

I tested it with a picture of a duck and it worked perfectly. The duck went up, the duck came back down with identical hashes. DNS is now a file server, and as the kids say… Skibidi.

But a JPEG of a duck is boring, and a 1GB MP4 would need roughly 670,000 TXT records spread across hundreds of domains. This was not going to scale to my aspirations of Shrek.

I needed something smaller, something compressed, and something that would actually demonstrate how absurd this is.

Can It Run DOOM?

The universal benchmark for “can this thing do something it was never designed to do?” is, always has been, and always will be DOOM. Thermostats run DOOM, pregnancy tests run DOOM, and I want DNS to run DOOM.

The idea is to fetch the entire game engine and its assets from DNS TXT records, load everything into memory, and run it. No downloads, no installers, and no files written to disk. My goal is to load the game into memory entirely through public DNS queries.

While researching this, I knew I needed to use a DOOM port written in a language that could be reflected into memory in Windows. I knew C# is used frequently by threat actors for this, but I don’t know C# and wasn’t about to rewrite the DOOM source myself, so that’s where I started looking.

I found managed-doom, a pure C# port of the original DOOM engine. Managed .NET assemblies can be loaded from raw bytes in memory, so no files need to exist on the filesystem. In theory, this meant I could fetch the game’s compiled code from DNS and execute it without ever touching the disk.

(In theory.)

Claude Did This Part Because I don’t know C#

managed-doom needed some patching before it could run from memory. It expected to read game data from disk using file paths (C:\Path\to\Game.dll), so that had to be changed to accept a memory stream instead. It compiled as a native executable, which can’t be loaded via reflection, so that had to change. Its windowing library was also a native DLL, which must exist as a file on disk for Windows to load it, so that had to be ripped out entirely and replaced with direct Win32 API calls.

I worked on a majority of this piece with Claude, going back and forth on the tricky parts (all of it.) The result is a set of pure managed .NET assemblies that can run DOOM from a MemoryStream with zero native dependencies. The gory details are in the repo.

I also decided to completely cut the audio to save on the amount of DNS records needed. So, unfortunately, DOOM runs silent, but I don’t think the demons mind.

Creating the Records

With compression, DOOM fits comfortably in a single CloudFlare Pro DNS zone. The WAD file drops from 4MB to 1.7MB, the DLL bundle goes from 4.4MB to 1.2MB. In total, it required about 1,966 TXT records on a single DNS zone. The upload took about 15 minutes using the CloudFlare API.

The player script is about 250 lines of standalone PowerShell. It resolves all ~2,000 DNS queries in 10 to 20 seconds, reassembles everything in memory, loads the assemblies via reflection, and launches the game with nothing written to disk.

I chose to spend $20/month on a CloudFlare Pro domain for this project because I abuse their free tier for my cursed computing projects enough already, and I really didn’t want to buy 10 domains to do it the other way.

DOOM Over DNS

And it works. DOOM is stored, launched, and running from DNS records.

As I mentioned above, DNS is incredibly boring, so this is difficult to illustrate in a flashy, exciting, sexy hacker way. Here’s a sample of a couple of the records. Keep in mind there are about 2,000 of these created to run DOOM.

The metadata records look like this. The player script reads from these to know how many records to loop through for reassembly, the hash value to check against for corruption, and any additional zones (domains) that might be present.

No files are written disk as part of the player script, nothing is installed, and no additional dependencies are required. All it took was about 2,000 TXT records and a 250-line PowerShell script that knows how to put them back together with Resolve-DNSName and some vibes.

omg I love DNS. DNS is my life.

DNS is almost 45 years old and it was designed to map hostnames to IP addresses. It is not a file storage system. It was not designed to be a file storage system. Nobody at the IETF was thinking about it being used as a file storage system when they wrote RFC 1035.

Yet here we are. The most boring protocol on the internet is also, quietly, one of the most abusable.

I described this project to my mother as such: It’s like taking a phone book and playing the 1986 academy award winning action film Top Gun starring Tom Cruise as a flip-book animation out of the phone numbers on every page.

The full source for this project is available on GitHub.