Exercise 2
Last updated
Last updated
Assembler/disassembler for the DEX format used by Dalvik.
smali = "assembly" of the DEX bytecode.
backsmaling = decompiling to smali.
Allows converting a DEX blob to something “more human friendly”.
Similar to Assembly language in a common CPU.
Why? Isn’t DEX <- -> class possible?
With recent compiler optimizations (and Kotlin, and obfuscation) not always.
It’s possible to compile DEX (smali) -> class -> Java, but the code may not be correct.
Use of smali enables patching DEX bytecode directly (although it’s more complex).
Quite a few DEX “obfuscators” exist, with different approaches:
Functionally similar to binutils’ strip, either java (ProGuard) or sDEX.
Rename methods, fields and class names.
Break down string operations to “chop” hard-coded strings, or encrypt them.
Can use dynamic class loading (DexLoader classes) to impede static analysis.
Can add dead code and dummy loops (with minor impact on performance).
Can also use goto into other instructions (or switches).
Additional advantage: As obfuscators remove dead code, applications become smaller.
In practice, obfuscation is quite limited, due to:
Reliance on Android Framework APIs (which remain unobfuscated).
JDWP and application debuggability at the Java level.
If Dalvik can execute it, so can a proper analysis tool.
Popular enough obfuscators have de-obfuscators...
Cannot obfuscate Activities.
About 25% of applications have some form of obfuscation.
Code shrinking (or tree-shaking): detects and safely removes unused classes, fields, methods, and attributes.
Resource shrinking: removes unused resources from a packaged app, including unused resources in the app’s library dependencies.
Obfuscation: shortens the name of classes and members, which results in reduced DEX file sizes.
Optimization: inspects and rewrites your code to further reduce the size of your app’s DEX files.
Unreachable code is removed from the application.
