6 ms·

Creative anti-debugger technique in Spotify for Windows

65 points by tkiley 17y ago

tkiley 17y ago
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.
asciilifeform 17y ago
Given the existence of Bochs, Qemu, and VMWare, the use of anti-debugger traps is a comical anachronism.
- tptacek 17y ago
  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.
  - mahmud 17y ago
    Off the top of your head, what are some hard ones to look at?
    - tptacek 17y ago
      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.
      - Create 17y ago
        Most of my experience here is NDA'd though. ...security through obscurity never really works.
        tptacek 17y ago
        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.
        Create 17y ago
        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.
        tptacek 17y ago
        I don't know who's argument that comment was intended to address, but it wasn't mine.
- vorador 17y ago
  Not necessarily. I'm sure that an emulator differs in some subtle ways from a real machine.
  - asciilifeform 17y ago
    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.
    - tptacek 17y ago
      Yes. The predictable difference is timing.
      - asciilifeform 17y ago
        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.
    - vorador 17y ago
      This paper may be of interest to you : http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf http://handlers.sans.org/tliston/ThwartingVMDetection_Liston...
      - framiere 17y ago
        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
tptacek 17y ago
If the time it took to reverse enough of Spotify to find this trick was worth more than the N months of what Spotify was trying to protect (prior to the disclosure of the problem), then the trick was a net win for Spotify. That's the basis of DRM. 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.
YuriNiyazov 17y ago
Man, this is the sort of thing that originally seduced me to become a software guy.

65 points by tkiley 17y ago

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.

asciilifeform 17y ago

Given the existence of Bochs, Qemu, and VMWare, the use of anti-debugger traps is a comical anachronism.

tptacek 17y ago
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.
- mahmud 17y ago
  Off the top of your head, what are some hard ones to look at?
  - tptacek 17y ago
    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.
    - Create 17y ago
      Most of my experience here is NDA'd though. ...security through obscurity never really works.
      - tptacek 17y ago
        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.
        Create 17y ago
        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.
        tptacek 17y ago
        I don't know who's argument that comment was intended to address, but it wasn't mine.
vorador 17y ago
Not necessarily. I'm sure that an emulator differs in some subtle ways from a real machine.
- asciilifeform 17y ago
  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.
  - tptacek 17y ago
    Yes. The predictable difference is timing.
    - asciilifeform 17y ago
      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.
  - vorador 17y ago
    This paper may be of interest to you : http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf http://handlers.sans.org/tliston/ThwartingVMDetection_Liston...
    - framiere 17y ago
      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

tptacek 17y ago

If the time it took to reverse enough of Spotify to find this trick was worth more than the N months of what Spotify was trying to protect (prior to the disclosure of the problem), then the trick was a net win for Spotify. That's the basis of DRM. 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.

YuriNiyazov 17y ago

Man, this is the sort of thing that originally seduced me to become a software guy.