

Computing with traps - varjag
https://www.github.com/jbangert/trapcc

======
jbangert
Author here. The point of this work is not only the specific result (lots of
VM edge cases, very hard to reverse engineer source of computation), but to
promote this general class of 'problem' \-- things that are typically not
thought to be so complicated actually containing a Turing-complete
executionenvironment. Other examples include ELF and DWARF binary files, PDF,
etc. etc.

Once you need to evaluate a Turing machine to see what a file (or in my case,
a set of page tables) actually means, you loose a lot of tractability.

------
kazinator
Sounds like a good test case generator for the trap handling in virtual
machines.

------
userbinator
One important thing to note about this is that it requires writing to the
page/descriptor tables, so it must be done from ring 0. It makes a great
"stress test" for emulators though.

------
amelius
> One practical use of this technique is for code obfuscation - many (kernel)
> debuggers will break due to the frequent context switches (esp. cooperative
> debuggers like KGDB) and analyzing the binary is going to be extraordinaly
> confusing, especially if normal X86 instructions and trap instructions are
> interleaved to do weird control transfer. Furthermore, out of the many
> virtual machines only Bochs runs such trap based programs correctly (and
> there are other tricks to distinguish bochs from a real box).

In other words... security through obscurity.

~~~
duaneb
All security is through solutions being obscure. I don't understand this
criticism. Encryption just puts mathematical bounds on the obscurity, for
instance, and a lock only works through the obscurity of having to find a
crowbar.

Security is measured through degrees and layers. No secure system is provably
secure to all attacks. Something like the above would definitely add a lot to
the cost of attempting to understand the data flow, and that shouldn't be
discounted. If I were building a root kit/drm, this would be a pretty decent
way for me to hide data and computation long enough for me to adapt, away from
the tools and patterns people understand.

Security through many layers of obscurity is how our internet doesn't fall
apart. Just think about the massive amounts of plaintext email you can sniff
between servers.

~~~
amelius
> All security is through solutions being obscure. I don't understand this
> criticism. Encryption just puts mathematical bounds on the obscurity

There is a difference. Once somebody writes a tool to unravel the obscurity,
it is simple and fast for everybody to break the security.

Not so with encryption (if used properly, with changing keys, one-time
passwords, etc.)

~~~
duaneb
> Once somebody writes a tool to unravel the obscurity, it is simple and fast
> for everybody to break the security.

Yes, it has a lower bound. But that tool has a high obscurity level itself. So
the lower bound on breaking the security is finding someone who can write that
tool.

Not great, but decent to buy time, as I said before :)

