Is java class file or jar file is easy to reverse engineer? Because java generates a class file after compilation and not exe files. Is jar and class files are easy to decompile compare to c# and C++? If it is easy, then how can we protect java code so that it is difficult to reverse engineer?
Asked
Active
Viewed 1.2k times
3 Answers
14
Yes, Java class files are easy to reverse engineer. The format is very regular, and very constrained: the VM must be able to verify that the code complies to the strong typing rules of Java code. This is like the output of a C compiler with all optimizations deactivated: the program structure is plainly visible. (In the Java model, optimization happens in the VM itself, when the JIT compiler runs.)
People try obfuscation, though; e.g. with ProGuard (there are many tools on that market; this one is free and opensource). For instance, all classes and methods are renamed with strings which make no sense to a human (but the obfuscation also produces a translation file which the developer keeps for himself, so that he may interpret back stack traces in case of bug reports).
Alternatively, you might be able for process your Java code in an Ahead-of-Time compiler, like JET. This has some restrictions (in particular, the result is no longer "portable" since it is native code) but it makes decompilation harder (close to the complexity of reverse engineering compiled C or C++).
As a rule, reverse engineering tends to work, and for Java even more so, even after obfuscation. You'd better not use obfuscation as the foundation of your security.
It is also worth noting that this is very similar to code reading issues in any .Net language such as C#. It is pretty much equally trivial to generate Java, VB.Net or C# code from the distributed files and obfuscation techniques that try to make it more difficult to read are similar for both as well.
AJ Henderson
- 41,896
- 5
- 63
- 110
Thomas Pornin
- 322,884
- 58
- 787
- 955
-
Correction: an AOT compiler is not an alternative to _name_ obfuscation, but rather a complementary technology. At the same time, _code_ obfuscation hinders subsequent compiler optimizations and therefore should not be used prior to AOT compilation. Kindly refer to [my article on Java code protection](http://www.excelsior-usa.com/articles/java-obfuscators.html) for an extended discussion on this topic. – Dmitry Leskov Jan 31 '13 at 02:11
7
There are a number of tools that allow for decompilation of java programs, and they're fairly straightforward to use.
For example JD-GUI presents a graphical view of a loaded JAR file and makes navigating the code reasonably easy.
If someone wants to modify code in an application that they have access to, that's relatively straightforward and well documented for example this McAfee paper walks through the process of decompiling a program, modifying a Java Class and then re-compiling the program.
as @ThomasPornin said, relying on obfuscation is a bad idea for this kind of problem. If you let someone download a copy of a program you need to assume that an attacker would be able to get access to any information within the program and can bypass any security check that is only in place on the client-side.
Rory McCune
- 61,541
- 14
- 140
- 221
2
a small number of class files or JAR files is easy to reverse engineer (see answer from @Thomas). However, larger java applications e.g. J2EE that use many hundred JAR files and have hugely complex build scripts can be difficult to reverse engineer just because of the complexity of the code.
There are open source and commercial tools to help organise your code and make sense of it all, including an interesting Eclise plugin called VERA.
If you are just trying to learn about the structure of the code then there introspection tools that can help - as well as modelling tools such as Rational Suite/Enterprise Architect that can suck in java JARs and provide you with UML models.
Callum Wilson
- 2,543
- 11
- 16