Renaming entitites in obfuscated java bytecode

Question

I'm working with an SDK for developing apps that's distributed as an AAR, and has been obfuscated with ProGuard. I'm just trying to reverse a few things it does. The classes, methods and variables have been obfuscated, I'm pretty sure with ProGuard. I've been looking for a toolchain that would give me a better workflow than my current one but can't find what I need.

Here's what I'm doing now:

• Created a sample app in Android Studio that calls the things I care about in the SDK
• Set breakpoints and step into the code I'm interested in
• Using the Android Studio decompilation (I wasn't expecting it to have that, awesome!), start working out what the different variables, methods, and classes are for and giving them names.
• Write those names down in an ASCII notes file for reference
• Go back and forth from my notes to the code, screaming while my brain loses grip on all the mappings I'm trying to keep in my head

Here's what I'd like to do:

• Run my sample app in Android Studio, step into the obfuscated bytecode as before
• As I figure out a method, relabel it in the code browser, have that relabel propagate to all invocations of that method, similar to a "refactor" action in many IDEs
• Become sane again, see my family, make progress

I would think some kind of baksmali / smali parser / smali assembler process should achieve this but I can't find anything out there yet that does it. Virtuous Ten might be able to do it, but it craps out in unclear ways trying to generate smali on my SDK jar. I get zero smali or java when I run it on my jar.

Any ideas?

Answer 1

You may want to try jadx, which supports decompiling *.aar since v0.6.1. You could save the decompiled code as a Gradle project, which you could then open it in Android Studio and do the refactoring.

---

Alternatively, note that *.aar is basically a *.jar and Android resources bundled together. You cannot use baksmali, the *.jar still contains JVM bytecode and not converted to dex! You just need to:

1. Rename the *.aar to *.zip and unzip it
2. Decompile the classes.jar
3. Create a project with the decompiled *.java files
4. Use "Refactoring" to rename, etc.

---

Both of these methods only support static analysis, you cannot debug an app using the decompiled result. Unless the decompiled result can actually be compiled, which you could link your sample code with them instead of the library.

Also, these won't help if the real code are compiled with NDK (check if there are any *.so files when you unzip the *.aar).

Answer 2

As I figure out a method, relabel it in the code browser, have that relabel propagate to all invocations of that method, similar to a "refactor" action in many IDEs

While my project doesn't have IDE integration I think I made exactly what you're looking for. Mostly because I made it for similar reasons.

Its a GUI that decompiles code with CFR but links class and member names to the decompiled text. To rename them you simply click the name or member, type in a new name and hit enter. You can export your changes as a text file or as a updated jar file.