I have a bootable FreeBSD drive that I'm using to wipe the contents of a hard drive before donating the PC to my local thrift store. I'm using the following command to achieve this:
dd if=/dev/urandom of=/dev/[drivename] bs=64k
Let's say hypothetically the hard drive has either corrupt sectors or areas that are physically damaged. Would those sectors be overwritten with the above command? Or would it be possible to still extract data from the sectors that are damaged or that are corrupt?
This a type of question that depends on point of view:
At some point a damaged sector can not be read from or written to. But a hard drive is designed with the idea that bad sectors can happen at some point.
This would have consequences if there wasn't a mechanism in place to deal with such sectors: Assume the sector at LBA address turs bad, we'd all of a sudden have a hole in our sequential LBA address space. To counter this hard drives maintain a pool of spare sectors. Once the hard drive discovered the sector at LBA 100 for example has issues, it can remap LBA 100 to a spare sector and take the original sector out of commission.
So, no you will not be able to write to LBA 100, that is the original sector, however since the drive will map LBA address to a spare sector you can write to LBA 100 after all. So it will appear you can write to the sector as long as the drive has spare sectors available while you're in fact writing to a different physical sector.
There's a few conditions that will trigger the drive to deal with a bad sector:
This drive has already been reallocating sectors and there's also pending sectors. Pending sectors will go away if you write to them:
About recovering data, or extracting as you say, data from bad sectors:
The best 'tool' to get data from bad sectors is the hard drive itself. If a drive can not read a sector it will apply all sorts of error recovery tricks without you even having to ask for it. This can take as much time as 20 seconds per sector. It's why people often complain about 'unstable' drives being slow; the drive is simply trying very hard to recover the data from a problematic sector.
Software specialized in recovery of data from such sectors can only do a few things:
EDIT: If this is about overwriting data and hitting a bad sector, same mechanisms apply:
If drive discovers a bad sector during the wipe it will be reallocated. Some may argue this is unsafe, or a possible attack vector since the original sector is taken out of commission and thus is not overwritten.
However recovery is unlikely:
If the drive supports enhanced erase then that would be your best option to securely erase all sectors, including the ones already reallocated.
To a large extent, the question depends on whether "bad" means that the operating system has marked it as such, or whether the drive's firmware considers it unusable.
In the first case, a lower-level tool might be able to overwrite it.
In the second, the bad area has been marked as unusable and possibly been replaced from a reserve pool, these are firmware operations and there's a real possibility that the "bad" area cannot be overwritten except using a special hardware tool.
If the entire storage area has not been wiped and reformatted at the hardware level, it is likely that a determined and well-funded adversary could recover information from it. Historically, top-level forensic equipment could recover traces of the original data even after a hardware wipe since there were residual traces of the clock/data transitions visible as very faint analogue signals.
Operations at the firmware or OS levels will not prevent that.
Ultimately, the only way to wipe a drive is with a hammer and a furnace.
As I am not sure about the behaviour in one setting the following cases apply:
SSD
There is no fixed mapping between the sector(s) that you are trying to erase and the flash block(s) that is used to store the content of those sector(s).
As flash blocks have a limited lifetime in terms of write cycles the firmware of the SSD has to remap flash blocks once they have reached their end of life. This remap operation is not an accident, it is part of regular wear treatment. This aging or wear process is reflected in the change of certain SMART attributes depending on the manufacturer. After remapping you can't reach those sectors anymore by means of your operating system. Specialized tools seem to be able to do that, though.
The anti-forensic splitter in the LUKS encryption system was built to counter such effects.
HDD
The mapping between sector numbers and physical sectors is typically static with the exception of errors that seem to occur at the end of life of the HDD. Pending sectors seem to rise like the volume of an avalanche. The remapping of pending sectors triggered by a write operation to a pending (unreadable) sector makes this sector unavailable to the operating system. Look at the RAW figure for the reallocated sector count (SMART attribute) to determine the extent of what became unaccessible for you.
What I can't tell is if a write operation to a pending sector will trigger a last write attempt to this sector (which might result in a write success) or if the sector will be immediately remapped.
Conclusion
Remapping prevents your erasing efforts for both HDDs and SSDs but remapping is differently distributed over time. The SMART "reallocated sectors" attribute is common for HDDs. You can use it to evaluate how many sectors have become unavailable for overwriting and act accordingly. Given the way of operation of SSDs I would rather physically destroy them than rely on overwriting their content with random data or zeros.
Short answer: yes, it is good idea to fill the drive with zeroes or random numbers before selling, giving away or re-purposing.
Even better would be to fill the drive with known data and then verify if it reads correctly. The badblocks tool has write/wipe mode for such task:
badblocks -w /dev/disk/by-id/ata-MNFCR-MODEL_SERIANO (tip: do not bother with /dev/sd? files, do address drives within /dev/disk/by-id/ to avoid any confusion). It will write four patters to ensure all the bits on the drive are able to change. The last pattern is 0x00 which is convenient. One can sped up the test by specifying only one pattern using -t 0. As a nice side effect you're also testing your cables and IO controller which can be faulty too.
Alternative way is to make the drive to wipe and check itself on its own, using ATA Secure Erase and then SMART Long Self Test. The advantage is that you're not utilizing OS's resources.
Sometimes data on a HDD becomes unreadable not because of physical surface failure but because of improper writing due to random power surge or something. Writing over those sectors fully restores it.
badblocks -wsv ..., -sv shows progress and more verbose.
The old school answer would be "yes, that is how you tell drive firmware to remap the sector and replace it with a good spare sector".
The even older schooler answer would be "no, you will have to tell your disk controller/operating system to do this remapping" (this does not apply to any hard drives you will find today outside of hard core retrocomputing contexts).
The new school answer would be "if bad sectors cause enough upset to make it through the drive firmware's mitigations, unless you are SURE of the cause, consider the drive bad - there is too much of a risk that whatever created any new bad sectors after the time of manufacturing checkout will create more (eg contamination in the drive, or even worse a domino effect going on), outweighing replacement cost). Also there could be performance degradation if a lot of remapped sectors cause a lot of additional seeks (which are extremely expensive on spinning hard drives).
For an SSD, the linux command blkdiscard can tell the disk to drop it's complete contents. This is a good, secure way of wiping a SSD that doesn't require overwriting, AND will hit all the "inactive" and "spare" blocks, as well as any blocks already marked as "bad"
And its very quick too, at 10-20 seconds.
Downside, this doesn't work for a spinning hard drive, and you need to boot off some other disk.
An overwrite, as per your example won't touch the spare/inactive/bad blocks and in theory the content could be extracted later. The likelyhood of secrets being revealed is low, but not zero so paranoia is reasonable here.
