Security configuration of Android devices

Android version 6 Marshmallow introduced the gatekeeper lock format. Additionally, some Android devices which ship with v6 or later will have Full Disk Encryption enabled. This page aims to summarise security configuration details relating to Android devices.

To determine whether an Android device is hardware-backed, navigate to Settings – Security – Credential Storage – Storage type.

 

Device Make

Device Model

Android version
(out of the box)

FDE status
(out of the box)

Credential Storage type

H/W Backed flag from gatekeeper file

Notes

LG K4 2017 M160  v6.0.1 OFF Hardware backed TBD Backup PIN required for pattern lock
Alcatel U5 4047D  v7.0 OFF Hardware backed 0×01
Motorola C Plus XT1723 v7.0 OFF Hardware backed 0×01
Alcatel Shine Lite 5080X v6.0 ON Hardware backed TBD
Vodafone Smart E8 v7.1.1 OFF Hardware backed TBD
Alcatel A3 5046Y v6.0 ON Hardware backed TBD
LG K3 K100 v6.0.1 ON Software only 0×00 Backup PIN required for pattern lock
Motorola E3 XT1700 TBD TBD TBD TBD
Samsung Galaxy A3 SM-A300FU v5.1.1  OFF Hardware backed TBD
Samsung Galaxy S8 SM-G950F v7.0 ON Hardware backed TBD
Samsung Galaxy S7 SM-G930F v6.0.1 ON Hardware backed TBD
Samsung Galaxy S7 Edge SM-G935F v6.0.1 ON Hardware backed TBD
Samsung Galaxy S6 SM-G920F v5.1.1  OFF Hardware backed TBD
Samsung Galaxy A3 (2017) SM-A320FL v6.0.1 ON Hardware backed TBD
Samsung Galaxy A5 (2017) SM-A520F v6.0.1 ON Hardware backed TBD
Samsung Galaxy J5 (2017) SM-J530F v7.0 ON Hardware backed TBD
Samsung Galaxy J5 SM-J500FN v5.1.1  OFF Hardware backed TBD
Samsung Galaxy J5 (2016) SM-J510FN v5.1.1 OFF Hardware backed TBD
Motorola Moto X XT1092 v6.0 OFF Hardware backed TBD
Samsung Galaxy J3 (2017) SM-J330F v7.0 ON Hardware backed TBD
HTC Desire 650 D650H v6.0.1 OFF Hardware backed TBD
Sony Xperia XA F3111 v6.0 ON Hardware backed TBD
Motorola Moto C XT1754 v7.0 TBD Hardware backed TBD
HTC One M9 v5.0 TBD Hardware backed 0×00 Unexplained mismatch between Credential Storage and gatekeeper file flag
Alcatel Pop 4 v6.0 TBD TBD 0×01
LG Nexus 5X v6.0 TBD TBD TBD
Sony Xperia XA1 G3116 v7.0 ON Hardware backed TBD
Sony Xperia L1 G3311 v7.0 ON Hardware backed TBD
Samsung Galaxy J3 (2016) SM-J320FN v5.1.1 OFF Software only TBD

Regular expressions and search terms for phone examiners

This page is intended to act as a resource for phone forensic examiners who are working with physical extractions (“hex dumps”) of mobile phone handsets. It aims to provide advice as well as usable search terms and regular expressions that phone examiners can use to find key data within a mass of hex data.

The page is split into two sections to reflect that certain types of data are commonly stored as files (e.g. video, MMS etc.) whereas other data types such as previous SIM details may be stored as individual “records” rather than in files. Do also refer to Gary Kessler’s excellent file signature page – we can’t live without it!

Non File Based

Data Type Example (decoded) Info on format Suggested search / regexp
IMSI 234105563888549 http://en.wikipedia.org/wiki/IMSI Country/region specific – See below
IMSI prefixes are country specific so a single global IMSI search probably doesn’t make sense (and would return too many ‘false positive’ hits). Encoding of the IMSI within the handset memory will vary, but some handsets will follow the SIM card standards and store the IMSI in hex in a reverse nibbled decimal format.For example, the IMSI 234105563888549 would appear as the hex 29 43 01 55 36 88 58 94. Some Samsung and Nokia handsets certainly use this approach.IMSIs are normally 15 digits long, the leading “9” in the above example creates 8 pairs of hex digits. IMSIs start with the Mobile Country Code (for the UK this is “234”) which is followed by the Mobile Network Code. In the UK, the MNCs “10”, “15”, “20”, “30” and “33” are used by the five UK networks O2, Vodafone, 3, T-Mobile and Orange respectively.So the following regular expression:
\x29\x43[\x01|\x02|\x03|\x33|\x51]

could be used to find all occurrences of the five valid UK IMSI prefixes.

The regular expression could be extended to specify that the remaining 9 characters must be digits, but this makes the regular expression much longer and somewhat confusing (due to the fact that we are writing a regular expression to match hex rather than one to match text).

Some Samsung handsets (e.g. E1080i, E1120) appear to always store

\x11\xF2\xFF

directly after the IMSI. Hence the regular expression above can be extended to include the last 5 bytes of the IMSI and this (Samsung-specific) trailer:

\x29\x43[\x01|\x02|\x03|\x33|\x51].{5}\x11\xF2\xFF
Data Type Example (decoded) Info on format Suggested search / regexp
ICCID 8944110064815443720 http://en.wikipedia.org/wiki/ICCID#ICCID Country/region specific – See below
ICCID prefixes are also country specific and country-specific searching is a good place to start. ICCIDs are also often stored (as per the SIM standards) in hex in reverse nibbled decimal format like IMSIs See the notes above on IMSI encoding.ICCIDs are normally 19 or 20 digits long, so expect 10 pairs of hex digits, possibly using an “F” as padding  if the ICCID was only 19 digits long (that’s how it’s done on the SIM and hence some manufacturers will follow this). All ICCIDs start “89″ followed by the dialling code for that country and then a two digit identifier for the issuing service provider (known as the Issuer Identifier Number). For example, all UK SIM cards all start “8944” and the Issuer Identifier Numbers  “10”, “11”, “20”, “30” and “12” are used by the five networks Vodafone, O2, 3, T-Mobile and Orange respectively.So the following regular expression:

\x98\x44[\x01|\x02|\x03|\x11|\x21]

could be used to find all occurrences of the five valid UK ICCID prefixes.

Data Type Example (decoded) Info on format Suggested search / regexp
SMS N/A GSM 03.38 (GSM 7 Bit Alphabet)GSM03.40http://www.dreamfabric.com/sms/ Country/region specific – See below
Format for transmission of SMS across the network (and storage on the SIM) is standardised, but copies of SMS in handset memory (or on removable media) are often manufacturer-specific. It makes sense to start by looking for SMS using the GSM standard format and then adjusting the search based on the results.The start of a GSM standard SMS header includes the phone number of the SMSC responsible for handling the message as well as the length of that phone number. The length and format of phone numbers varies from country to country, so it is most practical to start by looking for SMS which have SMSC numbers relating to a specific country. The very first byte of a standards-based SMS is the status of the message which could be “00” (deleted) , “01”  (read),  “03” (unread),  “05” (sent) or “07” (unsent). The second byte stores the length of the SMSC number counted in bytes (including the Type of Number field which itself is 1 byte long) which should be consistent within a particular country. The Type of Number (TON) field is usually set to “91” for the SMSC number. This indicates that the number which follows is in international format (e.g. “447958879884”) – again the first few digits of the SMSC number will be the country code which can be included in the search expression. Taking the UK as an example, a typical SMS header for a read message might look like:

01 07 91 44

We can choose to ignore the status byte in our search (as manufacturers may have chosen to not include this) and just search for the characteristic “07 91 44” string.  So, to search for SMS relating relating to UK subscribers, we could use the regular expression:

\x07\x91\x44

This search term may identify SMS present within a memory dump. Further work will be required to determine the actual start and end of the SMS message. The message content itself is quite possibly encoded using the GSM 7-bit alphabet (i.e. not ASCII) so don’t expect the words of the text message to jump out at you!

Some Samsung handsets (e.g. D500, D600 etc.) use the keyword “DEADBEEF” as a delimiter between text messages in the handset memory. Running a ASCII text search for “DEADBEEF” on such a handset should yield results – and if you are searching the OneNAND raw memory then you’ll be looking at live and deleted messages (only live messages can be recovered from the FAT file system layer).

File Based

Data Type Info on format Suggested search / regexp
MMS MMS Encapsulation Protocol (Candidate Version 1.3, 28-Jan-2008), Open Mobile AllianceMMS Conformance Document (Candidate Version 1.3, 28-Jan-2008), Open Mobile Alliance
\x8C[\x80\x84]\x98
OR
<smil
Format for transmission is standardised but copies of MMS in handset memory are often in manufacturer-specific format. If the manufacturer has stored the message in a proprietary format, it may still be able to locate them using an ASCII text search for “<smil” which should appear near the start of a message. MMS messages start with a “tag” (0x8C) which indicates that the first header field will be the message type (which itself is one byte long). The message types of most interest are 0×80 (sent messages) and 0×84 (received messages). The third byte in the message should be the tag 0×98 which indicates that the second header field that follows is the Transaction-ID.As such, we can search for all sent and received messages with the regular expression:

\x8C[\x80\x84]\x98
Data Type Info on format Suggested search / regexp
3GP / MP4 MP4 file format defined in MPEG Part 14 (ISO/IEC 14496-14:2003)
\x00\x00\x00.\x66\x74\x79\x70
Commonly encountered “4th byte” values are 0×14, 0×18, 0x1C, 0×20. The regular expression above will match on 3GP/MP4 headers with any value present in the 4th byte.

Default Handset Security Codes

Most mobile phone handset manufacturers provide some form of security code or PIN function on their devices which is separate to the PIN mechanism provided by the SIM. The table below attempts to document the default values for such handset security codes which may allow access to a device.Note that as some manufacturers will use different default values on different handset models, it is highly recommended to download a copy of the handset user manual from the manufacturer’s website in order to see if it documents the default security code setting of the handset.

IMPORTANT: The information provided here is, to the best of our knowledge correct. Use of this information is of course at your own risk. Remember that some handsets such as an iPhone, BlackBerry etc. can be configured to erase their contents when a security code is entered incorrectly

Manufacturer

Default Security Code

Notes

Nokia

12345

Samsung

00000000

Sony Ericsson

0000

LG

0000

Sagem

0000

RIM BlackBerry

None

BlackBerry handsets do not use a default device password

Android

None

Android handsets do not use a default screen lock

Default SIM PINs

Some communications service providers (CSPs) issue their SIM cards pre-configured with the same default PIN on all of their cards. This practice is by no means universal worldwide and in some countries, different default PINs are set on each SIM issued. The table below attempts to document the behaviour of each network provider.

IMPORTANT: The information provided here is, to the best of our knowledge correct. Use of this information is of course at your own risk. Remember that a SIM will become “blocked” after 3 incorrect attempts to enter the PIN (after which the PUK will need to be entered).

Country

CSP

Default SIM PIN

Notes

UK

Vodafone

0000

UK

Orange

1111

UK

EE

1111

UK

3

0000

UK

T-Mobile

1210

UK

Virgin Mobile

7890

UK

O2
(online PUK retrieval)

0000, 5555 or 1234

0000 is most common

UK

Tesco Mobile
(online PUK retrieval)

5555

UK

giffgaff

5555

IMSI and ICCID Prefixes

GSM and 3G SIM cards are configured with two identifiers: an ICCID and an IMSI. The ICCID (Integrated Circuit Card Identifier) can be thought of as the serial number of the card itself whereas the IMSI (International Mobile Subscriber Identity) is analagous to an account number for the mobile subscriber.

TIP: IMSI is pronounced  “imzee” by those ‘in the know’!

Both the ICCID and IMSI include country and issuing network information, but unfortunately the same concept has been implemented differently in the two identifiers. This can be extremely confusing! The following tables are intended as an aide-memoire for quickly recalling the ICCID and IMSI prefixes used by different communications service providers.

NOTE: The two digit network code used in the ICCID is referred to as the Issuer Identification Number. The two or three digit network code used in the IMSI is referred to as the Mobile Network Code (which is preceded by a three digit Mobile Country Code)

This page is intended to complement the existing excellent resources at www.numberingplans.com and Wikipedia which we would strongly recommend that you bookmark too!

Country

CSP

ICCID Prefix

IMSI Prefix (MCC + MNC)

Notes

UK

Vodafone

894410

23415

UK

Orange

894412

23433

UK

3

894420

23420

UK

T-Mobile

894430

23430

UK

EE

894430

23430

UK

Virgin Mobile

(MVNO of T-Mobile)

894430

23430

UK

O2

894411

23410

UK

Tesco Mobile
(MVNO of O2)

894411

23410

UK

mobile by Sainsbury’s (MVNO of Vodafone)

894410

23415

This ICCID and IMSI prefix taken from an actual mobile by Sainbury’s SIM.

UK

Vectone Mobile

894401

23401

This ICCID and IMSI prefix taken from an actual Vectone Mobile SIM and relates to Mapesbury Communications Ltd. However Vectone Mobile’s Wikipedia page indicates that they are an MVNO of T-Mobile!

UK

Talk Mobile
(MVNO of Vodafone)

894410

23415

UK

Lebara
(MVNO of Vodafone)

894410

23415

UK

Lyca Mobile
(MVNO of Orange)

894412

23433

This ICCID and IMSI prefix taken from an actual Lyca Mobile SIM. The Lyca Mobile Wikipedia page states that Lyca also uses the O2 network in the UK.

UK

Nomi Mobile
(MVNO of Vodafone)

894410

23415

UK

ASDA Mobile
(MVNO of Vodafone)

894410

23415

UK (Jersey)

Marathon Telecom Ltd

894403

23428

UK

IDT Mobile
(MVNO of Orange)

894412

23433

UK

Mobile World
(MVNO of T-Mobile)

894430

23430

UK

giffgaff
(MVNO of O2)

894411

23410

This ICCID and IMSI prefix taken from an actual giffgaff SIM

Italy

WorldSIM (Service Provider Name stored on card is ‘Global Roaming’)

89234

22201

Although technically an Italian SIM, WorldSIM has been sold on British Airways flights and is targeted at UK customers. The card claims to include “Multi IMSI Technology” and offer both a UK and a US mobile number

Liechtenstein

SIM 4 Travel

8942305

29505

Although technically a Liechtenstein SIM, SIM4Travel SIMs have previously been on sale in UK airports

Android folder paths for microSD and eMMC storage

All Android devices will have the facility to provide external storage which could be one or both of the following:

  • Removable microSD card – some, but not all Android devices provide a microSD card slot
  • eMMC chip soldered to the circuit board of the device – some, but not all devices may contain an eMMC chip either instead of, or as well as a removable microSD card.

Confusingly there is a lot of variation in the folder location for these two areas on different Android devices and different Android versions. The following tables lists some of the folder paths that we have seen used on Android devices for the removable microSD card and the eMMC chip.

Path for removable microSD card

Notes

/storage/extSdCard

 Seen on some Samsung devices

/storage/ext_sd

 Seen on some HTC devices

/mnt/sdcard/external

 Used within Android backups

/storage/sdcard<N>

<N> is a number – e.g. /storage/sdcard1

Values of “0” and “1” have been seen for removable microSD cards on different devices.

It is possible that USB storage connected via a USB OTG (“On the go”) cable might be mapped in this way with a different number

/storage/usbdisk

Seen for USB drive connected via OTG cable

 

Path for eMMC storage

Notes

/mnt/shell/emulated/<N>

<N> is a number which distinguishes between different users on the same device. The owner account has the id “0” so this path will typically be: /mnt/shell/emulated/0 This is believed to have been introduced in Android v4.4.4

/storage/emulated/legacy

This is believed to be the folder naming structure used in Android v4.4.3 and earlier

/storage/emulated/<N>

<N> is a number which distinguishes between different users on the same device. The owner account has the id “0” so this path will typically be: /storage/emulated/0

/mnt/sdcard

This is potentially confusing as it is not the removable microSD card, but the eMMC storage. To make matters more confusing the removable SD card may appear as a sub-folder of this – i.e. /mnt/sdcard/external

shared/<N>

<N> is a number.

This is the folder naming used within Android ADB backups (and which may appear within backup extractions performed by forensic tools)

/data/media/<N>

<N> is a number – e.g. /data/media/0

Seen in extractions of rooted devices

iOS Photo Attribution flowchart

Flowchart for assisting in attributing photos which may have been synchronised via PhotoStream or shared via iCloud Photo Sharing.

Example cover sheet for a mobile forensic extraction

Suggested wording for a cover sheet that might accompany a mobile device extraction report

Important information about the attached “logical extraction” report

The attached report relates to a “logical extraction” of a mobile device. A logical extraction requires  the device to be powered on and data is extracted from the device by means of a series of queries (by the extraction software) and responses (from the device).

Consequences of this extraction method include:

  • The data included within the report is a subset of the data contained within the device
  • Deleted data may exist in the device but in some cases will not have been extracted
  • Some of the data presented has been decoded, converted or interpreted by the extraction software
  • The contents of a powered mobile device are changing continuously and therefore the state of the device is not exactly identical to when it was taken into custody.

Important information about the attached “physical extraction” report

The attached report relates to a “physical extraction” of a mobile device. A physical extraction typically involves using software on a PC to take as full and accurate a copy of the contents of the device’s memory as possible. This data is then decoded and interpreted by a forensic software tool (this may be the same software used to extract the data from the device or a separate software product).

In the majority of physical extractions, data will have been copied from the device whilst it was powered off, however, this is not always the case.

Consequences of this extraction method include:

  • Although all of the available data may have been copied from the device, the data
    included within the report is only that which it has been possible to decode and interpret.
  • Deleted data should have been extracted from the device however its presence within the report is dependent upon the ability of the software tools used to identify and decode it
  • Some of the data presented has been decoded, converted or interpreted by the extraction software
  • The contents of a powered mobile device are changing continuously and therefore if the device in question was powered on in order to extract data, the state of the device is not exactly identical to when it was taken into custody

Proposed Model for Defining the Role of a Mobile Forensic Examiner

This document is intended to accompany the slide presentation “Has Anyone Seen A Career Path Around Here?” first delivered by Kevin Mansell in June 2014.

About this document

This document is intended to accompany the slide presentation by Kevin Mansell of Control-F, entitled “Has anyone found a career path?” and provides further detail than can be conveyed via the slides alone.

The role of a mobile forensic examiner

The job of a mobile forensic examiner is multi-faceted and complex. Mobile devices often need to be coaxed and coerced into yielding their contents. Once data has been extracted, items of evidential interest are not always immediately obvious and may require skilful analysis in order to locate and interpret them.

Added to these technical aspects of the role, mobile device examiners worldwide are faced with the challenge of examining increasing numbers of ever more complex devices with limited resources. The danger of slipping into treating mobile forensics as a “handle turning” exercise is real and ever present.

The wider organisation in which the mobile forensic examiner is employed is likely to have a very limited understanding of what the role actually entails. Mobile forensics may be seen as some sort of magic, or perhaps more worryingly as a simple low-skilled role: plug in the device, click some buttons, print the report and move on to the next device.

This lack of understanding of what mobile forensics actually involves is damaging in two ways:

Staff churn

Until the role is properly understood by management and human resources departments, job descriptions for mobile examiners will not properly reflect the role being performed. This already means (in the UK at least) that mobile forensic examiners are often paid less than their colleagues employed as computer examiners due to mobile forensics being perceived as being a less skilled job. Consequently highly skilled mobile forensic examiners will transfer to computer forensic roles for more pay, move to another organisation for a wage increase or leave the field entirely. All three of these outcomes are damaging to mobile forensics as a discipline and the criminal justice system that they serve.

Miscarriages of justice

Evidence recovered from mobile devices, and the testimony given by the examiners who recover it, affects people’s liberty. There have been miscarriages of justice in the UK and elsewhere where forensic evidence has either been mishandled, misinterpreted, overstated or ignored. To date there has not been a “headline” case in the UK where mistakes relating to mobile forensic evidence have led to a miscarriage of justice, but if it can happen with DNA and other “traditional forensic” disciplines, it is only a matter of time before mobile forensics, forensic examiners and their employers fall under the spotlight for the wrong reasons.

Mobile forensics isn’t what it was

Just ten years ago, most mobile phones didn’t have cameras, memory cards, Internet access or GPS functionality. Although cheap “burner” handsets without those capabilities can still be purchased, almost all new handsets are smartphone devices1.

Those changes are part of the reason why mobile device forensics is becoming ever more complex: we have more devices which can perform more tasks. At the same time, we have a wider array of techniques for recovering data from mobile devices. The decision as to how to process a particular evidential exhibit coupled with the skilled analysis required to locate and interpret key evidence has never been more important.

Many organisations employing mobile forensic examiners are deploying kiosk-based products operated by staff who do not have a background in digital forensics, typically to process devices associated with volume crime. These staff will not have the same skills or experience as examiners within a dedicated forensic unit. Although this is not a problem in itself, many organisations fail to properly distinguish between the two roles.

Just as paramedics play a vital role in healthcare provision, dealing with a huge range of medical scenarios, there is also a need for “generalists” in the field of mobile forensics. Equally, we expect our healthcare providers to employ skilled anaesthetists, surgeons and consultants; highly trained and experienced staff in specialist roles. In mobile forensics we need to encourage the development of specialist staff with specific skills: bypassing security mechanisms, interpreting mobile web artefacts, de-soldering flash memory chips, recovering deleted data from smartphone app databases etc.

Employers of mobile forensic examiners need to recognise the different dimensions of the job and build organisational structures where staff can progress and be promoted into specialist roles. However, before that can happen we need a model that describes mobile forensic examination in sufficient detail to allow accurate job descriptions to be written. The remainder of this document proposes such a model.

1 A search in June 2014 of the comprehensive database on www.gsmarena.com reveals that of the 46 devices (handsets and tablets) listed as “Coming Soon”, 44 are Android devices, 1 runs Windows Phone 8 and another runs the Tizen Linux-based operating system; in other words all are smartphone devices. In March 2010, only 3 years ago, only 35% of the “Coming Soon” handsets were smartphones

Overview of the Model

This document and the accompanying slide presentation propose a 3-level model, informally described as consisting of levels at 50,000 feet, 5,000 feet and 5 feet. The use of imperial units should not preclude use of this model in countries that state altitudes in metres!

High Level Description (50,000 feet)

At a high level, mobile device forensics can be considered as consisting of acquisition of data from mobile devices and analysis of that extracted data. In many organisations these two roles will be performed by the same person (examiners typically had to be a “jack of all trades”), but it is important to note that this need not be the case. There are today, and increasingly will be in the future, advantages from having staff specialised in either the acquisition or analysis aspects of mobile device forensics.

Acquisition can be broken down into the following sequence of tasks. Although these tasks may often be conducted by the same person for a particular device examination, this need not be the case.

  1. SELECT an appropriate acquisition tool and extraction type based on the type of device and case requirements
  2. EXTRACT data from the device in accordance with recognised digital forensics principles, local operating procedures and the law
  3. EVALUATE extracted data to assess the success of the acquisition and the need for further data extraction (and return to Step 1 if appropriate)
  4. PRODUCE extracted data in a format which is usable by the recipient

Steps 1-3 in particular are skilled tasks. Step 3 (“Evaluation”) is especially important due to the real possibility that a particular extraction tool/technique will only recover a subset of all relevant data from a particular device and hence further examination will be required.

Analysis can be broken down into the following sequence of tasks. Again, these need not necessarily be conducted by the same person for a particular examination.

  1. ESTABLISH the requirements for any analysis based on input from the case officer (what does the investigating team hope to achieve by examining the device?)
  2. ANALYSE the extracted data in accordance with those requirements
  3. REPORT results from the analysis in a format which is usable by the recipient
  1. EXPLAIN the significance of reported data in written and verbal testimony

Middle Level Description (5,000 feet)

Mobile device forensics requires knowledge and practical skills in the following five subject areas. Note that the sub-topics listed should not be considered a comprehensive list, but rather as examples of which each subject area involves.

1. Principles

  • Digital forensic principles
  • Relevant legislation
  • Exhibit handling, continuity/“chain of custody”

2. Devices

  • How mobile devices behave
  • What data mobile devices store
  • Types of mobile device
  • Connection interfaces
  • Mobile operating systems

3. Acquisition

  • Extraction techniques (e.g. manual, logical, physical, JTAG, chip-off etc.) and what they can/cannot recover
  • Extraction tools – how to operate a specific tool and what functionality it provides
  • Troubleshooting acquisition problems – Has an acquisition failed? If so why?

4. Data

  • Fundamentals of digital data
  • Numbering schemes – e.g. decimal, binary, hexadecimal
  • File systems – live vs. deleted vs. unallocated, characteristics of flash memory etc.
  • Working with raw data – e.g. working in a hex viewer, nibbles, bytes,offsets etc.
  • Analysis tools – recovery of live and deleted data using tools
  • File signatures and file carving
  • Searching raw data
  • Decoding and interpretation of raw data (e.g. timestamps, encoded or encrypted data)
  • Tool development – writing scripts or other software tools to automate data recovery and interpretation

5. Reporting

  • Converting recovered data into appropriate formats
  • Producing written reports and witness statements
  • Giving verbal testimony

Low Level Description (5,000 feet)

Each of the five subject areas defined at the middle level can be broken down further into competencies and expected outcomes. Benjamin Bloom, a prominent American educational psychologist described learning in a particular area as consisting of a spectrum of skills (Bloom, 1956)2. A skills spectrum can be considered similar to a ladder with less demanding skills at the bottom, building in complexity to higher order skills at the top. For example, when considering thinking (“cognitive”) skills, low order tasks often involve simply recalling information. As learning progresses, an individual should able to apply knowledge to a task or problem. Evaluation skills such as comparing, contrasting and judging are at the highest level.

Petty summaries Bloom’s structure for learning as follows (Petty, 2004):

  • Full learning only comes from learning skills at all levels
  • Higher order skills are dependent on lower order skills being mastered first Using acquisition of data from a mobile device as an example, we can start to identify competencies at different levels:
  • EVALUATE: “Compare and contrast four different methods of extracting data from mobile devices and provide an example scenario of where each might be appropriate”
  • APPLY: “Which of the following extraction techniques could be used to recover previous SIM details from a Samsung GT-I9100 handset?”
  • STATE: “Define the term logical extraction”

These expected competencies can be used to define learning objectives and can form the basis of assessment programmes; in other words we can define what we expect a mobile forensic examiner to be able to do.

In order for the model proposed here to be truly useful, the five subject areas (and sub- topics) defined at the middle level need to be refined, completed and then broken down into competencies at the different levels of Bloom’s Taxonomy. Including experienced mobile forensic practitioners from different organisations and countries in completing the model is critical to ensuring that it is representative and has practical application. Volunteers are welcomed!

2 Bloom’s work has the daunting title “Taxonomy of Educational Objectives”, put simply it is a structure for learning.

Using the Model

Once complete, this model can be used to write job (accurate) descriptions and provide input to workplace performance evaluations, structure training programmes and assess examiner competency. Organisations can use the model to better understand the skillsets of their staff and to ensure that they have staff with capabilities across all of the relevant subject areas.

Importantly, if the wider forensic community can agree on what a mobile forensic examiner could and should be able to do:

  • Minimum competency standards for different roles (for example, a “Triage Examiner” or “Smartphone Data Analyst”) can be agreed at an organisational level. If successful, this could be used to define a national competency standard within a particular country.
  • Job grading and pay scales can be aligned fairly with computer forensic examiners and the wider organisation. This lays the foundations for improved career progression opportunities within mobile forensics and reducing the costs of staff churn

Conclusions

This document has proposed a three level model to describe the role of a mobile forensic examiner. It is hoped that this can be used to enhance understanding of the role played by mobile examiners within an organisation, reduce staff churn and raise standards in mobile device forensics.

Further work is required to develop the model and feedback on it is welcomed via email to kevin.mansell@controlf.co.uk Updated versions of this document will be made available at www.controlf.net/downloads

Bibliography

Bloom, B. (1956). Taxonomy of Educational Objectives. Handbook 1: Cognitive Domain. Longman. Petty, G. (2004). Teaching Today – A Practical Guide. Nelson Thornes.

Mobile Telephone Examiner’s Conference, Blackpool

Kevin Mansell was invited to address over a hundred phone examiners from the law enforcement community at the Mobile Telephone Examiner’s Conference in February 2009. Kevin delivered a presentation titled ‘How Big Is Your Iceberg?’ which is now frequently referred to simply as ‘The Iceberg’ presentation.

Kevin suggested that the forensic examinations of electronic devices such as mobile phones are akin to icebergs.  What you can see “above the water line” may only really be a fraction of the potential evidence which can be recovered, and which may be relevant, to an investigation.

In his presentaion, Kevin explored what lies “under the water” and how the use of physical acquisitions (“hex dumps”) to retrieve deleted data, free software tools and knowledge of how mobile devices store data internally can radically enhance an investigator’s ability to retrieve key evidence.