Saturday, May 30, 2015


I haven't produced breakout web-links to the other forum discussions as this post is only raising a point about Metrology and standardisation in digital forensics.

A recent forum question posted by a PhD student sought ideas for a research area. I suggested the following:

You may wish to consider the process of:

(a) examination of mobile/feature/smart phones, embedded devices etc with respect to
(b) evidential examination aligned to iso17025 et al with specific attention interest and engagement to
(c) Metrology - tools used, processes in place and procedures followed
(d) to determine possible impact on evidential results and outcomes.

There is little published study in this area for digital forensics.

The above suggestion, along with suggestions made by others, produced a second forum thread specifically asking about standardisation in digital forensics testing and referred to my comments in the other forum thread. So I made further observations:

The reason why I mentioned Metrology is to actually see whether it is possible to have a minimum standard. In other words, start small and work in areas where commonality in agreement is high amongst those working in digital forensics.

Even before even writing test scripts or anything else start with e.g. the humble physical leads/cables and terminating plugs. They interface with the test tool and the target device. What forensics requirement should there be for these cables/leads/plugs e.g. VGA, DVI, HDMI, Ethernet etc etc. How many people keep a traceable record of what is being used to acquire evidence in the test lab.

iso9001 has been mentioned and this standard provides a useful guide on record keeping. In most cases user take for granted that the cable/lead/plug is ok and just swap it out if it is deemed not working? Simple questions:

1) Is there a cable/lead tester on the market?
2) What results can be obtained?
3) How to determine output results?
4) Compare manufacturing guidelines for MTTF and MTBF?
5) Can the results scrutinised be improved?
6) Can a minimum standard be achieved.

Mundane and tedious testing is never welcomed, but long before digital forensics raised its head these tests were going on. My own earlier experiences were in telecomms manufacturing. We worked with factory type approval guidelines BABT340 and iso9001. Record keeping and testing of tools was fundamental and mandatory to retain quality. Devices were subjected to standards such as bs6301, bs6305, bs6317, bs6789 etc. I still believe that BABT340 and other standards and guidelines for the manufacturing and supply of telecomms and datacomms products for placing on the marketplace are far more aligned to digital forensics and provide industry-specific stepping stones guidance towards minimum standards because all manufacturers were being channelled through the same process.

Just because some of the examples given by the above standards have been replaced with EU or other standards, doesn't mean to say we cannot learn from those industry-specific experience and adopt a similar system.

From what I see going on and hear from others in digital forensics labs cables/leads/plugs can be a source of problems in the acquisition process yet no common ground has been established for their use. There are ISO framework standards adopted for digital forensic labs, but those have been adopted after the fact of produced evidence. But what are the framework standards or common ground documentation directed towards the tools actually being used prior to acquisition and generation of evidence?

Knowing DUT memory

A newcomer to mobile phone examination asked a question on another forum:

"My first question is a general one: how can I know that the data I get in an extraction is everything that was on the device? For example, I recently acquired an image from a ZTE Z667G with prior knowledge that there were messages between 2 subjects using Facebook Messenger. The device was not able to be rooted with Oxygen's root exploit, so I used the Android backup method. When I began to analyze the data, I noted that Facebook messenger was not in the listed applications; also, none of the database files for that app were acquired. Had I not been told about the messages by the detective working that case, that data would have likely been missed. Without going through the device manually, how can I know for sure that what I'm getting is everything that is there?"

There is a temptation to reply with "try another tool". However, the opening question was "how can I know that the data I get in an extraction is everything that was on the device?", which suggests a knowledge of the memory where a mobile handset can store messages.

Knowing the memory available and areas where data maybe stored is another aspect an examiner may wish to consider as a planned exercise before commencing examination of the target DUT (device under test). As a simple exercise consider:

a) Handset memory
b) (U)SIM memory
c) SD card memory

Query: the examiner is interested to know the memory available in an e.g. Samsung Galaxy S6 edge (GSM)?

One popular website used by mobile phone examiners is Phonescoop:

The site identifies the following:

32 GB internal storage, raw hardware
23 GB internal storage, available to user
also available in 64 and 128 GB versions

SIM card size
Nano (4FF)

Is there any info that identifies whether an SD card may be used? Check for yourself at the link above.

The newcomer referred to the ZTE Z667G. Would this be the correct model at Phonescoop?

However, a Z667g user manual suggests a different name:

and another website identifies the Z667g under a different name:

Could that suggest variances between the different model names??

As an examiner can you verify or validate the accuracy of the Phonescoop details elsewhere?
e.g. are there any other website that may provide details? There are many, so here is another link:

Finally, what does the ZTE manufacturer website state about the ZTE Z667G?

There are a range of tools out there each to assist the examiner extract and harvest data; but be mindful, a tool may provide answers but a tool should not determine the questions and by extension think for you.