Write Blocker for L...
 
Notifications
Clear all

Write Blocker for Linux flips upon encountering bad sectors  

Page 1 / 2
  RSS
aandroidtest
(@aandroidtest)
Junior Member

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

Quote
Posted : 05/08/2015 7:37 am
twjolson
(@twjolson)
Active Member

Where did you hear that dc3dd acts like this?

ReplyQuote
Posted : 05/08/2015 8:26 am
aandroidtest
(@aandroidtest)
Junior 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.

ReplyQuote
Posted : 05/08/2015 8:28 am
athulin
(@athulin)
Community Legend

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.

ReplyQuote
Posted : 05/08/2015 8:12 pm
thefuf
(@thefuf)
Active 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?

ReplyQuote
Posted : 05/08/2015 8:46 pm
aandroidtest
(@aandroidtest)
Junior 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!!

ReplyQuote
Posted : 06/08/2015 7:44 am
thefuf
(@thefuf)
Active 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?

ReplyQuote
Posted : 06/08/2015 3:39 pm
aandroidtest
(@aandroidtest)
Junior 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?

ReplyQuote
Posted : 11/08/2015 7:32 am
thefuf
(@thefuf)
Active 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.

ReplyQuote
Posted : 11/08/2015 2:15 pm
aandroidtest
(@aandroidtest)
Junior Member

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

ReplyQuote
Posted : 12/08/2015 12:55 pm
thefuf
(@thefuf)
Active Member

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

Okay, thank you. Does this failing drive have a partition table (i.e. do you see /dev/sdb1 after attaching the drive and before trying to image it)? Is this a SATA or PATA drive?

ReplyQuote
Posted : 12/08/2015 3:22 pm
aandroidtest
(@aandroidtest)
Junior Member

Hi,

Yah can see the partitions and it is a SATA disk.

Regards

ReplyQuote
Posted : 12/08/2015 3:59 pm
thefuf
(@thefuf)
Active Member

The problem is in the kernel, not in the udev. My guess is that the kernel is revalidating the device on I/O error, thus resetting its r/o flag to zero. I think we can fix this, but I need you to do the following first

1. Run "sudo udevadm monitor –property >> log.txt".
2. Reproduce the issue again.
3. Open the "log.txt" file in text editor and search for any lines starting with "DISK_RO=". Do you see them?

ReplyQuote
Posted : 12/08/2015 7:28 pm
aandroidtest
(@aandroidtest)
Junior Member

Hi,

Yes I Could see it. Twice

DISK_RO=0
DISK_RO=0

I also tested in the newly released Kali Linux 2.0, seems to have the same flipping occurrence. As you have mentioned could be the kernel issue.

Regards.

ReplyQuote
Posted : 13/08/2015 8:49 am
thefuf
(@thefuf)
Active Member

Hi,

Yes I Could see it. Twice

DISK_RO=0
DISK_RO=0

I also tested in the newly released Kali Linux 2.0, seems to have the same flipping occurrence. As you have mentioned could be the kernel issue.

Regards.

1. Place this to /usr/sbin/wrtblk-ioerr
#!/bin/sh

# Mark a specified block device as read-only
[ $# -eq 1 ] || exit
[ ! -z "$1" ] || exit
bdev="$1"
[ -b "/dev/$bdev" ] || exit
[ ! -z ${bdev##loop*} ] || exit
blockdev --setro "/dev/$bdev" || logger "wrtblk blockdev --setro /dev/$bdev failed!"

# Mark all child block devices as read-only
syspath=$(echo /sys/block/"$bdev"/*/dev)
[ "$syspath" = "/sys/block/"$bdev"/*/dev" ] && exit
for child in $syspath; do
dir=${child%/*}
partition=${dir##*/}
[ -b "/dev/$partition" ] || continue
blockdev --setro "/dev/$partition" || logger "wrtblk blockdev --setro /dev/$partition failed!"
done

2. Make this file executable "chmod +x /urs/sbin/wrtblk-ioerr".
3. Add the following line to your udev rule
ACTION=="change", SUBSYSTEM=="block", KERNEL!="ram*", ENV{DISK_RO}=="0", RUN+="/usr/sbin/wrtblk-ioerr %k"
4. Try to reproduce the issue again.

ReplyQuote
Posted : 13/08/2015 12:30 pm
Page 1 / 2
Share: