Seizure Phase

Forensic Tools

Experimental Design

The experiment was prepared in terms of (a) activating mobile airplane mode to isolate receiving and transmission signals, (b) connecting the mobile device through a USB cable with the workstation, which is not connected to the Internet and free of malware, (c) selecting trust computer, (d) connecting iTunes for backup, (e) running Belkasoft to get backup and to load iTunes backup for analysis and comparison, and (f) running FINALMobile software to get another backup and later for analysis.

Acquisition by iTunes and Belkasoft

• iTunes backup: Create iPhone backup as shown in Figure 14-1. This backup will be analyzed forensically using Belkasoft. The backup data is stored in the following path: C:UsershpAppDataRoamingApple ComputerMobileSyncBackup

• Acquisition by Belkasoft: When doing acquisition for Apple mobile, Belkasoft offers three acquisition methods: iTunes backup; full logical backup, which requires a jailbreak; and agent backup, which is not supported for current iOS (12.5.3 for suspected iPhone). Figure 14-2 shows selecting acquire Apple mobile. In Figure 14-2 Belkasoft recognizes the iPhone after connecting the iPhone with the workstation. Figure 14-3 shows the starting backup process.

In Figure 14-2, mobile forensics examiners are required to choose whether to add an existing data source or to acquire and analyze. As shown in Figure 14-3, acquisition for mobile was selected and Apple mobile was chosen.

Figure 14-4 shows that the examiner should choose to trust this computer to activate the mobile connection to recognized mobile by Belkasoft.

For obtaining a logical image for targeted smartphones, it is not allowed to use Belkasoft without jailbreak as shown in Figure 14-5.

As shown in Figure 14-8, when choosing full logical backup, it is required for the mobile to be jailbroken.

Examination/Analysis Phase

1. Using Belkasoft

iTunes backup, which was taken by Belkasoft, is open for analysis by Belkasoft as shown in Figure 14-6.

The results show that about 107 files that were opened by the Chrome application were shown in the overview. No other information was provided in the overview, so for more details, it is important to lookup for the Chrome SQLite database. To do that, we need to move to File System, where we can locate related SQLite files as shown in Figure 14-7.

As shown in Figure 14-8, all Chrome app SQLite database files are located under the path AppDomain-com.google.chrome.os. Walk through this path looking for SQLite database files. To open any SQLite files, we can use the integrated SQLite viewer in Belkasoft as shown in Figure 14-9.

Viewing data that is stored on SQLite for sure gives more details and artifacts. SQLite file format could be .db or .sqlite3, and some files have no extension, so it is important to know that we can recognize any SQLite file according to the header of files as shown in Figure 14-9. A lot of SQLite files were found under the Chrome path. These files are a mine of data that can be used to get artifacts. Just for example, the history SQLite database file provides the history for the Chrome application, and shows the number of times each site was visited. It provides a keyword search via Chrome application and many other details.

As shown in Figure 14-10, SQLite signature offset is zero and size is 16 bytes. Another example is the “Login data” SQLite database file, which is saved by Belkasoft and viewed by SQLiteStudio as shown in Figure 14-10. This table gives other artifacts about logins signed through the Chrome application.

2. Using FINALMobile

iTunes backup was taken by iTunes and opened by the FINALMobile forensics tool, as shown in Figure 14-11.

It is clear at first glance that a program at the workspace directly displays some of the contents of the Chrome application; the display is done by the Chrome_WebHistory tap and all its contents are read directly from the history SQLite file. These tools also give us the ability to search all files manually through File Explorer as shown in Figure 14-12. We can use this feature to look for all SQLite database files.

As mentioned before, because forensic tools do not display all SQLite database files directly, searching for all files through navigating the path of desired application is extremely important to obtain the largest possible number of artifacts. FINALMobile also as Belkasoft gives us the ability for this search and also provides us with the ability to export SQLite database files to be opened later by any tool such as SqliteStudio, or we can directly open it without exporting as shown in Figure 14-13.

3. Using iBackUp

iBackup will automatically find the iTunes backup as shown in Figure 14-17, or we can simply open the backup from the desired path. After that, it is easy to view all mobile content as shown in Figure 14-14. Also, these tools give us the ability to export any file including SQLite database files; in this practical case when we use iBackup tool it’s can’t able to recognize SQLite files, as it doesn’t support hex dump to view the file header.

4. Using iExplorer

Used to view iTunes backup and gather related SQLite files, this tool gives us the ability to export any file including SQLite database files as shown in Figure 14-15. In this tool, it is not possible to recognize SQLite files if they have no extension or are without previous experience. In other words, it doesn’t support hex dump to view the file header.

Before Rooting

Using ADB Command

For everything you need, just download the Software Development Kit (SDK), which includes an integrated development environment (IDE), which is required for investigative tools like ADB and quick boot. Figure 14-18 shows the adb command to get backup -shared -all, which is used to get backup from external memory on the mobile.

The backup will be saved with .ab format. To make this backup universal format, open with different automated forensics tools; then it is required to convert it to .tar format. For that, it is essential to install the Java development kit (JDK), and then copy abe.jar to the platform-tools folder. Later we can use the command shown in Figure 14-19 to convert. ab format to .tar format. The backup.ab and backup.tar will be stored in the platform-tools folder.

Using AXIOM

Two options are available when acquiring evidence using AXIOM as shown in Figure 14-20.

ADB (Unlocked) is used when you have passcodes and patterns for the device and you can unlock it. Advanced (Lock Bypass) is used to bypass the lock screen. Figure 14-21 shows progress when choosing the ADB (Unlocked) option, which is used to acquire a quick or full image as shown in Figure 14-5, hence the full image requires the device to be rooting, and the quick image is stored as .zip format.

Figure 14-22 shows the progress of preparing the device including disconnecting and reconnecting the mobile to the workstation, installing the mobile driver, and attempting to bypass the device if it is locked. AXIOM provides two types of images: a full image, which means whole contents of the device, and a quick image.

Using Belkasoft

We can get backup using Belkasoft by:

1. a.

   Choosing “Mobile” from Acquire and analyzing and then select Android as shown in Figure 14-23.

    

1. b.

   Selecting acquisition method as shown in Figure 14-24.

    

Using FINALMobile

FINALMobile Forensics supports different platforms as shown in Figure 14-25.

To get a backup of Android using FINALMobile, we have to select the Android platform, then choose the make and model as shown in Figure 14-26.

There are two acquisition methods as shown in Figure 14-27. Both are given logical image.

Rooting

Odin3 software as shown in Figure 14-28 was used to root the mobile.

To root the mobile device using Odin3, first, we have to enable OEM to unlock as shown in Figure 14-17, turn off the mobile, and then log in to the download mode by holding and pressing power + volume down + home together until getting the warning screen, then pressing up the volume. After that, run Odin3 as administrator and connect the mobile device to the PC via USB cable; the Odin3 software will confirm the connection by showing “Added” as shown in Figure 14-29. If there is no confirmation, then there is a problem with the mobile driver and it is recommended to install the correct driver for the mobile.

Once the connection is confirmed, then locate the root file, which can be downloaded from samsungsfour.com [15] depending on the version and model, add it to Odin3 by clicking AP, select the root file, which is in the format of .tar.md5., and then choose to start rooting the device as shown in Figure 14-28.

After successfully rooting the mobile, we can get superuser (SU) privileges and access the data folder on the Android, which was limited to SU before rooting; we can do anything, such as removing files that contain passcodes or patterns, and we can get physical acquisition.

Use ADB to enter the shell and then get SU privileges after rooting the mobile as shown in Figure 14-29.

And now, let us remove password and pattern from the mobile using SU privileges and using the files containing password and pattern, which are found under /data/system, and then look for gatekeeper.password.key and gatekeeper.pattern.key. by removing these two files, as shown in Figure 14-30. Then there will be no passcode or pattern on the mobile.

After Rooting

Using Belkasoft to get a physical copy, we need to select DD backup and verify root status to continue as shown in Figure 14-31, then select the partition or all partitions to get a backup physical in which the images are logical, and then click Next to start the process of physical imaging.

After rooting the mobile, using AXIOM the full image option will be available as shown in Figure 14-32.

Examination and Analysis Phase for Android

1. Before Rooting

Analyzing the manual backup taken by adb command will be done manually by extracting backup.tar and looking for SQLite files. Then we will use SQLiteStudio to open these files. As adb doesn’t back up all installed applications, the Chrome app is one of the applications that doesn’t back up in this case. Even when using automated forensics tools such as Belkasoft, AXIOM, or FINALMobile to analyze backup.tar, it still has no data related to the Chrome app. It is still the same as ADB backup; there is no data related to the Chrome app. The artifacts that were retrieved are shown in Figure 14-33.

Analyzing a logical image using FINALMobile, as shown in Figure 14-34, shows analyzing results for the logical image that was taken as “Samsung backup” and spotted on Chrome results.

If we are looking for more artifacts, it will be necessary to look for every single SQLite file located under Chrome. To achieve that, we navigate to the File Explorer as shown in Figure 14-35.

One more thing: it is important to look at all SQLite files depending on file signature instead of looking at file extensions, as some SQLite files have no extension. Figure 14-36 shows the SQLite signature.

Analyzing Quick images using AXIOM, first we open the image by process and wait until we finish analyzing evidence. Figure 14-37 shows artifacts. No artifacts related to Chrome apps were found.

2. After Rooting

We try to find artifacts using Belkasoft and results show that no artifacts were acquired. By loading the image to the AXIOM process, and waiting until it finishes analyzing, Figure 14-38 shows artifact statistics for the full image after rooting.

As shown in Figure 14-39, analyzing full images retrieves data related to Chrome apps.

iOS

The Chrome application used in iPhone mobiles is like any other application where many artifacts can be extracted. In the conducted experiment, acquisition of SQLite manually without jailbreaking the mobile is possible if the mobile is open (no passcode or pattern is given) using iTunes, iBackup, and iExplorer to get iTunes backup. We can easily export an SQLite file and then open it with any SQLite viewer such as SQLiteStudio. Or we can use Belkasoft and FINALMobile as forensics tools to get iTunes backup and do forensics analysis using tools features or export SQLite files to be opened by SQLiteStudio.

There are many SQLite database files under Chrome path, such as history, login data, top sites, affiliation database, cookies, favicons, shortcuts, web data, and more. Just for example, th history file contains information about all browsing such as downloads, keyword_searched_items, URL, and so on. As shown in Figure 14-41, login data file contains information about all user logins, such as origin_url, password_element_username_element, and so on as shown in Figure 14-40. Topsites: contains the most visited sites through Chrome application, as shown in Figure 14-40.

All tables inside the History SQLite database files include login details through the Chrome app, and information about the top sites visited using Chrome app web browser, as shown in Figure 14-41.

Android

Many applications exist for a specific purpose; for example, the purpose of the email application is to open the email, the purpose of the Facebook application is to open Facebook, and so on. Regardless of these applications that are designed for specific purposes, Internet browsers are still used to search and open an email, Facebook, and so on. The most used Internet browser is the Chrome app. Therefore, it is always recommended to check the artifacts in Chrome and the rest of the Internet browsers, if any. Like any mobile platform, Chrome is used in Android. Using Chrome can provide a lot of artifacts. And once more, if we are looking for more artifacts, it is required to look for all SQLite database files.

There are many methods to do acquisition for Android platforms. ADB manual extraction doesn’t back up everything; for example, ADB didn’t acquire Chrome data. To get Chrome data, we have to do logical acquisition by automated tools such as FINALMobile, AXIOM, and so on. There is no need to root Android mobile for the logical image. Logical images will never provide deleted files. After analyzing the logical image with FINALMobile as shown in Figure 14-42, we get 27 artifacts.

Rooting the Android platform is used to have SU privileges to do whatever we want. Android physical acquisition required the device to be rooted. After rooting the device, we can get a physical image. After doing a full image acquisition using AXIOM, we can do analysis for the full image using Belkasoft, because the image won’t open with AXIOM. Since Belkasoft can deal with corrupted images, we will use Belkasoft to analyze the full image taken by AXIOM, as shown in Figure 14-43. A total of 204 Chrome artifacts were retrieved after rooting.

Moreover, we still can navigate to the Chrome SQLite files as shown in Figure 14-44.

After rooting Android, one more experiment is done when disabling Chrome apps. To disable the Chrome app go to Settings ➤ App ➤ Chrome ➤ Disable. After disabling Chrome, one more full image was taken by AXIOM. Analysis of this image returns nothing related to the Chrome app.

Comparison between Tools Used for iOS

In summary comparisons between data acquisition from iOS devices and iOS backups, we mainly used three tools to do data acquisition for the iOS device, iTunes, Belkasoft, and FINALMobile. No differences were found between the acquired data for the case study. All copies of backup contain the same SQLite files; it is easy to export files and later view all data using SQLiteStudio or by SQLite viewer, which is included in Belkasoft and FINALMobile. Using automated forensics tools gives different artifacts because each tool views artifacts directly from some SQLite database files; for example, FINALMobile extracts data from devices in a different way from Belkasoft. If we are are looking for more artifacts, then it is very important to dive deeply looking for SQLite database file because forensics tools will never show you all artifacts, which are the logical images stored in SQLite files. Also, it is important to use more than one tool, because of the differences in mobile platforms, equipment, architecture, OS, the make, and so on. Knowing mobile features will facilitate the choice for the digital forensics specialist to select which tool will be effective in different cases. Table 14-4 shows basic features available in each table for previous experiments.

Table 14-4. Used Tool Features for iOS

Table 14-5 summarizes the comparison between tools used for Android in the acquisition phase.

Table 14-5. Comparison between Tools Used for Android in Terms of the Acquisition