Fascinating! Plus a very easy to follow presentation. Thanks for the link.
Reveal talk at Blackhat showing this off: https://www.youtube.com/watch?v=KrksBdWcZgQ
Same guy who did the https://github.com/Battelle/movfuscator which compiles programs into code with only the x86 MOV instruction.
Ok, changed from https://github.com/Battelle/sandsifter.
It seems this is the preferred URL: https://github.com/xoreaxeaxeax/sandsifter - for example the issue tracker is enabled, and has 45 issues, whereas the other URL has the issue tracker disabled.
Can one of the admins fix?
Seems like using immediate values in inline assembly operands can be fragile depending on what optimizations the compiler decides to apply. Try building with -ftree-ter in your CFLAGS, as suggested by https://stackoverflow.com/a/11518308
I figured it out, it's because Debian enables PIE and that somehow causes GCC not to be able to satisfy its own rules for allowing inline-assembly to modify %rsp to the value required by this program.
works when compiled with -no-pie on xubuntu 18.04
Can anyone actually get this to compile? I failed last year, and it's still failing:
$ CFLAGS=-fPIC make clean all
rm -f *.o injector
cc -fPIC -c injector.c -o injector.o -Wall
injector.c:321:93: warning: excess elements in array initializer
injector.c:321:93: note: (near initialization for ‘total_range.start.bytes’)
injector.c:322:91: warning: excess elements in array initializer
injector.c:322:91: note: (near initialization for ‘total_range.end.bytes’)
injector.c: In function ‘inject’:
injector.c:778:2: warning: asm operand 15 probably doesn’t match constraints
__asm__ __volatile__ ("\
injector.c:778:2: error: impossible constraint in ‘asm’
make: *** [Makefile:38: injector.o] Error 1
Note that "provide an emulation of an x86 CPU that is sufficiently true to the hardware that it is impossible for a guest program to distinguish it" is not a goal of upstream QEMU -- in part because we don't think it's actually possible. Don't trust TCG (pure-emulation) QEMU to contain a potentially-malicious piece of code, either...
That's very cool. I am also surprised about the bugs discovered in disassemblers. You would expect that these kind of mistakes are quickly discovered. Or was the Intel manual wrong?
Edit: Ah, they explain it in the last paragraph of that section.
The demonstration in Figure 7 of a program that executes a benign codepath on QEMU but malicious on baremetal - and the benign codepath is what shows up in the disassemblers they tested - is very neat.
I love the visual design of the UI. It looks like something out of a hacker movie.
this page fault trick to check insn len is awsome, this is such a good technique!
Share a porn live link