How to dump memory of any running processes in Android (rooted)

First download and untar the Android NDK (in my case it is r7 version).

Next untar the “dump_android_memory.tgz” (which can be downloaded from and copy the entire directory “dump_android_memory” under the “samples” subdirectory.

“cd” to that directory, and execute “export NDK_PROJECT_PATH=`pwd`”.

Then execute “../../ndk-build” as follows (ie, just execute the “ndk-build” that comes with the NDK download):

After compilation look for the file:


And then “file” to view the binary file type:

file libs/armeabi/dump_android_memory
libs/armeabi/dump_android_memory: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

Now this is a ELF file successfully compiled and created by NDK.

Copy the dump_android_memory binary to your Android devices via “adb push”. (details not shown). Assuming “adb” is in your $PATH, connect into your android device:

adb push dump_android_memory /data

adb shell

(“su” will be necessary to escalate to root if it is a real Android device)

Inside the Android device, run as root (“su”) to execute the command “chmod 4755 dump_android_memory” to setuid the executeable.

# chmod 4755 /data/dump_android_memory

# /data/dump_android_memory
/data/dump_android_memory <pid> <start_address> <total_words>
where <start_address> is in hexadecimal (remember the “0x” in front is
needed – by sscanf()

Finding where is the starting address to dump (for efficiency), using pid=37 as an example:

# cat /proc/37/maps
00008000-00028000 r-xp 00000000 00:01 24 /sbin/adbd
00028000-00029000 rwxp 00020000 00:01 24 /sbin/adbd
00029000-00034000 rwxp 00029000 00:00 0 [heap]
10000000-10001000 ---p 10000000 00:00 0
10001000-10100000 rwxp 10001000 00:00 0
40000000-40008000 r-xs 00000000 00:07 188
/dev/ashmem/system_properties (deleted)
40008000-40009000 r-xp 40008000 00:00 0
40009000-4000a000 ---p 40009000 00:00 0
4000a000-40109000 rwxp 4000a000 00:00 0
40109000-4010a000 ---p 40109000 00:00 0
4010a000-40209000 rwxp 4010a000 00:00 0
bed45000-bed5a000 rwxp befeb000 00:00 0 [stack]

Now you can dump the memory of any live process using the command “dump_android_memory <pid> <start_address> <total_words_to_dump>” where words are measure in counts of 4 bytes, and start_address must be entered in hexadecimal format as “0x12345678”.

Dumping 10 words:

# /data/dump_android_memory 37 0x00008000 10

464c457f 10101 0 0
280002 1 80a0 34

Dumping 100 words:

# /data/dump_android_memory 37 0x00008000 100

464c457f 10101 0 0
280002 1 80a0 34
20998 5000002 200034 280003
e000f 70000001 1e198 26198
26198 1460 1460 4
4 1 0 8000
8000 1f5f8 1f5f8 5
1000 1 20000 28000
28000 8e4 787c 6
1000 0 0 0
e1a0000d e3a01000 e28f2004 e28f3004
ea006730 ea006737 28000 28008
28014 2801c e1a00000 e1a00000
f005b510 bd10ffa1 f013b510 bd10ff51
6803b510 2b001c04 6840d005 68626058
60136064 1c206024 f0013008 6a60fa35
d0012800 ff3cf013 28006aa0 f013d001
6ae0ff37 d0032800 31301c21 fb64f001
f0131c20 bd10ff2d f7ffb510 bd10ffd9
4657b5f8 b4c04646 4e154d14 447d1c07
468859ab 681c4692 d014429c 1c386a61
f92af00f d10a2800 46406aa1 f924f00f
d1042800 2b006ae3 4553d001 6824d009
429c59ab 2001d1ea bc0c4240 469a4690
1c20bdf8 ffacf7ff e7f62000 2043a #

Hope it helps.


9 responses to this post.

  1. What is the purpose of dumping memory on per-process process basis? For live-memory forensic:

    Its usefulness is however, easily circumvented by malware. You just need to write play around with the memory page table, for example something similar:

    “SHADOW WALKER” Raising The Bar For Rootkit Detection

    How? Unlike in the x86 architecture, ARM page table does not have the “PRESENT” bit, and therefore, using this bit is impossible. So what left is to manipulating with the PTE values itself. Possible????? Not sure.


  2. It must also be highlighted that the “adb” command (from Android SDK) is very useful for dumping userspace memory too.

    ./adb shell dumpsys meminfo
    Applications Memory Usage (kB):
    Uptime: 8042250 Realtime: 8042250

    ** MEMINFO in pid 1207 [] **
    native dalvik other total
    size: 3936 3079 N/A 7015
    allocated: 3716 2538 N/A 6254
    free: 83 541 N/A 624
    (Pss): 1106 2249 1457 4812
    (shared dirty): 1428 4088 1256 6772
    (priv dirty): 1024 984 768 2776

    Views: 0 ViewRoots: 0
    AppContexts: 0 Activities: 0
    Assets: 2 AssetManagers: 2
    Local Binders: 5 Proxy Binders: 9
    Death Recipients: 0
    OpenSSL Sockets: 0

    heap: 193 memoryUsed: 193
    pageCacheOverflo: 26 largestMemAlloc: 50

    Pagesize Dbsize Lookaside Dbname
    1024 28 289 EmailProvider.db
    1024 20 0 (attached) BodyDatabase : EmailProviderBody.db
    1024 20 10 EmailProviderBody.db

    ** MEMINFO in pid 1187 [] **
    native dalvik other total
    size: 3640 2887 N/A 6527
    allocated: 3554 2390 N/A 5944
    free: 69 497 N/A 566
    (Pss): 963 1338 1131 3432
    (shared dirty): 1444 4128 1320 6892
    (priv dirty): 880 656 656 2192

    Views: 0 ViewRoots: 0
    AppContexts: 0 Activities: 0
    Assets: 4 AssetManagers: 4
    Local Binders: 5 Proxy Binders: 11
    Death Recipients: 0
    OpenSSL Sockets: 0

    heap: 189 memoryUsed: 189
    pageCacheOverflo: 34 largestMemAlloc: 50

    Pagesize Dbsize Lookaside Dbname
    1024 5 133 downloads.db
    1024 54 31 internal.db

    As shown above, it even tell you which process is linked with which databases (a.k.a lsof in Linux/Unix).


  3. Very nice guide. But what should my word count be if i wana dump the entire process?


    • When you do “cat /proc/37/maps”, you can see that the memory are divided into different contiguous segment – which is virtually mapped. Those addresses in between not listed are not virtually mapped, and therefore the C program will encounter errors when you cross the segment boundaries. Unless you modify the C program to intelligently skipped unreadable region, otherwise the C program will encouter segmentation fault.


  4. You can also dump memory with this application.
    Memory Dump (ROOT)


  5. HI,
    I try to read dump on msm8916 platform running Android 6.0 and I only visualize ffffffff all the times on every process. Any suggestion would be really appreciated. Thanks


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Astr0baby's not so random thoughts _____ rand() % 100;

@astr0baby on Twitter for fresh randomness


Artificial Intelligence, Deep Learning, and NLP

The Data Explorer

playing around with open data to learn some cool stuff about data analysis and the world


Data | ML | NLP | Python | R


Just a thought

IFT6266 - H2017 Deep Learning

A Graduate Course Offered at Université de Montréal

Deep Learning IFT6266-H2017 UdeM

Philippe Paradis - My solutions to the image inpainting problem


Taking the required Steps for learning


Pulkit's thoughts on the course project


Machine learning. Artificial Intelligence

the morning paper

an interesting/influential/important paper from the world of CS every weekday morning, as selected by Adrian Colyer

The Spectator

Shakir's Machine Learning Blog

Everything about Data Analytics

big data, data analytics

%d bloggers like this: