I have came across many Java obfuscators which just renames the class names and that can be viewed by online java decompilers. But I want a obfuscator which generates output that cannot be decompiled using any tools. ( We can obfuscate the .net projects in such way ).
Please suggest me such java obfuscator ?
Search for "flow obfuscation".
Decompilation is always possible. However, a lot of decompilers expect bytecode to be generated by regular compilers like javac and have trouble to restore compilable Java sources from flow-obfuscated classes. The results are more often than not so broken that it is hard for a human to recognize the original (Java high-level) control flow. That creates an additional hurdle that can only be overcome by investing more time in bytecode analysis.
Be aware, however, that it's a race: decompilers are also becoming better at this. So you should always test the obfuscated results against all decompilers you can get a hold off.
We've used an obfuscator called "allatori" (together with a second mostly name-based obfuscator) in a project with quite satisfactory results.
As Stefan mentioned flow obfuscation is an easy way to mess with older decompilers. For modern decompilers you're going to have to put in more effort. Heres some features you can search for:
Synthetic Modifiers (JD-GUI does not show synthetic members)
Opaque Predicates (Think of this as junk code that can't be resolved statically)
String Encryption
Not sure what it's called but replacing all invokes with invokedynamics is cruel. Requires Java 8 to run and decompile.
Everything is reversible but it'll make it more of a pain.
Related
How can I package my Java application into an executable jar that cannot be decompiled (for example , by Jadclipse)?
You can't. If the JRE can run it, an application can de-compile it.
The best you can hope for is to make it very hard to read (replace all symbols with combinations of 'l' and '1' and 'O' and '0', put in lots of useless code and so on). You'd be surprised how unreadable you can make code, even with a relatively dumb translation tool.
This is called obfuscation and, while not perfect, it's sometimes adequate.
Remember, you can't stop the determined hacker any more than the determined burglar. What you're trying to do is make things very hard for the casual attacker. When presented with the symbols O001l1ll10O, O001llll10O, OO01l1ll10O, O0Ol11ll10O and O001l1ll1OO, and code that doesn't seem to do anything useful, most people will just give up.
First you can't avoid people reverse engineering your code. The JVM bytecode has to be plain to be executed and there are several programs to reverse engineer it (same applies to .NET CLR). You can only make it more and more difficult to raise the barrier (i.e. cost) to see and understand your code.
Usual way is to obfuscate the source with some tool. Classes, methods and fields are renamed throughout the codebase, even with invalid identifiers if you choose to, making the code next to impossible to comprehend. I had good results with JODE in the past. After obfuscating use a decompiler to see what your code looks like...
Next to obfuscation you can encrypt your class files (all but a small starter class) with some method and use a custom class loader to decrypt them. Unfortunately the class loader class can't be encrypted itself, so people might figure out the decryption algorithm by reading the decompiled code of your class loader. But the window to attack your code got smaller. Again this does not prevent people from seeing your code, just makes it harder for the casual attacker.
You could also try to convert the Java application to some windows EXE which would hide the clue that it's Java at all (to some degree) or really compile into machine code, depending on your need of JVM features. (I did not try this.)
GCJ is a free tool that can compile to either bytecode or native code. Keeping in mind, that does sort of defeat the purpose of Java.
A little late I know, but the answer is no.
Even if you write in C and compile to native code, there are dissasemblers / debuggers which will allow people to step through your code. Granted - debugging optimized code without symbolic information is a pain - but it can be done, I've had to do it on occasion.
There are steps that you can take to make this harder - e.g. on windows you can call the IsDebuggerPresent API in a loop to see if somebody is debugging your process, and if yes and it is a release build - terminate the process. Of course a sufficiently determined attacker could intercept your call to IsDebuggerPresent and always return false.
There are a whole variety of techniques that have cropped up - people who want to protect something and people who are out to crack it wide open, it is a veritable arms race! Once you go down this path - you will have to constantly keep updating/upgrading your defenses, there is no stopping.
This not my practical solution but , here i think good collection or resource and tutorials for making it happen to highest level of satisfaction.
A suggestion from this website (oracle community)
(clean way), Obfuscate your code, there are many open source and free
obfuscator tools, here is a simple list of them : [Open source
obfuscators list] .
These tools make your code unreadable( though still you can decompile
it) by changing names. this is the most common way to protect your
code.
2.(Not so clean way) If you have a specific target platform (like windows) or you can have different versions for different platforms,
you can write a sophisticated part of your algorithms in a low level
language like C (which is very hard to decompile and understand) and
use it as a native library in you java application. it is not clean,
because many of us use java for it's cross-platform abilities, and
this method fades that ability.
and this one below a step by step follow :
ProtectYourJavaCode
Enjoy!
Keep your solutions added we need this more.
I got the Java classes from an APK after using some tools like dex2jar and JD-GUI. As everybody knows Java byte code can be converted to Java classes back so mostly it is optimized and obfuscated through some tools (like ProGuard is used in the case of Android) to make it secure from others. So what I got is obfuscated code and I want to make it error-free, readable, understandable so that I can further modify it for my own purpose (for my personal use only, I don't mean to violate any copyrights). So any help i.e advices, tools, helping material to make this obfuscated code much closer to what was written by a developer or to make it error-free and understandable will help me a lot. Currently my focus is about to reversing obfuscating techniques used by ProGuard like when I tried reverse engineering on my own projects and found that:
int resource values can be altered with ids by matching through the R file which is generated with reverse engineering.
The if/else conditions mostly converted to while(true) and some continues and breaks.
Inner classes mostly broke up to separate files
So, any other techniques and helping material for the above mentioned ways which can describe how to properly reverse them will be very helpful.
There isn't a magical tool that will refactor obfuscated code into a buildable project. Most likely, you won't be able to decompile and de-obfuscate an APK to be clean and maintainable code. This is a good thing.
There are tools which are better than dex2jar and jd-gui. One of them is apk-deguard, which claims to reverse the process of obfuscation. From their about page:
DeGuard
DeGuard (http://www.apk-deguard.com) is a novel system for statistical
deobfuscation of Android APKs, developed at the Software Reliability
Lab, ETH Zurich, the same group which developed the widely used JSNice
system. Similarly to JSNice, DeGuard is based on powerful
probabilistic graphical models learned from thousands of open source
programs. Using these models, DeGuard recovers important information
in Android APKs, including method and class names as well as
third-party libraries. DeGuard can reveal string decoders and classes
that handle sensitive data in Android malware.
You should use Enjarify, which is owned by Google, instead of dex2jar. Also, apktool is good for decompiling an APK's resources, which is not handled by dex2jar and enjarify.
Other tools include jadx, procyon, fernflower, show-java, smali/baksmali.
You will need a good IDE for refactoring. JEB looks like a good tool for refactoring. This is a paid tool mostly used by Android security researchers.
This should help:
DeObfuscator
Reverse engineering is a difficult task (i would say subtle art), mostly hit and miss, especially with obfuscated code, what you can do is to focus in some special function, that seems pretty obvious and start from there, renaming and refactoring classes, also a good IDE may help you a lot (my personal recommendation: NetBeans).
I'm looking for a Java macro language that provides for convenient ways of doing closures (that compile to anonymous inner classes) and list comprehension (that compiles down to basic java loops).
An example of the kind of thing I'm looking for would be Xtend2 http://www.eclipse.org/Xtext/#xtend2
But I want something for general purpose programming (Xtend2 is very specific DSL for Xtext and has a ton of dependencies). Maybe even something that would let me define multiple classes in a single file (which would then get split up into two separate files by the pre-processor).
Does anything like this exist?
Edited to add:
I'm doing Android development so any alternatives have to generate either valid Java source or the byte code has to be compatible with the dalvik recompiler.
Mmm, there used to be the JSE, which was tremendous fun, back in the day.
Mirah is cool, but not ready for primetime, IMO.
You can do a lot with smart templating, although your source view is the Java.
There's a post on SO about using XTend on Android from a few days ago, too.
Frege produces java source code.
I do not know whether dalvik would like it. (But I would be interested to hear ...)
And, of course, you have some runtime library code.
That being said, there are a number of other projects that do closures etc. in java, for example: lambdaj
I require a source code obfuscator for Java that is working on windows 7.
Because I plan to release a closed source library in GWT it really has to be an obfuscator that outputs source and does not process ready to use .class files. The result files need to be .java files.
The only obfuscator that is Java-to-Java instead of .class as a result is Java Source Code Obfuscator from Semantic Design.
But sadly it seems this one does not work on Windows 7.
What about compile it into class files with all the debugging symbols stripped and then run a decompiler on the resulting class files? Example decompiler
Despite the existence of some quality work out there, I assure you Java obfuscation will NOT stop someone who is determined to decompile your code. Understand that all you are buying is a bit of time. If they have your class files in hand and choose to decompile them, it won't take long before they have your source code.
If you don't trust your customer, don't give them the class files. Come up with a different solution. More and more companies are moving to services as a way to keep their source code in house and still make their monies.
Most Java source codes are self obfuscated, nobody can understand them.
There are no effective obfuscators, the silly things they do do not deter anyone determined to steal your code. This is a false market based on false fears. If the threats were real, there will be de-obfuscators, selling for much higher price than obfuscators.
If you really want to obfuscate your code, don't use meaningless symbols, use misleading symbols.
Sometimes when decompiling Java code, the decompiler doesn't manage to decompile it properly and you end up with little bits of bytecode in the output.
What are the weaknesses of decompilers? Are there any examples of Java source code that compiles into difficult-to-decompile bytecode?
Update:
Note that I'm aware that exploiting this information is not a safe way to hide secrets in code, and that decompilers can be improved in the future.
Nonetheless I am still interested in finding out what kinds of code foxes todays crop of decompilers.
Any Java byte code that's been through an obfuscator will have "ridiculous" output from the decompiler. Also, when you have other languages like Scala that compile to JVM byte code, there's no rule that the byte code be easily represented back in Java, and likely isn't.
Over time, decompilers have to keep up with the new language features and the byte code they produce, so it's plausible that new language features are not easily reversed by the tools you're using.
Edit: As an example in .NET, the following code:
lock (this)
{
DoSomething();
}
compiles to this:
Monitor.Enter(this);
try
{
DoSomething();
}
catch
{
Monitor.Exit(this);
}
The decompiler has to know that C# (as opposed to any other .NET language) has a special syntax dedicated to exactly those two calls. Otherwise you get unexpected (verbose) results.
The JDBC type-4 drivers for DB2 Connect are classics. Everything called one or two-letter names, irrelevant code that ends up having no effect, and more. I once tried to take a look to debug a particularly annoying problem and basically gave up. I'm hoping (but by no means confident) that this was passed through an obfuscator rather than the code actually looking like that.
Another favorite trick (although I can't remember the product) was to rename all objects to be constructed from the set {'0','O','l','1'}, which made reading it very difficult.
Assuming you can decompile back to a reasonable style of source code (you can't always do that), what is hard to "reverse engineer" are algorithms that operate in unfamiliar problem domains. If you don't understand Fast Fourier transforms, it doesn't matter much if you can get back the code that implements an FFT Butterfly.
(If this phrase is unfamiliar to you, I've already won if I encode one. If it is familiar to you, you are a pretty good engineer and probably don't have any interest in reverse engineering code). [Your mileage with North Koreans may vary.]
Java keeps a lot of information in the bytecode (for instance many names). So it is relatively easy to decompile. Hard to decompile bytecode mostly is generated by hard to read sourcecode (so that's not really an option). If you really want to obfuscate your code, use a obfuscator, that renames all methods and variables to unrecognizable stuff.
Exceptions are often difficult to decompile.
However, any code which has been obfuscated or has been written in another language is difficult to decompile.
BTW: Why would you want to know this?
Java Bytecode does not correspond directly to Java constructions, so decompiling implies that you know that a certain java byte code sequence corresponds to a Java code construction.
The Soot framework for decompiling java byte code has a lot of information on this, but their webpage is down for me right now.
http://www.sable.mcgill.ca/soot/