Java code obfuscation

[Matthew Zimmer]

Hey all,
I'm looking at using a tool to obfuscate some java code and have a 3
part question:

1. If price were not a factor, what obfuscator would you use?
2. If price were a factor and you wanted a midrange cost product (say
under $500) what obfuscator would you use?
3. If you wanted a free obfuscator which one would you use?

Something of note about my product is that there is a fair amount of
reflection going on as I do a lot of dynamic class loading. I've played
around with RetroGuard, and while it's nice, the script creation looks
like it will be quite painful with the amount of reflection I'm going to
have to work with. Anyway, I'd appreciate any thoughts you might have.

Thanks.
Matthew Zimmer

 

[nos]

Hey all,
I'm looking at using a tool to obfuscate some java code and have a 3
part question:

1. If price were not a factor, what obfuscator would you use?
2. If price were a factor and you wanted a midrange cost product (say
under $500) what obfuscator would you use?
3. If you wanted a free obfuscator which one would you use?

Something of note about my product is that there is a fair amount of
reflection going on as I do a lot of dynamic class loading. I've played
around with RetroGuard, and while it's nice, the script creation looks
like it will be quite painful with the amount of reflection I'm going to
have to work with. Anyway, I'd appreciate any thoughts you might have.

Thanks.
Matthew Zimmer

why do you think you need to obfuscate?

 

[Matthew Zimmer]

why do you think you need to obfuscate?

Well, the product is for my company and a lot of man hours have been
spent on this code. My company has decided that it would be better to
reduce the ease of which our code can be decompiled and the only way I
know of to do that is obfuscation. If there is a better way I'd love to
hear it!

 

[Andrew Thompson]

....
Well, the product is for my company and a lot of man hours have been
spent on this code. My company has decided that it would be better to
reduce the ease of which our code can be decompiled and the only way I
know of to do that is obfuscation. If there is a better way I'd love
to hear it!

http://mindprod.com/unmain.html ?

 

[Matthew Zimmer]

http://mindprod.com/unmain.html ?

--
Andrew Thompson
* http://www.PhySci.org/ Open-source software suite
* http://www.PhySci.org/codes/ Web & IT Help
* http://www.1point1C.org/ Science & Technology

LOL...well, while that would help, I don't personally want to go back
and change all of our nicely written and fairly clean code (with the
exception of the reflection which I personally fought against but lost
the battle to somebody who thought it made the code cleaner *sigh*) to
follow those rules. However, in future projects I'll make sure that I
follow all those rules.

 

[Andrew Thompson]

....
LOL...

Since you have demonstrated you have
a sense of humour* Matthew, I will point
you to another of Roedy's fine pages,
this one actually more ..on topic.

http://mindprod.com/jgloss/obfuscator.html#OBFUSCATOR
(shrugs) As an open-source freeware coder,
I have never tried any of them, but you may
get some pointers there.

* A quality that is demonstrably absent
from a lot of posters!

HTH

 

[Matthew Zimmer]

Since you have demonstrated you have
a sense of humour* Matthew, I will point
you to another of Roedy's fine pages,
this one actually more ..on topic.

http://mindprod.com/jgloss/obfuscator.html#OBFUSCATOR
(shrugs) As an open-source freeware coder,
I have never tried any of them, but you may
get some pointers there.

* A quality that is demonstrably absent
from a lot of posters!

HTH

--
Andrew Thompson
* http://www.PhySci.org/ Open-source software suite
* http://www.PhySci.org/codes/ Web & IT Help
* http://www.1point1C.org/ Science & Technology

Thanks Andrew,
there were several obfuscators on that page that my yahoo/google search
didn't turn up on the first several pages. I think the most interesting
point on it though was that there really is no point to the whole
obfuscating. Of course, convincing the powers that be about that is
unlikely.

I do, however, have to argue with one particular word that you used in
your post. You said that humour is "A quality that is demonstrably
absent from a lot of posters!" I would suggest that in the future you
change the word "posters" to "people" as it's a little more accurate and
I don't view it as fair to shortchange all the humorless people out
there who don't have usenet access.

Anyway, thanks again.
Matthew

 

[Andrew Thompson]

Andrew Thompson wrote: (humour) ....
I do, however, have to argue with one particular word that you used in
your post. You said that humour is "A quality that is demonstrably
absent from a lot of posters!" I would suggest that in the future you
change the word "posters" to "people" as it's a little more accurate
and I don't view it as fair to shortchange all the humorless people
out there who don't have usenet access.

Oh, p-e-o-p-l-e (wracks memory),
.....yeahhhh. Good point.
Maybe I need to get out more. ;-)

 

[Tony Morris]

I think the most interesting

point on it though was that there really is no point to the whole
obfuscating.

You're spot on there.

<insert-dry-sense-of-humour-here>
jus' kiddin'

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Michael Scovetta]

IMHO, Java obfuscation is easily defeated, and is a poor practice to
rely on to protect intellectual property. Even if bytecode-level
obfuscation craps out most decompilers, that only means that we're
waiting for a better decompiler. I would be curious to see an
obfuscator that can create code that the JVM can decode but a
decompiler cannot.

Instead, consider either (a) fully compiling your product to binary
(system-dependent)-- Most apps run on one system, so this isn't a big
problem. Obfuscating binaries is more effective than Java bytecode, or
(b) re-thinking your process-- why are you preventing your clients
from viewing your product source code? Is this security through
obscurity? Are you using patented algorithms and the such that you
don't want getting out? I assume that you only really need to protect
1% or something. Use JNI in that case, and call the DLL/so.

-Mike Scovetta

 

[Mickey Segal]

I think the most interesting point on it though was that
there really is no point to the whole obfuscating.

I thought there were two benefits to obfuscation that were widely accepted:
1. Obfuscation replaces informative names with uninformative names, making
your code harder to follow than it was previously.
2. By doing so obfuscation makes your code smaller.

Are these wrong, or just felt to be minor points?

 

[NOBODY]

1-retroguard
2-retroguard
3-retroguard

And obfuscation can replace class bytecode constant pool identifiers
with any unicode string (including numbers and other normally illegal
chars).

Unless a decompiler can create legal identifier for those, it still
can't expose the meaning of the code.... People at this level of
expertise would better interpret bytecode directly with javap...

Tell me what this does...

void a(b a1) {
(new c(a1)).d(this);
}





(e-mail address removed) (Michael Scovetta) wrote in

 

[nos]

1-retroguard
2-retroguard
3-retroguard

And obfuscation can replace class bytecode constant pool identifiers
with any unicode string (including numbers and other normally illegal
chars).

Unless a decompiler can create legal identifier for those, it still
can't expose the meaning of the code.... People at this level of
expertise would better interpret bytecode directly with javap...

Tell me what this does...

void a(b a1) {
(new c(a1)).d(this);
}

it prints the message "don't top post"

 

[Tim Tyler]

I thought there were two benefits to obfuscation that were widely accepted:

1. Obfuscation replaces informative names with uninformative names, making
your code harder to follow than it was previously.
2. By doing so obfuscation makes your code smaller.

Are these wrong, or just felt to be minor points?

If you want point 2, code shrinkers are there to shrink code.

Making code harder to understand is a goal which can conflict with
the aim of maximally shrinking the code - since it can involves things
like inserting code to mangle strings - and adding confusing bits of
pointless dead code that just get in the way.

 

[Tony Dahlman]

[snip]

it prints the message "don't top post"

Who wrote this?

(e-mail address removed) (Michael Scovetta) wrote in

IMHO, Java obfuscation is easily defeated, and is a poor practice to
rely on to protect intellectual property. Even if bytecode-level
obfuscation craps out most decompilers, that only means that we're
waiting for a better decompiler. I would be curious to see an
obfuscator that can create code that the JVM can decode but a
decompiler cannot.

Instead, consider either (a) fully compiling your product to binary
(system-dependent)-- Most apps run on one system, so this isn't a big
problem. Obfuscating binaries is more effective than Java bytecode, or
(b) re-thinking your process-- why are you preventing your clients
from viewing your product source code? Is this security through
obscurity? Are you using patented algorithms and the such that you
don't want getting out? I assume that you only really need to protect
1% or something. Use JNI in that case, and call the DLL/so.

-Mike Scovetta

[snip]
Thanks.
Matthew Zimmer

All flaming on top-posting aside, I think Michael has this one right on.

Java has this weakness--that people can steal your code. Not only that
but WORA has not, nor can it be, achieved at present. Rather Bill Joy's
glib comment applies, "Write once, debug everywhere." (AFI can remember)

So Michael has it right. Still WORA applies because the same code can
run on multiple platforms, but a vendor has the resposibility to lab-test
her/his code on all the platforms he/she may want to sell to.

Still, as pointed out but not as clearly, there will always be someone,
somewhere, who will take the time (if warranted) to steal your code. And
that, damn-it-all, is the reason we still need lawyers.

Meanwhile, maybe someday Microsoft will realize that "hide your code from
hackers" is *not* a security measure. It's just denial.

Regards, Tony Dahlman

 

[nos]

[snip]

it prints the message "don't top post"

Who wrote this?

(e-mail address removed) (Michael Scovetta) wrote in

IMHO, Java obfuscation is easily defeated, and is a poor practice to
rely on to protect intellectual property. Even if bytecode-level
obfuscation craps out most decompilers, that only means that we're
waiting for a better decompiler. I would be curious to see an
obfuscator that can create code that the JVM can decode but a
decompiler cannot.

Instead, consider either (a) fully compiling your product to binary
(system-dependent)-- Most apps run on one system, so this isn't a big
problem. Obfuscating binaries is more effective than Java bytecode, or
(b) re-thinking your process-- why are you preventing your clients
from viewing your product source code? Is this security through
obscurity? Are you using patented algorithms and the such that you
don't want getting out? I assume that you only really need to protect
1% or something. Use JNI in that case, and call the DLL/so.

-Mike Scovetta

[snip]
Thanks.
Matthew Zimmer

All flaming on top-posting aside, I think Michael has this one right on.

Java has this weakness--that people can steal your code. Not only that
but WORA has not, nor can it be, achieved at present. Rather Bill Joy's
glib comment applies, "Write once, debug everywhere." (AFI can remember)

So Michael has it right. Still WORA applies because the same code can
run on multiple platforms, but a vendor has the resposibility to lab-test
her/his code on all the platforms he/she may want to sell to.

Still, as pointed out but not as clearly, there will always be someone,
somewhere, who will take the time (if warranted) to steal your code. And
that, damn-it-all, is the reason we still need lawyers.

Meanwhile, maybe someday Microsoft will realize that "hide your code from
hackers" is *not* a security measure. It's just denial.

Regards, Tony Dahlman

last job I had we gave the source code to the customer along
with all the other stuff --> licensing

 

[beagle]

last job I had we gave the source code to the customer along
with all the other stuff --> licensing

Which is sometimes reasonable, and sometimes not reasonable.