Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
However, the movfuscator as implemented does still require a sigaction(2) syscall to set up a signal handler, under the justifications that "it is not actually part of the program" and that "if we were in ring 0, we wouldn't need help from the kernel" [0]. However, the latter part seems a little dubious to me: without the help of the kernel running non-MOV instructions, you'd never be able to escape from 16-bit real mode into 32-bit protected mode, since you wouldn't be able to load a valid GDT with the LGDT instruction (as far as I am aware).
[0] https://github.com/xoreaxeaxeax/movfuscator/blob/90a49f31219...
A variation of this has been done using Intel MMU fault handling. Behold: https://github.com/jbangert/trapcc
This is a proof by construction that the Intel MMU's fault handling mechanism is Turing complete. We have constructed an assembler that translates 'Move, Branch if Zero, Decrement' instructions to C source that sets up various processor control tables. After this code has executed, the CPU computes by attempting to fault without ever executing a single instruction. Optionally, the assembler can also generate X86 instructions that will display variables in the VGA frame buffer and will cause control to be transferred between the native (display) instructions and 'weird machine' trap instructions.