Complie time using custom classloader for decryption.

I need to decrypt several class during compile time, but my custom classloader could load everything except my encrypted classes.

Here is my sample code and how I test it.

Test.java:

public class Test {

public Test(){

System.out.println("test");

}

public void hello(){

System.out.println("hello");

}

}

Test1.java

public class Test1 extends java.lang.Test{

public Test1(){

System.out.println("test1");

}

public static void main(String[] args){

new Test1().hello();

}

}

#EncryptedClassLoader will print out the class name it trying to load, for example: "load class: java.lang.System"

1. Compile Test.java file and have it encrypted, make it into a jar file - test.jar.

2. Compile Test1.java file and try to run Test1.class with encrypted Test.class file using :

C:\lib>java -Djava.system.class.loader=EncryptedClassLoader -classpath c:\lib;c:\lib\tools.jar;c:\lib\test.jar Test1

Gives the output:

load class: java.lang.System

load class: java.nio.charset.Charset

load class: java.lang.String

load class: Test1

load class: Test

load class: sun.security.provider.Sun

load class: sun.security.rsa.SunRsaSign

load class: com.sun.net.ssl.internal.ssl.Provider

load class: com.sun.crypto.provider.SunJCE

load class: java.lang.Object

load class: java.io.PrintStream

test

test1

hello

So now I'm sure there's no problem with my EncryptedClassLoader

3. Try to compile Test1.java with the encrypted Test.class in test.jar(These's no Test.java file in the same folder) by using:

C:\lib>javac -J-Djava.system.class.loader=EncryptedClassLoader -J-classpath -J.;c:\lib;c:\lib\tools.jar;c:\lib\test.jar Test1.java

Give the output:

.............. (loading several system classes)

load class: com.sun.tools.javac.util.Position

Test1.java:4: cannot find symbol

symbol: class Test

public class Test1 extends Test{

^

load class: java.lang.Long

load class: java.io.DataInputStream

load class: com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter

load class: com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy

load class: com.sun.tools.javac.jvm.ClassReader$ProxyVisitor

load class: com.sun.tools.javac.code.Types$SubstFcn

load class: com.sun.tools.javac.code.BoundKind

load class: java.lang.StringBuffer

Test1.java:12: cannot find symbol

symbol : method hello()

location: class Test1

new Test1().hello();

^

2 errors

> from the output I found that Test.class never visited/loaded by my EncryptedClassLoader

Though I set EncryptedClassLoader as the default system classloader but it seems to load everything except my encrypted class.

Does anyone know why it works like this?

Thank you in advanced,

Alex.

null

[3020 byte] By [fourplay56a] at [2007-11-26 12:40:44]
# 1

> C:\lib>javac

> -J-Djava.system.class.loader=EncryptedClassLoader

> -J-classpath

> -J.;c:\lib;c:\lib\tools.jar;c:\lib\test.jar

> Test1.java

What's the -J in front of the classpath list doing there? Not the right syntax. Try

-J-"-classpath .;c:\lib;c:\lib\tools.jar;c:\lib\test.jar"

ejpa at 2007-7-7 16:12:38 > top of Java-index,Core,Core APIs...
# 2
Thank you for the reply,I'm sure "-J-classpath -J.;c:\lib;c:\lib\tools.jar;c:\lib\test.jar" this works. I tried yours...but doesn't work.
fourplay56a at 2007-7-7 16:12:38 > top of Java-index,Core,Core APIs...
# 3
HiWere u able to solve the problem?
uditha_na at 2007-7-7 16:12:38 > top of Java-index,Core,Core APIs...
# 4

I don't know why he was specifying the javac classpath like that instead of using javac's -classpath option.

But this whole business of decrypting class loades is pretty much a waste of time. It adds a layer of comfort but it's not really what I would call secure. At some point the unencrypted bytes have to appear in memory and from that point the classes are no longer secure.

The best protection against software piracy is not anti-decompilation techniques but time-to-market and pricing your product so that buying it is cheaper than reverse-engineering it.

ejpa at 2007-7-7 16:12:38 > top of Java-index,Core,Core APIs...
# 5

I agree with ejp. Technically this is useless. The only way to protect a piece of code would be DRM. And we still do not have complete DRM systems. Your attempt falls woefully short of DRM. Don't bother wasting your time. Anyone that wants to decompile your code will be at least as smart as you. And probably moreso if decompiling is what they do for a living.

On the other hand, this is common knowledge to us software level folks. Management often does not comprehend this, or more likely does not care if it does not technically work...

_dnoyeBa at 2007-7-7 16:12:38 > top of Java-index,Core,Core APIs...
# 6
... and note that in the music field EMI, which has as much IP to protect as maybe anybody in the world, has just abandoned DRM.
ejpa at 2007-7-7 16:12:38 > top of Java-index,Core,Core APIs...