Java: URLClassLoader keeps loaded classes in Temp dir

Question

I'm trying to load jar file from web using URLClassLoader, all works fine, but all loaded classes keeps stored in Windows temp directory, and can be copied for deobfuscation until I call classLoader.close(); which in turn will cause a program ClassNotFoundException.

Can I load classes without saving to disk?

(Only memory) Another solution encrypt jar classes, and write custom ClassLoader that will decrypt classes, but i don't find any examples.

I tried to look for docs or articles on this topic, but found nothing :(

Please tell me whether it is possible to implement and where I can take the material on the topic? Thanks!

If the code is sensitive (code has sensitivity levels too, just like data), then you need to keep it on a server you control. It should not be available locally on a desktop or device the [potential] attacker controls. — jww, Sep 06 '14 at 20:21

score 2 · Accepted Answer · answered Mar 24 '14 at 14:07

You do realize that anyone with access to the machine you're running the code on could always get a hold of the code that will do the custom classloading, right? This means that they could simply decompile that class itself and make it write out the decrypted classes, rendering this whole exercise pointless. True, most people won't know how to do it, but it is possible.

My advice would be to just obfuscate the code, if you really must do so. Worrying about people getting a hold of your library won't get you far, as there's very little you could do to protect it from being decompiled, unless you're using obfuscating code constructs which will confuse the decompiler (or features jad and the likes do not support and thus cause them to produce seriously broken decompiled code).

Anyone with sufficient knowledge and proper motivation will figure out a way to do it.

I do not know a reliable way to protect in addition to obfuscation, but this protection is exactly like code obfuscation only slow down the process of decompilation. — Draiget, Mar 24 '14 at 15:17
It is become my understanding that Java is meant to be open and that any libraries written in it must be so too. If the binaries in Java were meant to be encrypted decompiling code would not be so much easier that in the C++ world. I think that the way Java wanted developers to protect the code was through licenses. Just look at the boom of licenses that popped up a few years after Java started becoming so main stream. A lot of these licenses are very much related to Java projects (although they are so genericly worded). — carlspring, Mar 24 '14 at 15:26

score 1 · Answer 2 · answered Mar 24 '14 at 14:14

It is fairly straightforward to create your own ClassLoader that retrieves classes from over a network. In Java documentation example for Classloader:

class NetworkClassLoader extends ClassLoader {
     String host;
     int port;

     public Class findClass(String name) {
         byte[] b = loadClassData(name);
         return defineClass(name, b, 0, b.length);
     }

     private byte[] loadClassData(String name) {
         // load the class data from the connection
          . . .
     }
 }

You only have to implement loadClassData and everything else is handled for you. In that loadClassData function, you can have encryption or anything else.

Yeah, you could read the jar in memory and load the classes from there, but someone could still decompile your class, reverse-engineer it, re-compile it and replace your custom class loader with theirs. This is really just a wasted effort. With proper motivation people who know what they're doing will crack this. — carlspring, Mar 24 '14 at 17:09

Java: URLClassLoader keeps loaded classes in Temp dir

2 Answers2