If you haven't seen it, the original conference talk on the Movfuscator is excellent – https://www.youtube.com/watch?v=R7EEoWg6Ekk – it goes through it in detail and describes how version 0.0 had Brainfuck as a totally legitimately valid intermediate language ;-)
M/o/Vfuscator: A single instruction C compiler
11–20 of 30 posts
Re: M/o/Vfuscator: A single instruction C compiler
#12Branching with only MOV? How does that work? Is there no actual flow control but instead conditional manipulation (MOVs) of values?
Basically the branching points are pointers where one writes a junk memory address or the actual one to operate on. Where to get the correct addresses? A lookup table, the addresses moved into registers.
I think this could be a hack that's repeatable to a pretty good degree in many architectures.
If you'd like to see how exactly, watch the presentation. The presentation links were already shared in discussion and searching movfuscator in Youtube also gets you the result.
Re: M/o/Vfuscator: A single instruction C compiler
#13Related.
> The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.
Re: M/o/Vfuscator: A single instruction C compiler
#14If you haven't seen it, the original conference talk on the Movfuscator is excellent – https://www.youtube.com/watch?v=R7EEoWg6Ekk – it goes through it in detail and describes how version 0.0 had Brainfuck as a totally legitimately valid intermediate language ;-)
Re: M/o/Vfuscator: A single instruction C compiler
#15If you haven't seen it, the original conference talk on the Movfuscator is excellent – https://www.youtube.com/watch?v=R7EEoWg6Ekk – it goes through it in detail and describes how version 0.0 had Brainfuck as a totally legitimately valid intermediate language ;-)
He's my favorite speaker (watch all his talks... they're worth it!), but he seems to have gone MIA (possibly after joining Intel? I don't know the timeline), much to my dismay.
Re: M/o/Vfuscator: A single instruction C compiler
#16Branching with only MOV? How does that work? Is there no actual flow control but instead conditional manipulation (MOVs) of values?
There can be control flow. MOV an address into the right spot in the interrupt vector table then do a MOV that causes a fault that calls the right interrupt (such as a page fault).
The video describes in detail what actually happens. I encourage watching it, it's pretty genius, but the very short version is that you turn execution "off" for any code that is not in the "current" branch by switching over all MOVs to target a scratch space instead of their real targets, which means they still execute, but don't have an actual effect. Before each possible branch target, you check whether to turn execution "on", if it's the current one, i.e. making the instructions which are part of that branch affect "actual" memory again.
Re: M/o/Vfuscator: A single instruction C compiler
#17Branching with only MOV? How does that work? Is there no actual flow control but instead conditional manipulation (MOVs) of values?
X86 MOV is quite a beast.
Re: M/o/Vfuscator: A single instruction C compiler
#18Branching with only MOV? How does that work? Is there no actual flow control but instead conditional manipulation (MOVs) of values?
There can be control flow. MOV an address into the right spot in the interrupt vector table then do a MOV that causes a fault that calls the right interrupt (such as a page fault).
Re: M/o/Vfuscator: A single instruction C compiler
#19Branching with only MOV? How does that work? Is there no actual flow control but instead conditional manipulation (MOVs) of values?
"All problems in computer science can be solved by another level of indirection." - David Wheeler Basically the branching points are pointers where one writes a junk memory address or the actual one to operate on. Where to get the correct addresses? A lookup table, the addresses moved into registers. I think this could be a hack that's repeatable to a pretty good degree in many architectures. If you'd like to see how…
Re: M/o/Vfuscator: A single instruction C compiler
#20Branching with only MOV? How does that work? Is there no actual flow control but instead conditional manipulation (MOVs) of values?
However, it seems to me like if you booted the processor directly into the program instead of having a bootloader and kernel to help you, then you'd run into a brick wall trying to move from 16-bit real mode to 32-bit protected mode, since doing so requires setting up a global descriptor table (GDT), and the only way I know of to do that is with the LGDT instruction. Unless I'm forgetting something?