Write Blocker for L...
 
Notifications
Clear all

Write Blocker for Linux flips upon encountering bad sectors

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

Wow,

Now it doesn't flips! Thanks!!

Sorry I am a noob in this area, just for clarification.

The new udev rule, actually checks whether the status changes and if it changes it will run the shell script which will reset the status to RO only? Am I right?

Am I write to say udev rules takes priority over changes initiated by kernel?

Thanks

 
Posted : 13/08/2015 1:03 pm
thefuf
(@thefuf)
Posts: 262
Reputable Member
 

The new udev rule, actually checks whether the status changes and if it changes it will run the shell script which will reset the status to RO only? Am I right?

Yes. And if you execute this rule before any other udev rule (like LVM or RAID activation rules), nothing bad will happen. That's why you need to prefix your rule with "01-". According to the man page of udev

The udev rules are read from the files located in the default rules
directory /lib/udev/rules.d/, the custom rules directory
/etc/udev/rules.d/ and the temporary rules directory
/run/udev/rules.d/. All rule files are collectively sorted and
processed in lexical order, regardless of the directories in which they
live. However, files in /etc/udev/rules.d/ take precedence over files
with the same name in /lib/udev/rules.d/; this can be used to ignore a
default rules file if needed.

Am I write to say udev rules takes priority over changes initiated by kernel?

The kernel marks a device and all its partitions as read-write and sends the uevent message to a userspace program (i.e. udev). This program finds out that the r/o status of a device was changed to 0 (r/w) and initiates the process of marking a device and all its partitions as read-only.

PS. Take a look at https://github.com/msuhanov/Linux-write-blocker

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

Thanks for the explanation!!

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

Hi,

But I noticed something by implementing this.

I tried to acquire using dc3dd command (with hash calculation) with the udev rules implemented from a disk that contains bad sectors.

Now it doesn't flips, but at the end of the process the hash doesn't match.

In the log file, it shows the input hash but for output hash it specify "Input/Output error".

Whereas when I set the source as RW and do acquisition, at the end of it the hash matches (both the input and output hash are the same).

Does this mean that when bad sector is encountered the system tries to set the the source as RW actually writes zeros into the bad sector and calculates the hash subsequently?

But now with udev rules in place which forces the source to be always RO, it cannot write zeros to the bad sectors thus subsequently it fails the hash calculation?

Thanks

 
Posted : 14/08/2015 10:47 pm
thefuf
(@thefuf)
Posts: 262
Reputable Member
 

Hi,

But I noticed something by implementing this.

I tried to acquire using dc3dd command (with hash calculation) with the udev rules implemented from a disk that contains bad sectors.

Now it doesn't flips, but at the end of the process the hash doesn't match.

In the log file, it shows the input hash but for output hash it specify "Input/Output error".

Whereas when I set the source as RW and do acquisition, at the end of it the hash matches (both the input and output hash are the same).

Does this mean that when bad sector is encountered the system tries to set the the source as RW actually writes zeros into the bad sector and calculates the hash subsequently?

But now with udev rules in place which forces the source to be always RO, it cannot write zeros to the bad sectors thus subsequently it fails the hash calculation?

Thanks

dc3dd is always replacing bad sectors with null bytes in-memory and in an output image (it can't just skip unreadable areas, because this will misalign partitions and file system data), dc3dd has zero knowledge about udev rules on a system and the write policy set on a drive being acquired should not change anything. And dc3dd is not expected to write anything to a source drive.

Please, do the following
1) install hashdeep (http//sourceforge.net/projects/hashdeep/);
2) run "hashdeep -p 512 -c md5 image-1.raw | cut -d ',' -f 2 > 1.txt" (where "image-1.raw" is an image file from the first acquisition, this will produce a huge output file);
3) run "hashdeep -p 512 -c md5 image-2.raw | cut -d ',' -f 2 > 2.txt" (where "image-2.raw" is an image file from the second acquisition);
4) run "diff 1.txt 2.txt > diff-1-2.txt";
5) paste the contents of the "diff-1-2.txt" file here, if it's not too large (but don't do this if you consider hashes of sectors to be private!).

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

Ok, managed to solve it.

My mistake, I actually got input error when calculating the hash. The issue is I was using md5sum to calculate the hash. Thus when it hits a bad sector, it throws a error.

When I used dc3dd to calculate the hash on the fly while acquiring, the hash matches. So the issue is not with the dc3dd command.

Thanks!!

 
Posted : 17/08/2015 10:02 am
Page 2 / 2
Share:
Share to...