4 ms·

The Tigress Diversifying C Virtualizer

30 points by lelf 12y ago

userbinator 12y ago
The most prominent application of this can be summed up in one acronym: DRM.
- sitkack 12y ago
  It could also possibly make hacking Nginx a whole lot harder.
  - astrange 12y ago
    It's not really good for that, unless you want to prevent someone from understanding their own nginx binary. Undefined behavior remains undefined behavior, and you could arm against overflows more easily with just -fstack-protector or even ubsan.
- azakai 12y ago
  I'm not sure why DRM would be more prominent than other applications? Software diversification is a big topic right now, in the hopes it can make all software more secure. That could help virtual machines, network stacks, and really anything from web browsers to entire OSes.
  - comex 12y ago
    Tigress is labeled as an "obfuscator" that forces people to "crack, and re-crack, the code", for "software protection" from the owner of an "untrusted remote site" [i.e. you on your computer] - its main purpose is to prevent people who already have full access to the binaries from understanding them. This is somewhat related to the type of benign diversification that mitigates exploitation - preventing code that has limited access to the system from pumping the weird machine correctly - but, I think, not much. Many techniques required for the first are useless for the second: if everything is open source, or even if it's not and the attacker is smart enough (unlike most protection measures which are supposed to be independent of intelligence...), then measures implemented by this tool like 'virtualization' (i.e. indirecting execution through an interpreter), branch obfuscation, etc. can be undone easily by an attacker with full access to memory; if the attacker doesn't have full access, there are much simpler and more performant types of randomization that are equally good at defeating them. And measures useful for the second (generally, anything that involves multiple variations of the same version of a program, to force exploiters to learn which one is in use) are no good against the first (since the attacker can just pick one to extract secrets from).
  - hyc_symas 12y ago
    This doesn't make existing code more robust. It only makes it orders of magnitude bigger and slower. Nobody will voluntarily run browsers, network stacks, or OSes built with these techniques, it would set your compute performance back 4 decades at least. As an example, in Adobe's RTMPE (encrypted RTMP) protocol, the type 8 encrypted handshake used an obfuscated crypto routine that comprised 95KB of x86 object code, taking billions of machine cycles to execute. After de-obfuscation it was found to simply be XTEA, which is implemented now in rtmpdump in only 4 lines of C code and executes in hundreds of machine cycles.
- tptacek 12y ago
  That is correct. The author of this tool is an expert in that field, too; his book (Surreptitious Software) is solid. I'm not sure what the subtext of your comment is, though. If it's "software like this is bad because it enables DRM", that's an odd position to take. If you don't want to obfuscate your code, don't run this transformer on it.
  - userbinator 12y ago
    I would never use such a tool on my software; the concern is that others will - especially malware authors, who have been obfuscating their creations for as long as malware has existed. Executable packers/encrypters already significantly frustrate analysis by security researchers and antivirus programs; more powerful obfuscation/diversification tools only make it harder to distinguish between benign and malicious software. Obfuscation makes even legal reverse-engineering (as defined by the DMCA) difficult, meaning that threats like backdoors could become harder to discover. Amusingly enough, the definition of surreptitious that Google gives is quite relevant here: "kept secret, especially because it would not be approved of." I wonder if these people who are pro-DRM ever find themselves in a situation where the systems they create are used against them, and reconsider the effects of their work.
    - tptacek 12y ago
      Tools like these show us what's possible (actually, as Collberg points out, this particular tool is more like training for learning what's possible; the frontier of this approach to software protection is way past it). This is science. It is weird to object to it. Should we instead pretend that it's not possible to effectively obfuscate code?
marktangotango 12y ago
TIL (today I learned): It appears a 'diversifying C virtualizer' is an application that takes C source code, compiles it to an AST and transforms it to bytecode, and inserts a bytecode interpreter in place of the function. It can generate many different such bytecode/interpreter representations of a function, thus making it more of a challenge for crackers.
- tptacek 12y ago
  That same approach, obviously, works for lots of different languages. Not just C. You can even do it at the level of raw algorithms, transforming (for instance) a block cipher implementation that accepts a key as a parameter into one specialized on a specific key and from which the key is (H)ard to extract.
  - v0i0-0 12y ago
    Could you maybe point me to such one tool, i.e. one that specializes routines for given parameters. Will these tools also perform optimizations that might be possible if the specialization took place?

30 points by lelf 12y ago

userbinator 12y ago

The most prominent application of this can be summed up in one acronym: DRM.

sitkack 12y ago
It could also possibly make hacking Nginx a whole lot harder.
- astrange 12y ago
  It's not really good for that, unless you want to prevent someone from understanding their own nginx binary. Undefined behavior remains undefined behavior, and you could arm against overflows more easily with just -fstack-protector or even ubsan.
azakai 12y ago
I'm not sure why DRM would be more prominent than other applications? Software diversification is a big topic right now, in the hopes it can make all software more secure. That could help virtual machines, network stacks, and really anything from web browsers to entire OSes.
- comex 12y ago
  Tigress is labeled as an "obfuscator" that forces people to "crack, and re-crack, the code", for "software protection" from the owner of an "untrusted remote site" [i.e. you on your computer] - its main purpose is to prevent people who already have full access to the binaries from understanding them. This is somewhat related to the type of benign diversification that mitigates exploitation - preventing code that has limited access to the system from pumping the weird machine correctly - but, I think, not much. Many techniques required for the first are useless for the second: if everything is open source, or even if it's not and the attacker is smart enough (unlike most protection measures which are supposed to be independent of intelligence...), then measures implemented by this tool like 'virtualization' (i.e. indirecting execution through an interpreter), branch obfuscation, etc. can be undone easily by an attacker with full access to memory; if the attacker doesn't have full access, there are much simpler and more performant types of randomization that are equally good at defeating them. And measures useful for the second (generally, anything that involves multiple variations of the same version of a program, to force exploiters to learn which one is in use) are no good against the first (since the attacker can just pick one to extract secrets from).
- hyc_symas 12y ago
  This doesn't make existing code more robust. It only makes it orders of magnitude bigger and slower. Nobody will voluntarily run browsers, network stacks, or OSes built with these techniques, it would set your compute performance back 4 decades at least. As an example, in Adobe's RTMPE (encrypted RTMP) protocol, the type 8 encrypted handshake used an obfuscated crypto routine that comprised 95KB of x86 object code, taking billions of machine cycles to execute. After de-obfuscation it was found to simply be XTEA, which is implemented now in rtmpdump in only 4 lines of C code and executes in hundreds of machine cycles.
tptacek 12y ago
That is correct. The author of this tool is an expert in that field, too; his book (Surreptitious Software) is solid. I'm not sure what the subtext of your comment is, though. If it's "software like this is bad because it enables DRM", that's an odd position to take. If you don't want to obfuscate your code, don't run this transformer on it.
- userbinator 12y ago
  I would never use such a tool on my software; the concern is that others will - especially malware authors, who have been obfuscating their creations for as long as malware has existed. Executable packers/encrypters already significantly frustrate analysis by security researchers and antivirus programs; more powerful obfuscation/diversification tools only make it harder to distinguish between benign and malicious software. Obfuscation makes even legal reverse-engineering (as defined by the DMCA) difficult, meaning that threats like backdoors could become harder to discover. Amusingly enough, the definition of surreptitious that Google gives is quite relevant here: "kept secret, especially because it would not be approved of." I wonder if these people who are pro-DRM ever find themselves in a situation where the systems they create are used against them, and reconsider the effects of their work.
  - tptacek 12y ago
    Tools like these show us what's possible (actually, as Collberg points out, this particular tool is more like training for learning what's possible; the frontier of this approach to software protection is way past it). This is science. It is weird to object to it. Should we instead pretend that it's not possible to effectively obfuscate code?

marktangotango 12y ago

TIL (today I learned): It appears a 'diversifying C virtualizer' is an application that takes C source code, compiles it to an AST and transforms it to bytecode, and inserts a bytecode interpreter in place of the function. It can generate many different such bytecode/interpreter representations of a function, thus making it more of a challenge for crackers.

tptacek 12y ago
That same approach, obviously, works for lots of different languages. Not just C. You can even do it at the level of raw algorithms, transforming (for instance) a block cipher implementation that accepts a key as a parameter into one specialized on a specific key and from which the key is (H)ard to extract.
- v0i0-0 12y ago
  Could you maybe point me to such one tool, i.e. one that specializes routines for given parameters. Will these tools also perform optimizations that might be possible if the specialization took place?