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.

 
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.

No comments: