7 Toolbox Forensics: Multiple-Tool Approach

After the mobile device evidence has been successfully seized, tagged, and packaged, the next steps involve preserving, processing, and analyzing the data stored on the devices. As discussed in preceding chapters, mobile forensics is different from computer forensics in many ways, and one significant difference has to do with how the devices are processed during examination. With mobile device forensics, using only one tool to process and analyze the evidence can be a detrimental task, although a computer forensics examiner can sometimes get by with using only a single tool. This poses problems for a lot of mobile device investigators for several reasons—in particular, the cost involved in using several software solutions. Mobile device forensic software does not come cheap. Although open source solutions are available, one solution will not provide all the tools necessary to accommodate every type of device, every type of operating system, or all different types of stored user data. This is a limitation of all mobile forensic solutions because of one simple fact: no one tool can process and analyze all mobile devices.

This chapter covers the various reasons you’ll need to use a multiple-tool approach to the examination and analysis of a mobile device. To choose the best tools, you need to know not only what a tool is doing to the extracted data but also what methods are used to validate the tool, the collection, and the process. As a forensic examiner, you will encounter a variety of pitfalls, whether you are trying to use a single tool or multiple tools. Your understanding and preparation for these challenges will help reduce criticism of either approach and will help you improve your expertise in the mobile forensic field.

Preparing for the challenge of collecting digital data from a mobile device is based primarily on the methods and tools that you use. Of course, most examiners are not capable of financially supporting each forensic solution currently available on the market. With that in mind, you must be knowledgeable of what your current software is capable of and its limitations. More importantly, you must research the available software and purchase the most competent software that will handle the majority of devices you will encounter. Research the types of devices, operating systems, and available and appropriate technologies; armed with this information, you can make the right decision regarding the best tools to use.

Choosing the Right Tools

Your decision as to which tool to use in an examination can be affected by a variety of factors, including price, ease of use, and, more often than not, using what “everyone else” uses. Each of these reasons has its own merits. Studying a tool and using sound judgment can make your decision much easier.

Commercial mobile forensic tools are some of the most expensive software examination tools available. Although their prices vary significantly, what is included in each is not necessarily related to the price—in other words, the manufacturer’s suggested retail price does not correlate to what is actually included with the solution. Commercial tool prices range from $500 to well over $20,000 for a single license for a single year. These prices may then be reduced to approximately 30 to 40 percent for yearly updates. Keeping up with the technology of mobile device forensics is costly, but with wise research on the tools for your mobile forensic toolbox, you can justify the expensiveness of some tools. The astronomical prices of some software solutions on the market are often attributed to the fact that these companies think the money they’ve invested in research should be passed on to the consumer. Because of the pricing disparity and the variety of technologies available, it is extremely important that you conduct diligent research on each tool prior to purchase.

If some examinations and collections will be conducted by first responders or persons who have not been formally trained on forensic practices for the collection of digital evidence, it is important that you look at the tool’s ease of use along with how it maintains forensic integrity. Does the tool enable those who are not technologically savvy to perform the steps necessary to recover the required digital data from a mobile device? Maintaining forensic integrity requires a tool that packages the collected data in a format that probably cannot be tampered with or altered. This is typically completed by the software in the form of hashing. Hashing of the overall data in its current form can help to fingerprint the data collected, but not all solutions hash the data in the same way or in the same format.

In the National Software Reference Library (NSRL), NIST describes hashing as a mathematical technique used to produce a unique signature of a file. Hashing a file involves a one-way computation when the file has been compressed to a fixed length of 0’s and 1’s into a single string. A unique number is created based upon the mathematical computation and is often referred to as the digital fingerprint of the file. If even a single 0 or 1 is changed within the file, the entire digital fingerprint will change.

The way and format in which the software hashes data can be very important. If the software simply hashes the extracted personal data (such as Short Message Service [SMS], contacts, or call logs) after it has been extracted into a Microsoft Excel spreadsheet, it is doubtful that this hash can be verified using another solution. If the secondary solution extracts the same data, but this solution hashes the file in which the data actually exists, the hash could be entirely different. It would make sense that additional metadata would also be in the overall file where the data had been extracted, which would create an entirely different hash.

Extracting the physical files, hashing them, and producing an overall hash value of the entire collection contained in a single file would be the best method. With this method, all the collected data is contained within a single file, and if any portion of the file is altered, the fact that the overall hash has changed could be immediately identified. Also, to check the integrity of an individual file, the container could be opened and each file’s hash could be rehashed to show that the file had not been tampered with since first being collected. To verify the reliability of the collected data, each collection and subsequent analysis must be repeatable. Having tools that will allow for the creation of digital fingerprints, or hashes, of the files and overall container should be a priority when you choose a mobile forensic solution.

What types of mobile examinations are going to occur? Will you examine the actual collected device or the backup, or both? These are important questions to consider when you’re selecting a mobile forensic solution, especially if only backups are going to be analyzed. Choosing a software solution that covers the collection of the mobile device when the target is always going to be a device backup obtained from a PC or network server would be frivolous and unneeded. Understand the target of the examination when you’re making a determination of the types of solutions to fill your mobile forensic toolbox.

You should also look for software solutions that include support of current technologies. Look for solutions that offer the greatest support for not only the collection of data but also for superior analysis of the underlying structures. Today’s devices contain storage databases and configuration files that are loaded with digital information that is often overlooked by software solutions. Choose a tool that can not only collect but also digest and analyze the critical files found within the newest smart devices.

Remember that different parts of the world use different types of devices, different parts of a geographic region use different types of devices, and different areas of a company or agency use different types of devices. Tailor your mobile solution toolbox to the devices and, more importantly, the types of devices that are appropriate to your area. If a region deals with Nokia legacy devices exclusively or BlackBerry devices exclusively, don’t choose a tool that specializes in iOS or Android devices. If you’re conducting examinations in Europe, don’t purchase a tool that is most appropriate for Code Division Multiple Access (CDMA) mobile devices, which are used primarily in the United States and in some Asian countries.

Consider the following facts as you determine the best tool to use in examinations of today’s mobile devices:

•  More than 58 percent of users globally in 2017 used a smart device.

•  In North America in 2017, most forensic labs deal with Android and iOS devices in almost 96 percent of their digital investigations.

Supporting global mobile device statistics should not influence your decision as to what type of mobile forensic software you select if these statistics are not consistent with what you will deal with locally.

Using the multiple-tool approach can be limited at the analysis phase simply because various software products do not allow for the analysis of another tool’s data. Make sure that the software you use to conduct data analysis can import various types of mobile device data from multiple tools. The ability to import multiple image types will allow for validation of the collected data and will also provide a complement to another tool. This feature will help you uncover even more information that may have been missed by another tool.

Finally, one thing that should not influence your decision for a competent mobile forensic solution is the fact “everyone is using it.” Just because software is popular does not necessarily mean the software will be useful to all examinations in all regions. Carefully consider and investigate all facets pertaining to a localized tool set. Research the type of software and its features, interoperability, and forensic implications before making a decision as to the software that you will use for mobile device examinations. Most companies allow demonstration copies to be evaluated prior to the purchase of the software; this can be a good way to determine whether the software is right for you before you purchase.

After you’ve gathered forensic tools, you must properly assess them and learn to use them before conducting a live investigation. Learn about the software’s operating functions, features, and limitations. Consider and seek out training on the software, which is often provided by competent companies. Without undergoing training on the tools you will use, you may end up using them in less-than-optimal ways. Moreover, because technology changes quickly, what was once a current method for conducting a collection may no longer be valid.

Technology changes quickly. For example, “long ago” in mobile forensics, when Apple changed the processor in its iOS devices from an A4 (S5L8930X) to an A5 (S5L8940) chip, it was no longer possible to create a physical image of the iOS device. The exploit that had been used for devices with A4 and older chips was not valid for new iOS devices containing the newer chips. This is still de facto in mobile forensics of iOS devices today.

Analyzing Several Devices Collectively

When you’re dealing with many devices and collective evidence, keep in mind that some mobile forensic tools do not allow the analysis of more than one device image or different types of media (such as computers and mass storage devices) concurrently. In these instances, you may find it better to use a conventional computer forensic solution for detailed analysis. This might not be the best conclusion, however, based upon some available mobile forensic tools. Many mobile forensic tools such as Oxygen Forensic Detective, MSAB XRY, and Cellebrite UFED 4PC can collectively analyze multiple mobile devices and mass storage devices, drones, and cloud data in a single case.

Oxygen Forensic Detective can uniquely analyze data from all aforementioned stores across multiple cases within a database. This type of feature analysis will enable you to examine all digital information and multiple devices simultaneously, which provides a very big picture of the collected evidence. Using different types of software (such as computer forensic), not just different types of mobile forensic software, can help you paint a collective picture of the events. More and more mobile devices are becoming mini computers with extended memory, storage, and capabilities. Also, more investigations of a single event will contain multiple pieces of digital devices, so the ability to analyze all of the data collectively and in a single platform will provide digital evidence synergy. Looking for a mobile forensic solution that offers a “big view” of collective data across devices will offer fantastic results!

Verifying and Validating Software

After you have determined which software to purchase and received training to use it, but prior to your first examination, you must verify and validate that the software performs as you expect. A lot of software vendors will explain exactly how the software should perform, but ultimately it comes down to how the software actually performs within the environment in which the examiner will be operating.

Verification and validation are often used synonymously in digital forensics, but they are two separate processes used in different situations to test a software solution against a predefined set of knowns. International Organization for Standardization (ISO) 9001:2015 outlines quality management system standards and defines both verification and validation separately. In both definitions, objective evidence is used, which ISO 9001:2015 defines as “data supporting the existence or verity of something.”

•  Verification   Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled.

•  Validation   Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled.

In other words, verification consists of determining, through testing and examining specific tasks or data, whether the specified performance of a tool is met satisfactorily. Validation, on the other hand, involves determining through testing that a tool, when used in a certain way, performs as intended.

Applying the concepts of verification and validation within the context of mobile forensic examinations is similar. Verification typically can be performed using a single software solution and observing whether the data that is reported matches what is stated in the guidelines and documents regarding the software. Validation typically involves using multiple tools to show whether or not the initial tool has altered the original evidence while performing a collection as defined by the software manufacturer.

Both verification and validation techniques, along with the results, can be used in other atypical ways. Sometimes these techniques can be used to determine a difference in a control sample, which could indicate compromise, while other methods might be used to determine data integrity compromise. Important to understand is that reliance on what a product developer states should be the output is not as important as what the examiner determines using a baseline. The only way to complete this task is by verification and validation of the software solutions in the forensic toolbox.

These baselines should be performed using the same reference device(s) when the software is first installed and configured and also after each major update.

Establishing Baselines

In science parlance, a baseline is a point, or a reference point, at which the experiment will be measured. Once a baseline reference point is made, any and all other experiments can be measured against the baseline to determine what changes have occurred. A baseline will shift only if it is created using a different medium, which would create an entirely different reference point.

In mobile device forensics, the creation of a baseline will allow for the verification and validation of the software. By having a reference point, the examiner can quickly identify any changes that have been made by the software to the recoverable data from the mobile device, by the mobile device operating system, or even by malicious infiltration of malware or unauthorized entities.

How the baseline is created will depend upon the desired result—verification of data changes or validation of the software. If the desired result is to identify the various data that is collected from the baseline device after changes in version, versus what the product literature indicates it will collect, a single method should be used. If the desired outcome is to determine whether user data has been altered by a forensic tool or by hostile programs or actors, another baseline should be used.

Creating a Baseline Image for Data Verification

When creating a baseline for data verification, your objective is to determine whether collected user data from the mobile device has been altered between updates to a forensic software solution or if data has been added or deleted by malicious, accidental, or hostile means. As indicated, baseline devices should be purchased and populated with data and will be used only for verification of collected data from a mobile forensic solution. If the objective of the baseline is to determine hostile, accidental, or malicious intent, the actual suspected device will need to be collected to create the baseline. Both software verification and device integrity verification should be covered. Pay specific attention to how a baseline is taken, compared, and examined for both types of device verification.

“Hostile intent” could mean the installation of software to monitor the device, such as a rogue application or service, and “malicious intent” could indicate the installation of an application intended to destroy data.

Software Verification   Software verification involves examining the data of a prepopulated device with the forensic software solution that will be used to perform mobile device examinations. Save the collected data in a format that can be easily analyzed and compared side-by-side to a secondary extraction. This comparison extraction should occur upon any minor and major updates to the forensic software used for examinations. The simple comparison collection should consist of all of the current user data capabilities supported by the software and should be a query of only the logical data contained on the device, not a physical collection.

A “logical collection,” in the context of a baseline, consists typically of only data that can be accessible by simple communication techniques; a “physical collection” uses more advanced communication that yields entire partitions from a device.

Once data has been prepopulated on the mobile device, the exemplar devices must not be altered after the baseline is created and not until the comparison collection is completed. By using this method, the examiner can determine whether changes have been made during the various updates to the forensic software to verify that the data collected is consistent with data that is within the baseline and to identify any variations to the output. Changes to software occur frequently, and using this method will assist the examiner in determining quickly whether the software conforms to the expectations of a similar collection.

Changes or differences to the collected data can be attributed to the addition of new scoped data artifacts, new capabilities, and alterations to data within an already scoped data set. An example of each of these changes is described next, along with recommendations for each when encountered:

•  New scoped data artifacts   These artifacts are additions to already defined data. This could include the addition of a status to an SMS message indicating a read or an unread message that was not indicated in the previous version, the addition of a work phone number to the contacts table, or the read date in a calendar entry. This should be documented and verified to ensure that the new addition is correct for the exemplar device. If new scoped data artifacts are located, an entirely new baseline should be created after the completion of the verification cycle.

•  New capabilities   These would include an entirely new set of data that was not in the previous release, such as the addition of memos or user applications when the previous forensic software version did not collect this app data. This addition should be documented, and each artifact in each category should be analyzed to ensure that the data conforms to the expected values. A new baseline should be created after the completion of the verification cycle.

•  Alterations to data within an already scoped data set   This alteration occurs to a value that existed previously in an earlier release. Because the actual value of the data has changed, the examiner must research whether the previous value provided by the software was incorrect or the release being evaluated is incorrect. This change is the most important to document and to understand because it can have the biggest impact on the software verification cycle. If you determine that the value was corrected in the software from a previous release, make sure the software company has documented this on release notes. A new baseline should be created using the new version after the verification process has been completed and all changes documented. If the value in the software that is being verified had been correct in previous versions and is now incorrect, immediately notify the software vendor of the inconsistencies. Then document this information and do not create a new baseline.

The baseline comparison method can be tedious. Because of the manual process involved in determining new capabilities and additional artifacts within each capability, it is important that you clearly document data contained on the exemplar devices. To obtain the needed baseline information, you should first export the logical data by data type. Then export each data type to a format that can allow for easy comparison by their hash values. If the hash value of the files is the same, then there is no additional change in values or capabilities. If the hash values do not match, this could indicate a change, and those files will have to be manually inspected to determine the changes that have occurred. If a change has occurred, create a new baseline, and the changes in the forensic software should be updated and verified in the release documentation.

Verification Workflow Example   Following is the workflow for the verification of software. The tools used in this exercise are not the only tools available to accomplish this task. Mobile forensics tools such as Cellebrite UFED Physical Analyzer, MSAB XRY, Magnet AXIOM, and Oxygen Forensic Detective can all export collected data in various formats. The following procedure can be used with any of the mobile forensic tools that will allow collected data to be individually exported into single files.

For this example, the tools used are Oxygen Forensic Detective and hashdeep. Using Oxygen Forensic Detective, selected capabilities from the baseline image are exported into an Excel .xls file (see Figure 7-1). (Note that Oxygen Forensic Detective will also be discussed in Chapter 8.) Hashdeep is a free program that computes multiple types of hashes against a set of folders, files, and subfolders. It can also be used to compare a known set of values in a text file against a set of files, folders, or subfolders when performing an audit. Hashdeep was developed by Jesse Kornblum and can be downloaded from http://sourceforge.net. It is maintained at https://github.com/jessek/hashdeep.

FIGURE 7-1 Oxygen Forensic Detective exports data into an Excel .xls file.

This exercise involves comparing a baseline created with a previous version of Oxygen Forensic Detective with the current version of the software (10.1.0.54). This comparison uses the hashes created from exported files in an effort to identify changes immediately within the files. If a change is encountered, we will determine whether the change falls into the three categories discussed:

•  New scoped data artifacts

•  New capabilities

•  Alterations to data within an already scoped data set

First, we export the data into a folder and, from the Windows command prompt, hash the contents using hashdeep with the following instructions:

C:md5deep>hashdeep64 -c md5,sha1,sha256 -b C:BaseLine-TESTING*

The format for the command contains a call to the executable (hashdeep64), a flag (-c) to enable comma-separated output, the hash formats, a flag (-b) to enable bare mode and show only filenames of hashed files, and then the path to the folder with the files that will be hashed.

The result shows the hashdeep dialog, the result format, and the string used to invoke the application and the hashes:

The result, including the hashdeep dialog, is then saved to the file baseLine-knowns.txt. This file can be used to determine any differences in any image that will be obtained with the newer version of Oxygen Forensic Detective so that the values can be compared to ascertain whether changes have been made to the mobile device data’s output.

Using Oxygen Forensic Detective 10.1.0.54, we make another collection on the exemplar device when an update is sent out to users. The capabilities are all exported to another .xls file (see Figure 7-2).

FIGURE 7-2 The second export of the same exemplar device after an acquisition with new version of Oxygen Forensic Detective

From the Windows command prompt, we use hashdeep again to compare the hashes to show those that match and those that do not match in the baseline hash file baseLine-knowns.txt. This command determines whether any files are the same based upon hashes, by using the -m and -k flags. The -m flag specifies that hashdeep should show only the files within the baseline that match the hashes that are within the file identified with the -k flag. It returns no matches, which indicates that all the files are different between releases of the forensic software:

C:md5deep>hashdeep64 -m -k baseLine-knowns.txt
C:BaseLine-TESTING*

To identify which files are different based upon the known file hashes, we run another command using the -x and -k flags. The -x flag will identify which files within the baseline are different, and the -k flag identifies the file of known values. If files are returned, they can then be manually compared to the known files.

Several hash values have changed, and those files must be examined to determine the differences. This will help us differentiate between the types of changes that have occurred between releases in order to verify the forensic solution. The changes that are observed in Oxygen Forensic Detective has to do with new parsing algorithms for the WebKit data, new search terms used by the examiner, and additional watch list terms. Figure 7-3 shows several changes between versions of AccessData’s MPE+. The large difference was a direct result of the manufacturer changing the application that queries an Android device. This information would not be known if it were not for the verification of the software. The image in Figure 7-3 depicts an additional column of data that indicates whether the SMS message has been seen or read, and also changes the format from local time to UTC time, which are both listed in the Sent column.

FIGURE 7-3 Using Microsoft Excel, both .csv files from MPE+ 5.0 and 5.5.5 are compared, showing various differences.

If any changes between the baseline and the secondary comparison image are detected, a new baseline should be created. In this example, a new image was created with MPE+ 5.5.5, and the files are all hashed. A subsequent extraction was completed with version 5.5.6 and the results compared using the steps previously covered with hashdeep. Here is the process with the new version:

Using the -m switch this time identifies all files that match within the original data set and the new version:

To confirm, we check to see if any files do not match by using the -x switch. This command does not return any files:

The result indicates that the new baseline files in MPE+ 5.5.5 are identical to the secondary image created with MPE+ 5.5.6. This proves that no changes were made to the extraction method and additional software capabilities have not been added between releases.

Device Integrity Verification   The baseline steps involved in the verification of the software differ from the steps used for verification of changes to a device. The device integrity verification process does not determine whether the forensic software has made a change, but whether the device has been compromised.

Many global companies rely on mobile devices to keep their employees in touch with one another, to allow work to be completed remotely, and to keep production up—no matter where employees are located. An employee who is constantly tethered to a mobile device can instantly access files, documents, e-mail, and any other type of electronic data. With this mobility comes the price of data security, however. When you are confronted with the possibility of device compromise, you can take steps to ensure that the compromise can be recognized. You can create a baseline of the mobile device prior to its being deployed in an area where data could be compromised and later examined. This verification can identify malicious applications, injection of foreign data, and other types of espionage.

To complete this process, you must create a baseline of the device just prior to the journey. Of course, data will change in the course of the deployment, simply because the user will be using the device. But by creating a baseline for the device and its contents, you can quickly dissect information to determine whether anything has been compromised on the device. Once the device is obtained, a physical data collection should be completed. If a physical data collection cannot occur, for example, on a new iOS device, a full file system collection along with application files should be obtained. The files are needed in this type of verification because the addition or deletion of files that had previously existed or had not existed will be key to the process.

Not all mobile forensic software can complete this process, but software such as Cellebrite UFED 4PC and UFED Touch Ultimate, MSAB XRY, and Oxygen Forensic Detective can create an image that can later be used to conduct a baseline analysis on most smart devices.

Once you have created a baseline for the device partition or file system, you must make an image of the device data along with hashing and indexing all the files within the created baseline image. Indexing involves categorizing, listing, filtering, and sometimes formatting the data to make it easy to search. Once all of the files in the collected image have been hashed and indexed to create each file’s unique digital fingerprint, you create a custom dictionary, a list that contains all the file metadata along with the hash of each file in the image. Your forensic software should be able to create a dictionary containing all of the file hashes within the baseline image. Then save this dictionary along with the device baseline image to sort the known files against unknown files or alert files contained within the comparison device image once the device is back from the deployment.

This technique is typically used by companies that are operating in different countries and by military employees or contractors. The following example information was culled from the employee travel policy of a major gas company. This policy requires that the security team take a baseline of the contents of the device and create an indexed list of the contents, which can be later compared to the contents of the device immediately when the device is returned:

Immediately prior to the travel the mobile device designated to be used shall be forensically imaged by the device security team. The image that is created of the mobile device will be indexed and stored. …Upon return, the device will be immediately forensically imaged using the same technique used to create the baseline. The baseline dictionary will be imported and any delta analyzed immediately. Should the delta be identified as a security risk as defined in…the device should be removed from service and further response from the designated security team will be elevated based upon the reported compromise.

In today’s world, entire company networks can be infiltrated with a simple rogue malicious app embedded on a user’s mobile device. This technique should not be limited to travel policies, but can also be used to create a baseline of a device upon distribution to employees. If an employee is terminated, accepts a job from a competitor, or is subject to an investigation, the device data can immediately be compared to the baseline that was created when the device was distributed at hiring.

Using the following process, a device’s integrity from a snapshot was examined to determine compromise, data changes, and malfeasance.

First, the images were collected using a Cellebrite UFED Touch device and then examined in AccessData Forensic Toolkit (FTK), as shown in Figure 7-4. FTK is a computer forensic product with built-in functionality for comparing known values that enables the examiner to flag files that match and do not match a known set of hashes.

FIGURE 7-4 A physical image of the device partitions for an Android are imported as evidence into FTK.

X-Ways Forensics software can also create a set of hashes that can be used against an image created and exported by a mobile forensic tool. EnCase Forensic from Guidance Software can also allow for a set of hashes to be exported and then added to a hash database within the product. EnScripts are also available and can be used within EnCase to enable the examiner to export all files that either match or do not match a known hash within the hash library.

Next, a complete file list was created that contains all of the file hash values, which can be stored in a file and imported into a file database of known file hashes—in FTK, this is called the Known File Filter (KFF). The KFF stored the file hashes and used them to discern the known files from the unknown files when a second image of the device was created and imported into FTK. With this information, the examiner quickly identified which files had been altered and immediately began the examination into the cause of the change to the files.

After the baseline was created, the device was taken outside of the country for approximately three days, where it was used on various networks. The following process was used to determine whether data was altered while the device was out of the country.

1.  A file list was created (by choosing File | Export File List Info, as shown in Figure 7-5) with the added evidence using the function within FTK to export file list information. Once exported, it was saved to a .csv file, which was modified to contain only the MD5, SHA-1, and SHA-256 columns.

FIGURE 7-5 Using FTK to export a file list to a .csv file

2.  This created a listing of 52,456 file hashes. The hashes were exported and modified, and then the user imported them into a file list to be used by FTK’s KFF. (This file list can also be used in other tools such as EnCase and X-Ways Forensics.)

3.  A secondary image of the same device was collected using the same software—in this case, Cellebrite UFED Touch. The same partitions used to create the known hashes were used—the userdata partition and the dbdata partition from a Samsung Fascinate. These partitions were again added as evidence into the FTK case.

4.  The evidence was processed. Once complete, using the Filter Manager, all files that were identified as KFF Ignorable could be hidden. (KFF Ignorable equates to the files that are identical in hash from the baseline list.) After the files were hidden, only the files that were altered or created sometime after creating the baseline image were shown.

In this exercise, the baseline image contained 52,456 files, and all were hashed, creating a list that could be used to narrow down the number of files that needed to be examined to 64. The 64 files were examined for signs of malware or illegal access. The results were negative.

This technique can prove very valuable to a company’s security. Using a mobile forensic tool first to collect the baseline image and then analyze with another tool that typically is used for computer forensics can be the only options when performing a similar device integrity verification exercise. Mobile forensic tools currently do not offer the examiner an option to filter user-defined values immediately, but computer forensic solutions such as FTK, EnCase, and X-Ways do offer this useful baselining feature.

Validating a Mobile Forensic Tool Using a Baseline

To validate a mobile forensic tool, you must first recognize that a second mobile forensic tool will be needed to perform this correctly. A single solution cannot be validated against itself, and if only a single solution is being used to perform all of the mobile forensic duties, then using the verification processes outlined previously will suffice.

To perform a proper validation of the software, you must employ a device that is used only as a mobile device baseline exemplar. Using actual evidence to perform the testing could pose problems should the software being validated fail testing. Having device exemplars of the most prevalent devices that are examined in the region will be the best use of the validation principles.

The object of the validation is to determine whether the software is modifying the device data upon extraction. It’s important to understand that data on a mobile device will invariably change because communication continually interfaces with an active mobile device. By using one mobile device forensic application to create the baseline, you can use another application to test for possible data corruption. Perform these tests before using any mobile forensic software in an examination and also upon each major release update.

As you know, a mobile device cannot be inhibited from being written to simply by employing a typical write-protection device. Furthermore, mobile forensics software interfaces with the device via protocols used to debug, back up, query, and manipulate the data on the device, changing the data in some way. Also, because the device is powered on, working processes such as system maintenance, system clocks, and other processes will continue to operate. It is important that you not get caught up in the changes to the various system processes but focus on the user data and user applications on the device.

To perform the validation of the software, you must collect a physical or file system image. Simply collecting the logical user data will not allow you to correlate and compare the two tools. You should also use an intermediary tool, as described earlier in the verification of software data. This tool should allow for the indexing, categorization, and hashing of each file in the mobile device partition or file system, similar to what was discussed earlier in the chapter. Then you can use this information to create a baseline dictionary of files, using their hashes, which existed on the mobile device at the time of collection. Next, you use the validated tool on the exemplar mobile device to conduct a logical extraction, selecting all capabilities that are supported for a forensic extraction. At the conclusion of the data collection on the mobile device, reacquire the mobile device with the initial mobile forensic software and recollect physical or file system data. It is important that you perform the same type of collection you used during the first extraction. You can compare this image to the initial data collection by using the dictionary created with the baseline data collection. If data has been added, deleted, or modified by the tool being validated, these files will be immediately identified upon completion of the dictionary comparison.

You must examine each file that diverges from the baseline image. These will undoubtedly include system files, which will commonly change because of the active state, and software protocols and changes the examiner may have made to complete a data collection of the device (such as placing an Android device into Android Debugging Bridge mode). Any files that contain user data should be scoured. The forensic software should not alter content in files that contain user data, such as SMS, contacts, call logs, browsing history, user applications, and so on.

If you determine that the mobile forensic software has modified a critical piece of user data, you must further examine the file to determine if the integrity of the user data has been compromised. At times, forensic software can alter a file’s metadata during the extraction, which could change the overall hash value, but the data contained within the file has not been altered. If this is the case, although the user data has not been compromised, you should have a clear understanding as to why the file metadata was changed. If at any time you determine that the user data other than the metadata contained within the file has been altered, notify the forensic software company and discontinue use of the software until it is updated to address the problem.

Validation Workflow Example   The following example shows a complete workflow using several products to address this type of software validation. This workflow was completed using Cellebrite UFED Touch, FTK, and Oxygen Forensic Detective.

1.  Using the technique described earlier in the section “Device Integrity Verification,” we created an image using a single forensic solution—in this case, Oxygen Forensic Detective. This was the baseline image—a physical image or image that contains a device file system.

2.  We created a hash list of the files using FTK, as outlined earlier.

3.  Using the software to be validated (UFED Touch) and the same device on which the baseline was just created, we conducted a full extraction of the device (this could be logically or physically or both).

4.  After the collection was completed by the UFED Touch of the exemplar device, we performed another collection using Oxygen Forensic Detective, as with the initial baseline in step 1.

5.  We compared the files obtained from the collection by UFED Touch in step 4 to the hashes obtained in step 2 in FTK.

6.  We analyzed any files that were different as identified by the hash to determine whether they were a system file or a file that contained user data, which could have been altered by the software being validated. If any new files were identified that were not in the baseline image, we closely inspected the files to identify whether they were collected from the device or added by the software. The software should never add a file that was not extracted from the mobile device. If this occurs, the software should not be used until verified by the vendor software developer.

In this example, the UFED Touch did not add files upon the extraction, but six files showed different hash values. Inspection of the files showed they were system files, with no adverse changes to user data. This test validated the UFED Touch.

Using Multiple Tools to Your Advantage

This chapter described the ways that you can use one software application to complement another for verification and validation. Using multiple tools to perform this very important task is essential to ensure the validity of each data collection event and of the overall investigation. Using multiple tools is not just for verification and validation, however, but also for the actual analysis of data. This analysis typically cannot be performed using a single solution for many of the reasons already discussed, and most in the industry agree that there is no single solution that will perform every function an examiner will request or want.

The ultimate goal of any digital investigation should be to uncover and make visible all data available on the device should that data be desired during an investigation. If the data exists on the device and it can be recovered, that data should be presented in some way for further analysis. Simply using a single tool will not suffice because of the inherent limitations known to exist in every mobile forensic solution. In many cases, digital artifacts are easily seen in the data within the forensic tool, but the information cannot be visualized into a report or clearly represented in a way that could be discernible to an average observer. Using a secondary tool to support the analysis and display of the data in a form that can be evaluated and used to convey the investigative message is the ultimate goal of any digital investigation. The actual case example described in the sidebar shows the value in this type of collective tool analysis.

The use of a single solution to handle all mobile devices and contingencies is something that most software vendors realize is not possible. Most practitioners also understand this and believe that more than one tool is needed, as indicated in the case study. What can be clearly observed, however, is that very few examiners actually use multiple tools.

Why is there no single solution that can cover every contingency? The many reasons involve too many mobile devices, too many mobile applications, lack of a specific analysis feature, missing analysis of a specific application, or lack of support for a specific file type. The reasons are many, the solutions are few, but what is clear is that no single tool can rule them all. For this reason, the word that should be used in mobile forensics is complementing. To complement one another is to “bring to perfection,” as described in one definition of the verb. When you use a secondary tool to perform analysis of data that works differently from the imaging tool, the solutions truly complement one another and the investigation profits.

As outlined in the actual law enforcement case, the use of multiple tools can be a game changer. Adhering to the philosophy that a single tool is all that’s needed is a recipe for disaster.

Dealing with Challenges

Most challenges to the examination of a mobile device will not come from what was collected from the device, but from how the data was collected. Also challenged will be the software used to collect the data. Questions abound about whether the tool wrote data to the device, whether the tool deleted data from the device, and whether the tool merged data from the previous collection into the current device’s data. Also, a lot of challenges can come from questions about the inability of one tool to do one thing while another tool can accomplish the task.

Understanding the many ways in which the processes described in this chapter can be challenged will help you prepare for better examination techniques and for handling these common objections in court. What is quite evident when observing most individuals conducting mobile forensic exams is the fact that few examiners comprehend how important these challenges can be to their cases. Moreover, some current examiners believe that multiple tools are only for validation of the tools and fail to recognize that using multiple tools increases the chance of uncovering additional data from the device.

Overcoming challenges in verification and validation, along with the use of both single-tool and multiple-tool examinations, will forever be challenged.

Overcoming Challenges by Verification and Validation

The reasoning for conducting verification and validation of mobile forensic software is simple: to overcome a challenge before being challenged. Software is created by a software engineer who is a human being, and human beings can make mistakes. Software code is developed to do one thing, but it sometimes does another. Relying on what a software company has stated regarding how a tool should perform is not good practice. It’s the responsibility of the examiner to maintain and test any software to be used in the forensic lab or in the field to perform digital data collections and analysis from mobile devices.

When it comes to explaining the various reasons behind the verification and validation of tools in the lab, an examiner must be prepared to support each challenge when presented. If an examiner cannot support the reasoning behind tool verification and validation with credible data, the collection and analysis of a mobile device should not be completed or even initiated.

There are various challenges to performing a proper baseline that mobile forensic tools can stifle. The greatest challenge is typically regarding how the integrity of the device was compromised due to the intrusive methods in the collection of the digital data from the device.

Some claim that mobile forensic software can change, alter, and modify data on the device. Mobile devices typically have their data collected while they are powered on, so data can change even without software interaction. When a device is powered on, its operating system is constantly changing its system files, just as a computer does. The device will update directories and index files and will allocate memory and monitor the system clock. This even occurs when the device is isolated 100 percent from all network sources.

When testing a forensic application by creating a baseline, you can show that no user data was altered in the collection and subsequent analysis of the data. In baseline verification and validation testing of the software used in the analysis, you can show that no user data was altered, changed, or modified. Based upon the testing of the software and passing results, you can conclude that during the digital forensic investigation, the software performed as described and did not alter, modify, or change the user data as represented in the case.

Typical mobile device collections are conducted via a USB cable connected to a computer and to the mobile device. Using device and manufacturer protocols that are unlike any other digital device collection methods, communication occurs between the software and the device. Unorthodox methods such as using protocols to initiate a data backup of the device, installing a small program and initiating the program to query the device’s internal user data repositories, and placing a custom partition on a device to allow for the bypass of security are a few methods used in mobile forensic software. These methods do not alter, modify, or change the user data as determined by the baseline testing conducted using the mobile forensic software.

Overcoming Challenges for Single- and Multiple-Tool Examinations

Another, more personal, challenge can come in the form of an attack of the credibility of the examiner who conducted the collection and examination. Any change from the expected results is said to be caused by a lack of training of the examiner or the improper type of training received, along with the forensic tool used.

Training is necessary to mitigate challenges of the improper use of the forensic software or any device used in the forensic examination of the mobile device. Being certified in the forensic software is not essential to conduct an examination using it, but a certificate can show the examiner’s competence to perform collection and analysis of the mobile device. Becoming well acquainted with all of the software that is currently in the mobile forensic toolbox can occur only with proper research, usage, and ultimately training.

Single-Tool Challenges

In many instances, even if the examiner has more than one tool available, he or she will use a single tool from the start to the finish of the examination. This tool will be used to collect the data from the mobile device, create an image, analyze the data, and create a report. This scenario, more times than not, is the norm. Sometimes an examiner has only one mobile forensic tool in his or her arsenal because of budget issues or for other reasons. In any case, the challenge often cited is that data output cannot be verified using the same tool that created the first forensic collection. This is primarily because an anomaly in the software’s collection of data from a mobile device would, in theory, exist each time the collection was performed on an exemplar device, showing no difference.

If the lab has multiple tools, then using a single solution from start to finish can be justified so long as the verification and validation have occurred as outlined previously. What becomes critical when only a single solution is available will be the validation, testing, and identification that no user data was altered over subsequent extractions of a testing device. You must conduct the baseline testing as documented earlier and cover the steps on baselining devices when device integrity is required.

If only a single tool is available for the collection and analysis of data, the examiner should be diligent in every aspect of the examination. Verification of the data must typically be managed by visual verification on the actual exemplar device during verification testing. Challenges to “missing” data that is recoverable with another tool can also occur when using a single solution. When data is missed and consequently critical to the opposing counsel, the examiner who was not able to recover this critical piece is often questioned as to why this data was not disclosed, which questions the credibility of the examiner.

Dealing with this type of challenge involves simply explaining that all software is not created equally, with some having very robust analysis features while others simply report on limited data. In this instance, the software that was used has limited analysis features and does not support the recovery of the indicated information; ergo, the data was not located.

Multiple-Tool Challenges

When you use multiple mobile forensic products for a single device collection, various challenges can involve how the image was created, whether the integrity of the image was maintained, and whether changes were made to the actual data within the case. To overcome these challenges, you can follow several key investigative techniques.

To avoid problems with a challenge to the creation of the image and its integrity, use only one piece of software to create the data image of the mobile device. It is extremely important that you make every effort to extract the mobile device data only once from the evidentiary device. The more times that a device is hooked up to a computer, queried, extracted, and accessed, the more likely corruption will eventually occur. Sometimes collecting the digital data from a mobile device more than once is unavoidable—for example, when the device data is extracted at a scene and then again at the forensic lab. In these cases, to avoid a challenge, make sure you examine and compare the first extraction data to that of the second collection. If you note a difference in the data collected, clearly document all of the changes and the reason the data has changed. If proper procedures have been followed to isolate the device from network connections, the second collection should not contain additional user personal information, but should this occur, provide additional documentation stating how this information was written to the device. Such changes to data will undoubtedly be used later to discredit the data on the device and examination.

Also, challenges can be made against the integrity of the evidence by using a secondary tool when the secondary tool can import and analyze another tool’s created mobile device image. It becomes very important that when you create an image with mobile device software, you also create an overall hash value of digital data collected. Most mobile forensic software applications create an overall hash of the evidence image, but for those that do not, the examiner should use a third-party tool that will create a hash value. Several free file hash software applications are available online and can be downloaded to perform this task.

If you’re using an online software application, it is important that you create a text file that can be associated with the image file that contains the hash value, the date the hash was created, the person who hashed the file, and the software that was used to create the hash. With this information, if needed, a second person can duplicate the steps to validate the image as well. Once the hash value is obtained, it will be used at the conclusion of the examination to verify the integrity of the image after a secondary tool has been used to analyze the primary tool image. Some software titles will actually verify the image’s hash upon import, and if it is not identical from the hash obtained at the creation of the image, the user will be immediately notified. Other applications, such as AccessData FTK Imager (Figure 7-6), can run a function to verify the integrity of images created by AccessData products. This hash, as shown in Figure 7-7, can then be used to compare against the image when requested at any time during the evidence life cycle.

FIGURE 7-6 Using AccessData FTK Imager, import the created image, right-click the device name, and select Verify Drive/Image.

FIGURE 7-7 The image will be tested and hashed and compared to the hash that was created when the image was made.

When using a secondary tool to analyze a primary tool’s image, make a copy of the actual evidence and analyze the copy of the image using the secondary tool.

Challenges when using multiple tools can also arise when a feature that is used to analyze data runs scripted code within the interface against the collected mobile device evidence. Scripted code could include code written in Python, C#, EnScript, or others. By using these features, the examiner can interact directly with the evidence; it is extremely important that you take steps to validate that changes are not being made to the actual evidence.

To overcome this challenge, test each feature that can act upon evidence with user-generated scripts. To test, create a simple rehash of the evidence containers after the use of the customized feature. If there is a difference in the hash values before and after running a script, you must document and research the issue to identify where the failure occurred and if the evidence was tainted. If the hashes match, as they should, after running the custom scripts, you should also document this so that if you’re challenged, you can provide specific information regarding the testing completed to verify the function and image integrity testing.

When conducting any type of analysis, all work should be done on a copy of the actual evidence file. Evidence should not be used for testing or baselining purposes.

Chapter Summary

Data integrity is at the heart of a forensic examination. Maintaining confidence in the resulting output of a mobile forensic collection is critical. To do this, the examiner must be confident in the mobile forensic tools that are being used to perform the data collection and examination. By performing frequent verification and validation techniques, the examiner can be confident that his or her examinations will hold up when challenged. A great by-product of rigorous testing of the forensic tools in a lab will be tool knowledge. Expanding the examiner’s knowledge of the tool from a traditional training curriculum or “I read the manual and web site” track with intimate hands-on work will not only benefit in court, but also in work production. Examinations of mobile data will be much more detailed and pointed, and will contain information that only an examiner very knowledgeable with a product could produce. The more that a tool can be dissected, tested, and used, the better the examiner will become at using the tool, and the actual investigation will reap the benefits.

Although there are many benefits to using multiple tools for mobile device examinations, not everyone has the luxury of using more than one tool. In these cases, you should ensure that the validation process is conducted vigorously. By using a single tool, not only will the examinations be limited to a single set of features and support, but the ability to verify and validate will be much more difficult. Using a single tool to conduct mobile device investigations can be accomplished, but there will always be a bigger risk of a challenge to the operation of the software and the examiner’s methods. Also, the location of additional data could be jeopardized simply because the single tool does not support a feature, device, or data set. Selection of the mobile forensic tool, if allowed to have only one solution, is critical.

There are great benefits to using multiple tools to collect and examine mobile devices; nevertheless, with the use of multiple software applications comes risks. The many benefits range from verification and validation, to wider spectrum of device support, to the recovery of additional data by using features and controls of a secondary tool not supported by the primary tool. The risks come from the collection of the same device with different tools, ways in which tools validate the data with hashes, the inability to determine whether a tool altered the data, the integrity of the collected digital data, and the lack of correlation of the data between software applications.

Without the examiner having a firm understanding of the tools in his or her toolbox, there will always be risks. Overcoming any challenge to the collection and analysis of mobile device data comes in the form of understanding the operation of the mobile forensic software in the digital forensic toolkit.