Gkogkos Nikos@ngkogkos

Live Memory Forensics on Android devices

Agenda

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!

Agenda

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

Agenda

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)

Acquiring a RAM.dump

Agenda

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

Process Analysis (2)

• 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

Process Analysis (3)

$ python vol.py -f ~/android-dumps/example.dump linux_psauxVolatility Foundation Volatility Framework 2.4Pid Uid Gid Arguments1 0 0 /init2 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/sdcard474 10005 10005 android.process.media523 10029 10029 com.android.inputmethod.latin539 1001 1001 com.android.phone[snip]1138 10053 10053 com.savemebeta1157 0 0 /system/bin/sh -1164 0 0 insmod /sdcard/lime.ko path=tcp:12345 format=lime1381 0 0 [kworker/0:1]

Process Analysis (4)$ python vol.py -f ~/android-dumps/example.dump linux_psxviewVolatility Foundation Volatility Framework 2.4Offset(V) Name PID pslist pid_hash kmem_cache parents leaders---------- -------------------- ------ ------ -------- ---------- ------- -------0xde81bc00 init 1 True True True True True0xde81b800 kthreadd 2 True True True True True0xde81b400 ksoftirqd/0 3 True True True False True[snip]0xde071800 zygote 65 True True True True True0xde071400 drmserver 66 True True True False True0xde071000 mediaserver 67 True True True False True0xde0a7c00 installd 68 True True True False True0xde0a7800 keystore 69 True True True False True0xde0a7400 qemud 70 True True True False True0xde0a7000 sh 73 True True True False True0xde0e9800 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.dex1138 0x00000000b2a34000 0x00000000b2ceb000 rw- 0x0 0 4 2028 /dev/ashmem/dalvik-zygote1138 0x00000000b2ceb000 0x00000000b5a34000 rw- 0x0 0 4 2352 /dev/ashmem/dalvik-heap1138 0x00000000b5ae0000 0x00000000b5ae5000 rw- 0xaa000 31 0 671 /system/lib/libdvm.so1138 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 1138Volatility Foundation Volatility Framework 2.4Pid 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..

Searching & Dumping files (2)

$ python vol.py -f ~/android-dumps/infostealer.dump linux_find_file -F /data/data/com.savemebeta/databases/user_info4Volatility Foundation Volatility Framework 2.4Inode 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.dumpVolatility Foundation Volatility Framework 2.4

$ file userinfo4.dumpuserinfo4.dump: SQLite 3.x database, user version 1

$ sqlite3 userinfo4.dumpSQLite version 3.8.10.2 2015-05-10 18:17:19Enter ".help" for usage hints.sqlite> .tablesandroid_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

Searching & Dumping files (3)

$ 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

Searching & Dumping files (4)

$ python vol.py -f ~/android-dumps/sms-contacts.dump linux_find_file -i 0xd844f350 -O mmssms.dbVolatility Foundation Volatility Framework 2.4 $ sqlite3 mmssms.dbSQLite version 3.8.5 2014-08-15 22:37:57Enter ".help" for usage hints.sqlite> .tablesaddr pdu threadsandroid_metadata pending_msgs wordsattachments rate words_contentcanonical_addresses raw words_segdirdrm sms words_segmentspart sr_pendingsqlite> select * from sms;1|1|6980012345|2|1437138595606|1437138594000|0|1|-1|1|0||"Hello, this is a test sms message"||0|0|12|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_filesVolatility Foundation Volatility Framework 2.4Offset (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 -PVolatility Foundation Volatility Framework 2.4bf0007f0 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_modulesVolatility Foundation Volatility Framework 2.4Offset (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 –LVolatility Foundation Volatility Framework 2.41 -> /dev2 -> /app-cache3 -> /mnt/obb4 -> /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 lines19dde20c: HTML document text28ca44b8: GIF image data, version 89a, 1 x 10029b5cf95: JPEG image data, JFIF standard 1.0229f711e8: JPEG image data, JFIF standard 1.02301c338b: 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

Agenda

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

Questions?