Smartphone forensics is relatively new and quickly emerging field of interest in the digital forensic community and law enforcement, today's mobile devices are getting smarter, cheaper and more easily available for common daily use.

To investigate the growing number of digital crimes and complaints, researchers put lot of efforts to bring the most affordable investigative model; in this chapter we will put the point on the importance of paying real attention to the growing market of smartphones and the efforts hold in this way from a digital forensic point of view in order to bring the most comprehensive investigation process.

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

Smartphone forensics model

Given the pace at which mobile technology grows and the variety of complexities produced by today's mobile data, forensics examiners face serious adaptation problem, developing and adopting standards makes sense.

Reliability of evidence depends directly on adopted investigative processes, choosing to bypass or accidentally bypassing a step may (and will certainly) lead to incomplete evidence and increase the risk of rejecting them in the court of law.

Today, there is no standard or unified model adapted to acquiring evidence from smartphones. The dramatic development of Smart devices suggests that any forensic examiner will have to apply as many independent models as necessary to collect and preserve data.

Similar to any forensic investigation, several approaches and techniques could be used to acquire, examine and analyze data from a mobile device, this section provides a proposed process in which guidelines from different standards and models (SWGDE Best Practices for Mobile Phone Forensics, NIST Guidelines on Mobile Device Forensics, Developing Process for Mobile Device Forensics by Det. Cynthia A. Murphy) were summarized. The following schematizes the overall process:

Evidence Intake: trigs the examination process. This step should be documented.

1. Identification: the examiner needs to identify the device's capabilities and specifications. The examiner should document almost everything during the whole process of identification.
   
2. Preparation: the examiner should prepare tools and methods to use and must document them.
   
3. Securing and preserving evidence: the examiner is invited to protect the evidence and to secure the scene as well as isolate the device from all networks. The examiner is encouraged to be vigilant when documenting the scene.
   
4. Processing: at this stage, the examiner starts performing the actual (and technical) data acquisition and analysis and document steps, tools used and all his findings.
   
5. Verification and validation: the examiner should be sure of the integrity of his findings and must be validating acquired data and evidence. This step should be documented as well.
   
6. Reporting: the examiner produces a final report in which he documents the process and findings.
   
7. Presentation: this stage is meant to exhibit and presents findings.
   
8. Archiving: at the end of the forensic process, the examiner should preserve data, report, tools and all his finding in common formats for an eventual later use.
   

The first chapter of the book presents an overall view of some of the most known digital forensics processes, and the latest chapter covers in details guidelines and best practices on mobile forensics.

Low-level techniques

Digital forensic examiners can neither always nor exclusively rely on commercially available tools. Handling low-level techniques is a must. This section will also cover some techniques of extracting strings from different object (ex. Smartphone images)

Any digital examiner should be familiar with concepts and techniques like:

• File carving, defined as the process of extracting a collection of data from a larger data set. Applied to a digital investigation case, File carving is the process of extracting "data" from unallocated file system space using file type inner structure and not File System structure, meaning that the extraction process is principally based on file types headers and trailers.
• Extracting Metadata, by an ambiguous way metadata is data that describes data or information about information. In general metadata is extra hidden information generated and embedded automatically in a digital file. The definition of metadata differs depending on the context in which it's used and the community that refers to it, metadata can be considered as machine-understandable information or can be referred to records that describe digital records. In fact, metadata can be subdivided into three important types: Descriptive (including elements like author, title, abstract and keywords), Structural (describing how object is constituted and how elements are arranged) and Administrative (including elements like date and time of creation, data type, and other technical details)
• String dump and analysis, most digital investigations rely on textual evidence, this is obviously due to the fact that most stored digital data is linguistic as for instance logged conversation, lot of important text-based evidence can be gathered while dumping strings from images (smartphone memory dumps) and can include emails, instant messaging, address books, browsing history… Most of currently available digital forensic tools rely on match and indexing algorithms to search textual evidence at the physical level, so they search every byte to locate specific text strings.
• Encryption vs. Encoding vs. Hashing, the important thing to keep in mind is that encoding, encrypting and hashing are terms that do not say the same thing at all:
  • Encoding: Is meant for data usability and is reversible using the same algorithm and requires no key
  • Encrypting: Is meant for confidentiality is reversible and depending on algorithms, it relies on key(s) to encrypt and decrypt.
  • Hashing: Is meant for data integrity and cannot be 'theoretically' reversible and depends on no keys.
• Decompiling and Disassembling, are both kind of reverse engineering processes that do the opposite of what a compiler and an assembler do.
  • A decompiler translates a compiled binary's low-level code designed to be computer readable into human readable high-level code. The accuracy of decompilers depends on many factors like the amount of metadata present in the code being decompiled and the complexity of the code (not regarding algorithms but in terms of the high-level code used sophistication).
  • The output of a disassembler is at some level processor dependent; it maps processor instructions into mnemonics, which is in contrast to decompiler's output far more complicated to understand and to edit.

All of these concepts and techniques are extremely well detailed in the second chapter of the book.

iDevices Forensics

Just like all Apple operating systems, iOS is reduced of Mac OS X thus iOS uses Hierarchical File System Plus (HFS+) as its primary file system. HFS+ replaces the firstly developed file system HFS and is considered as an enhanced version of this last and they still architecturally very similar. The main improvements seen in HFS+ are:

• Decrease in disk space usage on large volumes (efficient use of disk space)
• International-friendly file names (by the use of UNICODE instead of MacRoman)
• Allow future system to use and extend Files/Folder's metadata

HFS+ divides the total space on a volume (file that contains data and structure to access this data) into allocation blocks and uses 32-bits fields to identify them, meaning that this allows up to 2^32 blocks on a given volume which "simply" means that a volume can hold more files.

All HFS+ volumes respect a well-defined structure, and each volume contains a volume header, a catalog file, extents overflow file, attributes file, allocation file, and a startup file.

Also, all Apple's iDevices has a combined built-in hardware/software advanced security and can be categorized according to Apple's official iOS Security Guide as:

• System security: Integrated software and hardware platform.
• Encryption and data protection: Mechanisms implemented to protect data from unauthorized use.
• Application Security: Application sandboxing.
• Network Security: Secure data transmission.
• Apple Pay: Implementation of secure payments.
• Internet Services: Apple's network of messaging, synchronizing and backup.
• Device Controls: Remotely wiping the device if lost or stolen.
• Privacy Control: Capabilities of control access to geolocation and user data.

When dealing with seizure, it's important to turn on Airplane mode and if the device is unlocked to set Auto-lock to "never" and to check whether the passcode was set or not (Settings -> Passcode). If you are dealing with a passcode set try to keep the phone charged if you cannot acquire its content immediately, if no passcode was set to turn off the device.

There are four different acquisition methods when talking about iDevices: Normal or Direct, this is a perfect case when you can deal directly with a powered on device; Logical Acquisition, when the acquisition is done using iTunes backup or a forensic tool that uses AFC protocol and is in general not complete where emails, geolocation database, apps cache folder, and executables are missed; Advanced Logical Acquisition, a technique introduced by Jonathan Zdziarski (http://www.zdziarski.com/blog/) but no longer possible by the introduction of iOS 8, and Physical Acquisition that generates a forensic bit-by-bit image of both system and data partitions. Before choosing (or not, because the method to choose depends on some parameters) one method, the examiner should answer three important questions:

1. What is the device model?
2. What is the iOS version installed?
3. Is the device passcode protected?
   1. Is it a simple passcode?
   2. Is it a complex passcode?

Each method is documented, explained and demonstrated in the book. You will also be diving into iOS internals, file system, PIN cracking and different forensics tools used successfully to extract data from an iOS 8+

Android Forensic

Android is an open source Linux-based operating system; it was first developed by Android Inc. in 2003 then in 2005 it was acquired by Google and was unveiled in 2007. The Android operating system is as most of operating systems, consists of a stack of software components roughly divided into four main layers and five main sections as shown on the image from https://upload.wikimedia.org/wikipedia/commons/a/af/Android-System-Architecture.svg) and each layer provides different services to the layer above.

Understanding every smartphone's OS security model is a big deal in a forensic context, all vendors and smartphones manufacturers care about securing their user's data, and in most of the cases security model implemented can cause a real headache to every forensic examiner, Android is no exception to the rule. Android, as you know, is an open source OS built on the Linux Kernel and provides an environment offering the ability to run multiple applications simultaneously, each application is digitally signed and isolated in its very own sandbox, each application sandbox defines the application's privileges. Above the Kernel, all activities have constrained access to the system.

Android OS implements many security components and has many considerations of its various layers; the following figure summarizes Android security architecture on ARM with TrustZone support:

Without no doubt, lock screens represent the very first hard starting point in every mobile forensic examination. As for all smartphone's OS, Android offers a way to control access to a given device by requiring user authentication; the problem with recent implementations of lock screens in modern operating systems in general and in Android since it is the point of interest of this chapter, is that beyond controlling access to the system user interface and applications, lock screens has been extended with more "fancy" features (showing widgets, switching users in multi-users devices…) and more forensically challenging features like unlocking the system key store, to derive the key encryption key (used among the disk encryption key) as well as the credential storage encryption key.

The problem with bypassing lock screens (also called keyguards) is that techniques that can be used are very version/device dependent. Thus, there is neither a generalized method nor all-time working techniques.

Android keyguard is an Android application which window lives on a high window layer with the possibility of intercepting navigation buttons to produce the "lock" effect. Each unlock method (PIN, Password, Pattern and Face Unlock) is a view component implementation hosted by the KeyguardHostView view container class.

All of the methods/modes used to secure an Android device are activated by setting the currently selected mode in the enumerable SecurityMode
of the class KeyguardSecurityModel. The following is KeyguardSecurityModel.SecurityMode implementation as seen from Android open source project:

enum SecurityMode {

Invalid, // NULL state

None, // No security enabled

Pattern, // Unlock by drawing a pattern.

Password, // Unlock by entering an alphanumeric password

PIN, // Strictly numeric password

Biometric, // Unlock with a biometric key (e.g. finger print or face unlock)

Account, // Unlock by entering an account's login and password.

SimPin, // Unlock by entering a sim pin.

SimPuk // Unlock by entering a sim puk

}

Before starting our bypass and locks cracking techniques, dealing with system files or "system protected files" assumes that the device you are handling meets some requirements:

• Using Android Debug Bridge (ADB)
  • The device must be rooted.
  • USB Debugging is enabled on the device.
• Or booting into a custom recovery mode.
• Or jTAG / Chip-Off to acquire a physical bit-by-bit copy.

Techniques and details on cracking a passcode on Android, as well as most of the interesting aspects of Android internals are extensively detailed in the fourth chapter of the book.

Windows Phone Forensic

Based on Windows NT Kernel, Windows Phone 8.x uses the Core System to boot, manage hardware, authenticate and communicate on networks. The Core System is a minimal Windows system that contains low-level security features and is supplemented by a set of Windows Phone specific binaries from Mobile Core to handle phone-specific tasks which make it the only distinct architectural entity (From desktop-based Windows) in Windows Phone.

Windows and Windows Phone are completely aligned at Window Core System and are running the same code at this level. The shared core consists of the Windows Core System and Mobile Core where APIs are the same, but the code behind is turned to mobile needs.

As most of mobile operating systems, Windows Phone has a pretty layered architecture, the kernel and OS layers are mainly provided and supported by Microsoft but some layers are provided by Microsoft's partners depending on hardware properties in the form of board support package (BSP) which usually consists of a set of drivers and support libraries that ensure low-level hardware interaction and boot process created by the CPU supplier, then comes original equipment manufacturers (OEMs) and independent hardware vendors (IHVs) that write required drivers to support the phone hardware and specific component. Following is a high-level diagram describing Windows Phone architecture organized by layer and ownership:

There are three main partitions on Windows Phone that are forensically interesting: MainOS, Data and Removable User Data (not visible on the screenshot above since Lumia 920 does not support SD cards) partitions, as their receptive names suggest, the MainOS partition contains all Windows Phone operating system components, Data partition stores all user's data, third-party applications, and all application's states. And Removable User Data partition which is considered by Windows Phone as a separate volume and refers to all data stored on the SD Card (on devices that support SD cards).

Each of the previously named partitions respects a folder layout, and can be mapped to their root folders with predefined Access Control Lists (ACL). Each ACL is in the form of a list of access control entries (ACE), and each ACE identifies the user account to which it applies (trustee)
and specifies the access right allowed, denied or audited for that trustee.

Windows Phone 8.1 is extremely challenging, and different forensics tools and techniques should be used to gather evidence, one of the interesting techniques is side loading an agent to extract contacts and appointments from a WP8.1 device.

To extract Phonebook and Appointments entries we will be using WP Logical which is a contacts and appointments acquisition tool designed to run on Windows Phone 8.1 (details on how the application was implemented and link to download it are under WPLogical Implementation section), once deployed and executed, WP Logical will create a folder with the name "WPLogical_MDY__HMMSS_PM/AM" under the public folder
PhonePictures where M=Month, D=Day, Y=Year, H=hour, MM=Minutes and SS= Seconds of the extraction date. Inside the created folder you can find appointments__MDY__HMMSS_PM/AM.html and contacts_MDY__HMMSS_PM/AM.html

WP Logical will extract the following information (if found) regarding each appointment starting from 01/01/CurrentYear at 00:00:00 to 31/12/CurrentYear at 00:00:00

• Subject
• Location
• Organizer
• Invitees
• Start Time (UTC)
• Original Start Time
• Duration (in hours)
• Sensitivity
• Replay Time
• Is Organized by User?
• Is Canceled?
• More details

And this information about each found contact:

• Display Name
• First Name
• Middle Name
• Last Name
• Phones (kind -personal, office, home...- and numbers)
• Important Dates
• Emails (kind -personal, work,...- and email address)
• Websites
• Job Info
• Addresses
• Notes
• Thumbnail

WPLogical also allows the extraction of some device related information as Phone Time zone, Device's friendly name, Store Keeping Unit (SKU), etc.

Windows Phone 8.1 is relatively strict regarding application deployment; WPLogical can be deployed in two ways:

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

1. Upload the compiled agent to Windows Store and get it signed by Microsoft, after that, it will be available in the store for download.
2. Deploy the agent directly to a developer unlocked device using Windows Phone Application Deployment utility.

The fifth chapter of the book covers almost every aspect of Windows Phone 8.1 forensics, including WP8.1 internals and forensics tools, used to provide a forensics examination.

Resources

• Mastering Mobile Forensics - https://www.packtpub.com/networking-and-servers/mastering-mobile-forensics
• WP Logical - https://github.com/soufianetahiri/Windows-Phonne-Logical-Forensic/