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.

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).

Figure 6: The user has accessed websites of the CIA, DEA, and secret services all the way up to the White House.

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.