Is there a tool to deobfuscate java obfuscated codes?
The codes is extracted from a compiled class but they are obfuscated and non-readable.
+7
A:
First step would be to learn with which tool it was obfuscated. Maybe there's already a "deobfuscator" around for the particular obfuscator.
On the other hand, you can also just run an IDE and use its refactoring powers. Rename the class, method and variable names to something sensitive. Use your human logical thinking powers to figure what the code actually represents and name them sensitively. And the picture would slowly but surely grow.
Good luck.
BalusC
2009-11-02 18:10:24
I don't know what obfuscator is used.And on the decompiling process some methods and variables appears as "???" and they are coming from nowhere!I'm using JD-GUI http://java.decompiler.free.fr/
Salar
2009-11-02 18:33:20
JDO can help doing that. See http://stackoverflow.com/questions/1662766/tool-to-deobfuscate-java-codes/1662928#1662928
Pascal Thivent
2009-11-02 18:45:58
Ah, that way. Well, then the decompiler didn't support the original compiler version, e.g. decompiling against Java 1.5 while the code was compiled with 1.6. This ain't going to work. Read the decompiler's documentation and/or try different ones.
BalusC
2009-11-02 18:47:16
A:
No. If there was, there would be no point in obfuscating in the first place.
There are only a few reasons I can think of to need to unobfuscate code:
- You were careless, didn't back up your source, and it got lost.
- You're trying to use code that doesn't belong to you, which is unethical.
- You bought something without spending the extra money to buy the source code, so you're trying to reverse that bad decision now.
None of the above are good reasons.
Ken White
2009-11-02 18:10:31
Hmmm, what about forensic analysis of a problem (for security holes, backdoors, etc), that isn't a good reason?
C. Ross
2009-11-02 18:12:10
How about ethical white-hat hacking, to test the strength of the obfuscation of your own code?
Yishai
2009-11-02 18:12:16
@BalusC, although I generally agree, sometimes management just wants it, and if your code consists of an algorithm that would be very useful to copy, and it enforces a license key scheme, it makes it harder to just "take it" and bury it in a web application somewhere. Sure the obfuscation is breakable, but breaking it can make enough noise that an employee might blow the whistle - increasing the risk, and thus reducing the incentive.
Yishai
2009-11-02 18:18:23
@C. Ross I don't believe in *Security through obscurity* (http://en.wikipedia.org/wiki/Security_through_obscurity)
Pascal Thivent
2009-11-02 18:22:57
@Pascal, no, but I believe in obscurity through obscurity. Obfuscation isn't security, but that doesn't mean it has no purpose.
Grumdrig
2009-11-02 18:30:13
Well the code is from my own company but it is very old and it is written by former members. Currently no one knows what tool is used to obfuscate that. :(Maybe it should be written again but it seems it doesn't worth it.
Salar
2009-11-02 18:33:55
@Grumdrig Did I says that? I was just answering C. Ross about security holes, backdoors, etc.
Pascal Thivent
2009-11-02 18:34:09
Forensic analysis in court cases is another justifiable purpose. Companies get bought and sold and sometimes they need to figure out what the shipped code looked like at some point.
Alex Feinman
2009-11-02 18:54:14
I don't think this answer is helpful. Telling the OP they are either 1. stupid, 2. evil, or 3. cheap does not help anyone. And just because something is obfuscated does not imply that it can't be obfuscated.
Peter Recore
2009-11-02 19:05:17
@Salar: So the code is from your own company but you don't have the source? How is that possible? Don't you use version control and have backups?
Ken White
2009-11-02 19:06:12
@C. Ross, @Alex: I concede that I missed forensic analysis in my list, and that it *might* be an exception to the "no good reasons" statement.
Ken White
2009-11-02 19:08:26
@Peter: It was obfuscated for a reason. Otherwise, no one would have gone to the effort. I mentioned reasons I could think of to need to obfuscate. Sorry you don't find it useful. Others have pointed out a couple of other reasons; I've conceded them.
Ken White
2009-11-02 19:12:34
@Ken White, that's not my fault! we have TFS now but the software is old seems they didn't have such version controlling that time! (I wasn't here)
Salar
2009-11-02 19:22:00
(my own company = the company i work for) sorry for my english!@Peter, I agree with you; don't just complain when you don't know the answer.
Salar
2009-11-02 19:24:41
@Salar: I wasn't complaining. And I was providing an answer; my answer was that, except under very rare circumstances, you shouldn't need to unobfuscate. Trying to reverse the obfuscation of code is similar to trying to decompile an executable - most of the time it's being done for the wrong reasons (with *rare* exceptions).
Ken White
2009-11-02 19:44:57
+3
A:
Did you try to make the code less obscure with Java Deobfuscator (aka JDO), a kind of smart decompiler?
Currently JDO does the following:
- renames obfuscated methods, variables, constants and class names to be unique and more indicative of their type
- propogates changes throughout the entire source tree (beta)
- has an easy to use GUI
- allow you to specify the name for a field, method and class (new feature!)
Currently JDO does not do the following (but it might one day)
- modify method bytecode in any way
Pascal Thivent
2009-11-02 18:44:04
A:
Most likely only human mindpower to make sense of it. Get the best decompiler available and ponder on its output.
Thorbjørn Ravn Andersen
2009-11-02 19:09:34
A:
I used Java Deobfuscator (aka JDO) but it has a few bugs. It can't work with case sensitive file names. So I've changed the source and uploaded a patch for that in sourceforge. The patch, Download
Salar
2009-11-03 17:07:30