Computing with traps
github.com
Computing with traps
1–10 of 13 posts
Re: Computing with traps
#2Re: Computing with traps
#3> 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.
Re: Computing with traps
#4Sounds like a good test case generator for the trap handling in virtual machines.
Re: Computing with traps
#5> 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 ba…
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.
Re: Computing with traps
#6> 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 ba…
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.
Re: Computing with traps
#7> 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 ba…
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.
Re: Computing with traps
#8> 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 ba…
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 understa…
> 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.)
Re: Computing with traps
#9One 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.
Re: Computing with traps
#10> 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 ba…
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.