I work for a government contractor that is really picky about what software gets installed on their machines (US government laws). As part of a reverse engineering effort, I need to figure out what a certain set of .class files do. A decompiler would be really helpful, but I can't seem to find one that meets the standards set here. Basically, I need to find a decompiler that was developed in the United States. Anyone know of any? Free is preferred, but commercial will do.
FYI, JAD and JD are out as they are not developed in the US.
I'd inform your employer that putting preconditions on where the software comes from isn't going to protect them, and it's not going to get them what they want. The U.S. competes in a global economy and in the global internet. It sounds a little childish of them to think that they gain any advantage or security from not installing software that works. Part of being a good employee, designer, or programmer is helping your client realize their limitations and overcome them. You should help them to greater success.
What about installing "unapproved" software on a VM?
It scares me when I hear this type of nonsense eminating from my own government.
Run jad -p, recompile the source and compare the compiled class with the origional class file.
You can run jad on a throwaway computer/VM instance. If there is reasonable agreement on the compiled class you know the software functioned properly.
I figured that I should answer this since nothing provided worked. I ended up solving the requirements by using javap, guessing a lot, and banging my head against the desk until it worked. javap didn't give me much of what I needed, since it called a lot of native code. Eventually, I got what I needed using the tried and true guess and check method.
There really needs to be a decompiler. Maybe Sun (Oracle) can make one...
I'm assuming that you can't move the .class files off of the machine and on to a lab machine where you can install JAD?
I work with the government as well and if a particular piece of software is critical to the success of your project, you need to communicate that to your PM, who will then communicate that to his or her government counterpart. After that, there should be a checklist for your IA assessors to follow to approve that piece of software.
Procyon is all-American, it is developed by Mike Strobel. According to Mike's profile page, he is in Manhattan.
I assume that it's legal for you to be decompiling them in the first place, right? Most user-agreements I've read state that you aren't allowed to reverse engineer anything... Assuming it's legal, how come JAD and JD are out?
I've had success with DJ Java Decompiler, though it's not nearly as pretty as JD. There's also SoThink Java Decompiler, but I've never used it personally.
There are several others, but most of them seem to be built upon JAD, so I guess they're out too.
I once used cavaj (freeware), but I don't know whether it is made in the US.
mmmh pretty ironic, you cant use a decompiler because the decompiler isent made in the US but you can decompile code nevertheless ?
If you need to know what a class does then ask the people that created it for the source
If they refuse to give the source then i dont think its legal to decompile it anyway
Here's an idea, can you send the files to someone else to decompile and then just send you the decompiled source?
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.
Now, I know that...
Anything can be reverse engineered, given enough time and resources.
However, would compiling your Java code to native code with a tool like GCJ make it more difficult to decompile? I mean, given a few minutes, I can decompile a .jar using JD-GUI, and it is relatively accurate. Most of the "Java to EXE" converters are just .exe launchers for the JVM, and while there are many benefits to the JVM, I have been led to believe that security of the source code is not one of them.
Bottom line: Can you use something like GCJ to compile your Java source (or .class) files to native machine code, and if so, will that protect it from decompiling?
EDIT: Ideally, it would be something more than just obfuscation. The specific project is a commercial game, so what we are looking for is a way to make it more difficult to get to the source code to begin with, not just understand it. Also, I'm not sure that Steam accepts .jars, and we are planning on submitting it to the new Green Light project.
I wouldn't choose that approach just for source-security.
Check out some Obfuscator tools out there like ProGuard
If you want to see what those tools do to your source code, just try read the decompiled Minecraft jar if you have one on hand.
A downside to using this is, that if your code depends on using reflection, you'll have to configure the tools to ignore those functions/classes/whatever, as those will not be found at runtime otherwise.
Technically, yes. Using something like GCJ will make it harder to decompile, however keep in mind that you are losing some major benefits of using Java if you do this. Namely, you lose the ability to write cross-platform applications.
You could use an obfuscator to make the code harder to decompile AND still keep the benefits of using Java.
a Source code obfuscator like
this , this and this
makes your variables, functions, etc... unreadable by other(has no logical meaning). You should read here too!
I have written an application in Java on my windows machine and want to package it for my Mac. I am aware of JarBundler, and initially I thought it would be perfect because I was going to obfuscate the .jar with ProGaurd anyway, however: when I obfuscate the application I run into problems on Mac with the AboutHandler and QuitHandler.
I have been looking around and I noticed the there is no .jar file in the Eclipse (IDE) .app, even though I am lead to believe it was written in Java, and so this seems to be what I need. The only problem is I have no idea how it is done, and I was hoping one of you could guide me please. I have read that Mac users do tend to have a different mindset and applications don't tend to get hacked as much, and I know that it will still take a decompiler to read the source however, if I can do something like this I would rather like to. For me, anything I can do to help to prevent people reading the source code is a merit, the only problem is for some reason obfuscation isn't playing ball!
Thanks in advance
The Eclipse IDE uses a native launcher, but hands off control to Java after the initial startup. The IDE itself is indeed written in Java.
What are the problems you run into with AboutHandler and QuitHandler?
Unfortunately this is not possible. It was my careless mistake that Eclipse managed this when in actually fact it is only a native launcher and the .jar files are stored elsewhere as Ewald and Edvin Syse have correctly pointed out.
So I guess the real answer to my question is "you can't". As long as you use Java, you're going to have to live with jars and thats the end of it. But to be honest, I don't think that's all to bad as the internet makes out. An exe is just as easy to deconstruct to a 'windows hacker' as a jar is to a 'Java hacker', etc. and that's something you have to live with.
In reality though, you have to think about the odds of any of the audience you really care about hacking your software. Is it really worth all this stress and hard work just to add an extra layer of protection that only frustrates hackers and makes them more determined?
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' looking for a java obfuscator that will at a minimum rename all private method names, inner method variables such that reading the source code and decompiling a jar will make it unfriendly to do so.
I realize it isn't that hard to get algorithm knowledge etc., I just want it to be a pain to decompile and thus maintain the decompiled code.
The goal is to prevent someone from decompiling the source and simply using it w/o having to do any work. I don't care if they can figure out my algorithms etc., I just don't want it to be super easy where they can just decompile the .jar and add the 100% visible and readable source code into their project.
Suggestions?
ProGuard is what I use.
http://proguard.sourceforge.net/
has a nice easy to use GUI or can be implemented into ant scripts. Also offers optimization and some other nice features.
Obfuscation is not your only option. See my article "Protect Your Java Code - Through Obfuscators and Beyond". If nothing else, you will find there links to actively maintained obfuscators.