write blocker or no...
 
Notifications
Clear all

write blocker or not?

18 Posts
12 Users
0 Reactions
3,141 Views
(@mansiu)
Trusted Member
Joined: 16 years ago
Posts: 83
 

In Windows I would always use a write blocker, but I do acquire using Linux distributions without a write blocker.

Thirded! Also the acquisition speed of a hard drive through a USB3 Sata dock is about 3 times the speed of acquisition through a writeblocker.

performance issue is not a strong supporting reason for not using a writeblocker

have you ever used a writeblocker with ESATA connector? i think it pretty much give you a native hard drive speed


   
ReplyQuote
minime2k9
(@minime2k9)
Honorable Member
Joined: 14 years ago
Posts: 481
 

In Windows I would always use a write blocker, but I do acquire using Linux distributions without a write blocker.

Thirded! Also the acquisition speed of a hard drive through a USB3 Sata dock is about 3 times the speed of acquisition through a writeblocker.

performance issue is not a strong supporting reason for not using a write-blocker

have you ever used a writeblocker with ESATA connector? i think it pretty much give you a native hard drive speed

Where do you work?! With the number of jobs we image a year its a very good reason, especially give the size of hard disks is on the rise.

I've yet to see a write-blocker on any connection, eSata, Firewire, USB (although not tried USB3 yet) get much above 20mbs, we easily get 50 - 60 mbs using Linux and a Sata USB 3 dock.
The only downside is that the Linux box needs to be configured properly to never mount disks.


   
ReplyQuote
(@mansiu)
Trusted Member
Joined: 16 years ago
Posts: 83
 

In Windows I would always use a write blocker, but I do acquire using Linux distributions without a write blocker.

Thirded! Also the acquisition speed of a hard drive through a USB3 Sata dock is about 3 times the speed of acquisition through a writeblocker.

performance issue is not a strong supporting reason for not using a write-blocker

have you ever used a writeblocker with ESATA connector? i think it pretty much give you a native hard drive speed

Where do you work?! With the number of jobs we image a year its a very good reason, especially give the size of hard disks is on the rise.

I've yet to see a write-blocker on any connection, eSata, Firewire, USB (although not tried USB3 yet) get much above 20mbs, we easily get 50 - 60 mbs using Linux and a Sata USB 3 dock.
The only downside is that the Linux box needs to be configured properly to never mount disks.

let me show you an acquisition log in one of my tests.

equipment used
Hard drive Kingspec SSD KSD-MS18.1-032MJ
WriteBlocker Tableau T3458is using SATA connection
Acquisition tool Tableau imager / E01 / default compression / 2GB chunk
PC Intel CPU Q9400, 8GB ram, Windows 7, WD 500GB OS, Seagate 1.5TB 7200rpm storage


-----------------------Start of Tableau Imager Log entry------------------------

Task Disk to File
Status Ok
Created Wed Jun 06 181821 2012
Started Wed Jun 06 181822 2012
Closed Wed Jun 06 182453 2012
Elapsed 7 min
User ivaN
Case ID <<not entered>>
Case Notes <<not entered>>

Imager App Tableau Imager
Imager Ver 1.11

--------------------------Source Disk---------------------------

Model KingSpec KSD-MS18.1-032MJ
S/N KSMS180000000440
Firmware Revision 100415
Capacity in bytes reported Pwr-ON 32,153,272,320 (32.1 GB)
Capacity in bytes reported by HPA 32,153,272,320 (32.1 GB)
Capacity in bytes reported by DCO 32,153,272,320 (32.1 GB)
HPA in use No
DCO in use No
ATA Security in use No
Cable/Interface type SATA
Blank check status Not Blank

----------------Forensic Bridge / Write-Blocker-----------------

Vendor Tableau
Model T3458is
Description T3458is Forensic Bridge
Serial number 000ecc34 0058104d
Bridge Access Mode Read-Only
Firmware build date Oct 6 2009
Firmware build time 151312

----------------------Disk-to-File Results----------------------

Output file format .e01/ewf
Compression Minimize Size
Chunk size in bytes 2,147,483,648 (2.1 GB)
Chunks written 2
Filename of first chunk j\kingspec.E01
Total errors 0
MD5 a1542f7f1912c4a8ab9b2079e8c7d7f6
SHA1 e53e8aca1f3922fae907535dfcb3f74626226cc0

------------------------End of Tableau Imager Log entry-------------------------

The acquisition speed is 78.42MByte/second. The SSD is not a beast in speed, i use that because it is small in size and good for testing purpose. Other equipment used are not top in class, just ordinary tools.


   
ReplyQuote
minime2k9
(@minime2k9)
Honorable Member
Joined: 14 years ago
Posts: 481
 

Yes 70mbs+ may be achievable when imaging a solid state drive, but I would expect through our system to double that easily (although not tested on SSD).
We are achieving the speed I stated with standard hard disks, which still make the vast majority of our suspect drives.


   
ReplyQuote
bshavers
(@bshavers)
Estimable Member
Joined: 20 years ago
Posts: 211
 

A common situation where individual hardware writeblocked speeds take a back seat is when you have more computers to image than you have writeblockers. Say you have a floor of workstations to image, or several floors in a massive collection. Unless you have a hardware write blocker and forensic laptop for every computer, or a hardware imager for every hard drive, it will be difficult to surpass the speed of booting all the systems to a forensic CD and let them image at the same time to an attached USB external drive.

And you have to include the time savings of not having to disassemble the computers and remove the hard drives to image, keeping track of dozens of loose hard drives, and the myriad of little problems when you are taking apart dozens of machines spread over several floors of a company.

I'm just saying…nothing wrong with booting to a forensically sound disc and nothing wrong with a hardware writeblocker. Time and place for everything.


   
ReplyQuote
(@mansiu)
Trusted Member
Joined: 16 years ago
Posts: 83
 

@bshavers, I understand your point and absolutely agree with you and I love your winfe project

but i just want to stay clear with my point of view in the previous post, "performance issue is not a good supporting reason"

@bshavers, in your case, it is really a limitation of lack of equipment and tools, so, go without writeblocker is acceptable

however, to the previous post which i replied to, minime2k9 stated that he has yet found a writeblocker with any connection can come up with a speed more than 20MB/s, that is what i want to clarify

In the last post, i posted the acquisition log for a SSD, this time, i found a log using a grandmather's hard drive, a WD 80GD IDE drive

Acquisition machine, same as the last one
Hard drive, WD 80GB IDE

-----------------------Start of Tableau Imager Log entry------------------------

Task Disk to File
Status Ok
Created Thu Mar 10 164230 2011
Started Thu Mar 10 164230 2011
Closed Thu Mar 10 171604 2011
Elapsed 34 min
User ivan
Case ID
elwood
Case Notes
elwood hard disk

Imager App Tableau Imager
Imager Ver 1.11

--------------------------Source Disk---------------------------

Model WDC WD800JB-00JJC0
S/N WD-WCAM9U076130
Firmware Revision 05.01C05
Capacity in bytes reported Pwr-ON 80,026,361,856 (80.0 GB)
Capacity in bytes reported by HPA 80,026,361,856 (80.0 GB)
Capacity in bytes reported by DCO 80,026,361,856 (80.0 GB)
HPA in use No
DCO in use No
ATA Security in use No
Cable/Interface type IDE
Blank check status Not Blank

----------------Forensic Bridge / Write-Blocker-----------------

Vendor Tableau
Model T3458is
Description T3458is Forensic Bridge
Serial number 000ecc34 0058104d
Bridge Access Mode Read-Only
Firmware build date Oct 6 2009
Firmware build time 151312

----------------------Disk-to-File Results----------------------

Output file format .e01/ewf
Compression Maximize Speed
Chunk size in bytes 2,147,483,648 (2.1 GB)
Chunks written 20
Filename of first chunk e\elwood.E01
Total errors 0
MD5 553763d50882f0e45bf86a00d5d24f9c
SHA1 54fd5ccf17b1e095020683fc750fe29da31de7e0

------------------------End of Tableau Imager Log entry-------------------------


the average speed of this acquisition is 39.7MB/s, I think it is pretty close to the native speed of the WD 80GB itself


   
ReplyQuote
(@twjolson)
Honorable Member
Joined: 17 years ago
Posts: 417
 

I agree. Software write blockers are less reliable than hardware ones. You never know when an update to Windows or a particular software could cause the registry tweak to not work properly.

To play devil's advocate

A hypothetical change that might occur one day, possibly, does not make them unreliable. Them working one day, then not working the next with no apparent cause, makes something unreliable.

The same could be said for hardware write blocking. How do you know you won't update the firmware someday, and it won't break? I believe that has occurred in the past, if memory serves me.

In the end, it doesn't matter which you use. Test them to make sure they work as advertised and use whatever makes you happy.


   
ReplyQuote
Beetle
(@beetle)
Reputable Member
Joined: 17 years ago
Posts: 318
 

In Windows I would always use a write blocker, but I do acquire using Linux distributions without a write blocker.

I second this.

Ditto that.


   
ReplyQuote
Page 2 / 2
Share: