0

I mean how is this okay?

If I've made a program that I don't want to share it's code, there's actually no way to achieve this, it can be decompiled really easily! (talking about jars),

Isn't this considered as a serious problem? It's it's not the same with other languages (it's not that easy as with java).

Edit : I'm not asking how to prevent so, I'm asking why?

mhashim6
  • 527
  • 6
  • 19
  • This is roughly a duplicate of http://stackoverflow.com/questions/49379/how-to-lock-compiled-java-classes-to-prevent-decompilation and there's some good discussion in the answers there. – Dave Ross May 05 '16 at 16:21
  • I'm not asking how to prevent so, I'm asking (why)? – mhashim6 May 05 '16 at 16:25
  • 2
    @mhashem6 Because you can do this with any language. If anything, I'd almost call it a security feature - The ability to check code for backdoors and viruses before I run it on my machine. It's easier with interpreted languages, and harder with native-compiled languages, but still not *hard* to decompile C++, for example. It's just a matter of how much time & effort you want to put into it. If you don't want to share the code, then don't - expose it as a web service where the code runs on your own hardware. If you share the executable, you're sharing the code-- that goes for any language. – Darth Android May 05 '16 at 16:28
  • @Darts Android, so it's not a problem with Java specifically? – mhashim6 May 05 '16 at 16:36
  • As to the historical why: java was conceived to be compiled not to machine code but a portable, nice pseudo-machine-code. And still today you can let your application run on any platform that has a java runtime (Windows, Mac, Linux, car system, sat receiver, ...). It guarantees that an int is 32 bits and such. – Joop Eggen May 05 '16 at 17:04
  • @mhashem6 Correct. C#, for example, is just as easy to decompile. Javascript, PHP, Python, Ruby, and Lua are examples of interpreted languages, where you have to just give someone the source if you want them to run your code. C/C++ are more difficult to decompile, but it can be done. – Darth Android May 05 '16 at 20:31

1 Answers1

2

Obfuscate the code with a tool or library.

For more information on this topic, see: https://www.owasp.org/index.php/Bytecode_obfuscation#How_to_prevent_Java_code_from_being_Reverse-engineered_.3F which describes:

How to prevent Java code from being Reverse-engineered ? Several actions can be taken for preventing reverse-engineering :

Code Obfuscation.

This is done mainly through variable renaming; see next paragraph for more precisions,

Suppression of End Of Line Characters. This makes the code difficult to parse, Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.

Class file encryption.

This implies some overhead for uncyphering at runtime. Several tools are available:: Canner, by Cinnabar Systems, or JLock by JSoft. They are available for evaluation, and the first is proposed currently for Windows Platforms only. Replacing the method names with certain characters e.g '/' or '.' in the class header causes the popular decompilation tools such as JAD to dump the source code which is incomprehensible (you cannot determine the control flow from the source).

Note: Beware of 100% Java solutions using encryption to protect class files as these are more than likely snake oil. Since the JVM has to read unencrypted class files at some point, even if the class files are encrypted on the disk, they will have to be decrypted before being passed to the JVM. An attacker could modify the local JVM to simply write the class files to disk in their unencrypted form at this point. (See: Javaworld article).

Conjecture: It's is very easy to circumvent these methods to reveal bytecode using a Java profiler.

What obfuscation tools are available ? A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/ http://proguard.sourceforge.net/alternatives.html

KlassMaster, shrinks and obfuscates both code and string constants. It can also translate stack traces back to readable form if you save the obfuscation log.

Proguard is a shrinker (make code more compact), and optimizer and obfuscator. Jode is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,, Jarg,

Javaguard, which is a simple obfuscator, without many documentation,

CafeBabe, which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

If you want to prevent 'code tampering', then I recommend you sign your jar files. This would make the jar unusable if tampered with. For more information see: https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html

pczeus
  • 7,709
  • 4
  • 36
  • 51
  • 5
    Note, this just increases the difficulty of decompiling. Given enough determination, if I can run the code, I can decompile it. This goes for *any* language. – Darth Android May 05 '16 at 16:26
  • Thank you sir, but I'm asking about why java doesn't encrypt the sources? – mhashim6 May 05 '16 at 16:33
  • 3
    Even languages like C++ don't 'encrypt' the sources. Just because you can't read assembly or byte code, doesn't mean a hacker can't. Yes, Java has nice decompilers making it easier, but there are other means for other languages. Finally, asking 'why' is an opinion based question and would be invalid on StackOverflow. – pczeus May 05 '16 at 16:36
  • 2
    *"if I can run the code, I can decompile it. This goes for any language."* @mhashem6 this is your answer. – noppa May 05 '16 at 16:43
  • Thank you all, btw my (why) was (why programmatically) I mean did they have to do so. – mhashim6 May 05 '16 at 16:52