Visitors to trewmte.blogspot.com may recall a discussion thread posted back in 2012 regarding a JTAG Tutorial http://trewmte.blogspot.co.uk/2012/09/jtag-tutorial.html. The purpose of that thread was to enable students, newcomers and experienced mobile/smart phone examiners to get a feel for JTAG before undertaking such examinations or purchasing tools etc.
Today, Kevin Swartz from www.nowsecure.com has released a FREE three-part training course specifically for JTAGing smart phones. Kevin has dropped a line to me saying "Hi Greg, yes, please feel free to link to any of our free resources pages: https://www.nowsecure.com/resources/".
The FREE three-part training course:
PDF Download: https://www.nowsecure.com/resources/jtag-forensics-training/
JTAG 101 videos:
https://www.youtube.com/playlist?list=PLkotz0CYBQDrXpvO0UZlmrUpQLtegPgWI
JTAG 102 videos:
https://www.youtube.com/playlist?list=PLkotz0CYBQDp_YMS_jMXSjKsvgWtL8e_p
Thanks Kevin. You're a decent chap for your kind gesture to help out students, newcomers and experienced examiners in the community.
Showing posts with label mobile phone examination. Show all posts
Showing posts with label mobile phone examination. Show all posts
Friday, April 10, 2015
Saturday, September 14, 2013
(U)SIM Examination (Physical) Pt1
(U)SIM Examination (Physical) Pt1
We begin with GSM as this is the original starting place where examiners first learned about subscriber identity modules (SIM). There are many ways to learn about SIM: using a SIM reader tool is one way, receiving instruction during training that concentrates on the types of user and network data that can be harvested by examiners. An education and training process can equally include a training module or modules on the physical aspects of a card and identify, for the examiner, material parts of the SIM, the known routes to understanding electrical aspects, processing aspects, storage geometry and memory mapping, so on and so forth. The thinking here is analogous to the way in which there is an expectation that a computer examiner would understand HDD disc geometry, clusters and sectors, BIOS etc even before entering into the search and study of the 'content' that may be recorded on the disc. It is or should be the same for (U)SIM.
The SIM Card can be seen as a composition of at least three constituent parts:
- The physical card (the storage carrier).
- An integrated circuit card micro-processing chip (the operating system and content storage device).
- The subscriber identity module; an area of physical memory allocated at manufacturing for pre-market and post-market recording by the mobile network operator and SIM user.
- A fourth constituent part could be a Card with an etched antenna for RFID/NFC for use by (US)SIM (but this part is not included or discussed at this stage).
- etc
To enable test and inspection of these constituent parts GSM approved and adopted GSM11.17 to assist manufacturers, operators and service providers help formalise and uniform the test and inspection procedures rather than have a mish-mash of randomly selected tests for SIM cards submitted for use in GSM. The former is highly desirable as the goal of GSM has always be about interconnection-compatiblity and interconnection backward-compatibility. By way of illustration, a GSM SIM Card Phase 1 should still be able to be inserted into a GSM Phase 2+ mobile device and allow communications to take place, unless the operator or device manufacturer has declared and stated otherwise.
From an examiner's viewpoint we would desire to know how those three constituent parts translate to the work we do? Some examples are set out below
Physical Card
Due to the form factors used in GSM we can make assessment to determine the supply chain and manufacturer of the card itself. We look at the card to see if has been cut down for use and any attempts of anonymity by removal of the SIM Serial Number (SSN) compared to manufacture polarisation techniques. Later 3G/LTE USIM Cards have undergone some changes since GSM's inception; the latter will be dealt at a later date.
Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module
ICC Chip
Manufacturer and technical specification are important to determine a range of potential evidence, including release into the marketplace and technological and electronic capability. Clearly the geometry and memory mapping are important. There are various techniques to deal with a card with a damaged chip. One example is called 'acid-etching' used to gain access to the physical chip itself by removal of the outer protective coverings used in the manufacturing process.
Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module
Physical Memory
Determining geometry and memory mapping forms part of the testing and inspection process set out in GSM1117. We can use these procedures to formulate a forensic analysis programme, similar to the way in which computer forensic examiners seek to determine specifically data discovered and recovered from a particular memory location on the HDD and define the data from its binary and encoded states and any formatting that may be applicable to the data. That being so, would it be out of the question in SIM examination terms for the EFBCCH file to be formatted as .bmp? Below are a set of powerpoint slides I have prepared so that examiners can comprehend procedures approved and adopted for test and inspection for GSM SIM Cards. Later on when we 3G/LTE (U)SIM this GSM starting point assists formulate how to identify differences between the various (U)SIM/LTE cards but equally identify expansion of technology services and content so the examination limit or avoid omissions during the investigative/evidential process.
We begin with GSM as this is the original starting place where examiners first learned about subscriber identity modules (SIM). There are many ways to learn about SIM: using a SIM reader tool is one way, receiving instruction during training that concentrates on the types of user and network data that can be harvested by examiners. An education and training process can equally include a training module or modules on the physical aspects of a card and identify, for the examiner, material parts of the SIM, the known routes to understanding electrical aspects, processing aspects, storage geometry and memory mapping, so on and so forth. The thinking here is analogous to the way in which there is an expectation that a computer examiner would understand HDD disc geometry, clusters and sectors, BIOS etc even before entering into the search and study of the 'content' that may be recorded on the disc. It is or should be the same for (U)SIM.
The SIM Card can be seen as a composition of at least three constituent parts:
- The physical card (the storage carrier).
- An integrated circuit card micro-processing chip (the operating system and content storage device).
- The subscriber identity module; an area of physical memory allocated at manufacturing for pre-market and post-market recording by the mobile network operator and SIM user.
- A fourth constituent part could be a Card with an etched antenna for RFID/NFC for use by (US)SIM (but this part is not included or discussed at this stage).
- etc
To enable test and inspection of these constituent parts GSM approved and adopted GSM11.17 to assist manufacturers, operators and service providers help formalise and uniform the test and inspection procedures rather than have a mish-mash of randomly selected tests for SIM cards submitted for use in GSM. The former is highly desirable as the goal of GSM has always be about interconnection-compatiblity and interconnection backward-compatibility. By way of illustration, a GSM SIM Card Phase 1 should still be able to be inserted into a GSM Phase 2+ mobile device and allow communications to take place, unless the operator or device manufacturer has declared and stated otherwise.
From an examiner's viewpoint we would desire to know how those three constituent parts translate to the work we do? Some examples are set out below
Physical Card
Due to the form factors used in GSM we can make assessment to determine the supply chain and manufacturer of the card itself. We look at the card to see if has been cut down for use and any attempts of anonymity by removal of the SIM Serial Number (SSN) compared to manufacture polarisation techniques. Later 3G/LTE USIM Cards have undergone some changes since GSM's inception; the latter will be dealt at a later date.
Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module
ICC Chip
Manufacturer and technical specification are important to determine a range of potential evidence, including release into the marketplace and technological and electronic capability. Clearly the geometry and memory mapping are important. There are various techniques to deal with a card with a damaged chip. One example is called 'acid-etching' used to gain access to the physical chip itself by removal of the outer protective coverings used in the manufacturing process.
Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module
Physical Memory
Determining geometry and memory mapping forms part of the testing and inspection process set out in GSM1117. We can use these procedures to formulate a forensic analysis programme, similar to the way in which computer forensic examiners seek to determine specifically data discovered and recovered from a particular memory location on the HDD and define the data from its binary and encoded states and any formatting that may be applicable to the data. That being so, would it be out of the question in SIM examination terms for the EFBCCH file to be formatted as .bmp? Below are a set of powerpoint slides I have prepared so that examiners can comprehend procedures approved and adopted for test and inspection for GSM SIM Cards. Later on when we 3G/LTE (U)SIM this GSM starting point assists formulate how to identify differences between the various (U)SIM/LTE cards but equally identify expansion of technology services and content so the examination limit or avoid omissions during the investigative/evidential process.
Sunday, May 19, 2013
Saturday, March 30, 2013
(U)SIM Examination (Physical) Pt1
(U)SIM Examination (Physical) Pt1
We begin with GSM as this is the original starting place where examiners first learned about subscriber identity modules (SIM). There are many ways to learn about SIM: using a SIM reader tool is one way, receiving instruction during training that concentrates on the types of user and network data that can be harvested by examiners. An education and training process can equally include a training module or modules on the physical aspects of a card and identify, for the examiner, material parts of the SIM, the known routes to understanding electrical aspects, processing aspects, storage geometry and memory mapping, so on and so forth. The thinking here is analogous to the way in which there is an expectation that a computer examiner would understand HDD disc geometry, clusters and sectors, BIOS etc even before entering into the search and study of the 'content' that may be recorded on the disc. It is or should be the same for (U)SIM.
The SIM Card can be seen as a composition of at least three constituent parts:
- The physical card (the storage carrier).
- An integrated circuit card micro-processing chip (the operating system and content storage device).
- The subscriber identity module; an area of physical memory allocated at manufacturing for pre-market and post-market recording by the mobile network operator and SIM user.
- A fourth constituent part could be a Card with an etched antenna for RFID/NFC for use by (US)SIM (but this part is not included or discussed at this stage).
- etc
To enable test and inspection of these constituent parts GSM approved and adopted GSM11.17 to assist manufacturers, operators and service providers help formalise and uniform the test and inspection procedures rather than have a mish-mash of randomly selected tests for SIM cards submitted for use in GSM. The former is highly desirable as the goal of GSM has always be about interconnection-compatiblity and interconnection backward-compatibility. By way of illustration, a GSM SIM Card Phase 1 should still be able to be inserted into a GSM Phase 2+ mobile device and allow communications to take place, unless the operator or device manufacturer has declared and stated otherwise.
From an examiner's viewpoint we would desire to know how those three constituent parts translate to the work we do? Some examples are set out below
Physical Card
Due to the form factors used in GSM we can make assessment to determine the supply chain and manufacturer of the card itself. We look at the card to see if has been cut down for use and any attempts of anonymity by removal of the SIM Serial Number (SSN) compared to manufacture polarisation techniques. Later 3G/LTE USIM Cards have undergone some changes since GSM's inception; the latter will be dealt at a later date.
Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module
ICC Chip
Manufacturer and technical specification are important to determine a range of potential evidence, including release into the marketplace and technological and electronic capability. Clearly the geometry and memory mapping are important. There are various techniques to deal with a card with a damaged chip. One example is called 'acid-etching' used to gain access to the physical chip itself by removal of the outer protective coverings used in the manufacturing process.
Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module
Physical Memory
Determining geometry and memory mapping forms part of the testing and inspection process set out in GSM1117. We can use these procedures to formulate a forensic analysis programme, similar to the way in which computer forensic examiners seek to determine specifically data discovered and recovered from a particular memory location on the HDD and define the data from its binary and encoded states and any formatting that may be applicable to the data. That being so, would it be out of the question in SIM examination terms for the EFBCCH file to be formatted as .bmp? Below are a set of powerpoint slides I have prepared so that examiners can comprehend procedures approved and adopted for test and inspection for GSM SIM Cards. Later on when we 3G/LTE (U)SIM this GSM starting point assists formulate how to identify differences between the various (U)SIM/LTE cards but equally identify expansion of technology services and content so the examination limit or avoid omissions during the investigative/evidential process.
We begin with GSM as this is the original starting place where examiners first learned about subscriber identity modules (SIM). There are many ways to learn about SIM: using a SIM reader tool is one way, receiving instruction during training that concentrates on the types of user and network data that can be harvested by examiners. An education and training process can equally include a training module or modules on the physical aspects of a card and identify, for the examiner, material parts of the SIM, the known routes to understanding electrical aspects, processing aspects, storage geometry and memory mapping, so on and so forth. The thinking here is analogous to the way in which there is an expectation that a computer examiner would understand HDD disc geometry, clusters and sectors, BIOS etc even before entering into the search and study of the 'content' that may be recorded on the disc. It is or should be the same for (U)SIM.
The SIM Card can be seen as a composition of at least three constituent parts:
- The physical card (the storage carrier).
- An integrated circuit card micro-processing chip (the operating system and content storage device).
- The subscriber identity module; an area of physical memory allocated at manufacturing for pre-market and post-market recording by the mobile network operator and SIM user.
- A fourth constituent part could be a Card with an etched antenna for RFID/NFC for use by (US)SIM (but this part is not included or discussed at this stage).
- etc
To enable test and inspection of these constituent parts GSM approved and adopted GSM11.17 to assist manufacturers, operators and service providers help formalise and uniform the test and inspection procedures rather than have a mish-mash of randomly selected tests for SIM cards submitted for use in GSM. The former is highly desirable as the goal of GSM has always be about interconnection-compatiblity and interconnection backward-compatibility. By way of illustration, a GSM SIM Card Phase 1 should still be able to be inserted into a GSM Phase 2+ mobile device and allow communications to take place, unless the operator or device manufacturer has declared and stated otherwise.
From an examiner's viewpoint we would desire to know how those three constituent parts translate to the work we do? Some examples are set out below
Physical Card
Due to the form factors used in GSM we can make assessment to determine the supply chain and manufacturer of the card itself. We look at the card to see if has been cut down for use and any attempts of anonymity by removal of the SIM Serial Number (SSN) compared to manufacture polarisation techniques. Later 3G/LTE USIM Cards have undergone some changes since GSM's inception; the latter will be dealt at a later date.
Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module
ICC Chip
Manufacturer and technical specification are important to determine a range of potential evidence, including release into the marketplace and technological and electronic capability. Clearly the geometry and memory mapping are important. There are various techniques to deal with a card with a damaged chip. One example is called 'acid-etching' used to gain access to the physical chip itself by removal of the outer protective coverings used in the manufacturing process.
Image courtesy of wikipedia - http://en.wikipedia.org/wiki/Subscriber_Identity_Module
Physical Memory
Determining geometry and memory mapping forms part of the testing and inspection process set out in GSM1117. We can use these procedures to formulate a forensic analysis programme, similar to the way in which computer forensic examiners seek to determine specifically data discovered and recovered from a particular memory location on the HDD and define the data from its binary and encoded states and any formatting that may be applicable to the data. That being so, would it be out of the question in SIM examination terms for the EFBCCH file to be formatted as .bmp? Below are a set of powerpoint slides I have prepared so that examiners can comprehend procedures approved and adopted for test and inspection for GSM SIM Cards. Later on when we 3G/LTE (U)SIM this GSM starting point assists formulate how to identify differences between the various (U)SIM/LTE cards but equally identify expansion of technology services and content so the examination limit or avoid omissions during the investigative/evidential process.
Tuesday, December 11, 2012
A European Focused Mobile Consumer Survey
A European Focused Mobile Consumer Survey
Informa Telecom and Media have published the results of their Smartphone Usage and Behaviour Survey 2012 conducting the survey in four european countries UK, Spain, Germany and the Netherlands http://www.informatandm.com/mobile-consumer-survey/ .
The results for the UK identified the brand of mobile phone owned in particular age groups.
The responses to the survey confirm that the smartphone market in the UK is segmented and therefore mobile operators attempting to forecast device usage and data/services activity may require enabling customers the selection and choice of a range of platforms to sink their teeth into optimising any consumer initiative to enable the growth of smartphones to continue.
For examiners the survey illustrates that predominantly the smartphones to be examined fall into a fairly small category, which could be quite useful for forecasting future examinations and, in particular, the expenditure on tools etc.
Informa Telecom and Media have published the results of their Smartphone Usage and Behaviour Survey 2012 conducting the survey in four european countries UK, Spain, Germany and the Netherlands http://www.informatandm.com/mobile-consumer-survey/ .
The results for the UK identified the brand of mobile phone owned in particular age groups.
The responses to the survey confirm that the smartphone market in the UK is segmented and therefore mobile operators attempting to forecast device usage and data/services activity may require enabling customers the selection and choice of a range of platforms to sink their teeth into optimising any consumer initiative to enable the growth of smartphones to continue.
For examiners the survey illustrates that predominantly the smartphones to be examined fall into a fairly small category, which could be quite useful for forecasting future examinations and, in particular, the expenditure on tools etc.
Sunday, October 14, 2012
To Clone or NOT to Clone?
The purpose of this article is to reiterate the issues surrounding the best practice model of the forensic examination/data harvesting of mobile telephones and the isolation of radio signals. It’s not the intention of the author to critique any persons/methods or vendors of products/services but merely to highlight the issues which are still apparent today considering such methods have been adopted for well over ten years in the field of mobile phone forensics and which in the opinion of the author are yet to be addressed to a satisfactory level.
Best practice advocates the need to isolate the target device from any communication signal in order to prevent changes in existing live/deleted recoverable data. Bearing this in mind the most common practice is to utilise U/SIM cloning tools and to replicate a working copy of the target U/SIM or in some cases creating a working U/SIM for those target devices where the original U/SIM is not available. The majority or most commonly adopted tools/applications for such a method will only permit the examiner to copy the minimal data required to allow successful boot which are the ICCID and IMSI in the main with the addition of other parameters such as the MNC. Although it may be regarded as best practice in the main it’s not without issue. From experience and review/re-examination of cold and live cases the same problems are encountered yet not addressed to a satisfactory level.
There are several vendors of such products and in the main they are adequate to a degree however some vendors of such products do not appear to continue with the product development cycle of such functions as one would expect. We see improvements and development with the core functions of mobile phone forensic applications and that is most welcomed however the basic fundamental process in this case cloning of the target U/SIM are left behind. Thus how is it possible to continue or improve upon a best practice model if the basic fundamental requirements are not addressed?
Examples where failings have been noted are listed below:
1. Misrepresentation of acquired/harvested data:
Quite often through examination it has been noted certain data types are not translated or presented in the correct format. For example contact names may be missing as they are contained within the ADN of the U/SIM card and due to the cloning system have not been transferred through which in turn is replicated to other data sets such as SMS and call list.
2. Inaccessible data
Situations have been encountered where data is not available via the GUI of the target device thus the possibility of missing or non-examination of data exists. An example of this was encountered whilst examining a BlackBerry Bold device where the BBM application was not available without the use of the original target U/SIM, the reason being that the application or some functions were tied to the SIM Application Toolkit.
The above examples are just the tip of the iceberg and in the opinion of the author there are certainly more issues encountered in the use of U/SIM cloning systems when examining mobile telephones and/or devices which utilise the use of U/SIM cards.
So how can we overcome such issues and improve upon the best practice model? One solution is total radio isolation and the use of the original target U/SIM i.e. faraday enclosures/rooms. Unfortunately this option is not a satisfactory way forward due to cost, health & safety issues, practicality and when dealing with volume work.
For a more practical and sustainable solution the author would suggest that the vendors of such products/services review their product development cycle, obtain and work with the necessary feedback from seasoned practitioners with a view to providing far more robust products/services which at best eliminate U/SIM cloning issues or which offers the examiner more flexibility as to the cloning parameters required or at least work towards providing bulletins of known issues and possible solutions for identified issues.
Author: Vinny Parmar
Digital Forensic Practitioner
Accredited MTEB Mobile Phone Trainer
Sunday, September 23, 2012
JTAG Tutorial
JTAG Tutorial
Certain mobile phones have no other access capability other than a test interface to allow for debugging and memory analysis capability other than to use JTAG (Joint Test Action Group) standard: IEEE 1149.1 : 1990 Standard Test Access Port and Boundary-Scan Architecture. IEEE 1149.1 : 2001 is available here: http://standards.ieee.org/findstds/standard/1149.1-2001.html
There are various reading materials available by way of the internet that help an examiner understand the way in which JTAG can be used:
http://www.corelis.com/education/JTAG_Tutorial.htm
What is JTAG?
Overview of the JTAG architecture and the new technology trends that make using JTAG essential for dramatically reducing development and production costs. The article also describes the various uses of JTAG and the tools available today for supporting JTAG technology.
Additional material: http://en.wikipedia.org/wiki/Joint_Test_Action_Group
What is JTAG?
Overview of the JTAG architecture and the new technology trends that make using JTAG essential for dramatically reducing development and production costs. The article also describes the various uses of JTAG and the tools available today for supporting JTAG technology.
Additional material: http://en.wikipedia.org/wiki/Joint_Test_Action_Group
Other materials that may interest:
Mobile Phone Chip Off - http://trewmte.blogspot.com/2011/02/mobile-phone-chip-off.html
Mobile device forensics - http://en.wikipedia.org/wiki/Mobile_device_forensics
JTAG acquisition from Android - http://www.caseite.com/content/jtag-acquisition-android
Is JTAG forensically approved? - http://www.forensicfocus.com/Forums/viewtopic/p=6533275/
Sunday, April 15, 2012
Examination Techniques8: Simple Experiments2
Examination Techniques8: Simple Experiments2
Continuing the discussion to offer suggestions on ways to generate test methodologies in order that down the line it might be possible to create validation and verification processes, practices and procedures for mobile phone examination (device under test (DUT)).
Assuming that an examiner is satisfied as to when s/he is using the appropriate tool that it will extract and harvest data from the make/model (DUT) under examination, there will still be the prior query what exactly is this tool communicating to the DUT? For instance, considering logical data as opposed to physical data, does the tool intended for use provide an "output log" that contains the communications (commands) sent to the DUT (e.g. APDU or AT+ etc etc) so that the examiner:
- can corroborate what is being instructed to the DUT when that tool is applied to it?
- comprehend are the responses (data) received from the DUT to be expected or are the data incomplete?
- Should the data be incomplete, is that because the commands are incorrect in their instructions which data are to be extracted or is it because the handset has not stored any further data other than that data returned in response to the command sent?
The objective of this simple experiment is to observe the content of any harvested logical data so that when dealing with physical (deleted) data recovery an examiner can start to build a template, from known logical data samplings, in order to apprehend some understanding of any deleted data that has been recovered as to what maybe there and what maybe missing.
Previous discussions relevant to this topic:
Examination Techniques6: Simple Experiments - http://trewmte.blogspot.co.uk/2012/03/examination-techniques6-simple.html
Examination Techniques5: Validation and Verification - http://trewmte.blogspot.co.uk/2012/03/examination-techniques5-validation-and.html
External links:
http://www.forensicfocus.com/Forums/viewtopic/t=8879/
Continuing the discussion to offer suggestions on ways to generate test methodologies in order that down the line it might be possible to create validation and verification processes, practices and procedures for mobile phone examination (device under test (DUT)).
Assuming that an examiner is satisfied as to when s/he is using the appropriate tool that it will extract and harvest data from the make/model (DUT) under examination, there will still be the prior query what exactly is this tool communicating to the DUT? For instance, considering logical data as opposed to physical data, does the tool intended for use provide an "output log" that contains the communications (commands) sent to the DUT (e.g. APDU or AT+ etc etc) so that the examiner:
- can corroborate what is being instructed to the DUT when that tool is applied to it?
- comprehend are the responses (data) received from the DUT to be expected or are the data incomplete?
- Should the data be incomplete, is that because the commands are incorrect in their instructions which data are to be extracted or is it because the handset has not stored any further data other than that data returned in response to the command sent?
The objective of this simple experiment is to observe the content of any harvested logical data so that when dealing with physical (deleted) data recovery an examiner can start to build a template, from known logical data samplings, in order to apprehend some understanding of any deleted data that has been recovered as to what maybe there and what maybe missing.
Previous discussions relevant to this topic:
Examination Techniques6: Simple Experiments - http://trewmte.blogspot.co.uk/2012/03/examination-techniques6-simple.html
Examination Techniques5: Validation and Verification - http://trewmte.blogspot.co.uk/2012/03/examination-techniques5-validation-and.html
External links:
http://www.forensicfocus.com/Forums/viewtopic/t=8879/
Saturday, March 31, 2012
Examination Techniques6: Simple Experiments
Examination Techniques6: Simple Experiments
Leaving validation to one side, when I am teaching mobile phone examination I get delegates on the course to try lower level tests, at first instance.
Try this experiment:
1) Conduct acquisition and harvesting of the handset's SMS text message logical data.
2) Produce a paper printout report of all those text messages (this will be one test guide).
3) Through the handset reading tool you are using display the text messages on the screen of your computer (this will be another test guide)
4) With the test handset switched ON view the text on the screen and take screen shots. The information in the screen shots should be as complete as that which can be viewed on the screen of the handset by the ordinary user (this will be yet another test guide).
The purpose of this experiment is, having cross-referenced all the three test guides, to see if they are, in the first instance, identical in every way? Moreover, can the tests be replicated by an examiner with the same system or another system?
Another simple experiment to consider:
To consider and, through trial and error, discover when would you apply a hash value?
Does your tool currently produce a hash displayed on the screen for each text message or are all of the saved text messages given a hash value?
Specifically, when your computer produces the output of data on to printed paper, is a hash value displayed (somewhere) and, if so, is the hash value the same as seen in the program on the computer screen or is it the hash value for the data that is actually printed on the paper (or would you need another value for that)?
With respect to the handset screen shots, would they need a hash value and would the hash value be created by the screen shot program for the images or the printed out data.
The purpose of this experiment is to identify exactly the relevance of hash values and to what they are being attributed, to what they technically prove (or who they exonerate), apart from having loads of hash values needing to be explained to a Court where the hash values do not exactly corroborate each other, but different things.
Now re-run the experiments with two different handset readers.
Previous discussions about some issues associated with validation and verification:
Leaving validation to one side, when I am teaching mobile phone examination I get delegates on the course to try lower level tests, at first instance.
Try this experiment:
1) Conduct acquisition and harvesting of the handset's SMS text message logical data.
2) Produce a paper printout report of all those text messages (this will be one test guide).
3) Through the handset reading tool you are using display the text messages on the screen of your computer (this will be another test guide)
4) With the test handset switched ON view the text on the screen and take screen shots. The information in the screen shots should be as complete as that which can be viewed on the screen of the handset by the ordinary user (this will be yet another test guide).
The purpose of this experiment is, having cross-referenced all the three test guides, to see if they are, in the first instance, identical in every way? Moreover, can the tests be replicated by an examiner with the same system or another system?
Another simple experiment to consider:
To consider and, through trial and error, discover when would you apply a hash value?
Does your tool currently produce a hash displayed on the screen for each text message or are all of the saved text messages given a hash value?
Specifically, when your computer produces the output of data on to printed paper, is a hash value displayed (somewhere) and, if so, is the hash value the same as seen in the program on the computer screen or is it the hash value for the data that is actually printed on the paper (or would you need another value for that)?
With respect to the handset screen shots, would they need a hash value and would the hash value be created by the screen shot program for the images or the printed out data.
The purpose of this experiment is to identify exactly the relevance of hash values and to what they are being attributed, to what they technically prove (or who they exonerate), apart from having loads of hash values needing to be explained to a Court where the hash values do not exactly corroborate each other, but different things.
Now re-run the experiments with two different handset readers.
Previous discussions about some issues associated with validation and verification:
Thursday, March 22, 2012
Examination Techniques5: Validation and Verification
Examination Techniques5: Validation and Verification
The constant and never ending challenge to ensure examination tools meets the requirements when used with or applied to the DUT (device under test) naturally generates constantly evolving polices, practices and procedures. The 'digitally-evolving' and 'technology-fast development' age has brought with it an inability to keep policies, practices and procedures up-to-date. That includes the tools and techniques that maybe used or applied.
Examiners may find it helpful when dealing with Validation and Verification:
- To validate is to assess doing the right things,
- To verify is to evaluate doing things right.
As always, Wikipedia has interesting articles and prompts that can help start researching points:
http://en.wikipedia.org/wiki/Verification_and_validation
However, a word of caution and a useful philosophical approach to remember, born out of having previously had experience and worked in QA, factory assessment/evaluation pre-approval and technology assessment. When considering Validation and Verification they hold the same unlying warning as that attributed to Galileo, who said "the Bible shows the way to go to heaven, not the way the heavens go". Thus agreeing that validation is being performed does not necessarily mean verification will automatically support that claim.
The constant and never ending challenge to ensure examination tools meets the requirements when used with or applied to the DUT (device under test) naturally generates constantly evolving polices, practices and procedures. The 'digitally-evolving' and 'technology-fast development' age has brought with it an inability to keep policies, practices and procedures up-to-date. That includes the tools and techniques that maybe used or applied.
Examiners may find it helpful when dealing with Validation and Verification:
- To validate is to assess doing the right things,
- To verify is to evaluate doing things right.
As always, Wikipedia has interesting articles and prompts that can help start researching points:
http://en.wikipedia.org/wiki/Verification_and_validation
However, a word of caution and a useful philosophical approach to remember, born out of having previously had experience and worked in QA, factory assessment/evaluation pre-approval and technology assessment. When considering Validation and Verification they hold the same unlying warning as that attributed to Galileo, who said "the Bible shows the way to go to heaven, not the way the heavens go". Thus agreeing that validation is being performed does not necessarily mean verification will automatically support that claim.
Sunday, March 18, 2012
Hashing Call Records
Hashing Call Records
Given the varying development of mobile phone forensics and evidence practices and procedures around the world, I have endeavoured to share my experiences, gained from more than two decades dealing with mobile telephone evidence. It is though a very difficult path to tread on the international stage largely because examiners may have developed their own theories as to how things should be done, others have developed products based upon their existing technical or commercial policies and yet a further influence is where practices and procedures are governed by local or countrywide rules or laws.
The purpose of enabling free participant enrolment into the Forum for The Mobile Telephone Examination Board (MTEB), set up on Linkedin, is exactly to deal with disparaties and to enable a worldwide audience to express views and opinions but confined to an audience in the same field of endeavour without the pressure from those trying to sell or market their services or wares to forum members.
Hashing of call records is one of those international topics that when, once discussion starts, it becomes apparent that depending on where the examiner is located particular requirements exist that are not relevant to the rest of the world. My response under these conditions is to try and show why I would or wouldn't use or apply a particular method without opining rules or requirement imposed on the way I would/should conduct examinations in my country.
In response to a recent question raised about Hashing of call records, I raised the following observations:
' The call records you receive from the operator are not 'the' original records, but copies of them (maybe?). An *assumption* might be the defence may request a copy direct from the operator in order to cross-reference that with the records you worked with and served.
That said, it may have good standing or be good practice to hash the inbound unopened electronic file from an operator (where the file extension is say .txt, .doc, .csv, .xls, .mdb and so on) at the outset if only to protect yourself, should you need to, to be able to provide some comfort to the Court or DA of "..this is the original file containing the copy records.....that I received from the operator....at the [sic] material time....before I started examination and analysis of the file's content....."
From previous experience:
1) For an appeal case I was instructed to examine a number of records from an operator's computer. In viewing the records, on first blush, there was 'disparity' and 'inconsistency' between the records served. Unless the operator's staff member randomly made selection and choice of content (fields of data), then the staff member was most likely directed by someone to provide content in the records presented. This led to questioning of 'who' 'what' 'where' and 'why'. This maybe relevant to the 'someone' who requests particular data, thus directing the staff member of what s/he wanted and, perhaps with good intention, but had guessed at what the fields of data actually meant and unilaterally decided what s/he thought was not relevant. Hashing a generated file where the content is directed to staff members seems to add little by way of supporting the accuracy of the meaning of the data, but just that data may not have been altered after hashing a received file.
2) A series of .xls spreadsheets served by the pros to the defence some of the spreadsheets contained cells that appeared to contain no data. However, when highlighting each cell call data could be seen in the 'formula bar' in excel relating to mobile calls. Mistakes by someone formatting the spreadsheet can happen, but it caused the defence a huge resource to cross-reference back to the paper records to understand why missing calls were occurring. An impact assessment on the hashing value needs to be considered before and after formatting.
3) An expert's word.doc report requested from the pros was emailed by the police, when it was learned the expert had sent it by email to the police because it was over 200 pages and megabytes in size. When opened, the word.doc displayed a range of corrections to 'words' and 'paragraphs' made by an individual (and not the expert's secretary etc) who was not the expert who produced the report. I sent screen shots to the defence of my findings and the defence checked with their copy of the same file sent to them. I do not know the outcome of that particular matter as my work finished on that particular part of evidence assessment. I suspect a hash value including the material time of receipt and prior to the file being examined might be useful if 'someone' is the person some way down the line.
4) Formatted (or non-formatted) files or content in files can be a pain at times and consideration of the value of obtaining a hash value can mean adopting a policy on a case by case basis. There are discussions about how certain types of formatting impact on data.
5) Having the original copy remaining intact and hashed and produce two working copies of the original may be useful.
Some other observations. Would you hash winrar, winzip files etc? Would that be for the similar reasons, as above, or would you not hash because compression is involved?
If the records are received in paper form, are you hashing the scan of each page or one hash of the entire scanned pages you generated?
I'm not suggesting your thoughts on hashing are wrong or right, merely I am raising some thoughts you may wish to consider how relevant they might be to your question; on the basis, of course, that you haven't already considered them previously. '
Clearly, whether an examiner must/shall, should/would, may/might apply hashing to a particular file seems to be optional, dependent on where the examiner is located.
I am glad, though, that this subject has been raised because it gives me the opportunity at long last to appropriately identify a new tool created by a professional examiner I know, Ted Smith, who works at Her Majesty's Revenue and Customs (HMRC). He has developed a tool called QuickHash ( http://sourceforge.net/projects/quickhash/ ) and is a free development, but Ted is seeking assistance from the community to test it and provide feedback to him. Ted sent an email to me saying: "I make these tools for use by the community so the more people that use them, the more worthwhile it is. If you do write about them, I’d appreciate a mail so I can go and have a read."
Perhaps readers would be generous and kind enough to send an email (trewmte@gmail.com), comments will be appropriately attributed to the author unless requested otherwise, and let us know if you feel this tool can be:
- Benchmarked
- Screencasts or screen shots of positive and negative findings
- Constructive criticism
My best wishes to you and many thanks.
Given the varying development of mobile phone forensics and evidence practices and procedures around the world, I have endeavoured to share my experiences, gained from more than two decades dealing with mobile telephone evidence. It is though a very difficult path to tread on the international stage largely because examiners may have developed their own theories as to how things should be done, others have developed products based upon their existing technical or commercial policies and yet a further influence is where practices and procedures are governed by local or countrywide rules or laws.
The purpose of enabling free participant enrolment into the Forum for The Mobile Telephone Examination Board (MTEB), set up on Linkedin, is exactly to deal with disparaties and to enable a worldwide audience to express views and opinions but confined to an audience in the same field of endeavour without the pressure from those trying to sell or market their services or wares to forum members.
Hashing of call records is one of those international topics that when, once discussion starts, it becomes apparent that depending on where the examiner is located particular requirements exist that are not relevant to the rest of the world. My response under these conditions is to try and show why I would or wouldn't use or apply a particular method without opining rules or requirement imposed on the way I would/should conduct examinations in my country.
In response to a recent question raised about Hashing of call records, I raised the following observations:
' The call records you receive from the operator are not 'the' original records, but copies of them (maybe?). An *assumption* might be the defence may request a copy direct from the operator in order to cross-reference that with the records you worked with and served.
That said, it may have good standing or be good practice to hash the inbound unopened electronic file from an operator (where the file extension is say .txt, .doc, .csv, .xls, .mdb and so on) at the outset if only to protect yourself, should you need to, to be able to provide some comfort to the Court or DA of "..this is the original file containing the copy records.....that I received from the operator....at the [sic] material time....before I started examination and analysis of the file's content....."
From previous experience:
1) For an appeal case I was instructed to examine a number of records from an operator's computer. In viewing the records, on first blush, there was 'disparity' and 'inconsistency' between the records served. Unless the operator's staff member randomly made selection and choice of content (fields of data), then the staff member was most likely directed by someone to provide content in the records presented. This led to questioning of 'who' 'what' 'where' and 'why'. This maybe relevant to the 'someone' who requests particular data, thus directing the staff member of what s/he wanted and, perhaps with good intention, but had guessed at what the fields of data actually meant and unilaterally decided what s/he thought was not relevant. Hashing a generated file where the content is directed to staff members seems to add little by way of supporting the accuracy of the meaning of the data, but just that data may not have been altered after hashing a received file.
2) A series of .xls spreadsheets served by the pros to the defence some of the spreadsheets contained cells that appeared to contain no data. However, when highlighting each cell call data could be seen in the 'formula bar' in excel relating to mobile calls. Mistakes by someone formatting the spreadsheet can happen, but it caused the defence a huge resource to cross-reference back to the paper records to understand why missing calls were occurring. An impact assessment on the hashing value needs to be considered before and after formatting.
3) An expert's word.doc report requested from the pros was emailed by the police, when it was learned the expert had sent it by email to the police because it was over 200 pages and megabytes in size. When opened, the word.doc displayed a range of corrections to 'words' and 'paragraphs' made by an individual (and not the expert's secretary etc) who was not the expert who produced the report. I sent screen shots to the defence of my findings and the defence checked with their copy of the same file sent to them. I do not know the outcome of that particular matter as my work finished on that particular part of evidence assessment. I suspect a hash value including the material time of receipt and prior to the file being examined might be useful if 'someone' is the person some way down the line.
4) Formatted (or non-formatted) files or content in files can be a pain at times and consideration of the value of obtaining a hash value can mean adopting a policy on a case by case basis. There are discussions about how certain types of formatting impact on data.
5) Having the original copy remaining intact and hashed and produce two working copies of the original may be useful.
Some other observations. Would you hash winrar, winzip files etc? Would that be for the similar reasons, as above, or would you not hash because compression is involved?
If the records are received in paper form, are you hashing the scan of each page or one hash of the entire scanned pages you generated?
I'm not suggesting your thoughts on hashing are wrong or right, merely I am raising some thoughts you may wish to consider how relevant they might be to your question; on the basis, of course, that you haven't already considered them previously. '
Clearly, whether an examiner must/shall, should/would, may/might apply hashing to a particular file seems to be optional, dependent on where the examiner is located.
Photo image from QuickHash courtesy of Ted Smith
I am glad, though, that this subject has been raised because it gives me the opportunity at long last to appropriately identify a new tool created by a professional examiner I know, Ted Smith, who works at Her Majesty's Revenue and Customs (HMRC). He has developed a tool called QuickHash ( http://sourceforge.net/projects/quickhash/ ) and is a free development, but Ted is seeking assistance from the community to test it and provide feedback to him. Ted sent an email to me saying: "I make these tools for use by the community so the more people that use them, the more worthwhile it is. If you do write about them, I’d appreciate a mail so I can go and have a read."
Perhaps readers would be generous and kind enough to send an email (trewmte@gmail.com), comments will be appropriately attributed to the author unless requested otherwise, and let us know if you feel this tool can be:
- Benchmarked
- Screencasts or screen shots of positive and negative findings
- Constructive criticism
My best wishes to you and many thanks.
Subscribe to:
Posts (Atom)