[Java-project] Java code protection

[SergE]

Not sure about aspectwerkz. I have only a small experience with AspectJ 
and if I'm wrong, please, correct me. Using ApsectJ you'll probably have 
to preprocess rt.jar anyway. If you wish to use load time weaving, there 
are two problems:
1) You can't weave java.lang.ClassLoader since it is loaded before 
AspectJ classes. So "execution" join point is helpless.
2) You can't use "call" joint point to intercept calls to defineClass() 
method in custom class loaders since it does not capture super calls to 
non-static methods. This limitation is probably general for all AOP 
implementations since it is caused by non-dynamic dispatch nature of 
super calls in JVM.
Of course, there are probably another ways to do this, I don't know. Any 
thoughts?

Turning back to rt.jar. Actually it's quite easy to modify it "by 
hands", since it's sources are available with JDK. The only class to be 
changed is java.lang.ClassLoader. To prove the concept, I've added the 
following code to defineClass():

if (!name.startsWith("java")) {
//Set appropriate root folder here
File dump = new File ("/home/serg/classes" + File.separatorChar + 
name.replace ('.', '_') + ".class");
FileOutputStream out = null;
try {
out = new FileOutputStream (dump);
out.write (b, off, len);
}
catch (Exception e){
e.printStackTrace ();
}
finally {
if (out != null) {
try {
out.close ();
}
catch (Exception e) {
}
}
}
}

It works. All classes are dumped to the specified folder in spite of 
custom class loaders used by application.

Stephen de Vries wrote:
>
> Ohhh, interesting.
>
> Wouldn't it also be possible to use something like 
> aspectwerkz.codehaus.org to create an interceptor? (could be a lot 
> easier than mucking about with rt.jar)
>
>
> On 24 Oct 2006, at 12:23, SergE wrote:
>
>> I have no experience with this tool, but I think that there is even 
>> no need to find a key to break protection. They said, they use custom 
>> class loaders in order to achieve encryption. It seems, this imposes 
>> no protection at all, because all ClassLoaders have to deliver their 
>> class definitions to the JVM through the 
>> java.lang.ClassLoader#defineClass(String name, byte[] b, ...) method. 
>> Here, byte[] b - is the byte array with class definition in the 
>> standard format specified by SUN's JVM Specification. No class loader 
>> can avoid calling this method and it is declared final. One can 
>> modify rt.jar and introduce some logging facility, for example 
>> dumping of unencrypted byte code into file.
>
> --Stephen de Vries
> Corsaire Ltd
> E-mail: stephen at corsaire.com
> Tel: +44 1483 226014
> Fax: +44 1483 226068
> Web: http://www.corsaire.com
>
>
>
>