5 ms·

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 m

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

by azakai 12y ago

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.