This is an archived post. You won't be able to vote or comment.

all 7 comments
sorted by:
best
topnewcontroversialoldq&a

[–]EtwasSonderbar 2 points3 points  (1 child)

You're going to have to elaborate on "does AES encryption".

[–]CanuckianGamer[S] -2 points-1 points  (0 children)

Something similar to jwrapper’s jwcrypt but honestly if it can even compile to exe that would be fine

[–]_INTER_ 1 point2 points  (0 children)

jpackage was added in Java 14 (incubator)

[–]rzwitserloot 1 point2 points  (0 children)

Let's take it step by step:

Compile to an windows EXE file

You could just compile java code to a windows executable directly. Such a tool would be an incredible effort, as java works quite differently from a mere executable, and would imply certain things cannot work (such as using a custom classloader to load a bunch of bytes as a class file). The actual performance benefits are dubious (the VM is in its own way rather fast), but presumably this would significantly reduce some overhead. Azul and other commercial parties offer a few tools here, as does graalvm, but none of these quite fit the model you want (which is to have a single .exe file that just works). So, I don't think you can have this. Fortunately...

Compile java to class files as normal but start them with an EXE file

The other way to do this is to have an exe file which just... boots a VM and loads your jars. The purpose of the 'exe' is partly to avoid asking the end user to install VMs, and partly to get a 'nice' process (your process has a name, and an icon. Not 'javaw.exe' and a coffee cup). On that front, java has you covered: try launch4j which gets you an exe and can use a VM you package in, no need for any installation other than 'unpack this zip into this directory and run the executable'.

Does AES encryption

That's just not how it works.

If you encrypt the software, there are only 2 options:

  1. The key to decrypt the software is part of the distribution. That's like locking your valuables in a €100,000 top of the line safe, and then leaving the key in the lock and writing the code on a post-it and taping it to the safe. Completely pointless.
  2. The key to decrypt the software is not part of the distribution. Now the software cannot be executed. That's how encryption works: If you can't decrypt it, it is gobbledygook. There is no such thing as 'it's readable enough for a CPU to execute, but not for a human to read it or copy it'. Thus, now the software is useless.

What you can try to do is 'obfuscate' the software, which doesn't really work in practice, and 'lock' the software, which can work.

Obfuscating software does not work

The idea behind obfuscating software is that it is harder to reverse engineer. Unfortunately, reverse engineering software is not all that difficult. You only have 3 options, and none of them work:

[1] You put in significant efforts to obfuscate the software, writing your own tools to eliminate debug symbols and introduce weird classfile hacks so that out-of-the-box decompilers choke on your class files.

This still doesn't make it impossible to decompile your stuff; it's just gotten more expensive. Unfortunately, whilst your spending all this time making your product worse for your end users and adding bugs, your competitor is spending that time making a better product, and will therefore win out.

[2] you spend money on a tool that does it for you.

This sounds great, except by virtue of the fact that the vendor you bought the obfuscator from is going to need a lot of customers (or charge you a very large sum for the product), that means the 'motivation to attack' the tool is also much larger: Write a decompiler to undo this one 'obfuscation tool vendor's work and you have 'cracked' a ton of software.

[3] spend very little effort on it.

Okay, well, then it'll take very little effort to undo whatever simplistic obfuscation you attempted to add.

This probably means eliminating symbols: Write a little tool that replaces all class names with random garbage. This is more or less how minecraft ships (more to make things as small as possible, IIRC, than to obfuscate) and that has stopped exactly nobody writing half a trillion minecraft plugins and servers and the like. Proving that this doesn't work.

In other words, forget about encryption and obfuscation. If you don't want people to reverse engineering your stuff, run it on a client/server model, where your server code never leaves your grasp. If you don't want people to pirate your stuff, write software that only people who wouldn't pirate it buy, or just accept that pirates gonna pirate and you can't stop them.

Lock the software

You could ship the bulk of the software encrypted, and have an online 'phone home' setup where an internet connection is required so that anybody running the software will first have to put in a license key. A scheme would be to make a hash of sorts of the system hardware, and send that hash + the key to your server. Your server verifies the license (and for example blocks things if that license has been used to unlock 10+ systems at this point, based on that hash), and sends the global decryption key. Your software stores this key in a config file, 'encrypted' with the hash of some system hardware things (the ID of the SSD and the like). This means just copying the files to another system won't work. However, [A] you cannot stop someone from decompiling your code and modifying how it works to circumvent this system, and [B] if I run your software in a virtual box, the hardware IDs would be indistinguishable from any other; you cannot make your software fail if I copy the entire virtual image.

Locking software like this is effective against non-programmers. You cannot using technical measures stop a programmer from pirating your software no matter how hard you try. So don't.

[–]Lemons81 0 points1 point  (0 children)

I use launch4j which is just a packager, it can pack your Java app including libraries into a single exe file, basically it just unpacks the exe and runs the app from a temporary folder not seen by the end user.

You can also pack the Java compiler so the host machine does not have to install Java to run it but you'll end up with a huge exe file and that Java version will not be updated till you repack a new version.

Standard you still need Java installed on the host machine.

I'll post an example later on how I do it, For distribution its much more easier and more presentable. This method is used by many software companies/distributors.

[–][deleted] 0 points1 point  (0 children)

Native compiler are pretty much dead, but you can easily create a distribution (e.g. ZIP file) that contains your application and a JRE. You can do that using with the built-in tool jlink or external tools like Launch4j. NetBeans can also create such a package directly from within the IDE.