Re: About jobfuscate

On Jan 4, 3:47 pm, Mark Space <marksp...@xxxxxxxxxxxxxx> wrote:
It is nevertheless humorously appropriate in this case. The OP may be
unaware that obfuscation isn't going to provide much benefit.

That was exactly my point. Obfuscators (and also copy protection) are
snake oil. Any kind of expensive cryptography or similarly that relies
on security through obscurity (including any that put the decryption
keys on untrusted systems but try to hide them from those systems'
administrators, including in turn every form of copy protection known
to Man) is snake oil and not worth so much as one lousy thin dime or
moment of your time, nevermind whatever's actually being charged for
it.

Obfuscation is, essentially, weak encryption. Copy protection (or
using *real* encryption on the binary and an obfuscated stub that
decrypts it, which is a stronger form of obfuscation) is stronger
encryption but leaves a decryption key in the hands of every would-be
attacker, albeit hidden or obfuscated in some manner. It only takes
one to manage to decrypt and crack your app and upload it to p2p and
warez sites and free copies are out there and easy for anyone else to
download and install, so it doesn't matter if Joe Average can't crack
it; Joe Average *can* use Limewire and someone else *can* both crack
it *and* use Limewire. And sooner or later, someone will, unless your
product is so obscure that your main problem is low volume. In that
case, free copies will, through network effects, actually raise sales
volume anyway, and right when you want it least your copy protection
suddenly is actually effective! Ouch.

Crypto that relies on secrecy of the algorithm is similarly snake oil.
The MPAA found this out to their chagrin when the CSS* copy-protection
emperor was discovered to be devoid of clothing a decade or so ago.
The same mistake keeps being repeated over and over in computing
history though, with the odd prominent case (a vulnerable e-voting
machine here, some ATMs being hacked there...) or high-profile
individual leak of supposedly-secure data and a constant low-grade
churn of instances that go unnoticed. AES, Blowfish, and the
asymmetric ciphers used to encode symmetric session keys for things
like SSL are all you really need (with a big enough key size; stay
away from 56-bit DES, which is dead).

Of course, some entities just don't learn. The MPAA learned a little
after the CSS debacle and relied on stronger crypto with their HD-DVD
AACS encryption. Too bad they forgot that copy protection is
invariably essentially DOA anyway because it puts the keys in the
hands of the untrusted parties. AACS has, predictably, been cracked
wide open, and all their fancy key-revocation nonsense did was make it
need cracking every few months instead of just once. :P

* Check out http://en.wikipedia.org/wiki/Content_Scramble_System --
just the phrase "proprietary 40-bit stream cipher" is sufficient to
give any security expert the willies, and enable him to accurately
guess its current essentially-defunct status at the same time, if it
weren't that any security expert worthy of the title already knows
what CSS is and what happened to it. CSS got pretty much *everything*
wrong, since it a) was copy protection and thus gave potential
attackers the decryption keys, b) had fewer bits than even DES, and c)
had a proprietary algorithm ALL AT THE SAME TIME. :P And millions of
dollars were wasted on this boondoggle, and again on its successor
AACS which made at least the first of the three mistakes all over
again and likewise was rapidly cracked.
.

Relevant Pages

  • Re: make entire exe private
    ... to reverse engineer IP and the need to put important IP on a server. ... Your IP already has legal protection in the form of copyright and, if you play your cards right, patent protection as well. ... At the very least, you are setting yourself up for a lot of extra work, as _all_ of your testing will need to be done on the obfuscated release of the program, and any anomalous behavior that occurs will require that you not only debug your own code, but that of the obfuscation system you're using. ... And of course, no matter what you do, there's always a chance that some serious bug will be induced by the obfuscation system that isn't noted until the program's been released and is in use by the customer. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: obfuscatorS & decompilers
    ... > obfuscation plus simple context flow graph obfuscation (like simple loops ... However it is possible to achieve protection even ... > opaque predicates and my call tree flattening scheme. ... > demonstration of a simpliest aspect of call tree transformation technique. ...
    (microsoft.public.dotnet.security)
  • Re: Copy protection for a .NET application
    ... cracking is just as simple on x86 code as it is with IL. ... obfuscation which is a big problem with the idea in general. ... > across .NET Framework Service packs. ... > environments protection is not strongly needed. ...
    (microsoft.public.dotnet.framework)
  • Re: Copy protection for a .NET application
    ... cracking is just as simple on x86 code as it is with IL. ... obfuscation which is a big problem with the idea in general. ... > across .NET Framework Service packs. ... > environments protection is not strongly needed. ...
    (microsoft.public.dotnet.general)
  • Re: Copy protection for a .NET application
    ... cracking is just as simple on x86 code as it is with IL. ... obfuscation which is a big problem with the idea in general. ... > across .NET Framework Service packs. ... > environments protection is not strongly needed. ...
    (microsoft.public.dotnet.languages.csharp)