The document discusses different approaches for instrumenting Android apps to add network monitoring capabilities. It describes choosing to modify the app's dex file by disassembling it to Smali code, inserting instrumentation code, and reassembling it. This allows intercepting HTTP calls without requiring access to the app's source code or build process. The key benefits are that it works on any app and Android version without the app's code needing changes.
3. Motivation?
Little Eye Measures, Analyzes and helps optimize app
resource usage on Android. But network stats are
aggregates only
Friday 13 December 13
4. Motivation (2)
Needed granular network stats - each endpoint/URL,
Latency, Data transferred
Considered different approaches
Implement a VPN client app
Use a proxy
Looked at OS stats - didn’t find anything
Java debug wire protocol (JDWP)
Instrumentation
Friday 13 December 13
5. Instrumentation
ie, Rewriting parts of a binary (in this case, android app)
Allows us to intercept HTTP calls, with code-level
context (parameters, errors) for each call
Works on any app
Works on practically any android version/device
Opens up a lot of exciting possibilities...
Friday 13 December 13
6. Instrumentation (2)
Can be: Static or Runtime
Examples
Android Traceview (startMethodTracing)
Android test automation framework
iOS instruments
Purify (Rational / IBM)
JVM -javaagent option
AspectJ
Friday 13 December 13
8. classes.dx
Dalvik is the custom android VM (different from JVM)
Dex = Dalvik EXecutable format. It’s a custom
bytecode format designed for android
Build process:
compile .java code into .class files
dx converts each .class file into .dx representation,
and stores them in the single classes.dx
all ref’d library code also goes into classes.dex
Friday 13 December 13
9. Reverse engineering tools
Smali (by JesusFreke) - dex disassembler
ApkTool - decodes resources, repackage app
dex2jar - disassembles dex to .class format
JD-GUI - Decompiles .class into .java
Androguard - Tool for deep analysis of android app
ApkAnalyzer - Tool for analysis of app, also supports
instrumentation of the app.
Friday 13 December 13
14. Instrumentation Approaches
Explored the following approaches on android
Runtime
Instrument .class files during build process
Instrument .dex file
Friday 13 December 13
15. Runtime instrumentation
A JVM allows this - pass in a java.lang.instrumentation
(using the -javaagent flag) which can transform class at
class-load time
Dalvik doesn’t support this
It supports passing in a android.app.instrumentation,
but that has a limited set of methods, mostly for
automated testing
Friday 13 December 13
16. Instrumenting .class files
Considered modifying .class files, in two ways:
Using the JavaAssist tool/library
AspectJ
Both are well understood tools, but need to be done at
build time
Requires a process change, plus not all of our users
have access to the build (e.g. 3rd party QA team)
Friday 13 December 13
17. Instrumenting .dex file
Found some tools - none of these looked solid enough
dexpler - research project
redexer - research project
apkil - google summer of code project
Tried dex2jar to convert .dx into .class - but this is not a
reliable method. Fine for reading code (skip the failed
conversions), but not for this use case.
Friday 13 December 13
18. Instrumenting .dex file (2)
Smali
A simple tool that decompiles the .dx into an
intermediate format (also known as smali)
This is well-used (e.g. ApkTool, ApkAnalyzer, and
apkil use it)
Active project, well supported by JesusFreke
I disassemble an app, modified the smali code, and reassembled and repackaged, and it just worked!
Friday 13 December 13
19. Automating instrumentation
Challenges:
Need a way to find all the appropriate calls in the app
to replace
Need to do it without side-effects.
Tried many approaches, JesusFreke pointed me to
MutableMethod which did what i needed
Called my approach Umbreyta (icelandic for transform).
https://github.com/LittleEyeLabs/smali
Friday 13 December 13