Live Memory Forensics on Android devices

Gkogkos Nikos
@ngkogkos
Live Memory Forensics on
Android devices

Digital Forensics (1)
• 3 main phases
– Data Acquisition
– Data Analysis
• Searching for artifacts
– Data Presentation (reports, timelines)
• Proving that results are accurate
– Usage of hash functions (md5, sha256)

Digital Forensics (2)
• Traditional Digital Forensics deal with non-
volatile δεδομένα (HDD, removable
media)
• Live Memory Forensics deal only with
volatile data (RAM dump/image)
• RAM dumps must be forensically sound
• Best approach?
– Do both!
• Data may reside in different types of memory
• Demand Paging, Swap Space

Why Live Memory Forensics?
(1)
• Everything executes or goes through RAM
eventually (procs, sockets, kernel)
• Some data reside only in RAM
– buffers, sockets, encryption keys
• Sensitive data (credentials) can be usually
found unencrypted
• RAM.size < HDD.size
– Firstly do RAM forensics which is quicker

Why Live Memory Forensics?
(2)
• Malware Analysis
– Behavioral analysis
– Reverse Engineering
• We can dump the executable
• Malware can’t slip away from RAM
forensics that easy
– It has to leave traces in order to execute
properly!

Android basics (1)
• Android is a Software
Stack
• Search for artifacts in
Application & Kernel side
• We can search in
Runtime layer too
– Lots of trouble!
– Dalvik VM != ART
• Zygote process preloads
every library
– Every app is a zygote fork
– Hence, it has every lib
loaded in its Virtual
Address Space
• App Life Cycle
– Every app remains in a
ready-steady state

Android basics (2)
• Android apps’ .apk [Android Application
Package] file gives nice hints
• Disassemble the .apk file (apktool)
• AndroidManifest.xml: permissions, Ιntents
• classes.dex: Reversing the app
– DEX Smali assembly (Dalvik’s assembly)
– DEX Java with a decompiler
• Android’s filesystem
– data/ storage/ app-cache/ …
– One can dump the filesystem from RAM.dump

Working Environment
• LiME (Linux Memory Extractor) – LKM
• Copies RAM’s pages content to a local dump file
• 99% efficiency, main developer: Joe Sylva
• Volatility framework
• Works for RAM dumps for any OS
• Open Source, great community, many plugins
• Python �
• Other tools
• Android SDK tools (ADB), Android emulator(S)
• GNU/Linux Command−Line Tools (grep, strings)

Process Analysis (1)
• Volatility plugins for procs
– linux_pslist, linux_psaux, linux_pstree,
linux_threads, linux_psxview
• They traverse OS structures
– Active Process list, kmem_cache, PID hash
table
• Check parent-child relations

• Check apps’ UIDs
– Android assigns a unique UID in each app
– User installed apps have UID > 10000
– Process Hollowing could be detected
• Check Linuxes standards for process
names, environment variables
– Kernel threads must be enclosed in []
– They cannot have environment variables
– A malware could masquerade in [] but still
have environment variables

$ python vol.py -f ~/android-dumps/example.dump linux_psaux
Volatility Foundation Volatility Framework 2.4
Pid Uid Gid Arguments
1 0 0 /init
2 0 0 [kthreadd]
3 0 0 [ksoftirqd/0]
4 0 0 [kworker/0:0]
[snip]
468 1023 1023 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard
/storage/sdcard
474 10005 10005 android.process.media
523 10029 10029 com.android.inputmethod.latin
539 1001 1001 com.android.phone
[snip]
1138 10053 10053 com.savemebeta
1157 0 0 /system/bin/sh -
1164 0 0 insmod /sdcard/lime.ko path=tcp:12345 format=lime
1381 0 0 [kworker/0:1]

$ python vol.py -f ~/android-dumps/example.dump linux_psxview
Offset(V) Name PID pslist pid_hash kmem_cache parents leaders
---------- -------------------- ------ ------ -------- ---------- ------- -------
0xde81bc00 init 1 True True True True True
0xde81b800 kthreadd 2 True True True True True
0xde81b400 ksoftirqd/0 3 True True True False True
[snip]
0xde071800 zygote 65 True True True True True
0xde071400 drmserver 66 True True True False True
0xde071000 mediaserver 67 True True True False True
0xde0a7c00 installd 68 True True True False True
0xde0a7800 keystore 69 True True True False True
0xde0a7400 qemud 70 True True True False True
0xde0a7000 sh 73 True True True False True
0xde0e9800 adbd 74 True True True True True
• Requires strong internal knowledge of the Android OS
and the Linux kernel
• Tough for a rootkit to hide from every OS “spot”

Process Mappings Analysis
1138 0x00000000aa0cb000 0x00000000aa2af000 r-- 0x0 31 1 6813 /data/dalvik-
cache/data@app@com.savemebeta-1.apk@classes.dex
1138 0x00000000b2a34000 0x00000000b2ceb000 rw- 0x0 0 4 2028
/dev/ashmem/dalvik-zygote
1138 0x00000000b2ceb000 0x00000000b5a34000 rw- 0x0 0 4 2352
/dev/ashmem/dalvik-heap
1138 0x00000000b5ae0000 0x00000000b5ae5000 rw- 0xaa000 31 0 671
/system/lib/libdvm.so
1138 0x00000000b5ae7000 0x00000000b5ae8000 r-- 0x23000 31 0 485
/system/framework/conscrypt.jar
• linux_proc_maps: displays a proc’s mappings
• Memory segments allocated for libraries, stack/heap region
$ python vol.py -f ~/android-dumps/example.dump linux_proc_maps -p 65 | grep -iF "/system/lib/" | awk
'{print $9}' > zygote_libs.output
$ python vol.py -f ~/android-dumps/example.dump linux_proc_maps -p 899 | grep -iF "/system/lib/" |
awk '{print $9}' > dialer_libs.output
$ diff zygote_libs.output dialer_libs.output
• Cross-Check zygote’s libraries against a suspicious app’s
• If app has extra libs loaded, this is some good alarm

Searching & Dumping files (1)
$ python vol.py -f ~/android-dumps/example.dump linux_lsof -p 1138
Pid FD Path
-------- -------- ----
1138 0 /dev/null
1138 1 /dev/null
1138 2 /dev/null
1138 3 /dev/log/main
1138 4 /dev/log/radio
1138 5 /dev/log/events
1138 6 /dev/log/system
1138 7 /system/framework/core.jar
1138 8 /dev/__properties__
1138 9 socket:[1803]
[snip]
1138 47 /data/data/com.savemebeta/databases/user_info4
• linux_lsof: displays any open file (regular files, streams,
logging buffers, sockets)
• The user_info4 file looks interesting..

$ python vol.py -f ~/android-dumps/infostealer.dump linux_find_file -F
/data/data/com.savemebeta/databases/user_info4
Inode Number Inode File Path
---------------- ---------- ---------
6815 0xde7c8a00 /data/data/com.savemebeta/databases/user_info4
$ python vol.py -f ~/android-dumps/infostealer.dump linux_find_file -i 0xde7c8a00 -O userinfo4.dump
$ file userinfo4.dump
userinfo4.dump: SQLite 3.x database, user version 1
$ sqlite3 userinfo4.dump
SQLite version 3.8.10.2 2015-05-10 18:17:19
Enter ".help" for usage hints.
sqlite> .tables
android_metadata credentials reg_info4
• We can extract a file with linux_find_file
• Finds and extracts a file out of OS caches
• It is obvious that savemebeta is a keylogging malware!
• One can dump the savemebeta.apk and proceed with Reversing

$ python vol.py -f ~/android-dumps/infostealer.dump linux_enumerate_files --output=text --output-file=dump-
files
$ cat dump-files | grep "/data/app" | egrep ".apk$"
3628688208 0x5c /data/app/com.savemebeta-1.apk
3628158240 0x5a /data/app/com.android.service-1.apk
[snip]
$ cat dump-files | egrep ".db$"
3628510096 0x1a23 /data/data/com.android.providers.telephony/databases/telephony.db
3628425472 0x1a09 /data/data/com.android.providers.telephony/databases/mmssms.db
3628945664 0x1a18 /data/data/com.android.email/databases/EmailProviderBackup.db
3628947776 0x1a16 /data/data/com.android.email/databases/EmailProviderBody.db
3628948304 0x1a0c /data/data/com.android.email/databases/EmailProvider.db
3628924192 0x1a3b /data/data/com.android.deskclock/databases/alarms.db
3628163328 0x19c4 /data/data/com.android.providers.settings/databases/settings.db
3628820800 0x1a42 /data/data/com.android.providers.media/databases/internal.db
3628473888 0x1a01 /data/data/com.android.providers.media/databases/external.db
3628394288 0x1a10 /data/data/com.android.launcher/databases/launcher.db
3628554224 0x1a2c /data/data/com.android.launcher/cache/widgetpreviews.db
3628536720 0x1a21 /data/data/com.android.providers.downloads/databases/downloads.db
3628406640 0x19d5 /data/data/com.android.providers.contacts/databases/profile.db
3628494176 0x19d3 /data/data/com.android.providers.contacts/databases/contacts2.db
• linux_enumerate_files: displays all files found in the
filesystem cache

$ python vol.py -f ~/android-dumps/sms-contacts.dump linux_find_file -i 0xd844f350 -O mmssms.db
$ sqlite3 mmssms.db
SQLite version 3.8.5 2014-08-15 22:37:57
Enter ".help" for usage hints.
sqlite> .tables
addr pdu threads
android_metadata pending_msgs words
attachments rate words_content
canonical_addresses raw words_segdir
drm sms words_segments
part sr_pending
sqlite> select * from sms;
1|1|6980012345|2|1437138595606|1437138594000|0|1|-1|1|0||"Hello, this is a test sms message"||0|0|1
2|2|6980000000||1437138617752|1437138616000|0|1|-1|1|0||"This is a second sms message for testing
purposes"||0|0|1
• Extracting SMSes
• Firstly, get the inode offset
• Then dump the file again with linux_find_file

Searching for LKM rootkits (1)
$ python vol.py -f ~/android-dumps/infected.dump linux_kernel_opened_files
Offset (V) Partial File Path
---------- -----------------
0x306e5800 /root/.keylog
• Check for files opened in the kernel-land with
linux_kernel_opened_files
• Search for LKMs with linux_lsmod: traverses the kernel’s
global list with loaded kernel modules
• 1-line C code for a rootkit to delete itself from that list…
$ python vol.py -f ~/android-dumps/infected.dump linux_lsmod -P
bf0007f0 lime 9349
format=lime
dio=0
path=tcp:12345
• The only LKM found is LiME…

Searching for LKM rootkits (2)
$ python vol.py -f infected.dump linux_hidden_modules
Offset (V) Name
---------- ----
0xa03a15d0 suterusu
• linux_hidden_modules: looks for LKMs using the Carving
technique
• It looks for byte sequences that define a kernel module
structure in RAM
• Suterusu is an open source Linux/Android rootkit
• We can dump it with the linux_moddump plugin
• Reverse Engineering ARM 32bit executables
 IDA pro
 HopperApp

Recovering filesystems (1)
$ python vol.py -f ~/android-dumps/example.dump linux_tmpfs –L
1 -> /dev
2 -> /app-cache
3 -> /mnt/obb
4 -> /mnt/asec
$ mkdir appcacheoutput
$ python vol.py -f ~/android-dumps/example.dump linux_tmpfs -S 2 -D appcacheoutput
• Volatility provides many linyx plugins that recover filesystems
• They can be recovered even if they locked with a user
specified password
• We can extract the tmpfs filesystems
– Those reside only in RAM
– They are being used for optimization reasons

Recovering filesystems (2)
$ sudo python vol.py -f ~/android-dumps/Evo4GRodeo.lime --profile=LinuxEvo4GARM linux_recover_filesystem –D
fs-example-output
$ cd fs-example-output/
$ echo */
acct/ app-cache/ data/ dev/ mnt/ proc/ sys/ system/
$ cd app-cache/com.android.browser/cache/webviewCache
$ sudo chmod -R 777 .
$ file *
0107b850: ASCII English text, with very long lines
19dde20c: HTML document text
28ca44b8: GIF image data, version 89a, 1 x 100
29b5cf95: JPEG image data, JFIF standard 1.02
29f711e8: JPEG image data, JFIF standard 1.02
301c338b: PNG image data, 1000 x 90, 8-bit/color RGBA, non-interlaced
[snip]
• linux_recover_filesystem: extracts part of the device’s whole
filesystem structure (the % of data that was cached in RAM)
• One then can apply traditional Digital Forensics techniques
• Android’s stock browser uses the app-cache tmpfs
filesystem to store its webviewCache 

Volatility plugin dev (1)
• Volatility framework provides some useful
API
– Quick byte sequences (needles) searching in
RAM data
– Easy data parsing, formatting and printing
• What would be a useful plugin?
– Facebook: 1.31 billion mobile users [22/4/15]
– 1.31 billion / 7.3 billion ~= 0.179

Facebook plugin (1)
• Required tools
– Hex Editor, python IDE, patience
• Technique being used
– Carving with many sanity checks
• 3 main functions (text, csv)
– Find facebook friends
– Find owner’s personal info
– Find messages
• https://github.com/ngkogkos/volatility-plugins

Facebook plugin (2)
• “Trapping” a message
• One can check all these sequences to
guarantee that the message is valid

Facebook plugin (3)
• Many issues arise in the beginning
• Many random findings..
– Eliminate them with more sanity checks
• What if 2+ users were logged in?
– The plugin user provides the proper user ID
• Sometimes we get duplicate messages
– Remove them with --strip-duplicates argument

Facebook plugin (4)
• facebookcontacts

Facebook plugin (5)
• facebookgrabinfo
• python vol.py –f RAM.dump
facebookgrabinfo –format=visualizer
• In real accounts this JSON structure
contains the person’s phone number

Facebook plugin (6)
• facebookmessages
• A more demanding case..

Why is it useful?
• So why not simply open the facebook app
to get the messages?
• Scenario
– Criminal acts through the facebook app
– Deletes the messages before device falls into
the investigators’ hands
– If they get a RAM.dump the messages can be
retrieved
• Provided the device wasn’t rebooted..
• No need to know their facebook credentials

Conclusions
• We did some experiments with many
facebook test accounts.. and guess what?
• Facebook doesn’t care about users’
privacy (top secret )
• Many critical apps (e-banking, e-shops)
still store data plaintext in RAM
– Solution: explicitly overwrite sensitive data
– However: this situation helps forensics’ guys

Special Thanks
• Andrew Case @attrc &&
Jamie Levy @gleeda
– For answering my questions
– Being the great devs of Volatility
• Dave @superponible
– Assisting me with the plugin dev
• Peter Fousteris @lostpfg
– Doing the art stuff

Live Memory Forensics on Android devices

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Live Memory Forensics on Android devices

Similaire à Live Memory Forensics on Android devices (20)

Dernier

Dernier (20)

Live Memory Forensics on Android devices