Velocity Reviews > Java > JAR/Class-file de-compilation reverse engineering and IP protection

# JAR/Class-file de-compilation reverse engineering and IP protection

Richard Maher
Guest
Posts: n/a

 09-20-2009
Hi,

I appreciate that this has been discussed at length previously and there is
some useful stuff to be found on the net but can I please just ask someone
to confirm that there's not a whole lot one can do to stop an enthusiastic
(let alone dedicated) coder from converting a Java class file back to its
original source format?

My understanding (too strong a word here is that a custom class-loader
is probably the best bet but does anyone have a very simple example of one
of these, especially one that would not fall foul of the sandpit and other
requirements of an *unsigned* applet?

Are people routinely paying for "supported" obfuscators or rolling their
own? (And are they much of a deterrant and/or footprint-reduction impact in
the first place?)

Do you have examples of the quality of output one can produce from publicly
available de-compilers?

"All too hard", just rely on copyright protection and those companies who
might use it coughing up?

Cheers Richard Maher

Joshua Cranmer
Guest
Posts: n/a

 09-20-2009
On 09/19/2009 08:19 PM, Richard Maher wrote:
> My understanding (too strong a word here is that a custom class-loader
> is probably the best bet but does anyone have a very simple example of one
> of these, especially one that would not fall foul of the sandpit and other
> requirements of an *unsigned* applet?

One method I have demonstrated (or rather, I first saw demonstrated), is
to replace java.lang.ClassLoader with a slightly modified version,
namely one that dumps the bytecodes out passed through the bottleneck
defineClass methods. I first saw this method online somewhere, but I
really have no clue as to how to find it.

And, of course, once you have the bytecode, you can run all the
decompilers and other tools you want on it as if it were a regular
classpath.

> Are people routinely paying for "supported" obfuscators or rolling their
> own? (And are they much of a deterrant and/or footprint-reduction impact in
> the first place?)

Obfuscation, insomuch as the names are turned into stuff like `a',
probably has a footprint-reduction impact, but I don't have hard numbers.

In terms of a deterrent, it would probably provide little to an
experienced hacker. Indeed, experienced hackers can easily crack the
copy protection on many new games or reverse engineer the license key
sections--and this is native code, which is theoretically much harder to
crack than bytecode. So fully reproducing readable source code, even in
full obfuscation mode, should only take a few hours for a moderately
complex class.

> "All too hard", just rely on copyright protection and those companies who
> might use it coughing up?

The best defense is to keep as much logic off the client side as
possible. Outside of that, all you'd do is slow down somewhat those who
would try to break it. Of course, if people do attempt that, that
generally means that you're program's successful enough to attract the
cracking community.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Arne Vajhøj
Guest
Posts: n/a

 09-20-2009
Richard Maher wrote:
> I appreciate that this has been discussed at length previously and there is
> some useful stuff to be found on the net but can I please just ask someone
> to confirm that there's not a whole lot one can do to stop an enthusiastic
> (let alone dedicated) coder from converting a Java class file back to its
> original source format?
>
> My understanding (too strong a word here is that a custom class-loader
> is probably the best bet but does anyone have a very simple example of one
> of these, especially one that would not fall foul of the sandpit and other
> requirements of an *unsigned* applet?
>
> Are people routinely paying for "supported" obfuscators or rolling their
> own? (And are they much of a deterrant and/or footprint-reduction impact in
> the first place?)
>
> Do you have examples of the quality of output one can produce from publicly
> available de-compilers?
>
> "All too hard", just rely on copyright protection and those companies who
> might use it coughing up?

See below for an example.

I would not start messing around with a decrypting classloader.

Possible run an obfuscator like Proguard.

It ensure that the crackers actually have to do a little
bit of work.

And as a nice side effect it reduces the size of the
jar files a bit which is great for applets.

Arne

================================================

C:\>type Maher.java
public class Maher {
public static void main(String[] args) {
Richard r = new Richard();
r.dosomething();
}
}

class Richard {
public void dosomething() {
for(int i = 0; i < 3; i++) {
print();
}
}
private static void print() {
System.out.println("Ofuscation sucks");
}
}

C:\>javac Maher.java

C:\>java -cp . Maher
Ofuscation sucks
Ofuscation sucks
Ofuscation sucks

Parsing Maher.class...The class file version is 50.0 (only 45.3, 46.0
and 47.0 a
re supported)

// Decompiler options: packimports(3)
// Source File Name: Maher.java

public class Maher
{

public Maher()
{
}

public static void main(String args[])
{
Richard richard = new Richard();
richard.dosomething();
}
}

Parsing Richard.class...The class file version is 50.0 (only 45.3, 46.0
and 47.0
are supported)

// Decompiler options: packimports(3)
// Source File Name: Maher.java

import java.io.PrintStream;

class Richard
{

Richard()
{
}

public void dosomething()
{
for(int i = 0; i < 3; i++)
print();

}

private static void print()
{
System.out.println("Ofuscation sucks");
}
}

C:\>jar cvf rm.jar Maher.class Richard.class
adding: Maher.class(in = 317) (out= 241)(deflated 23%)
adding: Richard.class(in = 520) (out= 36(deflated 29%)

C:\>java -cp rm.jar Maher
Ofuscation sucks
Ofuscation sucks
Ofuscation sucks

C:\>type rm.pro
-injars rm.jar
-outjars rmx.jar
-libraryjars <java.home>/lib/rt.jar

-keep public class Maher {
public static void main(java.lang.String[]);
}

C:\>java -jar proguard.jar @rm.pro
ProGuard, version 4.2
Preparing output jar [C:\rmx.jar]
Copying resources from program jar [C:\rm.jar]

C:\>java -cp rmx.jar Maher
Ofuscation sucks
Ofuscation sucks
Ofuscation sucks

C:\>jar xvf rmx.jar
inflated: META-INF/MANIFEST.MF
inflated: Maher.class
inflated: a.class

Parsing Maher.class...The class file version is 50.0 (only 45.3, 46.0
and 47.0 a
re supported)

// Decompiler options: packimports(3)

public class Maher
{

public Maher()
{
}

public static void main(String args[])
{
new a();
a.a();
}
}

Parsing a.class...The class file version is 50.0 (only 45.3, 46.0 and
47.0 are s
upported)

// Decompiler options: packimports(3)

import java.io.PrintStream;

final class a
{

a()
{
}

public static void a()
{
for(int i = 0; i < 3; i++)
System.out.println("Ofuscation sucks");

}
}

C:\>

Richard Maher
Guest
Posts: n/a

 09-20-2009
Hi Arne,

"Arne Vajhøj" <(E-Mail Removed)> wrote in message
news:4ab581d9$0$293$(E-Mail Removed)... Wrote lots of good stuff with examples (see below for details) Thanks very much for the great info and examples! That JAD looks pretty scary! Even preserves/provides indentation. Source-code on demand - How easy was that I do like the look of that Proguard though (especially being able to "keep" the Applet or Main class) so I will read up on it (licensing etc). I guess one downside of this method is having to re-test all your code after it's been PROGUARDed. (Or don't deploy it to test until it's been PROGUARDed I suppose?) Then there's the support issue and "How long, after a new version of Java, is it before Proguard has a version that supports it?". But that's any software/freeware I guess, and if your deliberately using old Java versions then what does it matter? Still, it also shrinks the JAR size down then this could well be worth persuing - Thanks again! Cheers Richard Maher PS. I'll read the website testimonials, but if anyone here has had bad experiences then please let me know. "Arne Vajhøj" <(E-Mail Removed)> wrote in message news:4ab581d9$0$293$(E-Mail Removed)...
> Richard Maher wrote:
> > I appreciate that this has been discussed at length previously and there

is
> > some useful stuff to be found on the net but can I please just ask

someone
> > to confirm that there's not a whole lot one can do to stop an

enthusiastic
> > (let alone dedicated) coder from converting a Java class file back to

its
> > original source format?
> >
> > My understanding (too strong a word here is that a custom

> > is probably the best bet but does anyone have a very simple example of

one
> > of these, especially one that would not fall foul of the sandpit and

other
> > requirements of an *unsigned* applet?
> >
> > Are people routinely paying for "supported" obfuscators or rolling their
> > own? (And are they much of a deterrant and/or footprint-reduction impact

in
> > the first place?)
> >
> > Do you have examples of the quality of output one can produce from

publicly
> > available de-compilers?
> >
> > "All too hard", just rely on copyright protection and those companies

who
> > might use it coughing up?

>
> See below for an example.
>
> I would not start messing around with a decrypting classloader.
>
> Possible run an obfuscator like Proguard.
>
> It ensure that the crackers actually have to do a little
> bit of work.
>
> And as a nice side effect it reduces the size of the
> jar files a bit which is great for applets.
>
> Arne
>
> ================================================
>
> C:\>type Maher.java
> public class Maher {
> public static void main(String[] args) {
> Richard r = new Richard();
> r.dosomething();
> }
> }
>
> class Richard {
> public void dosomething() {
> for(int i = 0; i < 3; i++) {
> print();
> }
> }
> private static void print() {
> System.out.println("Ofuscation sucks");
> }
> }
>
> C:\>javac Maher.java
>
> C:\>java -cp . Maher
> Ofuscation sucks
> Ofuscation sucks
> Ofuscation sucks
>
> Parsing Maher.class...The class file version is 50.0 (only 45.3, 46.0
> and 47.0 a
> re supported)
>
> // Decompiler options: packimports(3)
> // Source File Name: Maher.java
>
>
> public class Maher
> {
>
> public Maher()
> {
> }
>
> public static void main(String args[])
> {
> Richard richard = new Richard();
> richard.dosomething();
> }
> }
>
> Parsing Richard.class...The class file version is 50.0 (only 45.3, 46.0
> and 47.0
> are supported)
>
> // Decompiler options: packimports(3)
> // Source File Name: Maher.java
>
> import java.io.PrintStream;
>
> class Richard
> {
>
> Richard()
> {
> }
>
> public void dosomething()
> {
> for(int i = 0; i < 3; i++)
> print();
>
> }
>
> private static void print()
> {
> System.out.println("Ofuscation sucks");
> }
> }
>
> C:\>jar cvf rm.jar Maher.class Richard.class
> adding: Maher.class(in = 317) (out= 241)(deflated 23%)
> adding: Richard.class(in = 520) (out= 36(deflated 29%)
>
> C:\>java -cp rm.jar Maher
> Ofuscation sucks
> Ofuscation sucks
> Ofuscation sucks
>
> C:\>type rm.pro
> -injars rm.jar
> -outjars rmx.jar
> -libraryjars <java.home>/lib/rt.jar
>
> -keep public class Maher {
> public static void main(java.lang.String[]);
> }
>
> C:\>java -jar proguard.jar @rm.pro
> ProGuard, version 4.2
> Preparing output jar [C:\rmx.jar]
> Copying resources from program jar [C:\rm.jar]
>
> C:\>java -cp rmx.jar Maher
> Ofuscation sucks
> Ofuscation sucks
> Ofuscation sucks
>
> C:\>jar xvf rmx.jar
> inflated: META-INF/MANIFEST.MF
> inflated: Maher.class
> inflated: a.class
>
> Parsing Maher.class...The class file version is 50.0 (only 45.3, 46.0
> and 47.0 a
> re supported)
>
> // Decompiler options: packimports(3)
>
>
> public class Maher
> {
>
> public Maher()
> {
> }
>
> public static void main(String args[])
> {
> new a();
> a.a();
> }
> }
>
> Parsing a.class...The class file version is 50.0 (only 45.3, 46.0 and
> 47.0 are s
> upported)
>
> // Decompiler options: packimports(3)
>
> import java.io.PrintStream;
>
> final class a
> {
>
> a()
> {
> }
>
> public static void a()
> {
> for(int i = 0; i < 3; i++)
> System.out.println("Ofuscation sucks");
>
> }
> }
>
> C:\>
>

Qu0ll
Guest
Posts: n/a

 09-20-2009
"Richard Maher" <(E-Mail Removed)> wrote in message
news:h944js$hkr$(E-Mail Removed)...

[...]

> I do like the look of that Proguard though (especially being able to
> "keep"
> the Applet or Main class) so I will read up on it (licensing etc).
>
> I guess one downside of this method is having to re-test all your code
> after
> it's been PROGUARDed. (Or don't deploy it to test until it's been
> PROGUARDed
> I suppose?) Then there's the support issue and "How long, after a new
> version of Java, is it before Proguard has a version that supports it?".
> But
> that's any software/freeware I guess, and if your deliberately using old
> Java versions then what does it matter?
>
> Still, it also shrinks the JAR size down then this could well be worth
> persuing - Thanks again!
>
> Cheers Richard Maher
>
> experiences then please let me know.

My Java development focuses on applets and I simply could not imagine life
without ProGuard. It's an awesome tool and I rely on it heavily. So far it
has proven to be extremely safe and only occasionally have I encountered any
kind of issue with it and, even then, Eric Lafortune whom maintains it has
been quick to patch to fix. You'll find it removes heaps of dead code you

Yes, you certainly do need to re-test your code because there are some
things that will be removed when you don't want them to be or some things
which relied on non-obfuscated class names etc. but all of these things can
be fixed by correct configuration. ProGuard even optimises your code so it
will run faster!

Anyway Eric, you have my email address, I will be expecting a small reward
for this otherwise unpaid endorsement!

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
http://www.velocityreviews.com/forums/(E-Mail Removed)
[Replace the "SixFour" with numbers to email me]

Roedy Green
Guest
Posts: n/a

 09-20-2009
On Sun, 20 Sep 2009 08:19:58 +0800, "Richard Maher"
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>I appreciate that this has been discussed at length previously and there is
>some useful stuff to be found on the net but can I please just ask someone
>to confirm that there's not a whole lot one can do to stop an enthusiastic
>(let alone dedicated) coder from converting a Java class file back to its
>original source format?

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

You are right, it is very easy to decompile/disassemble a source file.

Most of the time you flatter yourself if you think any one module
contains some great secret. It is only the app as a whole you want to
discourage from piracy.

The most serious approach is native optimised compilation. See
http://mindprod.com/jgloss/nativecompiler.html

My own preferred approach needs an Internet connection, frequent
running small parts of the app on a server where the hacker can't even
look at them.
--
http://mindprod.com

"Perfect reusable components are not obtained at the first shot."
~ Bertrand Meyer (born: 1950 age: 59) 1989, creator of design by contract and the Eiffel language.

Joshua Cranmer
Guest
Posts: n/a

 09-20-2009
On 09/19/2009 10:42 PM, Richard Maher wrote:
> That JAD looks pretty scary! Even preserves/provides indentation.
> Source-code on demand - How easy was that

The last I checked, JAD could not decompile the Java 5-specific stuff.
In fact, to my knowledge, only one fully-functioning decompiler exists
that can do it.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Arne Vajhøj
Guest
Posts: n/a

 09-20-2009
Richard Maher wrote:
> "Arne Vajhøj" <(E-Mail Removed)> wrote in message
> news:4ab581d9$0$293\$(E-Mail Removed)...
> Wrote lots of good stuff with examples (see below for details)
>
> Thanks very much for the great info and examples!
>
> That JAD looks pretty scary! Even preserves/provides indentation.
> Source-code on demand - How easy was that

It does not preserve, but it tries to write the code as readable as
possible.

> I do like the look of that Proguard though (especially being able to "keep"
> the Applet or Main class) so I will read up on it (licensing etc).

ProGuard is GPL with some exceptions.

But they explicit state that it does not have any impact on
the input or output code.

ProGuard is free. You can use it freely for processing your
applications, commercial or not. Your code obviously remains yours after
having been processed, and its license can remain the same.

> I guess one downside of this method is having to re-test all your code after
> it's been PROGUARDed. (Or don't deploy it to test until it's been PROGUARDed
> I suppose?)

Yes.

> Then there's the support issue and "How long, after a new
> version of Java, is it before Proguard has a version that supports it?". But
> that's any software/freeware I guess, and if your deliberately using old
> Java versions then what does it matter?

http://sourceforge.net/projects/proguard/files/
then it seems rather actively maintained.

Obviously no guarantee for the future.

Arne

Roedy Green
Guest
Posts: n/a

 09-20-2009
On Sun, 20 Sep 2009 08:09:55 -0400, Joshua Cranmer
<(E-Mail Removed)> wrote, quoted or indirectly quoted someone
who said :

>The last I checked, JAD could not decompile the Java 5-specific stuff.
>In fact, to my knowledge, only one fully-functioning decompiler exists
>that can do it.

It decompiles it, but not into idiomatic java with enums and generics.
However, if all you want to do is figure out how the program works, it
tell you all you need to know. I have some sample decompiles posted
at http://mindprod.com/jgloss/enum.html

They helped me figure out how enums worked under the hood.

--
http://mindprod.com

"Perfect reusable components are not obtained at the first shot."
~ Bertrand Meyer (born: 1950 age: 59) 1989, creator of design by contract and the Eiffel language.

Roedy Green
Guest
Posts: n/a

 09-20-2009
On Sun, 20 Sep 2009 08:24:18 -0400, Arne Vajhøj <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>> That JAD looks pretty scary! Even preserves/provides indentation.
>> Source-code on demand - How easy was that

>
>It does not preserve, but it tries to write the code as readable as
>possible.

Indentation and local variable names are not normally included in the
class files. However, a decompiler can reconstruct them with quite
plausible code. For example, a local variable of the Sample class it
can call "sample".

--
http://mindprod.com

"Perfect reusable components are not obtained at the first shot."
~ Bertrand Meyer (born: 1950 age: 59) 1989, creator of design by contract and the Eiffel language.