±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36231
New Yesterday: 4 Visitors: 155

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

Forensic PC anti-contamination procedures

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2, 3, 4, 5  Next 
  

Jonathan
Senior Member
 

Re: Forensic PC anti-contamination procedures

Post Posted: Aug 24, 09 23:06

Some excellent points Sean, and almost enough to make me change my 'wiping is unnecessary' stance!

In my jurisdiction (England, Wales & Northern Ireland) there are no accepted standards for how a computer forensic analyst should work; there are certainly guidelines and suggestions from ACPO but as far as I can see, they don't cover the topic of wiping drives before using them to store images on. So any methodology must come down to the analyst themselves, based on their experience and knowledge. To the best of my knowledge there has never been a case of one forensic image 'contaminating' another forensic image and altering its contents. I would also be happy to say to a court that with the combination of software, hardware and checks which I use it would in fact not be possible without some error being reported.

From a practical viewpoint, would your view preclude storing more than one image on a drive? If you're out on site with some 1TB disks and the PCs you're imaging are all 80GB would it be just one 80GB image per terabyte disk? Some places work with images stored on shared NASs/SANs and this too would be brought in to question too if we were to let mischievous lawyers influence our practices.

Am actually prepping for an imaging job at the moment; I'm taking several 750GB WD Green drives which were factory sealed when I opened them earlier - could it be argues that I've contaminated them already by putting FTK Imager Lite, a volatile data collector batch file I put together and my standard folder hierarchy on to them?

Finally, it's not possible to prove that the section of the drive your image is on was wiped prior to acquisition. In a Devil's advocate type of way, what's the practical difference between wiping a drive and saying that you've wiped the drive?
_________________
Forensic Control
twitter.com/ForensicControl
St Bride Foundation, 14 Bride Lane, London, EC4Y 8EQ 
 
  

seanmcl
Senior Member
 

Re: Forensic PC anti-contamination procedures

Post Posted: Aug 24, 09 23:38

Johnathan:

Good points. Allow me to clarify. Whenever I create a new work/storage environment using a new or previously used drive, I sterilize it first. In fact, as I close cases and back up data, I make it a point to sterize my work disks, mark them as such, and put them into storage for future use.

As you noted, it is hard to get over the counter drives under a few hundred Gbytes (which is why I have saved drives over the years), but it would be a waste to store an 80Gbyte image on a 1 TB disk with nothing else on it. As long as the drive was sterilized prior to my saving the image to it, as long as it has remained in my possession, and as long as I can verify the hash of the image against the source, I am not concerned about storing multiple images on a single drive.

I always sterilize a drive before doing a restore to it and although it is unnecessary, I always sterilize a drive before using it as a clone though the clone should overwrite the existing data and I set the rest of the drive to be wiped with a pattern that I use to indicate that I have wiped it and not that it was factory configured. Again, since I do this in my spare time and keep these in stock, it isn't a big deal.

I make it a practice to use evidence drives for evidence, only. My case files, programs, OS, etc., all reside on separate drives. This is in case I should find, for example, CP on an evidence file and need to turn the drive over to the Feds, which has happened.

I agree with other posters that the hash of the evidence file should be enough to demonstrate that it has not been contaminated and I also acknowledge that given the rapid evolution of NAS, SANS and high density drives, it is impractical for most offices to follow a one evidence drive for one source drive philosophy but I try to avoid setting myself up for questions related to contamination for the reasons already noted.

I also make sure that my TEMP and other file space is not located on my OS disk. Certain programs (FTK comes to mind), can actually extract viruses into the user's temporary space during case processing so, when the program allows, I reset the configurable storage locations to other than the program or user drives.

Still, I weigh practicality against the absolute need. My goal is not to be religious about what I do, but to consider my actions in terms of where it may expose me or my clients to avoidable controversy. Sometimes it is inevitable but I prefer to avoid it if all that it requires is a simple extra step.

As for your last question, I have found a great deal a variability in the contents of UA in OEM, factory refurbished and new drives which means that I cannot always say what was on the drive before I used it. That is why I use my own pattern for wiping which is also why I couldn't, easily, say that I did wipe it when I didn't (although, as a practical point, I could always apply the pattern to the UA after adding the evidence to the drive).

Also, I try to read all of the literature (when I can), especially the parts with which I disagree, so that if I am asked a question about why I did or did not do A because it was recommended by B, I already have thought up an answer. That isn't as tedious as it sounds (although if any famous forensic authors ever come over to my house for dinner, I'll have to make sure to move the books back from the WC to the bookshelves). Wink  
 
  

jamie
Site Admin
 

Re: Forensic PC anti-contamination procedures

Post Posted: Aug 25, 09 01:30

Contamination and the courtroom aside, are there not also important data security issues to consider? If sensitive data is somewhere it no longer needs to be, as may be the case with an unwiped drive, surely that raises issues of unauthorised access (loss, theft, even internal authorization issues) which proper sanitization procedures would eliminate?

Jamie  
 
  

Patrick4n6
Senior Member
 

Re: Forensic PC anti-contamination procedures

Post Posted: Aug 25, 09 05:39

Semi-offtopic, but in response to Sean's post about using a non-standard pattern. It was somewhat of a joke in my old agency, that if we were ever required to wipe and return a hard drive on a contraband possession case, we'd wipe it with the 4 character repeating string "dope".

Allow me to demonstrate what this looks like:

dopedopedopedopedopedopedopedopedopedopedopedopedopedopedope
dopedopedopedopedopedopedopedopedopedopedopedopedopedopedope
dopedopedopedopedopedopedopedopedopedopedopedopedopedopedope
dopedopedopedopedopedopedopedopedopedopedopedopedopedopedope
dopedopedopedopedopedopedopedopedopedopedopedopedopedopedope
_________________
Tony Patrick, B. Inf Tech, CFCE
www.patrickcomputerfor...s.com/blog
www.twitter.com/Patrick4n6 
 
  

Fab4
Senior Member
 

Re: Forensic PC anti-contamination procedures

Post Posted: Aug 27, 09 18:44

- pwakely
The specific term "CRC32" is sometimes used to mean 'any' 32-bit CRC (as there are many), but is also used to refer to the specific 32-bit CRC used in PkZip as well as other applications. This has a non-zero IV, and as such does not produce a zero output for all-zero data. If you wish to perform an all zero check using a CRC, you would therefore need to ensure you are using a CRC designed with that in mind (which is uncommon for the reasons mentioned above); Typically a "checkZero(data,len)" function would also be lower computation.


Phil or anyone else,

Does anyone use a CRC that provides a zero hash value for a zero'd drive?  
 
  

Patrick4n6
Senior Member
 

Re: Forensic PC anti-contamination procedures

Post Posted: Aug 27, 09 21:56

I use CRC64 to verify zero all the time, and I know that IACIS teaches the use of CRC to verify zero, so I expect it has wide usage.

The processing overhead of calculating a CRC on a drive is negligible. I use a 4 year old computer for this purpose, and I'm still getting speeds approaching the expected max read speeds for the given drives, i.e. 80+MB/s average read speed on newer drives.
_________________
Tony Patrick, B. Inf Tech, CFCE
www.patrickcomputerfor...s.com/blog
www.twitter.com/Patrick4n6 
 
  

pwakely
Member
 

Re: Forensic PC anti-contamination procedures

Post Posted: Aug 28, 09 11:47

- Fab4

Phil or anyone else,

Does anyone use a CRC that provides a zero hash value for a zero'd drive?

I dont.

If you wanted to use a CRC for this purpose, any CRC with a zero initial vector and zero output hash should be suitable (see table at homepages.tesco.net/~r...alogue.htm ). There aren't many, for the reasons described earlier (for most CRC uses you want different lengths of all-zero to produce different results).

It's interesting to consider this in light of the "theatre" discussion in this thread. If you're going to trust software to perform this check for you, performing the CRC has no additional benefit than direct testing that the values are all zero. However since the CRCs are 'standard', software performing this algorithm may be somehow deemed to be a more formal test than an 'all zero' check, even though it just wasted clock cycles in reality.


I use CRC64 to verify zero all the time, and I know that IACIS teaches the use of CRC to verify zero, so I expect it has wide usage.

Very interesting; I wonder whether this has becomes 'standard practise' in their teaching because of the availability of CRC checking software vs all-zero checking software (CRC64 is one of the few CRCs with the right property for this purpose). Certainly the computation complexity of CRC calculation is so low that it's not a problem to perform it, but since the purpose here is an all zero check I'm suprised this would be selected as the method of choice unless there were some other pragmatic reason (e.g. prior to using MD5/SHA-1/etc the full drive could have been being tested the check when full of data that it had not changed using a CRC in software, and then the same CRC software was used to check the all zero, perhaps?).

Phil.  
 

Page 4 of 5
Page Previous  1, 2, 3, 4, 5  Next