5 ms·

Sandsifter: x86 processor fuzzer

105 points by bellinom 8y ago

judge2020 8y ago
Reveal talk at Blackhat showing this off: https://www.youtube.com/watch?v=KrksBdWcZgQ https://www.youtube.com/watch?v=KrksBdWcZgQ
- artificial 8y ago
  Fascinating! Plus a very easy to follow presentation. Thanks for the link.
infinity0 8y ago
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 .start={.bytes={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}, .len=0}, ^~~~ injector.c:321:93: note: (near initialization for ‘total_range.start.bytes’) injector.c:322:91: warning: excess elements in array initializer .end={.bytes={0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}, .len=0}, ^~~~ 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 2
- rgovostes 8y ago
  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 https://stackoverflow.com/a/11518308
  - infinity0 8y ago
    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.
    - rgovostes 8y ago
      You ought to update your pull request, then! I'm not sure why they don't accept regular issues.
      - sabas123 8y ago
        Because this github release was only for talk and he has since moved on (albeit is still using it for other projects) The sifter isn't terrible intresting it self but could use a lot of chances. Like the ability to use multiple disassemblers. God that was such a pain to hack that one together.
    - vectorEQ 8y ago
      for these kind of low level things, it's best to turn off all compiler optimizations and os specific features. if you run gcc -V or something hten it will dump it's default flags for the distro you are on. What i ususally do is create a cross compiler with nothing enabled for these kinds of projects. This saves a lot of sifting and disabling options and optimizations. If you have a bunch of inline assembly and such things, optimizations can be really killing.
- iammyIP 8y ago
  works when compiled with -no-pie on xubuntu 18.04
infinity0 8y ago
It seems this is the preferred URL: https://github.com/xoreaxeaxeax/sandsifter 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?
- dang 8y ago
  Ok, changed from https://github.com/Battelle/sandsifter https://github.com/Battelle/sandsifter.
panic 8y ago
I love the visual design of the UI. It looks like something out of a hacker movie.
shinelive 8y ago
Share a porn live link www.shineliveapp.com/?f=ycombinator
caf 8y ago
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.
- tralarpa 8y ago
  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.
- pm215 8y ago
  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...
pkaye 8y ago
Same guy who did the https://github.com/Battelle/movfuscator https://github.com/Battelle/movfuscator which compiles programs into code with only the x86 MOV instruction.
vectorEQ 8y ago
this page fault trick to check insn len is awsome, this is such a good technique!

105 points by bellinom 8y ago

judge2020 8y ago

Reveal talk at Blackhat showing this off: https://www.youtube.com/watch?v=KrksBdWcZgQ https://www.youtube.com/watch?v=KrksBdWcZgQ

artificial 8y ago
Fascinating! Plus a very easy to follow presentation. Thanks for the link.

infinity0 8y ago

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 .start={.bytes={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}, .len=0}, ^~~~ injector.c:321:93: note: (near initialization for ‘total_range.start.bytes’) injector.c:322:91: warning: excess elements in array initializer .end={.bytes={0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}, .len=0}, ^~~~ 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 2

rgovostes 8y ago
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 https://stackoverflow.com/a/11518308
- infinity0 8y ago
  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.
  - rgovostes 8y ago
    You ought to update your pull request, then! I'm not sure why they don't accept regular issues.
    - sabas123 8y ago
      Because this github release was only for talk and he has since moved on (albeit is still using it for other projects) The sifter isn't terrible intresting it self but could use a lot of chances. Like the ability to use multiple disassemblers. God that was such a pain to hack that one together.
  - vectorEQ 8y ago
    for these kind of low level things, it's best to turn off all compiler optimizations and os specific features. if you run gcc -V or something hten it will dump it's default flags for the distro you are on. What i ususally do is create a cross compiler with nothing enabled for these kinds of projects. This saves a lot of sifting and disabling options and optimizations. If you have a bunch of inline assembly and such things, optimizations can be really killing.
iammyIP 8y ago
works when compiled with -no-pie on xubuntu 18.04

infinity0 8y ago

It seems this is the preferred URL: https://github.com/xoreaxeaxeax/sandsifter 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?

dang 8y ago
Ok, changed from https://github.com/Battelle/sandsifter https://github.com/Battelle/sandsifter.

panic 8y ago

I love the visual design of the UI. It looks like something out of a hacker movie.

shinelive 8y ago

Share a porn live link www.shineliveapp.com/?f=ycombinator

caf 8y ago

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.

tralarpa 8y ago
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.
pm215 8y ago
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...

pkaye 8y ago

Same guy who did the https://github.com/Battelle/movfuscator https://github.com/Battelle/movfuscator which compiles programs into code with only the x86 MOV instruction.

vectorEQ 8y ago

this page fault trick to check insn len is awsome, this is such a good technique!