4

I downloaded latest stable Ubuntu (ubuntu-16.04.3-desktop-amd64.iso image that I double checked for authenticity) and used it to boot my new Win10 system which I wanted to wipe. I followed the instructions, like those at

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

to unfreeze the drive and wipe it using the

time hdparm --user-master u --security-erase ... /dev/sda3

command. In fact I ran it another time (after resetting the drive password) and running with --security-erase-enhanced option second time (thanks to http://www.stevenmaude.co.uk/posts/securely-erasing-frozen-hard-disks-with-hdparm instructions).

It took almost 2 hours each time to go through the erase process. At the end, no errors were printed out. 0's were shown for various times, like 0 cpu time and 0 system time. Only the elapsed time was showing ~2 hours.

After those two runs, I was still able to open random text and xml files in both Windows and non-Windows directories and look at their contents even though I had not opened them earlier in that same Ubuntu session, so it could not have cached them!

then...

  • I could no longer boot into Windows - guess that's a good sign :-)

  • After restarting computer and loading up Ubuntu again, it no longer auto-mounts /dev/sda3 (or anything else resembling a hard drive). fdisk -l shows the drive but that's about it.

  • Tried loading Paragon bootable CD and it also shows no filesystem.

Any ideas as to what I am missing?

It's almost as if it blew away the entry into the file system but after the two erases it was still able to navigate and find file content in that same session of running Ubuntu. Now I don't seem to be able to see anything because anything I try to run no longer finds starting point for the file system, but I wonder if all the data is still laid out there on disk?!

Thank you!

Justin
  • 81
  • 1
  • 5

3 Answers3

4

(OP here) I cannot double check this as I already cleaned out the drive using Active @Killdisk but I ended up following up with developer of hdparm (Mark L.) who indicated that it's likely the issue was related to the fact that my drive was auto-mounted at the time I was performing secure erase. In his own words:

you MUST unmount anything that got automounted, because stuff that is mounted gets periodically written to by the kernel (filesystem timestamps etc), which could account for some of the non-zero stuff you saw later.

The "non-zero stuff" he is referring to is the output of sudo xxd -a /dev/sdX command suggested by sudodus earlier on this thread.

Justin
  • 81
  • 1
  • 5
3

I think you needed the reboot for the new mapping of the hard disk drive to be seen by the system.

If you want to, you can try to recover files from the 'drive surface' with PhotoRec,

http://cgsecurity.org

or look at the following link,

Re: best way to wipe a drive

which also shows checking the result with xxd

roten@my-precise:~$ sudo hdparm -I /dev/sdb
...
Security: 
    Master password revision code = 65534
        supported
    not    enabled
    not    locked
    not    frozen
    not    expired: security count
    not    supported: enhanced erase
    88min for SECURITY ERASE UNIT. 
Logical Unit WWN Device Identifier: 50000391f340058c
    NAA        : 5
    IEEE OUI    : 000039
    Unique ID    : 1f340058c
Checksum: correct
roten@my-precise:~$ sudo hdparm --user-master u --security-set-pass Eins /dev/sdb security_password="Eins"

/dev/sdb:
 Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
roten@my-precise:~$ sudo hdparm -I /dev/sdb
...
Security: 
    Master password revision code = 65534
        supported
        enabled
    not    locked
    not    frozen
    not    expired: security count
    not    supported: enhanced erase
    Security level high
    88min for SECURITY ERASE UNIT. 
Logical Unit WWN Device Identifier: 50000391f340058c
    NAA        : 5
    IEEE OUI    : 000039
    Unique ID    : 1f340058c
Checksum: correct
roten@my-precise:~$ sudo time hdparm --user-master u --security-erase Eins /dev/sdb security_password="Eins"

/dev/sdb:
 Issuing SECURITY_ERASE command, password="Eins", user=user
0.00user 0.00system 1:11:03elapsed 0%CPU (0avgtext+0avgdata 2432maxresident)k
0inputs+0outputs (0major+200minor)pagefaults 0swaps
...
Security: 
    Master password revision code = 65534
        supported
    not    enabled
    not    locked
    not    frozen
    not    expired: security count
    not    supported: enhanced erase
    88min for SECURITY ERASE UNIT. 
Logical Unit WWN Device Identifier: 50000391f340058c
    NAA        : 5
    IEEE OUI    : 000039
    Unique ID    : 1f340058c
Checksum: correct
roten@my-precise:~$ sudo time xxd -a /dev/sdb
[sudo] password for roten: 
0000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
1000000000000 0000 0000 0000 0000 0000 0000 0000  ................
2000000000000 0000 0000 0000 0000 0000 0000 0000  ................
3000000000000 0000 0000 0000 0000 0000 0000 0000  ................
54272.57user 343.93system 15:10:36elapsed 99%CPU (0avgtext+0avgdata 2096maxresident)k
488398400inputs+0outputs (0major+179minor)pagefaults 0swaps
roten@my-precise:~$
sudodus
  • 45,126
  • 5
  • 87
  • 151
  • Thanks for the response. Could you clarify regarding "I think you needed the reboot for the new mapping of the hard disk drive to be seen by the system." I thought hdparm would overwrite everything, so I should not be able to see file contents. Only after reboot I could not see the filesystem or mount anything; but while using same ubuntu session, I could still retrieve file contents for what should have been all overwritten. At this point I can't mount the drive to run xxd command. – Justin Oct 28 '17 at 16:49
  • I *think* the kernel might have the old content of the partition table and file system cached, even if you thought the opposite. Anyway, you can check now (with PhotoRec or thoroughly with `xxd`) if there is some data to be found. You need not, should not and I think cannot mount any partition on the drive, because there should be no partition, no file system and no data left on the drive. `sudo time xxd -a /dev/sdx` should look for data, and there should be only zeros, where `-a` means that nul-lines (with only zeros) will be skipped (otherwise you would drown in output). – sudodus Oct 28 '17 at 23:11
  • Use DBAN if you do not rely on hdparm for this purpose (secure erase). – sudodus Oct 29 '17 at 06:29
  • sudodus, while "mount" command does NOT show /dev/sda mounted, running xxd on /dev/sda anyway shows some NOT 0 data. "sudo hdparm -I /dev/sda" shows my 1Tb drive, currently in frozen state again, not enabled, and while online examples, including yours above, show that I should see a line saying how long it would take to wipe it, mine never showed it. In other words, just below "supported: enhanced erase" line, I see "Logical Unit WWN Device Identifier: ..." line right away. One more note: it used to be /dev/sda3 when I erased it (twice) but now it's just /dev/sda without number at the end. – Justin Oct 29 '17 at 19:29
  • There should be no number at the end, because the partition (and partition table) is overwritten. If you do not rely on the result, maybe you should try to use `hdparm` according to the link in my answer, https://ubuntuforums.org/showthread.php?t=2124829&p=12555068#post12555068 or use DBAN, downloaded from https://sourceforge.net/projects/dban/files/dban/ -- I have used the old version dban-2.2.7 (I treated it with `isohybrid` and could clone it to a useful USB boot drive.) – sudodus Oct 29 '17 at 19:37
  • I am sorry if I am not following. Instructions I had used earlier (when it auto-mounted /dev/sda3) were the same as in the link you provided. I ran through those instructions twice in fact: with -secure-erase and -secure-erase-enhanced options. Both took over 2 hours with no errors. THEN, I could still see files and even file contents until reboot. After reboot of live ubuntu DVD, it would no longer see or mount /dev/sda3. xxd shows non-0's on /dev/sda (sda3 does not exist). I tried Active @Killdrive off of Ultimatebootcd and now xxd shows all 0's.. but I don't know if HPA ever got cleared. – Justin Oct 30 '17 at 01:37
  • When xxd shows all 0's, I think everything is wiped. Do you mean the host protected area (HPA), an area of a hard drive or solid-state drive that is not normally visible to an operating system? I think both hdparm and DBAN should wipe enough for a normal user's security, but I am not an expert in this field, and I don't know any details about HPA. – sudodus Oct 30 '17 at 07:19
  • Yes, I mean host protected area. There are other areas too (IIRC, DOC was another one). From what I read DBAN does NOT clear those areas. Only hdparm and HDDErase are supposed to. DBAN (older version) did not work on my drive anyway. No-longer-supported-since-2008 HDDErase also does not seem to work. Only hdparm did something but I am not sure if it wiped or not.. FYI, after running Active @Killdrive, xdd is stil running after almost 24 hours, showing one line of 0's every few hours... how long should xdd take on 1Tb drive? Anyway, appreciate your help! – Justin Oct 30 '17 at 14:40
  • `xxd` takes maybe 10 times longer (or more) than `hdparm` for the same drive, you have to be patient ;-) – sudodus Oct 30 '17 at 14:43
  • I was wrong about 24 hours. The command just finished and it says it took ~18 hours. It printed out 15 lines, all filled with 0's. So NOT 0000..., 1000..., 2000..., like in the sample output I saw in https://ubuntuforums.org/showthread.php?t=2124829&page=2&p=12555068#post12555068 but rather 0000..., 0000..., 0000..., – Justin Oct 30 '17 at 18:51
  • I would be satisfied at this point, and rely on the wiping result. (The alternative would be to destroy the drive physically, if I would need a higher level of security.) – sudodus Oct 30 '17 at 19:01
0

/dev/sda3 represents a partition, the whole disk is /dev/sda.

hdparm --user-master u --security-erase ... /dev/sdx

(in your case replace sdx with sda)

Christophe Nagel
  • 1
  • 1