8 Mobile Forensic Tool Overview

Selecting a mobile forensic solution can be an extremely difficult task. Trying to understand the capabilities of each tool can be confusing and at times cryptic. Although lots of mobile forensic software vendors list the vast number of devices that their products can support, you must remember that even if a product supports 18,000 devices, if it will not help with the single device that you need to collect, or the device is supported but does not extract the data that could be critical to the case, it’s not the right tool for you. Vendors in the mobile forensic marketplace use the term “profiles” to describe their support and generally describe support for a “type” of device, loosely based on model. This enables the vendor to claim support for a subsection of the model or profile, even though not all of the device carrier’s versions may be supported.

Quite honestly, the numbers game used by most mainstream vendors is just that—a game. The examiner should be aware of these types of nuances when selecting a solution that claims to support a specific model of device that will be examined. Most vendors post information online, where the examiner can go to determine whether a device is supported. But what does it really mean when a vendor says the software handles the “logical and physical collection” from an iPhone 7 running Apple iOS 11? Such information is often misleading, especially because logical and physical collections might mean one thing to one examiner or vendor and mean something entirely different to another.

In this chapter, several mobile device solutions are identified and the types of examinations are discussed—but in a more granular way that departs from the traditional nuances of logical and physical collections. Open source, freeware, and commercial tools all have benefits and limitations. Each piece of software covered here comes from my personal experiences as well as community experiences, but as with everything, one person’s experience can differ from another’s. Consideration of the level and type of examination required should be one of the deciding factors in the type of mobile device tools you choose to use for the collection and subsequent examination of recovered data. In some cases, the tool you use to collect a mobile device can be entirely different from the tool you use to complete the analysis of the data.

Just as confusing is the tool progression—the decision to move into another category of examination for a particular device or situation. Not all devices are supported with a simple connection via USB cable, and some are not supported by any traditional methods. Some devices must be examined after the removal of the memory chip, while others can be examined with a physical connection directly to the mobile device printed circuit board (PCB).

Mobile device forensics in today’s world does not involve simply attaching a cable, clicking a Go button, and waiting for completion. To conduct a thorough mobile device examination when it counts is to comprehend the tool progression continuum, the risks involved, the training needed, and the tools available.

Collection Types

There is no more confusing discussion in mobile forensics than either listening to or speaking about a logical and a physical collection of a mobile device. This is one of the most danced around issues in mobile device forensics. What constitutes a logical collection and what constitutes a physical collection? If a file system was recovered and happens to contain files and folders, is that a logical collection? If the file system contains unallocated space, does it constitute a physical collection? To be honest, there is no clear definition for the difference between logical and physical with regard to mobile device collections, and there are too many variables involved. The following section discusses both terms, some historical data, and what today’s working practitioner believes to be the definition.

Logical Collection

As defined in the 2007 publication, NIST SP 800-101, “Guidelines on Cell Phone Forensics,” a logical acquisition implies a bit-by-bit copy of logical storage objects (such as directories and files) that reside on a logical store (such as a file system partition). In 2013, the Scientific Working Group on Digital Evidence (SWGDE) published the document “SWGDE Best Practices for Mobile Phone Forensics,” which removed the bit-by-bit classification proposed by NIST and classified a logical collection in a different way. SWGDE stated that a logical acquisition implies a copy of logical storage of objects (such as directories and files) that reside on a logical store (such as a file system partition). In the 2013 publication “SWGDE Core Competencies for Mobile Phone Forensics,” a logical examination is described as a process that provides access to the user-accessible files. Moreover, SWGDE indicated that the logical analysis process will “not generally provide access to deleted data.” In a 2014 revision (currently being updated), NIST SP 800-101R, “Guidelines on Mobile Device Forensics,” described a logical acquisition as capturing a copy of logical storage objects (such as directories and files) that reside on a logical store (such as a file system partition).

The definition is getting closer between both groups, most likely because of the personnel who are now contributing both to the NIST and the SWGDE documentation.

Confusing, isn’t it? There appears to be a common theme of files and directories from a mobile device, and honestly, the definitions have become better in describing the data available, but to a layperson reading this information and ultimately applying it to his or her job, it is cloudy at best, and almost mystical. The mysticism comes in the form of one of the terms used in SWEGDE’s logical definition: “generally.” It is because of this “generality” that the word “logical” has lost some credibility. The problem arises because, within a subset of devices such as iOS and Android devices, a logical file extraction can often contain deleted data. Simply stating that a logical examination is capturing the logical storage objects (such as directories and files) from the file system of a mobile device is too general and, quite honestly, in some situations inaccurate. The terms “logical” and “physical” acquisition are throwbacks to computer forensics parlance, and they are more often than not misinterpreted when it comes to mobile device forensics. Data that is not accessible to the user, such as system files, application stores, and deleted data, can often be collected from a device in a currently defined logical extraction. This would contradict some of the definitions mentioned.

A logical collection on its face should be interpreted as the extraction of user data from a mobile device without the collection of a device’s file system. This data is extracted from the mobile device using proprietary protocols and queries and displayed in the software user interface. An example of a logical collection as just defined would be using a software tool on an Android device with an Android application package (APK) file. Most forensic software applications use this method when conducting their version of a logical extraction. The APK queries the Android device’s internal databases and returns the data to the software interface. The data is then displayed in the software’s user interface. This method does not return a file system, but the data that is represented by the contents of the files on the device. This distinction is important, because the currently accepted definition makes an assumption that all logical collections and recovered data from a mobile device by software are similar, so long as the device is supported logically. Because of this often-used generality in describing a logical collection of a mobile device with a particular solution, a subcategory of a logical extraction should be discussed—a file system collection. A file system collection bridges the gap between what the mobile forensic community believes to be a logical extraction and a physical collection.

File System Collection

A file system collection contains much more information than the defined logical collection and should be considered a step up from a logical collection. A file system contains the files and folders that the device uses to populate applications, system configurations, and user configurations along with user storage areas. The following sections define and explore different types of file system collections.

MSC, MTP, and PTP   Mobile devices such as iOS, BlackBerry, Android, and Windows Phones can have “points of storage,” which could mean that the mobile device file system collection must occur in multiple places. A user storage area can be the location where images, videos, and audio are stored and accessible by the user via a computer and a cable. Another user storage area can be an internal storage point that also stores application data, system log files, and documents.

Mobile devices have long enabled users to transfer data to a PC using “USB Mode,” or the USB Mass Storage Class (MSC). Legacy feature phones and devices, when removable media was added as a supported feature, would allow the user to move media from the device to a PC much like transferring data from a flash drive to a computer. In 2008, the Media Transfer Protocol (MTP) mode, originally part of the Microsoft Framework, became a standard by the USB Implementers Forum (USB-IF) as a USB type. This mode is recognizable when a device is plugged into a PC and is automatically mounted as a device, rather than a drive. This access occurs via MTP, a subset of Picture Transfer Protocol (PTP), which adds some enhancements and enables communication between the mobile device and the PC to copy, move, replace, and delete files from and to the mobile device. The move away from MSC to MTP was made in most modern mobile devices because if the device was in MSC mode, it could not store or communicate with the default storage point, making the device useless during an MSC connection. The device could not access applications, take pictures, or otherwise operate, so MTP mode was implemented, which enables the device to function even when tethered to a PC. Furthermore, the use of MSC exposed an entire partition to the computer system that would have to be properly formatted as FAT to mount and retrieve files. With the use of MTP, files can be retrieved at the file level. In the instance of Android devices using MTP, the device is able to move, store, and add a file without mounting a partition. Essentially, the device just acts as a file server to the client, and when files are requested, they are available no matter what underlying OS formatting is in use.

The “media” in MTP should not be confused with traditional media such as images, videos, and audio. In the MTP specifications outlined in Media Transfer Protocol v.1.1, the term “media” in Media Transfer Protocol is used to identify any binary data and is not restricted to the audio/video formats to which it is commonly applied. This clearly indicates that any file that is stored can be recovered using MTP. Mobile devices running the Android system, Windows, BlackBerry, iOS, and feature phones of today allow for access to a logical file system via MTP and PTP.

The difference between the operating system, at a basic level, regards the extent to which files can be accesses and what types of files can be accessed in this manner. Apple iOS devices will allow access to the media (pictures and videos only) area via a file explorer, such as Windows Explorer and the Finder, using PTP. With an Android device, first by default in Honeycomb 3.0 and a standard in Ice Cream Sandwich 4.0 and later, the device can provide access to the internal storage area of the device, an external media card, or both, using MTP. The accessible data includes application files, user documents, and media and system files. A Windows Phone, like the Android, allows for the transfer of files from both the internal and external card (if available) using MTP. Windows Phone data from both locations can contain documents, images, audio, and video. BlackBerry devices starting at version 5.0 allow for MTP as well as MSC. If the BlackBerry is set as a portable device, access to the internal and external card storage areas is available. These storage areas can support multiple file types such as documents, audio, video, images, and system files. Access and recovery of these files should not be overlooked in the examination of a mobile device.

Table 8-1 shows the types of data available on basic mobile devices using MTP and PTP.

TABLE 8-1 Mobile Device OSs and Data Accessible Using PTP and MTP

Figures 8-1, 8-2, and 8-3 show the various device types and how they are depicted within the desktop operating system.

FIGURE 8-1 File system view of an iOS device connected as a PTP device—DCIM (Digital Camera Image) folder is available

FIGURE 8-2 File system view of an Android device connected as a MTP device—notice the internal and external file systems containing various files and folders

FIGURE 8-3 File system view of a Windows Phone connected as an MTP device

The files can be copied manually to an evidence location when the device is connected to the examination computer. Although this is not generally recommended, it is advisable if the forensic software does not support the collection of these files. To make these accessible to the computer, the device must be unlocked.

Internal System Collection and Display   Some mobile device systems can also be accessed from a protocol level to display a represented file system. Feature phones using propriety file systems can have their file systems collected and displayed to show system files, user databases, media, user files, logs, user settings, and more, as shown in Figure 8-4. These files are not directly accessible to the user via the device interface, and inside of these file systems are artifacts that would not have been available without the use of specialized tools. These files are the actual containers queried and parsed by the logical software and displayed in the software interface. By having the actual file, you can conduct a more detailed analysis, which should be considered much more valuable than what “logical” defines. Similarly, mobile devices, such as Apple iOS, Android, and BlackBerry devices, also can have their underlying file systems collected to reveal application data, media, user files, system files, logs, user settings, and device settings.

FIGURE 8-4 In a CDMA file system, many files and folders can contain additional evidence.

All three of the file system examples involve collections that can be lumped into the “logical collection” bucket definition. Because this level of collection is not available to all software solutions that identify logical support for the device, it makes sense to identify a secondary category or level for the tool used. For example, a vendor may describe providing “logical support” for an iOS device when the support is actually a query and return of the database content, which is then displayed via the user interface. In all actuality, an iOS device contains numerous files, as depicted in Figure 8-5, such as property lists (plists) and SQLite databases that contain user, system, and deleted data at the logical file system level, which is something that the vendor does not support but claims to. This type of recoverable data at the logical level clearly extends the definition of what is often described as a “logical extraction.” Chapters 13 and 14 are dedicated to the analysis of these types of files, so you can clearly see that the term “logical” is often misrepresented by software vendors.

FIGURE 8-5 In an iOS device file system, many files not represented by a superficial logical collection will be missed.

When possible, the examiner should make a collection of a device’s file system. The information contained far exceeds any data that is collected on the surface. Collecting the “surface” logical data along with file system recovery is what every examination should strive to accomplish. This type of collection should be referred to as a file system collection, not simply a logical extraction.

Physical Collection

To some, a physical collection includes application data, system files, and other information that is not available to the user via the handset. NIST SP 800-101 states that a “physical acquisition implies a bit-by-bit copy of an entire physical store (e.g., a memory chip).” In 2013, “SWGDE Best Practices for Mobile Phone Forensics 2.0” used a definition of a physical acquisition that was identical to that of NIST. In 2014, “Cell Phone Forensics in a Correctional Setting: Guidebook” was released and published by the Department of Justice, which described a physical analysis of a mobile device as a “digital forensic examination process that involves reviewing the data on a digital device by pushing a boot loader into the digital device and dumping the memory from it.” Then, in 2014, NIST SP 800-101R described a physical acquisition as “extracting and recording a copy or image of a physical store (e.g., a memory chip).” Clearly, as with the definitions for logical collection, practitioners and researches interpret the definition of physical collection in various ways. In some instances, the definition is so vague that some software vendors are selling tools along with their own idea of supporting mobile devices “physically.”

If the NIST and SWGDE literal definition implies that a bit-by-bit copy of a memory chip is used, then software vendors providing “physical” support for legacy devices, or smart devices using a USB cable, are not compliant. Providing a bit-by-bit copy of mobile device memory would entail an interaction with the actual memory store using a tool that can read from block 1 to block n, where n represents the ending block of the flash memory chip. Inherently, a mobile device, when interacting using a USB cable, will be able to scan and collect data only in a way that is allowed at the operational level of the mobile device. In simple terms, a mobile device will enable the examiner to extract what he or she wants and only if the software can communicate in the way the device can understand. So a change is necessary in how an examiner should approach a physical examination of a mobile device and then define what is taking place.

The physical collection of a mobile device’s data should imply that direct communication with a device’s internal data storage is made to collect a representation of the data as it is stored on the actual device flash memory. This data is a snapshot of the area of the flash memory store that is accessible using specialized tools and methods. That being said, there are different levels of a physical collection that depend upon the type of specialized tools that are used. In “Best Practices for Mobile Phone Forensics 2.0,” SWGDE defines these as “non-invasive” and “invasive” physical collections, which are further explained in the following sections.

Non-Invasive Physical Collections

A non-invasive physical collection, according to SWGDE, “involves a process that provides physical acquisition of a phone’s data without requiring opening the case of the phone.” With this technique, the software must be able to communicate with the device to allow for a binary data “dump” of the device. In most cases, a collection using non-invasive techniques and software will not yield a physical image as defined by NIST (a bit-by-bit copy of the physical store). However, this method should yield a representation of the data area targeted by the software’s communication in the format in which it is stored on the device. The data can then be interpreted and displayed in the software as it was on the device, allowing for advanced analysis techniques.

An example of a non-invasive method is attaching a flasher box to a device’s USB port or FBUS connection and dumping the memory from predefined offsets known to contain user information. Another non-invasive example would be collecting an Android device using tools such as Oxygen Forensic Analyst or Detective, UFED, and XRY and selecting a physical option for a particular device that is not currently locked, with Android Debugging enabled. All mentioned tools communicate with the device to obtain partition information using the Android Debug Bridge (ADB), and they subsequently extract the returned partition table and partitions without altering the device partitions or operating system structure, which should be considered non-invasive.

Communication does not always necessitate the loading of a boot loader, as some literature indicates, but elevated privileges to the device do need to be obtained by the software conducting the physical collection (such as HEX dump or data dump).

These methods, however, target only what is visible by the communication method. Various partitions are not enumerated by the Android device’s operating systems by design and are not accessed or extracted by the forensic software. Again, the partitions that are available are extracted and in the format (file system) found within the actual device, but it is not a bit-by-bit representation of the entire device memory store.

Invasive Physical Collections

An invasive process, according to SWGDE, provides physical acquisition of a phone’s data and requires disassembly of the phone for access to the circuit board. For example, JTAG (Joint Test Action Group) or ISP (In-System Programming) allows for communication with a mobile device using the device test access points (TAPs). JTAG is not a direct read of the actual memory module (flash), but a method to communicate with the device processor to access the NAND area of the device and obtain a binary file containing a representation of the partitions on the device. ISP differs from JTAG in that the processor is bypassed and the connection is made directly to the embedded Multi-Media Controller (eMMC) or embedded multi-chip package (eMCP) flash memory. Again, if the software is interacting with the device microprocessor, the microprocessor will dictate what memory stores are available and where to read from. The use of JTAG and ISP is classified as invasive primarily because the direct interaction with the mobile device circuit board is necessary when soldering to the TAPs or using specialized connections directly to the circuit board.

Usually, a device is still functional after a JTAG or ISP procedure.

Another example of an invasive process is the removal of the memory chip from the mobile device, typically referred to as a “chip-off.” Chip-offs are destructive methods, however, and generally the mobile device will not be functional after using this technique. A chip-off, however, will enable a direct read of the memory chip using specialized hardware and software. The examiner can create a full binary file of the device memory flash without limitations typically imposed by a device microprocessor. This physical collection method would conform to a bit-by-bit representation of the entire device physical store and equates to a traditional hard drive collection. The resultant data must also be interpreted by software and a represented file system compiled from the binary file in order to conduct further analysis. As devices progress along with more security-focused operating systems, the encryption of the device at the file system and file levels will hamper JTAG, ISP, and chip-off examinations as well.

Collection Pyramid

A “collection pyramid” was developed by Sam Brothers of the U.S. Customs and Border Protection and described in the SWGDE document “Best Practices for Mobile Phone Forensics 2.0” and also later published in “Guidelines on Mobile Device Forensics.” This pyramid outlines a tool classification that can be used as a practitioner’s approach when conducting mobile device examination; it is a departure from merely classifying a tool as logical and/or physical. Using this approach, the examiner can outline the analysis methods without identifying the differences between a logical and physical acquisition relative to the device or the data, but relative to the actual type of analysis and extraction methods used.

This ideology traditionally caused confusion in the mobile forensic community. Because of the various opinions as to what constitutes a logical examination versus a physical examination and the comparison to the definition imposed by computer forensic examiners and governing bodies of forensic practitioners, the use of multiple analysis methods is recommended. By describing methods of collection of a mobile device, an examiner can predict the outcome of using the available forensic tools and also the training and expertise required for each discipline.

The collection pyramid is visually represented as an analysis ranging from the most invasive and specialized tool to the least invasive and least specialized tool (see Figure 8-6). The tip of the pyramid, or smallest represented part, is the most specialized tool, and the largest and base of the pyramid is the least specialized. These methods are numbered from 1 to 5, with 1 being least specialized and 5 the most specialized. The following sections present the different levels listed by name, as provided by Brothers, with additional information to explain better what each will offer to the examiner when conducting each level of analysis.

FIGURE 8-6 Tool classification pyramid (copyright Sam Brothers, 2015)

Level 1: Manual Extraction   Manual extraction, or examination, involves capturing stored device information either by photography or written documentation. Photographing the information would be much more reliable in legal proceedings and therefore is the preferred method. Conducting a manual examination via the “commando method” or by “thumb jockeying” the device involves manual manipulation of the device to locate evidence stored inside. This method involves navigating the mobile device to the user stored areas and photographing or writing down the content observed in the device’s viewing area. The first mobile examinations were conducted using the manual examination method, but mobile devices at that time were not capable of storing the amount of data that can be stored in today’s devices. Conducting a manual examination of a smart device today is a considerable feat when prompted to document thousands of mobile device text messages, videos, or images!

Manual extraction may be the most cost-effective, and sometimes the only available, option, but it can be difficult at times and dangerous in others. If a mobile device is damaged or locked or data is stored in a foreign language, the documentation can be difficult, if not impossible. Manual examinations of a mobile device can be conducted by examiners without training and with only a digital camera, which involves more people in the examination process. Manipulating the keys and navigating a foreign device could expose the possibilities of unintentional data corruption at a later date, and there may be a complete disregard for the preservation of the data. Tools for conducting manual examinations are further discussed in the “Tools Available” section later in the chapter.

Level 2: Logical Analysis   A logical extraction occurs using a built-in device transfer method (such as USB, Wi-Fi, IrDA, or Bluetooth) used by the mobile device. A connection is made with the device using a data transfer method, whereby the software can communicate using device protocols to extract data using commands comprehended by the mobile device. The data is returned to the software, which can be further analyzed and reported. This is the type of collection currently offered by most examiners as well as forensic software vendors.

Level 3: HEX Dumping/JTAG/ISP   This level of collection uploads specialized software into the volatile memory of a mobile device. In doing so, it bypasses built-in security that would typically inhibit access to the device’s internal memory store. However, devices that have chip-level encryption enabled will still pose problems for examiners.

This method could be used when conducting an analysis of an iPhone 4. These devices do not allow access to the internal protected stores that contain protected data (for example, Apple’s built-in e-mail client) using any of the connection methods and communication described in a logical extraction.

A custom application or package is installed onto the device in an effort to act as the original application, package, or ROM on the device that contained the security measure. Once this vulnerability has been patched with the vendor’s own application or package, allowing access to the device that was inhibited by the device file, the examiner can then access the files using commands and procedures used by the mobile device. Typically, a raw file system, represented in the format used on the mobile device, is extracted.

A subsection of this portion of the pyramid also belongs to flasher boxes and JTAG methods. Both will be described in the “Tools Available” section, but to help you understand their placement in this pyramid, they are briefly described here.

By using the JTAG TAPs in a mobile device, the examiner has access to the flash memory. Using specialized tools comprising hardware and software, the examiner uses software to communicate via hardware to the microprocessor of the device that interfaces with the flash storage medium. The examiner accesses the flash area, circumventing password security, to obtain partition information and user storage areas. Using JTAG or ISP can be invasive because the device is disassembled and in some instances leads are directly soldered to the TAPs on the circuit board, but in some instances preconfigured jigs can be used. The output when using JTAG or ISP is a binary file of the selected partition or memory area.

The output produced by most flasher boxes is represented by what the hardware flashing device has been configured to output. The output can be in an encrypted format, segmented, or altered (boot loader added to start of image), or it can be a flat binary file. This is truly a hexadecimal representation of the data living on a mobile device. Limitations to flasher boxes are numerous, ranging from proprietary output to flash area memory constraints. Data output produced with the use of JTAG or ISP methods offers a better representation of the data, with little interference with the digital data output—it is the preferred method, but it can be more physically destructive to the mobile device. The decision to use these devices should be left to examiners with appropriate training and an understanding of the various formats and implications of using the tool and its invasive nature. This type of collection not only involves specialized hardware, but also specialized training and skills.

Level 4: Chip-Off   The chip-off examination involves the physical removal of the mobile device flash memory. Using specialized tools and techniques, the examiner disassembles the device and removes the flash memory from the circuit board. Once the flash module is removed intact, it is placed into a specialized component to read memory modules. These memory module adapters are specific to the type of flash memory and its configuration. A binary file is produced upon reading that must be interpreted by software that specializes in the decoding and interpretation of this type of file. An examiner who should be conducting these examinations should be well trained; otherwise, the evidence could be easily compromised. Needless to say, a chip-off examination is invasive, and once the chip is removed from the device, the chip would need to be reballed and then reinstalled into the device so it could operate as it had previously. This process is extremely labor intensive and equally expensive. Generally, once a device has been disassembled at the chip level, the device is inoperable.

During the removal process of the BGA chip, you must remove the tiny pads that allow for the flow of input and output communication to the PCB; these must be reattached, which is called reballing. Reballing involves affixing tiny solder beads to each pad on the memory chip. This is no easy feat, as some flash memory chips have more than 200 pads! These beads, once affixed, are then reheated (reworked) to allow them to become permanently attached to the flash memory, which will allow communication with a chip programmer.

Level 5: Micro Read   With this level of examination, the flash memory medium is read by an electron microscope. This type of examination is not only considered theoretical, but it has never been conducted publicly on mobile device evidence. The theory involves using an electron microscope to read and count electrons that occupy a cell on a flash memory chip. If electrons are present, a 1 is represented; if no electrons are present in the cell, a 0 is represented. This is often referred to as “gating.” After combining the binary data manually, it can be translated into raw data and interpreted. An example of the work involved to translate the information after reading from a flash chip is shown in this example:

01001101 01101111 01100010 01101001 01101100 01100101 00100000 01000100 01100101 01110110 01101001 01100011 01100101 00100000 01000110 01101111 01110010 01100101 01101110 01110011 01101001 01100011 01110011 00100000 01100110 01101111 01110010 00100000 01110100 01101111 01100100 01100001 01111001 01110011 00100000 01100101 01111000 01100001 01101101 01101001 01101110 01100101 01110010

What is incomprehensible would be the interpretation and decoding of more than 32GB of binary data from a standard Android device using this technique. Most examiners will never experience this form of examination and collection, but those who do this will probably not boast of their exploits, since this work would likely involve matters of national security.

Collection Additions

Although the collection pyramid does capture a vision of classification based upon collection of digital data from a mobile device with a tool, some additional considerations must be addressed and added to the continuum. If classifying a tool and a collection, you must consider a few other methods and subsections involved.

Descriptions of manual examinations using a specific tool or method should include a subset that describes using imaging (such as a photograph or video) or not using imaging. Suggested additions include manual extractions, manual with documentation, and manual with photography and documentation. There are obvious differences between simply pushing buttons and writing down the contents versus pushing buttons and then photographing the screen.

Pushing buttons on the device and writing down the contents displayed takes no tool training and is very labor intensive; it should be classified separately from more thorough methods. Methods progressing up the pyramid would involve manually pressing a device’s buttons and then photographing or creating a video of the various screens of interest. By using video, the examiner is not only documenting the data on the screen but also the procedure he or she used. This can help to dispel any allegations of improprieties that may have occurred during the manual examination.

In the logical classification of the pyramid, a file system extraction should be included for defining a tool and the mobile device analysis. Some tools do, in fact, perform a logical extraction, but they fail to support the device file system and should be classified separately. A file system collection will contain data not accessible by the user as well as data that has been deleted by the user, unlike a traditional logical query. Analyzing a mobile device file system can be challenging and time consuming, and extensive examiner training is necessary, which also should be considered in the tool and analysis continuum. Because of the enormous amount of additional data that can be collected in a file system extraction, it is always the preferred method. However, most collections by mobile forensic tools and examiners are logical without an attempt to collect the file system because of a lack of understanding and expertise in the analysis of the resultant collected data.

SWGDE identifies a file system level of collection in “Best Practices for Mobile Phone Forensics 2.0.”

At the pyramid’s HEX Dumping and JTAG collections level, the term “boot loader” is identified as a method that satisfies a higher level of tool collection and analysis. Because a boot loader is not always needed to obtain a raw binary dump of a mobile device, a better classification should be used. A new tool and collection pyramid can be created to indicate not only the types of tools that can offer the type of collection required but also the level of complexity of each tool, as shown in Figure 8-7.

FIGURE 8-7 A clearer representation of both tools and analysis, including portions of SWGDE and the tool classification pyramid

To understand these new categories, you need to understand boot loaders.

Boot Loaders

A boot loader is code that loads in a runtime environment or operating system. Boot loaders can be used in nearly all digital devices that have an underlying operating system. With mobile devices, a boot loader can change depending upon the hardware as well as the device’s service carrier. If the boot loader code becomes corrupted, the device either cannot be started or will continue to restart over and over—this is referred to as a “boot loop.”

The use of a boot loader to obtain a physical collection of a mobile device is classified in the “SWGDE Best Practices for Mobile Phone Forensics 2.0” as a non-invasive physical classification. Considerable operational differences are involved between using or not using a boot loader. Tool classification should be further expanded to describe that not all collections of binary data from mobile devices will involve using a boot loader, and in some instances, altering a device’s boot loader can have dire consequences.

To use a custom boot loader in mobile forensic software, the examiner places the device into a particular mode—for iOS devices, this is called Device Firmware Update (DFU) mode; most Android devices use a recovery, download, EDL (Emergency Download), or fast boot mode. This can occur operationally by the software or hardware intervention, but the examiner typically places the device into this state with a combination of key presses. Once the device is in the correct mode, the examiner selects the device make and model, and the software then replaces the device boot loader, unlocks the boot loader, and in some instances of Android replaces the ROM with a custom recovery ROM. The software then begins the process of calling instruction code to complete the collection of the mobile device’s data store. The customized version of the boot loader and/or recovery ROM loaded onto the device has been designed to allow full access to the device’s memory store and additional settings relating to data transfer. With a customized version in place, communication can occur with the software to obtain unadulterated access to the device.

Typically, on completion of the data collection, if the boot loader or ROM was exchanged, the original boot loader or ROM is returned to the device. In many cases, the customized boot loader is installed in the volatile area of the device’s memory and will be released upon restart of the device to remove it. The use of a custom boot loader or ROM is specific to each device, and if the custom boot loader is used on another device, corruption of the device boot process can occur and render the device useless. For this reason, a classification for “physical non-invasive” should include a subset that describes tools and analysis if you are using a custom boot loader; otherwise, these techniques should be classified as “physical invasive.”

Tools such as Cellebrite UFED Touch 2 use a modified USB cable to place a device into device mode without requiring a keypress pattern.

Not all binary collections described as “physical non-invasive” have boot loaders or ROM altered to obtain a hexadecimal dump of the memory store. Some techniques used in mobile forensic tools also allow physical access to a device memory store by the addition of a code set not available in the device’s original codebase. The action places a file or files into the temporary space of the device’s logical file system. This code then adds commands that are not installed by default to be executed to elevate privileges on a mobile device. With elevated privileges, the software can communicate with the mobile device and obtain access to areas of the memory store that are typically inaccessible. Once these areas are accessed, the memory storage can be recovered from the mobile device.

The classification “HEX/JTAG” and even “physical non-invasive” should include these possibilities and not assume that this classification applies only to tools and collections that use a boot loader to access a device memory store. This classification should indicate that the collection involves using customized techniques to enable access to the mobile device memory store that are not accessible ordinarily, because some methods might be non-invasive to the physical device but invasive to the internal operation. This classification would apply to boot loaders, rooting software, customized files, and customized ROMs.

Nontraditional Tools

Other tools can be used in many investigations, but because of their limitations or other concerns, they are considered “nontraditional” tools. Some tools are considered non-forensic, and others are extremely expensive. Having a thorough understanding of how these tools can be used is important because these tools are often discussed throughout the digital forensic community. Likewise, in some situations, nontraditional tools may be the only means of recovering the data.

Manual Examination Tools

A manual examination of a mobile device can include photographing a mobile device’s onscreen digital content using a tripod and a digital camera. The examiner will move from screen to screen, photographing the various pieces of evidence. This technique can be accomplished without specialized training in digital data recovery.

For a manual examination, use a digital video camera at the beginning of the work and allow it to run continuously during the entire process. This entire work can be reviewed for court, final reporting, or both. Stills from the video can be captured when needed for inclusion in a written report.

Some commercial products enable you to capture images of mobile device evidence. Using these tools, you can immediately document images or video in associated software for later review and reporting. There are, of course, limitations to the types of information that can be obtained using these tools, but little to no training is needed to operate them.

The following solutions are similar and enable the examiner to obtain information from the mobile device that may not be possible using traditional mobile forensic tools. Also, by using a manual solution, the examiner can allow for the documentation of the manual manipulation of a mobile device prior to conducting a traditional examination to show the actual device during testimony or presentation.

•  Paraben Project-A-Phone ICD8000 and Paraben Project-A-Phone Flex   These camera setups allow for both HD video and 8-megapixel pictures. The ICD8000 uses a clamping mechanism that can inadvertently press buttons on the side of the mobile device, including the power button on the right side of most Android devices, and improper clamping could change settings or power off the device. The Project-A-Flex does not use a vise but instead uses a mat on which the device can be placed to photograph the evidence.

•  Fernico ZRT3   This tool combines a camera and HD camera along with materials to hold the device and cameras in place. The device connects directly with software installed onto a PC to capture the photographs, and it uses technology such as Object Character Recognition (OCR) to translate images containing text to searchable text within the report. The device includes a mat onto which evidence can be placed to conduct the manual interrogation of the device.

•  Teel Technologies Eclipse 3 Pro   This tool is similar to the ZRT3 and combines a camera, mount, and platform, with a software solution to capture and document the images collected during the manual examination.

Flasher Boxes

A flasher box is a service tool that is typically used by mobile device technicians to fix a nonresponsive device, add features, or unlock a device for unrestricted access with any carrier. The tool’s name is derived from the action that the device is built to perform—it flashes a new version of the device firmware, ROM, OS, or settings. The flasher box could also be used to add language packs and even to change the serial number of the mobile device. The altering of a mobile device’s serial number (IMEI [International Mobile Station Equipment Identity] for GSM and ESN/MEID [Electronic Serial Number/Mobile Equipment Identifier] for CDMA) is illegal, however, and by changing the serial number, some devices can operate on a network blacklisted by their original serial number. Device manufacturers do not endorse the use of these types of hardware tools for these reasons.

These hardware devices were never designed for mobile forensics, but they are frequently used, and their technologies were used to formulate a lot of the current mobile forensic product capabilities. Each flasher box functions, programs, and repairs a specific device—sometimes a specific model of mobile device. Because of the various differences in device hardware and programming, many hardware flashing tools are available to fulfill this need. Not only are multiple boxes available, but these boxes come with multiple cables. Typically, each mobile device must have its own specific cable, and hundreds of cables are available for these boxes.

Because the devices are developed to repair and alter a mobile device’s software, the software used to control the flasher box can read and write to the attached device. Because of this ability, most examiners will not use a flasher box to conduct a physical examination of a mobile device; in addition, there is little to no documentation regarding how to use the hardware and software. This type of analysis should be classified as invasive, and the examiner needs specialized training before using this technique.

A flasher box will communicate with the mobile device using serial and USB protocols to recover areas of mapped memory. Memory offsets must be known if not identified by the software to recover the area where user data is stored. The resultant output is a binary file that often must be manually parsed and interpreted to locate evidence artifacts. In some cases, the data that is output is encrypted in a format known only to the flasher software. In this way, the flasher box manufacturers hide methods and procedures from other flasher box manufacturers. This limitation makes it difficult to examine the produced file. Table 8-2 represents some of the common flasher boxes and a general idea of the device support.

TABLE 8-2 Common Flasher Boxes Used in Mobile Forensic Device Collections

JTAG

The Joint European Test Action Group (JETAG) was formed in 1985 in Europe as a standard for boundary-scan testing. Boundary scanning in the context of mobile devices efficiently tests connections on the printed circuit board in an effort to program or debug the device without needing physical access to the flash. In 1986, members from North America joined, and the group became the Joint Test Action Group (JTAG).

Between 1986 and 1988, the group proposed and published a series of proposals to the IEEE Testability Bus Standards Committee (P1149) with the final JTAG Version 2.0 being accepted. This standard (IEEE Std. 1149.1) was accepted and published in February 1990 and has been updated several times with the current specification identified as IEEE Std. 1149.1-2013. At its core, JTAG is the standardization of TAPs and boundary-scanning architecture.

The word “JTAG” has a variety of meanings, from directly programming systems to debugging others, from Xbox hacking to forensics. In the context of this book, JTAG is described as the process of setting and reading values on the test pins accessible on the PCB of the mobile device. By using the TAPs, communication can occur via the boundary-scan path, interfacing with the Boundary Scan Registers (BSR) that interface with components on the PCB. These components can be programmed or read without removing, independently reading, or programming each separately.

In order for communication to occur with components, IEEE Std. 1149.1 indicates at a minimum that three input connection ports and one output connection port must be on a PCB. Furthermore, the TAP is a multipurpose port that enables access to test support functions built into a component, and the standard outlines that the TAP shall include TCK (Test Clock), TMS (Test Mode Select), TDI (Test Data In), and TDO (Test Data Out) as connections. An optional input port, TRST (Test Reset), can also be used and is covered in the IEEE document. A basic understanding of each TAP is outlined next in an effort to help you visualize what is taking place when conducting a collection using JTAG, which is also represented in Figure 8-8.

FIGURE 8-8 A simplistic communication model from a software debugger/programmer to and from a mobile device TAP group

•  TCK (Test Clock)   This port enables the synchronization of the internal state of the device between components. Devices are made of many components that could be using different forms of timing. The TCK maintains a standard across the components during a test.

•  TMS (Test Mode Select)   This port controls the TAP controller and relies on the TCK to determine the state of the process.

•  TDI (Test Data In)   This port accepts the data from the software debugger/programmer and sends it to the target.

•  TDO (Test Data Out)   This port accepts the data from the target and sends it to the debugger/programmer software.

•  TRST (Test Reset)   This port is optional but can be used to reset the TAP.

The TAPs for mobile devices are not readily documented, and manufacturers are making it more difficult to locate them on the device PCB. Some manufacturers, such as BlackBerry, have gone to massive lengths to hide the TAPs or place them where any access destroys the device. Some software and hardware vendors do have the devices that they support listed within their software showing the TAP locations, and some software can determine the correct TAPs automatically.

JTAG hardware for mobile devices is just another type of flasher box, but the point of communication and interaction is different from that of the typical box. The difference is the fact that serial communication occurs to and from TAPs located on the mobile device PCB, unlike most flasher boxes that communicate using the traditional USB connector pin-outs on the device.

Some flasher boxes used for Nokia models communicate using the Fast Bus (FBUS) or Meter-Bus (M-Bus) connectors on the PCB, which are early forms of TAPs. These connections were exposed and available under the battery, as shown in Figure 8-9.

FIGURE 8-9 FBUS connections on a Nokia 1280

JTAG hardware communications occur from the software to the hardware box through a cable or wire attached to the TAPs on the mobile device PCB. The wires to the device TAPs must be in contact for communication to occur. You must locate the TAPs and determine the type of test port in use. Because some JTAG boxes do not auto-detect the port type, this process can be time consuming. To determine to correct test port, you can use a secondary tool to scan the TAPs and identify TCK, TMS, TDI, TDO, and TRST. One such tool, the JTAG Pin Finder from 100RandomTasks, enables the examiner to attach wiring from the JTAG Pin Finder to the TAPs on the PCB and use associated scanning software to determine the correct ports. Once the correct ports are identified, the wire can be attached to the JTAG hardware to conduct a collection. Both the scanning of the port and subsequent collection involves soldering the wire to the appropriate TAP, as shown in Figure 8-10. However, in some instances, special Molex connectors can be used that snap directly onto a female Molex connector located on the mobile device PCB (Figure 8-11). Using a Molex connection would mean there is no need to solder the wires directly to the TAPs on the device PCB, which can be advantageous when attempting to determine the level of invasiveness that will be acceptable.

FIGURE 8-10 JTAG Pin Finder for scanning JTAG TAPs

FIGURE 8-11 Molex connector attached to a Samsung S3 JTAG TAP

JTAG software undergoes communication with the mobile device, and the examiner identifies the type of data to collect. When used correctly, the software can bypass all security of a mobile device and obtain entire device images in the file system format that exists in the flash memory. The JTAG software does not interpret the data to allow for a forensic analysis and the rebuilding of the file system, but several tools such as Cellebrite Physical Analyzer, MSAB XRY, and Oxygen Forensic Detective can import and analyze such images obtained from a JTAG collection.

Again, like using flasher software, JTAG hardware and software was developed to flash, alter, and repair a mobile device. It was never the intention of the JTAG hardware and software designers to offer features that would be used by mobile forensics examiners. Because of this, examiners must be properly trained in using these tools. All associated JTAG software can destroy evidence if not used correctly in a controlled environment, but when used properly, it can yield magnificent results. Table 8-3 lists several JTAG hardware and software combinations with supported device information.

TABLE 8-3 Commonly Used JTAG Boxes in Mobile Device Collections

ISP

In-System Programing (ISP) is a method similar to JTAG, but as mentioned previously, using the ISP technique will communicate directly with the flash memory and not through the processor. As with JTAG, the TAPs will be utilized to connect to the PCB and then to a hardware device to conduct the communication directly to the eMMC/eMCP and transfer the data to the software interface. The benefit of using ISP rather than JTAG is there is no dependence on the processor of the device—only the flash memory. Acquisition is not limited to only mobile devices but anything that is utilizing eMMC or eMCP flash memory, if the TAPs can be located and accessed. The TAPs identified by flash manufacturer Kingston Solutions, Inc., in the document “Embedded MultiMedia Card EMMC04G-M627-A01,” that can be utilized for ISP are the CMD, DATA0, CLK, VCC, VCCQ, and GRD. Listed in Table 8-4 are some hardware devices commonly used for ISP collection.

TABLE 8-4 Commonly Used ISP Boxes in Mobile Device Collections

Chip-Off

The removal of a device’s flash memory module and analyzing in a chip-off procedure is quite labor intensive in both the removal of the actual embedded flash memory chip and reading of the stored data. Because of the various differences between phone models and storage types, which could range from Thin Small Outline Package (TSOP) to Fine-pitch Ball Grid Array (FBGA), the purchase of the equipment to read the information from the embedded chips and the time investment required can be expensive. However, conducting the imaging of the memory chip using this method is the closest to the bit-by-bit collection a forensic examiner would expect and is similar to imaging a computer’s hard drive.

To perform a collection using the chip-off method requires that the examiner have specialized skills in disassembly of mobile devices, repairing of mobile devices, desoldering and soldering of fine electrical components, and forensic procedures. This technique is commonly referred to in electronics as “rework.” Depending on the type of chip, TSOP or FBGA, the removal and preparation of the memory chip will require different skills and time investment.

For TSOP chips, the pins that attach the chip to the PCB are exposed and can be easily removed by heating the solder joints. BGA chips must be heated to the correct temperature to remove the solder joints and adhesives and then be carefully removed from the PCB because their solder joints are not accessible along the exterior, as are TSOP chips. Both chips must be removed with extreme caution, because they cannot be reattached to the mobile device after removal. Upon successful removal, both TSOP and BGA chips must be thoroughly cleaned, examined, and inspected. For BGA chips, once they have been examined, they must also be reballed.

Once properly prepared, both TSOP and BGA chips can then be attached to the appropriate adapter and read in the designated chip programmer.

TSOP chips are not as common as BGA chips in today’s devices and are used in mobile devices on limited runs, prototypes, and smaller manufacturers. BGA chips allow for larger data capacities and faster input and output (I/O).

A chip programmer tool will allow for the collection of the raw data from the memory chip. The programmer itself can also be a detriment, much like a flasher box or JTAG box, because it can write to and even erase a memory chip if it’s used incorrectly. Examiners must follow proper procedures when using such equipment. Also, typically, more than one programmer should be available to an examiner because there are many different types of embedded flash memory types with the many mobile devices, adding even more complexity. In addition, prior to placement in the chip programmer, the memory chips are affixed to unique adapters, and each of these can cost upwards of $1800! These adapters must be compatible with the memory chip type—with the many differences in BGA-style chips, this can become extremely expensive.

Once the chip has been placed into the correct adapter and into the chip programmer, the examiner must select the identical chip and model as printed on the memory chip to begin the reading process.

The exact chip manufacturer and chip module must be selected and supported by the chip programmer. This step helps to identify unique preferences, algorithms, and settings that might be needed to perform a collection.

The analysis of the file produced by reading the memory chip is often the most tedious part of the process. Because a mobile device memory chip is based on flash memory (such as NOR or NAND) chips, the inherent advantage of I/O when compared to a traditional spinning hard drive might be the biggest detriment to forensic examination at the chip level. NOR flash memory is older technology that allows for high read performance, but it does not allow for high capacities. NAND flash memory allows for both faster programming and erases, but it can consume more power because of its higher functioning and complicated I/O interface. To understand some of the problems that could be encountered, you need a better understanding of flash storage.

When you put together the ways in which a NAND chip’s memory is constructed—the built-in structures, wear-leveling, and garbage collection processes—and the ways other various file system types are constructed, it is no wonder that reconstructing the data from a chip-off examination is so difficult. Data collected by a chip-off examination can look disjointed and spread across the entire image. When this type of data, commonly referred to as “non-contiguous” data, is used, it makes recovering the data extremely time intensive on some mobile device file systems.

It’s important to recognize the way flash memory moves data on the chip surface to prolong the life of the medium. With the function of traditional file systems and the flash translation layer, along with flash file systems, the fact that data is often written multiple times across the medium provides more opportunities for the examiner to recover forensic artifacts.

Traditional Tool Matrix

Table 8-5 indicates logical, file system, physical (non-invasive and invasive), and limited support features of several forensic tools. Limited support means only a small number of devices (such as Android and iOS only). For brevity, only the most popular tools currently in use are listed. NIST maintains a large list of forensic tools on its web site, including most mobile device forensics tools on the market (www.nist.gov/itl/ssd/software-quality-group/computer-forensics-tool-testing-program-cftt/cftt-technical).

TABLE 8-5 Traditional Mobile Device Forensic Tool Classification

Tools Available

A plethora of mobile forensic solutions are available today, from open source software, to freeware, to commercial tools. As previously discussed, the tools used in the forensic laboratory and in the field are those that can be used on the majority of devices observed in the area of operations. The tools discussed in the following sections cover the majority of devices, have the most robust feature set, and complement one another. These tools will provide the capability and versatility you need when you’re conducting mobile forensic examinations.

Open Source Tools

Open source tools allow for the viewing, changing, altering, and sharing of the source code by anyone. Any restrictions depend upon the licensing that accompanies the distribution. Most open source mobile device forensic tools are geared toward smart devices, iOS, and Androids. BitPim and TULP2G, for example, handle feature phones, but both tools are no longer being updated.

Let’s begin by discussing the actual usage and philosophy of open source tools. There has always been a rift in the forensic community regarding the use of open source tools versus commercial and freeware (closed source) tools. In 2003, Brian Carrier published “Open Source Digital Forensics Tools: The Legal Argument,” which discusses the forensic community debate that is still ongoing today and hinges on the integrity and reliability of the data and support for the software. There is no clear winner in this debate. Many examiners believe strongly one way or the other and cannot be swayed no matter the argument. However, both types of software can coexist in today’s mobile device forensic toolkit.

Using an open source tool for the collection of a mobile device can be of great benefit because the collection of the device is 100-percent verifiable and transparent. That is difficult to say about a closed software solution, which is often an Achilles heel for the examiner who has no idea how the tool extracted the data from the mobile device—it just simply happened.

At times, the use of open source tools is advisable simply because the mobile device image creation can be closely observed. Because device image creation is often challenged, having the source code to gather specific intelligence as to what is “under the hood” can help you dispel any allegations to discredit the image creation.

iOS Devices

iOS devices can be examined using several open source tools that work for both Windows and Linux as well. These tools all use the Apple Backup service to initiate a local backup of the device, just as a user would if using iTunes. Some tools also use additional Apple services during the collection of mobile device data. All of the tools covered in this section allow access to the device without enabled security—that is, the passcode for the handset as well as the iTunes password must be known, if enabled.

Inflatable Donkey   This software is used to extract iCloud backups up to and including iOS 11. This software does not parse and decode the software, but it downloads the specified databases contained in the user’s iCloud account. These databases can then be viewed in many commercially available tools as well as some freeware. As of November 2017, development of the code ceased, possibly (rumored so) because of pressure by Apple on the availability and usage for nefarious purposes. The codebase is a fork of the iloot code that many current commercial tools’ iCloud extraction is based on. The most current build is available on GitHub (https://github.com/horrorho/InflatableDonkey).

The following features are supported for extraction:

•  SMS/iMessage

•  Call history

•  Address book

•  Notes

•  Media (video/images)

•  Voicemail

Santoku   Santoku is a suite of tools used for mobile device forensic investigations, mobile malware analysis, and mobile security assessment, all rolled into one interface using a Linux virtual machine (VM). Santoku has not been updated since September 2014 and will not work well with newer devices for both iOS and Android. However, there are tools within the kit that will offer assistance with mobile security testing and other app analysis methods. Santoku can be added to a Mac partition to dual-boot, or to use the preferred method and only suggested method for Windows, create a virtual machine.

The Santoku web site offers online documentation that walks an examiner through the installation of the materials and setup for both Mac and Windows machines. Using the tool, however, requires a lot from the examiner: to use most of the tools in the suite, the examiner must have knowledge of the Linux command line. Because of the degree of user interaction required, use of this tool is not recommended for those not familiar with command line–based programming. The suite of tools is compiled and all tools are installed, which allows for easy setup and usage, but, as indicated, it can be intimidating.

Both iOS and Android device collections are supported in the Santoku interface. (Android collection is discussed next.) For iOS devices, Santoku can collect, parse, and carve data. Collections occur via an iOS backup, using an open source library called libimobiledevice, shown in Figure 8-12, and then use iPhone Backup Analyzer to conduct the parsing of the iOS backup. iPhone Backup Analyzer is the previous version of iPBA2.

FIGURE 8-12 Using the Santoku interface to start libimobiledevice to create an iOS backup

Additional tools for parsing device data also are installed on the virtual machine. Both Scalpel and The Sleuth Kit are included (https://github.com/sleuthkit), which can be used to investigate the file system and conduct data carving methods. Both tools are also command line tools but can allow for analysis of the file system to locate files by type, create a timeline based on identified files, and check hashes of files against known hash libraries and custom libraries.

Android

Many more open source tools are available for Android devices, probably because Android source code uses some open source language and access to the Android development SDK is available online (http://developer.android.com). Because of the variety of devices on which the Android OS operates and variants of firmware on top of the various builds of the operating system, open source tools are sometimes more reliable for the collection of the device data. Quick code changes and frequent releases, along with high community involvement in addressing specific problems, also make open source tools popular. These frequent updates and code modifications are necessitated by the openness of the Android device OS. If a carrier uses a specific codebase or the device does not operate as the user wants, the user can change it! The “modding” community for Android is larger than any other mobile device community, with a mission to make the phone do what they want. This, in turn, offers open source developers looking to collect data, instead of change data, an opportunity to use source code already produced in an entirely different way. The following sections cover some of the tools that are used frequently in the forensic community.

Santoku   As mentioned, Santoku is a Linux-configured VM and is a self-contained mobile forensic, mobile security, and mobile malware suite of tools. For Android devices, many more options are built into the application. For basic logical extractions, AFLogical Open Source Edition (OSE), developed by ViaForensics (which changed to NowSecure in 2015), is included in the Santoku edition. This tool is not longer updated and many scripts are outdated for extraction and parsing. I mention this tool simply for educational historical purposes.

Also included in Santoku are developmental tools that can be used to obtain a non-invasive physical device file system by using exploits such as Odin, Heimdall, and built-in fastboot methods. Note that these methods are extremely risky when they’re used without proper training and guidance and can have catastrophic consequences to the mobile device data and the device itself. Santoku also contains several tools that enable the analysis of mobile device malware, including Androguard and Apktool to decompile Android application files, along with versions of Wireshark that can assist with network analysis of Android applications during dynamic malware analysis. Again, this virtual environment is not for examiners just starting out in mobile forensics, because it requires that the user interact with command line utilities.

All the tools that have been compiled under the Santoku environments are available for native installation and do not need to be run under the prebuilt environment. However, having the system already set up and configured is a plus, especially since control of the built-in applications, device collection, and data analysis often must be configured to run correctly.

Android Backup Toolkit   The Android Backup Toolkit (https://sourceforge.net/projects/android-backup-toolkit/) is a suite of tools, including some that were developed by Nikolay Elenkov, who contributed to Santoku tools, for the backup and restoration of Android backup files.

Within the Android Backup Toolkit is the android-backup-extractor, which enables not only the extraction of the Android device using ADB but also deflates the backup into a tar (tape archive) file. Once the backup is converted to a tar file, the examiner can view and open the database files of applications and other files using freely available database browsers and file viewers.

A second application within the toolkit is the no-adb-backup-lister. As you should be aware, an app developer can place a flag ("FALSE") in the manifest file for the application. This indicates that the database files will not be included when a backup is initiated. This information can be helpful in explaining why a tool did not extract information from an installed application. WhatsApp and Facebook Messenger are prefect examples of the developer using this flag.

A third tool bundled in the toolkit is android-timestamp-keeper. Unbeknownst to many examiners, and tool developers as well, is the fact that MTP mode, when extracting files from the SD card (internal/external), will alter the date/time of the files. Using the android-timestamp-keeper script will enable the modified time of the mounted partition files to be backed up and restored correctly.

ANDROPHSY   ANDROPHSY (https://github.com/scorelab/ANDROPHSY) is a tool set that runs on Linux Ubuntu, much like Santoku, that utilizes several different dependencies including Java, Android SDK with Eclipse, and MySQL.

This tool set was developed as a forensic tool that contains case and evidence management, mobile device acquisition (logical and physical), analysis, and reporting. The software was first developed in 2015 and has not been updated. It can provide logical extraction of current devices but does not provide exploits above Android 4x, per the commitments on GitHub. This tool will enable logical extractions of current Android devices, however, as long as the current version of ADB is obtained and utilized.

Take care when running these tools, because some run directly on the device and may cause undesirable effects, especially if you’re processing evidence. It is important that examiners test and become familiar with the underlying code within each of the modules.

BlackBerry: MagicBerry

MagicBerry is an open source tool (https://code.google.com/p/magicberry/) that allows for the parsing of both IPD and BBB files, which are created for data backup using BlackBerry Desktop Manager software. Newer backups that are produced by BlackBerry Link software are not supported by the MagicBerry code or any open source tools. The MagicBerry compile program can be downloaded from the MagicBerry web site (http://menastep.com/pages/magicberry.php). The software supports the parsing of the IPD and BBB file to extract several types of user data, including SMS, contacts, call logs, service book, tasks, memos, calendar, and media (images and audio). The information can then be extracted and exported in various formats. This software was not created with the forensic examiner in mind, but it does enable the recovery and parsing for presentation. The MagicBerry software has not been updated for several years, and with the change in format along with encryption, this software appears to be at the end of its life.

Freeware Tools

Freeware is software that is essentially free to use, but the source code is often not available. Most freeware code cannot be modified by the user, viewed by the community, or updated without the direct involvement of the freeware project software development team. Some of the following tools do have open source components, however.

iBackup Viewer

iBackup Viewer (www.imactools.com/iphonebackupviewer/) is a freeware tool that allows for data extraction and offers some reporting capabilities. The free version does not support the decryption of encrypted backups, though the company offers this in its paid version. iBackup Viewer supports devices up to and including iOS 11. The data that is parsed and shown in the interface includes the following:

•  Contacts

•  Call history

•  SMS/iMessage

•  Calendar

•  Notes

•  Voice memos

•  Internet history (bookmarks, history)

•  Media (phones/videos)

•  App data

•  Filesystem view

•  WhatsApp messages

iBackup Viewer also enables the decoding and viewing of the iOS property lists (binary and XML).

iFunbox

iFunbox (https://i-funbox.en.softonic.com/) is a freeware tool for iOS devices. Apple iTunes must be installed on the device that is running iFunbox because the software uses Apple’s device services and device drivers to communicate with the software. iFunbox enables access to the iOS device applications and media area for all iOS devices, and with devices prior to iOS 8, it enables access to the raw file system. If an iOS 8 or later device has been jailbroken, a raw file system is also available. This tool is especially useful for gathering the file system data to be examined later using another forensic tool. iFunbox does not conduct any analysis of the device contents; it simply enables the internal contents to be displayed and copied to a storage location without the use of iTunes. iFunbox is also very useful if iTunes cannot recognize the device to conduct a backup. This software is not a standard forensic tool and should be used only after testing and validating the processes used by its communication. All iOS devices are supported, and access to the device and its file system are available without a jailbreak. iFunbox’s last update was in March 2017, which enabled support for the iOS 10 file system changes within the iTunes backup files.

Commercial Tools

A commercial tool is a closed source application that is available for purchase. Commercial tools covered in the following sections contribute both to the collection and the analysis of mobile devices in a single solution. A lot of commercial tools that can be used for mobile device forensics perform several tasks, although an examiner might need to use a second tool to complete the analysis if a particular feature is not available. (This was discussed earlier in the chapter as a basis for a multitool approach to mobile forensics.) An example would be the collection and viewing of property lists from an iOS device. One tool may collect the files, including plist files, but these files cannot be viewed within the application, so a second tool would have to be used for that. The commercial tools discussed here can also be used generally as a single solution if multiple tools cannot be purchased based upon the supported devices and feature set.

The tools discussed are those that I am well versed with and have personally relied upon for both professional and research collections. The following information is not intended to outline how the tools should be used, provide guidelines on collections using the tools, or describe specific instructions in the analysis of mobile device data. These sections provide an overview of the tools, their features, and their general use for mobile device forensics. Also, the devices are listed alphabetically, not in order of preference. These tools will also be used throughout the processing, artifact finding, and analysis discussions within this book.

Cellebrite

Cellebrite (www.cellebrite.com/en/home/), located in Petah Tikva, Israel, produces several tools—UFED 4PC (Logical and Ultimate), UFED Touch 2 (Logical and Ultimate), and (Logical and Physical) Analyzer software—for the collection and analysis of mobile devices. The UFED 4PC, UFED Touch 2, and Physical Analyzer software perform differently depending upon the version that the examiner is using. If the examiner is using the Logical version of both the UFED 4PC and Touch 2, the collection support is for UICC (Universal Integrated Circuit Card), feature phones (GSM/CDMA), smart devices, and mass storage devices. The collected data types are logical only, without file system support. If the examiner is using the Ultimate version of the UFED 4PC or Touch 2, logical, logical file system, non-invasive, and invasive physical collections are possible. Both the UFED 4PC and Touch 2 Ultimate solutions come with the Physical Analyzer (PA) software, which is used to conduct the decoding and analysis of the collected data from either tool.

The PA software enables importing and decoding of mobile device images from JTAG, chip-off, and GPS devices, and it can decode and parse collected images created using the UFED 4PC and Touch 2 Ultimate. PA software also includes visualization of timelines, link analysis, communication analysis, malware analysis, and watch lists. PA can search globally using strings, text, proprietary device formats, regular expressions, and many other data types across the entire device image and can conduct data carving across the device image to uncover additional data from unallocated and logical file system areas. Custom scripting is via Python, and a built-in shell and plug-in feature are available. PA also has integrated malware scanning using Bitdefender.

Malware analysis using one vendor’s product can be limited, because this type of signature analysis can be easily duped by malware developers. It would be much more prudent to scan the evidence using several types of malware-scanning software to maximize signature analysis.

MSAB

MSAB (www.msab.com) produces several mobile forensic products to include XRY and XAMN. The company is based in Stockholm, Sweden, and develops mobile forensic software to include XRY, XAMN, and XEC. XRY, the collection product, is sold as part of a modular suite, much like the tools from Cellebrite. They types of extractions you will be able to perform are based upon what modules are included in your version of XRY (Logical, Physical, or Cloud). MSAB takes it a step further, however, by including modules within modules!

XRY is divided into two types of products: XRY Logical and XRY Physical, and these divided into other modules. XRY Logical enables the user to conduct quick extractions (of iTunes backup, Android backup, Android Agent) and is geared toward “pump-and-dump” examinations. The XRY Physical add-on to XRY Logical enables the user to conduct password bypass of some Android devices, on-board memory chip reads, and other advanced mobile forensic tasks. If a user wants to extract data from the Cloud or from Chinese devices, for example, he or she would need to purchase the additional license.

XAMN is similar to Cellebrite Physical Analyzer and enables the user to look into the actual extraction from XRY for analysis as well as get into the hex level of binary physical extractions. The product is also divided into modules, called Spotlight, Elements, and Horizon, that are available via licensing.

XEC is the new module focused at centralized storage, control of extractions, administrator rights, and control of workflow. XEC is not included with the purchase of XRY or XAMN and contains additional modules: Director, Export, and Express. Each module in XEC is designed for the required workflow for administration.

Oxygen Forensics, Inc.

Oxygen Forensics (www.oxygen-forensic.com/en/) is based in Alexandria, Virginia, and develops both Oxygen Forensic Analyst (OFA) and Oxygen Forensic Detective (OFD). Both applications support the collection of UICC and legacy CDMA/GSM devices along with smart devices. Logical, logical file system, non-invasive, and invasive methods are supported.

Images from other tools such as the UFED series, Lantern, and XRY can be imported into both OFA and OFD to analyze the information further. Analytics, password analysis, malware analysis, and mobile app support are available within Oxygen Forensics software as well, making these applications good choices for examiners gathering group intelligence. File carving as well as deleted data and file searching over multiple images is also a supported feature.

Support of JTAG images from Android devices can be parsed for valuable user data within OFA along with a powerful SQLite database viewer. Oxygen Forensic Detective also contains a tool (Oxygen Forensic Cloud Extractor) to obtain information from cloud services to include Windows Phone, iOS, Android devices, and today’s most popular apps such as WhatsApp, Dropbox, Twitter, Facebook, Instagram, and many more. All data recovered from any mobile device via the Cloud or directly from the device can be visually represented within a timeline, social graph, and aggregated view, along with a native user data view. Oxygen Forensic Detective also supports today’s most popular recreational drones for extraction along with decoding, parsing, and mapping.

Magnet Forensics

Magnet Forensics (www.magnetforensics.com), located in Quebec, Canada, is the newest company in the mobile forensics world. The company focuses primarily on Internet artifact recovery and introduced Internet Evidence Finder (IEF) as a supplemental tool for computer forensic examinations. The tool was designed for computer examiners to find Internet evidence quickly—something that’s often lacking in regular computer forensic tools such as FTK and EnCase. Banking on the explosion of mobile device forensic evidence, Magnet first gave away a free extraction tool for mobile devices. The output produced from the tool was then analyzed in IEF.

Recently, Magnet released a forensic tool called AXIOM. AXIOM is an upgrade from IEF, and allows for the extraction and analysis of mobile device data from the most popular smart devices, plus the import of file systems from other tools and binary images produced by invasive and non-invasive extractions (such as chip-off, JTAG/ISP). AXIOM recently upgraded the product to include cloud data extraction from within the interface. AXIOM enables the concurrent examination of data from computers, mobile devices, and the Cloud within the interface.

Chapter Summary

The mobile forensic examiner must have a critical understanding of the different types of collections and what can be collected using each method, and at what level, for success. This becomes clear when considering the multitude of tools that are available. Although tools may indicate the ability for logical collections of thousands of devices, upon closer inspection they often do not support a logical file system collection. This limitation can be a detriment when requested to unearth additional data from the mobile device that might be contained only in the mobile device file system. Being prudent in what a mobile forensic tool can accomplish and knowing its limitations before making a purchase or considering it for the toolbox are important. Understand your mission and choose the appropriate tool to accomplish it, but also reflect on what might be needed later—such as file system or partition collection. Remember that doing one collection at the onset of the investigation is preferred instead of doing multiple collections because of tool limitations.

The tool classification outlined by NIST is only a guideline, and the recommendations outlined in this chapter should be considered in the same way. Obtaining a device file system is paramount, and a subset of logical examinations that enable obtaining a file system should be included. Additionally, HEX and JTAG should be more clearly defined, as listed by SWGDE, in declaring non-invasive and invasive methods. Furthermore, the terms “non-invasive” and “invasive,” as defined by SWGDE, should not describe only physical methods, as collecting data by means of removal of the device coverings and internal components, but they should also reflect the exchange and replacement of internal software ROMs. Performing a replacement and exchange of a portion of the device operating system to circumvent security and permissions to gain a physical binary image can be just as invasive as performing a chip-off, JTAG, or ISP procedure.

What is clear in the tool classification pyramid and in the text is the fact the progression up to the top of the pyramid should be directly related both to the technical training and the knowledge needed to perform the analysis. What is also apparent in the tool progression pyramid is the relational size of each level, which can also visually represent the number of examiners conducting the specific types of examination. In addition, the need for training as the examiner climbs to the top is also important. For an examiner to be successful at the level of chip-off, for example, he or she must undergo a sufficient amount of training and have sufficient knowledge in the area of device disassembly, flash memory physical architecture, flash memory internal architecture, and digital file systems. Without a level of competency that matches the level of examination, the examiner’s success rate will be unimpressive, while the possibility of catastrophe is increased.

Many tools can be used in a mobile forensic examination, and the use of multiple tools is a necessity. Tools that can be verified and validated more easily include open source tools that enable the examiner to peer into the actual code to verify what is happening while creating an image or parsing the data. The use of open source tools has always been controversial, but usually the controversy is encouraged by commercial tool vendors. As long as the tool can be verified and validated, be it open source, freeware, or closed source, it will be usable in mobile device examinations and will stand up to court challenges. Use of commercial tools is a necessity, however, because these tools cover more devices than typical open source tools. This is primarily due to the concentration of the open source tool on a single operating system and sometimes a single device. This is not due to a lack of understanding in the open source community, but due to a particular developer or group concentrating on the device subset that they actually own! Development time costs money, and commercial tools will cover more device profiles and file systems.

Several tools were discussed at the end of the chapter that will be used for further collections and analysis throughout the book. These software applications are not the only tools available to the mobile examiner, as is plainly evident in the tools table. These tools cover the largest number of devices with the most built-in features, however. Obtaining a single mobile device solution set that can conduct collections, analysis of internal and external data, and complete reporting is often the preferred solution.

Your understanding of the levels of examinations, along with the levels the tools will support, will help you make the best decision as to which tools will best suit the examination at hand.