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/
Showing posts with label verification. Show all posts
Showing posts with label verification. Show all posts
Sunday, April 15, 2012
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.
Subscribe to:
Posts (Atom)