Break Me00 The MoVfuscator Turning mov into a soul crushing RE nightmare Christopher Domas

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

I came back to reply with just this. Christopher Domas's conference talk on the movfuscator is legendary: ▶ this video

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 ;-)

> '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!]

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

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

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

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.

>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

I thought this article was gonna be a joke, seeing how the mov instruction in x86 is Turing complete: ▶ this video

> 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