Passive and active monitoring
Actively monitoring an application’s network activity is particularly advantageous: not only can we look at what the app is doing, but also get to alter its communication, e.g. by altering network responses to it and directly observe any effects this might have. This way, we can analyse code paths of great depth inside the application, which we might not have been able to do otherwise.
and on Android?
One particularly useful way of analysing applications is observing and manipulating their behaviour at runtime. Generally speaking, the two most beneficial ways to accomplish this are debuggers and network proxies - depending on the application, your mileage may vary. Let’s first take a look at how we can set up a proxy for our (Android) applications.
We’ll start by choosing a proxy to use. My go-to choice is the Burp Suite proxy, and this is the one I will use as an example here as well.
Setting up the Burp proxy is particularly easy. After you’ve downloaded and launched it, head
Proxy tab and then
Options. You can set up your interface on
0.0.0.0 and port
to 80 if your want to intercept HTTP connections, or 443 for HTTPS, or any port you wish
to proxy on.
Edit your listener and choose the
Certificate tab. Here you can specify what certificate
your want to use. Typically, when I’m analysing one app at a time I use the third option
“Generate a CA-signed certificate with a specific hostname” and I set up the hostname to
the one the application uses for communication. Now if you check “Support invisible
proxying” on the
Request Handling tab, Burp will proxy all connections the application
makes over the port we specified. However, since Burp’s certificate is not trusted, this
won’t work; we need to add it to the trusted certificates list. To the command line!
pushd /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/ && wget http://bouncycastle.org/download/bcprov-jdk16-141.jar && popd
adb pull /system/etc/security/cacerts.bks
keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass "" -importcert -trustcacerts -alias Portswigger -file PortSwiggerCA
You will be presented with a prompt on whether to trust the PortSwigger certificate; type ‘Yes’
adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock0 /system, where
mtdblock0is the appropriate device for your emulator instance.
adb shell chmod 777 /system/etc/security/cacerts.bks
adb push cacerts.bks /system/etc/security/cacerts.bks
adb shell chmod 644 /system/etc/security/cacerts.bks
cp /tmp/android-$USER/emulator-jxcLaF ~/.android/avd/devicename.avd/system.img
- Restart your emulator, pull the
cacerts.bksand make sure it contains the PortSwigger certificate.
[EDIT]: I received a couple questions about point #1; in particular, what is the deal
with the ¡magic! path. That path is the value of
$JAVA_HOME/jre/lib/ext/ or on my system
$JAVA_HOME/Home/lib/ext/. Its significance lies in that the JRE will look there
$CLASSPATH is modified) for providers.
Roughly, what we did is get the phone’s trusted certificate store (
cacerts.bks) and add
the PortSwigger certificate to it using keytool. Then we copied it back to the phone. The
only shady step is #9, which we’ll explain in the next paragraph. The reason we chose this
procedure is convenience; if we simply added our certificate through Android’s (before
ICS) functionality, it would not persist across reboots (try it).
Now the reason the procedure above worked is because we are moving the temporary copy
system.img. If you want this to be scriptable, which will prove
useful in the future, read the answers to this StackOverflow
which detail a step-by-step procedure to follow.
From Ice Cream Sandwich and onwards, we do not need to perform the above. Instead, we can
add any certificate through Settings (
Settings-> Security-> Credential Storage ->
[Install from storage]). This renders the aforementioned procedure redundant (finally),
and the added certs persist across reboots, as the store is on
/data partition, and more
Now we are able to verify our proxy works by setting it up, say at
and instructing our emulator to use it by passing the parameter
Do note that this method only works for applications which respect the proxy values in
System class or the default Android implementation of the
other applications, my approach is to set up a fake DNS responder and use the
-dns-server parameter of the emulator to point all of the device’s DNS lookups there.
That’s all! Next up, we’ll have a look in our application’s internals with various debuggers.« Past Future »