Thanks for those who have taken the Survey for Digital Forensics Tool Testing so far. For those who haven't taken the 4-mins survey which only has 15 easy to read questions to answer, please do so ( digital-forensics-tool-testing.html ). The larger the pool of anonymous answers being returned to the Faculty of Computer Science University of Sunderland for Dr. Graeme Horsman to analyse the better the feedback to you and the digital forensics community, as a whole, will be when Graeme publishes the findings.
Below are two youtube videos. Watch them both as they provide an interesting account of removing iPhone 5 ICs. These are general repair services for iPhone and not promoted as forensic chip off. In particular, pay attention to whether there are any good working practices and whether the operator's manner is acceptable for handling an exhibit?
Three observations I will share are (1) should the operator be wearing anti-static glovers?; (2) how would you keep contemporaneous notes (CN) simultaneously whilst removing a chip?; and (3) should you be testing chip off tools to understand their limitations before using them for chip removal and chip reading?
Please use weblinks
https://www.youtube.com/embed/jePWDxec9J0
https://www.youtube.com/embed/r5pC6zVMgSo
Investigations, Practices and Procedures: Seizure-Forensic Examination-Evidence. Cellular and Satellite Telephones, Call Records-Billing Data, Cell Site Analysis. Telecomms. Computer and Network Analysis. GPS devices & Jammers, Cyber, IoT forensics.
Showing posts with label procedures. Show all posts
Showing posts with label procedures. Show all posts
Sunday, May 28, 2017
Saturday, March 19, 2016
Emergency Cases - Smartphone Examination
Capturing the target subject's smartphone activities is not as easy as is thought, as we are all finding out with the current Apple and law enforcement debacle. The Apple case though is not the norm as the two opposing sides are fighting about the "right to access". The public are engaged with this story that continues to unfold as to what "Privacy" actual means, should terrorism enjoy the comfort of privacy and so on. However, there is a sub-text going on here (as well) concerning examination procedures for smartphones and methodology in emergency cases. Having been involved with mobile phone evidence in criminal and civil proceedings for over 30-years I can tell you it isn't as easy at all.
Consider the current Apple case (and the articles still keep coming) and mistakes that are said to have occurred. The - TECH INSIDER - reported (http://www.techinsider.io/apple-the-fbi-screwed-up-san-bernardino-investigation-2016-2)
"The fact that the password was reset means that Apple was unable to retrieve info from the iPhone's unencrypted iCloud backup like it has for past investigations, according to reporters Apple spoke with. If the password hadn't somehow been reset while in law enforcement custody, the FBI likely wouldn't need Apple to create a tool that lets it brute force hack the iPhone's lock screen passcode and gain access to the device's encrypted contents."
It is the words "password hadn't somehow" that has significance for me because in those words it doesn't take account of the intense situation people are operating under, speed of investigation operations, timescales, prevention for potential further attacks and pressure to resolve the case etc. So the sub-text here is learning from adverse outcomes in emergency cases. Put on hold demands for back-door access as the golden cure because, in itself, it is not. There can be a plethora of superlative elements that will be sifted, considered and discarded where found not to be relevant. For elements that may be relevant they still need to be sifted, considered and conceptualised.
From a range of materials I use in my training courses I use the following which I originated back in 2006 (and I published it back in 2010).
Primer(C now) = Point in time and Space (which is a constant reference point) in the present tense when the examiner is contacted for an investigation and from which the examiner uses to look back in time at and into the future regarding mobile telephone evidence.
.
(T) = Time is the timeline, limited by how far the examiner can see into the past and future based upon discovery.
.
(S) = Space is the space line that is used as a constant reference point from which all other events occurring in space can be considered based upon discovery (seizure of device, chain of custody of an exhibit etc)
.
(F) = Future relates to things that have yet to happen (future events). This is based upon things that maybe discovered from the time the examiner is contacted
.
(F d) = F d represents, as far as possible, thus not set to a specific period of time, how far into the future the examiner can identify events beyond which no further discovery is possible.
.
(PU usage) = Past User usage (below Blue line represents past recorded events, and below the red dotted line events unfolding during and after investigation)
.
(PR usage) = Past Record usage (below Blue line represents past recorded events, and below the red dotted line events unfolding during and after investigation)
The proposition in Smith Diag 1 is intended to represent, by use of visualization, how mobile telephone usage can be investigated. The diagram tests your powers of observation and, more importantly, your depth of knowledge. So do not be fooled by what you believe to be my poor graphics skills. I deliberately intended that (PU usage) area to be shown larger than the (PR usage) area in order to suggest more data may be found in the mobile telephone than maybe obtained from the network records. That is because not all activity on a mobile telephone leads to activity in the radio and fixed mobile network. Network records are not limited to billing records therefore issues associated with cell site analysis also need to be considered. It does not automatically follow there shall be parity between data obtained from the mobile telephone and the network records and vice versa. The diagram below (Smith Diag 2) represents a number of suggested data elements commonly arising during an investigation.
The third diagram (Smith Diag 3) uses the classic representation of Time (T) and Space (S). Use of a Time line may be obvious but the Space line may not be so obvious. The point of using Space is as a determinate for e.g. the seized exhibit in the examiner's possession. Let's say the examiner receives the mobile telephone exhibit on the 30th March 2008 at 3.00pm. The exhibit was seized 10th March 2008 at 11.00am. So, the examiner has two facts to work with (a) the exhibit in the laboratory (in time and space) and (b) the exhibit seized at a location from premises or person (in time and space).. So at the point the examiner has initial Contact (C now) with the exhibit then past events can now start to be determined. By way of illustration, following examination let’s say the examiner finds that the data recovered from the device reveals activity not connected with Space where the mobile telephone was seized at (b). Space would therefore be highly relevant, because (i) the examiner would need to demonstrate that as a fact and (ii) to demonstrate the separation in Space between each of the locations (a) laboratory, (b) the seizure, and the intervening factor between (a) and (b). This may be supported, for instance, by the last location and frequency details stored on the SIM card or may be the handset has GPS or one of the smartphone mapping system that might be set to automatic logging.
Have a go at designing one of these diagrams and show how you would handle the Apple phone (in this case) - the seizure and examination procedure. Just as a heads up F d is intended to represent a text message in the future that has been sent but not yet delivered to the target's handset. So how would you know if a text message is pending and who would you have to cooperate with to get that information (and the text content too)?
Hope this helps.
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, November 15, 2009
Iphone jailbreak hack
Iphone jailbreak hack
.Just in case some are unaware.
.
http://blog.intego.com/2009/11/11/intego-security-memo-hacker-tool-copies-personal-info-from-iphones/
.
and also at
.
http://www.theregister.co.uk/2009/11/11/iphone_hacking_tool/
.
Perhaps a point examiners may consider useful and that is what polices, practices and procedures do you have in place where:
.
a) you jailbreak and breach the digital signature of the handset to get inside?
b) the handset is already jailbroken (so to speak)?
c) the handset is already jailbroken and carries the hack code?
Subscribe to:
Posts (Atom)


