15 Advanced Android Analysis
Android devices are the most widely used smart devices globally. In fact, on May 17, 2017, the CEO of Google, Sudar Pichai, announced that more than 2 billion active Android devices were in use globally. Some research firms have placed the market share as of August 2017 at almost 90 percent (87.7 percent stated by DMR, a statistical company), though Google VP Dave Burke reported it was around 66 percent in all actuality, after statistical companies put market share considerably higher. Consumers can purchase any of the approximately 18,000 to 25,000 Android devices available, including smart phones and tablets. Luckily for the mobile examiner, these devices all have similar file system structures.
This chapter is dedicated to the deconstruction and analysis of the many files stored within the Android file system. As with a logical analysis of Android devices, in order for an examiner to perform an advanced analysis, a file system must be available. Such an analysis can be accomplished using a backup of the device, a noninvasive rooting technique, or acquisition via JTAG (Joint Test Action Group), ISP (In Service Programming), or a chip-off procedure. An examiner can also obtain some app and file system files using the Media Transfer Protocol (MTP) method discussed in Chapter 10, which will obtain the internal storage area along with external media.
As with iOS devices, there is, of course, the “tip of the iceberg data,” but that information pales in comparison to the app data, file system cache files, and user storage files that can be found intertwined within the Android file system. Using SQLite queries and Python scripting, as discussed in Chapter 14, the examiner can analyze artifacts that an automated tool is incapable of parsing. Deep analysis of the Android file system should be attempted with each examination. This chapter lists common storage areas, such as Short Message Service (SMS), contacts, Multimedia Messaging Service (MMS), and call logs, along with files that are found within most Android file systems. Tables and lists of additional file locations are also revealed throughout the chapter.
As discussed in Chapter 13 with regard to iOS advanced analysis, freefile lists and the write-ahead log (WAL) are also present within an Android device, and this data will be extremely helpful during many examinations. Android malware can also pose a significant problem for the Android operating system, and it can infiltrate many of the apps from Google or any other Android app repository. An examiner must investigate the possibility of malware within the apps on an Android device, which can add complexity to any Android investigation.
The examination of an Android device should never be limited simply to obtaining a logical collection using a mobile forensic solution’s application package (APK) file. Using the correct processes, procedures, and methodologies can yield a monumental amount of investigatory data in any Android mobile forensic examination.
Android Device Information
Android device manufacturers include LG, Samsung, Motorola, ZTE, and others, but it is the underlying file system that is of importance to an examiner, not the manufacturer. The file system is formulated by the Android OS and the version used by the actual device. One Android device might look like an apple, while another looks like a banana—but the examiner should understand that the data under the hood, including the file system look and feel, is almost identical in all of them—depending, of course, on the OS version. Granted, an Android device’s firmware can make a difference—so Samsung might include some files that Motorola does not, and LG might include some files not found in a ZTE device. The point is, one Android device might look different from another on the outside, but the underlying file system on both is remarkably similar. To be quite honest, the storage areas for actionable examiner data are relatively consistent over OS versions, with security and low-level development updates being the main changes.
Examiners should refer to the device examination by operating system type instead of by simply stating they are examining a Samsung Galaxy device. With more than 60 different Samsung Galaxy devices on the market and available, referring to the operating system version, security patch, and model first will help solidify the file system variations. It is possible the same Samsung Galaxy devices can be using two different versions of the OS, depending on the carrier. Documenting the OS version can also assist the examiner when analyzing another similar device, because often file system location and other data are the same.
To obtain many of the details (such as security patch and model number) described in this chapter, the examiner or device owner will usually need to unlock the device to examine the settings. Most tools report most of the data mentioned here, with the exception of the security patch version.
The particular methods used to obtain the information should not matter so long as a file system is available. The location of data within the file system will be the same, whether an image is obtained from a binary dump, backup, JTAG/ISP, or chip-off. The information in this chapter should be used as a map to point the examiner toward the various pots of gold within the Android file system.
Partitions
When an examiner is completing a non-invasive or an invasive physical collection of an Android device, he or she can find many partitions within the file system. Some practitioners state that there are six partitions, but from personal experience, I know that there is too much variation among devices to estimate the number of partitions an examiner may encounter—I have encountered four, eight, and even twelve partitions. The issue with today’s devices, and encryption, will be the primary partition (userdata), and the mount point /data folder will be fully encrypted.
Partitioning in Windows creates independent areas on disk, assigns a drive letter, decides where an operating system can be loaded if active, and determines where files can be stored or designated as a program directory. Android devices, however, do not use drive letters, but instead use mount points, directories under the root directory (/) that contain the data from each partition. All partitions are within the internal storage of the Android device but are logically separated (see Figure 15-1). The Android system sees partitions as separate, independent media, even though they are mounted in a single logical location under root. This root location is in fact a virtual pointer to the actual location of the data in flash media, and this is evident when you look at a JTAG binary dump or chip-off, where many folders are located under root and contain various file system files and folders.
FIGURE 15-1 A JTAG binary file, when imported into FTK Imager, will show as a logical file system under the root folder.
Depending upon the Android’s operating system version, an examiner can encounter various options. For example, prior to Honeycomb (version 3.0), the sdcard0 partition would be accessible within the partition table and was often included in a collection by use of a symlink (symbolic link) to /mnt/sdcard, the mount point for the media card. However, on device versions later than Gingerbread (version 2.3), the examiner may see another “external media card” that may actually be the internal media card. Because some devices can contain both internal and external media, an examiner should always examine both the sdcard and ext_sd (sdcard2, sd, external_sd) partitions. In addition, some other partitions reside only within certain device families. Table 15-1 shows the Android OS version numbers, release dates, and common names.
TABLE 15-1 Android Operating Systems
For example, Samsung Galaxy S Android devices have a data partition within their file systems called dbdata. With the Samsung Galaxy series, the devices not only kept the legacy dbdata partition but also conformed to the other Android operating systems and included a userdata partition. Samsung devices are the only devices in which the user data is split between the dbdata and userdata partitions, which is observed primarily in Samsung S Series Galaxy devices running Froyo and Gingerbread (2.2 and 2.3) versions of Android. An examiner should know whether both of the partitions are available or the singular dbdata partition is available. When data is split between these two partitions, the personal information manager (PIM) data and “tip of the iceberg data,” along with their respective databases, are generally stored in the dbdata partition, and app data, phone settings, and configurations are stored on the userdata partition. If the examiner’s solution does not allow for simultaneous importing of both partitions, these locations will have to be individually analyzed to recover valuable user data. The predominant version of Android remains 7.0 and 7.1 for devices, with the exception being the Pixel and Nexus series devices that are currently utilizing Android 8. However, current Android devices (as of this writing, Android 9x) consistently store third-party app data and PIM data within the /data folder (AKA userdata). The legacy dbdata partition has not been observed since the Series S Samsung devices.
When examining an Android device, the examiner usually will be looking through the userdata partition, found at /data/data for physical and /data for critical artifacts, but the cache partition often contains valuable data as well. The various file system types, along with paths to various files, will be covered in the following section. Table 15-2 shows various memory partitions and descriptions that might be encountered. Note that this list is not all inclusive but represents partitions commonly encountered.
TABLE 15-2 Partitions Encountered Within an Android Mobile Device
The File System
The various Android file system types were referenced in Chapter 8 and range from the first Android devices using YAFFS (Yet Another Flash File System) or YAFFS2, to Robust File System (RFS), to the EXT (Extended File System) variants, and F2FS (Flash-Friendly File System) developed by Samsung. Predominantly, EXT 4 is used as the underlying file system format for today’s Android devices. If the device utilizes an internal or external media card, various File Allocation Table (FAT) file system formats could be used. The newest SD card format was created by Samsung but released in Android O, called SDCardFS, which is replacing FUSE (Filesystem in Userspace). This is something an examiner will not notice, but it fixed a glaring forensic implication that few could explain: the change of a date on media if transferred to a computer from the device, typically via MTP. The date and time was often altered, which could have serious forensic implications. These various file systems are currently interpreted by most mobile forensic tools, with the differences in file systems generally being the size of the storage blocks on the flash, journaling, read/write speed, and minimum/maximum file sizes. The newer the device OS version, the larger the block size typically. Today’s mobile forensic tools can distinguish and mount these file systems without a problem, displaying a file system to the examiner that can be navigated and parsed. It was typical in the earlier years of Android analysis for the examiner to use Linux tools and command line tools within Windows to format these file systems and view them properly. That, fortunately, is no longer the case. What this means to the examiner is that the examination and analysis can occur immediately, requiring little work to maintain or rebuild the Android file system’s integrity—so the examiner can concentrate on the analysis.
The userdata partition contains not only the user data storage areas but also app information, app configuration files, uncompiled app code, and virtual sandboxed–compiled code. With the exceptions mentioned with the dbdata partition, on some Samsung S Android devices, the examiner will find a gold mine of information within this area. Not only are user files and app data available, but the actual app code is within the examiner’s reach. With the app code, an examiner can also look for malware instances—something a standard logical collection and analysis cannot offer. The cache partition (Figure 15-2) can contain /backup, /lost+found, and /recovery folders. The /backup folder often contains Android app packages with stored temporary data and can yield good artifacts. The /lost+found folder will contain files that had been recovered as a result of file-system corruption and should also be examined. Finally, the /recovery folder holds log files listing the recovery operations of the mobile device.
FIGURE 15-2 The cache partition should be examined for possible evidence when this partition exists within the Android device.
Android dbdata and userdata partitions extracted from a Samsung SCH-I500 running version 2.2.3 are shown in Figures 15-3 and 15-4. There are obvious differences between the two partitions in the number of folders and files stored. Within the userdata partition is the majority of user data within an Android file system, including valuable app data and system configuration files; the dbdata partition contains valuable user data in the lone /databases directory. The separation of user data between partitions is not typical, and generally the examiner will concentrate on artifact hunting within the userdata partition and media storage (such as sdcard, emmc, sd) partitions within the Android device output. Outlined in Table 15-3 are good locations for an examiner to investigate when conducting an advanced analysis of an Android’s userdata file system. The file system layouts for today’s devices up to Android 8.0 are similar, as discussed later in the chapter.
FIGURE 15-3 The dbdata partition in some Samsung Android devices can contain valuable data within the /databases folder.
FIGURE 15-4 The userdata (data) partition is much more robust and is found with the dbdata in predominantly Samsung Galaxy S Androids, but in /data through the current OS (9x).
TABLE 15-3 Android Partitions Compiled to Show the Major Landmarks Within the userdata, dbdata, sdcard, and emmc Partitions
Unallocated space can be observed within each Android partition and is accessible with physical collection. This area typically is unstructured because software is unable to build a file view. Generally, an examiner must use data carving tools to parse through the many blocks of data within this area. Many mobile forensic tools contain some type of data carving tool, but any data carving conducted by a forensic tool should allow for custom file type searching along with typical file types (such as jpeg, .html, .pdf, and .doc). FTK, EnCase, Scalpel, Oxygen Forensic Detective, and Cellebrite Ultimate are recommended. The carving of unallocated space, when available, should occur, because many images, videos, database files, text strings, and other evidentiary files can be recovered from this space. (This luxury of unallocated space is not available for iOS, as discussed in Chapter 13.) Of course, if the file system of an Android device has been encrypted, recovery is much more difficult and sometimes impossible. In devices running Android 6x to Android 9x, encryption is the default.
Devices up to Android 7 using full disk encryption (FDE) are based on dm-crypt, which works at the block device layer and can encrypt the device and removable media. This is not a file-level encryption but a full disk encryption, which differs from iOS encryption. FDE on an Android applies only to the user partition (/data), not the entire system. This means that the system partition containing the OS is unencrypted, and often the way in which decryption techniques exploit the OS is via the system partition. The encryption is only as good as the password in place, since the algorithm is based on the complexity of the password or phrase. At Android 5.0, new techniques for encryption were added that allowed only the used portions of the data partition to be encrypted, helping with speed. Furthermore, added to Android 5.0 was the encrypt on first boot feature, and an off-the-shelf device running Android 5.0 would encrypt by default on the first bootup; these devices cannot be returned to an unencrypted state. This is different for devices that had been upgraded to Android 5.0; these devices could, in fact, be returned to an unencrypted state if a factory reset was performed. Some investigative methods exploit devices with unlocked bootloaders, replace the system OS partition, and attempt to capture a user entering a password with a keylogger. Others, such as Passware, tested versions up to Android 4.0, to brute-force the password or phrase and then use the information to decrypt the user data.
The caveat to all of these tools is an unlocked bootloader, because using these methods on a locked bootloader can lead to all data on the user partition being wiped.
Also, open source tools such as hashkill (now deprecated) can break the passcode or phrase in versions up to Android 4.4, even when another encryption password is used along with the lock PIN or password. Android Lollipop (5) changed the encryption to rely not only on the PIN or passcode but also a secondary salt; thus, the currently available methods will not work. Android 5 devices came out of the box with encryption turned on, but without a password, and using the randomly generated keys shipped with the device, the user data via regular extraction such as ADB backup and logical agent is available when the device is turned on. If the user does not enter a password, the device data will be still be accessible with forensic tools, but physical extraction of the data can be hampered because of the encryption. At Android 7, file-level encryption was implemented and made available, which obviously made decryption more difficult, because at the file level a different decryption key could be implemented, which is much different from block-level or entire device encryption. This is true for both Android 8 and 9. The decryption of these devices upon obtaining a full physical extraction is where many commercial tools are devoting their research and development.
A basic agent-type logical examination of the Android device does not allow access to the device file system because the methods employed by software solutions simply use an installed APK file to run code to query known databases. If the database has a permission level appropriate for communication with another app, the data can be extracted. As mentioned, access to the internal and external media partitions is accessible with MTP tools and will allow for the collection of this data and give the examiner a file system–like experience—often containing many app media storage areas—but access to the /data area of the device at critical databases is not available unless root access is granted. If an examiner must conduct an advanced analysis of an Android device, the tool or method must either gain root (such as custom ROM, exploit, and so on) access via JTAG/ISP or chip-off. Some access to app data can be obtained using the built-in backup function (ADB Backup) within Android versions 4.x and later, but again this is only a portion of the data from the Android user data partition, and as the operating systems have progressed, the amount of app data has dwindled.
Predominant Android File Types
Android devices contain a multitude of file types, ranging from APK, DEX, LOG, SO, ASEC, DB, and JSON, to XML and TXT files. Also included are WAL files and journal files for SQLite databases—significantly more journal files than are found within the iOS file system when looking to older Android OS devices. The types of files an examiner will use in artifact investigations will be SQLite and XML files. APK and DEX files can be used for malware investigations, as discussed later in the chapter in the section “Android App Files and Malware.”
SQLite databases contain significant information, and an investigator would be remiss if he or she did not conduct a comprehensive analysis of these files. Android SQLite databases are no different from those of iOS and can be examined in much the same way. SQLite databases contain tables and fields with user preferences, data, and any persistent data the user and app needs stored for later use. Hundreds of thousands of apps are available for installation on any Android device, and mobile forensic solutions cover only 0.014 percent of the available applications currently available on the Google Play store. Of those supported apps, automatic parsing of data is often flawed. Because apps can change upon each update, a mobile solution is often outdated at release, so these solutions are always at a technological disadvantage. An examiner who can parse apps manually will always have the upper hand on these advances. Figure 15-5 shows an example of parsed data from a SQLite database. In this example, many tools parse the media store but fail to recognize the associated thumbnails.
FIGURE 15-5 Collecting SQLite information manually parsed from apps that are not supported by any automated tool is a necessity with Android devices, such as the MediaStore database from com.android.providers.media.
XML (Extensible Markup Language) is used extensively within the Android file system for settings, passwords, application protocols, network data sharing, and other preferences. The most significant XML files are located in the shared_pref folder within the app folders (see Figure 15-6). XML is a file type that uses <?xml version="1.0" encoding="utf-8"?> as a header, with a set of rules for encoding documents in machine-readable form. As discussed in Chapter 14, XML can be cleanly parsed using Python scripts to decode and display the key and values listed within the file.
FIGURE 15-6 XML files found within an app’s shared_pref folder can be used by an examiner to obtain critical investigation data.
Other file types within the Android file system include text files, log files, APKs, and DEX files, as discussed in the following sections.
Artifacts
Much like iOS, an Android device is full of digital gold if the file system is obtainable. Hundreds of SQLite databases, XML files, text files, media files, and more are stored within the user data area of the device. A logical extraction of an Android device still yields some great data, but the information has no “meat”—in other words, the information displayed is simply a query of the appropriate database, and the data is rendered to the examiner within the user interface. What about the files this data came from? These files contain valuable fields that might not have been queried by the mobile forensic solution’s APK file but can be accessed if the file is obtained. Also, deleted data within the database free pages can be recovered, as discussed in Chapter 13 with iOS, along with the WAL files that are used. This “tip of the iceberg data” and its locations are listed in Table 15-4 to assist the examiner in recovering the data that cannot be recovered with a logical collection.
TABLE 15-4 Standard “Tip of the Iceberg” Android Data, with Database Locations for Additional Analysis when Needed and Validation on Automated Parsing by Forensic Tools
Additional files such as system files, log files, and user settings within the Android file system are also available and can reveal many things about the device, including the OS version, mobile device specifics, user information, and other items pertinent to mobile devices use. By relying on a standard logical Android collection, the examiner is limiting his or her examination to a very small percentage of the available data within the mobile device.
“Tip of the Iceberg Data”
The mobile forensic solutions used by the examiner often collect significant data from an Android device. This data is active data from the databases within the user data and typically includes data from contacts, call logs, SMS, MMS, media, browser, Wi-Fi, and a few others. This is the “tip of the iceberg data,” with the bulk of the information residing “underwater,” however—even more so than with iOS. Because an Android logical extraction queries only the active data, the inactive or free page data or any other field not queried will not be collected. At least with iOS, an examiner would have access to the database the mobile solution queried to obtain the data presented in the user interface—but with Android, not so much.
Using advanced collection methods, however, the examiner can collect the entire file system, including database files and others, for advanced analysis. Table 15-4 represents the typical data that is extracted using a mobile solution’s APK file. Using the associated paths, the examiner can investigate the various database files for additional information. Also, information logically obtained by the mobile forensic solution can be verified and validated to ensure that dates and times are accurate, along with any missing fields from the reported data. An examiner can pull additional information from these locations that the logical collection missed.
Additional File System Locations
A common mistake made by many examiners is to begin the investigation immediately by going to the app area. Although the app area is a fruitful place and often mesmerizes even the most seasoned examiners, a better idea is to venture into many other areas within the Android file system.
Device configuration files, installed application accounts and device accounts, user settings, device details, and often password information can be gleaned from outside of the app data folder. Needless to say, the actual APK file and the compiled DEX files can be obtained in a file system–level extraction. With the actual files, static malware analysis of the code within the APK and DEX files often helps determine whether malicious code is present. The following section will outline some of the more plentiful areas for gathering system information. All of the root directory information and path data are located in Table 15-3 earlier in this chapter.
Clipboard Information
The path /clipboard/ is generally found only within a Samsung Android device and contains various folders, each identified with a unique number. Pure Android systems store clipboard data in RAM by the Clipboard service. However, each folder holds a file called clip (see Figure 15-7). The clip file header holds a value, android.sec.clipboard.list.ClipboardData<type of data>, and the end of the header is xptX (X = a variable value that changes depending upon the clip file). If the <type of data> is text, the clipboard content will be a text string; if it’s HTML, it’s a web page; if Bitmap, it’s an image file. If a bitmap is indicated within the header, the image files will be in the same folder as the clip file. If text or HTML, the data immediately follows the header. In current Samsung devices, in a secondary location, android.samsung.clipboardsaveservice/f/, the examiner can find saved images to the clipboard.
FIGURE 15-7 A clip file along with the associated image files
Log Files
In Android devices, particularly Samsung devices, services report errors and then log these errors within the log folder for exceptions within an app or device service. An examiner can find significant information in this folder and associated text files within a physical extraction. However, in a logical ADB extraction, several commercial tools will also include the files Dmesg.log, Dumpsys.log, and Logcat.log. Some text files of interest are listed here:
• /log/CallDropInfoLog.txt Listing of failed calls along with the dates and times of the dropped calls. The date is in the format YYYY.MM.DD HH:MM:SS.
• /log/CallNosvcInfoLog.txt Listing of calls that were attempted when the device did not have service. The date is in the format YYYY.MM.DD HH:MM:SS.
• /log/dumpstate_app_error_x.txt.gz If more than one dumpstate file is within the folder, the x will be an ordinal number. This file is a compressed folder created when an app crashes with an uncaught runtime exception. Tools such as 7-Zip can be used to access dumpstate files. Android versions up to 4.4.2 can contain significant user logins, settings, and more. The dumpstate file captures the state of the device at the time of the app failure, often producing data that cannot be found anywhere else on the device. Android 4.4.4 patched some of these vulnerabilities. The following illustration shows a log file produced within an Android 2.3 Samsung SGH-I727 device. It clearly indicates an incoming message alert from a phone number that was critical to an investigation, since the date and time were also logged.
• /log/dumpstate_app_anr_x.txt.gz If more than one dumpstate file is within the folder, the x will be an ordinal number. This file is a compressed folder that is created when an app receives an App Not Responding (ANR) event. A message to the user of the device is generated, indicating that the app is not responding and the log will be created. This file can be opened with tools such as 7-Zip. By using regular expressions formatted for e-mail, there is a possibility that data can be recovered. Android 4.4.4 patched some of these vulnerabilities.
• /log/dumpstate_app_native_x.txt.gz If more than one dumpstate file is within the folder, the x will be an ordinal number. This file is a compressed folder that is created when an app error occurs during a process. This error does not cause an exception and subsequent crash, and the user is not notified because this process is moved into the background services. This file can be opened with tools such as 7-Zip. By using search terms such as contentView, contentText, and tickerText, an examiner can find relevant data within some Samsung device log files. Android 4.4.4 patched some of these vulnerabilities.
• Dmesg.log This log will report health information about the device to include temperature, battery operation, current, and more. This documentation log is created with the device system reports information on the device.
• Dumpsys.log This log will report on application starts, current applications running, reboots, resets, Bluetooth data to include MAC, BSSID, SSID address, and much more. This file can be used for the investigation of a reset device or to get the application last used if there are no other details extracted by the software.
• Logcat.log This file can capture application logs that are running on the device. For example, the syncing of contacts to an automobile via Bluetooth can be identified within the logcat.log file, along with many other interactions the system has with apps on the device.
System Configuration
Settings that persist over restarts on an Android device can be stored within the /property folder and can assist an examiner in determining user and device settings. These files are all prefixed with persist and then the <data description>.
• data/property/persist.radio.cdma.mdn This setting within a CDMA device, if available, will show the device’s mobile dialing number (MDN), the device phone number.
• data/property/persist.service.adb.enable This setting indicates whether or not Android Debug Bridge (ADB) is enabled on the device. This is a Boolean value; 0 is false and 1 is true. This will generally be 1 if the device was collected using mobile forensic tools, so the state will not determine whether the user had enabled ADB. However, if the examiner uses JTAG or chip-off techniques, this value will be indicative of the user’s actions.
• data/property/persist.sys.country This setting indicates the country in which the device service is registered, which may or may not indicate where the device was last or is currently located. This will be a two-character representation such as US, KR, or UK.
• data/property/persist.sys.locale This setting indicates the language and country in which the device service is registered, which may or may not indicate where the device was last or is currently located. This will be a two-character representation such as US, KR, or UK.
• /property/persist.sys.language This setting indicates the language the device is currently set to display and use, represented by two characters; these identify the culture code used by the device for letters, numbers, signs, and so on. The file persist.sys.locale contains the language now.
• dataproperty/persist.sys.timezone This setting is the last system time zone update to the device. Since most mobile devices update their time zone, this value will represent the last time zone location of the device. This can be obtained via a cellular or Wi-Fi connection, so an examiner must be sure to isolate the device because this value could update if the device connects to another network.
• data/property/persist.usb.config This value indicates what services will be enabled when the device is plugged into a computer. Here are some examples:
• mtp Only MTP will be available.
• mtp, adb Both services will be active when the device is plugged in. This will be seen frequently if the examiner is using mobile forensic tools that root the device, and a true value will generally be available only with a JTAG or chip-off collection.
• /property/persist.mot.encrypt.mmc This Boolean value is present only in a Motorola Android and indicates whether or not the external media card will be encrypted.
Usage and Logs
The /system folder contains a wealth of information for the examiner, including more settings and storage files for Android system functions, account information, security information, and app listings.
• data/system/accounts.db This SQLite database lists all of the accounts that are used on the Android device. The app username and password can be located in this file. As of version 2.3, the password value is no longer plain text but a Base64-encrypted value. For an examiner, this can be valuable information for identifying usernames for specific Android accounts.
• data/system/user/0/accounts.db This SQLite database lists all of the accounts that are used on the Android device. The app username and password/token can often be located in this file. For an examiner, this can be valuable information for identifying usernames for specific Android accounts.
• /system/dmappmgr.db This is a fantastic SQLite database (Figure 15-8) for an examiner to determine apps that are frequently used and apps found on Samsung devices that had at one time been installed on the device and are no longer there, including the last time the app was launched. For an examiner, being able to determine app usage and services used can be critical to an investigation.
FIGURE 15-8 Actual dmappmgr.db from a Samsung Android device showing the 379 app records outlining the app name, number of launches, and critical date and time information
• data/system/recent_images This folder contains the screenshots of the corresponding items (app) and actions found within the recent_tasks folder. This could be a gold mine, almost a play-by-play of some actions by the user on the phone, along with images of the actions.
• data/system/recent_tasks This folder contains XML files the contain the task ID as well as the activity being utilized by the task, along with date and time information for the first activity time, the last activity time, and the last time moved. This, together with the recent_images, is a great find for the investigation.
• /system/gesture.key This file contains the SHA-1 value of the device gesture lock if it was used. The gesture.key file is a hash of the pattern in a byte array. Many online sources can be used to obtain the gesture coordinates from the SHA-1 hash, but this is not really necessary for an analysis of the file system. If the examiner wanted to examine the device powered on and navigate the user interface, he or she could replace the gesture.key with a hash that has been generated in another Android device and use that file instead of the original. The examiner can then enter the created gesture to unlock the device. This is deprecated, and now the gatekeeper.pattern.key is used. The table lockscreen.password_salt is now in /system/locksettings.db, with the added security of being device-specific.
• /system/packages.list This text file identifies the app location and the app that is currently on the Android device.
• /system/packages.xml This XML file identifies the app location and the app that is currently on the Android device, plus the app permissions.
• /system/password.key This file contains the salted SHA-1/MD5 calculation concatenated. The salt is located in the settings.db secure table under the key lockscreen.password_salt within the /data/com.android.providers.settings folder. If the examiner is looking at this file, access has already been made, and accessing the device via the UI is probably unnecessary. If necessary, the examiner can use the salt and the hash with a tool such as hashkill. This is deprecated, and now the gatekeeper.pattern.key is used. The table lockscreen.password_salt is now in /system/locksettings.db, with the added security of being device-specific.
• /system/SimCard.dat This text file lists the previous and current SIM operator, SIMSerialNumber, PhoneNumber, CurrentSIMCountry, SIMOperator, SIMOperatorName, CurrentSIMSerialNumber, and SimChangeTime, which is encoded in milliseconds. For an examiner, this can be a location to obtain the SIM information of previous UICC cards inserted and the current UICC, even if the UICC is not in the device at the time of collection. This information can be found at /data/com.android.providers.telephony/databases/telephone.db with current devices.
• /system/sync/accounts.xml Android devices enable the user to sync all data across accounts. For an examiner, this can create recoverable evidence, because the account usernames for apps are listed in this file. The examiner can link the username to the associated app using the information found in the accounts.xml file.
• /system/usagestats/usage - <date> These files can assist the examiner when looking for apps on a particular date. The text file is named usage - <YYYYMMDD> and is a Unicode binary file.
• data/system/usagestats This folder has a subfolder, usually 0, which then contains other subfolders: daily, monthly, weekly, and yearly. XML files within the folders include all the apps and details of each. The details are similar to those found in the dmappmgr.db in Samsung devices described earlier.
Wi-Fi Information
Wi-Fi information can be critical for many investigations. The data located within the /misc/wifi folder is recoverable and contains Wi-Fi and hotspot information. This data often shows the SSID and configuration settings.
• /misc/wifi/networkHistory.txt This offers much more verbose connection information than what is found in the wpa_supplicant.conf file on most devices, to include connection times (date/time) and failures.
• /misc/wifi/wpa_supplicant.conf or /wifi/bcm_supp.conf With logical extractions using an APK, the Wi-Fi information is collected, often without passwords. By navigating to the location within the file system, the examiner can locate each Wi-Fi spot to which the device was connected, along with the SSID and password. This information is stored within a dictionary and is readable in a text editor (see Figure 15-9).
FIGURE 15-9 Information from the wpa_supplicant.conf file is clearly readable within a text editor and contains access point names and passwords.
• /misc/wifi/hostapd.conf If the device was set as a hotspot, the information in this file will identify the SSID that was transmitted by the device and the hash of the password.
• /misc/wifi/softap.conf This contains the SSID of the hotspot and password configuration.
/data Folder
The primary source for examiner gold is the /data folder. This folder contains not only the stock Android apps such as e-mail, contacts, call logs, SMS, and MMS but also device-specific apps that may be found only on Samsung devices. This folder will also contain third-party apps and content. Unlike iOS, which has a distinct folder for iOS stock apps and another for third-party apps, the Android does not make that distinction. All apps and even some Android settings files are located within the /data folder. As referenced previously in Table 15-4, some Samsung devices also use a dbdata partition to store this same data, and references within this section will indicate this distinction. This section covers Android settings locations, stock Android apps, some Samsung-specific databases, and third-party apps.
Like iOS, Android will prescribe the reverse-DNS naming scheme for the apps located in the /data folder using the top-level domain (such as com, net, kr, org), the domain, and then the app name as the package name (pkg). Some apps use subdomains as well. For example, Samsung uses com.sec to prefix its stock applications (sec stands for Samsung Electrical Company).
The app folders have a hierarchy much like that of iOS. Android development API and SDK guidelines direct developers on how an app should store data, but like iOS, an app can create folders and store data in these folders if it must persist. Android does indicate that some folders must be used for certain circumstances, and these folders and the other common folders are outlined in Table 15-5. Note that Android development API information specifically outlines the protection of data during backups. This means that a standard ADB backup of Android devices can be missing many third-party application databases. This is not a limitation of the software or ADB, but is simply set by the app developer in the manifest during development.
TABLE 15-5 App Folder Common Directories and Associated Content
Stock Android Folders
Android devices usually contain these folders within the /data folder. Android has two levels of locations that store data—one level uses com.android.providers.<name of app> and the other uses com.android.<name of app>. The com.android.providers apps use the android.providers class, which allows other apps to access the content providers within the apps that are using this class. These apps are generally those with contacts, images, calendar, and SMS. An examiner should recognize all of these items using this class since most of them are artifacts that can be extracted using a logical collection. Because mobile forensic solutions use an APK file to access the content stores within an Android device, the accessible data types must conform to the classes allowed by Android. The standard com.android apps are stock Android apps that ship with the OS; they do not generally allow com.android.provider type control and are infrequently used. A few stock com.android apps contain data, such as com.android.browser, but typically these apps are void of user data. However, most Android devices also use the /data/com.google.android<name of app> path in every device encounter. Some of these locations will also be covered as a semi-default Android stock app with new devices. The following stock Android folders are the places an examiner will likely uncover valuable data on each Android investigation:
• /data/com.android.browser/databases/browser2.db This is the SQLite database of the built-in Android browser that contains tables for bookmarks, history, and user searches. This area should be investigated even if the mobile solution parses this data, because some columns are not reported by automated solutions. This has been deprecated in many Android devices. The path /data/com.android.browser.provider is still available in devices such as Samsung, but only with physical collections. However, the Samsung default is Samsung Internet Browser and is collected with both physical and logical collections at com.sec.android.app.sbrowser. On many Android devices the default browser has been replaced by the Chrome browser located at /data/com.android.chrome/app_chrome/Default/
• /dbdata/databases/com.android.browser/databases/browser.db Same as the previous entry, but this location can be found within some Samsung devices, particularly the Samsung Galaxy S series. This has been deprecated in newer Samsung Androids.
• /data/com.android.browser/databases/autofill.db This SQLite database stores user-saved information such as name and address information to be filled into forms stored within the browser history. This has been deprecated in many Android devices. The path /data/com.android.browser.provider/ path is still available in devices such as Samsung, but only with physical collections.
• /data/com.android.browser/app-databases/Databases.db This SQLite database stores the app and path information for apps using the Android web browser via WebKit functions. The mobile web app database will be stored within the app-databases folder identified within the Databases.db and can be explored to uncover use of that mobile web app. This has been deprecated in many Android devices. The path /data/com.android.browser.provider/ path is still available in devices such as Samsung, but only with physical collections.
• /dbdata/databases/com.android.browser/app-databases/Databases.db Same as the previous entry, but this location can be found within some Samsung devices, particularly the Samsung Galaxy S series.
• /data/com.android.browser/app-geolocation/CachedGeoposition.db This SQLite database stores the app geolocation information if the user enables this feature when asked within the browser. This is typically seen within WebKit apps such as Yelp, Walmart, Google, and many others. This file will show the date and time, in milliseconds, when the location was requested. This has been deprecated in many Android devices. The path /data/com.android.browser.provider/ path is still available in devices such as Samsung, but only with physical collections.
• /dbdata/databases/com.android.browser/app-geolocation/CachedGeoposition.db Same as the previous entry, but this location can be found within some Samsung devices, particularly the Samsung Galaxy S series.
• /data/com.android.chrome/app_chrome/Default/ In many Android devices, the Chrome browser is installed by default. The main databases are located in this area and have been previously described:
• Cookies This SQLite database contains the Chrome cookies that give creation date, host, name, and last access in milliseconds.
• History This SQLite database contains the downloads, URLs, and visits of the user. The urls table contains the URL, number of visits, and last visited time.
• Login Data This SQLite database contains usernames, passwords/token, times used, and date created.
• Top Sites This SQLite database contains the URL and thumbnails of web sites. This thumbnail data can be converted to a JPEG and viewed, oftentimes obtaining user information of the visit.
• Web Data This SQLite database is often contained in many applications that can access web pages within their application. These databases can contain credit card numbers, keyword searches, autofill data, and server addresses. This file should not be overlooked in a forensic examination.
• /data/com.android.chrome/cache/Cache/ This location is full of web site page data containing IP routing, URLs, search strings, and more. This is the temporary Internet location that should not be overlooked.
• /data/com.android.email/databases/EmailProvider.db This SQLite database stores the built-in Android e-mail client data for the user. The primary tables are Message, Attachment, and EmailAddressCache. The secondary database located in this same folder is called EmailProviderBody.db, and it contains the actual content of the entire e-mail message JOINed using the messageKey in the body table. Of course, if a user uses another app for e-mail, these databases could hold limited information. This location is now /data/com.android.email/db/EmailProvider.db.
• /data/com.android.email/cache/ This folder can store many files that were embedded into the sent e-mails, including pictures, HTML banners, and much more. An examiner can find many artifacts in the cache area that have been deleted from e-mail or other file locations on the device. This appears to be deprecated in new Android devices.
• /data/com.android.mms/db/message_glance.db This database is of interest and is extracted in a regular ADB backup and contains tables events, logs, and priority_sender. The table event lists phone numbers as well as the date of the event. In the logs table the address, which can be a phone number or e-mail address, is available, as are the direction of the contact (incoming/outgoing), how many events were made, and whether an event was deleted. The priority_sender includes the phone numbers that are saved as favorites. The content of the messages is not available.
• /data/com.android.phone/databases/ This folder can contain several SQLite databases, including autoreject.db, callreminder.db, and rejectmessage.db, if the user has set them up to handle certain phone tasks. These databases will not be created unless the user has set them up. The database names identify the action and subsequent storage of that data. Autoreject stores numbers the user has identified to be rejected when receiving a call, callreminder will notify the user of a call, and rejectmessage enables the user to send a customized message on rejection of calls.
• /data/com.android.vending/databases/localappstate.db This database stores installed apps and the installation date along with the username associated with the app. The path has changed to /data/com.android.vending/db/.
• /data/com.android.vending/databases/suggestions.db This database stores search terms used by the device user when searching for Android apps to purchase. The path has changed to /data/com.android.vending/ and db or databases (depending on the device).
• /data/com.android.providers.download/databases/downloads.db Android devices have always controlled the information that is downloaded from the Internet independently of the app using class DownloadManager. Apps use this class when a file is downloaded to the device, and the information related to the download is stored within this database. This includes downloaded e-mail attachments, downloaded web content, and much more. If the file no longer exists on the mobile device, the metadata can possibly still be recovered from this database to indicate that it was, in fact, downloaded to the device. The path has changed to /data/com.android.providers.download/ and db or databases (depending on device).
• dbdata/databases/com.android.providers.download/downloads.db Same as the previous entry, but this location can be found within some Samsung devices, particularly the Samsung Galaxy S series.
• /data/com.android.providers.media/databases/external<variable>.db Android devices use another class called MediaStore, which caches all media on the internal device and external media. The media can include images, videos, audio, and even files. This database holds any data within the storage areas that does not contain a file named .nomedia. If the .nomedia file is encountered, the MediaScanner will not search that folder, and the information will not be cached in the external.db file. The <variable> listed in the path can be seen in some Android devices—it is the actual serial number of the SD card that was inserted. Some Android devices’ com.android.providers.media folder can contain multiple external.db files because multiple external SD cards were inserted, and subsequently the MediaScanner scanned and documented the data from each, storing the data in independent files. The external.db SQLite database contains many tables, but the most important is the files table, which contains all the files that have been scanned, including dates/times, paths, geolocation, size, and what app the file is associated with—to name a few. An examiner can gather critical information on the files within the Android mobile device with associated metadata. The path has changed to /data/com.android.providers.media/ and db or databases (depending on device).
• /data/com.android.providers.media/databases/internal.db The internal.db file stores media paths to Android built-in system needs. The information found in the internal.db is generally of no use to an examiner because the information is system-based, not user-based, data. The path has changed to /data/com.android.providers.media/ and db or databases (depending on device).
• /dbdata/databases/com.android.providers.media/ Same as the previous entry, but this location can be found within some Samsung devices, particularly the Samsung Galaxy S series.
• /data/com.android.providers.settings/databases/settings.db The settings.db file is used by the device to persist all of the user’s settings within a SQLite database. The tables of interest within the database are the system and secure tables. The system table identifies the setup of the mobile device, including the location of service prior to collection within the aw_daemin_service_key_city_name key and also whether the device was in hands-free mode using the driving_mode_on key. Both of these keys can provide critical information for an examiner, and the settings of the device at the time of collection can be found within this database.
• /dbdata/databases/com.android.providers.settings/settings.db Same as the previous entry, but this location can be found within some Samsung devices, particularly the Samsung Galaxy S series.
• /data/com.android.providers.telephony/optable.db This database is used to store the carriers on which the mobile device has operated and lists the carrier name and the public land mobile network (PLMN) identifier within the operator table.
• /data/com.android.providers.telephony/databases/telephony.db This database is used to store the carriers on which the mobile device has operated and lists the carrier name and the PLMN identifier within the operator table. This also lists the SIM or SIMs that have been used by the device in the siminfo table. This provides the carrier name for each SIM that had been used.
• /data/com.android.providers.telephony/databases/mmssms.db This database stores all the MMS and SMS messages. The MMS information is stored within the pdu table, and attachments and content can be associated with the parts table. SMS uses the sms table, and several other significant tables reside within this database, including words and words_content, which both store text-based data that can prove valuable for an examiner. The words table is used by the sms and pdu tables to store searchable, indexed data for a mobile device, and the words_content table is used by the pdu table to store indexed, searchable text-based data for a mobile device. Because the pdu table uses both the words and words_content table, some data can be duplicated, but it can be filtered by using the foreign key in both tables. If the MMS or SMS session does not use a delete function, the information that is within the words and words_content may remain and can be harvested by the examiner even if the original SMS or MMS is deleted. This database is no longer backed up in a regular ADB backup, but can be extracted with a logical extraction using an agent. However, with the logical extraction and agent, deleted records from the database or journal/WAL file will not be recovered.
• /data/com.android.providers.telephony/app-parts/ This folder contains the attached files to MMS messages and is referenced in the mmssms.db parts table.
• /dbdata/databases/com.android.providers.telephony/mmssms.db Same as the previous entry, but this location is within some Samsung family devices, particularly the Samsung Galaxy S series.
Google Stock Apps
Because Google is Android and Android is Google, it should be no surprise to any examiner that most Android devices are populated with stock apps from Google. The following outlines some of these applications and where an examiner may find additional artifacts while examining the Android file system:
• /data/com.google.android.apps.docs/databases/DocList.db This database contains the list of files for Google Drive (in table Entry143). In this database, the filename, modified date, owner account, and other details are documented. Also, the table DocumentContent143 is the listing of files that are local and on the device, which can be found using the filepath field. Within the path /data/com.google.android.apps.docs/ are additional folders such as files/fileinternal/<GUID> that holds the files referenced in the filepath field of the DocList.db.
• /data/com.google.android.apps.docs.editors<docs,sheets,slides>/databases/ This location will house the database depending on the path of docs, sheets, and slides, and will contain information on created documents in the Google Docs platform.
• /data/com.google.android.apps.maps/databases/gmm_myplaces.db This database contains saved places or Google Maps favorites. The information is stored within the sync_item table and lists the latitude and longitude, time stamp, and the sync_item as a BLOB file, which is the location name along with the HTTP data to maps.google.com.
• /data/com.google.android.apps.maps/databases/gmm_strorage.db This database is the storage location for the turn-by-turn instructions for each route entered in the Google Maps app. The information is stored in the gmm_storage_table in the data field. The data field is BLOB data, and, when viewed, it gives the examiner a view of the directions followed by the user to a destination—the location name along with the HTTP data to maps.google.com. Figure 15-10 shows BLOB data within the gmm_storage_table that can assist an examiner when using mapping data in a case.
FIGURE 15-10 BLOB data within the gmm_storage_table
• /data/com.google.android.apps.maps/databases/search_history.db This database records the searched locations within the Google Maps app, storing the latitude and longitude along with a time stamp. This data is in the suggestions table in the SQLite database.
• /data/com.google.android.apps.maps/app_da_speech/ This folder stores the voice WAV files for the directions given.
• /data/com.google.android.apps.maps/cache/http/ This folder stores cached data in the form of GUID named files. Generally two related files with the same GUID are differentiated by a 0 or 1; 0-ending files are the description of the associated file ending in 1. This can be helpful for an examiner, since some street-view JPGs are stored in this location when a user requests that view of a location.
• /data/com.google.android.apps.maps/shared_prefs/settings_preferences.xml This XML file contains values Google Maps is using. One key, current_account_name, lists the registered account name for Google Maps. This information can be used to obtain court-ordered information on geolocation data that’s not stored on the mobile device but might be stored on the user’s account.
• /data/com.google.android.apps.maps/databases/ue3.db This new database for Google Maps contains the table userevent3_table that contains the account information, the field ue3 that contains BLOB data with directional information, and a third field time stamp. This is much like the legacy gmm_storage_table database.
• /data/com.google.android.maps/databases/mytracks.db This new database for Google Maps contains all of the tracks, waypoints, and trackpoints. The trackpoints table contains date/time information, latitude and longitude, speed, and elevation. The waypoints contain the pin description, address, name, latitude and longitude, date/time of start and stop, and several other fields of interest.
• /data/com.google.android.apps.gm/databases/mailstore.<username>.db This Google app store is for Gmail. Each mailbox is prefixed by mailstore and then the Gmail e-mail address. The SQLite database contains several tables, including messages, attachments, and conversations. The messages table contains the date and time information for e-mail messages, the subject, and a snippet of the e-mail message. The conversation table is used to present the e-mail on the device visually to the user without showing all the content—allowing for better app performance. Since content is stored on the Gmail server and only a portion of the mail is available to an examiner in the file system, sometimes the only indication of mail, if not in the messages table, is cached in the conversation table. Also found on Android devices with built-in Gmail at /data/com.google.android.gm/databases/mailstore.<username>.db.
• /data/com.google.android.apps.gm/databases/suggestions.db This SQLite database is found throughout apps within an Android and represents what a user searched for within the app itself using the search bar. Also found on Android devices with built-in Gmail at /data/com.google.android.gm/databases/suggestions.db.
• /data/com.google.android.apps.gm/cache/ This folder contains several folders representing the various Gmail accounts within the /databases folder. In each folder are files cached from attachments and e-mail. Also, a webViewCacheChromium folder stores temporary cache data to support web data browsing and e-mail–embedded items using HTML pages. Also found on Android devices with built-in Gmail at /data/com.google.android.gm/cache.<username>. Also, within the cache folder, the webViewCacheChromium folder name has changed to org.chromium.android_webview.
• /data/com.google.android.apps.messaging/databases/bugle_db This SQLite file is the main Android messenger database and contains conversations, messages, participants, and parts, among other tables. Using the data from the messages table, parts table, and participants table, an examiner can easily uncover messages that a commercial tool does not support.
• /data/com.google.android.apps.plus/databases/es0.db This SQLite file is the main Google+ database and contains circles, all_photos, activities, activity_comments, and stories, among other tables. Also contained with the /databases folder is the iu.upload.db file, which lists files uploaded to the user’s Google+ account. Google+ is deprecated but data is still available here as well as databases within /data/com.google.android.gms/.
• /data/com.google.android.apps.plus/cache/media/ This folder contains subfolders referenced by both the es0.db and iu.upload.db files. Each folder has numerous media files. Using a data carver in this folder system will yield many media items an examiner may need in an investigation. Google+ is deprecated but data is still available as well as databases within /data/com.google.android.gms/.
• /data/com.google.android.apps.plus/shared_prefs/accounts.xml This XML file contains the account information for the Google+ account. Google+ is deprecated but data is still available as well as databases within /data/com.google.android.gms/.
• /data/com.google.android.gms/ Within this directory for the Google Play services are many databases relating to Google apps that are using the Google Play service function. Databases include android_pay, auto_complete_suggenstions.db, context_<Gmail account name>, fitness.db.<email of user>.com, google_account_history, plus.db, pluscontacts.db, reminders.db, and many others.
• /data/com.google.android.googlequicksearchbox/databases/icingcorpora.db This SQLite file is used to store indexed applications, contacts, e-mails, phone calls, and postal codes. Within the database, the tables to view are applications, contacts, e-mails, phones, and postal codes. These tables list values that are most prevalent for that type based upon the score field. The value ranges from 1 to n. The highest n-valued item in the score column for each type will show first when the user begins to type into the Google Search box within each category (such as contacts, call log, e-mail, application). The score is typically based upon frequency of use per each category. An examiner can use this intelligence to determine most frequently contacted and used data within the device.
• /data/com.google.android.googlequicksearchbox/cache/http/ Like all other HTTP folders within the cache, GUIDs are stored in this location. This folder stores cached data in the form of GUID named files. There are generally two related files with the same GUID differentiated by a 0 or 1; 0-ending files are the description of the associated file ending in number 1. This information can be helpful for an examiner because voice searches, Internet searches, and typed searches using the Google Quick Search box are stored along with the data that was returned to the user (see Figure 15-11). The search, stored in the GUID with an appended 0, contains date and time information for both the search and return of data along with the content type description. Additionally, a folder under /cache/ could also be cronet. Cronet is a network library and will, like the http folder, hold valuable cached user information.
FIGURE 15-11 The file in the search describes what was searched for with the associated result displayed.
• /dbdata/databases/com.google.android.googlequicksearchbox/qsb-history.db This SQLite file is found in some Samsung Galaxy S series devices and contains the history of the searches used in the Google Quick Search box. This database has been deprecated, but the table history contains the query used and the date and time. Another database in the same directory, qsb-log.db, can be used to log web clicks used in a search. This information is obtainable within the clicklog table.
• /data/com.google.android.gsf/databases/subscriberfeeds.db This app is the Google Services Framework, and this SQLite database contains the Google accounts that are subscribed to, along with the user’s e-mail address.
• /data/com.google.android.gsf/databases/talk.db This SQLite database contains the Google Talk settings such as account and contacts within the app. Google Talk is deprecated and is now Google Hangouts (see com.google.android.talk).
• /data/com.google.android.street/cache/ This folder contains streetview images from a Google Maps instance. The images are all prefixed by tile_ and then ordered by a three-digit number. The examiner can use these tiles to obtain images that the user of the device accessed while using the streeview function in Google Maps.
• /data/com.google.android.talk/databases/message_store.db This SQLite database contains the Google Hangouts messages within the messages table.
• /data/com.google.android.talk/databases/babel.db This SQLite database is the conversation database for active conversations, participant names, messages, and information about the Google Hangout event. There can be multiple babel.db databases, and each database name will be followed by an integer starting with 0 (such as babel0.db, babel1.db, babel3.db).
• /data/com.google.android.talk/shared_prefs/accounts.xml This Google Hangout XML file lists key information to the Hangout owner and preferences for the account.
• /data/com.google.android.talk/shared_prefs/phone_verification.xml This Google Hangout XML file lists the phone number associated with the account.
• /data/com.google.android.youtube/databases/history.db This SQLite database is used by the Google YouTube app to store searches for videos along with the date and time of each search.
• /data/com.google.android.youtube/shared_prefs/youtube.xml This XML file identifies the account of the YouTube user along with a history of downloads, last login, and other significant information of value to an examiner.
Samsung Android Artifacts
With Samsung continuing to be the leader in the global smart device market, as reported by the IDC (www.idc.com/prodserv/smartphone-market-share.jsp), an examiner should be familiar with the file system artifacts that are specific to these Android devices. Following are app locations within the /data folder that an examiner will see only within the Samsung device. Although the many preinstalled applications may annoy some customers, many of these apps are used by many people.
• /data/com.samsung.android.providers.context/databases/ContextDB.db This SQLite database can help an examiner determine whether an application was running or had been launched around the time of an incident. The app’s internal services are exposed, showing the service that was launched as part of the app, to identify messages, notifications, and conversations. By using the app_usage table and fields package_name, class_name, and app_usage_last_access_time (in milliseconds), an examiner can gain interesting intelligence for a time line. A similar location for the device can also be found at /system/dmappmgr.db and the ApplicationControl table. In Figure 15-12, a parsed ContextDB.db file using the SQLQuery Builder application shows a considerable amount of information that can quickly be placed into a time line.
FIGURE 15-12 A parsed ContextDB.db file using the SQLQuery Builder application
• /data/com.samsung.android.app.galaxyfinder/SFinderHistory.db This database is filled with searches across the Samsung device when the user uses the built-in Samsung Finder app from the settings. This file can be a gold mine, especially because the date added is a part of the database table history.
• /data/com.samsung.clipboardsaveservice/f/ This folder stores saved clips from the clipboard (screenshots).
• /data/com.sec.android.app.clockpackage/worldclock.db This SQLite database contains all of the set clocks the user has added to the clock app. The examiner can use the worldclock table within this database to view any city that has been added to the wordclock view. New path and database name: /data/com.sec.android.app.clockpackage/db/worldclock.
• /data/com.sec.android.app.clockpackage/alarm.db This SQLite database contains all of the set alarms the user has added to the clock app. This table alarm contains the dates and times of alarm creation, the alert times, and the names of the alarms. New path and database name: /data/com.sec.android.app.clockpackage/db/.
• /data/com.sec.android.im/databases/taConvDB.db This SQLite database contains conversations and messages tables that can be used to recover the user’s instant messages, as long as the user is using the Samsung instant messaging platform.
• /data/com.sec.android.app.launcher/db/launcher.db This SQLite database contains installed applications, and even applications that have been deleted in the appOrder table. Within the favorites table the application name and also icons are stored.
• /data/com.sec.android.app.sbrowser/db/ This folder contains several databases rich with information. The SBrowser.db contains the BOOKMARKS table, which displays the URL of visited pages. The pintab.db contains the set bookmarks; typically, these are defaults added by Samsung. The weblogin.db contains the username and web site information that belongs to the user within the fpauth table.
• /data/com.sec.android.app.sbrowser/db/r/app_sbrowser/Default/databases/Databases.db This file is the directory listing for WebKit data. Also in the Default directory is the folder Local Storage, which contains the .localstorage database files from web sites visited.
• /data/com.sec.android.provider.logsprovider/databases/logs.db This SQLite database is a gold mine of information. This file stores information that has been displayed on the Samsung device, such as notifications from e-mail, MMS, SMS, and calls. To detail the contents, the database file stores call logs, message snippets (SMS/MMS), and e-mail snippets along with their associated metadata. If a message has been deleted from the main SMS, call log, message, or e-mail, the data remains within this log. Experience has shown that even if the user has reset the messages within the device, data can still be recovered from logs.db. Table 15-6 lists some of the information available from this telltale Samsung database with logtype and type coming from the logs table in logs.db.
TABLE 15-6 Logs.db from the Samsung Logging Function and Database Located at com.sec.android.provider.logsprovider
• /data/com.sec.android.provider.smemo/databases/pen_memo.db This SQLite database stores data from the Memo app, including voice, pictures, and text. The information is located in the table PenMemo within several fields, including CreateDate, Date, Content, Text, Text_sub, Drawing, and Thumb.
• /data/com.sec.android.provider.downloads/databases/sisodownloads.db This SQLite database is comparable to the com.android.providers.downloads database. This is a good database for an examiner to investigate because media downloaded from web sites can be located here.
• /data/com.sec.android.socialhub/databases/UniboxProvider.db This SQLite database contains accounts and messages tables that can be used to match accounts for social media, instant messaging, text messaging, and e-mail notifications with the messages themselves. If the user has enabled this feature, this database can contain current and historical data.
• /data/com.seven.Z7/databases/email.db This SQLite database contains more data from the social hub addition to the Samsung line. It can store e-mail addresses, passwords, and e-mail content. Also, associated accounts and their instant message data can be stored here.
Third-Party Apps
Unlike iOS devices, third-party applications are stored in the same /data folder along with all of the other stock, phone, and often carrier apps. The third-party apps use the domain name format previously outlined.
There are more than 1.5 million Android apps available on the Google Play site, and documenting each and every app naming convention would take hundreds of pages. An examiner should understand that the layout of the folders within each app and the databases used to store the artifacts will be generally similar to what is outlined in Table 15-5. App designers can build their own app folder structures, and one of the difficult things for the automatic parsing of the apps within an Android, or any smart device, is that folder structure and database naming can change with an app update.
Third-party apps generally store the temporary data within the /cache folder, which can also include additional folders, such as webViewCacheChromium, which is now org.chromium.android_webview or cronet_cache on current devices (cronet is the chromium network stack). This folder contains data that was displayed to the user using the app. Files of interest will be prefixed with an f_ and then a number. The f stands for files, and the files used by the web view in the app are listed. This naming convention is not observed in newer Androids, with files being stored in another directory under /cache typically named files or media. The /databases folder contains the databases for the app, along with another database called webview.db that stores form information and user information to be used within a web view in the app. This database can hold passwords, usernames, and other data important to an examiner. It should be noted that the webview.db has become Web Data and stored in the app_webview folder under the root of the app folder. Although Android development clearly encourages developers to use the correct controls of this class, WebViewDatabase, this database still should be queried. Apps also use the shared_prefs folder within the app structure, which contains XML files that outline the preferences for the app, including usernames and passwords. Because some apps do not store data on the mobile device for security concerns, the app simply uses a built-in browser to interface with a secure server, but often automated login information is located within the shared_prefs folder. This location should also be examined when conducting an examination of third-party apps.
Most Android apps use SQLite databases, and as outlined in Chapter 14, building a SQL query to support an application, along with recovering free pages and WAL data, should be conducted on any app important to the examination. Even in today’s most popular games, users can chat with one another, often adding to an examiner’s investigation, as shown in Figure 15-13.
FIGURE 15-13 Here, /data/com.zynga.words/WordsFramework is queried for its internal messaging with more than 100 messages returned.
File Interrogation
Every file mentioned in this chapter and any other file within the Android file system can be parsed to recover every bit of data within the particular file. The attack surface within the Android is limitless for an examiner with the right tools and, more importantly, the drive to succeed. The SQLite database queries along with Python scripting can enable an examiner to interrogate most of the files within the Android file system. With the primary files for storage being SQLite databases and the primary file type for settings and preferences being XML, the examiner already has a leg up, since the parsing of both of these file types was covered previously.
Android non-invasive or invasive physical recovery of the partitions also enables the examiner to carve the unallocated space on both the cache and userdata partitions. The unallocated space within the Android device can hold media files, SQLite databases, XML, HTML, deleted MMS media, and other settings that are no longer active within the file system. Using a forensic tool to carve the unallocated space for these particular file types should be attempted by the examiner prior to the conclusion of the examination. Hundreds and possibly thousands of additional files can be recovered. In Figure 15-14, hundreds of images deleted from MMS along with HTML files were recovered using data carving techniques with Oxygen Forensic Detective.
FIGURE 15-14 Many forensic tools support the data carving functionality.
SQLite, XML files, and any other files within the file system of an Android should be examined. Some examples of parsing of files using Python parsing are covered next, with files that have been recovered from an Android device. The creation of SQL queries for Android databases was covered in Chapter 14.
Scripts
Often an examiner will need to locate the operating system information from an Android device. This information is often difficult to find within the different files of the file system. If the examiner’s mobile forensic tool does not recover this information automatically, the examiner can create a simple script to run against the file located in the userdata partition at /log/recovery_log.txt to search and list only the operating system information:
An abbreviated output from running the script against recovery_log.txt displays the required operating system information:
Because an Android device holds many XML files, running a script to parse these XML files to make them more readable is often a necessity. This script will output the XML into a form that can be easily read within an examiner’s report:
The output of this script for a common Android file for the built-in browser indicates last search times and the web search engine located at /data/com.google.android.googlequicksearchbox/SearchSettings.xml. The script could be further refined to translate the date and time information as well:
Applying scripting to an Android examination, along with building SQL queries, can have an enormous impact on the outcome of an investigation. By using these types of techniques, an examiner will be sure to uncover the maximum amount of data from these treasure troves.
Android App Files and Malware
Android apps are created and installed to a device in the form of an APK file. APK files are compressed binary files containing DEX files, resource files (.arsc), uncompiled resources, and the AndroidManifest.xml file. These files and folders make up the app much like a Windows MSI or Mac .dmg file. The APK is installed to the device and stored in the /app folder within the Android file system for non-system apps; system apps are stored in the system partition. If an app is installed to the sdcard partition, the contents are generally encrypted and stored in a /sdcard/.android secure directory. The filenames have an asec extension instead of apk. If the device has decrypted these apps from the SD card, they will be stored at /data/app-asec and can be examined. The /dalvik-cache folder stores the installed app code for execution within the Dalvik VM instance when the app is called to run.
The important aspect of these two areas for an examiner concerns malware. Malware on an Android device is far more likely to occur than on any other smart device on the planet. Kaspersky Labs reports that more than 97 percent of mobile malware they detected was from the Android platform. There are various reasons for the malware infiltration on the mobile device, but it typically comes down to monetary gain for the group infecting devices. From SMS for a service to ransomware, an Android device can be susceptible. An examiner must be prepared for malware being involved on an Android device and understand the consequences.
Computer forensic examiners are trained to scan computer digital repositories for known malicious applications, viruses, keyloggers, and other similar files to disprove or prove malware added to, deleted from, or modified the data being examined. Mobile device examiners do not show this same diligence, however, which could possibly discredit any data that might be recovered from an Android device. Android malware is already outpacing Windows for malware infections, and what took Windows 14 years to achieve with infections, Android has overtaken in only 3. An examiner should be ready to complete an examination of malware on a mobile device, particularly an Android device.
Cellebrite offers a malware scanner within its mobile forensic software that uses Bitdefender to locate malware signatures. An examiner should realize, however, that a signature-based examination is the lowest form of malware analysis, because a signature is based upon a known hash. This known hash is placed into a blacklist and uploaded to a signature repository to be used against the app. Because an app can change daily after being morphed into an illegitimate form of a legitimate app, or because a zero-day app can drop at any moment, using signature-based analysis could miss valid malware. (This is not to say that the examiner should not perform an analysis of an Android device with a signature-based tool. Anything is better than nothing, and as long as the signatures are current, the analysis would be comparable to a computer’s virus/malware scanner.) Malware companies base the signatures upon the DEX file within the /davlik-cache folder. However, there are instances where malware has injected or patched a legitimate app’s DEX file within the davlik-cache, thus evading malware signature-based analysis.
Malware installed on an Android device can cause problems for an examiner, most importantly during the court testimony stage. Malware software can be used to gather information, disrupt service, connect to premium services, and even enable remote access to a device. Malware to disrupt can cause the device to be inoperable, cause redirects to web sites, install ransomware, and result in other problems. The following list shows several types of malware and how they work:
• Ransomware After locking the device, the user is shown a screen indicating that illegal material has been found on the device by the authorities and it will not be unlocked until a fine has been paid.
• Premium services These apps redirect phone and messaging services to a pay-per-use service to add phone charges. They collect money for every message sent and charge it to the carrier and then to the user’s account.
• Spyware Spyware can turn on and monitor microphones, cameras, messages, keystrokes, and other data from a mobile device. This type of malware is often sold as a legitimate “monitoring” app. The information gathered is sent from the device to a server under control of the criminal.
• Trojan This was the most prevalent type of malware at one time, with designers injecting malicious code into legitimate apps. Google Play at the time failed to identify this malware, and many unsuspecting users downloaded what they thought was the original app. For example, Svpeng, a Russian Trojan, affected Androids by asking for credit card information each time the user visited Google Play. The data was then sent directly to a server, and credit card details were sold. The Google Play store now uses “Bouncer” to scan the app for malicious code or changes—eliminating some of the risk.
• Data miner This app steals data from the device, including contacts and phone information. Often, the malware will steal contacts and extort money from the user—saying an image they have will be sent to all of the user’s contacts. Also, phone details such as IMEIs are stolen to sell to others to clone onto blacklisted handsets.
• Adware Messages from apps that should not be advising the user that “Your phone is slow,” “You have been infected,” or “Your device is being tracked,” is a sign of adware, a prevalent malware type.
• Downloader This app directs users to additional downloads that appear to be content—such as PDF, JPG, and so on—but are additional malware apps, often Trojans.
• Browser hijacker These apps use WebView and not the Android internal browser to redirect and incur browser drive-by hacks, often infecting the device without the user even doing anything on the web page.
• Botnet Like computer systems, mobile devices are subject to malware packages that turn the device into a zombie. The command and control (C&C) servers are connected, and the device becomes a part of a network of devices that often distribute more malware.
Malware actions might include modifying the permissions for an Internet game to read the contacts, SMS, or other phone details to transmit that data to another server, or using the details to send messages and even clone the serial number to another device.
Analysis Levels
Three levels of malware analyses—permissions, static, and dynamic—are used to root out malware and determine the legitimacy of the app and its intentions. Permissions is the first level of malware detection and analysis. Static analysis is the second level of malware detection, and dynamic analysis is the third and top-level analysis type.
Permissions Analysis
Android apps list permissions (Figure 15-15) that must be granted to the app to enable it to function as the developer intended. The user typically sees these permissions prior to installing the APK file on the device, and they can also be viewed by navigating to app settings. On devices running Android 6 and later, the app will not ask for permission on install. The app must ask the user to grant permissions at runtime. The user can accept or deny each permission one at a time if needed. Permissions for all APK files can also be viewed on the Google Play Store. The permissions granted to an Android app can assist the examiner as to the app’s intentions. Table 15-7 lists Android permissions and their descriptions, including ways in which malware can affect the permission. Permissions are separated into NORMAL, SIGNATURE, and DANGEROUS. Outlined in the table are those that could be dangerous and should be investigated.
TABLE 15-7 Android Dangerous Permissions and Descriptions (https://developer.android.com/guide/topics/permissions/overview)
FIGURE 15-15 App permissions
Permissions for all apps on a device can also be examined within the /system/packages.list if this file can be accessed.
An app cannot access parts of the mobile device or provider apps if permission has not been granted. Most Android users do not understand the implications of accepting all permissions requested by the app and choose to accept all—granting dangerous access to malicious apps. Obviously this is a security concern for the user, but how about the examiner? As an examiner, these permissions should be investigated on apps that are primary evidence within the investigation. An examiner should unequivocally explain the intentions of that app, the expected outcome of using the app, and the evidence it produced. This perceptive investigation of the app’s behavior will solidify the stance of the investigation and evidence recovered.
Static Analysis
Static analysis is a more in-depth analysis of any app that the examiner believes to be malware, based upon a permission or signature alert. A static analysis enables an examiner to look into the app code in a controlled environment—to look for “hooks” that might indicate malware, identify calls or posts to a third-party server, or recognize other anomalies within the app. Several tools are available to assist an examiner in the static analysis of Android apps; this type of examination is not automated and can be time consuming, but it is often a necessity.
In 2012, as part of course development for a malware analysis course, I created content and a virtual machine to enable students and attendees to analyze actual malware, both statically and dynamically. This method is still viable and utilized. The virtual machine was created using Linux Ubuntu as the OS with Eclipse, Wireshark, Androguard, and APKInspector installed. Eclipse was used for live active analysis using logcat and threading; APKInspector was used for the disassembly and analysis of the APK and DEX code; Androguard was used for disassembly of APK, ODEX, and DEX files; and Wireshark was used for active communication protocols. The benefit of using these tools was easy: they all are open source and freeware, and they allow for the investigation of malware within a virtual sandbox—the Ubuntu VM. The course introduction was given to a group at a High Tech Crime Investigators Association conference, which spawned several other virtual appliances for this type of analysis, using the same setup and tools.
For static analysis, an examiner can use APKInspector, an appliance built with Python, to look for values that would be typical for a malicious app, but some of these permissions can be found in legitimate apps, too. The total number of hooks the examiner uncovers will determine the threat score of the identified app. Table 15-8 represents some of the more common requests found in malicious apps. Using APKInspector, the examiner can search for these terms to determine whether the app is using processes and commands that should not be a part of the app’s functioning.
TABLE 15-8 Common Commands Observed Within the Codebase of Malicious Applications
Before the examiner launches APKInspector, Python must be installed within the Linux instance. Then, from the Ubuntu Linux terminal, the examiner types python StartQT.py from within the APKInspector directory. The APKInspector UI will open, where the examiner can select to open an APK file by clicking the open folder (blue folder with a plus sign). Using the interface SideView in conjunction with the MainView (Figure 15-16), an examiner can view permissions, code, and calls made in and out, along with the DEX-translated code information. The examiner can view the actual code to determine exactly how the app is functioning, any classes used, and any malicious code calls if they have been identified. Sometimes the examiner can find information that can be used to track the malware developer when comments (// This is a comment) are included within the code. APKInspector is not an automated tool, but it can help an examiner conduct a thorough static analysis of Android apps in an attempt to identify known malware hooks. However, a dynamic analysis must also be run to understand the malware and any malicious intent completely.
FIGURE 15-16 APKInspector can be a good static analysis tool that shows permissions, calls, and even code.
Dynamic Analysis
Dynamic analysis of an Android app can also be accomplished within a Linux Ubuntu virtual machine using an Android emulator and Wireshark, plus an emulator instance with Eclipse. Conducting a dynamic analysis of an Android app enables the examiner to monitor the app as it is running within the Android emulator, to watch the way the app works and monitor the output and input when the app is running certain processes.
Using Eclipse, the examiner can select the app within the interface and monitor the threads, as well as use logcat to monitor the device and app functions. Eclipse can also be used to monitor and debug the app APK while running in the instance of Eclipse, if needed. This can help an examiner monitor the suspected APK on an emulated device and debug/monitor the APK files as well. This information can show HTTP attempts and system communications. Eclipse can also be used to monitor an emulator that contains malicious APK files (Figure 15-17). Using threads along with logcat, the examiner can view occurring changes in the system in real time. A malicious browser can redirect the IMEI and phone number to a URL.
FIGURE 15-17 Monitoring malicious files in Eclipse
Before the examiner launches Eclipse, an instance of the Android emulator with the suspected Android malware must be running. An instance can be started from the Ubuntu VM from the terminal by typing emulator <Android Virtual Device (AVD)> or from the Eclipse instance, as long as the Android ADT plug-in has been installed. If Eclipse and ADT are used, the emulator can be launched from the toolbar. Once launched, the emulated device will be visible within the Eclipse instance. The examiner can launch the suspected malware app on the emulated device and within Eclipse select the logcat tab. This will show the communication with the device, the app, and any other system communication. The examiner can view any outside requests, calls, and network attempts and save this information to a text file to be included in a report if needed.
Be sure to set the Windows | Preferences | Android | LogCat | Maximum Number Of LogCat Messages In Buffer to 0 to capture an unlimited number of lines, and then restart Eclipse. If this is not set, the default is only 5000 lines.
Data from Wireshark can also be analyzed to determine whether any data was sent or received from an outside source using TCP. If information is transferred or received, the examiner can determine whether this data is reasonable and whether the data is being transmitted or received from the correct server for the app or is going to a third-party location not specified by the app documentation. If the latter is the case, the examiner should analyze exposure to the device along with any received information from the third-party server. This analysis can often refute allegations that an app downloaded material automatically, without the user’s knowledge, or that the app installed another unknown app that caused the evidence to appear on the device. This analysis can also help to determine a security breach and what type of data was lost.
Conducting a dynamic analysis using Wireshark is a good alternative. This is a basic introduction to its use; other resources are dedicated to using Wireshark with advanced methods that are not covered in this section. An examiner should at least comprehend that there are methods for the dynamic analysis of Android apps using Wireshark.
Before the examiner uses Wireshark, he or she should create a TCP dump file when launching an emulator instance. This dump file will contain the recorded network traffic between the emulated device and the outside network. While running a suspected app, the examiner can observe any anomalies with the app and its communication with the network. These anomalies can include sending data, receiving data, and connecting to unknown IP addresses and servers. The examiner can run the following command from the terminal within the Linux virtual machine to start an instance of Wireshark’s TCP recording on an instance of the Android emulator:
The app or apps can then be launched and the information can be examined to determine whether TCP/HTTP traffic has malicious intent. A capture file is then created, and this file will be imported into Wireshark and analyzed for any TCP or HTTP traffic.
Using advanced tools to combat the allegations of malware within an Android examination can be complicated, as shown in Figure 15-18, but an examiner must be prepared to conduct this type of analysis should these allegations be raised.
FIGURE 15-18 Advanced tools can produce complicated results.
Commercial tools from AppSec Labs and NowSecure also use a Linux Ubuntu VM and include various tools, many of which have been discussed in this section. AppSec Labs’ AppUse VM includes a dashboard that directs the examiner to certain functions within the VM and is used primarily for penetration testing, but it can also be used to analyze malware from mobile devices.
Chapter Summary
By obtaining the file system from an Android device using ADB backup, non-invasive, or invasive physical partition recovery techniques, an examiner can uncover artifacts that could prove critical to any investigation. If partition information cannot be recovered, the examiner still has an opportunity to recover data from the device’s internal or external media areas using MTP. App data, file settings, and persistent user data can be recovered from this area as well. Not all is lost if the partition-level file system data is not available; many users, and app developers, store data to the media area of the device, so as long as the device is unlocked or the examiner can access the device by circumventing the security, data can still be recovered.
Automating the recovery of Android artifacts is a difficult proposition for any software development team. Staying ahead of the ever-changing app and mobile device technology wave can be extremely difficult. When an examiner uses techniques discussed in this chapter and the two previous chapters in conjunction with the mobile forensic automated solution, a mind-boggling amount of data will be recovered. By using the scripting and query principles, even on databases and files already parsed by an automated tool, the examiner can be sure that recovered data is valid and properly recovered. The search for artifacts within an Android device should extend far below the surface of the “iceberg” to uncover the many files discussed in this chapter—from user settings to application data, this critical information is at the examiner’s fingertips.
In addition, “tip of the iceberg data,” such as SMS, MMS, call logs, and contacts, can be examined to uncover additional information that the automated tool neglected to report using a standard logical collection. By examining the SQLite databases, an examiner can look into the free pages, write-ahead logs, and the databases themselves to bring missing data to the surface.
Malware is a problem with mobile device forensics, and the examiner, as part of normal procedures, should be sure to scan and report any anomalies. This procedure comes from many years of court proceedings and reports that malware, Trojans, or viruses can install applications, download inappropriate images and videos, and modify the system somehow without the user’s knowledge. With a mobile device’s ability to extend itself into the Internet and network, along with the massive onslaught of Android malware, this type of issue is important to a court procedure. An examiner must take steps to scan the device’s contents when possible to cover this critical examination gap within the current Android investigations.