Android Mobile Forensics and Private Data Leaks

We have noticed many research studies investigating the causes of private data leaks over mobile working toward conducting leak-cause analysis of data. The researchers correlate the actual leaks to the user actions. The data leaking attitude of an application stays in stable status with respect to time; a similar data leaking attitude is expected to be observed repeatedly if an extra and adequate amount of application logs is analyzed (Ávila, Khoury, Khoury, and Petrillo, 2021). Thus, we are able to extract and understand log patterns and reveal the actual causes of data leaking behavior. Several researchers have carried out significant studies on mobile forensics of private data leaks; the research of Keng, J. C. J. observed a high-volume ratio of leaky applications. “Out of the 226 applications studied, 121 applications are not leaking private data (nonleaking apps). Among the 105 apps (46.5%) leaking privacy data, 64 apps (28.3%) were found to leak private data due to user actions on application widgets. We notice that an application can leak data in various ways: (1) User-Triggered Leaks (identified by association rules), (2) Start-Up or One-Time Leaks, and (3) Periodic Leaks” (Keng et al., 2013). In the first step, the researchers instrumented the mobile system to log and collect user traces with “Taint- Droid” as their tools for detecting data leaks. In the second step, the researchers conducted extensive testing of selected samples of mobile applications to collect the logs and trace the leaks. Finally, the researchers performed various analyses to produce and detect the causal relations among the user actions and data leaks. Other corresponding research on detecting and mitigating privacy leaks over iOS mobile platforms was conducted by Agarwal, Y. and Hall; the researchers observed a high volume of inappropriate application access to user data. “We observe that 48.4% of the total applications access the identifier, 13.2% access location, 6.2% access contacts and 1.6% access the music library. Next, we find that a large number of users actively make privacy decisions: 44,260 users make 10-100 decisions while 16,729 users make 100-363 decisions” (Agarwal and Hall, 2012).

Facebook as Mobile Application Advertising Platform

Commercial advertising over online platforms is the basic source of funds for mobile application developers, as well as playing a vital role in the growth of the international economy. This situation comes along with major individuals’ privacy and data protection concerns. Advertisers keep working very hard toward acquiring extensive corresponding information about their audience to have the ability to present them with advertisements appropriate for their interests. In other words, this might be called “behavioral advertising.” And due to the current technological innovations on the online world and social media platforms such as Facebook and Instagram, it becomes very possible to create profiles of Internet users and depend on such profiles for designing powerful tools to control preferences to commercial companies that offer online behavioral advertising services.

Several researchers have carried out significant studies on the fact that Facebook is using personal private data for advertising and marketing purposes. Special research conducted by Marcello M. Mariani investigated how the Italian regional destination management organizations (DMOs) strategically employed the Facebook platform to promote and market their destinations, as well as improving the current metrics for capturing user engagement. The investigations were carried out based on a big data analysis approach through extracting the data from the regional DMOs’ Facebook pages, in addition to semistructured face-to-face interviews conducted with DMO regional managers. The findings of the study indicated that “the way Facebook is tactically and strategically employed varies significantly across Italian regional DMOs. Visual content (namely photos) and moderately long posts have a statistically significant positive impact on DMOs’ Facebook engagement, whereas high post frequency, and early daily timing (in the morning) of posts have a negative impact on engagement. Last but not least, the study shows that most of the regional DMOs (except for Trentino, Tuscany, and Sicily) deploy Facebook with a top-down approach, allowing for little spontaneous user generated content (UGC)” (Mariani, Di Felice, and Mura, 2016).

Reverse Engineering of Android Applications

The main goal for analyzing source code and reverse engineering for Android applications is to provide inclusive understanding of the inner functionality of applications running over mobile Android platform (Wongwiwatchai, Pongkham, and Sripanidkulchai, 2020b), and to reveal additional information on how data are being transferred and moved through application components and objects into and out of applications (Tiwari, 2020). The investigations on different methodologies and tools for reverse engineering of Android applications carried out by Zhang, Baggili, and Breitinger concluded that there are several methods that can be used to decompile the precompiled Java code (Dalvik bytecode) into Java source code readable by application reviewers and developers, due to the fact that all applications running over the Android platform are programmed in Java language. One of the most well-known tools is dex2jar, that tool can convert Dalvik bytecode into Java source code (.jar, .class) (Zhang, Baggili, and Breitinger, 2017).

Sensitive Information Transmissions in Mobile Applications

While mobile apps often need to transmit sensitive information out to support various functionalities, they may also abuse the privilege by leaking the data to unauthorized third parties. This makes us question if the given transmission is required to fulfill the app functionality (Fu et al., 2020). “To date, various methods have been proposed to detect and isolate the third-party libraries that may incur privacy threats. However, they either rely on the namespace or the program structure. thus, suffering from the evasion attacks such as obfuscation and call graph manipulation, or counting on the deep cooperation of developers, which ignores a great deal of intentional data leakage driven by under-the-table income. More importantly, all of them are designed to handle the misbehavior from isolated ad libraries, and they do not apply to malicious transmissions embedded in the core app logic” (Fu et al., 2020).

The investigator team was able to “automatically detect privacy-sharing transmissions and determine their purposes by utilizing the fact that mobile users rely on a visible app interface to perceive the functionality of the app in a certain context. The characterizations of nonfunctional network traffic are then summarized to provide network-level protection. Researchers were not only reducing the false alarms caused by traditional taint analysis but also captured the sensitive transmissions missed by the widely used taint analysis system Taint Droid. Evaluation using 2125 sharing flows collected from more than a thousand running instances, shows that our approach achieves about 94% accuracy in detecting nonfunctional transmissions” (Fu et al., 2020).

Acquire Data from an iOS Device

Logical acquisition captures a part of the data that is accessible to the mobile user; in other words, what is available in an iTunes backup. This implies that we are not able to retrieve any of the deleted files, but this can be done instead using SQLite databases that can navigate the unallocated space so that we will be able to recover the majority of the deleted records, including but not limited to SMS, chats, Internet history, and so on. Logical acquisition is considered the simplest way to acquire data for the unlocked devices, since this method uses the built-in backup mechanism. The majority of tools and data acquisition methods designed for logical acquisition of iOS devices will not succeed and will fail if the device screen is locked. Even if a physical image were captured, there is little to no need for conducting a logical acquisition. Indeed, not all data can be parsed in a physical image, which is why we have access to a logical image, which generates readable data; this will assist you effectively in mining deep into the physical image looking for artifacts that are able to support your forensic investigation. Logical acquisition is considered the fastest, the easiest, and the cheapest way to get access to the data stored over the iOS device. There are a variety of tools, ranging from commercial paid to free, that can capture mobile devices’ logical images. Most of such tools require that acquiring devices are unlocked, or should have the ability to access the plist files through the host investigation’s machine.

File system acquisition: We are not able to extract the encryption keys needed to decrypt the device’s physical image, so conducting the physical acquisition is useless. However, there is file system acquisition to rescue us. Unfortunately, in most cases, it requires the iOS device to be jailbroken.

Acquire Data from an iOS Backup

The physical acquisitions and extraction of the iOS devices offer the majority of the data in an investigation process; it will be found as a rich area of information within iOS backups has been extracted. iOS mobile device holders have many alternatives to backing up the data available on their devices. Mobile holders choose to back up data to the PCs, using iTunes applications, or over the Apple cloud storage SaaS known as iCloud.

Every time an iPhone is synced with a PC or to iCloud, it generates a backup file by copying the user-selected files to extract from the device. Users can choose and select what they need to include in the backup files, although some backup files may be more significant and related to the case than others. Besides, the user of mobile can do backup to be extracted on both PC and iCloud; this implies that the data extracted from each area may not be similar to the other one. This case most likely happens due to the size constraints of iClouds.

Understanding Android Data Extraction Techniques

Data reset on an Android MD might be an important part of the civil, criminal, or organizational internal investigations conducted as part of corporate internal issues. During the process of dealing with digital investigations for Android MD, the forensic examiners need to be aware of the issues critically and need due diligence and special attention during conducting the forensic process; this might include, but is not limited to, what type of data might be extracted through the investigation process. It is recommended and considered the best choice to extract all possible data from MD immediately once the investigator can do so. As we explained in Chapter 3, the data extraction techniques for Android MD might be classified into three main categories:

The Manual Data Extraction: This method of data extraction required the investigators to utilize a normal MD interface to access the content presented in the device memory. The investigator will walk through the device manually by accessing different applications’ menus to view and observe any information details like the call logs, the text messages, and the instant message chats. The contents of every interested screen needs to be captured by taking a snapshot of pictures, and then it might be presented as legal digital evidence. The main obstacle to utilizing this examination type is that we are only able to investigate files that are accessible through the Android system (in User Interface mode).

The Logical Data Extraction: The logical data extraction method can extract data presented on the MD by directly interacting with the mobile OS to have access to the file system. This method is very significant because it provides various valuable data, works on the majority of devices, and is easy to use. Logical extraction of data does not require root access to the devices in general, but having root access to MD would significantly impact the amount and the kind of data that might be extracted even through logical techniques. Figure 6-1 illustrates an example of logical extraction used for our case using the pull ADB command, and Figure 6-2 shows the use of FINALMobile Forensics.

The Physical Data Extraction: The physical extraction of data refers to the process of obtaining an exact bit-by-bit image of a device (Tamma, Skulkin, Mahalik, and Bommisetty, 2020). It is important to understand the reality that a “bit-by-bit” image file will never be the same as copying and pasting the available contents of an MD. If we try to copy and paste specific contents of an MD, this process will copy only the available and presented files, like “visible files, hidden files, and system-related files.” This technique is considered to produce a logical image; any deleted files and any other files that are inaccessible will not be copied using the copy command. While in some cases, the deleted files might be recovered based on certain circumstances and utilizing certain techniques, the physical extraction of data is typically an exact copy to the MD’s memory and will include more valuable information, like the memory slack space and the memory unallocated space. Figure 6-3 illustrates an example of physical data extraction, and a comparison of three data acquisition techniques is given in Table 6-2.

Table 6-2

Data Acquisition Comparison: Manual, Logical, and Physical Data Extraction

Comparison Criteria	Manual Extraction	Logical Extraction	Physical Extraction
Extracted data	Access only the content presented in the device memory for the user	Access user data and file system	Full access to data
Acquisition tools	MD interface	FINALMobile Magnet AXIOM Oxygen Forensic Detective	Joint Test Action Group (JTAG) The chip-off technique DD command (ADB) Various forensic tools
Capture capabilities	Only capture what can be observed by mobile users manually	Captures the user and application data and the file system	Captures every single bit in the device memory
Accuracy	Not accurate, and subject to human omissions	Accurate if conducted under well-prepared environment	Very accurate if conducted under well-prepared environment
Device permission	Regular Android user permission	Regular Android user permission (more data for rooted devices)	Only available for rooted devices
Deleted file recovery	Not possible	Not possible	Possible in certain circumstances
Security constraints	Need to know pass code	Need to know pass code (possible bypass)	Need to know pass code (possible bypass)
Technical level	Very high level	High level	Low level (machine level)
Time constraints	Time-consuming (slowest)	Good extraction time (the quickest)	Good extraction time
Database direct access	Not allowed	Allowed	Allowed

Data Acquisition and Extraction

For the purpose of this research, and to be able to investigate the most important artifacts on mobile devices and Facebook applications, we first rooted the Android device (using Odin3) and then located and extracted Facebook application–generated artifacts on the Android file system under (/data/data) directory (such as app databases, app settings, app files, app images, app cache) using (ADB), as illustrated in Figure 6-4, Figure 6-5, and Figure 6-6.

With root permission on the Android device, we extracted the Facebook Application Package File (APK) artifacts generated on the Android file system under the (/data/app/com.facebook.katana-unIIK4MRZYqhhbj3LV0-IA==/base.apk) directory (base.apk ), as illustrated in Figure 6-7.

Facebook Information File Investigations (Account Artifacts)

In order to investigate the various activities regarding sharing of information between the exit point of data for installed applications into the Facebook platform, we requested the full Facebook information file for the test user and investigated various account activities regarding the entry point of Facebook data artifacts and potential leaks of data (i.e., location access, IP address), as illustrated in Figure 6-8.

Analysis of Facebook Source Code with Reverse Engineering

In order to investigate and analyze the Facebook source code and to reveal evidence on data leaks into its internal components, we deployed reverse engineering techniques to extract (Dalvik code files) located within the Facebook Application Package File (APK) into the Java source. First, we extracted the APK file of Facebook from the application directory of the mobile into a forensic workstation using (Pull Command). Second, we unzipped the file to extract the corresponding (Dalvik code files) named (classes.dex), with a total of 12 Dalvik code files. Third, we used Android applications decompile tools (Dex2jar 2.0.) to decompile the Dalvik code files into a readable Java source code. Finally, we were able to view and investigate the actual Java classes of the Facebook application using the Java programming language decompiler (GD-GUI-1.6.6.); the output of this step illustrated in Figure 6-9.

Case Analysis and Major Findings

Next to the Android device artifact extraction, and in parallel to Facebook information file acquisition. First, we manually explored and analyzed the majority of Facebook applications and Facebook information file artifacts. We were able to investigate various important Facebook application artifacts that store or acquire personal data of mobile users. Such artifacts include Location Information, Bluetooth Connections and Call Logs, Communication Information, as well as Facebook user artifacts such as Facebook contacts, Facebook messages, Facebook posts, and Facebook news feed. Figures 6-10 to 6-13 present information stored in such artifacts.

Second, we manually explored, reviewed, and analyzed the majority of Facebook application Java source code classes after decompiling the (Dalvik code files) located within the Facebook Application Package File (APK) . The analysis process focused on finding the entry points of data to the Facebook application from one side, and to the exit points of data from the other. We reviewed 12 class files and we were able to investigate various classes responsible for sharing and transferring data from and into Facebook applications. These included such points as Fileprovider.class, Phone Id, Location Information, and Bookmark Information. Figures 6-14 to 6-16 present data points of exchanges written in such Java classes.

All extracted data have been analyzed, including samples illustrated in the preceding work, considered as supporting evidence to our experimental results. Our artifact analysis process showed that the Facebook application is listening to various data sources and artifacts presented on mobile device. Such artifact include but are not limited to Location Information, Bluetooth Connections and Call Logs, Communication Information, and leaking it to commercial parties with or without explicit permissions from the user. The process of review and analysis of the majority of Facebook application Java source code classes showed that Facebook is collecting and leaking various data from mobile devices throughout programmable functions within the design of general Java classes structure (contents provider information, device ID information, etc.). Our case was investigated using both iOS and Android devices, but with more concentration on Android devices. We conclude that the security of new iOS devices is more reliable and harder to bypass, especially for new devices when compared to Android due to the complex design of iOS security measures.