Is there any open-sourced compilers for Java that able to produce bytecode-less output? I'm selling a Java application and I it to stop people from reverse engineering my program and giving it away for free.
There are ways to make java code hard to reverse engineer such as code obfuscators like ProGuard but that won't stop someone from giving it away for free.
To stop people from giving it away you need to use some kind of serial key that is assigned to each customer. At least that way if they give it away you know who did it.
If it runs on a computer, it can be reverse engineered. What you need is to use obfuscation. This way, your code will be harder to reproduce, because the logic in the obfuscated code is much more complex, than the code you originally wrote.
Related
From what I understand, obfuscating a java web application will just make it a little harder to read your application, but reverse engineering is still possible.
My goal is just to make it very difficult to read, and not be able to decompile and run (not sure if that's possible, I guess it will still run just with ugly variable names??)
So variable names like:
String username = "asdfsadf";
will become
String aw34Asdf234jkasdjl_asdf2343 = "asdfsdaf";
Is this correct:
public classes and variables will remain unchanged
ONLY private strings/classes/methods can be renamed
string encrytion can be used for some sensitive string data like encryption keys etc.
Really my goal is so that someone can't just decompile and release the code.
Web applications run server side. Clients will not see the code unless you mess things up.
There are plenty of good Java obfuscators which will do what you say, and much more. Here are some from google:
ProGuard
yGuard
JODE
Although these will make it much more difficult to read the decompiled code (and some decompilers will refuse to even try), keep in mind that it is always possible for someone to reverse-engineer the code if they have the binary, and are knowledgeable and patient enough.
The problem here is that the code needs to be in proper java syntax when you compile it. So no matter what obfustication you applied, if I have access to even just the bytecode I can figure out a way to reconstruct the source.
(http://www.program-transformation.org/Transform/JavaDecompilers#Java_Bytecode_Decompilers)
What you would need to do is keep the proprietary part of the software in such a place that your pirates would not be able to see it. As far as I am aware, that is the ONLY way to avoid hijacking your software.
You cannot prevent java code from being decompiled and run. Even if it is obfuscated, there may be people out there that are still able to figure out what your code is doing, despite the obfuscation. Everything you publish can be reverse engineered.
There exist even much stronger efforts in other languages to prevent decompiling and debugging, disk copy protection solutions for example, and even they get reverse engineered and hacked frequently.
If you don't want people to reverse engineer your code, let it run server side only, don't publish it and try to harden the server as much as possible.
http://www.excelsior-usa.com/protect-java-web-applications.html
Disclaimer: I work for Excelsior.
http://www.arxan.com/products/server/guardit-for-java/
Disclaimer: I don't work for Arxan.
No amount of obfuscation can protect you against "decompile & compile again" (without trying to understand what the code does). Decompilers don't care for unreadable variable names, nor do compilers.
Incidentally, if someone has access to your code, they don't need to decompile it to use it.
So the question is really: What do you want to achieve? When you know that then you can go to the next question: How much does it cost and how much money can I earn?
Usually, that equation is: You can't save/earn any money from obfuscation but doing it costs you time and money (good obfuscators aren't free). So it's a negative ROI.
Instead, try this approach: Create a great product (so people will feel it's justified to pay for it), fix bugs quickly (-> the thieves have to steal your work again and again just to keep up), add new features. That way, honest consumers have reason to buy from you.
If you plan to get money from thieves and criminals, well, forget it. They don't want to pay you, no matter what. You can make their lives a little bit harder but at a cost.
I want to protect some algorithms, from being reversed engineered. I know there is always a risk, but I want to make the work as complicated as possible. I know in Java there are ProGuard and other obfuscator. But the most knowledge isn't in the structure of the application, but in the numerical details of the algorithm. And reading about it, made me doubt on the protection of the algorithm.
Simple renaming some variables, wouldn't make it hard enough to reverse engineer the algorithms. Perhaps you can tell me, which methods would be more appropriate for algorithms and which of obfuscator may do the best work on algorithms.
At the moment I'm thinking about a bit handwork and to combine it with a tool.
Assuming that your algorithm should be executed as Java bytecode, on arbitrary JVMs. Then people can hack their JVM to dump the bytecode somewhere, no matter how much you obfuscate the class loading process. Once you have the bytecode, you can do control flow analysis, i.e. decide what information gets passed from where to where.
You can confuse the order of the individual instructions, but that won't change the computation. For someone who simply wants to run your algorithm unmodified, this doesn't change anything. How much a reordering will prevent people from modifying your algorithm very much depends on the algorithm and the complexity of the control flow.
You might be able to confuse the control flow using reflection in some obscure way, or by implementing your own interpreter and using that to run the algorithm. But both these approaches will likely come at a severe penalty to the performance of the algorithm.
In other languages (like native x86 code) you might be able to confuse the disassembler by introducing ambiguity about how the bytes should be split into instructions, using some bytes as tail part of an instruction in one case, but as a distinct instruction in other cases. But in Java there is no such option, the meaning of bytecode is too well defined.
One way you might be able to obfuscate things somewhat is by closely intermixing the algorithm with other steps of the program. For a straight-line program, this might make things a wee bit harder to track, in particular if you pass numbers through invisible GUI objects or similar bizarre stuff. But once you require loops or similar, getting the loop bounds lined up seems very hard, so I doubt that this approach has much potential either. And I doubt there is a ready-to-use obfuscator for this, so you'd have to do things by hand.
In my exeperience you can use .so file I.e. native implementation with java implementation and it is really hard to track with obfsucated code but only disadvantage is you will have to use JNI for that.
I don't want my class to be decompiled.
I have gone through some of the articles and found a patent site
Zelix KlassMaster
Is there any free tools available in the market which works in the similar way..
As far as I know there are no free tools with the same set of functions.
In my opinion the mix between ProGuard and Stringer Java Obfuscator is the best and also most cheap way to protect Java and Android applications.
N.B. I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.
Proguard is the best available free and open source obfuscator. Obfuscators jumble your class, field and method names so that it becomes difficult to make sense out of the decompiled code.
Zelix Klassmaster is a commercial obfuscator and is one of the best in the commercial space. Also, it has some additional feature to encrypt the string constants to that the strings arent visible when decompiled. There are also some other commercial tools like yguard, DashO-pro, Allatori and Smokescreen etc.
You can obfuscate your code, so that when it de compiles it isn't easy to read (for programmer)
You can't specifically stop it being decompiled. After all, a decompiler only has to be able to read the byte code to turn it into source code, and reading the byte code is also what the JVM has to do. So if you were to come up with some way to prevent programs from reading the byte code, the JVM wouldn't be able to run your class.
As others have pointed out, obfuscation is the way to go if you REALLY need to do this, but I would question whether you really do need to. It's also worth pointing out that if you do use obfuscation, finding bugs will be much harder because stack traces will also be obfuscated.
Obfuscation is certainly a way to protect your code. Also, there are other tools which encrypt your classes and provide a custom classloader which can decrypt and load your class at runtime. This is not a very foolproof way but yes there are tools doing that.
You can't prevent a java class from beeing decompiled. However, you can make the life of someone who will try to understand your code very very hard. This is the task of a so called obfuscator, like KlassMaster.
Please see this list for Open Source obfuscators.
Please see also one of my questions: https://stackoverflow.com/questions/1872170/how-to-protect-intellectual-property-in-java-app
Unfortunately in Java like in JavaScript getting to the source code is easy.
Understanding it is another thing.
If you try hard enough and send date through dozens of functions each doing a small part and passing it along then obfuscating it and maybe add some fake functions you might just give enough head eke to those with ill intentions enough of a head eke that they will quit before succeeding.
I'm using Zelix Klassmaster for my app Visual Watermark for about two years now. No new program "cracks" were released since then. So, it seems a good option for protecting Java apps.
I have an issue here..and its making me really nervous.
I was working on this game, and it was going great, so I took a copy of it on my laptop to work do some work while away from my computer.
long story short, hard-drive failure + poor back ups led to me losing a very important class.
Is there a way to decompile the apk to retrieve the bit of code that was lost? It isn't overly complicated or sophisticated, its just that its impossible to re-write it without reading every. single. line. of. code. in the entire application since it initializes a LOT of classes and loads a bunch of stuff in a specific way.
With a quick google search I was able to find apktool, which decompiles it into a bunch of .smali files, which I don't think were designed for human reading.
All I need to recover is one very big method in the class. I found the smali file that contains it and I think I found the line where it starts. something like
.method public declared-synchronized load(Lcom/X/X/game/X;)I
Anyone help would be appreciated since I would have to scrap the entire game without this method.
A quick google resulted in a way to decompile apks (decompile apk to java source). However, even though it results in java code, you probably won't have any variable names (just default ones like param1) as those are unrecoverably removed when you compile the source code to byte code, also, depending on the decompiler, for/foreach loops will be while loops instead, if/else blocks might not represent your original control flow due to compiler optimization.
As a general advise: Use some sort of source control. On your own server, paid account with github doesn't matter what, but use source control. Even if you are just one person developing on a project. It helps with this situation, it helps with reverting to a previous version, it helps finding a bug you introduced. When the tools are available, use them.
I'm about to port a smallish library from Java to Python and wanted some advice (smallish ~ a few thousand lines of code). I've studied the Java code a little, and noticed some design patterns that are common in both languages. However, there were definitely some Java-only idioms (singletons, etc) present that are generally not-well-received in Python-world.
I know at least one tool (j2py) exists that will turn a .java file into a .py file by walking the AST. Some initial experimentation yielded less than favorable results.
Should I even be considering using an automated tool to generate some code, or are the languages different enough that any tool would create enough re-work to have justified writing from scratch?
If tools aren't the devil, are there any besides j2py that can at least handle same-project import management? I don't expect any tool to match 3rd party libraries from one language to a substitute in another.
If it were me, I'd consider doing the work by hand. A couple thousand lines of code isn't a lot of code, and by rewriting it yourself (rather than translating it automatically), you'll be in a position to decide how to take advantage of Python idioms appropriately. (FWIW, I worked Java almost exclusively for 9 years, and I'm now working in Python, so I know the kind of translation you'd have to do.)
Code is always better the second time you write it anyway....
Plus a few thousand lines of Java can probably be translated into a few hundred of Python.
Have a look at Jython. It can fairly seamlessly integrate Python on top of Java, and provide access to Java libraries but still let you act on them dynamically.
Automatic translators (f2c, j2py, whatever) normally emit code you wouldn't want to touch by hand. This is fine when all you need to do is use the output (for example, if you have a C compiler and no Fortran compiler, f2c allows you to compile Fortran programs), but terrible when you need to do anything to the code afterwards. If you intend to use this as anything other than a black box, translate it by hand. At that size, it won't be too hard.
I would write it again by hand. I don't know of any automated tools that would generate non-disgusting looking Python, and having ported Java code to Python myself, I found the result was both higher quality than the original and considerably shorter.
You gain quality because Python is more expressive (for example, anonymous inner class MouseAdapters and the like go away in favor of simple first class functions), and you also gain the benefit of writing it a second time.
It also is considerably shorter: for example, 99% of getters/setters can just be left out in favor of directly accessing the fields. For the other 1% which actually do something you can use property().
However as David mentioned, if you don't ever need to read or maintain the code, an automatic translator would be fine.
Jython's not what you're looking for in the final solution, but it will make the porting go much smoother.
My approach would be:
If there are existing tests (unit or otherwise), rewrite them in Jython (using Python's unittest)
Write some characterization tests in Jython (tests that record the current behavior)
Start porting class by class:
For each class, subclass it in Jython and port the methods one by one, making the method in the superclass abstract
After each change, run the tests!
You'll now have working Jython code that hopefully has minimal dependencies on Java.
Run the tests in CPython and fix whatever's left.
Refactor - you'll want to Pythonify the code, probably simplifying it a lot with Python idioms. This is safe and easy because of the tests.
I've this in the past with great success.
I've used Java2Python. It's not too bad, you still need to understand the code as it doesn't do everything correctly, but it does help.