More detailed reporting of detected mappings?

[avahidi]

Is there a way to retrieve the mappings from obfuscated to real class/package name? This would be very useful if I want to do some analysis on the library files as found in the app - which for various reasons may not 100% match the files in the original library JAR (e.g. due to dead-code elimination).

Example:

{
	"libName": "Facebook",
	"package-mappings": {
		"a.a.a": "com.facebook.applinks".
		"a.a.b": "com.facebook.login",
		...
	},
	...
}

Or even

{
	"libName": "Facebook",
	"class-mappings": {
		"a.a.a.a": "com.facebook.applinks.AppLinkData".
		"a.a.a.b": "com.facebook.applinks.FacebookAppLinkResolver",
		...
	},
	...
}

[reddr]

The json output currently includes two fields "isOriginalPackageName" and "libRootPackage". The latter one is the root package as detected in the app. If it differs from the original one identified during profiling the first field is true. One could easily change the first field to always include the original root package. This allows to see whether the entire library has been (re-)obfuscated.

As for your proposed package/class mappings, by default the package names are stored in the hashtree which allows writing out such a mapping during matching (if they differ). There might be false positives for packages with only a few common classes that share the same hashes.

The class names are not stored by default for efficiency reasons, but this can be changed in the TreeConfig class (de.infsec.tpl.hashtree). For classes I would expect a higher false positive rate, since there might be small classes within the same package that share the same hash.

Such fuzziness can be significantly reduced when the bytecode is additionally used for profiling (however there is no implementation yet).

To cut a long story short, package mappings should be duable with moderate effort, but I would refrain from doing it for classes due to a higher expected FP rate.