2

I've coded a Java app and I plan to distribute it online. Each release will be locked with a secret serial key I made.

I need to secure my jar file from decompiler etc. Here is what I've done so far:

  1. User enters his serial key into a form
  2. The serial is sent to my dev server through a php script
  3. The script generates a new jar bin file which is encrypted in AES 128
  4. My "loader" downloads the jar file as bytes and decrypts it.
  5. It invokes the main method.
  6. User can use the app as he like to
  7. User close the app
  8. The cache is cleared and everything returns to step 1 or before.

I've made the steps 1 to 3, but I need to know if it is possible to make a custom classloader that grabs bytes from HTTP, decrypts them and invokes the main method. As the file is fully crypted (saved as bin on the PHP server), I can't use a basic class loader. About step 8, is it possible to unload content from the computer's memory?

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
Manitoba
  • 8,522
  • 11
  • 60
  • 122
  • 2
    I realize this is not a very upbeat or helpful thought, but if you don't already know how to secure your code, it's unlikely you've written anything that someone would want to steal. You efforts are probably best focused somewhere more productive. – Dave Jun 21 '12 at 11:55
  • 2
    *"I need to secure my jar file from decompiler etc."* When I run it in my custom JRE, it is mine. – Andrew Thompson Jun 21 '12 at 11:56
  • 1
    What's the point? Everything can be reverse-engineering, eventually. Is having the people buying your app jumping through these hoops worth your time? If your JAR doesn't deal with defence/sensitive stuff, I don't ever see a point in such things. The proportion of people wanting to peek behind the curtain is rather small. And the proportion of people **really** wanting to peek behind the curtain is even smaller, but these won't give up, and they'll circumvent your approach. So I don't think there's much benefit in wasting time doing that (apart maybe from learning). – haylem Jun 21 '12 at 11:59
  • @Dave I've already obfuscated my code with allatori (which is quite good actually). I need a kind of login form for my app that can't be cracked. – Manitoba Jun 21 '12 at 12:00
  • @haylem It does as this is a security app. – Manitoba Jun 21 '12 at 12:01
  • This has already been an issue on stackoverflow: http://stackoverflow.com/questions/4257027/how-can-you-protect-encrypt-your-java-classes – jayeff Jun 21 '12 at 12:02
  • @Vodernki: I refer you to AndrewThompsons comment. – Dave Jun 21 '12 at 12:05
  • @Vodemki: If you say so. Personally, except if contractually forced to, I probably wouldn't bother, especially not in Java. It's an interesting issue and question, but it's generally an already lost battle. – haylem Jun 21 '12 at 12:05
  • I perfectly know that if someone edit the JRE to make his own interpreter (code dumper) I won't be able to avoid that. So here is my question: Is there any way to secure a jar file that has already been obfuscated? I could use jar2exe or something but the custom JRE will still be able to dump my code. – Manitoba Jun 21 '12 at 12:10
  • An exe isn't totally secure. Exe are breaked every days. And java to exe conversions don't work well. In fact they rarely work when they don't just encapsulate the jar. What you may do is do a little more operations online on your server (like core and necessary data transformations). But this field is so big that we can't discuss it in comments. – Denys Séguret Jun 21 '12 at 12:14
  • I don't understand what kind of 'necessary [...] transformations' I could do online. Can we talk in a chat room? http://chat.stackoverflow.com/rooms/12853/java-security – Manitoba Jun 21 '12 at 12:17

2 Answers2

6

Yes, it is possible, but it's also useless.

Your classloader will be the weakest point of your security system. It cannot be encrypted, thus it will be relatively easy to decompile it.

Now, as there is a place in the Classloader where you must have a decrypted class in a form of bytearray, the only thing an attacker will have to do, is to dump this byte array to a file.

Referring to dystroy's code:

classBytes = EncryptionUtil.decryptBytes(url, key); 

// In this moment, classBytes contains unencrypted class.
// If an attacker adds:   
//
//   FileOutputStream fos = new FileOutputStream("some.name");
//   fos.write(classBytes);
//   fos.close();
// 
// he will destroy all your security.


return defineClass(name, classBytes, 0, classBytes.length);
Community
  • 1
  • 1
npe
  • 15,395
  • 1
  • 56
  • 55
  • That's why I said obfuscating this is necessary (and not sufficient). But you know, most java is use in enterprise with a few customers only not motivated enough for complex hacking. – Denys Séguret Jun 21 '12 at 12:00
  • @dystroy ClassLoader's construction is fairly easy. It will also be easy to find the class, as it will be the only unencrypted class, and only class that the user has to have on its workstation. Even if you obfuscate a classloader, it will still be very easy do decompile an understand it, as it has very little code. – npe Jun 21 '12 at 12:02
  • you make many assumptions about the used solution... And I answer to the specific technical point, I don't validate the general scheme in its (unknown) context of use. – Denys Séguret Jun 21 '12 at 12:03
  • 1
    What I wanted to point out is, that a lot of people think that encrypting their jars/classes is a great idea, and very little of them are actually aware how easy it is to break. That's all. Your answer is good and I have no other objections to your code :-) – npe Jun 21 '12 at 12:11
  • Keep the `SecureClassLoader` (which contains decrypt logic) in a jar file and convert the jar to exe / linux / mac format using some tools like [jar2exe](http://www.jar2exe.com/). I haven't tried it so I don't know how much secure it is from hacking. – Visruth Aug 04 '17 at 15:10
0

Yes, you can provide to a classloader the bytes you grab. I do it in a similar problem :

public class SecureClassLoader extends URLClassLoader {

    @Override
    protected Class<?> findClass(final String name) throws ClassNotFoundException {
        if (isEncrypted(name)) {
            final String resourceName = name.replace('.', '/') + ".class";
            URL url = findResource(resourceName);
            if (url != null) {
                byte[] classBytes = null;
                try {
                    classBytes = EncryptionUtil.decryptBytes(url, key);
                    return defineClass(name, classBytes, 0, classBytes.length);
                } catch (ClassFormatError e) {
                    log.severe("Bad format for decrypted class " + name);
                    throw new EncryptedClassNotFoundException(name, e);
                } catch (InvalidKeyException e) {
                    throw new EncryptedClassNotFoundException(name, e);
                } catch (IOException e) {
                    throw new EncryptedClassNotFoundException(name, e);
                }
            }
        }

        // default loader
        try {
            return super.findClass(name);
        } catch (ClassNotFoundException e) {
            throw new EncryptedClassNotFoundException(name, e);
        }
    }

    private boolean isEncrypted(String className) {
        /// some things
    }
}

But this won't be sufficient to protect your code. At the very least, don't use the same bytes for two users (you seem to do it). And obfuscate your code (I use proguard). This will protect you against ordinary hackers, not the best ones.

Denys Séguret
  • 372,613
  • 87
  • 782
  • 758
  • Bytes are generated everytime a user tries to connect. All successful connection receive an unique link to download the jar. Thanks for your code, I'll try that. – Manitoba Jun 21 '12 at 12:03
  • 1
    Even if I think other commenters make too many assumptions, don't ignore them totally, it pays to be attentive on this matter ;) – Denys Séguret Jun 21 '12 at 12:06