Write Blocker for L...
 
Notifications
Clear all

Write Blocker for Linux flips upon encountering bad sectors

21 Posts
4 Users
0 Likes
1,279 Views
aandroidtest
(@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 7:37 am
twjolson
(@twjolson)
Posts: 416
Reputable Member
 

Where did you hear that dc3dd acts like this?

 
Posted : 05/08/2015 8:26 am
aandroidtest
(@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 8:28 am
athulin
(@athulin)
Posts: 1141
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 8:12 pm
thefuf
(@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 8:46 pm
aandroidtest
(@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 7:44 am
thefuf
(@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 3:39 pm
aandroidtest
(@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 7:32 am
thefuf
(@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 2:15 pm
aandroidtest
(@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 12:55 pm
thefuf
(@thefuf)
Posts: 262
Reputable 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?

 
Posted : 12/08/2015 3:22 pm
aandroidtest
(@aandroidtest)
Posts: 29
Eminent Member
Topic starter
 

Hi,

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

Regards

 
Posted : 12/08/2015 3:59 pm
thefuf
(@thefuf)
Posts: 262
Reputable 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?

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

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.

 
Posted : 13/08/2015 8:49 am
thefuf
(@thefuf)
Posts: 262
Reputable 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.

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