Hacker News Reader

Comment by DogestFogey | Hacker News Reader

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 https://github.com/xoreaxeaxeax/movfuscator

2. Derbycon 2015 video https://www.youtube.com/watch?v=R7EEoWg6Ekk

View on HN

This is because "movfuscation" isn't a practical option for people actually trying to ship binaries that still perform well for customers but resist reverse-engineering. One of the battlegrounds for this sort of thing is the tug of war between game developers and cheat developers, and games still need to perform very well. Things the author mentioned, like address-rewriting at runtime, don't incur a performance penalty.

Just rebuild the sensitive portions of your code using movfuscator and leave the performance critical stuff alone. As long as everything is statically linked and you don't do anything stupid like "if (check) unlock()" that can be easily patched, it would make life pretty miserable for the RE crowd.

What's wrong with "if (check) unlock()" ? x)

It can be modified to "if (true) unlock()" relatively very easily, even in binary. No disassembling needed.

tell that to game developers shipping shitty DRM running game code inside a non hardware accelerated VM.

Demovfuscator | https://news.ycombinator.com/item?id=11961345 (June 2016)

references Movfuscator discussions:

- https://news.ycombinator.com/item?id=10021259

- https://news.ycombinator.com/item?id=9751312

Reply on news.ycombinator.com