5

Is there a way to deploy a Java program in a format that is not reverse-engineerable?

I know how to convert my application into an executable JAR file, but I want to make sure that the code cannot be reverse engineered, or at least, not easily.

Obfuscation of the source code doesn't count... it makes it harder to understand the code, but does not hide it.

A related question is How to lock compiled Java classes to prevent decompilation?

Once I've completed the program, I would still have access to the original source, so maintaining the application would not be the problem. If the application is distributed, I would not want any of the users to be able to decompile it. Obfuscation does not achieve this as the users would still be able to decompile it, and while they would have difficulty following the action flows, they would be able to see the code, and potentially take information out of it.

What I'm concerned about is if there is any information in the code relating to remote access. There is a host to which the application connects using a user-id and password provided by the user. Is there a way to hide the host's address from the user, if that address is located inside the source code?

Community
  • 1
  • 1
Elie
  • 13,693
  • 23
  • 74
  • 128
  • Already asked here: This has already been asked here: http://stackoverflow.com/questions/49379/how-to-lock-compiled-java-classes-to-prevent-decompilation – Craig Sep 29 '08 at 19:01
  • Why is it important for the user to not know a database service is running at the IP address you're connecting to? – user359996 Feb 16 '11 at 18:22

14 Answers14

15

The short answer is "No, it does not exist".

Reverse engineering is a process that does not imply to look at the code at all. It's basically trying to understand the underlying mechanisms and then mimic them. For example, that's how JScript appears from MS labs, by copying Netscape's JavaScript behavior, without having access to the code. The copy was so perfect that even the bugs were copied.

Igor Popov
  • 9,795
  • 7
  • 55
  • 68
gizmo
  • 11,819
  • 6
  • 44
  • 61
  • 1
    Gizmo, I think you should either delete or edit your comment. Anyone reading the question understands that Elie is looking for a way to prevent easy de-compilation. You're splitting hairs and it REALLY isn't an answer. Or you could update your comment to include the correct phrase. Pls b helpful! – Joseph Gordon Sep 30 '08 at 21:38
  • 6
    Sorry but I won't do that. I prefer to give a good answer to a wrong question than giving a wrong answer to a wrong question, especially as it is the case now with AlbertEin's answer that does not fit at allthe real requirement, which is "preventing someone to find an URL in the decompiled code". – gizmo Oct 01 '08 at 09:04
  • 2
    You could answer the *intended* question, and add a comment explaining the shortcomings of the *literal* question... – user359996 Feb 16 '11 at 18:19
12

You could obfuscate your JAR file with YGuard. It doesn't obfuscate your source code, but the compiled classes, so there is no problem about maintaining the code later.

If you want to hide some string, you could encrypt it, making it harder to get it through looking at the source code (it is even better if you obfuscate the JAR file).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
albertein
  • 26,396
  • 5
  • 54
  • 57
  • 4
    He said source code obfuscation, i'm telling him to obfuscate the resulting jar classes, that has nothing to do with source code – albertein Sep 29 '08 at 18:12
  • Indeed, presumably binary obfuscation is allowed. If its not, then his question really becomes, "How do I obfuscate my code? Ps, I can't use an obfuscator", and that wouldn't make much sense. Binary obfuscation isn't perfect, but its as good as you are likely to get. – jsight Sep 29 '08 at 18:17
  • I think he meant obfuscation of the generated bytecode, but he should edit to clarify. Obfuscated bytecode can still be reverse engineered, but not into a pretty format. – JeeBee Sep 29 '08 at 18:18
  • Everything can be reverse engineered, maybe he is confused about obfuscation and thinks that the source code is the think that gets obfuscated – albertein Sep 29 '08 at 18:21
  • dotFuscator obfuscates .NET IL code in a manner that cannot be decompiled to something you can use, including reordering commands and encrypting strings. You can recompile it, and if you're lucky, you can't read it. If you're unlucky, it will not even recompile. Bet there's such a thing for Java too – OregonGhost Sep 29 '08 at 18:24
  • I'm specifically looking to hide certain information contained in the source code. The exact address of the database I'm connecting to, to be exact. I don't care if they know which IP address I'm connecting to, though, just what at that IP address. – Elie Sep 29 '08 at 19:16
  • You could encrypt the string, but i would only make it harder to see, they could always read the source code to search for the encrypting key – albertein Sep 29 '08 at 19:27
  • which is precisely why I want to make sure they cannot access the source, so that they cannot find that information. – Elie Sep 29 '08 at 19:35
  • 1
    The information will always be there, you can only make it hard, like obfuscating the resulting byte code – albertein Sep 29 '08 at 19:44
  • 1
    What's to prevent them from using other means of deducing this information. Such as monitoring all out going traffic from the machine making the connection. – Benjamin Autin Sep 29 '08 at 20:56
  • @David: dotfuscator claims that they actually improve performance in many situations. – OregonGhost Sep 29 '08 at 21:04
  • I think that DB connections goes trought an encrypted channel, but i'm not sure about it. – albertein Sep 29 '08 at 22:10
8

If you know which platforms you are targeting, get something that compiles your Java into native code, such as Excelsior JET or GCJ.

Short of that, you're never going to be able to hide the source code, since the user always has your bytecode and can Jad it.

Grant Wagner
  • 25,263
  • 7
  • 54
  • 64
  • effectively. It's like copyright 'management'. You want to give the program so your computer can read it (and execute it) but don't want the user to read it (and copy it). It's a pretty unnatural thing. – helios Sep 29 '08 at 19:16
  • Compiling your Java into native code seems to be the only realistic solution, and should be better than obfuscation. – KJW Nov 27 '11 at 06:34
7

You're writing in a language that has introspection as part of the core language. It generates .class files whose specifications are widely known (thus enabling other vendors to produce clean-room implementations of Java compilers and interpreters).

This means there are publicly-available decompilers. All it takes is a few Google searches, and you have some Java code that does the same thing as yours. Just without the comments, and some of the variable names (but the function names stay the same).

Really, obfuscation is about all you can get (though the decompiled code will already be slightly obfuscated) without going to C or some other fully-compiled language, anyway.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Tanktalus
  • 21,664
  • 5
  • 41
  • 68
3

Don't use an interpreted language? What are you trying to protect anyway? If it's valuable enough, anything can be reverse engineered. The chances of someone caring enough to reverse engineer most projects is minimal. Obfuscation provides at least a minimal hurdle.

Ensure that your intellectual property (IP) is protected via other mechanisms. Particularly for security code, it's important that people be able to inspect implementations, so that the security is in the algorithm, not in the source.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Niniki
  • 812
  • 4
  • 6
2

I'm tempted to ask why you'd want to do this, but I'll leave that alone...

The problem I see is that the JVM, like the CLR, needs to be able to intrepert you code in order to JIT compile and run it. You can make it more "complex" but given that the spec for bytecode is rather well documented, and exists at a much higher level than something like the x86 assembler spec, it's unlikely you can "hide" the process-flow, since it's got to be there for the program to work in the first place.

Walden Leverich
  • 4,416
  • 2
  • 21
  • 30
2

Make it into a web service. Then you are the only one that can see the source code.

Ken
  • 2,092
  • 1
  • 19
  • 16
1

It can't be done.

Anything that can be compiled can be de-compiled. The very best you can do is obfuscate the hell out of it.

That being said, there is some interesting stuff happening in Quantum Cryptography. Essentially, any attempt to read the message changes it. I don't know if this could be applied to source code or not.

Chris Cudmore
  • 29,793
  • 12
  • 57
  • 94
1

Even if you compile the code into native machine language, there are all sorts of programs that let you essentially decompile it into assembly language and follow the process flow (OlyDbg, IDA Pro).

MattC
  • 12,285
  • 10
  • 54
  • 78
1

It can not be done. This is not a Java problem. Any language that can be compiled can be decompiled for Java, it's just easier.

You are trying to show somebody a picture without actually showing them. It is not possible. You also can not hide your host even if you hide at the application level. Someone can still grap it via Wireshark or any other network sniffer.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
1

As someone said above, reverse engineering could always decompile your executable. The only way to protect your source code(or algorithm) is not to distribute your executable.

separate your application into a server code and a client app, hide the important part of your algorithm in your server code and run it in a cloud server, just distribute the client code which works only as a data getter and senter.

By this even your client code is decompiled. You are not losing anything.

But for sure this will decrease the performance and user convenience.

I think this may not be the answer you are looking for, but just to raise different idea of protecting source code.

user116541
  • 96
  • 7
0

With anything interpreted at some point it has to be processed "in the clear". The string would show up clear as day once the code is run through JAD. You could deploy an encryption key with your app or do a basic ceasar cipher to encrypt the host connect info and decrypt at runtime...

But at some point during processing the host connection information must be put in the clear in order for your app to connect to the host...

So you could statically hide it, but you can't hide it during runtime if they running a debugger

0

This is impossible. The CPU will have to execute your program, i.e. your program must be in a format that a CPU can understand. CPUs are much dumber than humans. Ergo, if a CPU can understand your program, a human can.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
0

Having concerns about concealing the code, I'd run ProGuard anyway.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
yanchenko
  • 56,576
  • 33
  • 147
  • 165