41 replies to this topic

[Wonko the Sane]

@Wonko
Tried to do as described (but don't know what it has to do with this topic) & mybackup.img is 2GB but the heapsofzeroes.img is only 16Kb. No errors.
Got this error: failed to create sparsefile
the cmd file attached

The first dsfo command creates a dd-like image of the UFD - better be safe than sorry (and it works, OK).
The small batch should take the size of the image in bytes and use mksparse to create a sparse file of the same size (a newly created sparse file will be filled with all zeroes).
Sparse files "exist" (or can exist) only on NTFS volumes, maybe your C:\ drive is not NTFS?
Or maybe an issue with the OS you are running?
If you have enough space on the C:\ drive you can create a new file with the actual size of the UFD backup by using the command fsz (also part of the DSFOK package), only be VERY careful, as if you do not have enough space or you specify aq "too big" size, fsz will attempt to create the file nonetheless, possibly filling the volume up to the brim .
The third part, the dsfi command writes back the whole 00 filled image to the UFD (thus "wiping" it).



Wonko

P.S.: There is a small typo in the batch, my bad I corrected it in my previous post, there is a colon in:

if %1.==. goto :eof

but this only affects the "trap" to avoid executing the batch without parameters.

[darren rose]

@al_jo - I did right click and choose run with runscanner - but as explained in a previous post the disk I am trying to wipe is encrypted with truecrypt so runscanner cannot see the windows folder so hence doesn't work and I then get the error I said

[al_jo]

@Wonko
Noticed the semicolon yesterday but didn’t mention it because it made no change.
Anyway, seems I was using the wrong version of
mksparse.exe (from 2007)
but found another version (1.0.0.1) here:
http://markcox.googl...tools/mksparse/
and the image was now created successfully (2088763392 bytes).
After using the DSFI commands Recuva can not read the boot sector from the UFD.

@Darren
Only suggestion (again): Remove the encryption/protection if you want to use the wiper programs from a win7pe.

[darren rose]

yes that seems to be my only option - just thought I would ask - will stick with using diskpart to clean the disk to remove encryption etc - then using another tool to securely erase it - just thought there would be a eraser tool out there that worked to do both things in one easy step!!!!

[Wonko the Sane]

After using the DSFI commands Recuva can not read the boot sector from the UFD.

This was expected, what I made you do is simply to wipe (albeit slowly-BTW How long did it take? ) the UFD "properly" by writing to each and every sector of it a sector full of digital 0's.
This could mean that either your previous attempts were *somehow* doing *another* thing or that still *somehow* the files recovered by recuva were *fake*.
Which filesystem was the volume on the UFD formattted with?
Check the MBR of the backup image you have made, if you partitioned the UFD under XP, you most probably have 63 hidden sectors, if you partitioned it under Vista or 7 that value will be 2048.
IF the filesystem was NTFS you can issue EITHER of:

dsfi .PHYSICALDRIVE1 0 40448 C:mybackup.img

(if sectors before were 63)
OR:

dsfi .PHYSICALDRIVE1 0 1056768 C:mybackup.img

(if sectors before were 2048)
IF the filesystem was FAT16 or 32:

dsfi .PHYSICALDRIVE1 0 32768 C:mybackup.img

(if sectors before were 63)
OR:

dsfi .PHYSICALDRIVE1 0 1049088 C:mybackup.img

(if sectors before were 2048)
The above will re-transfer to the UFD just the MBR, the hidden sectors and the bootsector (and NOTHING else).
Then you can try re-running Recuva on it.
Alternatively you can try re-partitioning/re-formatting the UFD using the SAME OS and tools you previously used (using the /q option if you used FORMAT), IF (though I sincerely doubt it) Recuva cannot start simply because it cannot find the partition and/or the partition bootsector this should gave it a new chance to run.

BTW and JFYI the mksparse I normally use is by Bo Branten and since it has been removed on it's homepage, I posted a link to it in the given thread on post #43:
http://reboot.pro/31...__25#entry70583


Wonko

[homes32]

You could try my victoria script

it is graphical and runs from within PE and allows you to use the internal ATA erase commands through the porttalk driver, so it bypasses the OS API Freeze.

Attached Files

•  VictoriaHDDUtility43.jpg   168.27KB   17 downloads

[Wonko the Sane]

it is graphical and runs from within PE and allows you to use the internal ATA erase commands through the porttalk driver, so it bypasses the OS API Freeze.

NIce!

Never thought that Victoria for windows could do that.


Wonko

[darren rose]

@homes32 - thanks will take a look

[al_jo]

@Wonko
I just reported that Recuva could not find the bootsector after doing this:
dsfi .PHYSICALDRIVE2 0 0 C:heapsofzeroes.img
But of course there where no problems to reformat with the HP format tool.
Now I did this again:
dsfi .PHYSICALDRIVE2 0 0 C:heapsofzeroes.img (10 minutes)
and directly after that:
dsfi .PHYSICALDRIVE2 0 32768 C:mybackup.img (0 minutes)
and now Recuva can read the UFD and there was nothing to recover.


Ps. I never said that the files Recuva could recover, after the use of the different wiper programs, has useful or useless info.
Only reported what Recuva reported. Perhaps it’s only useless “crap” created by the “wipers”?

Attached Files

•  ff.gif   69.95KB   2 downloads

[cdob]

I never said that the files Recuva could recover, after the use of the different wiper programs, has useful or useless info.
Only reported what Recuva reported. Perhaps it’s only useless “crap” created by the “wipers”?

Using a 2GB UFD, zeroed and format.
One file added: hello.txt 'hello world'. A hex editor finds 'hello world' at disk.
Win7PE SP booted: format e:
Next a hex editor does NOT finds 'hello world' at disk.

A format overwrites user data. Data are not recoverable.
That's not a quick format.

ATA security erase is recommended still.

And mechanical destroying hard disk is nice at special requirements.

[Wonko the Sane]

@al-jo
No offence whatever intended , but your initial report of your tests did not sound "right" to me .
This is why I asked you to repeat it with a tool/method that I know how it works.
I am not familiar with Recuva, it is a kind of program a little bit too smart for me, I like to find my bytes one by one, but- as said before - *something* in your previous tests did not do what it was supposed to do.
I am pretty sure (as cdob just confirmed specifically) that Windows Vista and 7 FORMAT (without the /q) does actually wipe sectors.
So either - for any reason - the actual FORMAT was not completed successfully -but you used (unneededly) the two passes (and the same happened to the other wiping tools you tested or these latter - unless they were instructed to do "the right thing", i.e. a single 00 pass, created artifacts that Recuva mistook for files to be recovered) or Recuva simply and again *somehow* "faked" files.
Mind you that in some circumstances the wear leveling algorithm of an UFD may come into play, but at the most this would avoid the wiping of very few sectors, here and there, and to have them "resurface" is a very low chance.
I.e. theoretically it is possible that you may find out after several attempts one or a few single sectors, unlikely to contain any "meaningful" data.

As said in the already linked to thread, sledgy currents are the best when it comes to flash (the alternative being using the manufacturer tools that bypass any wear leveling that may be in place, allowing you to actually write zeroes on each and every sector/byte of the flash).


Wonko

[al_jo]

@wonko
Yes, there is probably something “wrong” with my UFD. Will put it in the trash.
And instead do some testing with a 120GB PATA drive tomorrow.

@all
There is a Winbuilder script for the very good recovery program Recuva here:
http://al-jo.zxq.net/Recuva.7z
And some reviews here:
http://download.cnet...4-10753287.html
and here:
http://pcsupport.abo...cuva-review.htm


Edit: Found the format ”problem”.
After doing this:
format [drive]: /x /fs:fat32 /p:1
Recuva finds 505014 zero-byte files & non recoverable.
After doing this:
format [drive]: /x /fs:ntfs /p:1
Recuva finds 265 files & 22 are “recoverable” (probably “made” by the format to ntfs command?).

And yes, the format command completed successfully of course!

Attached Files

•  Untitled.gif   109.59KB   1 downloads

[Wonko the Sane]

Edit: Found the format ”problem”.
After doing this:
format [drive]: /x /fs:fat32 /p:1
Recuva finds 505014 zero-byte files & non recoverable.
After doing this:
format [drive]: /x /fs:ntfs /p:1
Recuva finds 265 files & 22 are “recoverable” (probably “made” by the format to ntfs command?).

And yes, the format command completed successfully of course!

Very good .
What Recuva reports makes sense (i.e. makes NO sense whatsoever ) :
ALL structures of the NTFS filesysem are actually files!
SO what it finds are things like the $MFT, the $MFT mirror, $Quota, etc., etc., i.e. the "standard" NTFS filesystem structures (which since you just formatted are empty/contain no meaningful data whatsoever).
AND all the rest are "fake" files, it is quite obvious how a file that has no name, no last modified date, and it is 0 bytes in size, is unrecoverable is not actually a file but rather a "fake" or "artifact" created by Recuva.
JFYI, a good recovery app (for people who know where their towel is) is dmde :
http://softdm.com/


Wonko

[al_jo]

JFYI, a good recovery app (for people who know where their towel is) is dmde :
http://softdm.com/


Wonko

There is a winbuilder script for DMDE 2.4.2 Free Edition here:
http://al-jo.zxq.net/dmde.7z
Tested & working in Win7PE.

[homes32]

If you use HDPARM, you'll need to be able to place the computer to sleep and then wake it up.

I can't do this with my builds at the moment and not sure how to add the sleep function.

you can also just unplug the power cord directly from the HDD for a few seconds then plug it back in. SATA drives are hot swappable so it won't hurt them. PITA but it works.