How to extract sensitive plaintext data from Android memory

Right, I’ve had enough of ripping IoT stuff apart for the moment. It’s time to review and share a technique that I’ve used on my favourite mobile operating system (Android, duh!), but haven’t had much use for as it requires the right circumstances.

What I’m going to show you is how to directly dump memory from an Android process.

This is similar to the process I wrote about at the end of my article about the debug mode on apps, but this is more flexible and works with native apps.

NOTE: It sounds cool, right? But you need to be root and need to have an app with “juicy” stuff in memory and stuff that you can’t get through the app’s files.

Needless to say, I found a use.

An app I was testing stored very little real data, had a lock functionality on it, performed certificate pinning and compared the unlock code over the Internets, so it was never stored locally. It also didn’t perform any form of checking to see whether I was root.

I like a challenge.

The setup

Okay, this requires some work to get your (rooted) device ready. You need to edit the system partition to add the GNU debugger (gdb) to it. Fortunately you don’t need to compile this a pre-compiled version is part of the Android Native Development Kit (NDK).

Grab the Native Development Kit (NDK), extract it somewhere and find the right version of gdbserver for your platform. I’ll be using the ARM version on my Nexus 4 as it makes sense.

The steps are the same as adding anything to the root partition:

1. Upload the file
2. Enter a shell and become root
3. Remount /system as read/write
4. Copy file to /system/xbin (or /system/bin)
5. Change permissions to ensure that it is executable
6. Clean up

Or:

Now we need a gdb client to talk to the server process. We can’t use the standard gdb process on most Linux systems as that will not work correctly for the process in place on the device. So we need to perform a custom compile to ensure that we have a gdb that will, for example, run on Intel, but understand ARM.

First, download the gdb source code from gnu.org: (and yes I do write blog articles quite late at night, committed, that’s me).

Then we can build it normally, by using the –target flag to specify that we want gdb’s target to be an ARM processor:

And, we should now have a version of gdb in the gdb directory that runs on an Intel device and will understand an ARM target.

Examining the target

Now we have gdb running, we can attempt to read from memory. What we’re interested in (usually) is the heap memory – this is memory that’s been requested on the fly either from the Dalvik virtual machine, or if a native app, from the kernel.

We can find this information out using the /proc pseudo file system on the device. As an example, I’m going to dump the memory of the device’s keystore application. The first step is to find out the process id:

Then we can go to the /proc entry for this process and check the memory map:

What we’ll normally find are is the code that makes up the process and its libraries and then a copy of the important bits of the process:

• heap – memory assigned by the VM or by the kernel for data storage
• stack – memory used during function calls etc.

So above we can see that the heap runs from 0xb7712000 – 0xb771f000.

Reading memory

Right, it’s time to grab memory. This is slightly convoluted, but once you get used to it, it makes sense. The process is:

1. Start gdbserver on the process listening on a port on the device
2. Use adb to forward the port on the device to a local port
3. Use a third party program to forward the local port to the device where you will be running gdb
4. Connect via gdb
5. Dump the memory
6. Look for stuff
7. $$$ Profit $four$

1. Start gdbserver

This is the simplest part of the process, once you have gdbserver install we can just attach it to our process, and specify a TCP port for it to listen on. I’ve used 1234/tcp below, because:

Don’t ask me why the PID and connection string are that way around, it makes no sense to me either.

We are now listening to the network on port 1234, but as iptables gets in the way, we need to perform the following.

2. Use adb to forward the port

This will allow us to the use adb and our USB connection to the device to bridge between a network port on the host and the device:

C:Usersdave>adb forward tcp:1234 tcp:1234

This will now allow us to talk to the device on port 1234/tcp by connecting to 1234/tcp on the host device. There’s one problem:

As you can see it’s only listening on localhost:1234, which means if our version of gdb is running on another host, or a VM then we need to:

3. Use a third party program to forward the port

This step can be skipped if you’re running gdb and adb on the same host.

I use a really old program called “Port Forwarding for Windows” to forward from my native OS to the virtual machine I run gdb on:

Using 1234/tcp for simplicity. If this does not work as expected, check your firewalls as they will often break stuff like this.

Now all this is out of the way we should now be able to connect with gdb.

4. Connect with gdb

So I’m going to connect from my Linux VM via my Windows native OS to the gdbserver running on my Nexus 4, using the custom compiled gdb that I made earlier:

We now have a connection (bit anti-climatic really) so now we can dump the memory.

5. Dump the memory

This can be performed with the “dump memory” command very quickly. We’ll use the hex numbers we took from the process’ maps file earlier:

This will write the whole of the device’s heap to the file /tmp/heapout.

6. Look for stuff

And…

7. Profit

There will be a format to the heap, but this will depend on who it’s been allocated by and what’s been allocated. For 90% of cases, a simple strings will do this.

Now, I picked the keystore program for a reason: this is the Android keystore service and manages all access to the aforementioned keystore. The keystore uses a masterkey as a KEK (key encryption key). This is derived from the PIN or password for the device.

Can you see where I’m going? Yes, can we find the device’s PIN? Yes, we can, we just need to look for user 0’s master key and look at data around it:

And there we have the device’s PIN in the old cleartext.

How to prevent it

As I said in the intro, as this process requires root it’s only useful in a handful of situations, mostly where important data is transient, such as credit card PANs and CVVs and the device has already been rooted.

You can protect yourself though, by a little bit of planning when writing your apps: ensure that confidential data is destroyed as soon as possible after use.

Also, don’t just mark your objects deleted after use and hope the garbage collector picks them up – destroy them fully by overwriting all critical data with random data.