by Oleg Afonin, Danil Nikolaev & Yuri Gubanov
© Belkasoft Research 2015

Most would agree that the golden age of mobile forensics is over. There is no longer an easy way to get through the passcode in new iOS devices running the latest version of iOS. Chip-off acquisition is dead for iOS devices due to full-disk encryption, while physical acquisition of Apple hardware is dead since the introduction of 64-bit devices and versions of iOS 8 that cannot be jailbroken. Blackberries were highly resistant to chip-off acquisition from the beginning, and Android is getting there quickly. In this whitepaper, we will look into the current state of mobile forensics for the different platforms and devices, analyze current trends and attempt to predict how mobile forensics will look in the years ahead.

To gather these predictions, Belkasoft analyzed state-of-the-art tools, methods and hardware offered by leading manufacturers, and interviewed experts working for manufacturers of digital forensic products. Since manufacturers often specialize in specific areas (e.g. producing equipment for breaking iPhone passcodes), we questioned multiple representatives to be able to see the whole picture. Today, we are ready to share our findings.

iOS Forensics

Since Apple uses full-disk encryption with passcode-dependent, hardware-based encryption, chip-off acquisition has not been a possibility for a long time. The following acquisition methods are available for Apple devices:

1. Sending the device back to Apple. Generally available to government agencies and law enforcement. Only for iOS versions prior to iOS 8.
2. Physical acquisition. A non-destructive acquisition method allowing one to obtain the full image of the device via the standard Apple cord.
3. Logical (backup) acquisition. Deals with offline backup files produced by the device being analyzed.
4. Over-the-air acquisition. Downloads information from the iCloud.

Let us briefly review the benefits, drawbacks and current trends for each acquisition method.

Sending to Apple

Sending devices for acquisition directly to Apple used to be a viable strategy, but not anymore. With the release of iOS 8, Apple explicitly states in their Privacy Policy that the new system is so secure that even Apple themselves cannot access information inside the device if the correct passcode is not known. Thus, modern devices running the latest version of iOS can only be acquired this way if the correct passcode is known. By June 2015, more than 80% of iOS devices were running iOS 8, so the chances of actually handling a device with an older version of iOS are becoming slim.

iOS Physical Acquisition

When it comes to physical acquisition, the technique only works for jailbroken 32-bit devices (both conditions must be met), or 32-bit devices with a known passcode that can be jailbroken by the investigator. Compared to Android, relatively few Apple users install jailbreak. Since there is currently no jailbreak for the latest version of iOS available, and all new devices are using 64-bit circuitry anyway, physical acquisition will only work in rare cases (with the exception of developing countries where older 32-bit Apple hardware still occupies a major market niche).

iOS Logical Acquisition

If a passcode is known, or there is a way of finding it out, investigators can make the device produce an offline backup via iTunes. The backup can then be analyzed, but with some restrictions:

• Device secrets (items stored in the keychain) will only be available if the backup was password-protected (and will NOT be available in backups saved without a password). Somewhat counterintuitively, if you have a device that is configured to produce backups without password protection, setting a known backup password and entering that same password in the forensic tool will enable access to more information compared to analyzing non-protected backups.
• Cached items such as downloaded mail are not available in backups.
• If the device is configured to produce password-protected backups, changing that password is not possible if the password is not known. According to Apple, “If you forgot your [backup] password, the only way to turn off backup encryption on your device is to erase your device and set up as new. Erasing removes all data from your device.” (https://support.apple.com/en-gb/HT203790). In other words, resetting the password is not an option if you do not know it already, and backups protected with an unknown password must be broken into by using forensic tools without any timeframe or success guarantee.

Other than that, there is a great number of forensically important items that you can find inside an iTunes backup using forensic tools. Our tool of choice is Belkasoft Evidence Center. The picture below illustrates how the tool was able to extract over 8 thousand instant-messenger related artifacts from a sample iTunes backup:

Over-the-Air Acquisition (iCloud)

Finally, there is a way to acquire the content of Apple devices by downloading backups from iCloud.

iCloud is a cloud service available to Apple customers. 5 GB of cloud storage are available free of charge, and up to 50 GB can be purchased for a fee.

Apple designed a very convenient system for backing up devices to the cloud. Backups are incremental and occur automatically every time the device is put on a charger while locked and connected to a known Wi-Fi network (all conditions must be met). Back in 2012, about 33% of Apple customers were using iCloud. While no recent statistics are available, we can suggest that iCloud usage has increased dramatically, with the majority of Apple customers backing up their information into the cloud.

Cloud backups contain all of the same information as offline backups produced via iTunes. iCloud backups can be retrieved with forensic software if the user’s Apple ID and password are known, or if a binary authentication token from the user’s computer is available. Information can also be obtained directly from Apple by law enforcement with a government request.

Android Forensics

Acquisition methods available for Android devices differ significantly.

1. Sending the device to the manufacturer for data extraction. Generally available to government agencies and law enforcement for most domestic devices. May not be available for international models (e.g. no-name Chinese phones).
2. Physical acquisition. A non-destructive acquisition method allowing one to obtain the full image of the device via a USB cord and forensic software.
3. JTAG forensics. Retrieves information via the phone’s Test Access Port.
4. Chip-off acquisition. Requires the removal of memory chips. Produces raw binary dumps.
5. Over-the-air acquisition. Involves downloading information from Google Account.

Sending to Manufacturer

Sending the device to its manufacturer may be a viable acquisition strategy if the device is unavailable via other means. For example, Samsung, who is the number one seller of smartphone devices in the US, has an official policy to support information extraction when serving a government request.

Notably, this approach may not be available in the case of international devices (in particular, no-name and C-brand smartphones originating from China). On the other hand, most Chinese devices are not secured in any reasonable way, and can usually be acquired via physical acquisition.

Android Fragmentation

Android is a highly fragmented platform with several hundred manufacturers and many thousands of device models (source: http://opensignal.com/reports/2014/android-fragmentation/). In a report dated August 2014, OpenSignal states: “We have seen 18,769 distinct devices download our app in the past few months. In our report last year we saw 11,868”. According to the same report, “Samsung have a 43% share of the Android market”, as illustrated by the chart:

Unlike iOS, Android has multiple major versions of the OS running on the plethora of devices. The official source demonstrates slow adoption of the latest Android 5 ‘Lollipop’ compared to blazing fast adoption of the latest iOS 8 by Apple users.

All this means that manual acquisition is probably out of the question (unless performed on a small sample of well-known models), with specialized software becoming the necessary middleman.

Notably, over-the-air acquisition (Google Account analysis) is the only method that has nothing to do with hardware fragmentation. Cloud acquisition will inevitably change as full data backups get introduced in Android M, but other than that it’s not dependent on the version of Android OS either.

Physical Acquisition of Android Devices

In this short overview, we will not go into comparing security implementation details between the different versions of Android, device manufacturers and carrier requirements. We will only give a qualitative assessment. Depending on your choice of forensic acquisition tool, the phone’s make, model, carrier, Android version, user settings, root status, lock status, whether or not the PIN code is known and whether or not the “USB debugging” option is enabled, you may or may not be able to perform physical acquisition of a particular device. (Translated to human language, the above paragraph means “you won’t know until you try”).

With all that said, a random Android device will most probably be a Samsung phone (a 43% probability). It will most probably have a locked bootloader, being protected with a 4-digit passcode, without root, and with USB debugging disabled (the user must alter certain phone settings explicitly in order to change any of the above, which is not always easy and even not always possible). Whether or not the device will be encrypted is a hit or miss (most devices are not encrypted out of the box, but enabling encryption is as easy as setting a PIN code and toggling a single setting). In other words, you will have to rely on the quality of your extraction toolkit in order to be able to perform physical acquisition of said device.

JTAG Forensics (Android)

JTAG forensics is an advanced acquisition procedure, which uses the standard JTAG port to access raw data stored in the connected device. By using specialized equipment and a matching device-specific JTAG cable, one can retrieve the entire flash memory contents from compatible devices. Notably, JTAG acquisition is often available even for locked, damaged or otherwise inaccessible devices.

It is important to realize that JTAG forensics is a low-level acquisition method that will return raw content of the memory chips. If whole-disk data encryption is present on the device (either pre-activated by the manufacturer or enabled by the user), JTAG acquisition will produce an encrypted image. In order to decrypt the raw image, one will need access to the phone’s higher-level API, which, in turn, requires supplying the correct passcode. Notably, whole-disk encryption is active out of the box on many Samsung phones, Nexus 6 and Nexus 9 devices as well as some other flagship phones sold by leading manufacturers.

Despite that, JTAG forensics remains a viable acquisition method for compatible Android devices. With Google’s decision to back away from encrypting new Android 5.0 devices by default, manufacturers are under no obligation to enforce whole-disk encryption in their existing devices receiving an upgrade to Android 5.0/5.1 as well as newly released phones running Lollipop out of the box. You can use JTAG forensics on compatible phones only if they are not using whole-disk encryption.

Once the acquisition is completed, an investigator can use a product such as Belkasoft Evidence Center for JTAG analysis. The product will automatically extract and analyze dozens of forensically important artifacts, including contacts, call logs, geolocation data messenger chat histories, browsing history, etc. 

Chip-Off Acquisition

Chip-off acquisition is a highly advanced, lowest-level destructive acquisition method requiring physical de-soldering of memory chips and using specialized hardware to read off their content. Chip-off acquisition is often used as a last resort. If whole-disk encryption is not enabled, chip-off acquisition will produce the full binary image of the device complete with unallocated space.

As opposed to computer hard drives, in the world of mobile forensic the lowest-level access is not always the best thing. Granted, chip-off acquisition will produce the complete raw image of the memory chip(s) installed in the device. However, the investigator will have to deal with issues such as block address remapping, fragmentation, and encryption. In the case of Apple devices, Samsung phones and many other devices encryption is enforced out of the box and cannot be bypassed during or after chip-off acquisition even if the correct passcode is known. As a result, chip-off acquisition is limited to unencrypted devices or devices using encryption algorithms with known weaknesses.

Nandroid Backups

Examiners analyzing a rooted Android device have yet another venue for extracting the full and complete file system of the device by generating a so-called NANDroid backup. Nandroid backups can be created by booting the device into a custom recovery (by either issuing an ADB command or, of USB Debugging is not enabled, by holding the Vol- and Power keys on the device) and selecting the corresponding menu item.

The following conditions must be met in order to produce a Nandroid backup:

• Bootloader is unlocked and custom recovery (e.g. CWM or TWRP) is installed, -or-
• The device is rooted, Busybox package installed and a Nandroid backup app such as this is used

Note that a Nandroid backup app can be used to produce a full NANDroid backup even if the bootloader is locked and no custom recovery is available when Busybox package is installed and a Nandroid backup app is used on a rooted device. Root is generally not required to make or restore Nandroid backups if the operation is performed through custom recovery.

If all of the above conditions are met, the expert can boot into custom recovery and make the device dump the content of its file system onto an SD card (if supported by the device) or an OTG flash drive (again, if supported by the device). There is also a small chance to discover existing Nandroid backups in the device being analyzed. Nandroid backups are standardized between different recoveries. NANDrpod is a de-facto standard format for storing Android system backups. 

Over-the-Air Forensics: Google Account

There are currently no full cloud backups available to Android users. Current versions of Android do not back up application data; instead, only the list of applications is generally backed up from Android devices. As a result, over-the-air forensics similar to iCloud acquisition is not available for Android devices. Apparently, this is about to change in the coming Android M. However, over-the-air forensics is far from being dead.

Google has mastered data collection. The company collects and maintains massive amounts of data from users of its services. The information is collected from all devices under the same Google ID including phones, tablets, desktop and laptop computers regardless of the operating system (if at least one service under the Google Account umbrella has been used).

Accessing such a massive amount of data is extremely tempting. With the user’s Google ID and password, forensic experts can access and analyze all information from the user’s Google Account including Gmail, Contacts, Google Drive data, synced Chrome tabs and bookmarks, passwords, registered Android devices and their location history, and a lot of other information.

Windows Phone 8 Forensics

Windows Phone 8 and 8.1 is a relatively new contender on the mobile arena. The platform enjoys a global market share of 4.2% (Q1 2015), while showing a much higher adoption rate in select markets (namely Spain, France, Germany, Italy and the UK).

The Windows Phone 8 platform does not by default use full-disk encryption on devices sold to consumers. However, Windows Phone devices used in corporate environments are always encrypted.

The Windows Phone platform is quite secure, and does not allow for logical or physical acquisition techniques. This means that traditional forensic acquisition tools such as Cellebrite, XRY, or Oxygen Forensic Suite cannot acquire information from a locked Windows Phone by connecting via a USB cable.

At this time, two vectors of attack exist for Windows Phone devices: over-the-air acquisition of the phone backup from Microsoft Account and JTAG/chip-off extraction.

Windows Phone Cloud Forensics

The Windows Phone OS comes with the ability to create periodic backups of the content of the device to Microsoft cloud storage. These backups work similarly to iOS, and contain much of the same information including application data, synced passwords, and device configuration settings.

Cloud backups can be downloaded from the user’s Microsoft Account with tools such as Elcomsoft Phone Breaker providing that their Microsoft Account login and password are known. Alternatively, the data can be requested from Microsoft with a warrant.

Windows Phone 8 JTAG and Chip-Off Extraction

Forensic acquisition of non-encrypted Windows Phones comes down to either JTAG or chip-off extraction. Since Windows Phone 8 is a Windows-based OS, it uses NTFS as a file system and has many similarities to desktop windows platform. Notably, these methods will work with most publically sold Windows Phone 8 devices.

Windows Phone: Sending to Manufacturer

Unlike Apple, Microsoft does not enforce full-disk encryption out of the box. For this reason, Windows Phone devices can be sent to their original manufacturers accompanied with a warrant to have information extracted. Since Nokia smartphones (now manufactured by Microsoft under its own name) constitute the majority of Windows Phone units, Microsoft will be the final stop for most cases involving Windows Phone acquisition.

Windows Phone Page File Analysis

A large portion of Windows Phones’ data is stored inside page files, including information from both running and background apps. However, due to a different device architecture, Windows Phone page file format differs from the one of desktop Windows, so one will need a forensic tool that specifically supports Windows Phone page file. Belkasoft Evidence Center was the first forensic product with proper WP page file parsing. Carving pagefile.sys files with Belkasoft Evidence Center will allow you to find multiple types of artifacts, such as web pages, pictures, chats, as well as registry files and many more.

BlackBerry 10 Forensics

Once being a major player having a 43% share of the US mobile market back in 2010, the Canadian manufacturer today is a distant fourth. With only 1.5% of the US consumer market, BlackBerry devices are still commonly used in corporate environments.

From the very beginning, BlackBerries were secure. BlackBerry smartphones used full-disk encryption, making chip-off acquisition fruitless. Early-generation devices had an exploit allowing the attacker to break the encryption key offline by running an attack on a device-encrypted SD card. This is no longer the case today.

At this time, the only vector of attack on BlackBerry smartphones is accessing a BlackBerry backup file (or making the device produce a backup via BlackBerry Link), obtaining the suspect’s BlackBerry ID and password and using the login and password combination to decrypt the backup. If the backup is available, you can analyze it with forensic tools that support Blackberry backups.

Breaking (or recovering) the password is not possible as information used for decrypting the backup is stored on (and is retrieved from) a BlackBerry server. However, a government request can be made to obtain the decryption keys from the company.

Conclusion

In our view, the future of iOS forensics lies with over-the-air acquisition. Since many users configure their devices to maintain cloud backups, the data can be obtained from iCloud (or requested from Apple). The alternative to this is logical acquisition via offline (iTunes) backups, which may not be available if either device passcode or backup password are not known. We consider physical acquisition to be dead for recent Apple devices used with the latest versions of iOS.

When it comes to Android, physical acquisition is quite alive, and is the first technique to attempt. If the device is not rooted, the passcode is not known, and the “USB Debugging” option is not enabled, the outlook does not look bright (but there are still possibilities such as bootloader exploits). JTAG acquisition remains a viable option for compatible devices (if whole-disk encryption is not used), while chip-off acquisition can still be used as a last resort on unencrypted devices.

Offline backups are not generally available to Android users, yet they can technically be produced with certain manufacturers (e.g. via Sony PC Companion for Xperia smartphones). There are no full cloud backups available either (the upcoming Android M is about to change that, bringing Apple-like backups to Android). However, a lot of information can be retrieved from the user’s Google Account, including synced Chrome bookmarks, passwords, list of registered devices and their geolocation information, mail (Gmail) and calendar events, and so on.

Android is slowly becoming a secure platform. More devices feature whole-disk encryption out of the box. Each version of Android is more secure than the one it replaces. Android 5 is secure enough to become an obstacle on the way of physical acquisition; many forensic tools still do not support physical acquisition of devices running Android 5 unless the correct passcode is known. Full-disk hardware encryption is about to become the norm for Android devices in near future (2-3 years). For now, physical acquisition (as well as JTAG forensics) remain viable extraction options for Android devices, slowly losing their significance as the platform becomes more secure with more devices shipped encrypted out of the box.

Google collects a lot of information about its users. This information is collected from all devices under the same Google ID including phones, tablets, desktop and laptop computers regardless of the operating system (if at least one service under the Google Account umbrella has been used). Obtaining information from the user’s Google Account can deliver lots of valuable evidence. We can certainly notice a trend here, with Android device forensics being complemented (and at a certain point replaced) by cloud-based analysis of the user’s Google Account.

The upcoming Android M will feature full device backups – just like iOS. When (or if) this materializes, forensic experts will be able to perform cloud acquisition of Android backups similar to iCloud acquisition they can do today. Android M will be released in less than a year. It will probably be a matter of at least two years before the new system takes a noticeable number in the Android OS version chart.

About Belkasoft Evidence Center

Belkasoft Evidence Center is an easy-to-use tool for both computer and mobile forensics. The tool has an extensive out-of-the-box support for hundreds of mobile apps, which makes Evidence Center a keen choice to look for digital evidence inside phone backups, dumps, and images. The product supports all major forensic formats, including iTunes backups, Android backups, Blackberry backups, UFED physical and logical dumps, chip-off and JTAG dumps.

Among 100+ mobile applications that the product is able to extract data from include browsers (Safari, Chrome, Firefox, Opera), mailboxes (Gmail, Yahoo Mail), various messengers (Skype, WhatsApp, Viber, Kik), and other apps (Facebook, LinkedIn, Foursquare, QIWI wallet).

Find out more at Belkasoft.com. To test the product, request a free fully functional trial license at http://belkasoft.com/trial.

About the authors

Oleg Afonin is Belkasoft sales and marketing manager. He is an author, expert, and consultant in computer forensics.

Danil Nikolaev is Belkasoft sales and marketing manager, co-author, and content manager.

Yuri Gubanov is a renowned digital forensics expert. He is a frequent speaker at industry-known conferences such as CEIC, HTCIA, TechnoSecurity, FT-Day, DE-Day and others. Yuri is the Founder and CEO of Belkasoft, the manufacturer of digital forensic software empowering police departments in about 70 countries. With years of experience in digital forensics and security domain, Yuri led forensic training courses for multiple law enforcement departments in several countries. You can add Yuri Gubanov to your LinkedIn network at http://linkedin.com/in/yurigubanov.

Contacting the authors

You can contact the authors via email: research@belkasoft.com
Follow Belkasoft on Twitter: https://twitter.com/Belkasoft
Subscribe to the blog: https://belkasoft.wordpress.com

See also:
Our previous article: Acquiring Windows PCs
All articles by Belkasoft

by Oleg Afonin, Danil Nikolaev, Yuri Gubanov

Mobile forensics is a moving target. In our recent article, “The Future of Mobile Forensics”, we described acquisition techniques that used to be state-of-the art back then. Weeks later, some things had changed already. Three months after the publication a lot of things have changed. Our publication was published on Forensic Focus and discussed in online forums, with readers pointing to certain inaccuracies in our article. In this follow-up, we will use up-to-date information to address the issues of concern in the original article.

iOS 8.4 Forensics

Little changed in iOS 8.x forensics since publishing our original article. Some advances have been made though. iOS 8.4 was successfully jailbroken by the TaiG team (http://www.taig.com/en/), and physical acquisition is once again available for jailbroken 32-bit iOS devices (e.g. with Elcomsoft iOS Forensic Toolkit). However, 64-bit Apple hardware (including iPad mini Retina, iPhone 5s and all newer models) successfully resists physical acquisition attempts. Full-disk encryption still rules out chip-off, and there were never JTAG ports in Apple hardware. Unallocated space is still not recoverable as iOS does not keep decryption keys for unallocated areas.

One of our readers drew our attention to an acquisition method often referred as “Advanced Logical”. Besides physical acquisition, this was the only method allowing a user to extract mail. As far as we know, Apple shut the door to advanced logical acquisition in iOS 8.3, so only older devices remain susceptible to this method. Since Apple does not publish detailed iOS version breakdown (counting iOS 8 in general without giving any insight on how many users switched to the latest release), we do not know what percentage of devices running iOS 8 is still susceptible to advanced logical acquisition.

Apple constantly tweaks iCloud security, making adjustments to lifespan of binary authentication tokens that can be used by experts instead of the user’s login and password (and bypassing two-factor authentication).

iOS 9 Forensics

The latest version of iOS is a hot topic in the world of mobile forensics. With as many as 61% of eligible iOS devices running the latest version of the OS by the 19^th of October 2015, iOS 9 is a major concern to the forensic crowd.

The share of Apple devices running iOS 9 reaches 61% and growing [source]

Featuring a so-called “rootless” security system, the new generation of Apple’s mobile OS integrated a number of techniques to constrain security research. While this did not stop the Pangu team from releasing a working jailbreak (http://www.downloadpangu.org/pangu-9-download.html), the existence of this exploit changed little in the way of acquisition. So let’s recoup which acquisition options are available for iOS 9 devices.

Physical acquisition

For devices running iOS 9, physical acquisition remains a limited theoretical possibility. While 64-bit devices (iPhone 5S and newer, iPad mini 2 and newer) are out of the question, even 32-bit devices running iOS 9 remain resistant to existing methods of physical acquisition – even if they are unlocked and jailbroken. As such, no existing forensic tools can do physical acquisition of *any* iOS 9 device regardless of jailbreak status and architecture.

Status: physical acquisition is currently unavailable for all iOS 9 devices. This may change in the future, as physical acquisition of 32-bit devices remains a theoretical possibility.

Advanced logical acquisition

Nope. Advanced logical acquisition does not work on iOS 9 devices. And, unfortunately for us all, it is very unlikely that it is going to work later.

Logical acquisition

Logical acquisition remains available via the usual routine. Apple changed the format and encryption used in iTunes backups, so you will need to update whatever forensic software you are using to the latest version in order to gain iOS 9 support.

Products such as Belkasoft Evidence Center support analysis of iTunes backups of devices running iOS 9 (as well as Android, Blackberry and Windows Phones). This product finds and analyzes data from several dozens of iOS applications, including both most common and some of the newest apps: Skype, Viber, WhatsApp, Kik, WeChat, Whisper, FireChat, MeetMe, Tinder, ooVoo, MeowChat, and many more:

Over-the-air acquisition

Things get tricky when we speak about cloud acquisition of iOS 9 devices. Apple changed a lot of things in iOS 9 when it comes to cloud backups. There is a new data format, and there is a different type of encryption used. The biggest change, however, is the location of the cloud backup. Previously stored in Apple iCloud, iOS 9 backups are now saved into iCloud Drive, a cloud service with very different internal mechanics.

At this time most forensic software manufacturers are yet to adjust their products to able to acquire iOS 9 data from iCloud Drive. One of the tools that is already capable of this is recently released Elcomsoft Phone Breaker version 5.0. It is worth noting that binary authentication tokens continue to work in their usual fashion, allowing you to bypass two-factor authentication if you happen to use a non-expired token.

Android Forensics

There have been few advances in this area. A recent vulnerability report by Check Point introduces a backdoor allowing experts to acquire some Android devices remotely. One of our readers noted that bootloader-level exploits are available for many Android models and used by Cellebrite in their acquisition tools to dump the content of Android devices without rooting the phone.

Certifi-Gate

A major security vulnerability was discovered in Android by Check Point Software Technologies and revealed at Black Hat in Las Vegas. Dubbed Certifi-Gate, the vulnerability exists on millions of devices such as those manufactured by LG, Samsung, HTC, and ZTE, allowing attackers gain total control over affected devices remotely. The vulnerability exists in remote support tools pre-installed by some manufacturers to Android handsets in order to help users solve problems with their devices remotely. These tools include TeamViewer, MobileSupport (by Rsupport) and CommuniTake Remote Care. Apparently, a vulnerability exists in these tools allowing an attacker to use their security certificate to take over an Android device.

There is no way for the end user to revoke or invalidate the certificates. Waiting for a patch or uninstalling affected tools is the only protection method, and even that may leave behind a vulnerable certificate. Check Point estimates several million devices to be affected by this vulnerability.

At this time, we are not aware of any forensic tool that is able to exploit this vulnerability to gain access to Android devices. We do not know if it is even feasible to exploit this vulnerability to gain such access.

Stagefright and Stagefright 2.0

This famous security vulnerability has potential, yet the possibility of its forensic use for the purpose of gaining access to the phone’s data partition is questionable. So far, no forensic solutions that use this exploit exist.

Bootloader Exploit

Most Android devices sold by reputable vendors (including Samsung, LG, SONY, HTC, ASUS and many others) feature permanently locked bootloaders to protect devices against booting unsigned code. Physical acquisition options for bootloader-locked devices are limited, especially in the latest versions of Android. On many devices, rooting devices even temporarily requires unlocked bootloader as a pre-requisite.

One of our readers pointed out that a bootloader-level exploit exists for many devices, and is successfully implemented by Cellebrite in its acquisition kit. Cellebrite UFED can successfully boot some locked devices with an unsigned patched boot image to allow extracting device image.

The exploit exists in many devices based on the Qualcomm reference platform and using Qualcomm reference software. As a result, devices using an affected kernel can be booted with a patched kernel image without proper security verification.

Cellebrite were able to exploit this vulnerability to boot many affected models with their own patched kernels. This is not an easy task since a unique kernel had to be built for each individual device. Several hundred models are reported to be affected by this vulnerability.

If available for a given device, a bootloader attack is arguably the most forensically sound acquisition method available. Since booting an external image does not write anything to the device nor change any part of the system image, it is able to consistently extract unmodified images of the device that will persistently pass hash checks. Alternative physical acquisition methods work by acquiring root privileges and installing acquisition agents onto devices being acquired, which inevitably alters the content of the device.

Bootloader exploits are device specific. Cellebrite claims support for most Motorola Android devices, selected Samsung, Qualcomm, LG GSM and CDMA devices based on Qualcomm chipsets. Caution is required when using bootloader exploits as some devices are known to wipe data partition when booting a custom image.

Custom Recoveries

We have been asked whether a custom recovery such as TWRP or CWM can be used to boot the phone (tethered boot) and pull data partition. While this can be technically possible, particularly on devices with unlocked bootloaders or having a known bootloader exploit, booting a custom (read: unsigned) recovery can (and, in fact, does) trigger the phone’s protection mode, causing the device to wipe the content of the data partition immediately upon booting into recovery and without giving any sort of advance warning. For this reason, we cannot recommend custom recoveries as a viable forensic acquisition method.

Windows Phone 8 Forensics

With Windows 10 Mobile coming soon and considering the small market niche occupied by Windows Phone devices in general, Windows Phone 8 is becoming a white elephant. However, developments have been made to Windows Phone acquisition as well. We have the following data to add to our previous publication.

Windows Phone 8/8.1 Encryption Explained

When mentioning Windows Phone acquisition, we have to talk about JTAG and chip-off acquisition. Since most Windows Phones are consumer devices, their content is not encrypted, and JTAG works properly. However, we have been contacted by a customer who claimed that they had an encrypted Windows Phone device, and asked for help.

Windows Phone 8 and 8.1 do not have an option for the end user to control encryption of Windows Phone 8.x smartphones. Instead, encryption can be enabled or disabled by a group policy specified by the administrator of the corporate MDM (Microsoft Mobile Device Manager). If encryption is triggered by an MDM policy, the device will automatically encrypt the content of the user partition with BitLocker. As a result, JTAG and chip-off will not return a decryptable image.

What about BitLocker escrow keys? According to Microsoft, the Windows Phone 8 OS does not come with the provision of maintaining escrow keys outside of the device (unlike desktop versions of Windows featuring downloadable BitLocker Recovery Keys). Since private users cannot manually activate encryption in Windows Phone 8, the usual approach of grabbing escrow keys from https://onedrive.live.com/recoverykey will not work for Windows Phone devices.

So what happens when one is trying to acquire an encrypted Lumia phone with BitLocker encryption enabled through corporate device policies (consumer devices do not)? While one can technically make Windows Phone ask for a BitLocker recovery key at some stage (e.g. http://www.windowscentral.com/bitlocker-cyan-update-problems-windows-phones), the escrow key itself is never created, saved, or uploaded anywhere.

Windows Phone Bootloader Exploit

As suggested by a reader, an additional acquisition option is available for select Windows Phone devices. Some popular Windows Phone 8 devices such as Nokia Lumia 520 are susceptible to a bootloader exploit that enables physical acquisition of said devices. Cellebrite’s UFED is able to perform physical acquisition of select Windows Phones devices. Unencrypted images acquired via this method will contain full raw dumps of the phone’s storage. Supported Windows Phone 8 devices can be dumped with Cellebrite UFED via a USB cord.

Belkasoft Evidence Center fully supports analysis of UFED images. The product will automatically analyze the image, locating and laying out for you its contents: calls and messages, chat and messenger apps, email boxes, payment system apps, and so on.

Windows 8/8.1/10 and BitLocker

We were asked about ways to recover BitLocker escrow keys from the corporate MBAM (Microsoft BitLocker Administration and Monitoring). If a corporate account was used on a certain Windows computer, and the company maintains a MBAM to manage BitLocker keys, the first thing to verify is checking whether the MBAM had a policy of not using escrow keys (https://technet.microsoft.com/en-us/library/dn145038.aspx). To access BitLocker escrow keys, experts can follow steps described in Microsoft documentation: https://technet.microsoft.com/en-us/library/dn656917.aspx

BlackBerry 10 Forensics

In our original article, we wrote that BlackBerry’s only reason for existence was its exemplary security model. Full-disk encryption, non-bypassable PIN lock and securely locked bootloader all contributed to its security model, rendering JTAG and chip-off acquisition attempts useless.

Immediately after publishing the article we started receiving comments from mobile forensic experts who successfully performed JTAG acquisition of new-generation BlackBerries running BlackBerry OS 10, including Q10 and Z10 handsets. Apparently, there was no encryption to be found anywhere on those devices.

We stand corrected. BlackBerry OS 10 does not activate encryption by default. The user (or the administrator of the corporate BlackBerry Enterprise Server, BES) has to explicitly activate encryption on each device. If it is not enabled, the user partition will be stored in plain, unencrypted form. We have been only working with BlackBerry phones coming from corporate headquarters, and never experienced a BlackBerry phone seized from a private owner. From our experience, there are very few BlackBerry 10 devices sold to private customers, and we have never encountered one “in the wild”.

Conclusion

As we can see, mobile forensics is indeed a rapidly moving target. The latest version of iOS remained unjailbreakable for much too long, only to be finally jailbroken days after we finished our report. Windows Phone can surprisingly be encrypted with desktop-like BitLocker even though there is no trace of such an option anywhere in the phone settings. BlackBerry 10 does not enable encryption by default (who could have thought?), while a newly discovered vulnerability makes millions of Android handsets susceptible to a remote hack. Developers of forensic tools explore new opportunities and add non-obvious acquisition methods, even if for a limited range of handsets. The world is moving so fast these days…

© Belkasoft Research, research@belkasoft.com

The Tool

Whenever you have a mobile device backup, dump or image, our Evidence Center will help you to quickly find a few hundred of different types of forensically important artifacts, such as mails and calls, chat messages and SMSes, pictures and payment histories. Powerful SQLite viewer will recover deleted items from freelists, journal files and database unallocated space.

Evidence Center does the same quality job with computer and laptop drives or images, what makes it a really versatile tool, able to ease digital investigation both for computer and mobile forensics.

You can request a free full trial license as http://belkasoft.com/trial.

About the authors

Oleg Afonin is Belkasoft sales and marketing manager. He is an author, expert, and consultant in computer forensics.

Danil Nikolaev is Belkasoft sales and marketing manager, co-author, and content manager.

Yuri Gubanov is a renowned digital forensics expert. He is a frequent speaker at industry-known conferences such as CEIC, HTCIA, TechnoSecurity, FT-Day and others. Yuri is the Founder and CEO of Belkasoft, the manufacturer of digital forensic software empowering police departments in about 70 countries. With years of experience in digital forensics and security domain, Yuri led forensic training courses for multiple law enforcement departments in several countries. You can add Yuri Gubanov to your LinkedIn network at http://linkedin.com/in/yurigubanov.

Contacting the authors

You can contact the authors via email: research@belkasoft.com
Follow Belkasoft on Twitter: https://twitter.com/Belkasoft
Subscribe to the blog: https://belkasoft.wordpress.com

About Belkasoft Research

Belkasoft Research is based in St. Petersburg State University, performing non-commercial researches and scientific activities. A list of articles by Belkasoft Research can be found at http://belkasoft.com/articles.

by Davide Gabrini, Andrea Ghirardini, Mattia Epifani and Francesco Acchiappati

Preface

During the hacking camp MOCA 2016, at the end of a talk held by Davide “Rebus” Gabrini on passcode circumvention methods on mobile devices, a bystander offered an intriguing challenge: he offered for research purposes a smartphone to find out if and how someone could crack it, overcome security and extract information.

The smartphone was a Jolla White 16GB JP-1301, equipped with the Sailfish 2.0.1.11 operating system. The device was previously reset twice by the owner and it was protected by a 5-digit PIN without encryption on the internal storage. Moreover, the developer mode was not active because it required a Jolla account that was not available.

The challenge was accepted during the following End Summer Camp 2016 (ESC 2016), where a dream team of Italian forensic experts addressed the problem at the Ville Forensics, among the curious eyes of other hackers. The team was composed of Davide “Rebus” Gabrini, Andrea “Pila” Ghirardini, Mattia “Lo Zio” Epifani and Francesco “Swappage” Acchiappati.

Acquisition

The phone did not expose a service similar to ADB like on Android devices, but only the internal data partition as a Mass Storage Device*. In this case it is possible to perform a logical copy of the visible files and folders, but we are bound to the MTP protocol limitations; although the user data exposed in this way can be significant, the method is still partial and unsatisfactory.

As expected, attempts to acquire the device using well known forensics products like UFED4PC and Magnet Acquire failed, as these tools couldn’t even detect the device at all.

*For accessing the internal storage, the device must be unlocked, and therefore the passcode is required.

Physical Examination

When tackling a challenge, the first step is to know your enemy, therefore the handset was dismantled in its entirety and the motherboard exposed. All connectors were ZIF and the shields were partially interlocking and partially attached using clips on the mainboard.

Two things stood out.

The first is that SOC is not visible since is a SOC with POP for RAM on top, so the big chip with 3TA78 D9QMM codes on top  is a RAM chip (produced by Micron) which hides the Qualcomm SOC behind (kudos Andrea Barisani).

SEQ Illustration \* ARABIC1: Device motherboard with a MediaTek SOC installed

The second is that there are a plethora of test pads on the mainboard. From a certain point of view this helps, but on the other hand it does not allow to easily find and understand which are the ones needed for accessing at a service level (JTAG where are you? Please reveal yourself!)

SEQ Illustration \* ARABIC2: A quick look at the test pads on the motherboard

We also tried to connect the phone without battery through the USB port the system to check if it has a behavior similar of a MediaTek SOC based device that, when connected over USB without battery, exposes a USB interface from which it’s possible to perform a system flash or memory dump.

By adopting a procedure found on the Internet:

1. remove the battery
2. insert the battery while holding the volume down button
3. while holding the volume down, press power and keep it pressed until the phone vibrates
4. release power and volume down
   the system goes into recovery mode.

When connected in this mode, the device is being heralded as a new USB device named “Generic RNDIS device”. On Microsoft Windows 10 the driver is not loaded automatically, but if you proceed by manually installing a “Generic RNDIS device” driver among those written by Microsoft, the device is properly recognized as a network card.

By connecting the phone to a Linux operating system, the device is instead immediately recognized as a USB Ethernet adapter. We could then enable the interface and notice that the phone runs a DHCP daemon that assigns an IP address to the computer.

The phone only exposes the port 23 (telnet); once inside, without being asked for any kind of authentication, it provides the access to a shell with root privileges.

Running the mount command to check the list of file systems we realized that the main partition of the system is not mounted, and the device (/dev/ mmcblk0) has a GPT partitioning with 28 partitions.

A recovery system based on Linux is undoubtedly an aid, as it’s already equipped with the whole toolchain that is needed to perform a physical acquisition of the phone’s flash memory: there are both “dd” and “netcat”, and therefore the easiest method is to use the existing network connection between the computer and Jolla’s smartphone to perform a “dd over netcat” acquisition.

This procedure requires a netcat listening on the virtual Ethernet of the computer (there are also many ports for windows platform) on an arbitrary port (ex. 8888), and then to launch these commands:

first on the computer:
nc -lvp 8888 | dd of=/path/to/destination/image.raw
and then on the phone:
dd if=/dev/mmcblk0 conv=noerror,sync | nc [ip of the PC interface] 8888

The whole process takes about 3 hours, but the result is a full physical extraction of the internal device flash memory, which we can now analyze using our favorite tools.

CHINEX

Since the phone disassembly revealed the use of an MTK processor, we also attempted the acquisition through the Chinex kit that is available with UFED from Cellebrite, but we didn’t succeed since the device couldn’t successfully pass the MTK Pinfind procedure. We had the same behavior using the other methods available for generic MTK devices.

Analysis

Once the acquisition was successfully completed, we obtained a 16GB bit stream image.

The first thing we wanted to check out was the partitioning. To achieve this goal we opened the image with X-Ways Forensics. GPT partitioning was interpreted correctly by the software and 28 partitions were detected. That made us think: great, we are the champions!

Another unlucky attempt was using UFED Physical Analyzer: predefined profiles, script chains configured for MTK processors and individual Python plugins were not able to extract useful information from the raw dump. The best result we get was with a generic profile for MTK device, which seemed to point out a few email messages and deleted messages but then we realized that most of them were false positives. Again a dry shot.

Another part of the team started analyzing the individual partitions with X-Ways Forensics and found out that the largest ones (and therefore potentially containing juicy information) were number 24 (Linux Swap, even if it was recognized as “Linux Filesystem”, as big as 500 MB) and number 28 (13.5 GB). Unfortunately, we had another issue: the partition is formatted with the bleeding edge BTRFS file system, which, while we are writing this document, is not supported by either X-Ways or UFED PA. We had the same outcome during image inspection with FTK Imager and Autopsy, but the same would also be achieved by Encase or FTK: none of the most popular forensic analysis software, yet, supports BTRFS. But Linux does!

We then decided to “split” the work: someone decided to mount the file system on a Linux workstation for pulling out a TAR archive containing all the allocated data, while the remaining team members started to carve at raw level searching for information and fragments of meaningful content.

The first activity was completed successfully and the TAR file was turned back to X-Ways Forensics: as we could have expected, existing files on the device do not contain any data because the device had been reset by the owner before the delivery.

So what was left to explore was the path of the unknown: the raw data. We started with a byte-level carving with X-Ways Forensics and PhotoRec, while seeking more structured information with Internet Evidence Finder (IEF) and Bulk Extractor.

After a few seconds X-Ways extracted pictures related to Internet browsing activities on medical websites and shortly after both IEF and Bulk Extractor provided a long series of keywords used on Google and related to a specific medical treatment. The carving continued and some SQLite databases were detected (569 by X-Ways, over 600 by PhotoRec). Among them we identify the Cookies database, which provided us with the URL to which the medical images belong: we were then able to pinpoint the Google search and medical web site access to a specific date and time.

We continued with the file carving and we found the screenshots of a GPS application, probably the one that was installed by default on the system. From these screenshots it was possible to figure out where and how the owner moved with the device and, in some cases, it was possible to determine exactly the origin and destination of the trip.

As a final activity we decided to try to trace communications with third parties in an attempt to uncover as much as possible about the identity of the device owner. We managed to extract a complete email in EML format: in this email we found the sender and the recipient, indicating the name, last name and, of course, the email address.

At this point we launched a keyword search using the address of the sender and recipient, and this allowed us to recover about 400 matches: a detailed analysis of the results allowed to recover about 200 email messages, only partially overwritten but full of information about the owner’s job and several customers’ names. We of course also found private and personal emails exchanged on the phone.

At this point we decided to stop as the collected results were enough to prove that even when a phone is not supported by common forensic tools and is subjected to reset, it is possible to successfully retrieve meaningful data useful during investigations!

Happy with the results, we decided that it was time to move on to the next beer, but not before enjoying the phone owner’s reaction and his face going pale, when we began asking him if he knew anything about the subject matter and whether he had been in certain places.

ESC “Ville Forensics” beats Jolla Phone 2-0 (at least!).

by Patrick Siewert, Pro Digital Forensic Consulting

It’s not secret to those involved in the study and practice of mobile forensics that Apple likes to throw us curve balls with almost every new iteration of the iOS operating system. It turns out, iOS 10.2 is no different (released December 12, 2016). A conversation began recently on the IACIS list serve and got me thinking about trying to problem solve and figure out a work-around, so I spent the past day or so trying to do just that. (For those interested, I also wrote an article about the problem-solving aspect of digital forensics and you can read it here.)

The background is as follows: When an i-Device user running iOS 10.2 connects the device to a computer, they are automatically prompted by iTunes for an encryption password:

When the option to encrypt is selected, a prompt is displayed for an encryption password, which may be entirely different from the device passcode or the iTunes account password:

This default encryption prompt becomes an issue for examiners due to the fact that users often don’t remember these passwords because in the age of cloud-driven storage and wireless *everything*, users don’t routinely connect their devices to a computer and therefore, don’t remember the encryption password. This was the issue raised by another examiner on the list serve and it prompted many replies and potential work-arounds because when examiners attempt to analyze the extractions from these devices, they’re encrypted. Pretty much game over.
(For additional background on this issue as was introduced in iOS 10.0.1, please refer to Heather Mahalik’s blog on the topic located here.)

Before iOS 10, I ran across this problem a few times with iOS devices. My work-around then was to simply connect the device to a foreign computer (i.e., one that it had not been connected to previously) and de-select the encryption option and create another unencrypted backup, then pull the new backup into any number of commercial tools for analysis. This doesn’t work any longer because when the device is connected to a foreign computer and encryption is de-selected, iTunes prompts for the encryption password for verification. Darn the luck!

Methodology

For this testing, I used an iPhone 6, which we have on-hand for testing purposes. The phone has a handful of iMessages, pictures, videos, Kik messages and some other data on it. I updated the phone to iOS 10.2 and encrypted the backup on the Mac side of my forensic machine. I then switched to the Windows side and attempted to create another backup by de-selecting the “Encrypt iPhone Backup” option, which is when I quickly learned that in all updated versions of iOS and iTunes, the encryption password is needed to complete this action:

Being that I know the encryption password, I entered it and created a new backup via iTunes on my local machine. To be sure, unless you want to use a tool such as Elcomsoft to brute-force the password or attempt a dictionary attack based upon investigation and/or social engineering, you’ll need the encryption password to make this work. But even having the password doesn’t get us too far with Cellebrite under the current version.

How Does UFED Handle This?

Cellebrite Universal Forensic Extraction Device (UFED) Physical Analyzer (PA) has heretofore been one of the best commercial tools for acquiring and analyzing iOS devices. Indeed, you can use UFED PA to attempt a brute-force dictionary attack on these extractions if you have decent intelligence through additional investigation or social engineering by pointing UFED PA at a text file containing case-specific dictionary words:

In conducting this test and comparison, I used the latest version (as of this publication) of UFED PA, 5.4.7.5, which was released just 24 hours prior.  As you can see from the below image, even when the proper password is entered after an advanced logical extraction directly from the device, UFED PA still doesn’t parse the “analyzed data” into chats, web history, etc. like it used to with older versions of iOS:

That’s it.  That’s pretty much all we get.  When the “Backup” folder is expanded, we are presented with this:

The red arrow is used to illustrate that the listing of files keeps going. Further inspection of these files indicates it would be a very lengthy, tedious process to try and located you sms.db, let alone DBs from many third-party apps which can be crucial in many cases.

My next step was to create an unencrypted backup through iTunes to see if that could be pulled into UFED PA and parsed a bit nicer. It wasn’t. We are presented with a file structure identical to that which is created by iTunes, with one folder with a long alphanumeric name and dozens of sub-folders, each with a shorter alphanumeric designation. The only data that was automatically parsed in the backup was images, videos and device locations. Again, combing through all of this for your crucial evidence and databases can be a time-waster, so what else can we do? Try to use another tool!

How About IEF?

So now we have an advanced logical image in UFED PA (that is all but useless) and a backup through iTunes that is only slightly better when viewed through UFED PA. Now, I profess that push-button tools are the end of true forensics. Anyone who reads this blog knows that I firmly believe that you have to know and articulate where the data is located and how it got there. But sometimes, certain tools can help point us in the right direction. Enter Magnet Forensics’ Internet Evidence Finder (IEF, v. 6.8.4.3639). IEF is widely accepted as one of the best and easiest tools on the market to use. I love it for helping me out, for getting me a leg up on where I need to look, perhaps even with another tool. So I decided to try and pull the iTunes backup into IEF, just to see what would happen.

First, I selected the Mobile and iOS options in IEF:

Then, I selected “File Dump” to point IEF where I wanted it to look.

The next decision is probably the most crucial to the process.  I selected the Windows file browser, then navigated to the (now exported) iTunes backup folder – the one with the very long alphanumeric name.  But then I drilled down to the sub-folders and files immediately under the parent file and selected all of them, including all of the .plist and .db files:

Next, I had to tell IEF what I wanted it to look for.  The data set isn’t large and I’d rather have too much data to sift through than not enough, so I just chose everything and selected “next”:

It’s important to note here that I conducted a subsequent test selecting “iOS Backups” ONLY and did not receive a favorable outcome. Also, if the backup or device is encrypted, IEF will prompt for a password.

The processing took about 15 minutes. Once it was finished, the data was parsed out as you would have expected pre-iOS 10.2:

I have highlighted the file path of the location of the sms.db in the above image because now, IEF has told us where to look in UFED PA or other tools.  Consequently, we can now switch back to UFED to examine and export the .DB files as necessary.  The below image shows what we find in UFED PA when we follow the file path indicated through IEF in the iTunes backup of the iPhone:

So to wrap it up, get your encryption password, create a backup using iTunes on a foreign machine and bring the backup into IEF to point in you the right direction. From there, you can expand to UFED PA or another tool of your choosing, if necessary.

Take-Aways

There are several important things to take-away from this experiment. First, it has become vital in mobile forensics to have more than one tool at your disposal. Having access to two or more tools can actually save you time and effort. Imagine how tedious it would have been to sift through all of those folders (none of which contained a .db file extension by the way) to find the text messages or other pertinent data.

Second, the problem-solving aspect of “boots on the ground” forensics, especially mobile forensics, cannot be ignored. To make problem-solving a little easier, start to ask about encryption FIRST and save yourself some grief down the road. It’s also becoming apparent that we simply cannot rely on the pretty push-button features of many tools in the coming years, especially with regard to Apple and their iOS… and it’s only going to get more prevalent.

Finally, things are always changing. Never forget that. When I was conducting this testing and writing this article, I did so knowing full well that Cellebrite may push out a solution in the next week or two. But until those updates happen, we all need to collaborate to find solutions to these issues, because just like no one tool can do it all, no single examiner can always do it all.

About The Author

Patrick Siewert is the Principal Consultant of Pro Digital Forensic Consulting, based in Richmond, Virginia. In 15 years of law enforcement, he investigated hundreds of high-tech crimes, incorporating digital forensics into the investigations, and was responsible for investigating some of the highest jury and plea bargain child exploitation investigations in Virginia court history. Patrick is a graduate of SCERS, BCERT, the Reid School of Interview & Interrogation and multiple online investigation schools (among others). He continues to hone his digital forensic expertise in the private sector while growing his consulting & investigation business marketed toward litigators, professional investigators and corporations, while keeping in touch with the public safety community as a Law Enforcement Instructor. Email: ProDigitalConsulting@gmail.com; Web: www.ProDigital4n6.com

by Oleg Davydov, CTO, Oxygen Forensics

Modern smartphones are much more than just a device for voice calls. Now they contain a lot of personal data – contact list, communication history, photos, videos, Geo tags etc. Most smartphones can also work as a modem.

Almost every modem is Hayes-compatible which means it supports commands of the AT language developed in 1977 by Hayes. Every model supports some basic set of commands which is defined by the manufacturer. Sometimes this set can be extended and can contain very interesting commands.

Let us study behavior of an LG smartphone. When you connect it to the computer by USB you get access to the modem automatically (pic. 1). What is peculiar for LG is that the modem is available even if the phone’s screen is locked.

Pic. 1

Thanks to that, we can learn some useful information about the phone using AT commands even if the phone is protected by a password. (pic. 2).

Pic. 2

To learn what commands are supported by this model we have to examine its firmware. For example, for Android smartphones we only need to research the file /system/bin/atd. The pictures 3-5 demonstrate some AT commands for LG G3 D855 found in this file.

Pic. 3

Pic. 4

Pic. 5

It is clear that the phone supports most of the basic AT+ command set which can be used to extract common information about it (pic. 5). But of the most interest are LG proprietary commands (commands of AT% type). These commands (like AT%IMEIx, AT%SIMID, AT%SIMIMSI, AT%MEID, AT%HWVER, AT%OSCER, AT%GWLANSSID) return basic information about the phone. Among them is hiding a real pearl – the command AT%KEYLOCK (pic. 4). As you might guess this command allows you to manage screen lock state. In order to study this command behavior we can run a debugger and use the cross-link to find its handling function code. You can see this in pic. 6.

Pic. 6

When the command AT%KEYLOCK is called, the corresponding function, depending on the argument count, calls either lge_set_keylock() or lge_get_keylock() function from the /system/lib/libatd_common.so library. Pic. 7 shows the code of function lge_set_keylock().

Pic. 7

As you can see from pic. 8, if you pass to the function lge_set_keylock() the value “0” = 0x30, it will eventually call the function which would remove the screen lock whatever method had been used to lock it (you can use PIN, password, pattern or fingerprint to do that). Then it will return the string “[0]KEYLOCK OFF” (pic. 8).

Pic. 8

It becomes obvious that the command AT%KEYLOCK=0 allows you to remove the screen lock without any additional manipulations.

It’s worth mentioning that this command only removes the screen lock without affecting user settings. The command works as described: it writes zero value (which means unlock) to the special RAM area which stores the value responsible for screen lock. This means the command does not modify ROM in any way. This behavior is forensically sound because no user data is touched and after reboot the smartphone will return to the locked state. The command does not allow the investigator to find the screen lock PIN / pattern / password; it just removes it for some time.

To perform this analysis we used an LG G3 D855 model (with V20g-SEA-XX firmware). However, the aforementioned AT commands have been proven to work on other LG smartphones as well (LG G4 H812, LG G5 H860, LG V10 H960 etc). All these models support this approach.

Therefore it’s more than easy to unlock the phone. All you need to have is an LG Android smartphone turned on and connected to a PC by USB. This backdoor is obviously left by LG for its service software but can be used for forensic purposes as well. But bear in mind that criminals can also use this approach.

Oxygen Forensics was founded in 2000 as a PC-to-Mobile Communication software company. This experience has allowed our team of mobile device experts to become unmatched in understanding mobile device communication protocols. With this knowledge, we have built innovative techniques into our Oxygen Forensic® Detective allowing our users to access much more critical information than competing forensic analysis tools. We offer the most advanced forensic data examination tools for mobile devices and cloud services. Our company delivers the universal forensic solution covering the widest range of mobile devices running iOS, Android, Windows Phone, BlackBerry and many others. Oxygen Forensic® products have been successfully used in more than 100 countries across the globe. More info at www.oxygen-forensic.com

by Robert Craig and Michael Lambert

Abstract

Samsung devices are a large portion of the Android OS market.  Samsung has its own Internet Browser, “sbrowser”, installed onto their devices.  All web browsers leave artifacts from user activity.  The “sbrowser” cache files were similar to other browsers.  An embedded source URL gave insight where the cached image came from.  Looking at Internet History, cookies, and the cache file itself, an investigator can gain insight where the cached image came from and the likely web page it came from.

Contents

Abstract. 2

Introduction. 3

Literature Review.. 4

Method. 4

Findings. 6

Conclusions. 11

Reference List. 12

Appendix. 13

Authors. 14

Introduction

Mobile device examinations have become an integral part of criminal investigations.  Suspects use the device to plan and perpetrate their crimes.  One aspect of an investigation is what Websites the user visited.  Mobile devices have the options to use multiple web-browsers such as Chrome and Firefox.

Samsung began rolling out the latest version of its Android-powered Samsung web browser found in the latest Galaxy smartphones, and it represents Samsung’s desire to create a browser built around compatibility, functionality, and ease of use [1].  On the Samsung Developers web page it explains, “Samsung Internet for Android is a Simple, Fast, and Reliable web browser for your phone and tablet. It has replaced the Android Stock browser on Samsung Galaxy devices since 2012 to provide a browser highly optimized for our devices.’[2].  In the figure below (Fig. 1), Samsung is the leading producer of smartphones.  This means as mobile device investigators encounter the Samsung devices they will see more and more of the Samsung Browser. There is also the possibility the browser can be on other devices. The Samsung Browser is also available for download on the Google Play Store.

Fig. 1

For the purposes of this paper the Samsung Browser will be called the “sbrowser”.  This is from the Android Samsung Browser package name “com.sec.android.app.sbrowser”(Note how it is with a smaller case “s”).

The sbrowser is similar to any other web browser found on an Android mobile device.  It will store Internet history, cookies, and web page cache files.  The files located in the cache can assist investigators in identifying where the cached images came from by reviewing the Internet history and cookies, a correlation with the cached images can be found.

Literature Review

Cache files are artifacts that are left over from webpage visits.   The presence of metadata within a cache may be an integral piece of evidence for an investigation.   This however is hampered by issues retrieving that data.   Storage location and type may be different depending on the specific app.

Hoog 2011[4] states that the webview cache database provided the metadata about the cache files stored in cache directory [5].   In Chandrakumar 2014 [6], it is reported there is large cache format diversity surrounding apps.  App developers are at liberty to choose which format their cache would be appropriate for them and single apps may use multiple cache libraries.  These cache structures are often not documented.  Chandrakumar 2014 spoke of analyzing generic caches, in doing so Chandrakumar was able to map data found inside of the generic cache folders.  This data included but was not limited to constants for header records, length of URL and the URL of the cached data.

Martini, Do and Choo [5] speak of how cached files “may expose evidential data that was temporarily stored by the app; however that non-standard binary format is commonly used and unless that format can be decoded the binary analysis of the strings may be the only straightforward means of analysis.”  Martini, Do and Choo advised format of the files are subject to the choice of the developer but things such as header analysis and other standard forensic techniques could be used to determine the potential file type which could be used to potentially decode the file.  If decoded these cache files could be extremely useful to cases as it may expand upon traditional web history data and confirm site visits, times of visits and possible content of the site visited.

Method

For the mobile device a factory reset Samsung S5 (model SM-G900R, US Cellular, Appendix A) was used.  The Android OS version on the device was 5.0.  The mobile forensic software used to acquire physical acquisitions was Cellebrite’s UFED4PC v5.2.0.689.  Cellebrite’s Physical Analyzer 5.2.5.24 was used to analyze the data.

A base physical image was done first on the device (Appendix B).  Looking at the App Data Storage Directory the com.sec.app.sbrowser cache is empty (Fig. 2).

Fig. 2 – Screen shot from Physical Analyzer 5 of the base physical extraction

A test web page was created for web browsing (Fig. 3).  This allowed control of the content on the page.  The purpose of the testing focused on what images would be stored in the cache. The purpose of Minion images used in this research was mainly used because of their bright color and distinct characteristics which assisted in analyzing numerous image files.

Fig. 3a

Fig. 3b – Web Page and the inspect element. Note the image file path for the minion holding bananas

Fig. 4

The mobile device was then connected to the Internet via a Wi-Fi connection.  The sbrowser (Fig. 4) was opened. The home page was Google.com.  The URL of the test web page was typed in, and the sbrowser displayed the web page.  At that time no further browsing was done.

The same procedure was then done on the device to acquire a physical image (Appendix C).  The second physical image was placed into Cellebrite’s Physical Analyzer 5 (PA5).  It should be noted here a physical acquisition will likely extract the Cache folder.  It has been experienced by the testers that a logical or file system extraction will not extract the Cache folder contents.

After the second physical extraction the mobile device was turned back on and reconnected to the Internet.  A revisit to the test web page was done.  Prior to returning to this test web page, it was edited (Fig. 5). The image of the tattooed man smoking and talking on a mobile device was changed to another minion.  A third physical image (Appendix D) was done using the same acquisition procedure.

Fig. 5

Findings

There were notable artifacts located in the Cache Folder.  The full path to the cached images was /Root/data/com.sec.android.app.sbrowser/cache/Cache/.  The web page images are embedded in a cache file located in the folder.  The carved web page image file name has hexadecimal characters and is 16 characters long and ends with “_0”.  This is how Cellebrite’s PA5 automatically carved the image out and named it.  The images from the cache were bookmarked (Fig. 6).

Fig. 6 – Notable images in the cache from the 2nd physical extraction.

The cache file does contain additional information.  It contains the URL of where the web page image came from.  This URL actually points to the original image that is used to build a webpage.  This URL is located at the File Offset (FO) 24 (0x18).  This seems to be consistent with all the cache files examined.  The first (FO 0x0) 9 bytes of the cache files had the same header.  At FO 12 (0xC) for at least 2 bytes or possible 4 bytes the hexadecimal in little endian will give the length of the URL.  At FO 16 (0x10) for a length of 4 bytes is a value.  This value at first was thought to be a date and time value.  Using tools DCode v4.02a and RevEnge v1.0.34 to try and find a date and time value were unsuccessful.  It was thought that these bytes may be in reference to the size of the embedded image.  The values or combination of the values did not add up to the size.  After the embedded image there is additional information (discussed later) that has server connection information.  The value of the 4 bytes or a combination of values did not match the location of the end information.  Also, the values did not add up to the length of the file.  Below is the .jpg of the minion holding bananas in hex view (Fig. 7).  The header, size of URL, URL, and the .jpg header can all be seen.  Note the URL in the web page cache file is similar to the URL in Fig. 3.

Fig. 7

Fig. 8 shows the end of the cache file has additional information.  This begins after the end of the embedded image.  There is a server response that the request has succeeded (HTTP/1.1 200 OK), and the date and time.  8 bytes before HTTP/1.1 200 OK is a 3 byte long value, in this case 0xFC 9A 2E.  This value somehow is connected to “the-real-index”.  The browser appears not to store simple cache index data in the index file.  Chromium uses a similar indexing.  As explained by the Chromium Org, the “index” is extremely static, and the actual index data should be stored in a file called “the-real-index”[7].  It was observed that sbrowser has an “index” file that is small in bytes, but has a larger “the-real-index” file.  The 3 byte value discussed earlier was a constant in “the-real-index”.  In further testing an additional 3 byte value appeared during another web browsing session.  The 3 byte values appear to connect web browsing sessions with the cache file, and “the-real-index”.    The name of the server is also provided.  The last modified date and time listed is of the actual image for the web page.

The actual cache file has its own date and time created, modified, and access.  When the cache file is created on the device it will coincide with the time visiting that page.

Fig. 8 – Example of a last portion of the cache file.

The web history from the first physical extraction shows the last time a user visited a website (Fig 9). It should be noted that the time of the last visit is 09/13/2016 11:34:26 (UTC-5), and the server date and time above (Fig. 8) shows 09/13/2016 16:34:27 (GMT).  The date and times are the same with consideration to the time zones.

Fig. 9

The third acquisition was analyzed again in Cellebrite’s Physical Analyzer.  The image of the new minion (5f713e709b7a2f71_0) was created in the cache and that cache file’s creation, modified, and last accessed coincide with the time the page was visited.  The other two minion web page image cache files f053d3a13acf2646_0 & c733c38b87f0b3b3_0 (Fig. 10) last modified date and times changed.  The last modified date and time changed to the time that corresponds with the time the test web page was revisited.  However the date created and last access stayed the same.  The file itself did not change though.  The MD5 Hash value of the file from both physical extractions remained the same.  The minion web page image cache file that was no longer on the test web page dates and times stayed the same.

Fig. 10a

Fig. 10b

FTK v3.3.0.0 Imager used to display properties of the file below from the second and third physical extractions. The MD5 Hash value for both files was 809316767a22d168fefbadc92dcedcc8.

Internet Evidence Finder (IEF v6.8.2.3062) was also used on the third physical extraction.  This was mainly used to verify the images.  IEF did report the file the web page image was at.  IEF did display the image.  When it was viewed in hex view the entire cache file is viewed and not just the embedded image.  Just like Physical Analyzer, there is no reference in the report to the image’s resource URL.

Fig. 11 – Internet Evidence Finder used on 3rd physical extraction

Conclusions

A controlled web page was used to add cache contents to the mobile device.  The first (base) physical extraction showed the Cache folder to be empty.  The mobile device after visiting the test webpage populated the Cache folder with web page cache files.  There was a source URL for an embedded image within the web page cache file.  We know the date and time when we visited the web page from the Internet History.  Cookies also showed the date and times of visits to the test page.  These Cookies will show session times and first visits also.  Date and times coincided with the web page cache file and the domain name of the URL within Internet History.  The URL in the web page cache file had the same domain name as the web page as visited.  There is a strong correlation between the cached image file and the web page visited in the Internet History.  It is likely that a user could have viewed the cached image while visiting the specific web page that has the same domain name as part of the URL. In testing “http://disposablewebpage.com /turn/109EiHBBCrt” was the specific webpage.  The cached images made reference in the source URL to “http://disposablewebpage.com/”.  There is a relationship with the domain.  However, the specific webpage of the source URL in the web page cache files was not referenced.  So, in the test scenario if two different pages were used, it is possible that the source URL would have the same domain name in it, but not referenced to the exact webpage.  Web pages will pull the resource from where the image is stored, either from cache or the server.

The images in the cache can be correlated to a web-site that was visited.  The files give an indication that images found in the cache are the likely ones viewed while the user visited the specific website with the same domain name.

More research needs to be done on “the-real-index” and how it correlates with the cache files.  This research focused on the embedded source URL and embedded web page cache image.  Findings could show a user likely viewed the image stored in the cache file while visiting a web page at the time.

There are constants that do appear when within the cache.  These constants come before and after the image in set locations.  It is unknown if these constants change between devices or OS versions.  These constants also appear in the deleted cache files which would indicate that there is cache information to be gained, if not already overwritten, in the unallocated space of a device that can be linked to a recovered image.  Additional research needs to be completed in this area.

Reference List

[1] Spence, E. (2016, January 31). “Samsung Challenges Google as New Android Browser Beats Chrome”. http://www.forbes.com/sites/ewanspence/2016/01/31/samsung-android-browser-v4-html5/#12f1ed7e45ce.

[2] Samsung. (2016, March 21). http://developer.samsung.com/technical-doc/view.do?v=T000000202.

[3] Victor H. (2015, May 25). “Top 10 Smartphone makers in Q1: Sony and Microsoft Drop Out of Picture, Chinese Phone Makers Take Over.” http://www.phonearena.com/news/Top-10-smartphone-makers-in-Q1-2015-Sony-and-Microsoft-drop-out-of-the-picture-Chinese-phone-makers-take-over_id69643

[4] Hoog, Andrew (2011). “Android Forensics Investigation, Analysis, and Mobile Security for Google Android”.  Syngress, and Imprint of Elsevier.

[5] Chandrakumar, F. (2014, June 2). “An evidence-based Android cache forensic model”

[6] Martini; B., Do, Q.; Choo, K-K R (2015). Chapter 14- “Conceptual Evidence Collection and Analysis Methodology for Android Devices” In Ko R and Choo K-K R, editors, Cloud Security Ecosytem , pp. 285-307, Syngress, and Imprint of Elsevier. http://dx.doi.org/10.1016/B978-0-12-801595-7.00014-8.

[7] gavinp@chromiun.org  (2013, Apr 11). “Do not store simple cache index data in “index””. https://bugs.chromium.org/p/chromium/isses/detail?id=230332.

Appendix

Appendix A

Appendix B

Appendix C

Appendix D

Authors

Robert Craig is a Detective with the Walworth County Sheriff’s Office in Elkhorn, WI.  He has been involved in digital forensics since 2009.  He obtained his EnCase Certified Examiner (EnCE) in 2009.  He also received formal training on the Cellebrite software in 2013. While employed at the Sheriff’s Office and in training Robert has conducted hundreds of examinations of digital evidence such as mobile devices and hard drives.  In 2016 he completed a MSc in Forensic Computing and Cyber Crime from University College Dublin, Dublin, Ireland.

Michael Lambert is a Detective with the Walworth County Sheriff’s Office in Elkhorn, WI.  He has been involved in digital forensics since 2013.  He received formal training on the Cellebrite software in 2013. While employed at the Sheriff’s Office and in training Michael has conducted hundreds of examinations of digital evidence such as mobile devices.

by K M Sabidur Rahman & Matt Bishop (University of California Davis) and Albert Holt (NSA)

Abstract

The Internet of Things (IoT) comes with great possibilities as well as major security and privacy issues. Although digital forensics has long been studied in both academia and industry, mobility forensics is relatively new and unexplored. Mobility forensics deals with tools and techniques that work towards forensically sound recovery of data and evidence from mobile devices [1]. In this paper, we explore mobility forensics in the context of IoT. This paper discusses the data collection and classification process from IoT smart home devices in details. It also contains attack scenario based analysis of collected data and a proposed mobility forensics model that fits into such scenarios. The paper concludes with a detail discussion of related research problems and future work.

Introduction

Although mobility forensics for IoT devices is not a well-defined area of knowledge, this description summarizes the idea in general: “Mobility forensics addresses technology’s movement toward mobile devices (smart phones, tablets, small computers) and specialized tools and techniques needed to successfully recover data and evidence from those devices” [1].

While many IoT sensors are stationary, many others are mobile. To mention a few, sensors such as FitBit, sensors within Smartphones, Car Area Network (CAN) sensors are mobile. The context of computing is evolving rapidly and significantly, driven by new mobile and IoT devices in our homes and industries. Successful forensics in this kind of device needs new and updated tools and specialized techniques. Unfortunately, not much has been done so far in the field of IoT digital forensics. One reason is that IoT devices are not widely deployed and industry is focused on implementing the technology rather than securing it. But lack of security in IoT devices may lead to catastrophe in futuristic scenarios such as the Smart City [2] and Smart Grid [3]. This paper takes a close look at security, privacy, and vulnerability issues with IoT devices from a forensic point of view. As an example, we have analyzed the data collected by an IoT smart home device called “Sen.se Mother” [4], and have developed scenarios showing how the collected data can help with forensic investigations. We then propose a model to determine the implications of collected data and discuss what it adds to the digital forensics literature. This is a first such attempt towards mobility forensics for the Internet of Things. Although this paper’s findings are based on IoT devices in smart homes, the results can be generalized to IoT environments, such as industrial and other installations.

This paper is structured as follows. We review the literature in section 2 and discuss a problem statement in section 3. Section 4 presents our methodology and procedures and section 5 shows our results. Section 6 covers discussion and section 7 contains guidance for future work.

Literature Review

Although the field of IoT security research is relatively new, there has already been much interesting work. Weber [5] introduced some of the security, data authentication, access control and client privacy issues in IoT. Jing et al. [6] discuss IoT security in general and divide IoT architecture into layers to ensure more security; they also tried to solve different cross layer issues. Perumal et al. [7] talk about forensic investigation in machine-to-machine (M2M) communications and the Smart Grid. Hegerty [8] discusses the fundamental challenges IoT poses to digital forensics and identifies key areas that solutions should address.

An interesting paper by Oriwoh et al. [9] covers the modeling perspective of IoT forensics. The paper presents an example IoT crime scenario and attempts to identify sources of evidence within it. This paper also discusses how IoT digital forensics differs from classic digital forensics and emphasizes the requirement for a “Next Best Thing (NBT) Model of digital forensics” [9]. Work done in our paper moves the research closer to the goal. Valera et al. [10] cover a special application of IoT: medical devices. They also suggest that their set of security techniques and cryptographic SIM cards can make IoT devices with RFID/NFC more secure. Arias et al. [11] have used Nest Thermostat and Nike++ Fuelband as example IoT devices to discuss some common design practices and their implications for security and privacy of these devices.

Copos et al. [12] collected network data from an IoT device, the Nest Thermostat, using dumpcap, a network traffic sniffing tool. Then, from the collected data, they tried to infer whether someone is home. Peisert et al. [13] show how using a model can result in forensic analysis requiring a much smaller amount of carefully selected, highly useful data. In our paper, we present a new model that summarizes the finding from IoT devices and helps the investigator follow a structured process of investigation.

Problem Statement

The “Internet of Things” is not just a dream anymore. In the form of smart grid, smart homes, smart devices, smart cars (V2V), and M2M (in general), IoT is already here. Lack of security in IoT reflects the lack of security in cyberspace. This raises several important questions:

• Are those devices secure in the environment in which they function?
• How much are we aware of privacy issues?
• Can the new type of data and traces from these devices be utilized for forensic purposes, and if so, how can we collect and model them efficiently?
• What kind of data and attack related information and semantics can be retrieved from IoT devices?
• What can we learn from looking at IoT device data trails?
• How useful is the above mentioned data for forensic purposes?
• What are some possible scenarios where such data and information can aid forensic investigations?
• How is collected data interpreted in those scenarios?
• What new questions arise in addition to those posed by classic digital forensics?
• Can we develop a new forensic model to incorporate these questions?

These questions are very important for individuals, organizations and governments. Unfortunately, not much work has been done in the field of IoT mobility forensics. This paper is a significant step towards filling the gap.

Methods and Procedures

IoT Device Selection and Setup

We studied multiple IoT devices [4, 14, 15] and considered two of them.

• “Sen.se mother” [4] comes with a hub (called Mother) and 4 sensors (called Cookies). Cookies can be attached to an object (for example, a door, keyring, person or pets). They can be used for multiple purposes: (1) tracking how much you have walked or run or how much coffee you have consumed, (2) child care (to determine that the child is in the house), (3) a door alarm, (4) a medication reminder, and (5) sensing temperature and sleeping habits. In addition, devices from other platforms such as Nest and Philip Hue can be used with the Sen.se mother hub.
• The Hub from Samsung [14] can also connect additional smart devices (sold by Samsung) to the Mother. So, its additional functionality can be extended by choosing many kinds of devices to use with it.

As Sen.se Mother offers more flexibility and more diverse applications, we chose the first option. Installing Sen.se Mother was not straight forward. We had to collect the MAC address of the device using Wireshark to get it connected to the Internet. Once the Hub was connected, we deployed 4 sensors to collect different types of data. Collected data is visually displayed in the Sen.se Dashboard [4], a web portal provided by the vendor.

The Cookies and the Hub

As noted in the previous section, the Hub is a collector entity connected to the Internet. The primary job of the Hub is to act as a supervisor, configure the Cookies for specific tasks, collect data from the Cookies, and send them to the web portal. Cookies are sensors deployed to collect application specific data. A Cookie can save up to ten days of data without connecting to the Mother. As soon as a Cookie is reconnected to the Hub, it uploads all contents of its memory. A Cookie contains a CR2016 replaceable button cell with one year of battery life. To communicate with Mother, Cookies use radio (frequencies are 915 MHz in North America and 868 MHz in Europe). Every type of movement has its own pattern and signature. By placing a Cookie on an object or person we can capture and analyze movements. The Cookie will recognize a specific action that is to be monitored and will transmit sensed data for the chosen application. Some Cookies also contain thermometers. They can transmit the ambient temperature as well as sudden abnormal changes in temperature to the Hub. Another interesting feature of the Cookie is its ability to signal presence or absence of a person or object. One Cookie can be used for only one application given at a specific time. We deployed 4 sensors with 4 specific tasks:

• Bedroom door for security notification
• Thermostat for room temperature monitoring
• Sensing physical exercise and
• Sensing presence at home

When the smart-phone app for Sen.se Mother is connected to the web portal, it receives real-time notifications of events [4].

Sen.se API Documentation

The Sen.se has an application program interface (API) and associated documentation [16]. This serves three types of audiences:

• Users who want to access the data produced by their devices and build their own programs using those data and devices
• Developers using the Sen.se platform to create new applications for Sen.se users. Users can install these applications (referred to as native apps) in the same fashion as regular Sen.se applications, and they will be displayed on the web portal
• Developers willing to use the data provided by a Sen.se platform to enrich an external application (such as Android apps)

The Sen.se API is REST-oriented and returns data in JSON format. Although this API is a good way to access the data collected by sensors, it doesn’t give the user or developer any opportunity to access actual devices.

Data Collection

Four Cookies have collected data for the four applications from May 11, 2016 to May 31, 2016. First, the bedroom door application that tracks activities at bedroom door stored and reported all activities. Some data were false positives and false negatives. When the sensor sensitivity level is too low, occasionally it can’t detect very light activity at the door. On the other hand, if sensor sensitivity is very high, opening up other doors may trigger the alarm. But sensitivity is adjustable and it is easy to figure out the sensitivity level suitable for a given scenario. Collected data shown in the web portal contains information related to time, place and number of movements detected.

The second sensor was used to collect temperature data. Whenever the temperature crosses a user-specified threshold, a notification is sent to a smart phone application. In our scenario, the lower limit was set to 59°F and the upper limit was set to 78°F.

Another sensor was deployed to trace the presence of a person at home. We observed false positives and negatives at times. When the subject was sleeping and sensor did not detect any movement in the room, it reported that the subject left home. Also, the subject may have left the Cookie behind, violating the sensors’ assumption that the subject is in the same place as the Cookie. Collection of such data can be very important for scenarios like child care. At the same time, this kind of data is very sensitive from the privacy and cyber security point of view. In the wrong hands, presence- and absence- related data can be very harmful and consequential.

The fourth sensor was deployed to monitor the physical activity of the subject such as walking. Again, there was a high rate of false negatives, although very few false positives. For example, the sensor reported that the subject spent four days out of seven without walking, which is absurd; most likely, the subject forgot to carry the sensor. Or, perhaps an attacker deliberately manipulated sensor data. Again, this is sensitive information from both the privacy and security points of view. The data collected can reveal the subject’s pattern of life, which may prove useful to an attacker.

Data collected from sensors gave us insight into what next steps of our work should be. From the API documentation, we understood that we can only access the data stored in the database; we had no direct access to the devices through the API. The API queries enabled us to only read the REST API [17] database. Sen.se already has apps to access and display that data. Unless our target is developing a new app, there is not much motivation to write a new app to collect data from the forensics point of view. On the other hand, Oriwoh et al. [9] have shown that by applying a scenario based approach, we can determine the forensic significance of the data collected by apps. Hence, from practical attack and crime scenarios, we can interpret the data collected from a crime scene. After analyzing such scenarios and data, we have created a general model that formalizes a digital forensics approach for IoT. This approach also enables us to answer the research questions we started with.

Results

Data Classification

We classified the data collected from four applications. In table 1, for each set of information collected, we identify the source of the information and whether the information reveals the subject’s location or daily routine. We have indicated the severity of the leak too. The severity is considered high if both location and daily routine can be derived from the data; medium if only one of those is fully exposed; and Low if neither is exposed. Finally, we have described forensic interpretation of the data.

Scenario Analysis

Attack scenario analysis helps us understand how the data collected will be useful in practical scenarios. Here are some examples of such scenarios.

Event 1: Burglary

• Identification: Door sensor data indicates the time when the owner left home. Data indicates that there has been an activity at 11:40 am, even though the owner was not home at that time. The burglary happened on the same day.
• Interpretation: Does the data suggest that the burglar knew the owner’s daily schedule? This would help us investigate the incident. For example, would looking into CCTV camera footage from across the street that was collected at 11:40 am be useful?
• Preservation: Data collected by the sensor was stored in the cloud at near real-time.
• Analysis and presentation: Data presented on graphs is easy to understand and present to a court, so a graph correlating events with burglaries would be helpful.

Event 2: Abnormal death of a businessman, Mr. X

• Identification: Medication sensor data indicates that Mr. X took medicine at an abnormal time. In addition, the walk sensor indicates that Mr. X was walking at the time the medication sensor at home reported activity. Does this mean someone has tampered with Mr. X’s medication while he was out for a walk? Or is it simply a bug in the sensor app that shows Mr. X taking his medicine at an irregular time? Does this lead us to the reason for his untimely death?
• Interpretation: What does the data tell us? Is it meaningful? Is our interpretation correct? Can we trust the data? What about false positives? False negatives?
• Preservation: Data collected by the sensor was stored in the cloud at near real-time.
• Analysis and presentation: Data presented on graphs is easy to understand. Investigators may look into other related sensors, such as door activity or motion sensors. Data can be correlated to the events either manually or using automated software resources. Both methods have scope for further improvement.

Event 3: A banker’s laptop at home accessed by intruder

• Identification: A transaction was made using the banker’s user name at 7:14 in the morning. The presence/absence sensor indicates that the banker was not home at that time. There was no indication of a break-in. Door sensor data from the room where the laptop was indicates that there has been an activity at the door in 7:12 am (after the owner left home).
• Interpretation: Does the data suggest that the intruder knew the owner’s daily walking schedule? As there was no break-in, does this mean someone from inside the house came into the room and accessed the laptop? Could the banker have faked the scene to steal the money?
• Preservation: Data collected by the sensor was stored in the cloud at near real-time, with some possibility of false positives and false negatives.
• Analysis and presentation: Data presented on graphs is easy to understand and present to a court.

This scenario-based analysis leads us a general model for IoT mobility forensics.

Mobility Forensics Model

Figure 1 illustrates the model. The questions presented in this model are almost the same as classical criminal investigation and digital forensics. But the semantic and scope of them changes as the IoT environment is different than the conventional one.

Figure 1. IoT mobility forensics model

• What happened? What is the description of the incident (cyber-attack, crime etc.)? Does it directly impact human life? Is the incident confined to IoT devices only? Does it affect other computers and connected smart electronics devices?
• When did it happen? The time of the event is crucial for crime investigations and digital forensics. IoT devices are especially sensitive to time traces. Many critical systems and life-saving machines and IoT devices depend on millisecond of precision in time.
• How did it happen? Identifying the transition steps from the safe state to compromised state is one of the most important part of mobility forensics.
• Who and/or what did it? Identifying the person or object responsible for the event is the fundamental motivation of mobility forensics. Organizations, investigators and security researchers want to follow the event trails, both electronic and non-electronic, to find the entity responsible for the attack.
• Why did it happen? Finding the reason for the event is just as important as finding the entity behind it. When IoT devices are present, an attack scenario can be more complex than before, but at the same time data and digital evidence collected through IoT devices will contribute to unrevealing the complexity using forensics.
• What data was collected? This is an important question for IoT mobility forensics. In an attack scenario, forensic decisions may be affected by the amount of data collected by IoT devices. Moreover, how much of the data collected is useful and relevant to the attack is also an important factor.

Data Manipulation and Counter Measures

Understanding the data and model from IoT mobility forensics suggests some other important questions.

• How much can we trust the data extracted from IoT devices?
• How will the attacker changing the data before or after collection affect the forensic analysis?
• Can we prevent or detect such manipulations?

Corruption and manipulation of digital data has always been an issue for the security community. Even if the attacker doesn’t compromise the integrity of the data, the data collection process itself may produce incorrect information intermingled with accurate data. In our discussion, we have assumed that the collection-related errors are known to happen and investigators are aware of the fact that certain portions of the collected data are erroneous. Recently, Altolini et al. [18] proposed an encryption and authentication mechanism for low power IoT platforms. Such an implementation can help prevent data manipulation by attackers.

Discussion

Our findings thus far point to more questions that need to be addressed. We briefly discuss some of these questions here, with some answers from our set-up.

1. Can the attacker “get into” the sensors? Kasinathan et al. [19] suggests that attackers can gain access to sensors under the right conditions.
2. Can the attacker “get into” the Hub? The Hub is directly connected to the Internet and interacts with the web portal. Work on IoT intrusion detection [23] suggests such attacks on hubs are feasible.
3. What is the communication medium? In addition to traditional wireless networks, IoT devices are connected through cellular networks, radio, Bluetooth and other low power communication media. This diversity makes the communication more vulnerable than otherwise, and makes using generic protections against attacks harder.
4. Can we knock down the sensors with a classic flooding attack? Although we did not try this on our devices, Kassinathan et al. [19] suggest that DoS and flooding attacks may disable IoT devices.
5. Can data be manipulated deliberately to obstruct or mislead justice in a court of law? We have discussed this issue in the previous section; it needs more attention from the security community.
6. Is it possible to sniff the hub and sensors? In our experimental set-up, we were able to derive device identity (specifically, the MAC address of the Hub) by observing network packets. Copos et al. [12] provide an example of how sniffing can lead to a major security breach.

False Positives and False Negatives

Incorrect results have long been an issue in security research. Researchers have tried to avoid and mitigate such erroneous results by applying different methods [20]. Unfortunately, there is no single reason behind false positives and negatives. Likewise, there is no standard solution either. There are many reasons behind false positive and false negative reports from IoT devices. As we indicated in our previous discussion, the main reason for false positives and negatives is inaccuracy of sensing, and human error. Sensors are limited to the physical information they register and the implementation of the detection algorithm. Many sensor readings are tunable. That being said, the users of such data and models should be aware of the existence of false positives and false negatives. They should take proper steps to detect and minimize false results from IoT devices.

Limitations

Some limitations of our work are:

• Data is collected only from smart home devices
• The forensic model proposed here has not been implemented, deployed, and tested
• We assume implementation of the model will be scalable for the fast growing number of devices, which may not be true
• Our findings depend on data collected from one type of device. Perhaps different kinds of devices would produce more consistent results.

Future Work

This paper contains specific findings and results based on the smart home IoT device Sen.se Mother, its Hub, and its Cookies. Future work should include more generic scenarios where multiple types of IoT devices and their data are analyzed. Working towards more robust and mature model for IoT mobility forensics by providing better data analysis would be an improvement. In-depth analysis and discussion of the data collected is left for future work. As a huge amount of data is collected and stored, the privacy of users is an important issue. If large companies like Google and government organizations such as US Information Awareness Office (IAO) have access to such data [21], they may violate users’ privacy and use the data for profit or special purposes. Hence, privacy is a serious research problem in IoT security. Another interesting open problem is the reverse question: given a digital forensics scenario and a forensic model, what useful data can IoT devices collect for us? This can yield significant result, useful to both security community and manufactures of IoT devices. In our future work, we plane to focus on one specific question that we have discussed here.

Conclusion

As the field of IoT is booming, we need to secure these devices and systems. More work on mobility forensics for IoT can help achieve that goal. This paper analyzed data collected from IoT devices and proposes a new forensics model to make IoT world more secure. The methods discussed in this paper are useful for both industry and academia. Criminal investigation and evidence collection in the realm of Cyber Security can get valuable ideas from the work presented here. We also hope that the users shall be more aware of IoT security and privacy issues from the discussion of our paper.

Acknowledgement: Special thanks to Intel and the INSuRE [22] project team for funding the Sen.se devices. We would also like to thank the anonymous reviewers for their useful feedback that helped us improve our work. This work was supported by the National Science Foundation Grant Number DUE-1344369 to Purdue University, and by a subcontract from Purdue University to the University of California funded by that grant. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation, Purdue University, or the University of California.

References

[1] Mobility forensics. http://mobility-forensics.com/. Accessed April 21, 2016.
[2] Smart City. http://www.theverge.com/2016/5/24/11759272/Samsung-commercial-smart-city-network. Accessed May 31, 2016.
[3] Smart Grid. http://energy.gov/oe/services/technology-development/smart-grid. Accessed May 31, 2016.
[4] Sen.se Mother. https://sen.se/mother/. Accessed April 30, 2016.
[5] Weber, R. H. 2010. Internet of Things – New security and privacy challenges. Computer law & security review 26. 2010.
[6] Jing, Q., Vasilakos, A. V. and Wan, J. 2014. Security of the Internet of Things: perspectives and challenges. Wireless Network. 2014.
[7] Perumal, S., Norwawi, N. M. and Raman, V. 2015. Internet of Things (IoT) digital forensic investigation model: Top-down forensic approach methodology. ICDIPC. 2015.
[8] Hegarty, R. C., Lamb, D. J. and Attwood, A. 2011. Digital Evidence Challenges in the Internet of Things. WDFIA. 2011.
[9] Oriwoh, E., Jazani, D., Epiphaniou, G. and Sant, P. 2013. Internet of Things Forensics: Challenges and Approaches. CollaborateCom. 2013.
[10] Valera, A. J. J., Zamora, M. A. and Skarmeta, A. F. G. 2010. An architecture based on Internet of Things to support mobility and security in medical environments. IEEE CCNC. 2010.
[11] Arias, O., Wurm, J., Hoang, K. and Jin, Y. 2015. Privacy and Security in Internet of Things and Wearable Devices. IEEE Trans. On Multi-scale Computer System. 2015.
[12] Copos, B., Levitt, K., Bishop, M. and Rowe, J. 2016. Is Anybody Home? Inferring Activity From Smart Home Network Traffic. MoST. 2016.
[13] Peisert, S., Bishop, M., Karin, S. and Marzullo, K. 2007. Toward Models for Forensic Analysis. In the Proceedings of the Second International Workshop on Systematic Approaches to Digital Forensic Engineering pp. 3–15. April 2007.
[14] Samsung Hub. https://www.smartthings.com/. Accessed April 30, 2016.
[15] Nest Thermostat. https://nest.com/. Accessed April 30, 2016.
[16] Sen.se Developer. https://sen.se/developers/. Accessed May 6, 2016.
[17] REST. https://en.wikipedia.org/wiki/Representational_state_transfer. Accessed May 31, 2016.
[18] Altolini, D., Lakkundi, V., Bui, N. and Tapparello, C. 2013. Low power link layer security for IoT: Implementation and performance analysis. IWCMC. 2013.
[19] Kasinathan, P., Pastrone, C. and Vinkovits, M. 2013. Denial-of-Service detection in 6LoWPAN based Internet of Things. WiMob. 2013.
[20] Spathoulas, G. P. and Katsikas, S. K. 2010. Reducing false positives in intrusion detection systems. Computer and Security 29 p35-44. 2010.
[21] Total information awareness. https://en.wikipedia.org/wiki/Total_Information_Awareness. Accessed May 31, 2016.
[22] INSuRE. http://insurehub.org/about-us. Accessed April 30, 2016.

This paper was originally published on the INSuReCon’16 website (INSuReCon’16_paper_4).

by Oleg Afonin, Elcomsoft

Microsoft has developed Windows 10 as the one OS for all types of devices from servers to wearables. Desktops, laptops, two-in-ones, tablets and smartphones can (and do) run a version of Windows 10. There are countless forensic tools for acquiring evidence from the desktop version of Windows 10, much less for Windows-powered smartphones.

Forensic analysis of Windows 10 Mobile devices can be complicated due to the exotic status of such devices. Due to full-disk encryption, on-device access may not be an option. However, Microsoft collects enormous amounts of information from its users. This information is then stored in the user’s Microsoft Account. Some bits of data are fully accessible to the user, while access to some other bits (such as mobile backups) is restricted.

In this article we’ll have a look at what exactly is available in Microsoft cloud, what can be extracted and where this information is stored. We will also list the steps required to extract and view the data.

(c) DobaKung on Flickr

Microsoft Collects Information

Microsoft is notorious for collecting information from Windows 10 users. The amount of data collected by Windows 10 devices increased dramatically compared to the days of Windows 7. This “usage and diagnostics” data, which may include text snippets, app usage data, detailed or approximated location information etc., is automatically collected and transmitted to Microsoft servers unless one explicitly opts out.

Users of Windows-powered handsets (Windows Phone 8.x and Windows 10 Mobile) have access to iOS-style cloud backups created in their Windows Account. Once cloud backups are enabled, things such as application data, call logs, text messages and so on will also be stored in the cloud.

Finally, some information is synchronized by Windows-powered desktop and mobile devices in real-time or close to real-time speed. This includes Web browser history, Bing search history, location data, as well as other things such as notes, calendars, contacts etc.

Microsoft offers ways to access, restrict or delete this information via the Privacy portal.

However, we found that this portal returns very limited amounts of data compared to what’s being actually collected. For this reason we expanded Microsoft Account support in this latest EPB build.

(c) wynpnt on Pixabay

Windows 10 Mobile: What’s In The Cloud?

Browsing and Search History

Windows browsing history can only be extracted from the cloud from Windows 10 Mobile (phones) and regular Windows 10 devices if Microsoft Edge was used as a Web browser. Edge browsing history is automatically synced across desktop and mobile Windows 10 devices logged in to the same Microsoft Account. Windows 10 Mobile devices (phones) have Microsoft Edge as their default (and most commonly adopted) Web browser. Edge adoption is growing slowly but steadily on desktops. Note that we also have tools to extract browsing history from other popular Web browsers such as Chrome and Safari using their respective cloud services.

Search history can be extracted from all types of devices regardless of the Web browser used providing that the searches occurred on Microsoft-owned Bing. Microsoft collects Bing search requests if the user has been logged in to their Microsoft Account in the Web browser while running the search.

Call Logs

The call logs can be important evidence. Since cloud backups are enabled by default for all Windows Phone 8, 8.1 and Windows 10 Mobile smartphones, call logs are one essential bit to extract.

Microsoft does not specify the origins of location data it collects on desktop and laptop computers, tablets and 2-in-1 devices. At very least, location is reported by Cortana and via the Edge browser.

Location History

Microsoft collects location history from all stationary and mobile Windows devices starting with Windows 8.1. While users can review their location history by visiting https://account.microsoft.com/privacy/location and signing in to their Microsoft Account, the amount of data points returned on that Web page is low. Only the last detected location is displayed. However, forensic tools are available allowing to extract the complete location history from the cloud.

Text Messages (SMS) and Other Previously Extractable Data

Users of Windows 10 Mobile handsets enjoy the ability to synchronize text messages (SMS), notes, calendar events, contacts and some other information with the cloud. This data can be extracted.

Accessing the Data

Since Windows 10 (Mobile) data is stored in the cloud, user’s Microsoft Account authentication credentials are required to sign in and extract the data. Note that once you try to access mobile backups, the user will be alerted by email while you will see a request for the secondary authentication factor – even if two-factor authentication is not enabled on the user’s account. This means you will need access to the secondary authentication factor such as the user’s SIM card with trusted phone number, a trusted email address or similar.

Conclusion

Cloud forensics allows extracting information from the user’s Microsoft Account without having physical access to the actual mobile device. Considering the amounts of data collected, synchronized and stored by Microsoft in the cloud, cloud forensic is the way to go when analysing Windows 10 Mobile devices, and can return additional evidence when analysing Windows 10 PCs.

This article was submitted by ElcomSoft, a digital forensics solutions provider specialising in password recovery, mobile and cloud forensics.

by Patrick Siewert, Principal Consultant, Pro Digital Forensic Consulting

It’s becoming common knowledge that location evidence on cellular devices can provide a wealth of evidence in any number of civil, criminal and investigative matters. Law enforcement agencies use cellular location evidence from service providers to help place a criminal suspect at or near a crime scene in a given time frame. Search and rescue analysts can use cellular call detail records to help locate missing persons as well. And as we’ve detailed in previous articles, this type of evidence can be useful in any number of other matters, from divorce to alimony to fraud investigations and beyond.

So where does all of this evidence come from and how can we best utilize it? It can come from a variety of different places, but the two main areas are the mobile device itself and the records from the cellular provider. Proper legal authority needs to be in place to obtain the data from either source as well, but with the right training and experience, an investigator or consultant can help with obtaining those items. Once the data is in-hand, any number of tools and approaches can help parse out the relevant data and map locations that may be of interest in the case.

In the example cited in this article, the data was extracted from an Apple iPhone 7 through an advanced logical extraction using Cellebrite Universal Forensic Extraction Device (UFED) Physical Analyzer. Because I’ve been doing a lot of traveling lately and using the Waze app to find my way around various US-based locations, I decided to use Waze as a case study in location information. Cellebrite UFED does natively parse this data (see fig. 1), but does not natively map the locations.

Fig. 1: Waze Data parsed in Cellebrite PA

As you can see, Cellebrite adequately pulled GPS locations, dates, times and even addresses that were stored in Waze. The list is longer, but figure 1 gives us a sample of a few months of Waze usage throughout various locations.

But again, Cellebrite does not natively map this data. So how can we see this graphically and perhaps even create a demonstrative for use in court? Enter the cellular record analysis and location mapping tool, CellHawk from Hawk Analytics. CellHawk is an online tool that will natively read, parse and map location data from any of the major cellular providers as obtained through a search warrant or court order. However, as I learned recently by attending the CellHawk training, it can also map anything with a date, time and GPS coordinates. The tool just takes a little manual configuration once the data is exported in Cellebrite.

For this demonstration, I simply had to export the Waze Data into an Excel spreadsheet, which is natively supported in Cellebrite. From there, the spreadsheet is uploaded into CellHawk, which natively reads the file column headers and asks for some direction about where the pertinent data (date/time/GPS location) is located within the spreadsheet. Here’s an example of what we get when CellHawk reads and maps the data:

Fig. 2: Northeast Waze Locations Mapped in Cell Hawk

Our office is located in Richmond, VA, which is listed as the starting point for many of these trips. But this map details all of the client visits in/around Virginia, Maryland and DC as well as locations where training was delivered in the Philadelphia and Boston areas over a period of more than a year.

When a map location is clicked, CellHawk natively tries to associate a phone number with that data point. Because the CellHawk generic location finder was used to upload the spreadsheet, the identifier of “Waze” was entered instead of a phone number, but this is a user-defined customization in CellHawk. Interestingly, the dates and times of the data points are listed and viewable when clicked in CellHawk. The figure below details a recent trip to Kansas City, KS for the Cellular Analysis and CellHawk training:

Fig. 3: Date, time & location detail in Cell Hawk

What’s even more interesting about the dataset in general is the historical nature of some of these locations. Figure 3 also illustrates several locations in and around Chicago and Milwaukee. I used Waze to navigate in/around the Chicago area and to the Harley Davidson museum in Milwaukee in August, 2012. Since then, while the Waze user account hasn’t changed, the device has been upgraded through 3 or more different iPhone models.

This historical data was not a one-off or isolated to this trip only. Fig. 4 below shows map locations from a trip to and around the ALERRT Center in San Marcos, TX where I attended a conference in 2011:

Fig. 4: Waze historical data from 2011 mapped in Cell Hawk

That’s Great. Now What?

The data gathered by Cellebrite and mapped by CellHawk is useful to help prove or disprove someone may have been to and navigated around a particular area during a specified time frame. Further, if a subject of an investigation or litigation claims they cannot drive, Waze can help disprove that claim. When we factor in dates, times and historical data that is maintained over years and across multiple devices, the potential weight of that data becomes apparent.

There are other ways (no pun intended) to parse and map this data, but both Cellebrite and CellHawk make it fairly easy and intuitive. In the ever-present questions of who, what, where when, how and perhaps why of any incident, the ability to find, export and analyze this data simply and effectively is a fantastic investigative advantage!

P.S. If you think this was a cool illustration, I highly recommend checking out CellHawk for your cellular call detail record and cell site mapping. It’s a fantastic tool for mapping that particular set of data and that’s primarily what it was designed to do. Be looking for a future blog diving into CellHawk for that purpose.

About Patrick Siewart

Patrick Siewert is the Principal Consultant of Pro Digital Forensic Consulting (www.ProDigital4n6.com), based in Richmond, Virginia. In 15 years of law enforcement, he investigated hundreds of high-tech crimes, incorporating digital forensics into the investigations, and was responsible for investigating some of the highest jury and plea bargain child exploitation investigations in Virginia court history. Patrick is a graduate of SCERS, BCERT, the Reid School of Interview & Interrogation and multiple online investigation schools (among others). He continues to hone his digital forensic expertise in the private sector while growing his consulting & investigation business marketed toward litigators, professional investigators and corporations, while keeping in touch with the public safety community as a Law Enforcement Instructor.

by Oleg Afonin, Elcomsoft

Apple is about to launch its next-generation iOS in just a few days. Researching developer betas, we discovered that iOS 11 implements a number of new security measures. The purpose of these measures is better protecting the privacy of Apple customers and once again increasing security of device data. While some measures (such as the new S.O.S. sequence) are widely advertised, some other security improvements went unnoticed by the public. Let us have a look at the changes and any forensic implications they have.

Establishing Trust with a PC Now Requires a Passcode

For the mobile forensic specialist, one of the most compelling changes in iOS 11 is the new way to establish a trust relationship between the iOS device and the computer. In previous versions of the system (which includes iOS 8.x through iOS 10.x), establishing a trusted relationship only required confirming the “Trust this computer?” prompt on the device screen. Notably, one still had to unlock the device in order to access the prompt; however, fingerprint unlock would work perfectly for this purpose.

iOS 11 modifies this behaviour by requiring an additional second step after the initial “Trust this computer?” prompt has been confirmed. During the second step, the device will ask the user to enter the passcode in order to complete pairing. This in turn requires forensic experts to know the passcode; Touch ID alone can no longer be used to unlock the device and perform logical acquisition.

Establishing a trust relationship between an iOS device and the PC is required in order to perform logical acquisition. Without pairing the device to the PC, experts will be unable to make a local backup of the device. Considering the current situation with iOS 11 jailbreak, physical acquisition is not (yet) an option, so logical (and cloud) acquisition is currently the only way to go.

Before: iOS 8 through iOS 10

In order to establish a trusted relationship, users would perform the following sequence:

• Connect the iOS device to the computer. iTunes must be installed and launched at least once on that computer in order for the pairing to work.
• Unlock the device with Touch ID or by entering the passcode (if enabled).
• Tap Trust on the “Trust This Computer?” prompt on the device.
• In iTunes, tap Continue. The trust relationship between the iOS device and the computer is now established.

Now: iOS 11

iOS 11 introduces an extra step when establishing trusted relationship. The new pairing sequence:

• Connect the iOS device to the computer. iTunes must be installed and launched at least once on that computer in order for the pairing to work.
• Unlock the device with Touch ID or by entering the passcode (if enabled).
• Tap Trust on the “Trust This Computer?” prompt on the device.
• In iTunes, tap Continue.
• If the iOS device has a passcode, it will now prompt the user to enter the passcode. The trust relationship between the iOS device and the computer will be only established after you enter the correct passcode.

Forensic Implications

Prior to iOS 11, it was possible to perform logical acquisition of an iOS device by unlocking the device with Touch ID. The new pairing procedure requires the use of the device passcode in order to establish trust between the device and the computer, thus making logical acquisition possible only if you know the passcode.

This change is very important from the legal standpoint. While in certain cases the user may be compelled to unlock their device using their fingerprint, obtaining the passcode from the user may be challenging and, in many jurisdictions, not legally possible.

Recent Cases

In particular, Apple protects their customers’ data in cases of mass device seizures with dubious warrants like the one mentioned in this Forbes article. If the user owns a device running iOS 11, forcing a fingerprint unlock will no longer allow investigators to gain access to information other than what can be manually accessed on the device screen.

The S.O.S. Mode

In iOS 11, Apple has added an new emergency feature designed to give users an intuitive way to call emergency by simply pressing the Power button five times in rapid succession. As it turns out, this SOS mode not only allows quickly calling an emergency number, but also disables Touch ID.

Once the Power button (Sleep/Wake) is pressed five times in rapid succession, the iPhone displays a menu presenting various options including an option to cancel. Regardless of the option chosen (including the Cancel button), iOS will temporarily disable Touch ID and require the user to enter a passcode in order to unlock the device.

Forensic Implications

This feature can be used to discreetly disable Touch ID in situations where the user might be compelled to unlock their phone with a fingerprint. Once Touch ID is disabled, there is no other way to unlock the device but using the passcode or making use of an existing pairing record.

There is no way to tell that Touch ID has been disabled using the SOS feature. Once the sequence is completed and the user cancels the menu, the iPhone prompts for a passcode in the same manner it uses after Touch ID naturally times out.

Using Existing Pairing Records to Unlock

Even if the iPhone has been locked using the emergency feature, it may still be unlocked for logical acquisition using a valid pairing record extracted from the user’s computer. It is essential that the iPhone in question remains powered on and is not allowed to shut down or reboot before the unlock is attempted.

If the user has engaged the SOS mode, or if Touch ID has expired according to Apple’s rules, a valid pairing record will still allow you to get in and to produce a backup. You will need to use the last version of Elcomsoft iOS Forensic Toolkit for that. In order to unlock the device with pairing record, launch iOS Forensic Toolkit and choose option “B” for “Backup”. You will be prompted for a file containing the lockdown (pairing) record.

Lockdown records are saved in the following locations:

Windows Vista, 7, 8, 8.1, Windows 10:
%ProgramData%\Apple\Lockdown

Windows XP:
%AllUsersProfile%\Application Data\Apple\Lockdown

macOS:
/var/db/lockdown

While not directly related to iOS 11, it is important to note that macOS 10.2 and newer implement access control to restrict access to pairing records. This can be fixed by running the following command in console:

sudo chmod 755 /var/db/lockdown

There is also another issue with pairing records, and this time it is directly related to iOS 11. This issue apples to iOS Forensic Toolkit in macOS and Windows. Even as the connected device is already paired with the current system, EIFT does not recognize the device and asks for a pairing record.

A workaround is simple; just enter the path to the pairing record when requested. In Windows, do not forget using the quotes:

“C:\Users\All Users\Application Data\Apple\Lockdown\{ID}.plist”
/var/db/lockdown/{ID}.plist

We are going to address the second issue in EIFT 2.31 that will be released shortly. As for the lockdown folder access problem, we decided to address it in the user manual instead of changing permissions automatically due to potential security drawbacks.

Once again, for successfully unlocking the device with a pairing record it is essential that the iPhone in question remains powered on and is not allowed to shut down or reboot before the unlock is attempted.

More information about extracting and using pairing records in this article.

Using Pairing Records in iOS 11

One relative weakness related to pairing records is carried over from previous versions of iOS. Namely, if the user changes their passcode, all existing pairing records are not revoked. As a result, all existing pairing records remain valid and are not automatically invalidated after the user adds, removes or changes device passcode, adds or removes fingerprints. Moreover, in iOS 11, pairing records still do not have a set expiry date.

Forensic Implications

Your ability to unlock devices with pairing records extracted from the user’s computer(s) remains unaffected even if the user adds, removes or changes authentication methods (passcode, fingerprint). However, in order to successfully unlock the device with a pairing record it is still essential that the iPhone in question remains powered on and is not allowed to shut down or reboot before the unlock is attempted.

Our Take

This is one of the few obvious weaknesses still remaining in the iOS 11 security system. If Apple decides to automatically invalidate already issued pairing records on changing authentication methods (fingerprint/passcode or even just the passcode), or simply makes cryptographic keys in pairing records passcode-dependent, a major acquisition possibility may be locked.

At this time, pairing records do not have a set expiry date. They survive through reboots (providing that the phone has been unlocked with a passcode at least once after a reboot) and changes of authentication methods. It is known that Apple has full control over lifespan of the pairing records. The company may or may not change existing behaviour in the future.

Notifications No Longer Stored in Backups

In March, 2017, we discovered a way to extract undismissed notifications from iOS backups. Notifications are pushed by pretty much every app of forensic significance. Email clients and instant messengers, Uber and taxi apps, booking and travel services, online shopping and delivery services, social networks and banking apps are just a few things to mention. Unless read or dismissed, these notifications were stored in local and cloud backups.

More importantly, these notifications were kept in the backups forever. The user only has access to notifications from the last 7 days. Older notifications automatically disappear from the device notifications shade. For some reason these old notifications were still kept on the device; they were backed up and restored using both local and cloud backups.

This is no longer the case. Notifications are no longer part of any backups, local or iCloud. With no iOS 11 jailbreak (yet), we have no way to verify whether notifications older than 7 days are still stored on the device or not.

Forensic Implications

You now have one fewer piece of information available via logical or cloud-based acquisition process. Access to undismissed notifications with ElcomSoft tools lasted for less than 7 months.

A Word on Two-Factor Authentication

Two-factor authentication has been around for a while. First introduced in iOS 9 as a successor to the old and insecure Two-Step Verification, the new 2FA method has proved to offer a reasonable balance between security and convenience. In iOS 11, Apple starts pushing two-factor authentication much harder, up to the point of displaying a prominent pending notification dot over the Settings icon. By opening Settings, the user will see a pending notification reminding to enable two-factor authentication.

Notably, two-factor authentication is not yet universally available. The up to date list of regions where 2FA is already available on Apple’s website.

ElcomSoft products support most Two-Factor Authentication methods including codes pushed to trusted devices as well as offline codes generated on trusted devices. We don’t currently support codes delivered as text messages.

iCloud tokens can still be used to bypass two-factor authentication in iOS 11. By extracting an authentication token from the user’s i-Device, Mac or PC (the latter must have iCloud for Windows installed), experts can sign in to the user’s iCloud account without knowing the user’s Apple ID or password and without having to go through the second authentication step. Do note that iCloud tokens expire. More on the expiration of iCloud tokens as well as additional details on how to extract them can be found on our blog.

One more thing. If Two-Factor Authentication is active on the user’s account, gaining access to the user’s iCloud Keychain is somewhat easier as one only needs to have the user’s i-Device and does not need an iCloud Security Code.

Conclusion

For now, this was everything we wanted to share about the upcoming features of iOS 11. There are many more low-level and invisible changes to both the operating system and iCloud. There are changes in communication protocols, data formats and encryption. We kept an eye on the situation through all developer betas, and have already implemented support for most of them. An updated version of Elcomsoft Phone Breaker is just around the corner with support for iOS 11 local and cloud backups, the ability to download media, files, synced data and keychain produced by devices running the new OS. We are also updating Elcomsoft Phone Viewer to allow exploring local and cloud iOS 11 backups. Stay tuned for further announcements!

This article was submitted by ElcomSoft, a digital forensics solutions provider specialising in password recovery, mobile and cloud forensics.

by Andrey Fedorov

The purpose of this article is to find additional information about the capabilities, specifics, and USPs of the ADR512 Android Data Recovery program. A full description of this software can be found here.

Developers from 512 BYTE, who created the software, invited specialists from digital forensics lab Gross to test it. 

Let’s take a look at the practical tests. 

The essence of the experiment step by step was as follows.  

Two devices were taken: Lenovo A319 (OS version 4.4.2) and Xiaomi Redmi Note 3 Pro (OS version 6.0.1).

The Lenovo A319’s phone memory was reset to factory settings (all data, including the user’s, were deleted).

For the Lenovo A319, root rights were obtained to have full access to the memory (Hynix eMMC H4G2a) of the device.

An image of the Lenovo’s drive was created. The size of the image was 4GB.

The image was then investigated using Belkasoft Evidence Center Ultimate 2017, which is designed for data retrieval and analysis. The section “Messages” was missing in the report.

For testing, the instant messaging application imo was selected. This was installed via the Google Play Service. We chose this program because it has had over 100 million downloads. We purposefully did not choose the most used applications like “Viber”and “WhatsApp”.

Between these two devices instant messages were exchanged in “imo” (text: “512byte_gross”, “gross_512byte”). There is a screenshot below with the contents of the text messages, taken from the Xiaomi Redmi Note 3 Pro.

After using the “imo” application, the Lenovo A319 was re-imaged.

The image of the drive from was then investigated by using Belkasoft Evidence Center Ultimate. The “Messages” section now appears.

After that, the “imo” application was removed from the Lenovo A319 phone in the standard way.

After removing the application, the image of the Lenovo A319 drive was made again.

This image was then studied with Belkasoft Evidence Center Ultimate and X-Ways Forensics 19.2. Belkasoft Evidence Center Ultimate did not detect the deleted messages (there was no “Messages” section). The search was carried out among available and deleted data: the structure of the file system of the logical section was investigated. We applied the carving method (signature analysis, carved), and searched by keywords (since the message content was known). The research time was about one hour twenty minutes. The probable reason for the lack of a positive result can be explained is that this software explores the SQLite database file (db) directly. In addition, this software can search this type of file as a result of signature analysis (carving). As a result, it can be assumed that in the event of damage to the SQLite data structures (damage or lack of signature), the evidence in the file will not be detected.

Using the X-Ways Forensics 19.2 software, entries in the free sectors of the section (image) were identified. At the same time, as in the previous case, the search was carried out among available and deleted data: the structure of the file system of the logical section was investigated; a carving method was applied; and we searched for keywords. The research took about one hour forty minutes (including research of file system structures, signature analysis, and searching for inputs). The positive result was achieved thanks to the known content of the messages.

Next, the image was analysed using ADR512. The research time with the selected settings was less than two minutes. Using this software we detected the deleted messages from our test in the “imo” application.

Conclusion

This test demonstrated that ADR512 has the advantage of looking for deleted messages in front of applications that work directly with database files. The positive result is achieved due to the fact that the program ADR512 implements the search for all SQLite records, without reference to the database file.

If you know the message content, you can find it in any Hex editor. However, certain questions remain: interpretation of the fields, date and time, and most importantly, the time spent analysing the data.

In the case where the search context is unknown or the number of messages is too large, a fundamentally different approach is required. ADR512 finds the messages regardless of the content and number of records.

About The Author

Andrey Fedorov is co-owner of 512 BYTE company, specialists in data recovery, software development for data recovery and forensic analysis. He has more than 15 years of experience in this field.

by Patrick Siewart 

Increasingly, cellular records and their associated location information are being used in civil litigation, where previously they were considered to be a “law enforcement only” tool.  But in the age when users carry at least one smartphone with them at all times, the location data with regard to calls / texts / data usage can be crucial evidence in certain cases. These include insurance fraud investigations, domestic / custody / cohabitation matters and personal injury cases.

As we’ve detailed in previous articles, there are five main US-based cellular carriers:  Verizon Wireless, AT&T, Sprint, T-Mobile & U.S. Cellular. But what about those not on the list of five?  What about Boost or Straight Talk or Virgin Mobile or Cricket or Tracfone or… the list goes on and on. Well, these carriers are all what are known as mobile virtual network operators or MVNOs.  Check out our article detailing the record retention periods for each provider.

Essentially how MVNOs operate is by “leasing” the use of one of the five main cellular carriers, or sometimes more than one, to increase subscribership and allow of use of multiple devices on their plans, many of which are pre-paid or pay-as-you-go. Some MVNOs operate on strictly CDMA or GSM networks and some operate on both. Some MVNOs may be nationwide and some may be regional, as was the circumstance we dealt with recently regarding an MVNO that was based in the Tennessee Valley. The fact is, MVNOs far outnumber their host-networks in sheer numbers.

The first step is to determine which carrier the target of your investigation subscribes to, or which carrier owns the service for that number.  For this, the simplest resource is the Hawk Analytics Support site, which is free with a registration. The support site also has articles, sample wording for process, best practice documentation and more.

When you identify the carrier you need to submit legal process to is an MVNO, one of several things may happen upon submission, depending on what type of information you’re seeking and with which MVNO the account you’re interested in is associated.  For example, Boost or Virgin Mobile will refer you to Sprint’s legal compliance center for all types of requests, but Tracfone will not provide records for cell site listing and GPS location information.  Those requests will be referred to the parent network.  It really just depends on the MVNO you’re dealing with.  Remember, even if the account is a pre-paid “drop/burner phone” and the subscriber didn’t have to give a name or ID when initiating the account, there can still be great investigative data contained in the records.

And remember, only Verizon Wireless stores standard text message (SMS) content for a minimum of 3 and a maximum of 10 days.  After that, the information is purged.

As a quick reference, compiled a list of major MVNOs that you may run across in your investigations. All of the addresses for service of legal process to the respective MVNOs may be found on the ISP listing under the “Resources” tab on search.org.

Verizon Wireless-Only MVNOs

• Xfinity Mobile (Comcast)
• Affinity Cellular
• Spectrum Mobile
• Total Wireless
• GreatCall

AT&T-Only MVNOs

• Black Wireless
• Cricket Wireless
• EasyGO Wireless
• FreeUP Mobile
• Jolt Mobile
• Pure Talk USA
• RuraLTE
• ZillaTalk

Sprint-Only MVNOs

• Boost Mobile
• Chit Chat Mobile
• Kroger i-wireless
• Patriot Mobile
• Ready Mobile
• Tello US
• Scratch Wireless
• Virgin Mobile USA

T-Mobile-Only MVNOs

• China Telecom Americas (CTExcel)
• GoSmart Mobile
• KidsConnect
• Liberty Wireless
• Mint Mobile
• Roam Mobility
• SeaWolf Wireless
• Simple Mobile
• Ultra Mobile
• Value Wireless
• Walmart Family Mobile

As previously stated, some MVNOs use multiple networks for their service.  Which network is utilized can depend on where the device is purchased (i.e, Walmart, Target, etc.) and/or what type of device is selected for use.  This naturally allows for the MVNO to cast a wider net and attract more customers, but it can make things confusing for investigators who are trying to figure out where to submit legal process.  Here are some of the more common cross-carrier MVNOs:

• FreedomPop:  AT&T, Sprint
• Consumer Cellular:  AT&T, T-Mobile (GSM)
• Republic Wireless:  Sprint, T-Mobile
• Flash Wireless:  Sprint, Verizon
• Expo Mobile:  Sprint, Verizon
• EcoMobile:  Sprint, T-Mobile, Verizon
• Red Stick Wireless:  Sprint, T-Mobile, Verizon
• Best Cellular:  AT&T, Sprint, T-Mobile, Verizon
• Red Pocket Mobile:  AT&T, Sprint, T-Mobile, Verizon
• Straight Talk:  AT&T, Sprint, T-Mobile, Verizon
• Net10 Wireless:  AT&T, Sprint, T-Mobile, Verizon, US Cellular
• Boom Mobile:  AT&T, Sprint, Verizon
• TracFone:  AT&T, Sprint, T-Mobile, Verizon, US Cellular (feature phones only)
• Google Fi:  Sprint, T-Mobile, US Cellular

A complete and up-to-date list of MVNOs, their networks and some features about the available plans can be found at this Wikipedia page.

Wrapping It Up

MVNOs are a fact of life when looking to use cellular location data conducting investigations.  By arming yourself with the knowledge of which MVNO operates on which parent network and which information is available from whom, you can save valuable time, money and heartache.  Happy hunting!

About The Author

Patrick Siewert is the Principal Consultant of Pro Digital Forensic Consulting, based in Richmond, Virginia.  In 15 years of law enforcement, he investigated hundreds of high-tech crimes, incorporating digital forensics into the investigations, and was responsible for investigating some of the highest jury and plea bargain child exploitation investigations in Virginia court history. Patrick is a graduate of SCERS, BCERT, the Reid School of Interview & Interrogation and multiple online investigation schools (among others). He is a Cellebrite Certified Operator and Physical Analyst as well as certified in cellular call detail analysis and mapping. He continues to hone his digital forensic expertise in the private sector while growing his consulting & investigation business marketed toward litigators, professional investigators and corporations, while keeping in touch with the public safety community as a Law Enforcement Instructor.

Email:  Inquiries@ProDigital4n6.com
Web: www.ProDigital4n6.com
LinkedIn
Twitter: @ProDigital4n6

by Christa Miller, Forensic Focus

The oldest of the trio of Techno Security and Digital Forensics Conferences, the Myrtle Beach event marked its 21st year this June 2-5. More than 900 people representing the Americas, Europe, Asia, and Africa converged on the Marriott Grande Dunes resort for three days packed with lectures, hands-on labs, vendor exhibitions, and networking. Receptions on both Monday and Tuesday nights were well attended, with conference-goers lining up on the hotel’s outdoor patio for refreshments.

About 95 speakers presented more than 100 session topics ranging from digital forensics and incident response to information security; from investigations to ediscovery; and audit/risk management. Forensic Focus recaps session highlights below.

Day 1: DVR Analysis, Cloud Investigations, AI-Enabled Image Recognition, Modern-Day Acquisition, and Telegram Forensics

The conference kicked off at noon on Sunday. Jimmy Schoering, CTO at DME Forensics, began by sharing two case studies in which digital video recorder (DVR) evidence was needed for homicide investigations.

Schoering detailed his testing process including documenting baseline dates, times, and log entries, then using test data to determine how date/time changes would be reflected in the logs. He also discussed how to establish what’s on the DVR, including using frame-level metadata to show overlaps, overwrites, and time changes, and how answering “how and where” might help answer “who and why.”

In addition, Schoering covered how the subtle differences in the written report’s language that could be used in testimony at trial. Showing that the DVR wasn’t in service and recorded no data, for instance, is very different from showing simply that video couldn’t be recovered due to being overwritten.

Cloud investigations have historically been one of the trickiest for many investigators to implement owing to thorny legal questions. That was reflected at the start of a talk by Magnet Forensics’ Trey Amick, who spoke about when and why to include evidence from the cloud in investigations.

Why is it important? For one thing, only 2 weeks’ worth of Facebook Messenger conversations are stored on a person’s device; the rest remain cached in the cloud. Pixel smartphone owners are offered unlimited Google Photos storage. Cloud-based data can still provide evidence, even if suspects destroy their phones to prevent evidence collection.

Amick described different acquisition methods, including having subjects do their own Google Takeout, using the passwords or tokens stored within the device to search (assuming either a search warrant or other legal authority to do so), and conducting a “plain view” search using publicly available data such as tweets (commonly known as open source intelligence or OSINT).

In most cases, however, it’s wise to authenticate the collected data by serving the provider with a search warrant. Amick cautioned that this can take time, but is worth it to validate the evidence by matching key data points.

Next up was BlackBag Technologies’ Director of Training, Matt McFadden, who presented on how to leverage deep machine learning to triage pictures and videos. McFadden described how media categorization can go beyond skin tone — and the “AI buzzword” — to obtain results faster and more efficiently by making the computer do most of the heavy lifting.

This is especially important when it comes to identifying unknown images — in other words, images not already in Project VIC, Innocent Images, or other databases — that can indicate production and/or new victims. Even in cases that don’t involve child exploitation, newly identified images can be run against data from old cases, potentially helping to develop leads.

McFadden stressed that human eye verification is still needed, and that once identified or located, images need to be investigated further: examiners must analyze filenames, storage locations, timelines, permissions, media source(s), and file types, as well as determining who else has access to the computer and/or browser cache. He called this the difference between simply clearing and investigating case backlogs.

McFadden’s presentation was followed by Dr. Bradley Schatz of Schatz Forensic, makers of Evimetry. Schatz offered a roadmap to what’s changed in forensic acquisition of modern evidence, beginning with numerous challenges that all act to slow acquisition speeds. To meet these challenges, Schatz argued for a rethinking of acquisition workflow methodology: Advanced Forensics File Format (AFF4).  

While Schatz will be publishing the results of his emerging work in July at the Digital Forensics Research Workshop (DFRWS) in Portland, Oregon, he provided an overview in this session. AFF4 offers an advantage over triage in that it not only reduces latency, but can speed up acquisitions at the same time that it supports both live analysis and metadata collection.  

In other words, AFF4 reduces delays by allowing analysis and acquisition to be accomplished at the same time. Its nonlinear acquisition strategy turns triage into forensically reproducible activity by ensuring all files, metadata, etc. have all necessary NTFS timestamps. In this way, analysis/processing during acquisition gives answers hours and days earlier per device. 

If you’re interested in learning more, the AFF4 code is available in the pyaff4 Github.

Day 1’s final presentation in the digital forensics track came from Yuri Gubanov, CEO/Founder of Belkasoft, who covered Telegram Messenger investigation on mobile devices.

Describing how Telegram was created with security in mind — features include secret chats, time-limited messages, end-to-end encryption, and even notifications about screenshot taking of secret chats — Gubanov discussed forensics of the Telegram app on both rooted Android and jailbroken iOS devices (as well as ADB and iTunes backups).

In addition to database structures and artifacts available on both platforms, Gubanov discussed SQLite forensics: finding additional artifacts in freelists, write ahead logs (WALs) or (in older Android versions) journals, and unallocated space.

Sessions were followed by a reception in the exhibit hall, where more than 55 exhibitors joined the conference. The informal gathering saw longtime conference attendees joined by new faces, and was a good opportunity for many to catch up with old friends and make new ones.

Day 2: Keynote; Forensics on Drones, Chromebooks, and the Internet of Things

Monday’s sessions kicked off with a fast-paced keynote by Sherri Davidoff, founder and CEO of LMG Security and BrightWise, on “Emerging Threats and How to Counter Them.” Citing statistics showing that the average data breach costs $3.9 million, Davidoff described how small businesses, local governments, and schools can be devastated by banking trojans, ransomware, and cryptojacking.

In large part, this is owing to a multitude of factors, from poor implementation of security tools to criminals’ sophistication. Organizational issues like high turnover and fear of legal repercussions factor in, too.

These issues have been perhaps never more critical than now. With 30 billion IoT devices estimated to be online globally by 2020, Davidoff cautioned that the potential goes far beyond simply using IoT devices to power internet outages, as the Mirai botnet did in 2016. She predicted an uptick in cryptojacking, which could potentially allow criminals to lock and ransom building access, cameras, and other physical security measures.

Davidoff’s position is to take a similar approach as in healthcare: assume your organization is breached unless proven otherwise. One of her most important takeaways, therefore, is the need for smarter spending, i.e. refocusing from “big, fancy equipment” to organization and communication. That includes:

• Overcoming embarrassment and fears around duty-to-notify laws (and the associated potential for financial repercussions).
• Better process between legal, IT, and other departments.
• Refocusing from restoring operations to investigations — finding out how attackers got in a network, what data they got, how long they’ve been in, and whether they’re still there.
• Spending on proactive vs. reactive strategies, such as threat hunting.
• Less glamorous but effective preventive measures such as regular, rapid system patching, 24/7 monitoring that includes tests on weekends and holidays, email filtering with attachment restrictions, employee phishing training, strong passwords and two-factor authentication (2FA), the use of virtual private networks (VPNs), and more.
• If your organization is affected by ransomware, Davidoff shared her “Ransomware Dos & Don’ts (available as an article on LinkedIn). 

Just as criminals build relationships to distribute their wares, Davidoff further stressed, so does anyone involved with security. Information sharing, backed up by laws and regulations that encourage openness, is also key.

Following the keynote, the day’s first digital forensics track session focused on visualizing unmanned aerial system (UAS) forensic data. David Kovar and Greg Dominguez of Unmanned and Robotics Systems Analysis (URSA) focused on the need for visualized data to contextualize drones and the environment in which they’re found. 

UASs are complex — involving multiple pieces of hardware, as well as variables like the weather, battery power, the human operator, and data at rest and in motion across these pieces — so forensic examiners need to investigate a full range of paper trails and data from multiple sources to help contextualize your findings and the actions you took on scene. The end goal: understand (and potentially present to attorneys) what the operator(s) were looking at and why the drone was there.

Jessica Hyde, Director of Forensics at Magnet Forensics, then offered research on Google Chrome operating systems and Chromebooks. The devices’ cost-effectiveness, easy availability, low maintenance requirements, and relative security means more people and organizations are purchasing them.

Hyde’s presentation described various details around the ChromeOS integrated media player and file manager, as well as its ability to run any app from the Google Play store via built-in Android emulation. Perhaps most importantly, while Chromebook evidence can indeed be obtained via cloud acquisition or Google Takeout, the devices also can support a hard drive and store data locally.

Hyde stressed that challenges — and research opportunities — abound, including imaging, encryption, and what artifacts are possible to obtain for analysis. (Hint: artifacts are Chromium OS-based and in addition to browser-related ones, could include Linux shell artifacts like .bash_history.) In addition, Google Takeout only comprises browser history, not current/last tabs/sessions, cache or downloads that can prove nefarious intent.

Want to start on your own research? Hindsight, made by Ryan Benson, supports Chromium browser forensics; support for Chrome OS paths is included. 

The afternoon’s sessions began with a panel discussion on forensic certifications: why to get them, which ones to get, and in what order. Jared Coseglia, founder and CEO of TRU Staffing Partners, moderated the discussion between Stroz Friedberg’s Nathan Mousselli and Special Counsel’s Doug Brush. Describing a “full ecosystem” of core, advanced, proactive, and managerial-level certifications, the panel discussed:

• Exploring the different options that can lead down various competency pathways, and time and monetary requirements — including obtaining certifications on your own time and expense.
• How disciplines like privacy, e-discovery, or cybersecurity generally lack Bachelor’s-level degrees, which can pose a challenge to those seeking a clearly defined career path.
• Tool-specific certifications mean that individuals can become as “billable” as possible, making it possible for employers to leverage them more quickly.
• Different verticals might assign different levels of importance to different certifications depending on the types of work — mobile vs. hard disk vs. network forensics, etc.
• Certification maintenance depends on where you are and where you’re going in your career: from defensive to offensive security, for example, or from incident response on local networks, to AWS or other cloud-based environments.
• Obtaining training may require some creativity. For example, Brush persuaded his employer to sponsor classes for free in return for a free seat. He credited active community involvement in helping his staff to obtain their certifications, too.

Following the panel, Mike Raggo, chief security officer at 802Secure, presented on IoT wireless network forensics. Having presented at both RSA and DEFCON, Raggo described research on IoT cameras, USB ports, and smartwatches.

Raggo’s presentation echoed Davidoff’s keynote in discussing how IoT risks impact more than infosec and IT: facilities, retail, operations, building automation etc. can all be affected by data center disruption, data loss and credential theft, and IP theft or espionage. IoT breaches can also impact emergency response to fires, pathogens, floods, or simple power outages.

For example, a point of sale (POS) device in one organization were discovered to have Bluetooth radios installed, while Raggo cited research showing that 50 percent of organizations have at least one spy camera undetected by network security products currently in place.

Day 3: CCleaner Research, Emoji Artifacts, Malware Analysis, Private Browsing, and Identifying Darknet Suspects

Starting Techno’s third day was Kathy Helenek, of Digital Intelligence, who questioned whether a suspect’s use of CCleaner is really the end of forensic investigations as we know them. Her research compared forensic artifacts from systems that deployed both normal and “secure” deletion processes with CCleaner.  

What she found: with a few exceptions and even surprises, CCleaner’s Secure Delete indeed does what it claims. While she was able to recover numerous registry artifacts, shell items, metadata, and files following “normal” deletion, in most cases, “secure” deletion replaced alphabetic characters with Z’s and numeric characters with 0’s.

Helenek stressed to check artifact locations and validate if you see CCleaner has been run. Consider alternative ways, such as the use of volume shadow copies, carving, or syncs from Google or other devices to obtain the data, since tools are unlikely to see it. If the disk’s free space isn’t wiped, you may be able to recover some data files.

Helenek’s research involved using several tools written by Eric Zimmerman: in particular, Registry Explorer and Jump List Parser. Further testing is needed on roaming profiles and SQLite databases’ free pages.

Following Helenek’s presentation, Preston Farley, a Special Investigator with the Federal Aviation Administration (FAA), presented research on the forensic implications of emojis. Notably, when parsing private or text messages, social media posts and comments, email, and in some cases even usernames and passwords, you may encounter rendered — and unrendered — emoji, or the pictographic symbols used to denote emotions and in some cases, replace alphanumeric characters.

Courts struggle to address emoji. However, because many people communicate in emoji and Unicode’s emoji set grows every year, Farley’s presentation brought to light two different issues with interpreting emojis: a technical layer, and a social layer.

• On a technical level, Unicode support suggests, but doesn’t define, an emoji’s appearance; a “grinning face with smiling eyes” may look very different across Apple, Google, MS, Samsung, LG, HTC, Twitter, FB, Mozilla, Emoji One and others. Additionally, the Unicode Private User Area enables private parties to create their own emojis (often associated with proprietary logos), making it possible to use emojis no one else is familiar with.
• On a social level, people use emojis to communicate high level ideas without language mastery when they’re less literate or communicating across languages and cultures. However, what means one thing in one community can mean something totally different elsewhere — emojis are open to interpretation. This has obvious implications for investigators seeking to prove intent.

Farley argued that emoji support is currently a “huge void” among forensic tools, a gap that needs to be filled. Tools such as PyMoji.py can help, but broad support is needed: because the tools rely on operating systems, if emojis aren’t rendered on the system, they won’t be in the forensic tool, either.

Luiz Borges and Wilson Cordeiro, consultants with Brazilian firm TechBiz Forense Digital, presented “Malware Analysis and Reverse Engineering for Dummies,” including how to set goals: to data mine what happened and locate all infected machines/files; to determine what it does, how to detect it, how to contain/measure damage, and develop signatures to proactively hunt; host-based signatures detect infections on computers, network-based signatures; figure out how malware works.

The two fundamental approaches that Borges and Cordeiro covered were:

• basic / static: examining malware without running it
• dynamic analysis, running it (safely on an environment without risk of damage to system or network)

Other parts of the process include checking the executable’s libraries and functions once found, then using Process Explorer to see everything (including memory) running and consuming resources on the system. Likewise, when running the malware, use Procmon to identify every process plus changes being made on the system.

Borges and Cordeiro also demonstrated how to use Lightshot to take system snapshots to compare any filesystem changes. This kind of research, they stressed, is constant because just as you learn about one piece of malware, adversaries respond with new variants. Keep learning!

Forensic analysis of private browsing mode activity was the subject of a presentation by Joe Walsh, MCJ Program Director and Instructor of Criminal Justice/Computer Science at DeSales University. Contrary to marketing messages about the ability to browse without leaving traces, internet service providers (ISPs) still log what you’re doing, and are accessible to investigators with the proper legal authority.

Walsh’s research tested six browsers tested in six separate virtual machines using exactly the same activity, including searches, clicks, in-depth site visits, video watching, social media activity, etc. At the conclusion of each stage of research, Walsh captured RAM, which turned out to be key to his findings: while little browsing data was found on the hard drive, all browsers left some activity in RAM.

Therefore, while conventional wisdom dictate turning off the computer during a seizure, you should plan to modify your best practices to capture RAM before turning off the machine. Otherwise, a suspect’s attorney can mount a credible defense that the RAM you didn’t capture could have proven their client’s innocence, potentially leading to exoneration.

Walsh’s plans for future research include macOS, TAILS (The Amnesiac Incognito Live System, whose OS boots off a flash drive on computers with no hard drive), and mobile devices.

Also on the web-browsing continuum, Dr. Gareth Owenson, of Searchlight Security, spoke about how law enforcement can “hack” to identify darknet suspects.

After describing how Tor works to protect its users’ anonymity through a network of relay points, as well as how its “onion layers” work for encryption, Owenson described routes to deanonymization, with a focus on identifying users rather than sites.

This is possible through, as in many other criminal investigations, following the money: although most darknet transactions happen in cryptocurrency like Bitcoin, these aren’t actually anonymous because users want to turn it into cash to spend. Additionally, users often rely solely on Tor security, and don’t layer it with their own opsec (operational security).

Owenson showed how Searchlight’s Cerberus platform intercepted private messages between users revealing identifying information — Bitcoin wallet, email, home address, name — and how it can target MAC and IP addresses, along with user IDs (UIDs), to target users who are downloading or distributing illicit images.

Day 4: Forensic Identification of Fake Photos, Windows 10 Timeline Analysis, and Wearable Device Forensics

Techno’s final sessions took place on Wednesday morning. First in the digital forensics track: at a time when faked images and videos are feared to have alarming political, social, economic, and religious impacts in societies worldwide, Chet Hosmer, founder and technical author at Python Forensics, presented on the forensic identification of fake photos.

In contrast to steganography, fake photo research isn’t about hiding random data in a single pixel within an image. Rather, it’s about using algorithms to identify how images are merged, using anomalies that occur during the process of merging. The focus has shifted, too, from identifying illicit content, to protecting legitimate content.

To that end, Hosmer demonstrated the proof of concept Fake Image Analysis Testing Script (FIATS) core Python open source script, showing how anomalous integrations with a subject’s background are marked (as pixellations).

By looking at each pixel as a cell making up a grid, it’s possible to look at a single pixel as a center point in certain parts of an image, then look at that point and its surrounding pixels to see anomalous transitions. Applied to video, the FIATS technology performs this operation frame by frame to detect manipulation. Hosmer’s team is currently working on applying the technology to “deep fake” analysis.

Next, Spyder Forensics founder and CEO Rob Attoe presented on Windows ® 10 timeline analysis. An “immersive” browser of user activity across all devices — Office files interacted with, websites visited, graphics viewed, games played, etc. — the Windows 10 timeline offers up to 30 days of activity history for each account across devices where the user logged in. That includes OneDrive ® synchronization from each device.

Some of the takeaways from Attoe’s talk include debunking the “malware put it there” defense by recording how long the user interacted with a given file, as well as wherever the mouse or keyboard is active in a particular window and whether content was copied and pasted.

Attoe covered timeline, cloud account, and synchronization settings (including when group policies may be set in a corporate environment), as well as SQLite databases like activitiescache.db and timestamps such as lastmodifiedtime, expirationtime, createdincloud, starttime, enditime, and lastmodifiedonclient.

The conference’s final digital forensics presentation came from Nicole Odom, Forensic Scientist Trainee at the Virginia Department of Forensic Science. “Go-Go Gadget, Smartwatch” described Odom’s investigation of wearable devices and their forensic value in both connected and standalone states.

As smartwatches grow in popularity thanks to users’ interest in their convenience in tracking fitness activity and other tasks, Odom sought to understand interactions between wearables, phones, and cellular networks; what kind of probative evidence each might store; and locations of user data and artifacts.

One of the most interesting parts of the presentation was Odom’s description of her persistence in testing different methodologies to find the most viable, minimally invasive processes. By combining commercial tools, developer tools such as Tizen Studio SDB, and even constructing her own cables, Odom showed that a willingness to experiment (and document the outcomes) is often as important as the results.

Odom was also able to use her research to contribute to open source tools, and to develop her own: Gear Gadget is a data extraction tool for Samsung Gear S3 wearables. It’s available for download here and a GUI-based version is planned. Odom also contributed to the Artifact Genome Project. 

The team’s research was presented at the 71st Annual American Academy of Forensic Sciences meeting in February 2019. Their paper will be published in an upcoming issue of Journal of Forensic Science. Future research will explore mounting wearables to PC, logfile and timeline artifact analysis, deciphering fitness data, advanced acquisition, Apple Watch encryption, and the use of Elcomsoft’s iOS Forensic Toolkit for wearables.

Future Techno Security & Digital Investigations events will take place September 30 – October 2nd in San Antonio, Texas; March 9-11 in San Diego, California; and May 31 – June 3 in Myrtle Beach. Find out more here.

From the 30th of September to the 2nd of October 2019, Forensic Focus will be attending the Techno Security & Digital Forensics Conference in San Antonio, TX, USA. If there are any topics you’d particularly like us to cover, or any speakers you think we should interview, please let us know in the comments.

Below is an overview of the subjects and speakers that will be featured at Techno Security. The conference has four tracks: audit / risk management; forensics; information security; and investigations, along with sponsor demos. Forensic Focus will be concentrating on the digital forensics track throughout the event.

Monday September 30th

The program will begin at midday, with Eugene Filipowicz from Kroll giving a forensicator’s guide to fakes, frauds and forgeries. Alongside the rise in ‘fake news’ sites has been a rise in digital forgery of documents as well. Filipowicz will show how to use digital forensic tools to uncover fraudulent documents.

Alongside this, Rob Attoe from Spyder Forensics will be talking about drone forensic analysis and demonstrating the kinds of evidence investigators can expect to encounter in cases involving drones. Meanwhile in the Audit / Risk Management track, Harvey Nusz and Tony Belilovskiy will be hosting an interactive discussion about the US privacy landscape and how it has been affected by the California privacy act.

At 1.15pm, Jamie Clarke will be talking about darknet markets and how much illegal content is easily available there. Particularly focusing on fake IDs and their links to international terrorism, Clarke will highlight the importance of remaining on top of darknet activity in law enforcement investigations.

Trey Amick from Magnet Forensics will be showing attendees how the latest updates to macOS impacts on digital forensic investigations. He will also look at APFS artifacts and files including KnowledgeC.db, FSEvents, Volume Mount Points, Quarantined Files, and bash history.

At 2.45pm, Vico Marziale from BlackBag will go through the Windows 10 Timeline and talk about its use and application in forensic investigations. Meanwhile Trent Livingston from ESI Analyst will discuss the importance of linking as much data as possible together during digital forensic investigations, which can help to uncover key dates, locations and activities within a case.

The final sessions of the day will include a presentation on chip-off mobile forensics by Dusan Kozusnik, CEO of Compelson; a discussion of US data protection law as it currently stands, and what changes we can anticipate in the future; a look at cyber security threat and forensic intelligence; and a session from Elena Steinke from the Women’s Society of Cyberjutsu, who will be talking about the importance of private and public sectors working together by launching counter-intelligence-like operations in cyberspace.

Tuesday October 1st

The second day of the conference will begin at 8am with a keynote by Roman Yampolskiy from the University of Louisville. Yampolskiy will be discussing how artificial intelligence will impact on the future of cybersecurity, with a particular focus on the rise of AI-enabled cyberattacks and fake forensic evidence.

Following the keynote, at 9.30 speakers from Protiviti will be tackling the thorny issue of how to prove a negative in cybersecurity investigations. Chet Hosmer from Python Forensics will show us how to investigate fake digital photos; and Tarah Melton from Magnet Forensics will do a deep dive into Windows memory analysis.

Taking your forensic analysis to the courtroom and presenting it in a way that makes sense to non-technical members of the public is a challenge at best, and at 10.45 Jeff Shackelford from Passmark Software will talk attendees through how to create a virtual machine from a forensic image to be presented in court.

Jason Roslewich will discuss some unique characteristics of APFS, as well as forensic imaging methods; and over in the info security track will be the intriguingly titled ‘Hack Yourself Before The Hackers Do.’

After lunch, Magnet’s Trey Amick will take to the stage once again to show how investigators can use GrayKey and AXIOM to acquire and parse iOS data that other tools may have missed. Steven Konecny from EisnerAmper will show attendees how to investigate Ponzi schemes in the 21st century; and Charles Giglia, VP of Data Intelligence, will demonstrate the capabilities of CCleaner and discuss whether it signals the end of digital forensics as we know it.

The dark web will again be a topic of discussion on Tuesday afternoon, with Vincent Jung from Media Sonar discussing effective strategies for running darknet investigations. Lee Reiber, COO of Oxygen Forensics, will demonstrate the huge amount of data that can be gleaned from smart fitness trackers such as the Fitbit and the Apple Watch. And Nuix’s Hoke Smith will show attendees how to detect and investigate malicious PowerShell.

At 4.30pm Andy Thompson from CyberArk will be discussing ‘Really Bad SysAdmin Confessions’, talking through some of the worst mistakes we know about in the industry and how we can avoid them. Drones will be the topic of discussion over in the Forensics track, with Greg Dominguez and David Kovar showing how to select and visualise data obtained from UAVs.

In the Info Security track, Steven Chesser will talk about the GDPR and how it can improve process, culture and the bottom line.

The day will be rounded off with a talk from John Wilson on the legal implications of Blockchain technology for digital forensic investigations.

Wednesday October 2nd

The final day of the conference will begin with an early riser session at 8am, in which Stephen Arnold will talk about the latest changes to the dark web and how they will impact on investigations. Although the number of sites on the dark web has decreased, illegal activity is continuously on the rise. Arnold will show how end-to-end encryption, surface web discussion groups, pastebins, and obfuscation tools are playing an important role in illegal dark web activity, and discuss what we can do to address this challenge.

At 9.15am Will Hernandez from MSAB will show attendees how to use the latest exploits to recover data from Android devices; speakers from NTT Security will show how hackers gain unauthorised access to buildings; Michael DaGrossa will talk about the need for artificial intelligence in information security; and Tarah Melton from Magnet Forensics will demonstrate how to tell a digital story using Connections and Timeline in Magnet AXIOM. Meanwhile over in the Investigations track will be a talk about social media, digital evidence and ‘what lurks in the cloud’.

Speakers from Belkasoft will be presenting at 10.30am, looking at different approaches to mobile device acquisition. In the Forensics track will be a discussion about building a successful threat hunting program; and in Info Security we will be looking at cloud security automation.

After lunch, speakers from Ansilio will show how to reveal issues and risks that keyword searches may have missed. Barbara Hewitt from Texas State University will demonstrate how to examine threat avoidance theories; and Gregg Braunton will discuss the importance of having a ‘statement of work’ prepared. Abdul Hassan will be running his ever-popular demonstration of social media analysis in counter-terror investigations.

At 3.15pm Jerry Bui will talk about the challenges associated with running digital forensic investigations in the era of fake news, and how these can be addressed. Ronald Hedges will discuss how cybersecurity and technology can be used by attorneys over in the Info Security track; and the day will draw to a close with Stephen Arnold taking to the stage once more to provide some deeper insights into recent updates on the dark web.

There will also be networking events taking place throughout the conference, which will be advertised during the conference and in the program. Find out more and register to attend here.

by Michelle Oh, HancomGMD 

With an ever-increasing range of features and dramatically increased storage capacity, digital devices have become essential to our daily life. Their ability to store vast amounts of data means that these devices have proliferated and are now found in every household. They therefore prove to be a source of crucial information that acts as evidence in digital forensic investigations.  

With the expansion of 5G technology, we expect a new chapter in mobile development, and this will bring huge innovation for new technologies such as infrastructure, city management, autonomous vehicles, and connectivity for the consumer mobile internet. And this explosive growth of digital data will lead all investigators to face highly demanding challenges.

This article covers HancomGMD’s data extraction solution ‘MD-NEXT’. It focuses on how investigators can practically use MD-NEXT for both logical and physical data extractions. 

Following the step-by-step instructions below will show you the mobile data extraction sequence. It is a simple but useful tutorial for investigators who are looking for a tool which addresses all their their mobile forensic investigation needs.

I. Data Acquisition Sequence Method – Physical Extraction

Tested device – Samsung Galaxy S7 (SM-G935F) 

Step 1: Connecting the Device and Finding the Model

MD-NEXT provides a user-friendly and intuitive interface, to help you to easily find and select the device model. After the device has connected, click the cable icon on the bottom right of the screen and MD-NEXT will automatically detect the model. 

MD-NEXT supports more than 15,000 smartphone devices from around the world, including over 500 models from Chinese manufacturers (Huawei / Xiaomi / Oppo / Vivo, etc.) It also supports the extraction of IoT devices, AI speakers, smart TVs, drones and vehicle systems. 

Advanced Physical Extraction Features: 

• Bootloader, Fastboot, MTK, QEDL, Custom Image, rooted Android, iOS physical, ADB Pro, DL, JTAG, Chip-off, SD card, USIM, removable media 
• JTAG pin map viewer and connection scanning with AP 
• Drone SD card extraction: DJI Phantom, Maverik series / Parrot / Pix Hawk 
• AI speaker chip-off extraction: Amazon Echo, Kakao Mini, Naver Clova 

Step 2: Extraction Method

In the screenshot below you can see the available extraction methods for the model we have selected. Both logical and physical extractions are available. Selecting ‘BootLoader’ lets you extract all the mobile data including filesystem, user data, cache and so on. Then select the build number which matches your phone. A set of simple instructions will lead you to the download of the customized firmware.

Example: Build List for Samsung Galaxy Note 4 (SM-N910S)

MD-NEXT comes with an intuitive graphical user guide for each extraction method.

Samsung Galaxy S7 (SM-G935F) in Download Mode

Step 3: Selecting the Data Partition

When the device enters “Download Mode”, MD-NEXT recognizes and shows the file system to be extracted, and the user can easily expand the partition. You can then schedule the extracted data to be analyzed by MD-RED. 

MD-NEXT displays the specific extraction process with a useful menu which shows an extraction progress bar, as well as time and hex data by partition.

Step 4: Exporting the Acquisition Report

After the extraction sequence is completed, the user can generate an ‘Acquisition Report’. This contains detailed information of extracted partition: file path, file size, size of extracted data, and so on. All of the extracted data is guaranteed with the hash value.  

Data preview and save function: 

• Preview extraction data
• Hex viewer, data viewer 
• An image dump can be saved as ‘MDF’ and standard binary file format 
• Pre-defined extraction file name 
• Sound alarm for extraction status change 

Specific reporting function for integrity: 

• Extraction information: hash value, time, method and file name 
• Supports report formats such as PDF, Excel and HTML 
• Supports ‘Extracted File List’ generation with a hash value of each file 
• Supports ‘Witness Document’ generation 
• Regeneration of ‘Extraction Reports’ 

II Data Acquisition Sequence Method – Logical ‘Android Live Extraction’ 

Tested device – Samsung Galaxy Note 9 (SM-N960N)

Step 1: Device Connection and Logical Live Extraction

Android Live Extraction is a method of extracting the key active files from an Android Phone. After the device is connected, set up the phone as shown in the guide. MD-NEXT will automatically recognize the device.

Step 2: Data Extraction

You can then select the range of data for extraction. MD-NEXT will then start to acquire data from the device. You can check the extraction time and the status for each app on the ‘Extracting’ screen. 

Selective extraction for privacy protection: 

• Supports selection of partition, file, category and app 
• Supports selection of file system physical extraction 
• Supports selection of all logical extraction methods 

Step 3: Exporting the Acquisition Report

The acquisition report contains useful information such as hash value, time, extraction method, and file name. The report can be formatted as PDF, Excel, or HTML.

If you want to learn more about MD-NEXT, please visit our website or send an email to sales@hancomgmd.com 

Click to download the MD-NEXT Product Brochure

by Mike Dickinson, Deputy Executive Officer at MSAB

The purpose of this paper is to encourage mobile forensic practitioners to consider a wider number of critical factors surrounding their choice and use of mobile forensic tools. Specifically, the quality of decoding, training of users and ultimately the preservation of digital as evidence in court proceedings.

Introduction

There is a tendency in the world of mobile forensic tools to focus on one thing: data acquisition.

Most users tend to focus on purchasing a tool that gets them access to the data. Makes sense, right? Not much point in doing anything else, if you can’t get the data in the first place, and we would agree. But it shouldn’t stop there. There are four critical factors to consider:

1. Accessing Data
2. Decoding Data
3. Data Integrity
4. Training Users

This white paper focuses on points 2, 3 & 4 on the assumption that point 1 is already self-evident and gets plenty of attention in the marketplace.

The message here is that it doesn’t just stop once you have access, there are still some vitally important matters to consider before presenting your evidence in court.

1. Accessing data

If you do mobile forensics, you know that the hardest thing is getting the data in the first place. It is also the one thing customers are more than willing to pay for when it comes to the commercial aspects of the business.

This is currently the entire business model of Grayshift, for example, with their iPhone tool GrayKey. This tool is a way to get the data. The value of their product is that they have a unique exploit that allows users to bypass the iOS device security to recover the data.

Critically though, you need to purchase another mobile forensic tool in order to decode that data. The Grayshift business model assumes users already have another mobile forensic tool that can ingest their data and decode it to view the contents.

In other words, getting the raw data isn’t enough. You also need to be able to read it. Which leads us to the second priority – decoding.

2. Decoding Data

Why is decoding important? Put simply – time.

Unless you happen to be a digital forensic expert who reads hex binary data natively and has unlimited time to analyse data dumps, you’ll appreciate that some mobile forensic tools can automatically decode data for you.

Not many people are skilled enough to review binary data on a daily basis. But pretty much anyone can look at pictures acquired from a mobile device and work out if they are relevant or not. That is the value of decoding, it means you can quickly see what has been recovered and then determine if there is anything of evidential value on the device.

Disappointingly, we see a trend of users not giving as much thought to the quality of the tool’s decoding, compared to whether or not it can acquire the data in the first place. This is a significant oversight, given that most people only view what is automatically decoded by the tool.

It is almost as if it is assumed that the data presented will always be everything from the mobile device. Further, that every extraction will present the same data regardless of the tool used, if acquired from the same source. A simple comparison test between different digital forensic tools should soon debunk this assumption.

While the original raw data is always there in the extraction, a forensic tool’s ability to decode and present it is a separate matter. That’s because it relies on software engineers’ understanding of the latest data formats, which are changing all the time.

In our comparison tests between tools we have seen significant variances in the data presented based on the same acquisition. The speed of development and frequency of updates in apps, for example, means that the way data is stored is changing all the time and it is an endless task for tools to keep up to date.

The unpleasant truth is that mobile forensic tools often produce different results when you compare the outputs of their decoding. So, all other things being equal, you want to be sure that your tool decodes the most data in the most reliable way.

A true professional knows this and will have access to multiple mobile forensic tools for comparison and validation purposes. If two different tools come up with exactly the same result, the level of confidence in the results is significantly improved.

Equally, if there are variances, then the need for more verification is justified to ensure the integrity of the evidence presented. In serious crimes this should always be done as a matter of course.

The challenge of time, however, means that this isn’t always done in every single case. For example, it is neither practical nor proportionate for a non-specialist investigator to spend days studying digital data, for a minor case of shoplifting.

Nevertheless, investigators do need to review the contents of the phone extraction to ensure they are not overlooking evidence of similar crimes or more serious offences that make the case a more serious matter worthy of further investigation.

The simple shoplifter?

Imagine a scenario where you are using a mobile forensic tool without the latest decoding capability for WhatsApp and because it can’t see the contents of the messages, it presents no more evidence. You assume the shoplifting suspect is a one-off case and let him off with a warning and the case never goes to court.

Now imagine the same phone going through another tool that does have the latest support for WhatsApp and the data reveals that the suspect is working for a network of criminals who are dealing in stolen goods in order to fund terrorism.

This is an extreme example to make the case, but hopefully you now appreciate the importance of checking the quality of decoding that a mobile forensic tool offers.

3. Data Integrity

What if you did all that work to generate a report for presentation in court, only to discover it wasn’t usable in court?

Getting past security and encryption to acquire the data is important. Hopefully you now also appreciate the importance of good decoding too, but what about producing it as evidence?

We call this the ‘Chain of Custody.’ That’s because in many courts you need to be able to prove the origin and reliability of the evidence you present in court – from the moment it is first acquired until the day of the trial – to demonstrate that it has not been interfered with or altered in any way.

Most law enforcement users understand the necessity for the preservation of physical evidence. It’s commonly understood that you should preserve and not contaminate DNA evidence. Equally, that you should allow the defence the opportunity to examine the evidence to see if they get different results.

So how does this work in the realm of digital data evidence?

The Principles of Digital Evidence

The best guide written on this topic came from the Association of Chief Police Officers. The Good Practice Guide for Electronic Evidence outlined four principles when dealing with this type of evidence:

Principle 1: No action taken by law enforcement agencies or their agents should change data held on an electronic device or storage media which may subsequently be relied upon in court.

Principle 2: In exceptional circumstances, where a person finds it necessary to access original data held on an electronic device or on storage media, that person must be competent to do so and be able to give evidence explaining the relevance and the implications of their actions.

Principle 3: An audit trail or other record of all processes applied to computer-based electronic evidence should be created and preserved. An independent third party should be able to examine those processes and achieve the same result.

Principle 4: The person in charge of the investigation (the case officer) has overall responsibility for ensuring that the law and these principles are followed.

Look at Principle 3 again – an Audit Trail. Does your mobile forensic tool have one?

Seriously, check it out – is there a detailed log of all the processes applied to the device and the results that created the end report?

We know of at least one major tool that does not have an open, accessible audit trail that can be read and understood by an independent expert for the defence. An encrypted audit log of the extraction is not a transparent tool open to enquiry by the court.

Imagine taking all the time to acquire the data, decode it and then prepare a report in order to present the evidence at court – only to have it thrown out because nobody can make sense of what the tool is actually doing?

Impact of Privacy and Data Protection laws

It may seem obvious that by its very nature, the data recovered from a mobile device is often personal data.

Data Protection by design is important when you consider there is a piece of legislation with global reach that impacts law enforcement officers in the European Union, as well as law enforcement officers anywhere in the world, when handling personal data transferred from EU-based authorities.

The European Union’s data protection laws require that personal data be protected so that it is not lost, unintentionally deleted or accessed by unauthorized personnel. And more and more countries, over 100 as of mid-2019, are enacting their own data protection laws and regulations, according to a United Nations tracking study.

The monetary fines for violating data protection laws can be significant – that should focus everyone’s mind on the importance of data protection.

Data Protection by Design

You may be surprised to learn that one of the most popular tools on the digital forensic market stores data in an open file format easily readable in its native format when stored on a computer.

That should be of immediate concern. Consider, for example, an investigation into indecent images, where the file format allows you to see the images natively in Windows or on a USB memory stick or DVD. This type of data should be protected by default.

If you store digital evidence in an open file format, that leaves it open to accidental alteration. How can you show that it has not been interfered with prior to presentation in court? What if someone accidentally dropped images from another case into the wrong folder on the computer where the evidence is stored – how would you know?

Please be sure to check that your digital forensic tool is not susceptible to this basic oversight when considering the issue of data protection and integrity for presentation in court.

4. Training Users

The final piece of the puzzle is training. Your organization probably spent lots of money investing in mobile forensic tools, but does it then invest in the users?

Sadly, too often this seems to be overlooked. The budgets allocated seem to be directed exclusively towards the purchase of products, and training comes as an afterthought.

In times of budget cuts, we appreciate that training may be one of the first areas to be cut, as organizations focus on their immediate short-term need for savings, over the long-term beneficial investment in their staff. It’s natural that tough choices need to be made.

However, the big challenge with mobile forensics is that in order to get the data off a mobile device, you usually need to power it on and because they tend to be proprietary electronic devices, that will alter the state of the device. Thus, from a purely technical perspective, a conflict with Principle 1 of the Digital Evidence guidance.

However, Principle 2 has the answer – the user must be suitably trained.

That leads us to a very relevant court case in Australia where mobile forensic evidence was ultimately rejected. Not because the evidence was unreliable, far from it – the tools worked perfectly. The reason for the appeal was because the officer presenting the data was unable to adequately explain how the tools worked or show that he was suitably qualified: HERE.

… It was the first time he had experienced the relevant software and he did not
have any formal training in its use. It was also his evidence that the software
‘tried to do its best job at doing it’. To my mind this clearly raised questions as
to the reliability of the software and of Constable B’s correct use of it. In my
view, the prosecution failed to establish that the downloading process was of
a type generally accepted by experts as being accurate, and that the particular
downloading by Constable B was properly performed.

Hopefully, from this example you can see that it’s vitally important that organizations keep their users suitably qualified to present digital evidence in court.

The last thing anyone wants is for good evidence to be thrown out because it was not presented in the correct procedural manner or because a law enforcement witness was not adequately qualified to present the evidence. The mobile phone market moves fast, and new techniques and solutions are being developed all the time. Keeping up to date is a full-time job.

If you invest in specialist tools, be sure to invest in the operators of these tools as well – to ensure you get best value from your investment.

Conclusion

If you have understood the need to cover all four of these critical areas, your organization will be well on the way to leading the field in terms of best practices for mobile forensics.

The quality of decoding available in the tool, the security of the data recovered and the ability of the user to understand and explain these processes is just as important as data acquisition, when it comes to the bigger picture of getting your case to court.

For more information visit our website: https://www.msab.com.

About The Author

Mike Dickinson has spent half his working career in military/law enforcement and the other half in the private sector supporting these services. His specialism is providing tools and technologies designed to help in the fight against crime. Using his previous experience as a Senior Investigating Officer in the UK Police, Mike is dedicated to helping agencies make best use of their existing assets to improve the prevention and detection of crime; through the use of digital forensic technology.

by Chirath De Alwis and Chamalka De Silva

Recent advancements in technology have helped many people to have a better quality of life. Unmanned Aerial Vehicles (UAVs), also known as ‘drones’, are one such technological advancement that can help society to simplify day-to-day activities. These drones are now widely used in many industries such as agriculture, photography, transportation. But this same technology can also be used to conduct unethical activities.

Capturing privacy related content, illegal interception of other drones, and military use of drones in bombings are some common scenarios of unethical activities that can be done using drones. Investigating each scenario requires different approaches, as the availability of evidence can vary. Therefore, digital forensics investigators need to be able to examine drones in crime scene investigations. This article focuses on the technology behind drones and how drones can be useful in crime scene investigations. This helps investigators to simplify their digital forensics investigations when looking at drones.

Introduction

An unmanned aerial vehicle (UAV) (or un-crewed aerial vehicle, commonly known as a drone) is an aircraft without a human pilot on board and is a type of unmanned vehicle. UAVs are a component of an unmanned aircraft system (UAS), which includes a UAV, a ground-based controller, and a system of communications between the two. The flight of UAVs may operate with various degrees of autonomy: either under remote control by a human operator or autonomously by onboard computers.

Classification of UAVs

UAVs typically fall into one of six functional categories[1]:

• Target and decoy
  • providing ground and aerial gunnery of a target that simulates an enemy aircraft or missile
• Reconnaissance
  • providing battlefield intelligence
• Combat
  • providing attack capability for high-risk missions 
• Logistics
  • delivering cargo
• Research and development
  • improving UAV technologies
• Civil and commercial UAVs
  • agriculture, aerial photography, data collection

Technologies Used in UAVs

This section describes the latest technologies used in UAVs which will have a forensic value in crime scene investigations. UAVs have many other technologies, but these are the ones with the most forensic value.   

How Drones Work

Drones are made up of lightweight and durable materials, such as fiber and plastic. In order to operate a drone, users require an aircraft (also known as the drone), a controller unit, signal extenders, a battery, and a mobile device. The type of sensors and camera equipment can vary based on the type of drone and its purpose. 

A drone controller unit is required to connect to a mobile device that has an application which helps to view the path and navigate. Navigation can be controlled using the controller. The signal extender helps the user to extend the coverage of the drone signal, which helps it to fly for longer distances. Once the drone is ready for take-off, the user needs to power on the drone and connect to the controller using the mobile device. All the flight paths, camera view, battery status, and weather information are displayed in the mobile device attached to the controller. Modern drones have their own applications that are supported on both Android and iOS platforms. Flight records are stored inside the application, and users can upload the flight logs into the drone manufacturer’s cloud if required [2].  

Technology behind UAVs

Radar Positioning & Return Home

The latest drones have dual Global Navigation Satellite Systems (GNSS), such as GPS and GLONASS [3]. Modern drones can fly in both modes. DJI drones have called modes ‘P-Mode’ (this mode uses both GPS & GLONASS) and ‘ATTI mode’ (this mode does not use GPS & GLONASS, and the user can control the drone on their own). 

When the drone is first switched on, it searches and detects GNSS satellites, and saves the GPS coordinates as “Home Point”. High-end GNSS systems use Satellite Constellation technology [3]. Basically, a satellite constellation is a group of satellites working together to give coordinated coverage, and synchronized so that they overlap well in terms of coverage [3]. 

Most of the latest drones have three types of ‘Return to Home’ drone technology, as follows [3];

• Pilot-initiated return to home by pressing button on Remote Controller or in an app
• A low battery level, where the UAV will fly automatically back to the home point
• Loss of contact between the UAV and Remote Controller, with the UAV flying back automatically to its home point

Obstacle Detection and Collision Avoidance Technology

High-tech drones use four cameras and several sensors (the exact number depends on the type of drone) to detect obstacles in advance and avoid collisions. These sensors continuously scan their surroundings and alert the controller to avoid collisions. Some of the latest drones, such as Mavic Air, use this technology when using the ‘automatic return to home’ function. These systems fuse one or more of the following sensors to sense and avoid potential collisions[3]:

• vision sensors
• ultrasonic
• infrared
• lidar
• time of flight (ToF)
• monocular vision

No-Fly Zone Drone Technology

There are some high-security areas that have restricted flying drones (e.g. airport runways). These restrictions are put in place by governments and the Federal Aviation Authority (FAA) to restrict flying in these areas, promptin DJI and other manufacturers to introduce a “No-Fly Zone” feature [3]. Once the drone is flying, using GPS it automatically detects these restricted areas and stops the drone when it tries to enter these restricted areas. If a user tries to launch a drone inside a no-fly zone the drone motor will not operate, and user will not be able to fly within the restricted area.

DJI No Fly Zone in USA [4]

GPS ‘Ready To Fly’ Mode Drone Technology

When the compass is calibrated, it then seeks the location of the GPS satellites. When more than six are found, it allows the drone to fly in “Ready to Fly” Mode [3].

FPV Live Video Transmission Drone Technology

FPV means “First Person View”. A video camera is mounted on the unmanned aerial vehicle and this camera broadcasts the live video to the pilot on the ground [3].  

FPV Over 4G / LTE Networks

In 2016 a new live video option, which transmits over the 4G / LTE network and provides an unlimited range and low latency video, was announced [3]. This is the Sky Drone FPV 2 and comprises a camera module, a data module and a 4G / LTE modem [3].

Range Extender UAV Technology

This is used to extend the range of communication between the smartphone or tablet and the drone in an open, unobstructed area [3]. The transmission distance can reach up to 700 meters. Each range extender has a unique MAC address and network name (SSID) [3].

Drone Range Extender [5]

Operating Systems in Drone Technology

Most unmanned aircraft use Linux, and a few use Microsoft Windows. The Linux Foundation launched a project in 2014 called the Dronecode Project: an open source, collaborative project which brings together existing and future open source unmanned aerial vehicle projects under a nonprofit structure governed by The Linux Foundation [3]. 

Data available in UAVs

In commercial (non-military) drones, the primary available evidence would be GPS locations, media files and flight logs. The locations of these files and extraction is described in another article [6].

It is important to understand that the flight logs recorded in the inside of the drone are not accessible to the user by default. To access these flight log files stored in the drone, the user needs to open the app (DJI Assistant) inside the computer and click “flight data”. This will mount the memory inside the drone, which contains the flight logs in .DAT file format. The file name will look like this “FLY807.DAT”. This can also be viewed using the online tool Airdata.com [7]. 

How Can UAVs Support Digital Forensic Investigations?

There are many cases were drones can be used to commit crimes or become a part of a crime scene. Investigators should understand the scenario and analysis of the evidence should be done based on this. This section describes the most common scenarios, what information is available, and most importantly, how to start the investigation. 

Illegal/Unauthorized Data Capturing

Scenario:

The primary use of drones is capturing videos. Some users choose to capture illegal videos of unauthorized content; for example, people can use drones to take videos of what their neighbors are doing. People sometimes also try to get into unauthorized territories to capture footage. A great example of this are attempts to capture activities in Area 51 [8]. Sometimes people use drones for information-gathering and, in this case, rather than capturing the footage they can view it live. 

Potential Evidence:

Investigating crimes like these, the primary evidence would be images or videos captured by the drone. Analyzing these videos or images should depict what the controller has captured. If the controller did not capture the footage but watched the content in real time, we can analyze the flight logs and verify whether the drone was flying around the suspected area or not.  Since the flight logs contains flight maps, the controller cannot deny that the drone flew in the suspected area. 

Session Hijacking With Drones

Scenario:

The remote control unit is connected to the drone using a wireless communication medium; depending on the model of the drone, the technology can vary. In earlier stages, drones like Phantom 3 used their own Wi-Fi connections to connect to their controllers. Some of these communication mediums and technologies can have multiple vulnerabilities that allow attackers to interfere with the signals. Therefore, it is possible to conduct session hijacking and take the ownership, or full control, of the drone. Iran has recently taken down a US military drone [9], as a great example of this. Recently researchers have found a camera that can detect and take down drones [10]. These techniques are most commonly used in the military.

Hacking Drone [11]

Once a drone has been taken down or intercepted, the only evidence we will have to investigate are the flight logs recorded in the mobile device (from the controller). Analyzing these should help investigators to understand where the interception happened. When analyzing these flight log notifications, it should be possible to identify the interference and disconnection. If the drone was fully taken down or fully intercepted, then the “Find my drone” option should not detect the drone, because the controller cannot identify the drone from its GPS signals. 

Stolen Drones 

Scenario:

Sometimes drones can fall into a no man’s land due to a crash with an obstacle. In these cases, it is possible that someone might steal the drone. 

Potential Evidence:

This is a bit more straightforward than the previous scenarios. In this case, we can try to connect to the drone using GPS signals. The user can use the “Find my drone” option to navigate to the drone [12]. There are several cases reported in which users have identified their drones using this technique. When locating a drone using this option, if the drone appears to move, this could indicate that someone is taking the drone. 

Suicide Drones 

Scenario:

These drones can be used to crash aircrafts. Even though drones are flying at a limited speed, due to the high speed of commercial aircrafts, crashing a drone with a commercial aircraft can make a huge impact on the plane. Houthi rebels have claimed responsibility for a drone attack on the world’s largest oil processing facility in Saudi Arabia in the latest example of this [13].

Potential Evidence:

When a crash occurs, the potential evidence available is the crashed drone. Even though the drone has crashed, sometimes it is still possible to get the memory from the drone. But this is totally dependent on the impact to the drone. If the drone memory chip is available, investigators can analyze this and get the flight records from the drone memory, which will help in identifying where the drone’s journey started and its flight path up to the collision point. 

Drone Crash

Scenario:

A drone crash can happen in many ways. Internal technical failures and interaction with an obstacle are two common scenarios. The “Second MoD Airbus Zephyr” spy drone crash on an Aussie test flight in 9th Oct 2019 is a recent example [14]. 

Potential Evidence:

When a drone crashes, the potential evidence would be the drone memory or the flight log in the controller device. But most modern aircrafts can avoid obstacles, and this can be detected from the notifications. When the drone avoids an obstacle, it sends a notification to the controller device. The controller unit also receives notifications when a technical issue has occurred. This notification information is available in the flight logs. Analyzing these messages can show what caused the crash. 

Once a drone has crashed, the most important task is to identify the location of the drone. Depending on the wind speed, altitude, ground condition, and various other parameters, the crash point can vary. Recent research has been conducting into mathematically locating ocean-drowned aircraft [15]. This same formula can be modified to identify crash points for drones. The required information for this calculation can be found from the flight log located in the controller device.

UAV Anti-Forensics 

When criminals commit crimes they always try to hide their digital footprints to evade detection. Often criminals use anti-forensic techniques to mislead forensic investigators. As a forensic investigator, having an understanding of these helps us not to come to false conclusions during the investigation. This section covers some key anti-forensic techniques.

Altering Timestamps

Timestamp is a vital piece of evidence when conducting a forensic investigation on digital devices. Timestamp information helps to identify what has happened and when it happened. These timestamps also help in correlating events. Therefore, altering the timestamp is useful for criminals who want to mislead investigations. Recent research has revealed that it is possible to manipulate the timestamp of recorded media files by altering the system time in the Android OS before powering on the UAV [16]. Afterwards, all of the files created by the camera show the modified timestamp [16]. To investigate whether the timestamp has been tampered with or not, it is required to use the DJI vision app or look into the camera log. 

Blocking GPS Signals

Since GPS plays a crucial part when it comes to investigations, most attackers try to manipulate GPS data. Changing GPS data in media files does not limit the investigation of GPS records, though, since GPS data is available via the in-flight records as well. Therefore, the main possibility of manipulating GPS data is through restricting GPS signals. Recent research has attempted to disable the GPS module from drones [16], but the drones were unable to take off. In a follow-up piece of research, the researchers covered the top of the drone by attaching tin foil directly over the GPS receiver [16]. Since there was then no signal coming into the drone, the drone camera did not record any timestamps in the media files. The home point was also not recorded in the drone [16]. Since this helps to block the GPS signals, it also means that users can fly the drone in restricted areas without any issues. 

References

1. Medium. (2016). UAV Types, Classifications and Purposes. [online] Available at: https://medium.com/@UAVLance/uav-types-classifications-and-purposes-70651867194d [Accessed 6 Oct. 2019].
2. De Alwis, C. (2019). Crime Scene Investigation of GPS Data in Unmanned Aerial Vehicles (UAVs). [online] Forensic Focus – Articles. Available at: https://articles.forensicfocus.com/2019/10/03/crime-scene-investigation-of-gps-data-in-unmanned-aerial-vehicles-uavs/ [Accessed 8 Oct. 2019].
3. Corrigan, F. (2019). How Do Drones Work And What Is Drone Technology. [online] DroneZon. Available at: https://www.dronezon.com/learn-about-drones-quadcopters/what-is-drone-technology-or-how-does-drone-technology-work/ [Accessed 8 Oct. 2019].
4. DJI Official. (2019). DJI – The World Leader in Camera Drones/Quadcopters for Aerial Photography. [online] Available at: https://www.dji.com/flysafe/geo-map [Accessed 4 Oct. 2019].
5. Amazon.com. (2019). Ultimaxx Copper Parabolic Antenna Signal Range Booster for DJI Phantom 4, P4 pro, P4 Advanced, Phantom 3 Pro, Advanced and 4K Inspire 1 Controller. [online] Available at: https://www.amazon.com/Ultimaxx-Parabolic-Antenna-Advanced-Controller/dp/B0794GSQB7/ref=sr_1_11?keywords=drone+range+extender&qid=1571113640&sr=8-11 [Accessed 9 Oct. 2019].
6. De Alwis, C. (2019). Crime Scene Investigation of GPS Data in Unmanned Aerial Vehicles (UAVs). [online] Forensic Focus – Articles. Available at: https://articles.forensicfocus.com/2019/10/03/crime-scene-investigation-of-gps-data-in-unmanned-aerial-vehicles-uavs/ [Accessed 8 Oct. 2019].
7. Airdata.com. (2019). Drone Data Management and Flight Analysis | Airdata UAV. [online] Available at: https://airdata.com/ [Accessed 11 Oct. 2019].
8. Ronson, J. (2016). This Guy Sent a Drone to Spy on Area 51. [online] Inverse. Available at: https://www.inverse.com/article/12415-this-could-be-the-last-drone-footage-of-area-51-you-ll-ever-see [Accessed 4 Oct. 2019].
9. Berlinger, J. and Starr, B. (2019). Iran shoots down US drone aircraft. [online] CNN. Available at: https://edition.cnn.com/2019/06/20/middleeast/iran-drone-claim-hnk-intl/index.html [Accessed 6 Oct. 2019].
10. CNBC. (2017). This camera is built to detect and take down drones. [online] Available at: https://www.cnbc.com/video/2017/10/12/this-camera-is-built-to-detect-and-take-down-drones.html [Accessed 9 Oct. 2019].
11. Khandelwal, S. (2016). Hacker Hijacks a Police Drone from 2 Km Away with $40 Kit. [online] The Hacker News. Available at: https://thehackernews.com/2016/04/hacking-drone.html [Accessed 9 Oct. 2019].
12. F, F. (2019). How to use Find My Drone. [online] Forum.dji.com. Available at: https://forum.dji.com/thread-121403-1-1.html [Accessed 9 Oct. 2019].
13. the Guardian. (2019). Major Saudi Arabia oil facilities hit by Houthi drone strikes. [online] Available at: https://www.theguardian.com/world/2019/sep/14/major-saudi-arabia-oil-facilities-hit-by-drone-strikes [Accessed 11 Oct. 2019].
14. Corfield, G. (2019). Second MoD Airbus Zephyr spy drone crashes on Aussie test flight. [online] Theregister.co.uk. Available at: https://www.theregister.co.uk/2019/10/09/airbus_zephyr_drone_second_crash_australia/ [Accessed 11 Oct. 2019].
15. Sites.math.washington.edu. (2015). Lost and Found: Mathematically Locating Ocean Downed Aircraft. [online] Available at: https://sites.math.washington.edu/~morrow/mcm/mcm15/38724paper.pdf [Accessed 8 Oct. 2019].
16. Maarse, M. and van Ginkel, J. (2016). Digital forensics on a DJI Phantom 2 Vision+ UAV. [online] Os3.nl. Available at: https://www.os3.nl/_media/2015-2016/courses/ccf/ccf_mike_loek.pdf [Accessed 8 Oct. 2019].

About The Authors

Chirath De Alwis is an experienced information security professional with more than five years’ experience in the Information Security domain. He holds a BEng (Hons), a PGDip, and eight professional certifications in cyber security, and is also reading for his MSc specializing in Cyber Security. Currently, Chirath is involved in vulnerability management, threat intelligence, incident handling and digital forensics activities in Sri Lankan cyberspace. You can contact him on chirathdealwis@gmail.com.

Chamalka De Silva is an information security enthusiastic student currently studying for a BSc (Hons) Ethical Hacking and Network Security degree at Coventry University (UK). You can contact him on chamalkamds@gmail.com. 

Hello and welcome to this video about what’s new in XAMN 4.4.

I’m going to take you through ten new improvements, as you can see listed here in the latest release of the XAMN application. Let’s get straight on to the product so we keep this video as short as possible for you.

This is the latest version of XAMN 4.4. I’m working on a beta, so some features might change before the final release, but this should be a good indication of what’s coming up.

Let’s start with this file for an iPhone 6. And the first thing we’ve done is improved the loading functionality. You can see here there are twelve XRY files to be loaded, and you get feedback in relation to where the program is. Also it’s much faster to load.

The next thing I’d like to point out is that you can see on the left-hand side that we don’t have recently opened files anymore. We’ve improved this to allow for more screen space, so that you can see more of the extractions in this particular case, and have that information available. But if you do want to open another case, you just click on the ‘Open XRY Case’ or XRY file button in the top left, and you can see all the recently opened files there. So that’s a change in XAMN 4.4.

Also a new feature in the Start Case page here is quick views. So if we go into quick views, I can edit these directly in the start tab here – for example, if I wanted to add a classic mode, that’s one of my quick views on the right-hand side. Click ‘Classic mode,’ click ‘OK,’ and you’ll see it appears there. And conversely, if I untick it, it’ll disappear. So you can manage your quick views in XAMN 4.4 straight from the icon at the beginning of the application.

Let’s go to Pictures now and see one of the major improvements that we’ve added there. So we’ll go to Gallery view, so you can see all the pictures that we’ve got. Let’s click on this particular picture of a car that you can see here. I want to show you a new feature in relation to the picture viewer.

So if I open this in the XAMN Picture Viewer application… just drag that over onto the screen… you can get a much larger view of the picture in the application. But if I want to open another picture, I have to double-click on it. That will open a second dialogue box. And if I open a third picture… and so on and so forth; you get the idea. Essentially, you have to open each of the picture viewers for each gallery.

Now we’ve had a number of feedback to improve this process, so we’ve added a new ‘pin’ button here. So simply click the pin button, and now I can scroll through to the next picture simply by selecting it in the gallery view. It’s a much easier and quicker way to deal with images, so you can see them in a full view, if you want to. Great for a second monitor screen view, as well.

That’s the new picture view. To go back to the normal mode, unpin, and then you can see that I need to double-click that to open the next picture. A nice little improvement there in XAMN.

Let’s have a look at another feature we’ve added. We had some feedback in relation to examiners who had to look at indecent images. So we’ve made some changes in the Options menu, and we’ve included a new option: ‘Prevent animated gif files from being played automatically’, as you can see here. What I mean by that: let’s find a gif file to demonstrate.

So an improvement that we’ve made in XAMN previously is that gif files, if there, will preview and display automatically, as you can see this one’s moving. Now if it’s an indecent image, perhaps that’s not appropriate, so you’d like to prevent that from happening, quickly just go to the Options menu in the Detail panel; select ‘Prevent animated gif…’, click ‘OK’, close that down, go back to Pictures. Start again: if we search for that gif file again, now you can see that it’s no longer playing the animation, it just shows you the first frame.

It’s the same, extending that to Project VIC. So Project VIC, we’ve made some improvements in XAMN 4.4. Previously if you selected this button, you would have got a whole host of options. We’ve now moved that so that the Project VIC button just simply does a process review of the extraction, so you can see here we can filter on all artifacts, or just ‘Filtered.’ Select by view; I’ll do a quick check against our database. We can see no hits. OK, fine, let’s do that again. Let’s do it on all artifacts, see if we can get a match. And we’ve got thirteen hits in this particular view. So click ‘OK’, XAMN will update the data, and here are hits for Project VIC. And we can select those images if we want. Just to reassure you, this is a fake database, so if we open the picture viewer, these are just normal images that we’re testing in the system here.

And you can see that’s how the matches are displayed. So the images by default are prevented from being displayed. We won’t show them until you want to look at them in detail in the picture viewer.

If you want to change the settings for Project VIC, you can do that now in the Options menu. We have a new section for Project VIC here, where you can decide on the format that you want to use, depending on your region. And also, now you can add multiple databases, so more than one for each region. You can create a new one, or add them here in the Options menu.

OK, we can clear all the filters using the button here. Quick update for the Time filter: we’ve improved ‘Set custom time’. If I click on that filter it defaults to today’s date. It also means if you want to have a ‘from’ and ‘to’, obviously it starts from the current date. It’s much quicker and easier to get the filter in recent time.

Next big discussion point is chat view. So we have this chat thread here, with a discussion on the Kik app with a participant called Johnny Utah. You can see we can flick through that. Now historically the chat view was originally in XAMN Horizon; recently we’ve put it in XAMN Spotlight. And the great news is, in XAMN 4.4, we’re going to put this chat view into XAMN Viewer. What that means, quite simply, is that it’s now free to use for all XAMN users.

So XAMN Viewer now contains the chat view for free. And on top of that we’ve made some minor improvements as well. You can now see the exhibit ID, so you can see where the thread came from. This is from the Apple iPhone 5, which is number six in this case, number four; just to remind you, that’s the reference number we give to the particular exhibit. So that’s included now in chat view.

We’ve also added a new shortcut to PDF. So if this chat view is something that I want to report, I can very quickly click the ‘PDF Report’ button, it goes straight to a PDF and assumes that I want to print out this chat thread. I can click ‘Export’, and we’ll open that folder to see the results. Let’s drag it over here. And here you can see the PDF report with those chats – that’s the screenshot, very quickly printed out just as you see it there. So that’s a nice little touch for the XAMN chat view: a quick shortcut to PDF.

Don’t forget of course, though, if you want to do a more detailed report, select the ‘Report export’ option and you can go through all the artifacts and all the different file formats. So these are our twelve standard file format exports here. And you can choose between all artifacts, those filtered or those selected, as you can see here.

And another new feature to point out: if we go to PDF, perhaps if I wanted to do with pictures, we now number the pictures to make it easier to report. So let’s quickly go back to pictures in the gallery view. Let’s highlight this top row, and go to ‘Export.’ You can see it defaulted to ‘Selected (9 artifacts)’, and I want to do a PDF report of that. Click ‘Next’, and let’s go to ‘Pictures only view.’ We can put eight per page, or nine per page. We’ve selected nine artifacts, let’s put all nine on one page. Click ‘Next.’ And then we can open that up, and here you can see the PDF report that’s been created.

And there’s the original screenshot, and now you can see here we’ve numbered those individually selected nine images; those pictures that we’ve selected.

Great. One other feature I’d like to point out to you: very nice new implementation of screenshot. So now we can take a screenshot of what we’re looking at. Perhaps you’ve created a… let’s create a geographical map view, for a change. This is available in XAMN Horizon. So here’s a picture of several artifacts that have been created on this case. You can see that there’s some pictures there.

Let’s take a screenshot of that. So I can either drag an area – perhaps I just want the map for my report, and that creates a picture which can be saved – or alternatively I can just do a full screen, and then you can see I’ve got the whole screen there. And I can then save the file to a destination of my choice. That’s the new screenshot ability in XAMN 4.4. Great feature there.

Just one point in terms of tagging. You’ll probably be aware that… let’s remove that one… that we can add tags as a filter, and we can tag individual data. So let’s go to the view here. I can individually tag files, so I can mark these as important. And if I wanted to, I can edit the tags and give them all sorts of meanings.

We’ve included the option now to include tags in the export. So in the Extended XML export, the export schema now includes the tag marker information as well as all the other data, so you can be ingested into third-party analysis tools. There is a new extended XML schema available from the MSAB customer portal, detailing that for your third-party vendors.

Another nice little feature: if you wanted to save a subset of this for a third party to review, you can now click on the ‘Save subset’ options, and there’s a new feature here to include XAMN Viewer for free, as part of the package, so that the recipient can both receive the file and also have a reviewing tool to review the data in it.

Then we’ve made an improvement on call data records. If you’re not familiar with that, you’ll see that we have options here to import a binary file, or a UFED file from Cellebrite; but we can also import CDR – call data records.

If I click on that a wizard appears, and this will allow you to import the telephone records from network service providers to see if they match with the data that you’ve extracted from the handset. So we’re going to browse to a demo file, to show you, and then essentially you just follow the wizard. Click ‘Next’ and it will read the template, and it will say, OK, select the header row, which I’m going to do here. And it’s going to say OK, we think the data starts here, which is correct, so we’ll go ‘Next.’ And then select the end row: perhaps you just want a few of them, so we’re going to select the end row here; click ‘Next; and then it says OK, data formatting. How are we going to deal with it? And if you need to, you can expand this to get more on the screen, so you can see what we’re looking at here.

And then you basically tell XAMN what to do. Should it ignore this data, or should it treat it? And you can see here we’ve got various bits of information. What’s new in this release is that we can now import the call data tower name. So we can import the cell tower name; classify that; and perhaps we have first cell ID here, so we can import cell ID. So cell ID and cell tower name are two new categories that we can give to the data that we import, along with, you can see traditional ones here: latitude, longitude, perhaps also duration. And then you can mark the data and verify the format, as you see here. So that’s a great new feature in call data records: importing.

And last but not least, I’d like to show you a new feature with health data. I’m going to close this file down and open a new case with health data in the app. And you can see the improved feedback on file times and the faster opening times. Let’s open the health data here – so I’m just going to move this up. And here we’ve got some health data from Apple Health app. There’s various files along the way, and you can now view the heartbeat monitors in the feedback: here’s an example.

We’ve added a new feature so you can export this. A customer requested export as a csv file, so here we’ve got a heartbeat chart that we’d like to export. Click on the ‘Export as a CSV file’ shortcut and create a test file – call that ‘test2’. And I want to open that file… and we called that ‘test2’. And here’s all the data in the spreadsheet we just exported it to.

Quite simply you would select all the data – and if you’re a wizard in Excel you’ll know how to do this – and then you can insert a chart. Let’s insert a chart view. And there you can see the heartbeat data visually represented in Excel. Hopefully that looks vaguely like something that you saw in relation to this data format.

OK. So that’s a summary of all the recent new improvements that have been made in XAMN 4.4. Thank you for watching, and if you’d like any more information, please visit our website, www.msab.com.

by Alex Moeller

As the costs associated with running a mobile devices forensic laboratory can be considered to be high, this article is aimed at providing alternative options for small organisations or individuals looking to reduce overheads. 

Case Management Tools

There are numerous case management systems available online which are free to download, and premium features offered by some of the paid software are not worth losing coin over at the small business stage.

These case management systems, however, are a double-edged sword. Although many have built-in data loss mitigation features such as real-time backup, the feature requires a constant internet connection. This can open up your system to possible attacks and manipulation of case information.

Although lacking in features compared to the online programs, Microsoft Excel [1] is a viable option which can be used to design a functional case management system with little skill. The added bonus of services such as Air Tables [2] is that you can download premade templates into Excel, skipping all the messing around with fonts and table making. 

Mobile Forensic Tools

Now, this is the big saver part, and as most of us probably know, any decent software used in digital forensics is expensive. So how do you break up costs?

Building a PC that can handle Cellebrite [3] or XRY [4] will cost you around £500.00 if you’re smart, and while an expensive graphics card is not required, a decent amount of RAM and processing speed is.

Write blockers aren’t required unless you wish to perform SD card extractions. The usage of SD cards by mobile phones has generally decreased as a result of their more substantial internal storage capabilities. If you are required to examine an SD card then NIST [5] provides free validation test reports on multiple software write blockers, thus ensuring the most suitable tool is used for the work. 

SIM card readers themselves don’t cost a lot and can be purchased on Amazon for around £10.00. 

Extraction

Mobile phone extraction software can seem expensive, but it doesn’t have to be. The main difference between the more expensive ones versus the cheaper ones is ease of use. Tools like Cellebrite and XRY are great at combining lots of different mobile extraction methods into a streamlined and efficient solution. The less expensive tools require slightly more training and time spent becoming familiar with the steps involved, but practice makes perfect. Starting with the simple task of being able to extract only images or texts until your requirements outgrow the tool, at which point the more expensive software becomes the more viable tool.

Adb [6]–[8] is an option for Android devices, but you run the risk of breaking the phone if you don’t learn the correct commands.

Autopsy [9] is an option that should be considered as it is capable of extracting text messages (SMS / MMS), call logs, contacts, and GPS data. The downside to these types of software is that they have limited coverage as each device can have a different OS version. The aforementioned software will therefore only work on specific mobile devices.

A document entitled “Open Source Mobile Device Forensics” authored by Heather Mahalik in 2014 provides further options to consider when looking at open source solutions [10].

Analysis

As with the extraction stage, cheaper options are available for the analysis of data. The presentation of extracted data for analysis is crucial as there is a vast amount of data available to an examiner and it needs to be presented in a logical fashion. 

In most mobile phone extractions, however, large amounts of data are recovered, and so subsequently require a more professional touch. This can be achieved by using a software which inputs the raw data extracted from the phone and outputs it in graphical displays. 

Autopsy[11] has a GUI interface which comes with features like Timeline Analysis, Hash Filtering, File System Analysis and Keyword Searching out of the box, and has the ability to add other modules for extended functionality. 

Services like Splunk [12] offer a great way to transform messy looking data sets into clear and understandable models and tables. 

Validation

Validation of tools and methods is a massive, exhaustive process which never seems to end. 

But keep calm and keep validating. 

To ensure reproducibility and repeatability a laboratory must be able to validate results by demonstrating the reliability of the tools used to ascertain those results. For example, if instructed to locate a specific image stored on a mobile device, an examiner should be able to extract an image and confirm the hash checksum. A useful tool to accomplish this task is Jacksum [10], which is free open-source software that calculates a variety of hash checksums and can be incorporated into Microsoft Windows and accessed by simply right-clicking on a file. Another great tool for image analysis is Image Magick [11], which is also free and can provide detailed analysis of specific aspects of an image.

Validation needs to be tackled in an efficient manner with an appropriate strategy that meets your end-user requirements. Mobile phone validation can seem like a daunting task at first, but breaking it down into smaller parts will make it easier. First validating the fundamental features which exist on every make and model of phone such as contacts, SMS messages and call logs can set you on the right path, and the scope can be increased later on.

Validating every phone you encounter would be ridiculous. It would literally never end as new models are hitting the market quicker than we are able to validate. Instead, initially focus on a specific type of phone, or do a Google search for the most commonly purchased phones and pick a nice selection which represents a sample of the market. Commonly used phones can be expensive, so look for second-hand ones and perform a factory reset. Before conducting any tests perform an extraction of the phone and make note of any remaining data so it can be ignored in tests.

Buying new phones should be avoided not only to reduce costs, but also because second-hand devices have the advantage of being more closely aligned with the types of devices used in casework.

Documents published by NIST [13], [14] provide validation results [15] for you to set acceptable pass criteria for your own testing. The FSR [16] has also published guidance regarding validation, as has the Scientific Working Group on Digital Forensics [16] [17]. Combining these documents can help provide a solid overview when creating validation plans.

Digital Storage

Digital storage goes hand in hand with a good case management system. It’s crucial that exhibits for a specific case are kept as one and are not lost, and this can be achieved by keeping your case management system in sync with exhibit logs. Exhibit logs should state where an exhibit is being kept and if it has been returned to the instructing party.

The security of physical exhibits is as vital as the safety of any digital exhibits and should be made a priority. Depending on your work environment you will need a safe, stored within an area of restricted access. Ensuring only workstations with no internet capabilities have access to case data, and using only encrypted USB flash drives, will ensure safety from most outside dangers. 

A NAS system can be of great use but can cost a lot, so again, either look for cheaper alternatives like simply swapping out hard drives, or browse eBay until the right one comes up for a reasonable price. 

If that’s too expensive you can build your own, but consider that whatever route you take will require validation testing. Security is yet another key aspect to consider when using a NAS, as you can never be too careful in digital forensics. Most extracted data have the potential to contain viruses or malware which could compromise confidential files. The best way to ensure the safety of these files is to keep the NAS separated from the internet completely, but if you do need to connect to the NAS remotely an article by How-to Geek describes the necessary steps to keep it safe [19].

Report Writing

Reporting the results of a case needs to be completed with no grammatical errors and should be accessible to the reader. One way of ensuring this is by using software that picks up any grammatical errors found in reports, thus preventing any misunderstandings. Software like Grammarly [20] is free to use and offers a premium option for more advanced grammatical errors that perhaps Microsoft Word might not pick up. However, this and similar software require an internet connection to function, leaving you again open to any online attacks. With that being said, a few ways around this are available.

The first option would be to set up a low specification workstation for running internet searches and to operate Word with Grammarly installed. The finished report can then be put onto an encrypted memory stick, thus minimising the risk.

A safer option would be to make some tweaks to the spellcheck available within Word [21] and create your own dictionary of keywords and phrases you wish Word not to pick up on.

Peer Review

Peer reviewing of each other’s work is obviously a free thing to do if you work with someone else with a similar skill set, but if you work alone then you must make some friends who work in your area of expertise. Peer review is essential in ensuring reliability and error mitigation and is advised to ensure compliance with the FSR Codes of Practice [22].

When peer reviewing work, don’t waste time and money (and trees) printing out forms. Try using the comment feature in Word for areas that need addressing. This could also be a good way of recording improvement actions to show how your company finds errors and makes improvements. 

Delivery

Sending confidential documents online can be a risky game, so procedures should be put in place to mitigate against said risks. Tresorit [23] and Sophos [24] provide end-to-end encrypted file-sharing services and each offer free trials which should be taken full advantage of before making a decision on which to commit.

Transporting important case data via an external device requires security while in transit. This can be achieved by using strong encryption with software such as VeraCrypt [25], a free tool for encrypting hard drives and USB flash drives. 

Conclusion

It’s currently a difficult time for smaller laboratories to compete against larger ones, due to the stress of ISO 17025 accreditation looming over us all every second of our already stressful day-to-day lives. The chance to cut costs should be seized at every opportunity, to save money for those accreditation visits and rainy days. Not everything has to be state-of-the-art, cutting-edge tech. If you learn the necessary skills and are prepared to accept fewer flashy features, then try some of these alternative methods instead of forking out cash at every turn. I want my final words in this article to be positive and push for more cooperation between smaller digital forensic laboratories, as I believe that this will not only benefit everyone in setting a higher standard, but will also significantly improve our justice system. 

References

[1] Microsoft, ‘Microsoft Excel’. [Online]. Available: https://products.office.com/en-gb/excel. [Accessed: 13-Aug-2019].

[2] Air Tables, ‘Air Tables’. [Online]. Available: https://airtable.com/templates. [Accessed: 13-Aug-2019].

[3] Cellebrite, ‘Cellebrite’. [Online]. Available: https://www.cellebrite.com/en/home/. [Accessed: 15-Aug-2019].

[4] MSAB, ‘MSAB’. [Online]. Available: https://www.msab.com/. [Accessed: 15-Aug-2019].

[5] NIST, ‘DHS Reports — Test Results Software Write Block’. [Online]. Available: https://www.nist.gov/itl/ssd/software-quality-group/computer-forensics-tool-testing-program-cftt/cftt-technical/software. [Accessed: 17-Oct-2019].

[6] Android, ‘Android Debug Bridge (adb)’. [Online]. Available: https://developer.android.com/studio/command-line/adb#copyfiles. [Accessed: 15-Aug-2019].

[7] Chris Hoffman, ‘How to Install and Use ADB, the Android Debug Bridge Utility’. [Online]. Available: https://www.howtogeek.com/125769/how-to-install-and-use-abd-the-android-debug-bridge-utility/. [Accessed: 16-Aug-2019].

[8] Doug Lynch, ‘How to Install ADB on Windows, macOS, and Linux’. .

[9] Autopsy, ‘Autopsy’. [Online]. Available: https://www.autopsy.com/. [Accessed: 15-Aug-2019].

[10] Heather Mahalik, ‘Open Source Mobile Device Forensics’, 2014.

[11] Autopsy, ‘Sleuth Kit’. [Online]. Available: https://www.sleuthkit.org/autopsy/. [Accessed: 29-Sep-2019].

[12] Michael Baum, Rob Das, Erik Swan, ‘Splunk’. [Online]. Available: https://www.splunk.com/. [Accessed: 18-Aug-2019].

[13] NIST, ‘NIST (CFTT)’. [Online]. Available: https://www.nist.gov/itl/ssd/software-quality-group/computer-forensics-tool-testing-program-cftt/cftt-technical/mobile. [Accessed: 20-Sep-2019].

[14] NIST, ‘Mobile Device Data Population Setup Guide’. [Online]. Available: https://www.nist.gov/sites/default/files/documents/2017/05/09/mobile_device_data_population_setup_guide.pdf. [Accessed: 15-Sep-2019].

[15] NIST, ‘Test Results for Mobile Device Acquisition Tool Cellebrite’.

[16] FSR, ‘Validation Guidance’. FSR, 2014.

[17] SWGDE, ‘SWGDE Minimum Requirements for Testing Tools used in Digital and Multimedia Forensics’. 2018.

[18] SWGDE, ‘SWGDE Recommended Guidelines for Validation Testing’. 2014.

[19] Craig Lloyd, ‘6 Things You Should Do to Secure Your NAS’. [Online]. Available: https://www.howtogeek.com/350919/6-things-you-should-do-to-secure-your-nas/. [Accessed: 17-Aug-2019].

[20] Grammarly, ‘Grammarly’. [Online]. Available: https://www.grammarly.com. [Accessed: 17-Aug-2019].

[21] Microsoft, ‘Word’. [Online]. Available: https://products.office.com/en-us/word. [Accessed: 13-Aug-2019].

[22] FSR, ‘FSR Codes of Practice and Conduct’. 2017.

[23] Tresorit, ‘Tresorit’. [Online]. Available: https://tresorit.com/. [Accessed: 19-Sep-2019].

[24] Sophos, ‘Sophos’. [Online]. Available: https://www.sophos.com/en-us.aspx. [Accessed: 19-Sep-2019].

[25] Veracrypt, ‘Veracrypt’. [Online]. Available: https://archive.codeplex.com/?p=veracrypt. [Accessed: 05-Sep-2019].

About the Author

Alex Moeller is a Mobile Phone Forensics Examiner at Verden Forensics in Birmingham, UK, and has experience in conducting examinations in a variety of cases, both criminal and civil. He holds a degree in Forensic Computing from Birmingham City University and is currently preparing the laboratory for ISO 17025 accreditation in Mobile Device Forensics. 

by Patrick Siewert, Principal Consultant, Pro Digital Forensic Consulting

Since introducing our private sector clients to the impact that cellular call detail records (CDR) analysis & mapping can have on their cases, we’ve had a lot of robust discussions with litigators and clients about the veracity and value of this evidence.  CDR analysis has been used for decades in law enforcement to help prove or disprove the approximate location of criminal defendants in major crimes.  Only in the past several years have civil litigators and insurance companies also been introduced to the value that this evidence can have on their cases and/or claims investigations.  In the time we’ve been conducting CDR analysis, we’ve worked on varying types of cases from criminal prosecution for smaller prosecutors’ offices to domestic litigation to help prove/disprove cohabitation to high-dollar insurance claims to help determine if the claim and associated statements made under oath are verifiable with regard to location.  This specialty offshoot of digital forensics requires constant knowledge updating with regard to carrier practices and specialized training and tools to be able to perform these analyses effectively.

However, mainly among the Criminal Defense Bar, the notion has been put forth that CDR analysis may be “junk science” and therefore potentially unreliable as evidence in legal proceedings.  One high-profile case in which CDR analysis was used to obtain a conviction was the case of State v. Adnan Syed, chronicled in the Serial Podcast.  However, as we’ve seen more recent developments in that case unfold, the “junk science” claim doesn’t necessarily lie with the practice, rather with the potential practitioner.  Indeed, even in computer forensics, certain vendors of forensic tools like to claim their tool has been “validated in court”, when in reality it is the examiner and their competence that needs to be validated in court.  The tool (or in this case, the cellular records) is/are just a dataset that needs to be analyzed competently to be introduced as evidence in a legal proceeding.

Toward the end of establishing that CDR analysis is not “junk science”, here are three salient points that will help debunk the myth that these records and their associated analysis are not worthy of evidentiary status.

Reason #1: Cellular Records Are “Pure” Evidence

What do we mean by “pure” evidence?  Consider for a moment other types of digital evidence that are analyzed for use in court, such as the cell phone itself or a computer system.  These items are generally affected by the user to a great degree and therefore can be open to some scrutiny about the weight and value they hold.  Cellular Records are only available via court order or search warrant to the cellular provider.  A Verizon Wireless customer cannot call customer support and ask for their cellular call detail records with historical cell site data.  The provider will not provide this data this absent legal process.  This means the user has very limited (if any) ability to manipulate the data, which makes the evidence about as pure as it gets.

Furthermore, the record-keeper has no vested interest in altering the evidence.  In fact, they have every reason to maintain better, more accurate records!  It is a fact within the cellular industry that CDRs were never meant to be used as evidence in legal proceedings.  CDRs are kept by cellular providers so they can log and analyze their own networks for efficiency and to increase overall customer experience on the network.  Simply put, the records are kept for customer service purposes and cellular companies don’t make money by having poor customer service.  It is a fortunate byproduct that these records may be obtained via legal process and analyzed for potential use in legal proceedings.  This is why cellular providers don’t maintain these records indefinitely, as detailed in our 2017 article Cellular Provider Record Retention Periods.

Name another type of digital evidence that the user never touches and to which they generally don’t have access!

Reason #2: Automated Tools Have Greatly Decreased The Human Error Factor

Back in 2001 when the incident detailed in season 1 of the Serial Podcast occurred there were few, if any, automated tools with which to conduct CDR analysis.  In modern casework, we have many options for automated tools analysis, including CellHawk, ZetX, CASTviz, Map Link and Pen Link, as well as some others.  Use of automated tools can save time and greatly reduce error, but they come with a few warnings:

• Not all tools are created equally. If you’re using a tool that is free [to law enforcement], you’re generally getting what you pay for.
• Don’t rely on the tool to do all of the work. Automated tools are great, but they cannot tell you if someone likely shut their phone off or sent a call to voicemail or left their phone in one location while committing an offense somewhere else.  Only manual analysis of the data and the behavior of the user can help verify these conclusions.
• VALIDATE! If an automated tool is telling you something, make sure to always refer back to the original record for validation.  If an automated tool is citing a GPS coordinate for location, make sure you validate that there is actually a cell site at that location.

Reason #3: Trained, Experienced Analysts Don’t Deal in “Junk Science”

One of the traps digital forensic examiners of all ilks are susceptible to is the drawing of conclusions not based on fact.  While it’s true that a trained, experienced professional may reach conclusions based upon device activity, those same conclusions have to be rooted in some facts at some point.  The trap that sometimes rears its ugly head is when we reach conclusions that are either outside of our expertise or are not supported by the data.

There are several traps documented in litigation over the course of the life of CDR analysis in legal proceedings that have led to the claim of “junk science”.  Probably the biggest of these (and the one cited in the article linked above and again here) are conclusions about cell site range.  As analysts, we are not cellular engineers and we cannot be engaged in speculation or discussion about the “range” of a particular cell site.  This is why in most cases we approximate location of the target device in the investigation and do not get entwined in discussions about cell site range.  Even if we were fortunate enough to have propagation maps from the cellular provider which detail the effective/optimal range of a cell site, we still won’t draw conclusions about range.  It is not within the expertise of most analysts to discuss range.  That is for a cellular engineer to conclude, not an analyst of cellular records.

There are behaviors and activity that the records can tell us about, however.  A trained analyst can usually tell of the phone was off, or if a call was sent straight to voicemail, or if the phone was left in one location for a prolonged period.

At the heart of the records is user behavior.  Is there a pattern of behavior that is not adhered to during the time of the alleged incident?  Is there link analysis that can be done to confirm likely associates or accomplices?  If there are alleged accomplices, does normal text or call activity cease with these persons during the time frame of the incident?

All of these items and more can help lead a trained, experienced analyst to conclusions with a reasonable degree of certainty, but with most of these items, we require a larger dataset to compare the behavior at the time of an incident with behavior at other times.  An analyst cannot identify these behaviors with 24 or 48 hours’ worth of records.  This is not enough data from which to draw conclusions about behavior.  This is also why we highly advise obtaining at least 30 days of records on either end of the incident, preferably more.  More data is better when it comes to CDR analysis.

The ultimate test of whether or not the conclusions based upon trained, experienced analysis of the records is “junk science” lies with the competencies of the analyst.  One who draws conclusions not based on facts is what leads to an otherwise valid form of data analysis to be dubbed “junk science”.

Wrapping It Up

In any forensic discipline, there is the possibility for human error or oversight. We’re not infallible, after all, and we can’t be expected to be perfect all the time. But CDR analysis is the only one in which the term “junk science” has been bandied about quite a bit. Deeper inspection of the issues involved in each case where this claim has been made can provide lessons for current and future analysts to read and take heed. It’s when our conclusions span beyond the breadth of our expertise and what the data tells us that we get into trouble. Ultimately, everyone wants to see justice done. If we can use CDR analysis successfully in litigation without reaching past our ability into conclusions that are open to extreme scrutiny, justice will be served.

About Patrick Siewert

Patrick Siewert is the Principal Consultant of Pro Digital Forensic Consulting (www.ProDigital4n6.com), based in Richmond, Virginia.  In 15 years of law enforcement, he investigated hundreds of high-tech crimes, incorporating digital forensics into the investigations, and was responsible for investigating some of the highest jury and plea bargain child exploitation investigations in Virginia court history.  Patrick is a graduate of SCERS, BCERT, the Reid School of Interview & Interrogation and multiple online investigation schools (among others). He continues to hone his digital forensic expertise in the private sector while growing his consulting & investigation business marketed toward litigators, professional investigators and corporations, while keeping in touch with the public safety community as a Law Enforcement Instructor.