Looking for Hard Drive Utility To Provide Proof Of Wipe
I have a current opportunity in my hands based on a automated hard drive wiper i made with basic bash and udev commands. One of the requirements i must fulfill is to provide proof that the hard drives have been wiped.
Are there any open source utilities that can get this job done? I need to be able to add the data in a 1 line item. Here is an example of my automated hard drive log. The columns did not like my copy and past -.- Drive# Date/Time DriveLetter Temp Health TMP Model Serial MB 1 2018/07/10-18:08:31 /dev/sdf 18 ? 45317 ST31500341AS 9VS0GWB6 1430799 2 2018/07/10-18:36:16 /dev/sdam 20 ? 13277 WDC_WD3200AAJS-08L7A0 WD-WCAV2V120105 305245 3 2018/07/10-19:55:58 /dev/sdk 20 100 26131 SEAGATE_ST600MP0005 S7M0T0JY 572325 4 2018/07/10-19:55:59 /dev/sdh 20 100 26129 SEAGATE_ST600MM0088 S420NL4F 572325 5 2018/07/10-19:55:59 /dev/sdj 20 100 26131 SEAGATE_ST600MP0005 S7M0SV5L 572325 6 2018/07/10-19:55:59 /dev/sdp 21 100 27733 SEAGATE_ST600MM0088 S42017MJ 572325 7 2018/07/10-19:55:59 /dev/sdx 20 100 26129 SEAGATE_ST600MM0088 S420NKH1 572325 8 2018/07/10-19:56:14 /dev/sdac 19 100 24927 SEAGATE_ST600MM0088 S420MF1Y 572325 9 2018/07/10-19:56:14 /dev/sdy 19 100 26103 SEAGATE_ST600MM0088 S420NP2T 572325 10 2018/07/10-19:56:19 /dev/sdaf 20 100 26706 SEAGATE_ST600MM0088 S4202HV2 572325 11 2018/07/10-19:56:22 /dev/sdae ? ? 4920872 SanDisk_LT0200MO 423466960000ags/T43P 190782 12 2018/07/10-19:56:57 /dev/sdai 19 100 24879 SEAGATE_ST600MP0005 S7M0RNTJ 572325 13 2018/07/10-19:56:57 /dev/sdt 20 100 26131 SEAGATE_ST600MP0005 S7M0T09M 572325 14 2018/07/10-19:57:02 /dev/sdal 20 100 26131 SEAGATE_ST600MP0005 S7M0T0AH 572325 15 2018/07/10-19:57:22 /dev/sdam 20 100 26103 SEAGATE_ST600MM0088 S420NNRQ 572325 16 2018/07/10-19:57:31 /dev/sdan 19 100 26131 SEAGATE_ST600MP0005 S7M0SXEM 572325 17 2018/07/10-19:58:04 /dev/sdap 20 100 26131 SEAGATE_ST600MP0005 S7M0SV6L 572325 18 2018/07/10-20:02:59 /dev/sdw 21 100 24948 SEAGATE_ST600MM0088 S420MEP0 572325 19 2018/07/10-20:03:15 /dev/sdaq 21 100 27733 SEAGATE_ST600MM0088 S4108C4N 572325 20 2018/07/10-20:20:58 /dev/sdat 20 100 47429 WDC_WD2500AAKX-753CA1 WD-WMAYW2921274 238475 21 2018/07/17-19:25:19 /dev/sdd 23 100 20481 WDC_WD3200AZKX-00D6NA0 WD-WMC1S0595773 305245 22 2018/07/17-19:28:08 /dev/sdg 24 100 27988 ST3160815AS 6RX2DKVY 152628 23 2018/07/17-19:29:40 /dev/sdh 23 100 54406 WDC_WD2500AAJS-75M0A0 WD-WMAV2EA74134 238419 24 2018/07/17-19:32:45 /dev/sdi 22 100 55228 ST3250312AS 5VY64PWR 238475 25 2018/07/17-19:37:11 /dev/sdj 22 100 45709 ST250DM000-1BD141 9VYLX0E2 238475 26 2018/07/17-19:37:37 /dev/sdk 22 100 9887 ST250DM000-1BD141 Z6E8KXEE 238475 27 2018/07/17-19:39:29 /dev/sdl 24 100 25166 ST500DM002-1BD142 Z6E43PS0 476940 28 2018/07/17-19:41:21 /dev/sdm 23 100 7085 WDC_WD10EACS-00ZJB0 WD-WCASJ0367212 953870 29 2018/07/17-19:56:32 /dev/sdo 24 6 65279 ST31500341AS 9VS0PX9M 1430799 30 2018/07/17-19:56:32 /dev/sdp 23 13 62757 ST31500341AS 9VS4PHSH 1430799 31 2018/07/17-20:00:03 /dev/sdp 22 100 42142 ST3160318AS 6VMFHMEW 152588 32 2018/07/17-20:00:05 /dev/sdo 24 ? 31288 ST31000525SV 6VP4GW9S 953870 |
Well, would proof be that you cannot pull any data from the drive? In the future, please post long code segments like that using the forum's "[CODE]" tags to make it easier for everyone to read.
|
Quote:
The only way to prove the data was erased is to list the entire drive contents afterwards and they just be 0s (because random overwrites are meaningless). Oh, and SSDs don't count -- you need to either overwrite with 0s and trust that nobody can access any cells not set to 0 or use the built-in wipe and trust that. |
I think I read somewhere the only sure way to wipe an SSD was with a hammer...
OP could use something like photorec/testdisk to scan the entire driver after the fact to see if any files can be pulled. Still not as powerful as professional forensics data retrieval software but not sure OP's goal. |
One could state the only sure way to securely wipe any drive is with a hammer... I would assume that most SSDs these days have the built in capability of secure erase. This resets the drive back to its "out of the box condition" including the extra memory for wear leveling. I believe that normally since flash reset state is a 1 that after a secure erase the SSD drive will be all 1s.
It depends what procedure you are using to wipe hard drives drives and their final wiped state. A random value would be difficult to test. If zero, you could compare via the cmp command with /dev/zero. With a secure erase you typically need to set a password and upon completion of the secure erase the password is reset. Not sure if that is enough proof to state the drive was wiped. |
We used to use a VHS eraser.
Maybe set all to zero and do a dd to file and use it as proof. The dd file will be very small on gzip if zeroed out. A secure way is (edit "was") something like 9 times. |
In the old days we used a 9 track tape degausser which had a much bigger magnet then a VHS eraser...
It ultimately depends on what security standard if any your trying to to fulfill. In the US overwriting is no longer acceptable, the DoD standard is either destruction or degaussing but that does not work for SSDs. I don't know if the DoD security manual has been updated recently. |
michaelk mentions a good point -- to erase an SSD it, perhaps, should be set to all ones. I say this because any controller is going to see "set to 0" as "pretend has no data". Hence the mention of "secure erase" in the post also.
If you're not a state-level business or a paedophile then any "secure erase" is likely enough to be negligible risk. By the way, that's not a "no guilt nothing to fear" that's an opinion based upon financial considerations (the ones which rule most of our lives) -- nobody will spend tens of thousands of dollars for one social security number unless it's guaranteed to net more. |
At my company, I use a script using shred that mounts network shares and the last line is the log that outputs:
Code:
shred -vfz -n 3 /dev/${drivename} 2> >(tee /tmp/temp.txt) && grep "0%" /tmp/temp.txt >> /mnt/${serial}-${user}.txt |
Quote:
Is there evidence of how well shred works on SSDs? I'd also wonder about some wear-levelling stuff end up only overwriting empty space, or something (this, I have no citations for). |
Quote:
|
Quote:
You are probably correct in that your script will likely satisfy managers but, and I mean no offense, it's not proven to do anything. Well done with the manager thing though. ;) |
Quote:
|
It's kinda dirty, but you could use hexdump. By default it will stop outputting when there's all 00's and then just do a summary. I've never tried to hexdump an entire hard drive before though and I'm not in a position to test that now (with a wiped one) but worth a shot.
You could then write a script that just looks at the output to make sure there's no non zero values within the dump part. This won't prove that the data can't be recovered with a special electromagnetic microscope or something, but it will prove from a logical point of view that it's wiped. for HDDs I like to use the shred command with lot of random data followed by zeros. For SSDs, I'm honestly not sure what is better and I think the tech is too new for anyone to really have a good idea, but my train of thought is to take a "good enough" approach and do maybe 2-3 passes max. This should hopefully ensure that you get all the redundant flash (SSDs often overprovision flash so it lasts longer) while not wearing it out TOO bad. Personally for SSDs, I would just keep them until they are fully worn out. You can always find a use for a SSD in a build. Saves you from worrying about doing a secure erase. |
Quote:
The DoD wipe is a fallacy but one known to work on spinning rust as well as just writing zeros once. It's actually been proven and acknowledged by the guy who came up with it himself. SSDs, is there DoD standard? My guess is it's destruction my force and/or fire? |
All times are GMT -5. The time now is 02:23 PM. |