Write Blocker for L...
 
Notifications
Clear all

Write Blocker for Linux flips upon encountering bad sectors

21 Posts
4 Users
0 Likes
1,927 Views
(@aandroidtest)
Posts: 29
Eminent Member
Topic starter
 

Hi All,

Let's say for acquisition, "dc3dd" command is used and in the Linux system write blocker is implemented using udev rules.

Now I noticed that when dc3dd encounters a bad sector it flips the "acquiring" device from read only into read/write and tries to recover the bad sector and subsequently uses zero as the value for hash calculation.

Is it possible to prevent this occurrence? Is there any way it can be specified so that when bad sector is encountered, skip that sector and for hash calculation do not include that sector?

Thanks In Advance

 
Posted : 05/08/2015 6:37 am
(@twjolson)
Posts: 417
Honorable Member
 

Where did you hear that dc3dd acts like this?

 
Posted : 05/08/2015 7:26 am
(@aandroidtest)
Posts: 29
Eminent Member
Topic starter
 

I tested it.

When running dc3dd I watched the read write status using, "watch -n 0 blockdev –getro /dev/sdb"
and when bad sector was encountered it changed from 1 to 0.

 
Posted : 05/08/2015 7:28 am
(@athulin)
Posts: 1156
Noble Member
 

Is it possible to prevent this occurrence? Is there any way it can be specified so that when bad sector is encountered, skip that sector and for hash calculation do not include that sector?

rec=off stops dc3dd from writing bad sectors, but my impression is that it also forces dc3dd to stop when a bad sector is encountered.

There may be something to be done with the phod= , but I can't say for sure, not having tried it.

For an authoritative answer, however, you better ask in the dc3dd support forum.

Now I noticed that when dc3dd encounters a bad sector it flips the "acquiring" device from read only into read/write and …

That sounds doubtful. What exact udev rules are in force here? Exact command line? What other imaging tools have you tried (I assume you have tried at least one other, and that it didn't display this behaviour) ?

Seems more probable that the operating system is responsible for that.

 
Posted : 05/08/2015 7:12 pm
(@thefuf)
Posts: 262
Reputable Member
 

I tested it.

When running dc3dd I watched the read write status using, "watch -n 0 blockdev –getro /dev/sdb"
and when bad sector was encountered it changed from 1 to 0.

That doesn't sound like a dc3dd problem.

Sometimes an attempt to read from a bad sector results in a device being reset. This means a block device disappears from a system and then comes back. Do you see any errors in the blockdev output? Do you see the read-only flag being set again after a few seconds?

 
Posted : 05/08/2015 7:46 pm
(@aandroidtest)
Posts: 29
Eminent Member
Topic starter
 

I am using the following udev rule

SUBSYSTEM=="block", KERNEL!="ram*", ACTION!="change", RUN+="/sbin/hdparm -r1 $tempnode"

I actually tried dd, dcfldd, and guymager too. As mentioned above, i think the issue could be the OS and not the forensic software.

Kernel patch to disable read/write permanently could be the last resort i guess!!

 
Posted : 06/08/2015 6:44 am
(@thefuf)
Posts: 262
Reputable Member
 

I am using the following udev rule

SUBSYSTEM=="block", KERNEL!="ram*", ACTION!="change", RUN+="/sbin/hdparm -r1 $tempnode"

I actually tried dd, dcfldd, and guymager too. As mentioned above, i think the issue could be the OS and not the forensic software.

Kernel patch to disable read/write permanently could be the last resort i guess!!

Do you see any errors in the blockdev output (when you execute it via the watch command)? Do you see the read-only flag being set again after a few seconds? What happens when you change $tempnode to %k in the udev rule above?

 
Posted : 06/08/2015 2:39 pm
(@aandroidtest)
Posts: 29
Eminent Member
Topic starter
 

Hi,

Nope didn't see any error in blockdev.

And no difference when I change $tempnode to %k.

I also tried to lower the number of the udev rule. e.g. 01-writeblocker.rules

No difference too. Is there any other way to ensure udev rules is not overridden?

 
Posted : 11/08/2015 6:32 am
(@thefuf)
Posts: 262
Reputable Member
 

Hi,

Nope didn't see any error in blockdev.

And no difference when I change $tempnode to %k.

I also tried to lower the number of the udev rule. e.g. 01-writeblocker.rules

No difference too. Is there any other way to ensure udev rules is not overridden?

Can you run "sudo udevadm monitor" in another terminal and reproduce the problem? And then paste the output of that command together with the output of "dmesg | tail" here.

 
Posted : 11/08/2015 1:15 pm
(@aandroidtest)
Posts: 29
Eminent Member
Topic starter
 

Hi,

I ran "sudo udevadm monitor", got the following

KERNEL[439.808031] change /devices/pci000000/0000001f.2/ata6/host6/target600/6000/block/sdb (block)

UDEV[439.833507] change /devices/pci000000/0000001f.2/ata6/host6/target600/6000/block/sdb (block)

For "dmesg | tail", got the following

Sense Key Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex)
72 03 …………….
sd 6000 [sdb]
Add. Sense Unrecovered read error - auto reallocate failed
sd 6000 [sdb] CDB
Read(10) 28…………….
end_request I/O error, dev sdb, sector 40010
ata6 EH complete

 
Posted : 12/08/2015 11:55 am
Page 1 / 3
Share: