where to buy the ne...
 
Notifications
Clear all

where to buy the next box of HDDs?

31 Posts
10 Users
0 Likes
1,486 Views
CJ_Centeno
(@cj_centeno)
Posts: 6
Active Member
 

Thank You Bithead and Jhup for answering my question

 
Posted : 01/07/2012 7:58 am
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

Because lawyers tend to ask just the questions about things that is usually considered unnecessary.

It costs me only 15 minutes to kick off a wipe and hash of a target drive.

It would cost me hours of court time to explain why it is not necessary to wipe when using a container.

Sure, and you should also wear gloves and a gas mask when analyzing a hard disk, to be on the safe side, or even better build a "clean room" to avoid data contamination.

I do understand your practical approach ) , but it's exactly this kind of approach that dumbs down humanity, those who know how things work lower themselves to the level of those that don't know a s***t about them ( , and what starts as an urban myth becomes "accepted standard" or - worse - "compulsory procedure".

Be a man! wink
Fight for your beliefs! !

jaclaz

 
Posted : 01/07/2012 7:01 pm
mscotgrove
(@mscotgrove)
Posts: 933
Prominent Member
 

I very largely agree with Jaclaz.

The main area I feel has become a myth is that if there is a hash value, the answer is correct. In this example, I think a wipe is very valid, followed by a verify, but I do not understand the reason for a hash. Unless one has a table of hashes for every size of blank disk, it is just a long number with zero meaning

 
Posted : 01/07/2012 8:46 pm
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

The main area I feel has become a myth is that if there is a hash value, the answer is correct. In this example, I think a wipe is very valid, followed by a verify, but I do not understand the reason for a hash. Unless one has a table of hashes for every size of blank disk, it is just a long number with zero meaning

I am happy that you agree with me ) , but I am not sure to get it ? .

We do know (I hope) that when doing sector level copy there is no difference whatsoever between a stream of bytes (a whole disk cloned) written on a completely wiped hard disk or to a disk used till one minute before to hold the (say) your private collection of p0rn movies 😯 or the accounting data of your firm roll .

I mean, if you write 10,000,000 sectors, and you read them again, unless a write error occurred, whatever was there before is lost and the newly written 10,000,000 sectors are what you read (and the hashes of the sources and of the target are the same).

As I see it the same happens for a "container" like an Encase image.
The only possible issue I can see is the differences if you do a sector level copy of the "target" drive and the Encase image file is fragmented.
Then there would be a difference as in the wiped disks not used sectors will be all 00's whilst in the used and not sanitized hard disk they can be *whatever*, but still the image files will be identical and the hashes will match.

BUT JFYI, there is a little tool to calculate the hash of n 00ed files/sectors, maybe you missed it
http//www.forensicfocus.com/Forums/viewtopic/t=5077/postdays=0/postorder=asc/start=9/
http//www.edenprime.com/software/epAllZeroHashCalculator.htm

jaclaz

 
Posted : 01/07/2012 11:28 pm
mscotgrove
(@mscotgrove)
Posts: 933
Prominent Member
 

The issue we are discussing is wiping a new disk - before putting a container image file, or disk image on it. A hash of a file is useful, and a file may be an encase image. This will show that the file has not been changed.

The hash of a blank disk is to make sure that the disk does contain any previous information. I think it may be easier to explain to a judge that every sector was tested to make sure it was blank, rather than trying to explain that the disk had a hash value of 1234…. and you ran a program to determine a hash value for a disk of 345… sectors, and the hash values were the same. Surely the judge just wants to know that the disk was blank.

Keep it simple, a hash is not required.

 
Posted : 01/07/2012 11:57 pm
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

The issue we are discussing is wiping a new disk - before putting a container image file, or disk image on it. A hash of a file is useful, and a file may be an encase image. This will show that the file has not been changed.

The hash of a blank disk is to make sure that the disk does contain any previous information. I think it may be easier to explain to a judge that every sector was tested to make sure it was blank, rather than trying to explain that the disk had a hash value of 1234…. and you ran a program to determine a hash value for a disk of 345… sectors, and the hash values were the same. Surely the judge just wants to know that the disk was blank.

Keep it simple, a hash is not required.

Well, the point (at least mine) was that there is no need from a technical standpoint for the disk to be blank.

I am trying to say that if you paint your car with black, it becomes black, no matter if before it was white, red, yellow or sanded metal, the result you can see is anyway black.

I do understand that explaining this to a judge or to a lawyer will need more time than the time needed to always paint all cars white before painting 'em black, but still it makes no sense from a technical point of view.

jaclaz

 
Posted : 02/07/2012 12:35 am
Patrick4n6
(@patrick4n6)
Posts: 650
Honorable Member
 

The basis of the practice of wiping a destination drive comes from cloning rather than imaging. If you clone to a drive of a greater size than the original and then conduct an examination, if your software won't let you segment out just the cloned portion, you could potentially introduce elements from the end of the drive in much the same way that RAM slack can contain data other than the logical data. Thefore if your intention is to clone drives, you absolutely must wipe the destination clean and validate (generally with a zero checksum) prior to usage.

When imaging, this is generally not possible, however there are limited circumstances where a corrupted file table could point your software to some part of the disk outside of the logical image. Of course this would be captured in a post-hash, which is why hashing prior to finalising your examination should be done if you're choosing to not zero your destination drive, and should generally be done anyway.

That said, I never clone - unless I'm putting the clone back in the business computer and retaining the original - and yet I wipe every drive prior to imaging as a matter of course.

 
Posted : 02/07/2012 3:00 am
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

The basis of the practice of wiping a destination drive comes from cloning rather than imaging. If you clone to a drive of a greater size than the original and then conduct an examination, if your software won't let you segment out just the cloned portion, you could potentially introduce elements from the end of the drive in much the same way that RAM slack can contain data other than the logical data. Thefore if your intention is to clone drives, you absolutely must wipe the destination clean and validate (generally with a zero checksum) prior to usage.

Or zero out just the "excess space" …..
Using a zeroed out drive, IMHO makes a possible issue if the software used is not able to "segment" it.
I mean, by mistake it could come out (let's assume, as it normally happened with a "cylinder boundary respectful" partitioning that a bunch of sectors of the source drive, say 1500, are already 00 filled - as they are normally) that the examined space is larger than the source drive.
The report may by mistake take into account a number of 00ed sectors outside the original image.
If this is the case, it would make more sense to fill the disk with a special sector "pattern", so that the first instance of the pattern -1 marks the end of the cloned disk.

When imaging, this is generally not possible, however there are limited circumstances where a corrupted file table could point your software to some part of the disk outside of the logical image. Of course this would be captured in a post-hash, which is why hashing prior to finalising your examination should be done if you're choosing to not zero your destination drive, and should generally be done anyway.

Yes, this makes a lot of sense.

That said, I never clone - unless I'm putting the clone back in the business computer and retaining the original - and yet I wipe every drive prior to imaging as a matter of course.

Yes, but this is the same approach Jhup nicely explained before, prompted by "practical" reasons and not from "scientific" ones.

Since this thread - at least originally - is about "new" disks, there are three other questions that come to mind.
First one is, has anyone tried simply hashing the "brand new" disk (which by default should be all 00's) and compare it with the hash calculated ? (or if you prefer, has anyone checked that a brand new hard disk is all 00's)
Second one is, that IMHO the 00 wiping could be a valid "burn-in" test for a "brand new" disk drive, but for the same reasons, wouldn't writing a pattern to the new disk and veryfying it be a better test of the functioning of the drive?
Third one is - only indirectly related - what is the procedure when a disk is imaged or cloned onto a (new or old) hard disk, and everything verifies correctly, but, for any reason once you get to actually examine the disk it starts malfunctioning?

jaclaz

 
Posted : 02/07/2012 4:55 am
Patrick4n6
(@patrick4n6)
Posts: 650
Honorable Member
 

Second one is, that IMHO the 00 wiping could be a valid "burn-in" test for a "brand new" disk drive, but for the same reasons, wouldn't writing a pattern to the new disk and veryfying it be a better test of the functioning of the drive?
Third one is - only indirectly related - what is the procedure when a disk is imaged or cloned onto a (new or old) hard disk, and everything verifies correctly, but, for any reason once you get to actually examine the disk it starts malfunctioning?

jaclaz

The idea of using the zero as a burn in is also part of the philosophy of why I wipe every drive. I've only had 1 drive in 12 years fail during wipe, but that's still preferable to failing on-site, or even worse, failing after an on-site image.

As for verified on site but not during examination, I've always in my consultancy conducted examination on a copy of the image unless I'm retaining the original hard drive, and even then often so. This enables me to go back one step in the chain of evidence and create another working copy. Touch wood, this hasn't failed me yet, and I've never had an on-site image fail to verify during the creation of the working copy. Back when I worked in govt, we created a hash-verified archive of the image and if the image failed, we could go to that.

 
Posted : 02/07/2012 5:29 am
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

The idea of using the zero as a burn in is also part of the philosophy of why I wipe every drive. I've only had 1 drive in 12 years fail during wipe, but that's still preferable to failing on-site, or even worse, failing after an on-site image.

Very good ) .

Though the first question is less otiose than it seems, still on the validity of wiping or 00 writing as a burn-in test, and loosely connected to the recent ECC related thread (and actually more theory than anything 😯 )
http//www.forensicfocus.com/Forums/viewtopic/t=9325
IF the "brand" new drive is all 00's, all the ECC data will obviously be "00 related".
What happens if - for any reason - the drive is *somehow* defective - and fails in writing the ECC data?
You have ECC data relative to a 00 sector, and you actually write to that sector all 00's, the ECC won't change and if you verify/hash the disk everything looks OK.
Then you write something different from all 00's and the ECC is NOT updated, what will happen when you go and read that sector?
You get some kind of error.
So the burn-in by writing 00's seems far less effective than a burn-in writing random data or "patterns", doesn't it? ? .

jaclaz

 
Posted : 02/07/2012 6:10 am
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
Topic starter
 

You cannot have your cake and eat it too. mrgreen

I make a cost/benefit analysis depending on the case if I am going to do my full zeroing, and hashing.

You write that it is a waste and we should be able to explain it easily to the courts.

Now you are contesting exactly how the opposing counsel would dig into it.

I do not do it because it makes technical or forensics sense.

Just as you put a hole into the the ECC related issues, so will a good counsel if they perceive weakness, or have few other paths.

The idea of using the zero as a burn in is also part of the philosophy of why I wipe every drive. I've only had 1 drive in 12 years fail during wipe, but that's still preferable to failing on-site, or even worse, failing after an on-site image.

Very good ) .

Though the first question is less otiose than it seems, still on the validity of wiping or 00 writing as a burn-in test, and loosely connected to the recent ECC related thread (and actually more theory than anything 😯 )
http//www.forensicfocus.com/Forums/viewtopic/t=9325
IF the "brand" new drive is all 00's, all the ECC data will obviously be "00 related".
What happens if - for any reason - the drive is *somehow* defective - and fails in writing the ECC data?
You have ECC data relative to a 00 sector, and you actually write to that sector all 00's, the ECC won't change and if you verify/hash the disk everything looks OK.
Then you write something different from all 00's and the ECC is NOT updated, what will happen when you go and read that sector?
You get some kind of error.
So the burn-in by writing 00's seems far less effective than a burn-in writing random data or "patterns", doesn't it? ? .

jaclaz

 
Posted : 02/07/2012 9:24 pm
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

You cannot have your cake and eat it too. mrgreen

Sure, life is tough ( .

I make a cost/benefit analysis depending on the case if I am going to do my full zeroing, and hashing.

You write that it is a waste and we should be able to explain it easily to the courts.

Now you are contesting exactly how the opposing counsel would dig into it.

I do not do it because it makes technical or forensics sense.

Just as you put a hole into the the ECC related issues, so will a good counsel if they perceive weakness, or have few other paths.

Actually I am trying to separate the "practical" needs from the "theoretical" ones.

I never said (actually I said the opposite) that it would be easy to explain the matter to a court, I do perfectly understand that it would be difficult, and also said how I perfectly understand the "practical" approach, I was just pointing out how the practice is not dictated by "technical" or "forensics" science, but only as a "shortcut" (prompted by your cost/benefits analysis), I absolutely believe that if - by mistake or in an emergency of some kind - you will once forget or omit to do the 00 pass and the hashing, you will be able to explain to the court how this is "common practice" but not a "need" (at the cost of a few hours time) ) .

The ECC reasoning was only to point out how there is a (admittedly very remote) possibility that the wiping will not represent a valid burn-in of a brand new disk, of course as soon as you write to it some actual data, the issue will become evident as one will have every kind of ECC errors and the hash of the clone or image won't verify, and one will simply clone or image to another spare disk.

If you remember the good ol' times of floppy disks, the formatting wrote F6's…. wink

jaclaz

 
Posted : 02/07/2012 10:38 pm
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
Topic starter
 

You still do not get to eat your cake.

I think all the way to Win98, fdisk wrote F6's out too.

 
Posted : 03/07/2012 1:50 am
Patrick4n6
(@patrick4n6)
Posts: 650
Honorable Member
 

I think all the way to Win98, fdisk wrote F6's out too.

You're thinking of Format.

 
Posted : 03/07/2012 6:31 am
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
Topic starter
 

Nah, I might be wrong recalling but it seems to me fdisk in 98 used to write large chunks of F6 in some circumstances to partitions.

 
Posted : 03/07/2012 8:27 pm
Page 2 / 3
Share:
Share to...