Florian Specker wrote:
did you consider the possibility that the bad sector was not caused by
the rootkit? It's not uncommon that a disc contains bad sectors, which
you only remark when you actually read such a sector (or the whole disc,
e.g. dd it to another disc).
Bad blocks are detected on reads, but only remapped on write (and only
then if the write initially fails).
If a write failure is passed through to the OS, then the disc has run
out of 'spare' reserved blocks for remapping, and the drive should be
retired immediately (the S.M.A.R.T. metrics should reflect this fact).
If, however, the drive passes through a _read_ error to the OS, it's
possible (highly likely, even) to put things right by writing to that
block (e.g. running badblocks in write-test mode, using a sector editor,
dd'ing the entire drive or partition, or deleting the file that occupies
the block in question, then immediately filling the filesystem with a
dummy file). If the block is able to be remapped, then it *is* safe to
use. If anyone's throwing away drives on the first read error, then I'll
be happy to receive them, test them and use them for a few more years. I
have personally forced drives to remap failed blocks using the
techniques described above, and the discs are still reliable years
later. :-)
As an aside, I run badblocks in write-test mode before partitioning and
formatting in order to a) give the discs a soak test and b) attempt to
force marginal blocks to be remapped /before/ they're storing real data.
Try to low-level format the disc after investigating the incident.
Modern discs should not, and indeed, cannot be low-level formatted. The
best you can do is 'dd if=/dev/zero ...' them, or issue an ATA/SCSI
FORMAT_UNIT command.
Another possibility is some SMART-related function, but that is pure
speculation, as I don't know too much about these features.
Some of the S.M.A.R.T. metrics may only be valid if you regularly run
the S.M.A.R.T. self-tests.
Finally, once Linux is running, the BIOS cannot write-protect blocks.
Cheers & good luck cleaning up,
Florian
Best Regards,
Alex.
--
Alex Butcher: Security & Integrity, Personal Computer Systems Group
Information Systems and Computing GPG Key ID: F9B27DC9
GPG Fingerprint: D62A DD83 A0B8 D174 49C4 2849 832D 6C72 F9B2 7DC9
