5

We are considering the programming language for a desktop application with extended GUI use (tables, windows) and heavy database use. We considered Java for use however the fact that it can be decompiled back very easily into source code is holding us back.

There are of course many obfuscators available however they are just that: obfuscators. The only obfuscation worth doing we got was stripping function and variables names into meaningless letters and numbers so that at least stealing code and renaming it back into something meaningful is too much work and we are 100% sure it is not reversible back in any automated way.

However as it concerns to protecting internals (like password hashes or sensible variables content) we found obfuscators really lacking.

Is there any way to make Java applications as hard to decode as .exe counterparts?

And is it a factor to consider when deciding whether to develop in Java a desktop application?

Sandra G
  • 163
  • 6
  • 6
    Putting something you don't want a user to have on a users machine is pretty much asking for trouble. No matter what you do there's always the slim chance of someone being exceedingly clever and decompiling your code. The simple solution would be to not put resources that you don't want a user to find in plaintext in your code. – daniel gratzer Oct 30 '13 at 16:59
  • Ok I agree, but in my case if Java were as hard to decompile as any .exe executable it would be sufficient. Exe programs are cracked everyday but also many resist either because it's too expensive or because it's not worth cracking them. Java instead seems a piece of cake to crack, I would like to be as safe as exe not more. – Sandra G Oct 30 '13 at 17:03
  • 5
    What "internals" do you want to "protect"? Whatever is in memory is relatively easy to find from a live process, regardless of how hard decompilation is (virtually every game hack ever does this, and they're not hampered by the fact that most games are written in C++ or something similar). And sensitive data in the executable is even less safe. –  Oct 30 '13 at 17:03
  • I would like to avoid anyone to modify conditions which check for instance for activation or integrity of the program. Of course you can modify it when it's in memory as binary instructions or asm instructions but in Java it's as easy as following the decompiled user readable code high level language code! Binary, ASM are hard, Java decompiled is easy! – Sandra G Oct 30 '13 at 17:06
  • 3
    You just haven't been exposed to the C ones as much - http://boomerang.sourceforge.net/ –  Oct 30 '13 at 17:08
  • 1
    @SandraG, I think obfuscation is enough. Take a look at the output of the obfuscater -- do you really think you could understand that code? – Ben Lee Nov 05 '13 at 10:27
  • [.NET is just about worse](http://www.red-gate.com/products/dotnet-development/reflector/), yet tons of companies develop desktop software using .NET. – user Apr 11 '14 at 13:23

2 Answers2

4

Java is relatively easy to decompile back into legal Java code and with the abundance of programs capable of doing so it should definitely be a deciding factor whether to make use of Java for desktop applications. Albeit true that obfuscators do a good job at making it hard to make sense of your code it should be considered that if the data you are trying protect to is valuable enough it can and will be found.

No matter what you write your application in there will always be the chance of your application being reverse engineered. For instance if you write your program in Assembly it will take some effort but it can still be reverse engineered into compilable/understandable source. When choosing what language to write your application in you should consider how much effort it will take to reverse engineer you app with Java and C# being one of the easiest and C and Assembly being the hardest.

You can also attempt to hide sensitive data in the app/code by making use of the following techniques:

  • Encrypt variable data and have it decrypted at runtime.
  • Encrypt the entire executable section of your application and decrypt it at runtime using an unpacker (this is not the best option as it will result in AV software thinking your application is a virus)
  • Make sure buffers containing sensitive data are nulled after use.
  • Keeping sensitive data on a remote server and make use of SSL to download it at runtime.

I hope this answers your question.

Keagan Ladds
  • 180
  • 1
  • 8
0

Yes, you can make Java programs arbitrarily hard to decode. It depends on how much you want to do it and how much time and skill you have in pursuing this goal.

First, obfuscation is pretty good. Apart from mangling names it is possible to distort the code flow to the point where making sense of how a program works, what algorithm it uses and how it manipulates its data is just as hard as an optimised C++ program.

Second, it is very straightforward to disguise key data. As good developers of internationalised and configurable software you already store your data separately from your code, in resource files or something similar. The C++ programmer does something similar. You can easily encrypt that data using an algorithm and key buried deeply in the code.

Although my experience of this is in languages other than Java, you can arrange for chunks of code to be stored in encrypted form and decrypted when loaded into memory.

In these days of continuous Internet connection you can retrieve the code and keys you need dynamically from the 'net, and protect them with certificates. That's what Microsoft does with its store apps.

All of this is perfectly possible, and the game developers are doing it right now. On the other side are legions of hackers just waiting for the next release to wheel out their in-memory debugging tools and be the first to announce a crack.

You should wish that your software becomes well-known enough and valuable enough to attract this kind of attention. I have always focused first on solving the problem that no-one has heard of my software. If I am ever fortunate enough to have millions of hackers trying to break my programs, I am sure I shall have the resources to give them a good run.

david.pfx
  • 8,105
  • 2
  • 21
  • 44