How easy is it to reverse engineer a java program?

[C. Gardiner]

Hi,

I am principally a free-lance hardware designer, but when I work for
customers I often write utilities for automating various tedious parts
of the design flow. (I used to do this in perl, but in some cases Java
proves more portable and always has the XML libraries available, which
is not the case at all my customer sites with perl)

In mixed design-teams (customers people + me) I often get the request to
leave the (compiled) utilities behind when the contract is finished.
What I would like to do is hard-program them to one of
- the customers network
- a customer host
- a customer userid

If I do this, how easy is it for my competitors to reverse engineer
(e.g. disassemble) the compiled utilites, patch out the hard-programmed
locking mechanism and reuse them for their customers. If for instance I
am comparing strings in the lock mechanism, is it easy to find the
compare instructions, patch the code to always return true or to replace
the code sections by NOPs etc.

We're not talking about rocket science here, so I am more interested in
a practical deterent mechanism than in some complex security. I'm
assuming that my customers and free-lance competitors don't have weeks
at their disposal that would make the reverse-engineering cost effective.

Thanks for any input,
Charles

 

[jan V]

What I would like to do is hard-program them to one of

- the customers network
- a customer host
- a customer userid

If I do this, how easy is it for my competitors to reverse engineer
(e.g. disassemble) the compiled utilites, patch out the hard-programmed
locking mechanism and reuse them for their customers.

You can use a program like ProGuard to obfuscate "the hell" out of the
classes. ProGuard is free and is used by some commercial firms to give a
degree of protection to their IP.

I would give you another piece of advice: ensure that your contracts include
a non-reverse engineering clause WITH SUBSTANTIAL FINANCIAL PENALTY IF
BROKEN (sorry for shouting ;-).

Your multi-prongued IP-protection approach would then be:

- ensure every tool has a unique customer-dependent signature which can be
reconstituted EVEN IF your customer hacks the tool to bypass your copy
protection scheme (sprinkle your binaries with a whole bunch of unique
512-bit patterns, that should do the trick !!)

- contractual clauses

- some way of detecting when your customer has breached your contract on the
copy protection issue

- legal action to force customer to pay contractual penalty for breaching IP
protection

[BTW, taking legal action is a huge step, and will be very costly, both
financially and time-wise.. that's why the contractual financial penalty has
to be substantial to make the exercise worth the pain and time!]

If your customer isn't prepared to sign a contract with a financial penalty
clause for breach of IP rights, then maybe you should consider not dealing
with such people.....

 

[C. Gardiner]

Hi Jan,

thanks for the tip about ProGuard. I'll take a look at it.

On your other points, it's not so much my customers I'm worried about.
They are usually satisfied and let me come back. The bigger issue for me
is other consultants working for the same customers. What I really want
to discourage is my competitors taking my java utilities to other
customers for which I have never worked.

My general approach to my IP is that a customer can have it and use at
will (except for redistribution). I would of course like to know if my
larger customers pass the utilities around to other departments/groups
but also here, as long as I know who is using the stuff I really don't mind.

So what my original question boils down to is:
Can programs like javap etc. be used to help in easily removing any
security features I put in or is the effort here too high for somebody
who has more important things to do. (i.e. doesn't have weeks at his
disposal for putting all his effort into reverse engineering)

Thanks agin for your input,
Charles

 

[Monique Y. Mudama]

If I do this, how easy is it for my competitors to reverse engineer
(e.g. disassemble) the compiled utilites, patch out the
hard-programmed locking mechanism and reuse them for their
customers.

Well, there's jad:

http://kpdus.tripod.com/jad.html

Of course the result doesn't have pretty variable names or anything, but
I suppose that a determined individual could work it out.

 

[IchBin]

Well, there's jad:

http://kpdus.tripod.com/jad.html

Of course the result doesn't have pretty variable names or anything, but
I suppose that a determined individual could work it out.

I use 'FrontEnd Plus' which will use jad.
http://shareware.pcmag.com/product.php[id]61887[SiteID]pcmag

Here is an article for Java Decompilers
http://www.program-transformation.org/Transform/JavaDecompilers

Here is an article for Java Decompiler Tests
http://www.program-transformation.org/Transform/JavaDecompilerTests

--


Thanks in Advance...
IchBin, Pocono Lake, Pa, USA http://weconsultants.servebeer.com
__________________________________________________________________________

' If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor, Regular Guy (1952-)

 

[Roedy Green]

If I do this, how easy is it for my competitors to reverse engineer
(e.g. disassemble) the compiled utilites, patch out the hard-programmed
locking mechanism and reuse them for their customers.

very easy.

See http://mindprod.com/jgloss/decompiler.html
http://mindprod.com/jgloss/disassembler.html
http://mindprod.com/jgloss/obfuscator.html

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[George Cherry]

See http://mindprod.com/jgloss/decompiler.html
http://mindprod.com/jgloss/disassembler.html
http://mindprod.com/jgloss/obfuscator.html

Thanks for the links to decompiler sources. Does it bother
you that the outputs from the DJ Java Decompiler cannot
be compiled? For example, if one decompiles a Java class
that uses enum, you can't compile the Java code. Right off the
bat you're nixed by the compiler because the decompiled
code explicitly extends Enum. There are numerous other
no-no's in the decompiled code. The decompiled code looks
VASTLY different from the original Java source. It appears
that the Java compiler has very different rules for itself and
for us. It's illuminating (if troubling to me) to peruse the
decompiled code and compare it to the original Java code.

My, you're busy nowadays. Are you taking bupropion?

George W. Cherry

 

[steve]

Thanks for the links to decompiler sources. Does it bother
you that the outputs from the DJ Java Decompiler cannot
be compiled? For example, if one decompiles a Java class
that uses enum, you can't compile the Java code. Right off the
bat you're nixed by the compiler because the decompiled
code explicitly extends Enum. There are numerous other
no-no's in the decompiled code. The decompiled code looks
VASTLY different from the original Java source. It appears
that the Java compiler has very different rules for itself and
for us. It's illuminating (if troubling to me) to peruse the
decompiled code and compare it to the original Java code.

My, you're busy nowadays. Are you taking bupropion?

George W. Cherry

decompiling , does not give that much away., and in most cases it is not
worth the time in taking the code apart.
even for cracking, it does not work reliably.

 

[Roedy Green]

Thanks for the links to decompiler sources. Does it bother
you that the outputs from the DJ Java Decompiler cannot
be compiled? For example, if one decompiles a Java class
that uses enum, you can't compile the Java code. Right off the
bat you're nixed by the compiler because the decompiled
code explicitly extends Enum. There are numerous other
no-no's in the decompiled code

The sort of people who like decompiling, those sort of touch ups are a
minor inconvenience. They are primarily after small bits of
information about your program to change or steal a small piece of it.
They will leave the bulk of it alone.

They don't need source to modify even one class.

You can patch a class file.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[C. Gardiner]

Thanks to everybody who replied to my question.
It has been very informative.

Regards,
Charles

 

[.]

Hi Jan,

thanks for the tip about ProGuard. I'll take a look at it.

On your other points, it's not so much my customers I'm worried about.
They are usually satisfied and let me come back. The bigger issue for me
is other consultants working for the same customers. What I really want
to discourage is my competitors taking my java utilities to other
customers for which I have never worked.

My general approach to my IP is that a customer can have it and use at
will (except for redistribution). I would of course like to know if my
larger customers pass the utilities around to other departments/groups
but also here, as long as I know who is using the stuff I really don't mind.

So what my original question boils down to is:
Can programs like javap etc. be used to help in easily removing any
security features I put in or is the effort here too high for somebody
who has more important things to do. (i.e. doesn't have weeks at his
disposal for putting all his effort into reverse engineering)

Charles,

As someone who started life as a machine language programmer and worked my
way up to assembly then C language I know what you are thinking. When I
write an assembly language or C language application, reverse engineering
it to source code, editing the code then re-compiling is harder then just
disassembling the machine code and replacing a BRA, JMP or JSR (depending
on the architecture) with some NOPs. To muck people up I'll check multiple
places using a macro to inline the code rather than make it a function
call.

In Java the mindset is very different. The first thing people will do is
using JAD to decompile the code. If I don't run my code through something
like ProGuard, I can run the *.class file through JAD and it will
decompile it to EXACTLY the code I originally created. The only thing
missing will be the comments. The variable names will be identical to the
original source code. Scary.

You can deter 90% of the Java programmers by just using a program
obfuscator. The last 10% might be a little more determined. Probably 7%
will run the code through JAD and try to figure out the section of code
they want to remove. With good debugging skills they might even be able
to. I usually decompile the code after obfuscating it. If it is hard for
me to find then I know it will be hard for someone else to find.

Something else you might want to try is making a call to a native library
at random points.

The last 3% just know too much. They'll see it as a challenge and crack it
regardless. Most likely you don't have to worry about them.

 

[Thomas Hawtin]

On Sat, 30 Jul 2005, C. Gardiner wrote:

missing will be the comments. The variable names will be identical to the
original source code. Scary.

-g:none will sort that out.

Tom Hawtin

 

[Tim Tyler]

Thanks for the links to decompiler sources. Does it bother
you that the outputs from the DJ Java Decompiler cannot
be compiled? For example, if one decompiles a Java class
that uses enum, you can't compile the Java code. Right off the
bat you're nixed by the compiler because the decompiled
code explicitly extends Enum.

It sounds like a pre-Java-1.5 decompiler.