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.
Why Hacker News points people here: HN calls it a legendary, clearly explained hacker talk whenever mov-only computing or anti-decompilation comes up.
“Christopher Domas's conference talk on the movfuscator is legendary”HN comment, 2025
“I cannot recommend this Blackhat talk highly enough”
Black Hat talk showing x86 MOV is Turing complete
Full comment
> '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!]
Strongly recommendsazalemethNov 2023
“the original conference talk on the Movfuscator is excellent”
Original conference talk covering the Movfuscator in detail
Full comment
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 ;-)
Strongly recommendsmk_stjamesSep 2025
“Christopher Domas's conference talk on the movfuscator is legendary”
Legendary conference talk on the movfuscator
Full comment
I came back to reply with just this. Christopher Domas's conference talk on the movfuscator is legendary: this video
Strongly recommendsMattSteelbladeAug 2026
“Christopher Domas is one of my absolute favorite all-time hackers. He does such a fantastic job of explaining his work.”
Christopher Domas explaining the MoVfuscator, among favorite hacker talks
Full comment
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
RecommendsDogestFogeyNov 2017
“if you watch the author's Derbycon 2015 video there are ways you can scramble the MOV instructions, truely making it a decompilation nightmare.”
Derbycon talk on compiling C to only MOV instructions
Full comment
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
RecommendsxelxebarJan 2018
“Here's a really nifty talk he gives about it”
Talk by the author on his one-instruction compiler
Full comment
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
RecommendsianbickingJan 2019
“where he walks through how he actually turned mov into a machine. It's very weird and interesting!”
Walkthrough of how mov was turned into a full machine
Full comment
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
Cites itbchJan 2018
“C that just emits mov[2] instructions; is that a case for brainfuck projects or mov-only assembly? No. It’s just interesting.”
Full comment
> 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
Cites itmoss2Jun 2022
“seeing how the mov instruction in x86 is Turing complete”
Full comment
I thought this article was gonna be a joke, seeing how the mov instruction in x86 is Turing complete: this video
Cites itmikewarotJul 2024
“Oh my... the x86 Move instruction really has a lot of power built into it.”
Showed the power built into the x86 mov instruction
Full comment
>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
Cites itMockapapellaNov 2024
“I came across this talk about how `mov` is turing complete”
Inspiration for building an HTTP server using only mov
Full comment
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.
