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:

http://www.trewmte.blogspot.co.uk/2012/03/examination-techniques5-validation-and.html

http://trewmte.blogspot.co.uk/2010/06/evidence-and-admissibility-part-1.html

http://trewmte.blogspot.co.uk/2008/12/nokia-6233-clock.html

http://trewmte.blogspot.co.uk/2008/11/mobile-phones-and-fringe-coverage.html

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.

Archived Data

Archived Data

In the UK, the operators tend to vary their approach to data retention made available to law enforcement and data subjects running between weeks and a couple of years. However, data retention governed by the Directive and Legislation may go beyond that period, for instance in commercial disputes.

There are many confusing and contradicting issues associated with retention of mobile call information. The legislation appears to create a brickwall blocking unnecessary data retention. Under analysis exclusions or argumentative approaches are revealed that can give the impression that the brickwall has so many holes that it appears to have more holes than a Jeyes Cloth (J-Cloth).

For instance, the operator can give to law enforcement a Gold Copy of the records - a suggestion of the title that it contains everything, but can actually mean it is the only copy remaining. However, given the original raw data may still be with the operator, then what do all these rules really mean?

Law enforcement keep data records for considerably longer than is perceived, but that seems rather obvious when considering 'cold case' reviews.

Solicitors keep records for years in case there is an Appeal/dispute.

Both the Data Protection Act 1998 and 1984 contain requirements associated with 'processed data' and the legal position regarding a processed state and, thus, data rention periods. However, raw data that is untreated is not subject to the DPA in the same way and therefore in a raw data state may remain for many years in an unprocessed state in archive. National Security therefore could have access to archived raw data processed years after the archive was first made, but equally in a processed state data can linger on than most specified periods.

Preservation is not new of course and historically some, prior to digital archiving, had their records recorded to microfiche and as banking records were important some used inventive methods to preserve material and purchased old mines and stored their data in micorfiche format deep in the vaults of the earth in order to main a cold temperature, which if temperature increased (heat) it degraded preservation of the microfiche material. Some figures for storage were 90 years, particularly health and safety records for employees who may have been exposed to working where pervasive toxic conditions existed but weren't fully recognised at the material times.

Digital archiving today uses a range of storage media from optical disks to various data storage containment. It has been said that because of the recording properties of a SIM card data can be retained on a SIM card without degradation for upto 100 years; 50 years may be good though. So SIM maybe used under certain conditions for archive.

For mixed principles of data retention timescales the following provides useful guidance:

<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>

DIRECTIVE 2006/24/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 15 March 2006
on the retention of data generated or processed in connection with the provision of publicly
available electronic communications services or of public communications networks and amending
Directive 2002/58/EC
Article 6
Periods of retention
Member States shall ensure that the categories of data specified in
Article 5 are retained for periods of not less than six months and
not more than two years from the date of the communication.

Download: tinyurl.com/83mjky9

<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>

Directive 2002/58/EC of the European Parliament and of the Council
of 12 July 2002
concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications)
(23) Confidentiality of communications should also be ensured in the course of lawful business practice. Where necessary and legally authorised, communications can be recorded for the purpose of providing evidence of a commercial transaction. Directive 95/46/EC applies to such processing. Parties to the communications should be informed prior to the recording about the recording, its purpose and the duration of its storage. The recorded communication should be erased as soon as possible and in any case at the latest by the end of the period during which the transaction can be lawfully challenged.

[Note: retention of data for commercial disputes is considered to be custom and trade, and this can be equivalent to six years]

weblink: eur-lex.europa.eu/LexU...058:en:NOT

<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>

Anti-terrorism, Crime and Security Act 2001
102 to 105 Codes and agreements about the retention of communications data

[Note allows for retention periods longer than Directive on privacy and electronic communications and the Data Protection Act (http://www.legislation.gov.uk/ukpga/1998/29/contents)

weblink: www.legislation.gov.uk...24/part/11

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.

 

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.