

Ask HN: To obfuscate or not to obfuscate Java bytecode? - cwg

What is your take on bytecode obfuscation, specifically obfuscating a Java / Swing app that will have a trial version publicly available for download?<p>I know that obfuscation is not 'safe', and that there's always a way to decompile Java bytecode. But still, I have the feeling that I should do something to discourage enterprising users to decompile our code.<p>I have experimented with some Java bytecode obfuscators, and for whatever reason, they make the end result crash a lot. Now, I could probably dive into the inner workings of these obfuscators and somehow make it work, but it got me thinking: Does obfuscation actually make sense?<p>My thinking is that decompilation would be interesting to two groups of people: Those who want to crack the licensing mechanism, and the competition.<p>For the first group, I know there's probably nothing that will stop them. I have other means in place to discourage casual piracy, but I know there's no absolute security, and I don't plan to enforce that strictly (for the cost of unnerving paying users).<p>For the second group, my hunch is that it probably doesn't matter as well. If competitors can gain an advantage by looking at my (decompiled) source code, probably my business model is not robust enough, and I should rather be outperforming them, and stay ahead of the game.<p>What is your take on obfuscation? Does it make sense, and when so?<p>All your input is very appreciated!<p>Some background: We are working on a desktop application developed in Java / Swing, which is geared towards the enterprise market. Since the potential market is quite large and diverse, we want to make our app available as a trial version for download from our website.
======
nostrademons
I think the goal of obfuscation should be to keep honest people honest. In the
case of Java bytecode, I think they're _already_ honest. You don't see people
casually decompiling bytecode, because it's a royal PITA and the resulting
source is usually pretty unreadable anyway.

If someone really, really wants to reverse-engineer your object code, they'll
find a way to. If it's important to your business that they not...I'd find a
way to make it less important to your business.

------
barrkel
Obfuscation to protect source code, implementation details, etc. I believe is
very rarely warranted. Most applications have fairly mundane implementations,
with much of the differentiator being fit and finish of the whole. Even having
the source code directly, rather than having to disassemble it, wouldn't be a
huge risk IMO - any entity profiting from it will clearly be culpable of
copyright violation.

It's easy to get paranoid about the value of source code. The fact is, most
mature codebases are sufficiently scruffy that even their developers wouldn't
want to start from that codebase if they were to create a competitor. And when
you're not familiar with a body of source, it takes a lot of work to
understand its architecture and how it's put together; so then the risk is
even lower.

Obfuscation as a speedbump to cracking has more to say for it. If the
obfuscation badly affects stability, I'd suggest only using it for a handful
of core modules, code that lies on the critical path for most useful
application uses. Obviously, it's important that the code isn't something
trivial, like a boolean license check. It would have to be a module that would
be non-trivial to reimplement and re-link into the application.

But of course I'd suggest other things, like baking in some kind of internet
dependencies.

------
richardw
If you can get it working safely, I'd recommend obfuscating. It's easier to
remove it later than to add it when your full source is out in the wild.
Getting the genie back in the box is impossible.

Yes, some will find a way to get at it, but there is no reason to make it
stupidly easy for everyone else. Your competent competitors would probably
rather write their own code than sniff through obfuscated code, but they might
be quite happy to have your full source at hand when solving problems. Also,
very little is stopping someone from simply lifting your code, making a few
changes and releasing it as their own, for 10 bucks less than yours. It
happens, I assure you.

------
jim_lawless
As an alternative, you might consider writing some portion of your app in a
language that generates Java bytecode. Languages such as JRuby generate
bytecode that _currently_ cannot be fully decompiled.

This is a little different approach as the bytecode code isn't mangled as an
afterthought.

[http://jimlawless.wordpress.com/2010/03/07/jruby-as-a-
java-o...](http://jimlawless.wordpress.com/2010/03/07/jruby-as-a-java-
obfuscation-utility/)

------
dleskov
There are actually three ways other than obfustaction to protect your Java
bytecode. I humbly suggest that you check out my article "Protect Your Java
Code - Through Obfuscators And Beyond":

<http://www.excelsior-usa.com/articles/java-obfuscators.html>

