jadx
jadx copied to clipboard
support use Android mapping.txt to deobfuscation
can it support use Android mapping.txt to deobfuscation? I want to use custom mapping.txt to deobfuscation my source code,but I have no way to do that
This is very much needed feature for investigating our own apk file. For example, we can check whether we correctly did proguard configuration to retain a particular method, yet allowed obfuscation. Since we have mapping.txt with us, deobfuscation will make it much easier for us to verify the code in resulting apk.
If there is such a commandline tool that takes apk and the mapping.txt, it could be easily integrated with jadx. Or may be it is a matter of identifying substitutions from the mapping file. I already see that jadx has a setting to use substituting file name to class name. This feature would be an extension of that.
Hey @skylot (or any other maintainer), if you think it's a valid addition to the tool, I can help writing this :smile:
I really think it can help in cases such as using a custom dictionary in ProGuard configuration, and you need to debug if your dictionary is not messing up with class names or anything like that. As you may know, obfuscation can be really messy if you go too far on the ProGuard (or any other tool like that) configuration.
@Horaddrim sure, this is a nice feature and you can implement it if you want :+1: For start you can look at RenameVisitor and Deobfuscator classes and make similar parser as currently done at DeobfPresets. And feel free to ask any questions :)
It would be easier to implement this feature request if someone could provide a sample Proguard mapping file and attach it to this issue.
@jpstotz I collect some info about Proguard mapping file:
- Mapping specs and description (scroll to Mapping section)
- Source code from Proguard for parsing mapping file
- Sample app (just example from Android Studio): mapping.txt and app-release-unsigned.apk.zip
So, looks like parsing is not hard, but it needs some work for integration into jadx to support both mappings format. Quick TODO list:
- New options in cli and gui:
--deobf-file-format
(jadx
orproguard
),--deobf-file
(for load user file, new menu item in gui) - Refactor
Deobfuscator
class to use new interface for save/load mapping file - Implement that new interface for both formats
- Also this can break
rename
branch as soon it usesjadx
mapping for renaming
Hey everyone, just leaving some hints here because I wished I had some. I also needed this feature badly while decompiling an massive project. Therefore I started work on an converter that takes mapping.txt and spits out an .jobf file - I was able to make it convert, but then when opening in jadx, I noticed it wasn't able to move classes to other packages (with that proguard configuartion, all obfuscated classes got moved to the default package, and there is no way to undo that with a jobf file). So well, it definitefly needs an jadx patch to allow moving classes around packages with an jobf file but the rest should be doable with an converter like I wrote. Now the need to decompile is gone and I never continued from this point, but if anyone wants to have the converter (that does not work correctly due to the limitation) and is willing to finish it, let me know.
obfuscated classes got moved to the default package, and there is no way to undo that with a jobf file
@nift4 thanks for bringing up this issue! That should be fixed, but right now I'm not sure how exactly. We can add package in class rename line if original package is empty. But this can interfere with package renames because there is no original package, so this can lead to a lot of changes in deobfuscator code. I think I will open new issue for this change, because it is not related to 'mapping.txt' issue and also affect jadx-gui.
@skylot @jpstotz Is any possible add this feature in the future? That is helpful if the feature is integrated.
@01Sr work in progress right now. Implementation use FabricMC/mapping-io library to support various mapping formats including proguard. Although, proguard is slightly harder because mapping needs to be reversed before apply.
Can you share .jobf structure