IMPLICATIONS OF MOBILE DEVICE MANAGEMENT FOR DIGITAL FORENSIC
INVESTIGATIONS
Adam Jenkins
School of Science
Edith Cowan University, Perth, Western Australia
ajenkin6@our.ecu.edu.au
Abstract
Mobile Device Management software is designed to protect data on mobile devices. Apple and Samsung mobile
phones were examined using a commercial digital forensic application to understand the operation and
characteristics of MDM applications on these devices and consider the technical and legal implications.
Keywords
Smartphone, Android, iOS, Samsung, Apple, Mobile Device Management, security, legislation, digital forensics
INTRODUCTION
Ownership of smartphones worldwide has reached a point where it is inevitable that analysis of smartphone data
will be part of any corporate, law enforcement or national security investigation. The number of mobile phone
users worldwide reached 4.43 billion in 2015.
Threats to data confidentiality, integrity and availability arise from the use of mobile devices which may be lost
or stolen, or expose multiple vectors through which sensitive data can be stolen or an insecure channel into the
employer’s network can be accessed.
Organizations require solutions to mitigate the risks and secure corporate data and networks. The need for such
solutions led to the development of Mobile Device Management platforms.
MDMs work by using manufacturer’s features built in to mobile operating systems and provide a management
interface and tools to securely enroll mobile devices to business environments, configure settings, deploy corporate
content and apps, and lock or wipe devices remotely.
The MDM global market has been forecast to grow from USD 1.69 billion in 2016 to USD 5.32 billion in 2021
(“Mobile Device Management Market - Global Forecast to 2021,” n.d.)
MDM RISKS TO FORENSIC DATA EXTRACTION
MDM platforms have multiple functions as outlined above but three functions are of greatest significance to
mobile forensics; the protection of data at rest (data stored on the device), prevention of mobile device backup to
other systems, and remote locking and wiping of devices. These functions are encapsulated in the description of
the section of the Australian Signals Directorates iOS Hardening Guide (“iOS9_Hardening_Guide.pdf,” 2016)
dealing with encryption - “Keeping data safe when the device is out of your control”.
Forensic tools in many cases leverage the device manufacturer’s APIs for backup or data transfer, in order to
perform extractions. Some MDM platforms allow these features to be disabled.
The security features of MDM platforms are designed to secure employer data from unauthorized persons or
organizations. A comparison of 15 MDM platforms by Gartner Group reveal that all products surveyed offered
the ability to remotely lock or wipe (completely or selectively) enrolled devices (“MDM-Compare.pdf,” 2015),
with consequent implications for forensic examination of that data.
FORENSIC METHOD
Forensic best practice must always be followed when examining mobile devices. This includes fundamental
procedures such as maintaining the chain of custody of the physical and electronic evidence, taking steps to
prevent loss of data after device seizure, minimizing interaction with the data and verification and validation of
results.
Devices enrolled in MDM are vulnerable to being wiped remotely by commands issued by administrators. If
forensic best practice is followed, this will be prevented by isolating the device from WiFi and cellular networks
as soon as they are seized.
Minimum interaction with data dictates that devices be processed as normal as a first step.
TYPES OF MOBILE DEVICE MANAGEMENT MODEL
For the purposes of review, MDMs can be grouped by the security model they employ.
Kanonov and Wool identify five basic technologies (Kanonov & Wool, 2016). A review of these reveals that
many commercial platforms incorporate aspects of more than one model into their products.
Policy based
Policy based Mobile Device management functions by pushing policies to the device when it first connects to
the corporate network, a process known as enrollment. Enrollment may be performed physically or over-the-air
by email, message or by directing the device to a portal. Access to the corporate network is denied until the
device is enrolled and has received and implemented the policies set by the MDM administrator. This is
achieved by the MDM software interacting with the manufacturers APIs built in to the mobile device operating
system. Policy based Mobile Device Management allows very granular control over how devices behave by the
implementation of interlocking sets of rules which make up a policy. The manufacturers attempt to cater for as
wide a variety of desired behaviors by implementing policies for all aspects of device behavior to achieve
broader market penetration.
Remote Mobile Virtualization based
In this model, the corporate data is not stored on the device but remains on the corporate server in a virtualized
computing environment to which the mobile device connects. This encompasses both virtualization of the entire
operating system (Virtual Mobile Infrastructure) and of only individual apps and user sessions. More powerful
mobile processors and high bandwidth connections have made this model practicable. VMI is now recommended
by The U.S. National Institute of Standards and Technology (Souppaya & Scarfone, 2016). For example, VMI
vendor Sierraware offers manufacturers VMI firmware development, including Sierra Trusted Execution
Environment for ARM Trust Zone, and Sierra VMI, hosting of Android instances in a datacenter or cloud, which
is claimed to support cross-platform apps, monitoring and backup-and-restore all of which happens off-device
(“Sierra VMI datasheet Final.pdf,” n.d.).
Root based
A root-based security enforcement mechanism, DeepDroid, has been proposed (Wang, Sun, Wang, & Jing,
2015) which addresses what the authors identify as deficiencies within the Android security model. They state
that the “all-or-nothing” approach to app permissions on Android and the fact that security provisions such as
Mandatory Access Control and Device Administration APIs are unevenly implemented across Android versions
dictates against effective security provisions. They identify the system_server process within System Services
(which controls all app permissions) and the binder mechanism within the Android kernel (which interprets
interprocess procedure calls) as fundamental to all versions of Android and propose a service with root access to
hook the Android app runtime environment and apply fine-grained security controls using these resources. This
model relies on enterprise policy rules set by administrators and also context-aware access control by monitoring
communications between apps and services. No commercial MDM platforms appear to be using this model at
the time of writing.
Secure Container
Device owners are administrators on their own devices and can unintentionally or deliberately compromise data
security by installation of malicious apps or insecure data handling practices. A secure container is a separate
enclave on the device of which the employers IT department is the administrator and can control security of data
stored in that enclave. With the release of Android 5.0, the “multiple user” feature was added to Android. This is
the solution relied upon by Google’s “Android for Work” which creates separate “users” for the personal and
work environments. This allows segregation of the environments but does not prevent data sharing between
them. Restrictions on copying data between work and personal environments may also be implemented.
Hardware Backed
Implementing a Trusted Execution Environment in hardware has become possible with the development of the
ARM Trust Zone. ARM Holdings is a company that owns the intellectual property in the ARM family of
microprocessors. ARM does not manufacture physical components but licenses its intellectual property, designs
and development tools to chip fabricators. ARM’s designs are integrated into physical System-on-Chip products
by manufacturers such as Samsung, Apple, and Mediatek.
TrustZone is ARM’s marketing term for a set of security extensions enabled in ARMv6 and later processor
designs. It allows a security core to be added to a SoC at low cost by providing two virtual processors on the
same hardware, referred to as the “normal world” and the “secure world”. Each world has dedicated memory and
cache resources. The secure world can access its own resources and those of the normal world, but the reverse is
not true. Samsung KNOX is a hardware based secure container environment relying on the ARM Trust Zone.
Summary
The most widely deployed MDM platforms predominantly use policies and/or secure containers. Samsung
Knox, Android for Work and IBM Maas 360 lean towards containerization. VM Airwatch and MobileIron rely
on policies and apps customized by developers to support the MDM data security features (Pascucci, 2015b).
APPLICABLE LEGISLATION – WESTERN AUSTRALIA
Under West Australian law, provisions exist to assist law enforcement to gain access to data in the course of an
investigation. “Obtaining Business Records” and “Gaining Access to Data Controlled by Subjects” fall under
Parts 6 & 7 of the Criminal Investigation Act 2006. Under Section 59 of the Act, police and public officers may
apply for Data Access Orders to be issued by magistrates. The maximum penalty for failing to comply with a
Data Access Order is up to 5 years imprisonment or a fine of $24 000 and up to 2 years imprisonment. The
statute details the requirements of an application for a Data Access Order.
Similarly, under Part 6 of the Act, police and public officers may apply to a Justice of the Peace for an Order to
Produce a Business Record. The Act provides for a fine of $12 000 and up to 12 months imprisonment for
failing to comply with an Order to Produce.
These orders cover most common situations in which a public officer is seeking to compel a person to provide
access to data. The situation becomes more problematic when a MDM platform is involved, because of the
involvement of the MDM administrator.
An application for a Data Access order must “(g) state the name of the person to whom the order wanted will
apply (the target person); and (h) state the grounds on which the applicant suspects that the target person has
committed the serious offence” Hypothetically, a person who has committed a serious offence and whose mobile
device law enforcement are seeking to access may not have the means to provide access i.e. where the data on
that device is secured by a Mobile Device Management platform controlled by another person.
Under these circumstances, an Order to Produce might normally be more appropriate; if the MDM is controlled
by an employer or government department, it is reasonable to consider data “business records”, defined as “a
record prepared or used in the ordinary course of a business for the purpose of recording any matter relating to
the business” (“Criminal Investigation Act 2006,” n.d.) and “business” is defined as “any business, including a
business of a governmental body or instrumentality or of a local government, or any occupation, trade or calling”
(“Criminal Investigation Act 2006,” n.d.).
A case in which one member of a criminal organization, or a co-offender, controls an MDM solution on behalf
of the others is one that has not yet been tested under West Australian law. If the owner of a device does not
have the means to provide access to data on that device, a Data Access order may not be appropriate. It is unclear
whether an organized crime group, or a group of co-conspirators, could be legally considered a business and thus
whether data under the control of the group could be considered “business records”. Challenges to an Order to
Produce might therefore be mounted.
IMPLICATIONS OF MDM FOR FORENSIC EXAMINATION - USE CASES
A typical use case would be where an MDM solution is deployed by an organization and an employee of that
organization is under internal investigation. The organization would benefit by the presence of the MDM as they
can exert control over the user’s device to extract the data from it to support the investigation. The organization
may also have access to other data sources, such as device backups, user activity logs and billing records. The
organization should have in place policies and employee agreements that assert the rights of the organization to
take these actions, to prevent legal challenges to the process.
In a situation where an MDM solution is deployed by an organization and an employee of that organization is
under investigation by a law enforcement agency, similar conditions to those above exist if the organization is
co-operating with law enforcement. It is reasonable to expect such co-operation, both as a good corporate citizen,
but also to protect themselves from reputational damage. Even when organizations are inclined to be cooperative, they may require a legal instrument such as a search warrant or Order to Produce to be served, in order
to establish the legality of the procedure and protect the organization from liability.
In a situation where an individual or group under investigation by a law enforcement agency has deployed a
small scale MDM solution, co-operation is unlikely to be forthcoming and as detailed above, the situation
regarding court orders is unclear.
EXAMPLE - SAN BERNARDINO
An example of an investigation involving mobile device data and a subject of much debate in the forensic and
security communities was the matter of Syed Farook, a health inspector in the San Bernardino Department of
Public Health. On December 2, 2015, Farook and his wife Tashfeen Malik killed 14 people and injured 22 in a
shooting incident at Farook’s workplace. Farook and Malik were subsequently killed in an exchange of gunfire
with police. The FBI launched an investigation treating it as a domestic terrorism incident. FBI forensic
investigators were unsuccessful in gaining access to Farook’s employer-issued Apple iPhone 5c and sought to
use legal means to compel Apple to engineer a solution to give access to the device. At the time, it was not
widely reported that San Bernardino County had partially deployed an MDM platform to manage its mobile
devices.
Some reports state that the implementation of the MobileIron platform at the San Bernardino County Department
of Health was incomplete and only the component that allowed access to corporate email had been implemented
(Purdy, 2016) and others that while some departments were testing MobileIron, Farook’s department had “opted
not to participate in the test” (Heath, 2016). This last statement was attributed to county spokesman David Wert.
Wert was also quoted as saying that MobileIron can be evaded by an employee deleting an app and a profile
from the mobile device. In fact, Apple’s security solution is more robust than this opinion would indicate; from
the iOS Security white paper, “configuration profiles can also be locked to a device to completely prevent their
removal, or to allow removal only with a passcode.” (“iOS 10 Security Guide.pdf,” 2017)
Whatever the case, it is clear that Farook’s device was not enrolled in the MDM. MobileIron Chief Marketing
and Strategy Officer Ojas Rege stated on the company blog, “If the phone had been using MobileIron, the
County IT department could have … [sent] a command to the device to clear the passcode.” (Rege, 2016).
EXAMPLE – PHANTOM SECURE BLACKBERRYS
Phantom Secure is a Canadian company offering highly secure BlackBerry mobile devices by employing a
variation on BlackBerry’s corporate data security model. BlackBerry Enterprise Server (BES) is a MDM
application that runs on a corporate server. Blackberry Policy Service is a component of BES which performs the
security functions of pushing policies to devices, generating encryption keys and configuring device locks and
remote wipes. Phantom Secure deploys such a restrictive set of security policies that its devices are capable of no
other functions than communicating by encrypted email and chat. AES-256 encryption and 4096-bit PGP keys
(“Phantom Secure Private Messaging Service,” n.d.) are used to protect data in transit and long, complex
passwords to protect data at rest. A policy that prevents communication over the device’s Bluetooth and USB
interfaces renders them immune to forensic data extraction. Phantom Secure assumes responsibility for
supplying and maintaining the BES, and customers are provided fully pre-configured BlackBerry handsets with
global roaming SIMs. Phantom Secure avoids collecting payment or identity information about users and claims
that encryption keys exist only on user devices so they are unable to identify users or decrypt communications,
even under legal compulsion (“Encrypted mobile communications,” 2015). The company markets itself as a
privacy solution for professionals but the devices have been used by organized crime groups (Vergani & Collins,
2015, p. 421).
THEORY
Apple
Apple’s iOS has been an encrypting file system since iOS v3.0, released June 2009 (Bedrune & Sigwald, 2011,
p. 5), a desirable attribute for protecting data in a corporate environment. MDM solutions for managing Apple
devices interact with Apple’s APIs by applying policies and relying on the native on-device encryption. A set of
policies is compiled into a Configuration Profile, an .xml file that can be installed on the device over the air or
over USB using Apple Configurator.
A review of the Apple Developer Configuration Profile Reference document(“Configuration Profile Reference,”
n.d.) identified two keys that could affect a forensic data extraction of an iOS mobile device. The
“forceEncryptedBackup” key prevents an unencrypted backup of the device from being created, and the
“allowHostPairing” key, if set, prevents the device pairing with hosts other than the supervision host.
A critical aspect to iOS forensics is pairing records. Pairing records are used to establish a trust relationship
between an iOS device and a host computer. The pairing request is initiated by the host computer and creates a
set of keys on the host and the device. One of these encrypts the system “keybag”, a data structure used to store a
collection of encryption “class keys” that protect files in the file system. These keys are used to initiate an SSLencrypted session over USB or Wi-Fi, the only mechanism by which a service such as iTunes syncing or file
transfers can be started (“iOS 10 Security Guide.pdf,” 2017, pp. 14–16). The escrow keybag (a kind of backup
keybag) is part of the pairing record (Bedrune & Sigwald, 2011, p. 17).
Because pairing records created on the host computer are OS-independent .xml formatted plist files, they can be
copied to a forensic workstation to allow the iOS device to establish a trust relationship and permit data
extraction from user locked devices (Zdziarski, 2014).
Samsung
Knox is part of the Samsung Android operating system. Apps downloaded from the Android PlayStore are used
to activate Knox and provide an interface for configuring it. Knox is a hardware-based secure container
technology that creates a separate, encrypted space on a mobile device for confidential data which can be only be
accessed by a separate level of user authentication. This is achieved by using a Samsung customised version of
Security Enhanced Android, a major security enhancement implemented in Android 4.3.
Samsung uses an e-fuse to preserve the “chain of trust” that is rooted in the ARM Trust Zone (“White Paper: An
Overview of the Samsung Knox (TM) Platform,” 2016, pp. 6–8). If a non-Samsung boot loader, kernel or kernel
initialization script is used to boot the device, the chain of trust has potentially been broken as the non-genuine
software cannot be assured to be free from malicious or vulnerable functions. This causes the e-fuse (located
within the ARM Trust Zone) to “blow” and subsequent programming checks mandate that the device will then
be disabled from creating, or accessing an existing Knox secure container (Ning, 2013b) (Ning, 2013a).
An e-fuse or electronic fuse is a product developed by IBM in 2007 (Rizzolo et al., 2007), which allows a
physical change to be made in semiconductor components by a logic process. When an e-fuse is “blown” a
logical command causes an irreversible (or at least difficult to reverse) physical change. The state of an e-fuse
can also be queried by logical processes.
Some forensic extraction techniques rely on reflashing the Recovery partition on an Android device with a
customised version incorporating data extraction tools. These tools leverage the root privilege of applications
running from the Recovery partition when a factory reset is performed (Drake et al., 2014, p. 65).
The e-fuse has implications for such extractions because of the ability to destroy data stored in Knox secure
containers, a severe compromise to the forensic integrity of the examination. All possible precautions should be
taken to maintain the integrity of the original data, not least because future developments may allow the case to
be revisited and previously inaccessible data recovered.
EXPERIMENTAL METHOD
Two test devices were prepared a Samsung Galaxy S5 (Android) and an Apple iPhone 5s (iOS). Full details of
the sample devices appear in Appendix A. The test devices were reset to factory defaults then prepared as
follows:
Apple test device
Two levels of management of iOS devices are possible; “managed” and “supervised”. Supervision allows for a
greater level of control such as silent app updating, web filtering and single app mode (e.g. airline iPads for
movie viewing).
The Apple test device was configured using Apple Configurator 2, a software application for Mac OSX only (no
Windows or Linux versions) downloadable free of charge from the Mac App Store. Apple Configurator is
capable of configuring a wide range of settings for Apple mobile devices, requiring a USB connection to do so.
The device was then used for several weeks to populate it with sample data.
The Apple test device was first configured as a supervised device and the “allowHostPairing” policy was set to
prevent the device pairing with hosts other than the supervising computer. The device was then populated with
sample data.
An Advanced Logical data extraction was attempted using Cellebrite UFED Physical Analyzer.
The Apple test device was then configured as a managed device and in this case, copying of the pairing record
was successful in allowing the device to connect to the forensic workstation, even without unlocking the device
with the passcode. The “forceEncryptedBackup” key was set but UFED Physical Analyzer was not affected as it
has the option to extract data as an encrypted backup with a default password.
The data extraction was then repeated.
Samsung test device
The Samsung test device was set up, MyKnox v.2.3 was installed and the secure container created. The device
was then used for several weeks to populate it with sample data, including separate email accounts and pictures,
within and outside the secure container.
Logical and physical data extractions were attempted using Cellebrite UFED Physical Analyzer.
The device was later updated to MyKnox v.2.6 and the data extractions were repeated.
ANALYSIS
IDENTIFYING MDM MANAGED DEVICES
Ideally a forensic data extraction will be obtained and the extracted data will be inspected to determine the
presence of MDM management; this is the preferred method as it minimizes interaction with the original data.
Partial results, no results or unexpected results may indicate the presence of MDM and prompt the examiner to
investigate further. In the event that no data can be extracted, it may be necessary to manually inspect the device
to the minimum extent necessary to verify the presence of MDM management. Forensic practitioners should be
familiar with artefacts associated with MDM platforms and be able to recognize these.
Obstacles to Data Extraction
Apple
For supervised devices, it was predicted that copying the pairing record from the supervising computer to the
forensic workstation would permit the device to be connected. This failed in practice. Further research revealed
Apple Configurator also creates a “supervision identity” on the host computer, consisting of digital certificates in
X.509 format; Apple’s documentation (“Common Criteria Security Target for Apple iOS 9.3.5,” 2016) states
“Certificates can be installed for setting up multiple types of trusted channels including for host pairing”. The
supervision identity certificates are stored in the /Library/Keychains directory on the host computer and cannot
be copied from one host to another by a simple file copy, as can be done with the pairing record; certificates
must be password-protected, exported and re-imported to the new host (Dreyer & Karneboge, 2016, p. 298).
Samsung
MyKnox v.2.3 disables the USB debugging setting in Developer Options (Android Debugging Bridge). This
must be enabled for most forensic data extractions as they rely on the adb daemon on the device receiving and
processing commands from the adb server over a USB connection. This was implemented to mitigate
vulnerabilities in Knox v.1.0 (Kanonov & Wool, 2016, p. 23) and only a logical extraction over Bluetooth was
possible with this version installed. It appears these have been addressed in other ways as USB Debugging can
be enabled in Knox v.2.6.
Inspection of Extracted Data
Apple
Evidence was found of the profile created on the device by Apple Configurator. Within the folder
/Library/ConfigurationProfiles/ the file profile372c0becf5cb11340800e966a39a1816f9b326cc8e240a543fdc7b1a67e2697b.stub was
observed:
This file was found to be a binary .xml plist and contained useful information for the forensic examiner,
particularly if the user lock on the phone was bypassed. In this case, a PIN is set and a simple (numeric only)
passcode is allowed.
Figure 1: Details of the passcode settings for the device
Figure 2: Details profile removal password and the supervising host
Figure 2 shows the configuration password loaded on the device can be removed by entering a password and the
Removal Password is returned in plaintext – “password”. It is worth reiterating that this should never be
attempted in a forensic environment. It also identifies the supervising host.
Samsung
A forensic file system extraction of the Samsung test device was carried out and the results inspected. It was
noted that two Device User records were extracted, one named “KNOX”. This is consistent with the “multiple
user” feature of Android 5.0 utilized to create the secure container.
UserID 0 is assigned to the primary user, or owner – the first user created on the device (Elenkov, 2015, p. 90).
This consistent with the “normal world” user; UserID 100 is assigned to the Knox “secure world” user.
The two UserIDs have separate folder structures within the userdata partition, including separate accounts.db
database files. Although records of user activity stored in the “secure world” folder structure are encrypted and
cannot be accessed, information such as account names can be recovered.
Figure 3: Device users
Figure 4: user 0 accounts.db
Figure 5: user 100 accounts.db
The following is extracted from Root/system/device_policies.xml and shows the presence of
MyKnox as a management agent.
<admin_name="com.sec.enterprise.knox.cloudmdm.smdms.agent.global.myknox/com
.sec.enterprise.knox.cloudmdm.smdms.policyinterface.UMCAdmin">
Additional useful configuration data can be recovered from files in the secure world user’s folder. The following
is extracted from userdata/Root/system/users/100/device_policies.xml and contains details of the secure
container password format which would assist in attempts to guess or crack the password.
<active-passwordquality="131072"_length="8"_uppercase="0"_lowercase="0"_letters="0"_numeric
="8"_symbols="0"_nonletter="8"_recoverable="false_/>
Figure 6: Android password quality constants (“DevicePolicyManager | Android Developers,” n.d.)
Use of the secure profile can also be inferred. The Android database /Root/system/dmappmgr.db
records time of last launch and number of times an app has been launched.
Figure 7: Records of use of Knox packages
Timestamps are in epoch time. Knox switcher was last launched 12/04/2017, 8:12:31 pm
Inspection of device
MDM platforms require the installation of an app or agent. Pascucci states “All MDM products have apps that
are either in Google Play or the Apple App Store for users to download” (March 2015, para. 4) These packages
will appear as installed applications in forensic extraction reports and mobile forensic examiners must have a
broad overview of MDM products to identify these packages if they are detected in an extraction, and understand
the implications.
Apple
If the device can be unlocked, a check of the Settings app for iOS devices will reveal the use of an MDM:
Managed devices: If Settings/General/Profile exists, the details of the profile and the restrictions it imposes can
be viewed on the device. The entry “Delete Profile” may also be present indicating that the profile and associated
restrictions can be removed. This will require a password. Instead of “Profile”, it is possible that “Device
management” will appear under Settings/General (“Troubleshooting iOS 10 Devices with Mobile Device
Management Configurations | BlackBag Technologies,” n.d.).
Supervised devices: A Supervision entry will be present either under Settings/General or
Settings/General/About, depending on the iOS version (“Get started with a supervised iPhone, iPad, or iPod
touch - Apple Support,” n.d.).
In either case, details of the Restrictions within the profile can be viewed without risk of affecting existing data.
Supervision cannot be removed but a profile on a managed device can, if not protected by a password. This
should never be attempted in a forensic examination as it will result in data loss - “configuration profiles that
bind a device to an MDM server can be removed—but doing so will also remove all managed configuration
information, data, and apps.” (“iOS 10 Security Guide.pdf,” 2017, p. 56)
Samsung
If the device can be unlocked and manually inspected, the presence of active MDM management may be inferred
in several ways.
From the home screen, swiping down from the top of the screen will display the Notification bar – a link to
“Knox” mode, or “Work” mode will be visible.
Any management platforms will show a Device Administrators entry in the Security settings. The details of
operations each Administrator can perform can be viewed and although it may be an option to deactivate them,
this should never be done in a forensic environment as it may cause loss of data. Also in the device settings, the
Application Manager app will show running apps and services including MDM agents.
CONCLUSIONS/RECOMMENDATION
MDM platforms are effective at securing data on mobile devices, even from forensic examination, as is to be
expected from products produced and used by some of the world’s largest companies. Forensic investigators
must be adept at recognizing when these tools are in use and what types of data they may be securing, and if the
co-operation of the MDM administrator cannot be enlisted, legal remedies must be considered. In the device
seizure phase, investigators must consider whether it is appropriate to also seize other computers that may have
been used to administer the MDM or may contain device backups. The seizure phase should be carefully planned
ahead of time, executed promptly and mobile devices isolated from wireless and cellular networks without delay
to prevent remote locking or wiping. Even co-operating companies or employers may insist on legal procedures
such as search warrants or Orders to Produce, to satisfy policy and shield themselves from liability in respect of
employees’ privacy, so these should be obtained and served without delay.
APPENDIX A
Software
UFED Physical Analyzer
Version
6.2.0.79
Sqlite Forensics Explorer
Notepad ++
Apple Configurator
Oxygen Plist Viewer
2.0.0.0
7.4.1
2.0
9.3.1.76
Purpose
Forensic data extraction of sample mobile devices, parsing
extracted data
Examining sqlite database files
Examining .xml configuration files
Configuring Apple sample mobile device
Examining .plist files
Table 1: Software used
Apple iPhone model A1530 (iPhone 5s)
Specification
SoC
CPU
Memory
OS
IMEI
Details
Apple A7 (64 bit architecture) & M7 coprocessor
ARM v8 based 1.3GHz Cyclone dual-core
32GB
iOS 10.2.1
358693/05/458427/1
USB PID & VID
05AC & 12A8
Google account created for sample device
csg.6223.2016@gmail.com
Table 2: The specifications of the Apple sample device
Samsung model SM-G900i (Galaxy S5)
Specification
Details
SoC
Qualcomm MSM8974AC Snapdragon 801
CPU
Quad-core 2.5 GHz Krait 400
Memory
16GB
OS
Android 4.4.2, kernel 3.4.0-2269681
IMEI
353696/06/111825/1
USB PID & VID
04E8 & 6860
Google account created for user profile
csg6223.2016@gmail.com
Google account created for Knox Profile
csg6223.MyKnox@gmail.com
Table 3: The specifications of the Samsung sample device
REFERENCES
Bedrune, J.-B., & Sigwald, J. (2011, October). iPhone data protection in depth. Presented at the Hack In The
Box Security Conference, NH Grand Krasnapolsky, Amsterdam, The Netherlands. Retrieved from
http://esec-lab.sogeti.com/static/publications/11-hitbamsterdam-iphonedataprotection.pdf
Common Criteria Security Target for Apple iOS 9.3.5. (2016, September 7). Retrieved May 20, 2017, from
https://www.niap-ccevs.org/st/st_vid10725-st.pdf
Configuration Profile Reference. (n.d.). Retrieved May 20, 2017, from
https://developer.apple.com/library/content/featuredarticles/iPhoneConfigurationProfileRef/Introduction/I
ntroduction.html
Criminal Investigation Act 2006. (n.d.). Retrieved from
https://www.slp.wa.gov.au/pco/prod/FileStore.nsf/Documents/MRDocument:29396P/$FILE/Criminal%2
0Investigation%20Act%202006%20-%20[03-c0-02].pdf?OpenElement
DevicePolicyManager | Android Developers. (n.d.). Retrieved May 28, 2017, from
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#PASSWORD_Q
UALITY_ALPHABETIC
Drake, J. J., Oliva Fora, P., Lanier, Z., Mulliner, C., Ridley, S. A., & Wicherski, G. (Eds.). (2014). Android
hacker’s handbook: [a complete guide to securing the Android operating system]. Indianapolis, Ind:
Wiley.
Dreyer, A., & Karneboge, A. (2016). Managing Apple Devices (Third Edition). California: Peachpit Press.
Elenkov, N. (2015). Android security internals: an in-depth guide to Android’s security architecture. San
Francisco: No Starch Press.
Encrypted mobile communications. (2015, August). Retrieved from
https://www.slideshare.net/phantomencrypt/encrypted-mobile-communications
Get started with a supervised iPhone, iPad, or iPod touch - Apple Support. (n.d.). Retrieved May 20, 2017, from
https://support.apple.com/en-au/HT202837
Heath, A. (2016, February 23). What you need to know about Apple and FBI’s encryption fight - Business
Insider. Retrieved March 19, 2017, from http://www.businessinsider.com/what-you-need-to-know-aboutapple-and-fbis-encryption-fight-2016-2?IR=T
iOS 10 Security Guide.pdf. (2017, March 10). Retrieved May 8, 2017, from
https://www.apple.com/business/docs/iOS_Security_Guide.pdf
iOS9_Hardening_Guide.pdf. (2016, September 1). Retrieved April 4, 2017, from
https://asd.gov.au/publications/protect/iOS9_Hardening_Guide.pdf
Kanonov, U., & Wool, A. (2016). Secure containers in Android: the Samsung KNOX case study. In Proceedings
of the 6th Workshop on Security and Privacy in Smartphones and Mobile Devices (pp. 3–12). ACM.
MDM-Compare.pdf. (2015, May). Retrieved May 14, 2017, from http://mobiwm.com/wpcontent/uploads/2015/05/MDM-Compare.pdf
Mobile Device Management Market - Global Forecast to 2021. (n.d.). Retrieved May 13, 2017, from
https://globenewswire.com/news-release/2016/12/15/897867/0/en/Global-Mobile-Device-ManagementMarket-Growth-at-CAGR-of-25-8-2016-2021-Market-to-Reach-5-32-Billion.html
Ning, P. (2013a, December 4). About CF-Auto-Root | Samsung KNOX. Retrieved May 10, 2017, from
https://www.samsungknox.cn/en/blog/about-cf-auto-root
Ning, P. (2013b, December 4). About rooting Samsung KNOX-enabled devices and the KNOX warranty void
bit | Samsung KNOX. Retrieved May 10, 2017, from https://www.samsungknox.cn/en/blog/aboutrooting-samsung-knox-enabled-devices-and-knox-warranty-void-bit
Pascucci, M. (2015a, March). Introduction to mobile device management products. Retrieved May 14, 2017,
from http://searchsecurity.techtarget.com/feature/Introduction-to-mobile-device-management-products
Pascucci, M. (2015b, September). Comparing the best mobile device management products. Retrieved May 14,
2017, from http://searchsecurity.techtarget.com/feature/Comparing-the-best-mobile-device-managementproducts
Phantom Secure Private Messaging Service. (n.d.). Retrieved May 27, 2017, from
http://www.phantomsecure.tv/documents/PSspectrum.pdf
Purdy, J. G. (2016, March 9). Analyst Angle: The FBI vs. Apple - RCR Wireless News. Retrieved May 8, 2017,
from http://www.rcrwireless.com/20160309/opinion/analyst-angle-fbi-vs-apple-tag9
Rege, O. (2016, February 22). Reactions to the San Bernardino County debate | MobileIron. Retrieved May 8,
2017, from https://www.mobileiron.com/en/smartwork-blog/reactions-san-bernardino-county-debate
Rizzolo, R. F., Foote, T. G., Crafts, J. M., Grosch, D. A., Leung, T. O., Lund, D. J., … Wiedemeier, G. A.
(2007). IBM System z9 eFUSE applications and methodology. IBM Journal of Research and
Development, 51(1.2), 65–75. https://doi.org/10.1147/rd.511.0065
Sierra VMI datasheet Final.pdf. (n.d.). Retrieved May 13, 2017, from
https://www.sierraware.com/SierraVMIdatasheetFinal.pdf
Souppaya, M. P., & Scarfone, K. A. (2016). Guide to Enterprise Telework, Remote Access, and Bring Your
Own Device (BYOD) Security (No. NIST SP 800-46r2). National Institute of Standards and Technology.
https://doi.org/10.6028/NIST.SP.800-46r2
Troubleshooting iOS 10 Devices with Mobile Device Management Configurations | BlackBag Technologies.
(n.d.). Retrieved March 15, 2017, from https://www.blackbagtech.com/blog/2016/11/18/troubleshootingios-10-devices-with-mobile-device-management-configurations/
Vergani, M., & Collins, S. (2015). Radical Criminals in the Grey Area: A Comparative Study of Mexican
Religious Drug Cartels and Australian Outlaw Motorcycle Gangs. Studies in Conflict & Terrorism, 38(6),
414–432. https://doi.org/10.1080/1057610X.2015.1004891
Wang, X., Sun, K., Wang, Y., & Jing, J. (2015). DeepDroid: Dynamically Enforcing Enterprise Policy on
Android Devices. Retrieved April 19, 2017, from
https://www.internetsociety.org/sites/default/files/02_5_1.pdf
White Paper: An Overview of the Samsung Knox (TM) Platform. (2016, December). Retrieved May 13, 2017,
from https://kp-cdn.samsungknox.com/6ee7dbf222f5eabeafea9d15e3986f09.pdf
Zdziarski, J. (2014, September 28). Counter-Forensics: Pair-Lock Your Device with Apple’s Configurator –
Zdziarski’s Blog of Things. Retrieved March 19, 2017, from https://www.zdziarski.com/blog/?p=2589