https://core-jmp.org/2026/03/can-it-resolve-doom-game-engine-in-2000-dns-records/ core-jmp core-jmp death of core jump * Home * windows * Reverse Engineering * exploitation * shellcode * About * Privacy Policy HomeBlog.NETCan it Resolve DOOM? Game Engi... Can it Resolve DOOM? Game Engine in 2,000 DNS Records Can it Resolve DOOM? Game Engine in 2,000 DNS Records Can it Resolve DOOM? Game Engine in 2,000 DNS Records March 22, 2026 by oxfemale with no comment .NETDNSMalwarePoCpowershellRedTeam Download PDF Original text by Adam Rice The article "DOOM Over DNS" demonstrates an unusual proof-of-concept showing how the classic game DOOM can be stored and executed entirely using DNS infrastructure. The author exploits the fact that DNS TXT records allow arbitrary text data and are rarely validated or monitored in depth. By Base64-encoding binary files, splitting them into chunks, and storing them across thousands of TXT records in a DNS zone, the author turns DNS into a distributed file storage system. To make the idea practical, a modified C# port of DOOM (managed-doom) was used so the compiled .NET assemblies could be loaded directly from memory instead of the filesystem. The project compresses the DOOM WAD and engine binaries, uploads the encoded chunks into roughly 2,000 DNS TXT records, and then uses a PowerShell loader (~250 lines) to query these records, reassemble the data in memory, and execute the game without writing anything to disk. The result is a fully working DOOM instance launched entirely from DNS queries. Beyond being a humorous technical experiment, the article highlights how DNS infrastructure can be abused as a global, distributed storage and delivery channel, which has implications for malware staging, covert payload distribution, and forensic evasion. 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 mustexist 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. Share this: * Share on Facebook (Opens in new window) Facebook * Share on X (Opens in new window) X * Like this: Like Loading... Tags: .NET, Covert Channels, DNS, DNS Abuse, DNS TXT Records, DOOM, Fileless Execution, Malware Staging, Offensive Security, Payload Delivery, PowerShell, Proof of Concept, Red Team Techniques Previous Post (CVE-2026-0714) TPM-sniffing LUKS Keys on an Embedded Device Next Post What You Need to Know: Windows Admin Center Remote Privilege Escalation (CVE-2026-26119) Comments are closed. Search [ ] Recent Posts * Bypassing Code Integrity Using BYOVD for Kernel R/W Primitives * Hidden Bugs in Plain Sight: Hunting Vulnerabilities Inside Shared Libraries * Inside WMI: Tracing Windows Management from Consumers to COM Providers * Backup to SYSTEM: Exploiting the IDrive Client Privilege Escalation Flaw * Breaking the Firmware Trust: Disabling Security in a Locked BIOS Archives * March 2026 * February 2026 * January 2026 * November 2025 * September 2025 Active Directory byovd bypass cpp Detection Engineering EDR EDRBypass EDR Evasion EDREvasion Embedded Security Exploit Development firmware Firmware Analysis Firmware Security Hardware Hacking Hardware Security injection IoT Security Kernel Debugging Malware Development Offensive Security poc Post-Exploitation PPL Privilege Escalation Process Injection red team RedTeam Red Teaming Red Team Techniques Reverse Engineering ROP Secure Boot Security Research shellcode TPM Vulnerability Research winapi WinDBG windows Windows 11 Windows Internals Windows Kernel Windows security WindowsSecurity Categories * .NET * access * ACE * ACL * Active Directory * Active Directory * AD CS * Administrator * AI Agents * alloc * ALPC * Antivirus * APC * Apple Silicon * ASM * ASR * attaks * Audio * AV * BIOS * BitLocker * Blue team * Bluetooth * Boot ROM * Broadcom * BSoD * buffer overflow * BYOUD * BYOVD * Bypassing * Cache * Callbacks * CIMOM * CLFS * cmd * COM * Containers * Cortex XDR * cpp * CPU * Credential Attacks * Crypt * Cryptography * CryptoPro * DCOM * Debug * Defender * DEP * Deserialization * DFIR * DMA * DNS * Driver * dump * EDR * Embedded * Encryption * Escalation * ESP32 * Evasion * Eventlog * Exploit Development * exploitation * filesystem * firmware * Flash * Gadgets * GATT * Ghidra * Hardware * Hooking * Impacket * impact * Injection * IOCTL * IoT * Kerberos * kernel * kernel-mode * LDAP Relay * Library * Linux * LLM * LNK * Loader * LOLExfil * LSA * LSASS * MacOS * Malware * MCP * MS-DOS * MS-EVEN * MS-LSAD * MS-SAMR * Network * NTLM Relay * NVMe * ODR * Palo Alto * PBA * PCI * PEB * Penetration Testing * PHP * Plugins * PoC * powershell * powershell * PPL * Privilege * Protection * PXE * Python * QEMU * Race Condition * RCE * RedTeam * Registry * Reverse Engineering * root * ROP * RPC * RTTI * Rust * SAM * Secure Boot * Security * Security * shellcode * Shortcut * SPI Flash * STM32H5 * TCP/IP * TEB * Telegram * Telnetd * TPM * UAC * UART * UEFI * Uncategorized * Use-After-Free * user-mode * VMProtect * VMware * Warbird * WASM * WEB * winapi * winapi * WinDBG * windows * Windows Admin Center * Winsock * WMI * Wordpress * WSL * XNU Kernel Log in (c) 2026 core-jmp. All rights reserved. Shopping Basket [ ] [Search] [ ] [Search] %d