Java Obscured Obfuscation

Question

Related questions : Here and Here

I assume the situation is rather unusual to begin with, and therefore I admit that it is probably too localized for SO.

Problem

public class bqf implements azj { ... public static float b = 0.0F; ... public void b(...) { ... /* b, in both references below, * is meant to be a class (in the * default package) * * It is being obscured by field * b on the right side of the * expression. */ b var13 = ba(var9, var2, new br()); ... } } 

Error: cannot invoke a(aji, String, br) on primitive type float .

Compromise restrictions:

• Field b cannot be renamed.
• Class b cannot be renamed or reorganized.

Why

I am changing a confusing program. For irrelevant [?], Unknown (for me) and uncompromising reasons, the modification should be done by correcting the original jar using .class files. Consequently, renaming a public field b or class b will require modification of most of the program. Since all classes are in the default package, to refactor class b, you will need to change each class that references b (most of the program). However, there is a significant modification that I intend to do, and it hurts to do this at the bytecode level; just not enough to guarantee renaming / refactoring.

Possible solutions

• The most obvious is renaming / refactoring. There are thousands of classes, and each one is in the default package. It seems that every java program I want to change has this obfuscation :(

  In any case, sometimes I take the time to simply rename / reorganize the program manually. But when when there are too many mistakes (I once made 18,000), this is not a viable option.

• The second obvious option is to do this in bytecode (via ASM). Sometimes it’s normal when the changes are small or simple enough. Unfortunately, modifying the bytecode only for files that I cannot compile through java (which is most of them, but this is what I usually try to do), it compares very slowly.

• Sometimes I can extend class b and use it in my modified class. Obviously, this will not always work, for example, when b is an enumeration. Unfortunately, this means many additional classes.

• Perhaps you can create a class with static wrapper methods to avoid ambiguity. I just thought about it.

• A tool that reassigns all names (not deobfushat, only unique names), and then cancels them after making changes. That would be nice. I have to do one if it does not exist.

• The problem will also be solved in order to force the java compiler to require the keyword "this".

Answer 1

 ba(var9, var2, new br()); 

can be easily rewritten using reflection:

 Class.forName("b").getMethod("a", argTypes...).invoke(null, var9, var2, new br()); 

The problem will also be solved in order to force the java compiler to require the keyword "this".

I do not think how this will help you for a static member. The compiler should require us to qualify everything, basically, to prohibit simple names in general, except for local ones.

Answer 2

Write a helper method elsewhere that calls ba (). Then you can call it.

Note. In Java, the convention is that the class will have the name B , not B (which also applies to bqf and aqz), and if this were done, the problem would not be shown.

Real long-term treatment should not put classes in the default package.