Hi Jeremy (and Ken), Obfuscation of Java bytecode (like other "machine-level" instruction sets) will ultimately depend on what level of hiding is being done. Principally, whether you're really just scattering the data (i.e. using a secret scatter algorithm), or actually encrypt/decrypting it, it then moves the problem to being one of
secure key gen/storage/usage. My company - Cloakware - is firmly planted in the "software protection" field, focusing on hardening of Digital Rights Management and other content and IP protection system, for our customers. We have IP in the area of secure key storage, called "White Box Crypto", which solves the probem well for normal (read: all but the intel-grade needs). We use a variety of techniques - currently in C and C++, and will be extending that to include Java shortly. The techniques have varying impacts on code-size and/or performance-preserving, with associated tradeoffs against security level/strength of mechanism. As you point out - if the goal is to hide the data and/or implementation at runtime, then traditional support can be a problem. Stack traces - if you can get them from within an "anti-debug" enabled application or driver, may tell you very little (by design). I do know of one "obfuscator" that also has a free downloadable "anti-obfuscator" tool available so that customers can debug their applications. Make me wonder, what they were thinking... that attackers wouldn't notice? Let me know if you'd like to be part of the discussion as our Java work rolls out, and I'll set up a briefing. Hoping this is an "acceptably tasteful" posting from a vendor... :) Regards, - James James W. Stibbards Director, Systems Engineering Cloakware Federal "secure software ... from the inside out" 703.752.4836 office 571.232.7210 cell Previous message: ---------------------------------------------------------------------------- ---- Jeremy Epstein jeremy.epstein at webmethods.com Thu Dec 15 10:00:38 EST 2005 Ken, I looked into this a couple of years ago to protect against intellectual property theft (e.g., reverse engineering) and to make it harder to bypass software licensing techniques. My conclusion at that point was that the obfuscation didn't actually do much good (it was still fairly easy to figure out what was going on). It introduced an extra risky step - our developers want to do their debugging/QA on unobfuscated versions so they can figure out what goes wrong, but you then have to replicate all of your QA on the obfuscated version to make sure that the obfuscator didn't break anything. [I hope that no one would test one version and release another!] And if there was a discrepancy, it was likely to be difficult to find what went wrong. Most importantly for us, it made support a royal pain - stack traces no longer meant anything. And we had to be *very* careful not to obfuscate any published or undocumented-but-known interfaces. My conclusion is that it's better than just marketing hooey - there is some technical advantage - but that if you have an extensible product and/or you have to provide support, the pain is worse than the advantage. --Jeremy _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
