Obfuscators

[carmelo]

Hi everybody,
I need to protect my java code, so I ask you: what do you think is the
best obfuscator?
Is it possible to integrate it into Eclipse or Netbeans?
Besides, I'd like to know if is it possible to obfuscate web
applications code.


Thank you very much for your help
Carmelo

 

[Andreas Leitgeb]

I need to protect my java code, ...

Best is to write code, that you need not be ashamed of

 

[Joshua Cranmer]

Hi everybody,
I need to protect my java code, so I ask you: what do you think is the
best obfuscator?
Is it possible to integrate it into Eclipse or Netbeans?
Besides, I'd like to know if is it possible to obfuscate web
applications code.

Obfuscation is not going to stop anyone who seriously wants to crack
your code.

If you really want to obfuscate, the compression practice of stripping
method names gets you closer. Throwing in some large, key class files
improves the odds of discovering undocumented features in decompilers.

Or you could be really wacky and make correct functioning reliant on the
new features in Java 5. I've yet to see a functioning decompiler that
can preserve annotations.

 

[tomaszewski.p]

Hi everybody,
I need to protect my java code, so I ask you: what do you think is the
best obfuscator?
Is it possible to integrate it into Eclipse or Netbeans?
Besides, I'd like to know if is it possible to obfuscate web
applications code.

Thank you very much for your help
Carmelo

Obfuscator does not give you 'protected' code, but makes it a little
bit harder to analyze only - it will not prevent your code against
cracking or deassembling.

Obfuscator can be used to reduce code size (it removes unused code and
attributes from class files) and in my opinion this is the way it
should be used.

I recommend ProGuard (http://proguard.sourceforge.net/). For sure it
can be integrated to Eclipse.

Przemek

 

[Daniel Pitts]

Hi everybody,
I need to protect my java code, so I ask you: what do you think is the
best obfuscator?
Is it possible to integrate it into Eclipse or Netbeans?
Besides, I'd like to know if is it possible to obfuscate web
applications code.


Thank you very much for your help
Carmelo

The *best* protection is copyright and a EULA.
There are plenty of existing threads on this newsgroup about
obfuscation, I suggest you do a Google search.

HTH,
Daniel.

 

[carmelo]

The *best* protection is copyright and a EULA.
There are plenty of existing threads on this newsgroup about
obfuscation, I suggest you do a Google search.

HTH,
Daniel.

Ok, but there is no method for making the reverse engineering of your
java code hard? I thought that a good obfuscator should do that...
Is there any way to protect a java code against who wants to crack it?

 

[tomaszewski.p]

Ok, but there is no method for making the reverse engineering of your
java code hard? I thought that a good obfuscator should do that...
Is there any way to protect a java code against who wants to crack it?

You may try to do some protections using ClassLoader such as dynamic
code change before runtime, etc. I am sure there are lots of tricks to
do such things.
But to make it clear: there is no way to fully protect your code
against reverse engineering, because there is at least one method to
do this: the one which is used by your protection engine.

Przemek

 

[tomaszewski.p]

Ok, but there is no method for making the reverse engineering of your
java code hard? I thought that a good obfuscator should do that...
Is there any way to protect a java code against who wants to crack it?

This obfuscator looks promising:
http://www.zelix.com/klassmaster

Przemek

 

[Silvio Bierman]

Ok, but there is no method for making the reverse engineering of your
java code hard? I thought that a good obfuscator should do that...
Is there any way to protect a java code against who wants to crack it?

That depends on what you want to protect. If it is the secret password
that protects your family jewels I would not count on obfuscation. If
you are shipping an application and you want to prevent people from
decompiling it to working and compilable Java code they can work with
themselves a good obfuscator can go a long way.

In contrast to what many people (want to make you) believe a smart
obfuscator can prevent current decompilers from generating compilable
Java code. It can do this by generating Java-source-invalid
class/method/variable names and reordering code in such a way that
current decompilers can not reproduce the correct Java construct
(for/while/if etc) that was used. I have seen most of them resort to
non-Java output containing named labels and goto instructions which are
of course part of the VM instruction set but not of the Java language.

Silvio

 

[Daniel Pitts]

Ok, but there is no method for making the reverse engineering of your
java code hard? I thought that a good obfuscator should do that...
Is there any way to protect a java code against who wants to crack it?

There are ways to make it "less convenient" to crack it, but no way to
make it impossible. That's where copyright and EULA come in, it doesn't
make it impossible either, but it does make it illegal and it gives you
legal recourse.

In either case, there is always a chance that someone, somewhere, will
reverse engineer your code and use it in ways you don't want. The only
safe code is unreleased code. If you can make it a client/server
application, than put your precious protected code on the server side,
and don't let anyone have access to it.

That approach may not be cost-effective for your needs, but it is the
only 100% safe solution.

 

[Daniel Pitts]

That depends on what you want to protect. If it is the secret password
that protects your family jewels I would not count on obfuscation. If
you are shipping an application and you want to prevent people from
decompiling it to working and compilable Java code they can work with
themselves a good obfuscator can go a long way.

In contrast to what many people (want to make you) believe a smart
obfuscator can prevent current decompilers from generating compilable
Java code. It can do this by generating Java-source-invalid
class/method/variable names and reordering code in such a way that
current decompilers can not reproduce the correct Java construct
(for/while/if etc) that was used. I have seen most of them resort to
non-Java output containing named labels and goto instructions which are
of course part of the VM instruction set but not of the Java language.

Silvio

That doesn't mean that the code can't be reverse engineered, only that
it is more difficult. There may be no out-of-the-box reverse obfuscation
programs, but they could be written, or it could be done by hand.
Obfuscation is like a chain-link fence. It'll keep the rabble out, but
not a determined trespasser.

 

[bbound]

There are ways to make it "less convenient" to crack it, but no way to
make it impossible.  That's where copyright and EULA come in, it doesn't
make it impossible either, but it does make it illegal and it gives you
legal recourse.

Actually, reverse engineering is fair use. Releasing derivative works
might infringe, but the mere act of reverse engineering does not, and
the creation of interoperable tools does not (witness OpenOffice's
support for .doc format, which Microsoft surely doesn't like). There's
*one* execrable legal decision to the contrary, but that's the US
court system for you.

Regardless, you need to decide what you really want to "protect". Most
likely, it's a business model. A business model that does not rely on
nobody cracking your code is a much more reliable business model. Red
Hat has employed such a business model to great success, and there are
others.

 

[Silvio Bierman]

That doesn't mean that the code can't be reverse engineered, only that
it is more difficult. There may be no out-of-the-box reverse obfuscation
programs, but they could be written, or it could be done by hand.
Obfuscation is like a chain-link fence. It'll keep the rabble out, but
not a determined trespasser.

Locking your door at night does not by definition keep out any intruder,
surely not a determined trespasser. We lock it anyway.

I keep hearing "it is not waterproof" as an argument for not obfuscating
Java code. Just as with locking doors it is all about the effort to
break the security versus the reward once it is broken. Obfuscation can
tip the scale in this equation. No more, no less.

Silvio

 

[bbound]

Locking your door at night does not by definition keep out any intruder,
surely not a determined trespasser. We lock it anyway.

A very poor analogy. If someone breaks into your home they might
attack you, trash or take your stuff, or whatever.

If someone decompiles your code, they might what -- improve on it?
Make an interoperable product? Oh, the horror!

It's not like they can mess up your own copy of your code. (On the
other hand, if yours ever goes get lost or messed up somehow, they
might be able to provide you with a good copy!)

 

[carmelo]

Locking your door at night does not by definition keep out any intruder,
surely not a determined trespasser. We lock it anyway.

I keep hearing "it is not waterproof" as an argument for not obfuscating
Java code. Just as with locking doors it is all about the effort to
break the security versus the reward once it is broken. Obfuscation can
tip the scale in this equation. No more, no less.

Silvio

Silvio, so do you think that obfuscation is a good way to protect
against decompiling your (java) work?
If you're working on an open source project then there's not this
need, but for commercial purposes I think you have to protect the code
against easy "ripping" or copying, EULA is not enough... With compiled
languages you don't have this need, so copyright and EULA are enough...

 

[bbound]

Silvio, so do you think that obfuscation is a good way to protect
against decompiling your (java) work?

The real question is what preventing decompiling "protects" against.

If you're working on an open source project then there's not this
need, but for commercial purposes I think you have to protect the code

Nonsense. Red Hat does not feel the need to do so, not even "for
commercial purposes", and they've proven to be reasonably profitable.

You just need to pick a business model that does not fall to pieces
the instant you have real competition.

Which is easier, trying with great effort and probably eventual
failure to "bring the mountain to Mohammad", or going to the freaking
mountain?

 

[Roedy Green]

Hi everybody,
I need to protect my java code, so I ask you: what do you think is the
best obfuscator?
Is it possible to integrate it into Eclipse or Netbeans?
Besides, I'd like to know if is it possible to obfuscate web
applications code.


Thank you very much for your help
Carmelo

see http://mindprod.com/jgloss/obfuscator.html

I don't think any of the class file scramblers will do much to deter a
hacker. Native highly optimised compilation will though.

 

[carmelo]

Java is a compiled language.  Other compiled languages, like C, C++ and C#,
can also be decompiled.

Java is not a compiled language, it's an interpreted language!
Otherwise, what is the purpose of having a Java Virtual Machine??
With C and C++ compiled code it's not possible to decompile into
source code, you can decompile to ASM, which is really different from
having the source code (as you can with java)...

 

[RedGrittyBrick]

Java is not a compiled language, it's an interpreted language!
Otherwise, what is the purpose of having a Java Virtual Machine??

What is the purpose of javac?
What does JIT stand for?
What is Excelsior Jet?
(http://www.excelsior-usa.com/articles/java-to-exe.html)

With C and C++ compiled code it's not possible to decompile into
source code,

"The dcc decompiler decompiles .exe files from the (i386, DOS) platform
to C programs." -- From 1st item found by google for "decompile c"

 

[Joshua Cranmer]

Java is not a compiled language, it's an interpreted language!
> Otherwise, what is the purpose of having a Java Virtual Machine??

Java is compiled to a bytecode, which is then interpreted. It's nothing
terribly different from compiling something to, say, a MMIX binary and
then running that on an emulator.

With C and C++ compiled code it's not possible to decompile into
source code, you can decompile to ASM, which is really different from
having the source code (as you can with java)...

Blatant and utter BS. I have decompiled C++ by hand, and C decompilers
are starting to approach Java decompilers in terms of correctness. See
Hex Rays if you want an example.

Besides, to quote Ilfak Guilfanov, "C is portable assembly."