Post-Mortem Memory Analysis of Cold-Booted Android Devices - - PowerPoint PPT Presentation

SLIDE 1

Post-Mortem Memory Analysis of Cold-Booted Android Devices

Christian Hilgers Holger Macht Tilo Müller Michael Spreitzenbarth

FAU Erlangen-Nuremberg Chair of Computer Science 1

• Prof. Felix Freiling

IMF 2014

8th International Conference on IT Security Incident Management & IT Forensics May 12th - 14th, 2014 Münster, Germany

SLIDE 2

Introduction: Cold-Boot Attacks against Android

SLIDE 3

FROST

• FROST: Forensic Recovery of Scrambled Telephones
• Cold-boot based recovery tool for encrypted

Android smartphones.

• Scenario:

– Criminal leaves phone behind at the scene, or

the phone gets confiscated.

– The suspect is not able or willing to tell the PIN. – Phone is switched-on when police accesses it,

but its user partition is encrypted.

– Although all data on disk are encrypted, RAM

contents are never encrypted!

SLIDE 4

Remanence Effect

• RAM is not lost immediately after power is

cut but fades away gradually over time.

• Cooling down RAM chips slows down the

fading process (e.g, on PCs up to 40 sec).

• Question: How to acquire RAM dumps

from cold-booted Android phones?

• riginal

~150ms ~500ms ~1sec ~2sec ~4sec ~6sec

SLIDE 5

Example: Samsung Galaxy Nexus

Android phones have open bootloaders that enable us to run our own system code:

• Bootloaders are locked by default
• Bootloaders can be unlocked with

physical access via USB

• Unlocking wipes the user partition...
• …but RAM gets not wiped!

SLIDE 6

The FROST Attack

SLIDE 7

Evaluation: Bit-Error Rate

25-30°C 20-25°C 15-20°C 10-15°C 5-10°C 1 2 3 4 5 6 10 20 30 40 50 60 70 80 90 seconds bit-error rate

SLIDE 8

Post-Mortem Memory Analysis

SLIDE 9

Android Memory Contents

SLIDE 10

Simple Memory Analysis

• Tools like PhotoRec and Strings can recover

plenty of sensitive data from Android images:

• However, forensically more accurate analyses of

Android memory structures are needed:

–

Which data belongs to which process / App?

–

Can recovery be automated by Volatility plugins?

fully recovered partly recovered Address book contacts ✓ Calendar entries ✓ Emails and messaging ✓ Thumbnail pictures ✓ Web browsing history ✓ WhatsApp history ✓ WiFi credentials ✓

SLIDE 11

Background: Dalvik VM

• Dalvik VM = Java Runtime Environment
• one DVM instance per Android App
• to be replaced by ART in future (Android 4.4)

Hardware Linux Kernel Linux Process Linux Process Linux Process Dalvik VM Dalvik VM Dalvik VM Android App 1 Android App 2 Android App 3 APK

DEX Resources

APK

DEX Resources

APK

DEX Resources

SLIDE 12

Volatility Plugins for Linux

• Android is based on the Linux kernel
• each DVM instance is a Linux process
• hence, existing Volatility plugins for

Linux memory images can be used:

– linux_ifconfig – linux_route_cache – … – linux_pslist – linux_proc_maps

(acquires memory mappings of individual processes, i.e. for DVM instances / Apps)

SLIDE 13

Locate DVM Instances

• With existing Linux plugins, we can

identify memory regions per process: linux_proc_maps

• Entry point to each DVM instance:

DvmGlobals

• To analyze a specific App, it is essential

to locate the offset to DvmGlobals in the process memory.

• Therefore, we provide a Volatility plugin:

dalvik_find_gdvm_offset

SLIDE 14

dalvik_find_gdvm_offset

• Volatility plugin to locate DvmGlobals:

c l a s s d a l v i k _ f i n d _ g d v m _

• f

f s e t ( l i n u x _ c

• m

m

• n

. A b s t r a c t L i n u x C

• m

m a n d ) : d e f c a l c u l a t e ( s e l f ) :

• f

f s e t = x m y t a s k = N

• n

e f

• r

t a s k , v m a i n d a l v i k . g e t _ d a t a _ s e c t i

• n

_ l i b d v m ( s e l f . _ c

• n

f i g ) : i f n

• t

s e l f . _ c

• n

f i g . P I D : i f t a s k . c

• m

m } % " " % ! = % " % z y g

• t

e % " % : c

• n

t i n u e m y t a s k = t a s k b r e a k p r

• c

_ a s = m y t a s k . g e t _ p r

• c

e s s _ a d d r e s s _ s p a c e ( ) g D v m = N

• n

e

• f

f s e t = v m a . v m _ s t a r t w h i l e

• f

f s e t < v m a . v m _ e n d :

• f

f s e t } = 1 g D v m =

• b

j . O b j e c t ( % ' % D v m G l

• b

a l s % ' % , v m = p r

• c

_ a s ,

• f

f s e t =

• f

f s e t ) i f d a l v i k . i s D v m G l

• b

a l s ( g D v m ) : y i e l d (

• f

f s e t

• v

m a . v m _ s t a r t ) c l a s s d a l v i k _ f i n d _ g d v m _

• f

f s e t ( l i n u x _ c

• m

m

• n

. A b s t r a c t L i n u x C

• m

m a n d ) : d e f c a l c u l a t e ( s e l f ) :

• f

f s e t = x m y t a s k = N

• n

e f

• r

t a s k , v m a i n d a l v i k . g e t _ d a t a _ s e c t i

• n

_ l i b d v m ( s e l f . _ c

• n

f i g ) : i f n

• t

s e l f . _ c

• n

f i g . P I D : i f t a s k . c

• m

m } % " " % ! = % " % z y g

• t

e % " % : c

• n

t i n u e m y t a s k = t a s k b r e a k p r

• c

_ a s = m y t a s k . g e t _ p r

• c

e s s _ a d d r e s s _ s p a c e ( ) g D v m = N

• n

e

• f

f s e t = v m a . v m _ s t a r t w h i l e

• f

f s e t < v m a . v m _ e n d :

• f

f s e t } = 1 g D v m =

• b

j . O b j e c t ( % ' % D v m G l

• b

a l s % ' % , v m = p r

• c

_ a s ,

• f

f s e t =

• f

f s e t ) i f d a l v i k . i s D v m G l

• b

a l s ( g D v m ) : y i e l d (

• f

f s e t

• v

m a . v m _ s t a r t )

SLIDE 15

Generic Volatility Plugins

Altogether, we provide five Volatility plugins that can generically be applied to Android Apps:

– dalvik_find_gdvm_offset

find the DVM instance of a process

– dalvik_vms

find all DVM instances in memory

– dalvik_loaded_classes

list all classes of a DVM instance

– dalvik_class_information

list information of a specific class

– dalvik_find_class_instance

find a specific class instance

SLIDE 16

Example Outputs

• find DVM instances:
• find loaded classes:
• ...

$ ./vol.py [...] dalvik_vms -o HEX PID name heapStartingSize heapMaximumSize

• ---- --------------- ---------------- ---------------

2508 zygote 5242880 134217728 2612 system_server 5242880 134217728 2717 ndroid.systemui 5242880 134217728 stackSize tableSize numDeadEntries numEntries

• --------- ---------- --------------- ---------------

16384 4096 0 2507 16384 8192 0 4123 16384 8192 0 2787 $ ./vol.py [...] dalvik_vloaded_classes -o HEX -p 4614 PID Offset Descriptor sourceFile

• --- ---------- -------------------------------- ----------------

4614 0x40c378b8 Ljava/lang/Long; Long.java 4614 0x40deb6d0 Ljava/io/Writer; Writer.java 4614 0x414e2f60 Lde/homac/Mirrored/ArticlesList; ArticlesList.jav

SLIDE 17

Specific Volatility Plugins

• The generic plugins are designed to

support data recovery from any Android App.

• Additionally, we provide four examples

how to use these plugins in forensically interesting use cases:

– dalvik_app_calllog – dalvik_app_lastInput – dalvik_app_password – dalvik_app_pictures

SLIDE 18

Case A) Call Log Recovery

• Goal: recover list of incoming/outgoing

phone calls from confiscated phones

• Target process:

c

• m

. a n d r

• i

d . c

• n

t a c t s

• Target class:

P h

• n

e C l a s s D e t a i l s . j a v a

One instance of this class is in memory per call log entry. Class members:

– type (incoming, outgoing, missed) – duration, date and time – telephone number, contact name, photo

SLIDE 19

Case B) Last User Input Recovery

• Goal: retrieve the last given user input

from a confiscated phone

• Target process:

c

• m

. a n d r

• i

d . i n p u t m e t h

• d

. l a t i n

• Target class:

R h i c h I n p u t C

• n

n e c t i

• n
• Target field:

m C

• m

m i t t e d T e x t B e f

• r

e C

• m

p

• s

i n g T e x t (this field is like a keyboard buffer)

SLIDE 20

Case C) User PIN Recovery

• Goal: recover the user PIN (if entered at

least once before phone is confiscated)

• Target process:

k e y s t

• r

e

(Note: this process is an Android system process and not running a DVM instance)

• Target location:

– relative address inside k

e y s t

• r

e

– +/- 200 kBytes at maximum

SLIDE 21

Case D) Photo Metadata Recovery

• Goal: recover metadata like date, time

and GPS coordinates from photo gallery

• Target process:

c

• m

. a n d r

• i

d . g a l l e r y 3 d

• Target class:

L

• c

a l A l b u m └ L

• c

a l I m a g e

Class members:

– name, size, date and time – GPS coordinates (if activated)

SLIDE 22

Volatility Plugins Availability

• GNU General Public License 2.0
• Link:

https://www1.cs.fau.de/filepool/projects/android_volatility_plugins.zip

v

• l

a t i l i t y / v

• l

a t i l i t y / p l u g i n s / v

• l

a t i l i t y / p l u g i n s /

• v

e r l a y s / v

• l

a t i l i t y / p l u g i n s /

• v

e r l a y s / l i n u x / v

• l

a t i l i t y / p l u g i n s /

• v

e r l a y s / l i n u x / d a l v i k _ v t y p e s . p y v

• l

a t i l i t y / p l u g i n s / l i n u x / v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k _ a p p _ c a l l l

• g

. p y v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k _ f i n d _ c l a s s _ i n s t a n c e . p y v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k _ a p p _ p a s s w

• r

d . p y v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k . p y v

• l

a t i l i t y / p l u g i n s / l i n u x / f l a g s . p y v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k _ a p p _ p i c t u r e s . p y v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k _ l

• a

d e d _ c l a s s e s . p y v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k _ c l a s s _ i n f

• r

m a t i

• n

. p y v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k _ v m s . p y v

• l

a t i l i t y / p l u g i n s / l i n u x / d a l v i k _ a p p _ l a s t I n p u t . p y

SLIDE 23

Anti-Forensics Thwarting the Cold-Boot Attack

SLIDE 24

Anti-Forensics by Manufacturers

• Smartphone manufacturers could change their

bootloader policy, such that:

– bootloaders cannot be unlocked (like in

iPhones and Windows Phones)

– or RAM is wiped (not only disks) when

bootloaders get unlocked

• However, this only raises the bar for forensic

memory acquisition. The root problem, i.e., sensitive data in RAM, is not solved.

SLIDE 25

Anti-Forensics through Full Memory Encryption

• Obviously, full disk encryption (FDE) does not

counteract cold-boot attacks on Android RAM.

• In analogy to FDE, main memory must be

encrypted.

• However, due to performance and hardware

constraints, only academic solutions exist:

– M. Henson and S. Taylor, “Beyond Full Disk Encryption:

Protection on Security-Enhanced Commodity Processors,” Jun. 2013.

– A. Wurstlein, “Design and Implementation of a Transparent

Memory Encryption and Transformation System,” Aug. 2012.

SLIDE 26

Anti-Forensics through Secure Deallocation

• Idea: Erase highly sensitive data from

RAM on screen lock events (e.g., PINs and passwords).

• Problem: Dalvik VM does not enable the

application level programmer to reliably erase data from RAM.

• Future Work: Patch the DVM to allow

secure deallocation.

IMAP PW

lock screen

erased

unlock screen

IMAP PW

re-read password from (encryted) disk

SLIDE 27

Conlusions

SLIDE 28

Conclusions

• Screen locks (e.g., PINs) and disk

encryption are insufficient to protect sensitive data on smartphones today

• “Smartphone Security Survey” by Ponemon / AVG (2011)

–

89% use their smartphone for email

–

66% keep sensitive business data on it

–

34% use their smartphone for e-payment

• “Smartphones are “perfect targets” for cold boot attacks:

– smartphones contain sensitive data – smartphones are more often lost than laptops – smartphones are usually switched on (but locked)

SLIDE 29

Thank You! Questions?