Basically the idea is to get the code and cross-compile it using the Android NDK (Native Develpment Toolkit) toolset on Ubuntu, then getting the binary and transferring it onto your device and running it with the right permissions.

Update [2017-01-16]:I’m not sure whether this will work for Android on both x86 and ARM architectures. I tested it on an ARM architecture (physical device), and it worked. I’m yet to test it on an x86 architecture. Will update after testing. (My feeling is that it should). I forgot that there are multiple folders in the /libs directory that are created. One for each of the architectures. Pick the right executable from the right folder for your architecture, and it should work.

Update [2017-01-18]: I tested this entire thing on an Android 7.1.1 (Nougat) emulator, and eventually got it working. It seems that from Android 5.0 you will probably get an error like “error: only position independent executables (PIE) are supported“. From what i’ve read here this is is due to a security feature implemented from Android 5.0 onwards. The Android.mk file has to be modified a bit (i’ve added the modifications needed) to enable PIE for any executables from Android 5.0 onwards. (Truth is it seems the PIE feature is available from 4.1, but it is disabled, and from 5.0 it is enabled by default)

Create a directory in an appropriate location of your choice. I created one called memdump on my Desktop. Then create a directory with the name jni in that directory (this is important for using ndk-build later).

cd ~/Desktop
mkdir memdump
cd memdump
mkdir jni
cd jni

Create a file in the jni directory and copy-paste the code from the link provided above into the file. Name the file memdump.c. I’ve put the code here below also, just for completeness:

Click Apply or OK. A dialog should appear where you accept the license conditions and then the requisite tools should begin installing.

(For our case here, we will use only ndk-build since it was what worked. Ideally, you could use CMake … and actually the latest Android documentation suggests using CMake henceforth since i think they plan to retire / deprecate ndk-build eventually … All the same, i think the Android.mk file I found on StackExchange was written for ndk-build so that’s what we’ll use. Also i’m not yet sure how to use CMake for this task. If i figure it out i’ll write another blog post.) Also you could use Android Studio directly for this entire task of building/compiling the C code to get an Android/ ARM executable, but i don’t know how to configure it correctly yet.

Once you have the NDK installed, navigate to the ~/Desktop/memdump directory and while there execute ndk-build , which you can find under /home/Android/Sdk/ndk-bundle/

cd ~/Desktop/memdump
/home/Android/Sdk/ndk-bundle/ndk-build

If you happen to be on a Windows machine, you can get ndk_build.cmd to do the job for you. Navigate to the folder where you have memdump and you can run:
e.g:

At this point the code should build and compile creating a /libs directory an an /obj directory. Navigate into the libs directory and you will see directories for various architectures. Under each directory there is an executable for that specific architecture. We’re mainly concerned at this moment with the one under armeabi

Installing the Memdump executable on an Android device:

In order to use the Memdump executable, we need to get it onto an Android device in a place that allows execution, give the executable execute permissions and run it.

NB: We assume that the Android device is rooted properly and that the specific Superuser management app allows root access from the adb shell. (I haven’t tested it on an unrooted device, but i still suspect that the device needs to be rooted first)

Navigate to the directory containing the adb executable. Get into the adb shell and navigate to the /data/local/tmp (since execution of binaries is allowed there). We want to put the memdump executable in a directory in here. Create a directory here called mem_dump_tools (or whatever you’d like to call it). This is where we will put the memdump executable

NB: Make sure you don’t forget the “>” to direct the output of stdout to a file (or elsewhere)

Hack: (For those interested in Forensics & Reversing). If you get the Position Independent Executables (PIE) error here because you missed the lines LOCAL_CFLAGS += -fPIE and LOCAL_LDFLAGS += -fPIE -pie in the Android.mkfile, there is an interesting hack (credit to Koorosh Ghorbani ) that i found on Stackoverflow. You can open the executable with your favourite Hex Editor and you just have to change the 17th byte from 02 to 03 and the executable should now work without the PIE error.

We want to dump the process memory of a an application E.g. Chrome, Facebook, Whatsapp …etc. into a directory on the SDCard. Let’s use Chrome for now

Let’s first create a directory where the dumps should go.

./adb shell
su root
cd /storage/extSdcard
mkdir MEM_DUMPS

Now let’s get the process id of the process that we want to target

ps | grep chrome

Pick the pid from this. You should get 3 processes (one with sandbox , another with privileged affixed and another just plain com.android.chrome … pick this last one with nothing affixed to the name)

Then run memdump as follows:

./memdump <pid> > /storage/extSdcard/MEM_DUMPS/<mem_dump_file_name>

E.g.: ./memdump 1234 > /storage/extSdcard/MEM_DUMPS/chrome.dmp

The dumping process should now begin (there’s no real progress report, just the cursor blinking, or hanging), but it should take some seconds to minutes depending on your phone’s processing capabilities (for Chrome i got an 800MB dump file so give it some time and it tool like 2min, or try some less memory intensive app that might result in a smaller process memory dump file)

I used 2 different C code scripts to achieve the same goal of achieving the process memory dump. The specific code scripts are referred to as Memfetch(by Michal Zalewski – found on his blog) and Memdump(by Tal Aloni – found on StackExchange)

Update [2017-01-16]: I’m not sure whether this will work for Android on both x86 and ARM architectures. I tested it on an ARM architecture (physical device), and it worked. I’m yet to test it on an x86 architecture. Will update after testing.

Use the ls command to list the files. The files should be listed as below:

COPYING Makefile memfetch.c mffind.pl README

Now install the gcc compiler for Android on ARM (not sure if this is what it’s described as):

sudo apt-get install gcc-arm-linux-android-eabi

(some instructions say use the gcc-arm-linux-gnueabi but this didn’t work for me )

Edit the Makefile

Normally at this point you should be able to run the make command and compiling should work, however in Ubuntu the Canonical developers seem to have moved some key .h source files around causing problems. The first file that might cause problems if you run the make command will probably be this is because Ubuntu has moved them from the original location of /usr/include/asm to be in the kernel source files /usr/src/linux-headers-[your-specific-kernel]/include/asm-generic

Make sure you’ve installed build-essential for this path to be existent

sudo apt-get install build-essential

You can get to the correct path with:

cd /usr/src/linux-headers-$(uname -r)/include/asm-generic

Once you locate the asm-generic folder check that the page.h file is present.

Now the best way to solve this problem is to create a symbolic link (symlink) in /usr/include/ called asm that links to /usr/src/linux-headers-[your-specific-kernel]/include/asm-generic/ . This is done with the following command:

Even with this, there will still be some problems because there are some .h files in asm-generic that will be looking for asm-generic in /usr/include/ where the folder doesn’t actually have those header files. So an extra include (-I) directive will need to be added in the Makefile

At this point i finally ran the make command in the the memfetch directory and an executable was created. There were a couple of warnings, but no errors and the executable worked when I pushed into onto the Android device.

Pushing to the Android Device and Executing “Memfetch”:

NB: We are assuming that the device is properly rooted, and the setting for giving adb shell root permissions has been set in your “Super User” management app.

Go to the adbexecutable location, which might be /home/Android/Sdk/platform-tools it could also be elsewhere … depending on where you installed it

cd /home/Android/Sdk/platform-tools

The best location to push the executable is /data/local/tmp. Let’s create a directory in this location and use the adb push command to push the executable here

./adb shell
su root
cd /data/local/tmp
mkdir mem_dump_tools
exit
exit

We exited first all the way out so that we can run the ./adb push command

Verify that the memfetch executable has been pushed to the right location:

./adb shell
su root
cd /data/local/tmp/mem_dump_tools
ls -al

The memfetch executable should be in place however it cannot be executed because it does not have execute permissions. We can give it execute permissions with the following command (assuming we are still the root user)

chmod 755 memfetch

(As a side note: chmod u+x memfetch should also work.)

Verify that the Execute permissions have been applied

ls -al

You should see rwx against the name of the memfetch executable. (The x being the important thing)

Now if we run a particular app and search this process’ ID we can dump the process memory. Pick an app e.g. Google Chrome and fire it. Browse to some page

On the adb shell:

ps | grep chrome

You should get 1-3 processes with Chrome (one with sandboxed and another with privileged attached to the process name). Pick the process ID of the process that is plain com.android.chrome

Now we can run memfetch

./memfetch

e.g: ./memfetch 2314 if the process id is “2314”

You should now get some output to screen showing that the memory-mapped regions are being copied. The result is that for each address range (block) from the /proc//mem folder there is a sub folder called map that contains the mappings. These mappings result in an individual “region dump” per file (with a .bin extension) and each region dump filename is appended into a single file with a /lst extension containing all the filenames of all the regions dumped. So the end result is a lot of .bin files and a single .lst file.

NB: If at this point when you try to run memfetch and all you get is a listing of the available options/directives, and nothing else, then you need to comment out some section of the code in memfetch.c and recompile. I don’t know why this is the case, but someone on StackExchange [2] figured this out and it also worked for me.