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 http://groups.google.com/group/embeddednewbies/attach/03ee7f77fae48976/dump_android_memory.tgz?part=2) 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:
./libs/armeabi/dump_android_memory
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.
Posted by Peter Teoh on December 20, 2011 at 11:12 am
What is the purpose of dumping memory on per-process process basis? For live-memory forensic:
Click to access 07-339.pdf
Click to access thing.pdf
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
Click to access bh-jp-05-sparks-butler.pdf
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.
Posted by Peter Teoh on January 3, 2012 at 10:01 am
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 [com.android.email] **
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
Objects
Views: 0 ViewRoots: 0
AppContexts: 0 Activities: 0
Assets: 2 AssetManagers: 2
Local Binders: 5 Proxy Binders: 9
Death Recipients: 0
OpenSSL Sockets: 0
SQL
heap: 193 memoryUsed: 193
pageCacheOverflo: 26 largestMemAlloc: 50
DATABASES
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 [android.process.media] **
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
Objects
Views: 0 ViewRoots: 0
AppContexts: 0 Activities: 0
Assets: 4 AssetManagers: 4
Local Binders: 5 Proxy Binders: 11
Death Recipients: 0
OpenSSL Sockets: 0
SQL
heap: 189 memoryUsed: 189
pageCacheOverflo: 34 largestMemAlloc: 50
DATABASES
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).
Posted by Quentin Khoo (@Quenberry) on August 15, 2013 at 5:54 pm
Very nice guide. But what should my word count be if i wana dump the entire process?
Posted by Peter Teoh on October 15, 2013 at 7:51 am
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.
Posted by 김태우 on September 26, 2015 at 3:03 pm
You can also dump memory with this application.
Memory Dump (ROOT)
https://play.google.com/store/apps/details?id=com.cert.memdump
Posted by Peter Teoh on September 26, 2015 at 3:19 pm
cool!
Posted by Andrew Schulman on May 11, 2016 at 10:11 am
Does your program skip over unreadable regions, per the point made earlier? If not, it would be a great addition. I think I tried your app, and it crashed when I tried to save an entire process’s memory, so I think it was not skipping unreadable regions. I apologize if someone else also has a memory dump in play.google.com. The app I tried also had a “Search” facility, and I was hoping it would search for strings INSIDE memory blocks, but instead it seemed to be searching only titles/names of memory regions? I think with a few changes this would be a great app!! Thank you in advance.
Posted by Peter Teoh on December 15, 2016 at 1:05 am
Check out Volatility here:
https://www.contextis.com//resources/blog/thanks-memories-identifying-malware-memory-capture/
Posted by bitminer south on May 14, 2017 at 10:07 pm
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