Maintaining Android in the enterprise
Risk Management
SQLite Examined
If you want to analyze such databases (e.g., to obtain a history of past web actions), you first need to grab the database off the Android device. The virtualization capabilities of the Android SDK provide a useful tool for testing and learning techniques – you can perform open heart surgery on the system to your heart's content without bricking a device. However, you do need to provide the required content yourself via adb push
and adb pull
.
For a faster approach, you can simply search the Internet for existing images with preconfigured data. Many practice images are available; viaForensics, for example, offers various free image downloads [13].
Yaffs Nandump Image and Sleuth Kit
As an example, in the following, we will look at the yaffs2-nexus-one-postpopulation.nanddump
image. Its file name extension, nandump
, is indicative of the Yaffs filesystem, which only a few programs can read. Linux drivers are now available from the Yaffs project [14].
Even though these drivers can be added to the system that you need to evaluate at run time, using the Sleuth Kit 4.1 extensions seems more elegant. For the first time, they come with direct support for Yaffs and ext4. Because most repositories still offered legacy versions of Sleuth Kit when this issue went to press, admins wanting to follow these analysis steps need to build the program from the source code. You can do this with the four commands from Sleuth Kit in Listing 4.
Listing 4
Sleuth Kit
01 [root@pc]# fls -V 02 The Sleuth Kit ver 4.1.0 03 04 [root@pc]# fls -f list 05 Supported file system types: 06 ntfs (NTFS) 07 fat (FAT (Auto Detection)) 08 ext (ExtX (Auto Detection)) 09 iso9660 (ISO9660 CD) 10 hfs (HFS+) 11 ufs (UFS (Auto Detection)) 12 raw (Raw Data) 13 swap (Swap Space) 14 fat12 (FAT12) 15 fat16 (FAT16) 16 fat32 (FAT32) 17 ext2 (Ext2) 18 ext3 (Ext3) 19 ext4 (Ext4) 20 ufs1 (UFS1) 21 ufs2 (UFS2) 22 yaffs2 (YAFFS2) 23 24 [root@pc]# fls yaffs2-nexus-one-postpopulation.nanddump 25 d/d 2: lost+found 26 d/d 261: dontpanic 27 d/d 262: misc 28 d/d 268: Local 29 d/d 270: data 30 d/d 271: app-private 31 d/d 272: app 32 d/d 273: property 33 d/d 274: dalvik-cache 34 d/d 291: anr 35 d/d 292: system 36 d/d 394: backup 37 d/d 3: <unlinked> 38 d/d 4: <deleted> 39 d/d 61867264: $OrphanFiles 40 [...] 41 42 [root@pc]# fls -r yaffs2-nexus-one-postpopulation.nanddump | grep browser.db 43 +++ r/r * 1573464: browser.db-journal#600,6 44 +++ r/r * 3670621: browser.db-journal#605,14 45 +++ r/r * 3408487: browser.db-journal#615,13 46 +++ r/r 656: browser.db 47 +++ r/r * 8913552: browser.db#656,34 48 +++ r/r * 8651408: browser.db#656,33 49 [...]
You can now start your investigations. The Sleuth Kit version used in the listing is 4.1.0 (4.1.3 is now available); it supports Yaffs, the filesystem is readable, and you can discover directories and files.
In this example, the admin wants to find and reconstruct the browser history of the Android browser. The requested file is browser.db
with inode 656. This search result was missing in Listing 4 because the search was not performed recursively. However, it is interesting to see that older versions (journals) of the file also exist here.
Wear Leveling Generates Journal Files
This situation is a result of wear leveling [15], which involves the flash memory under Yaffs attempting to distribute writes conservatively among the memory cells. Forensic scientists love this; they can evaluate several files even if the user has been deleted or the history purged. To do this, you need to extract browser.db
with the icat
command,
[root@pc]# icat yaffs2-nexus-one-\ postpopulation.nanddump 656 > browser.db
along with the meta-information from the image, and view it with the graphical sqlitebrowser (Figure 6).
As seen in the figure, the Date
field is still in PRTIme
format, along with the hard-to-read Unix timestamps. An Awk script generates meaningful values:
[root@pc]# awk '{print strftime("%a, \ %d %b %Y.%H:%M:%S",($1/1000000-11644473600))}'
Similar information can be read from the image for almost any installed application; the backup or the push and pull commands generated by ADB already allow similar analyses on the running system. If you do this on a regular basis, and possibly automate the process, including measures as prescribed by corporate policy, you have at least a good chance of reducing the time window for break-ins.
If that's not enough, memory dump analysis can help: Memory dump analysis of a running system with Volatility [16] also is available for Android.
Buy this article as PDF
(incl. VAT)