6 HN users recommended this talk7 months2017–2026score 9
Years with an HN recommendation, 2007–2026
HN calls it a legendary, clearly explained hacker talk whenever mov-only computing or anti-decompilation comes up.
Christopher Domas's Derbycon 2015 talk on the M/o/Vfuscator, a compiler that emits only x86 mov instructions, showing mov is Turing complete. It explains how a full machine is built from mov and why the output is a nightmare to reverse engineer.
“Christopher Domas's conference talk on the movfuscator is legendary” (HN, 2025)
> 'Having worked on really "heavily obfuscated" code (flattened control flow, functions implemented in obfuscated VMs, custom incompatible ABI, cryptographic encryption of code, etc.), this gobfuscator looks comparatively easy :) ' For any HN readers who have not already encountered the MOVfuscator [1] I cannot recommend this Blackhat talk highly enough -- the x86 MOV instruction is turing complete, and it flattens arbitrary code to MOVs. It's also the only time I've ever seen brainfuck being used as a seriously sensible intermediate language ;-) [1] [this video] [I think this is the preferred link!]
If you haven't seen it, the original conference talk on the Movfuscator is excellent – [this video] – it goes through it in detail and describes how version 0.0 had Brainfuck as a totally legitimately valid intermediate language ;-)
Original conference talk covering the Movfuscator in detail
I cannot wait for the accompanying Black Hat talk. Christopher Domas is one of my absolute favorite all-time hackers. He does such a fantastic job of explaining his work. Some of my favorite talks of his: - Psychological Warfare in Reverse Engineering [link] - The MoVfuscator [this video] - Hardware Backdoors in redacted x86 [link]
Christopher Domas explaining the MoVfuscator, among favorite hacker talks
I'm surprised the Movfuscator hasn't been mentioned yet. It compiles C code into unconditional MOVs, and if you watch the author's Derbycon 2015 video there are ways you can scramble the MOV instructions, truely making it a decompilation nightmare. 1. Movfuscator page [link] 2. Derbycon 2015 video [this video]
Derbycon talk on compiling C to only MOV instructions
Christopher Domas implemented this idea in his one instruction compiler, the M/o/Vfuscator: [link] Here's a really nifty talk he gives about it: [this video]
Talk by the author on his one-instruction compiler
I'd recommend the video presentation linked off the page, where he walks through how he actually turned mov into a machine. It's very weird and interesting! [this video]
Walkthrough of how mov was turned into a full machine
> I see this sentiment a lot, but it’s not a useful one... Consider this response for entertainment purposes only. It’s easy to become insult(ed|ing) or get into a holy war, but I’m really not invested in any of that. That said: it is a useful sentiment, and a kubernetes script written in sh(1) is not the answer to the question. That one “can” does not mean one “should”. The reddit comment cites init scripts (I happen to use RC scripts, and haven’t viewed init scripts in a while) as an example of why shell is so great - everybody uses init! 1) of course everybody does. And it -happens- to be written in shell. So what? 2) this is fine! The scripts I see are 10s of lines long and practically flow top->bottom w maybe one or two conditionals. This is more akin to a job control language. A perfect application for sh(1). I just feel it (and you can too): sh(1) (or bash - nobody cares) features feel archaic and brittle. People have written impressive work in brainfuck[0][1], or C that just emits mov[2] instructions; is that a case for brainfuck projects or mov-only assembly? No. It’s just interesting. And kubernetes scaffolding or anything else big that happens (by some miracle) to work are not excuses for huge shell scripts. That’s just tautology - otherwise we’d be talking about the virtue of these scripts. For a boot sequence (rc/init) even if we ignore that the short scripts are actually suitable for the important job, I’d say their other grace is that sh(1) is demanded by POSIX
>What exactly is the ask here? I wasn't sure, just a kick in the pants to get me out of the rut I was stuck in. >Do you want input for a programming model? Any suggestions are great >Practical advise for building a compiler? Yes, or even hints as to the right direction. >Do you want to target real hardware or a software simulator? I was just targeting real hardware, and started learning Verilog using YOSYS. Then it dawned on me that if you have a compiler, and you can break code into a huge directed acyclic graph of operations, you can spilt it up into chucks rather trivially. The compiler becomes a universal solvent for code. If you have BitGrid chips, then can execute parts of the grid quickly in parallel (1 nanosecond or less cycles across the chip), if all you have is CPUs with a lot of RAM, you can execute parts of a huge grid very slowly (about 60 nanoSeconds/cell on my PC, single threaded, I should be able to get an 8x speedup on my 8 thread machine) I'd like to eventually run GNU Radio flowgraphs at better than real time through a BitGrid. I should be able to do it with audio now, for small graphs, using my simulator. I'd also like to figure out how to make a backend for GeoHot's TinyGrad that outputs a BitGrid graph. >[0]: [link] Oh my... the x86 Move instruction really has a lot of power built into it. [1] I'll be digging through the GitHub repo he mentioned[2] for a while, it looks quite interesting. Thanks for your help! [1] [this video] [2] [link]
Showed the power built into the x86 mov instruction
Hey HN, a few years back I came across this talk about how `mov` is turing complete and how this can be hacked into writing programs that run entirely using only `mov` instructions ( [this video] ). A couple years later I stumbled across an article explaining how to implement a simple http server from scratch ( [link] ). Naturally, I tried to combine the two concepts but the AI models weren't good enough at the time and I didn't have the bandwidth for yet another questionably useful rabbit hole. Fast forward to today and o1 was able to implement it with some iteration. I hope you enjoy this quick weekend project. I tried to make the README as helpful as I could to get it running on your own computer easily, though I probably missed some steps. I also tried to use o1 to review our conversation to add reasoning for various changes that were made between the original server implementation and the one that is `mov` compatible.
Inspiration for building an HTTP server using only mov
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
11 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Read more
Citations, criticism and jokes
Read more
Read more
Read more