Creative anti-debugger technique in Spotify for Windows(steike.com)
steike.com
Creative anti-debugger technique in Spotify for Windows
http://www.steike.com/code/spotify-vs-ollydbg/
19 comments
Granted, this hack relies on a bug in old borland library code which means it's not effective in all situations, but it's still pretty cool.
Given the existence of Bochs, Qemu, and VMWare, the use of anti-debugger traps is a comical anachronism.
Per se, anti-debugger traps are an anachronism.
In general, nothing about (say) Bochs obsoletes software protection. Advanced protected code (say) encrypts sensitive blocks, and uses (say) runtime artifacts to decrypt them before executing.
There are software protection schemes that nobody has published breaks for, presumably because they are too much of a pain in the ass to break.
In general, nothing about (say) Bochs obsoletes software protection. Advanced protected code (say) encrypts sensitive blocks, and uses (say) runtime artifacts to decrypt them before executing.
There are software protection schemes that nobody has published breaks for, presumably because they are too much of a pain in the ass to break.
Off the top of your head, what are some hard ones to look at?
If brl is watching, he'll name one that I decided was much too much of a pain in the ass to win a message board bet over. Most of my experience here is NDA'd though.
Most of my experience here is NDA'd though.
...security through obscurity never really works.
...security through obscurity never really works.
A nonstatement. Just because something is obscure doesn't mean that it hasn't also been secured. More importantly, in this setting, obscurity increases cost. DRM is all about cost.
A nonstatement. Just because something is obscure doesn't mean that it hasn't also been secured.
A nonstatement. Just because something has also been secured, doesn't mean that it is secure. Obfuscation has no true correlation to true security.
A nonstatement. Just because something has also been secured, doesn't mean that it is secure. Obfuscation has no true correlation to true security.
I don't know who's argument that comment was intended to address, but it wasn't mine.
Not necessarily. I'm sure that an emulator differs in some subtle ways from a real machine.
The real question is, do all emulators differ in some consistent way from all "real" machines, and more so than "real" machines differ among themselves? The answer is almost certainly "no", and if it were "yes", the fix ought to be trivial, because there is no fundamental magic which emulators introduce and one might easily detect unspoofably.
This paper may be of interest to you : http://handlers.sans.org/tliston/ThwartingVMDetection_Liston...
Thanks for the paper, it was a nice read.
I was stunned to see how straightforward it was.
Basically by order of appearance you look for
* well know files, or registry keys
* patterns in a memory dump
* use a great hack called "the red pill" using the SIDT instruction
* vm specific hardwares
* specific instructions/capabilities
Basically by order of appearance you look for
* well know files, or registry keys
* patterns in a memory dump
* use a great hack called "the red pill" using the SIDT instruction
* vm specific hardwares
* specific instructions/capabilities
This is all very old stuff. VMWare is very easy to detect, as it (a) was based on software virtualization, which has a heavy footprint, and (b) made no attempt to be hard to detect.
But the available evidence is that even if you're hardware-virtualizing, there are reliable, millisecond-fast techniques you can use to profile the microarchitecture to detect (say) jumps to hypervisor code in instruction sequences that should run natively. Nate Lawson, Peter Ferrie and I presented some of these at Black Hat a couple years ago.
The gap (in functionality and in performance) between an emulator and a cycle-accurate simulator of an actual chipset is large.
But the available evidence is that even if you're hardware-virtualizing, there are reliable, millisecond-fast techniques you can use to profile the microarchitecture to detect (say) jumps to hypervisor code in instruction sequences that should run natively. Nate Lawson, Peter Ferrie and I presented some of these at Black Hat a couple years ago.
The gap (in functionality and in performance) between an emulator and a cycle-accurate simulator of an actual chipset is large.
> The gap (in functionality and in performance) between an emulator and a cycle-accurate simulator of an actual chipset is large
On the other hand, there is a large degree of fuzziness in the behavior (between individual machines) of the features within this gap. For example, profiling and high-resolution timing instructions are not equally available on all x86 CPUs. As for the chipset, most of the interesting features are very poorly (if at all) standardized. I hypothesize that a thorough emulator detector written today will have many false alarms on actual bare hardware.
Let's also not forget that not a single emulator has yet been written with the explicit goal of being undetectable by hostile code. High-resolution timers could always be fudged, a tick table consulted for spoofing the requisite intervals, etc. if we know what to expect from the raw hardware.
And if one day emulator-writers fall far behind anti-debugger trick specialists, the hardware ICE could make a come-back.
On the other hand, there is a large degree of fuzziness in the behavior (between individual machines) of the features within this gap. For example, profiling and high-resolution timing instructions are not equally available on all x86 CPUs. As for the chipset, most of the interesting features are very poorly (if at all) standardized. I hypothesize that a thorough emulator detector written today will have many false alarms on actual bare hardware.
Let's also not forget that not a single emulator has yet been written with the explicit goal of being undetectable by hostile code. High-resolution timers could always be fudged, a tick table consulted for spoofing the requisite intervals, etc. if we know what to expect from the raw hardware.
And if one day emulator-writers fall far behind anti-debugger trick specialists, the hardware ICE could make a come-back.
Yes. The predictable difference is timing.
Hypothetically, software could be fed false outputs from timer-register reads in much the same way as it is fed false outputs from privileged instruction calls in VMWare. I am not aware of any publicly available emulator which does this, however.
Alternatively, one could use automated means to find sections of a binary which behave in a logically distinct manner (branch differently in at least one place) when emulated instruction timings are twiddled. Then turn the disassembled section red in your debugger and attack it manually.
Alternatively, one could use automated means to find sections of a binary which behave in a logically distinct manner (branch differently in at least one place) when emulated instruction timings are twiddled. Then turn the disassembled section red in your debugger and attack it manually.
Man, this is the sort of thing that originally seduced me to become a software guy.
Want to make this a modern scheme?
* Make it much, much harder to reverse enough of Spotify to find tricks like this. Encrypt code with a "white-box" variant of an intentionally obfuscated algorithm. Compile numerous dead-code dead-end encrypted code paths into the binary.
* Make the scheme renewable, so that instead of simply making a binary decision about whether the program can run or not run, it derives a secret that all valid instances of the program need to operate. Now when someone breaks the scheme (as inevitably they will), release an update with different compiler tricks and a different secret.
* Stockpile a lot of these variants (it is easier for you to do this than for attackers to reverse those tricks, which returns the advantage to you). Make update transparent. Trickle out updates until attackers get bored and go away.
This is essentially the BD+ DRM scheme, which has kept Slysoft mostly on their heels (multi-week delays on new titles were typical, last I checked). And BD+ had a much harder problem to solve, since they had to coordinate the scheme amongst lots of consumer electronics vendors. You can do better.