How to decompile confusing java programs avoiding class and package name conflicts

Question

I want to decompile a java program and recompile the received (obfuscated) source. I unpacked the .jar archive and got this directory structure:

com/ com/foo/A/ com/foo/A/A.class com/foo/A/B.Class com/foo/B/A.class ... com/foo/A.class com/foo/B.class org/foo/Bar.class ... 

The problem is that there are name collisions between packages and classes, which makes it impossible to recompile decompiled class files. The decompiled class will look like this:

 package org.foo; import com.foo.A; // <-- name collision error class Bar { ... } 

Is there a way to solve these name problems without renaming the class files?

EDIT: This is not a decompiler problem, but the question of how you can create a working .jar file with classes that violate naming conventions.

EDIT2: Well, I think at the bytecode level this naming is possible, so with a smart decompiler (which automatically renames classes and corrects their references), this problem can be solved.

Answer 1

The Java import mechanism provides an abbreviation for things, but you obviously cannot use it when there are collisions. You can always use the full name in your code, for example

 package org.foo; class Bar { private com.foo.Bar aDifferentBar; ... } 

EDIT:

I assume that there may be class files that conform to the JVM specification, but which cannot be created by a Java program that conforms to the JLS specification. If so, you will definitely need a smarter decompiler.

Answer 2

You cannot import packages in Java, so why should it be a name clash? What error message do you get from the compiler?

If there is a clash of names in the obfuscation code, the code will not work. Thus, the decompiled code should be without conflict.

Answer 3

Do you really need to unpack the entire jar and recompile everything? Instead of recompiling the entire decompiled source yourself, use the source jar as the classpath and extract and recompile only the classes you need to change. Then, when you need to pack your recompiled code, just copy the source jar and use jar -uf to replace the modified class files in place:

 jar -uf ./lib/copy_of_original_jar_file.jar -C ./bin com/foo/A.class com/foo/B.class [...] 

... and. / lib / copy _of_original_jar_file.jar becomes your new library.

One thing is certain, and this means that the original jar must work correctly with the Java class loader for the program to start. It should work the same as compiling your classmate .class files.

You should have much less name conflict problems using the original jar because you keep the same class pool scan order as the running application. Not only that, but Java decompilers are not perfect. By eliminating the need to recompile most of the decompiled codes, you avoid most of the problems that decompilers have with similar overlays of exception handlers, special characters in obfuscated characters, problems with variable visibility, etc.