I need to distribute a Java desktop app to the user. I am looking at different ways to protect my source code from reverse engineering.

One method is to distribute a Virtual Machine (says Linux) containing the app running inside that VM, and make the root user of that having a password of e.g. 50 characters. The drawback is that the download size of my app is too big (some Gigas). And the next question is: can an attacker read my Java code from inside a VDI disk image ?

Another method is Ahead of Time (AOT) compiling to native. ExcelsiorJet seems to be the best tool for that, however that is not free. Obfuscating the source code is NOT enough, since the ones wanting to read your source code are the ones that mainly want to care about the information flow and data structure. This excellent article explains more about AOT and obfuscating. Now the question is: by using ExcelsiorJet to compile to native, is my native code relatively safe from reverse engineering ?

Still another way: to e.g. use C++ to write the most security critical code, compile it to real native, and expose my unimportant Java source. But this means I'll need to maintain both parts as well.

  • 6
    What are you really trying to do? Anything can be reverse-engineered, given enough time. If you're looking for a fool-proof, never-be-able-to-reverse-engineer-our-secrets kind of method, you won't find one. One thing you might be able to do is host the core logic on some web service somewhere, and the only thing you release is a client to the service, but that depends on what you're really trying to do.
    – user64273
    Aug 8, 2018 at 23:22
  • VDI disk images are cryptographic secured. I think what you wrote in the last pera is the only option.
    – again
    Aug 9, 2018 at 9:18
  • Since v5.0, Virtual Box supports Disk Image Encryption, but does it slow down my app running on the VM alot ?
    – Ken Po
    Aug 9, 2018 at 13:23
  • 1
    What's the point of encrypting the image if the user needs the key to use it anyway? Aug 9, 2018 at 15:15
  • @again The VDI disk image encryption means nothing if you give the user the key (which you'd have to if you want them to run it).
    – Macil
    Aug 10, 2018 at 4:17

1 Answer 1


This question is bordering on product recommendation request / opinion, but I'll try to answer the parts that are on-topic.

First off, good reverse-engineers are good. With enough skill and time, java source, java bytecode, c++ source, and native assembly are all equivalent in terms of showing an attacker how your software works.

Building on @Zymus's comment, you're starting with conflicting requirements, you want to:

  • Give out your source code to people / machines that you don't trust, but
  • You don't want it to be reverse-engineerable.

If the computer they are sitting at is able to understand and run your code, then (with enough effort) so can the human. Full Stop.

When your starting point is "I want to give them my code, but I don't want to give them my code", I'm not surprised that you can't find a solution.

Directly answering your questions:

can an attacker read my Java code from inside a VDI disk image ?

Well, can the computer read (and run) the Java code from inside a VDI disk image? If so, so can the attacker.

Obfuscating the source code is NOT enough,

Okay, we're back to the conflicting requirements here; obfuscation is the act of making code that can still be run by a machine, but is hard for a human to understand. You say that's not good enough: you want to allow the attacker to run your code, but not read your code. That doesn't make sense.

is my native code relatively safe from reverse engineering ?

Still another way: to e.g. use C++ to write the most security critical code, compile it to real native, and expose my unimportant Java source.

Why do you assume that native code is harder to reverse-engineer than Java? Sure, there's more learning-curve to reverse-engineering assembly with tools like IDA Pro compared to reverse-engineering java with jad, but for a skilled reverse-engineer, the effort is very similar.

I like @Zymus' suggestion: if there are bits of code that you don't want the attacker to have, then don't give it to them; run it on a server and provide an API that only exposes the (less sensitive) input and output.

  • Thanks, I meant giving the user the obfuscated .jar file inside a VDI image, or compile with AOT to native and give the executable to the users. I don't understand yet the expression "if a computer can understand the code then so is the hacker", Please elaborate. Further more the more difficulty I give to the attacker the less chance of being hacked I'll receive, there are people who can hack but don't care, and people who care but cannot (yet) hack. At the beginning I'll need to have enough payment to go further in order to come up with better solution.
    – Ken Po
    Aug 10, 2018 at 17:56
  • @KenPo Explanation of the comment: assembly programming is becoming a bit of a lost art, but anyone who does reverse-engineering professionally will have no troubles opening a binary executable and reading the assembly code the same way you read java. There are also good visual tools (ex. Ida Pro / Ollydbg) for native disassembly. You can google "intro to reverse engineering" or browse reverseengineering.stackexchange.com to get a feeling for the difficulty involved. Be careful not to fall into the trap of "It's hard for me, so it must be hard for everyone". Aug 10, 2018 at 18:12
  • That said, you're allowed to define whatever security model you want for you product, for example you're allowed to say "v1 of the product obfuscates java, and moved all sensitive code to native binaries". Maybe that's more secure than leaving everything in obfuscated java, and maybe it isn't. At the end of the day, your VDI image trick is also a form of obfuscation, so as with all security, better to buy an obfuscation tool written by experts than to invent your own solution. Or better yet: assume that any code in the binary will eventually be reverse-engineered and design accordingly. Aug 10, 2018 at 18:26
  • Thanks, I'm glad I have asked here. I'll rethink my design basing on the new boundary I have learnt. I will come back here with more question.
    – Ken Po
    Aug 10, 2018 at 21:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .