Reverse Engineering Java - Deobfuscating symbols

Question

I'm new to Java and working on cleaning up a fairly large Java .jar sample where the obfuscator has renamed symbols into invalid names. For example:

import org.lib.00.0.2;

public final class 90
extends 2 {
    public 90() {
        90 iiIIiiiiiIiIi;
        90 v0 = iiIIiiiiiIiIi;
    ...
}

Using Recaf I am renaming these symbols that are using numbers but after doing so Recaf isn't able to find the renamed classes/packages and subsequent compiles with my code changes fail.

Are there any tools that will automate restoring the symbols to legal names? If not, how can I rename things in a way that won't break package/class paths?

Additionally, I'm considering if I should be using the decompiler at all and maybe just altering the ASM/instructions. I'm pretty comfortable with regular assembly and it seems this might dodge some of the obfuscation measures?

Thanks.

Answer 1

I'm not sure about tools specifically for your first question, but as for your second question, yes, definitely!

Decompilation is useful for understanding code, but it is terrible for modifying code. Compilation and decompilation are both lossy processes. Also, there's a lot of things you can do in bytecode that have no Java equivalent, so you shouldn't expect obfuscated bytecode to even decompile cleanly in the first place.

Disassembly and assembly by contrast doesn't lose any information and can cleanly roundtrip even to obfuscated bytecode, at least if you use a good disassembler like Krakatau. So if you are comfortable working with bytecode and are working with highly obfuscated bytecode, I would strongly recommend using Krakatau. For regular or moderately obfuscated bytecode (the most common case), other tools such as ASM will work as well, in case you want to use that instead. There are some bytecode quirks that ASM doesn't support properly, but I am not aware of any obfuscators in the wild that exploit them, so this is unlikely to be an issue in practice.

Note that the code you are working with may also be using introspection to try to detect tampering, so watch out for that. For example, some old versions of Stringer that I looked at would load themselves and count the number of constant pool entries in the classfile, so modifications would likely break them. (Krakatau makes it possible to avoid adding or removing constant pool entries if you're careful, but your best bet is to just analyze the code to find and remove the tamper checks)