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

> '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] [VIDEO] [I think this is the preferred link!]

If you haven't seen it, the original conference talk on the Movfuscator is excellent – [VIDEO] – it goes through it in detail and describes how version 0.0 had Brainfuck as a totally legitimately valid intermediate language ;-)

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

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 [VIDEO] - Hardware Backdoors in redacted x86 [LINK]

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 [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: [VIDEO]

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! [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