OPSEC question about killdisk and a cloned OS

I have an SSD running windows. It isn't the drive that came with the computer. I plan to Kill the drive with either killdisk or something similar in case it ever was taken for some reason. Now, if you clone the OS, that won't keep history, deleted files, etc, on the actual cloned system will it? The dban or kill disk will wipe everytthing like the MBR, etc. A clean install doesn't do that to my knowledge. So if I clone the OS to preserve my software and whatnot, then install it onto the drive that had dban or killdisk ran on it, what "stays" in terms of what can be recovered if it were taken by someone and examined (never think that could happen to me haha but never can be safe enough)? I would delete anything that I wouldn't want to be on a "cleaned" computer, then do the install. Is that terrible opsec or does killing the actual drive take care of all fuckery that may have been afoot?


Comments


[3 Points] TheDisapprovingBrit:

If you're paranoid enough to be using killdisk against it, is it really worth the risk of bringing stuff over to another drive from it? Just rebuild from scratch so you know you're safe.


[3 Points] TessellatedDirect:

Keep in mind that the internal controllers on SSD drives will retire memory if it shows a failure or too much use. They have extra built in so it just copies the data to another area then uses that. It does it all in such a way that the computer does not see it happening.

This means that even if you securely wipe the drive these retired memory areas will not be wiped. If they contained something sensitive it could be forensically recovered.

It would be a very difficult recovery though.


[1 Points] sapiophile:

It depends what you use to clone it. If you're using a low-level tool like dd or Ghost, then yes, the deleted data will still be present in the cloned drive.

I would suggest transferring the files directly instead of making a disk image, if this is what you need. The tool I'd recommend for this is rsync, but it may be difficult for someone who isn't very familiar with GNU/Linux and the command line - you'd want to use it from a Live GNU/Linux disc or flash drive (like Tails). Alternatively, you could just use the built-in Microsoft XCopy utility, or even back the data up over the network with FTP, SFTP, or similar.

Be aware of possible copy errors - I would strongly recommend using a tool that uses robust checksums, or generating separate checksums for the source and destination and then verifying them.