Closed 3ntr0phy closed 2 years ago
These are likely "fake" methods/classes added as a form of disassembly prevention. They are invalid methods that art rejects, but without rejecting the whole dex file. The valid classes should still be disassembled, and you should be able to ignore the errors related to these invalid classes.
hi JF. is there a way to force smali into creating such fake items? if they are just left out: i assume code could try to load a class and if not found or is loadable, tempering detection is triggered. anything can be done?
There are a bajillion ways a class could be invalid. I don't have any interest in trying to represent all the different ways a class could be invalid in smali's syntax, so that invalid classes can be kept during a disassemble/assemble roundtrip.
but maybe the number of ways that running code can find out is reduced to a few execptions (depending on how much extra info the exceptions contain).
so eg, methods that should fail to verify could all be replaced with a single method implementation, and just an attribute in smali, no code.
anyway, just saying
From a runtime perspective, the invalid class doesn't exist in either case. Any reference to it will fail to resolve.
ok, thanks. i thought malformed classes would trigger lazy exceptions only at load time, as the JVM does.
I am using the latest version of baksmali -2.5.2 - and I get the following error
8FEE61DFDA62A5734D0221D90CE1A1F894ECAA3F8D6C45A7F252514A1E173059.zip