The 5 Enduring Challenges of Mobile Forensics
Written by Christa Miller   

The practice of mobile forensics has evolved dramatically over the past 15 years-and, naturally, so have its challenges. As device manufacturers and app developers respond to consumer demand for a better balance between privacy and convenience, forensic examiners face a number of obstacles in retrieving evidentiary data:

• Manufacturer and wireless-carrier restrictions and controls.

• Hardware and software encryption.

• App versioning and privacy/encryption.

• Data spread among many different potential sources.

• Maintaining forensically sound processes.

Manufacturer and wireless carrier restrictions and controls
For a number of years, forensic boot loaders were considered the most forensically sound physical extraction method. Because a forensic boot loader replaced the device's normal boot loader-the first set of operations in the phone's startup process before handoff to the operating system-they allowed access to the device without modifying it. This enabled a read-only forensic extraction of all user data, including fragments in unallocated areas.

Boot loaders were never perfect; their common inclusion in vendor tools makes it difficult to explain how they work and, more importantly, how they don't modify data. More recently, however, vendors such as AT&T and Verizon have begun to lock their Android devices' original boot loaders, a practice intended to stop users from flashing new firmware unapproved by the vendor. In addition, Android Verified Boot, available since Android v4.4 (KitKat) and designed as a defense against rootkit-level malware, signs the boot chain so that no part of it can be modified (Android Source, 2017).

Other controls that can cause forensic problems with both iOS and Android platforms are theft-prevention mechanisms: Apple's Find My iPhone Activation Lock and Google's Factory Reset Protection (FRP), which both prevent forensic imaging.

Find My iPhone, introduced with iOS 8, requires the user's Apple ID password or device passcode before it can be turned off, or before the device can be imaged. Similarly, FRP, activated with a Google account and affecting devices running OS 5.1 or later, prevents use of a device following a factory data reset, until login using the Google username and password associated with setup. FRP prevents device access via recovery mode, and forensic tools don't disable it.


Find My iPhone, introduced with iOS 8, requires the user's Apple ID password or device passcode before it can be turned off, or before the device can be imaged.

Advanced-level forensic examiners can use tools like flasher boxes to remove FRP in order to flash a custom recovery to a device for acquisition. Once this is done, the /recovery partition, an alternative boot partition that's independent of the Android system, allows a user to boot the device into a recovery console to perform advanced recovery and maintenance. Flashing the recovery partition doesn't affect the user partition, but is a viable method for bypassing passwords and getting physical images of some of the most popular devices.

There are some caveats with this method:

• You must know the exact model of Android phone for it to work; the wrong recovery image will likely brick the device.

• With a tool like ClockWorkMod, sometimes to install the custom recovery, you need to select to wipe the user partition (Lohrum 2017).

• Recovery images won't disable encryption. Even if you get a physical image of an encrypted device running Android 6.0 or 7.0, in all likelihood it won't contain usable evidence.

• Bootloader locking prevents recovery methods. Flashing a locked bootloader risks that the device may not boot, or may require a re-flash of stock ROM, or the loss of user data. Determining bootloader lock status is very complex and risky.

• FRP lock status can often be determined by booting into download mode, and you can use an internet search to determine the device's physical key combination. However, key combinations and directions vary by device. If you see FRP LOCK: ON, don't flash the device.

• Some devices running Android 7.0 and up now require entry of the user's passcode in order to turn the device off, which is a necessary step before booting it into download or recovery mode.


Flashing the recovery partition is a viable method for bypassing passwords and getting physical images of some of the most popular Android devices, but it's risky and carries numerous caveats.

Hardware and software encryption
Encrypted devices have challenged forensic examiners since BlackBerry, but the trend has only accelerated in recent years with hardware-backed encryption keys such as Apple's Secure Enclave and Google's Gatekeeper. Not only are these keys impossible for mobile forensic tools to break; even physical imaging processes like JTAG, ISP, and chip-off are unable to acquire data in any useful format.

Just as iOS no longer relies on simple passcodes to protect devices, neither does Gatekeeper on simple hashes for PIN and pattern locks. So, while they're still breakable, the process isn't as easy. In addition, Gatekeeper counts the total number of failed verification attempts and throttles consecutive failed attempts-so mobile forensic tools that attempt to brute-force passwords will no longer work.


Newer features, such as Android's Gatekeeper password storage, can present new levels of obfuscation. In Gatekeeper's case, while PIN and pattern locks are still breakable, the process is not as easy because they no longer use simple hashes.

With the introduction of OS 7 (Nougat), Google came up to par with Apple by offering file-based encryption (FBE) rather than the full disk encryption available as of OS 5 (Lollipop). However, because Android adoption rates are so much slower and more diffuse than iOS adoption rates, investigators are as likely to encounter an OS 6 (Marshmallow) device encrypted with default_password (or some other PIN, pattern, or password lock) for boot and/or screen lock as they are to encounter a Nougat device which, through Direct Boot, loads some data upon boot while protecting other data-at the file level-via user credentials.

Owing to permissions, a user with a rooted device can't enable FBE; likewise, rooting a device trips a flag and removes the ability to enable FBE. From a forensics perspective, this means an FBE-enabled device cannot have a shell or permanent root applied for acquisition purposes. Instead, custom recovery methodology is recommended because the recovery partition already has root privileges. As a result, it's unnecessary to make a user environment with root privileges.

Keychains are another important element of iOS password protections. The keychain, the vault that stores passwords for any variety of services-social media accounts, Wi-Fi connections, and so forth-is encrypted and protected, though it should be possible for a mobile forensics tool to decrypt it.

All this means that when it comes to obtaining consent-and user passcodes-for a search, an investigator's powers of interrogation and/or deduction continue to be key. In the absence of these codes, forensic examiners may need to rely on backups, obtaining them from the cloud versus the device or a synced computer.

App versioning and privacy/encryption
Millions of apps exist; billions of downloads have occurred. Because of the challenges associated with forensic app support-versioning, database structure changes, and so on-only a small fraction of the most popular apps are supported by mobile forensic vendors. The remainder, which constitute millions of unsupported apps between the Apple App Store and the Google Play Store, offer varying degrees of access.

That's because forensic tools may not always recognize the existence of unsupported SQLite databases within iOS and Android file systems. Without being able to include the databases in their reconstructed, decoded file systems, these tools can miss critical evidence in both available and deleted databases and entries.

Another challenge to forensic app examinations is encrypted app data. Messaging apps like WhatsApp, Signal, and "vault" apps are appealing to users whether they're trying to keep private, political, or criminal activities a secret.

Privacy apps, meanwhile, can feature decoy PINs and vaults, so that the PIN a suspect provides leads to a vault that contains only decoy evidence. Other privacy-oriented apps hide themselves by appearing to be an innocent app, or removing their icons altogether.

Even so, "encrypted" apps may only encrypt some, but not all, data-counter to their advertising-and as a result can sometimes be a trove of evidence. For example, an app that encrypts only the message body within the SQLite database still leaves critical metadata in the clear, offering clues to contacts and date/time ranges. Forensic tools therefore need to be able to identify SQLite databases that are consistent with known databases containing chat, contacts, and geolocation information.

Data spread among many different potential sources
Storage space on mobile devices has been increasing exponentially. Even at that, however, evidence no longer comes from just computers, smartphones, and peripheral storage. It also comes increasingly from the cloud and Internet of Things (IoT) devices. As more consumers and industries adopt wearables, intelligent personal assistants, smart appliances, and other IoT devices, the more they may be called upon as digital "witnesses" in criminal investigations, contradicting or supporting claims or alibis. For example, a murder case made headlines in 2017 after police used a victim's FitBit to disprove her husband's alibi, including his timeline of events, in order to charge him with the crime.

Where all this data is stored isn't as simple as imaging a FitBit, Nest, or Echo Dot as if it were a computer or smartphone. The amount of data stored on these devices may be comparable to a vehicle or aircraft digital or event data recorder, storing only a limited amount of history; the bulk of data is instead likely to be accessible from a paired "controller" smartphone, or from the user's account in the cloud.

Thanks to synchronization, it can be difficult to determine which device data originated on. This is complicated by the availability across multiple devices-and even users. A single vehicle might be paired with more than one mobile device, for instance, while many smartphones and tablets might have different user accounts. For users of iOS devices, moreover, larger reliance on Apple Continuity data-syncing between devices-means that your sole source for data might not have come from that device.

Another important aspect of all these different data sources is their ability to help investigators establish "patterns of life," and the resulting ability to separate normal routines from disruptions to those routines.

Both GPS data and Wi-Fi hotspot connections can show paths of travel and points of interest on a map, together with dates and times that could help to establish investigative timelines. Connected vehicles and homes may offer event logs around doors locking or unlocking, engine stop and start, thermostat variations, and a smartphone's connectedness.


Visual tools such as maps can show points of interest based on GPS or Wi-Fi connection data from multiple devices.

The availability of this kind of data, however, may lead to legal trouble. Depending on your jurisdiction, search warrants typically depend on particularity: the places to be searched and the things to be seized. Both can be complicated when it comes to digital data. "The places to be searched" could be a server in another country, while "the things to be seized" increasingly need to be restricted to only, say, text messages and location data from a certain date/time range, or images and videos but no messages or social media data.

Applied to many different devices, however, even a strict timeline could be construed as overbroad. Not all the data on a fitness device, home or personal assistant, vehicle, or tablet may be relevant even within a specified range-especially if it includes information from people who aren't connected to the investigation. Investigators should therefore be prepared to navigate these waters with the careful guidance of a trusted and well-informed attorney.

Maintaining forensically sound processes
At one time in the not too distant past, "forensic soundness" meant using a write blocker to obtain a pristine copy of a hard drive as received by a forensic examiner. Mobile forensics has never been able to rely on write-blockers, however; it's always been necessary to access and even occasionally modify a device image in certain, specified ways. The acquisition process has always been a patchwork, from manual hacker methods to automated proprietary tools.

This trend has only accelerated over time, as more device and app developers add features to protect their users. Therefore, the working definition of "forensic soundness" has had to change. The definition now refers to a process by which the examiner is aware of-and meticulously documents-the steps taken in the acquisition and the changes made to a device.

Good documentation starts with a test device of the same make, model, and OS version, pre-loaded with sample data and app versions that are the same as the evidence device you're working with. Document each step you take throughout the process, and its results, in order to maintain a record of actions to which you can comfortably testify at trial. You can then compare the user data from each image to show that user data remains unchanged.

• Start with what your search warrant or other legal authority allows you to get, as well as appropriate chain of custody logging.

• Validate your forensic tools by testing with a device of the same (documented) make, model, operating system, and firmware version, as well as the same relevant apps and their versions.

• Document your methods, including the steps you took to acquire the device, whether it changed anything on the device (and if so, what) and which data your method accesses.

• Record the acquisition method, and what tool(s) and their version(s) you used-as well as the connection method used for each extraction: cable, USB, etc.

• Finally, document your footprint: the changes your method makes to the device, based on observations from previous testing.

As digital technology continues to evolve, so will its forensic challenges. Core analytical skills, such as data carving, coding custom functionality to commercial tools, and testing new physical acquisition techniques will continue to be necessary. So how can you stay on top of all these advances?

Read digital forensics news and blogs. Thought leaders in the community include consultants, law enforcement investigators, and even some vendors, as well as individuals in listservs, forums, and social media sites. Their contributions to blog posts, white papers, articles, and other media ensure that you can stay informed.

Hands-on device acquisitions continue to be the best way to keep your skills sharp. Part of this includes monitoring relevant hacker communities for JTAG and ISP pinouts, new roots, custom recoveries, and other solutions.

Likewise, understand how mobile device file systems are structured. Even if your forensic tool hasn't recovered app data, it's important to know how to use your knowledge of databases and file systems to search for new apps. Some tools offer features that use heuristics to predict the likelihood of new apps based on the existence of chat, geolocation, and/or other data. Be familiar with these features and tools, and make them work for you.

The rapid evolution of mobile forensics need not present overwhelming challenges to forensic professionals.


About the Author
Christa Miller serves as the Creative Writer and Content Marketing Strategist for Magnet Forensics, a digital forensics company.

References
Android Source, "Verified Boot," last updated March 17, 2017, https://source.android.com/security/verifiedboot/ accessed December 18, 2017

Lohrum, M, "Why not load ClockworkMod or TWRP to image a device?" Free Android Forensics, April 2, 2015, http://freeandroidforensics.blogspot.ca/2015/04/why-not-load-clockworkmod-or-twrp-to.html accessed August 9, 2017


This article appeared in the Spring 2018 issue of Evidence Technology Magazine.

 
< Prev   Next >






Image Clarification Workflow

A FEW WEEKS AGO, I received a call from Ocean Systems asking if I would like to beta test their newest software—ClearID v2.0 Image Clarification Workflow. The new progam has filters that were designed for use with Adobe’s Photoshop graphics-editing program.

Read more...