Computing with traps | Hacker News Reader

Computing with traps

github.com

40 pointsvarjag10 comments

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.

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

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.

> 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.

Think of it like the security offered by a safe. With time and the correct tools, any obfuscated binary will eventually yield. However, the sheer volume of a complex obfuscated binary (especially one which defeats conventional reverse engineering techniques) can keep security researchers spinning in circles for days or weeks while malware remains at large, or frustrate would-be pirates to the point of giving up.

Yes, it would be, but interestingly I didn't interpret it that way. I'm not sure what the author intended but while reading I imagined malware using this technique for obfuscation, and the inability to run this code in virtual machines would also hinder the analysis of such malware. Goes both ways I suppose.

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.

> 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.)

> 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 :)

What argument are you trying to make by throwing in the phrase "security through obscurity"?

This work is different from the kind of things that phrase usually refers to.

Reply on news.ycombinator.com