Artifacts of wiping

One I have seen that is very common is Eraser. Lots of settings that might match what you are looking for.

http//eraser.heidi.ie

Have you looked at the UserAssist, MUICache, and other artifacts for the user that might indicate program execution? That might provide indications of the application used…

I haven't yet examined the volume shadow copies, but I'm hopeful I'll find something there.

Just to clarify that VSC's, while handy, only contain differential data from the original; enough to restore a live file back to a previous version. There won't be complete copies.

Why is 0x57 an odd choice? Why would the user need to be tech savvy, maybe the screen said 0x10 by default and he didn't want it to look like a default wipe from drive wiper so it got changed slightly.

Saying it's an odd choice has no background nor base of reason, stay with the part where you say has anyone seen a probram that uses 0x57, although as 99% are able to use any character you want, I think it's a tough road.

I have an IP theft case where the suspect has clearly deleted and wiped relevant information. There are no documents of any kind on the hard drive, and much of the unallocated clusters on the drive have been written with an ASCII W, hex 57. I haven't yet examined the volume shadow copies, but I'm hopeful I'll find something there. I did find many link files pointing to files on an external drive (which I do not have). My theory is that the computer was sanitized at some point and the user kept using it with files from a USB drive until they finally returned the computer.

Have any of you seen a wiping program use 0x57 as the wiping character? I know many of them are configurable, but 0x57 is just an odd choice, and this user wasn't particularly tech savvy. I haven't seen any other traces of a wiping program, so do you have any tips on finding such traces?

PC was Windows 7 x64 Enterprise. Bitlocker encryption was enabled, but the image I have has the encryption removed.

If you know that names of the documents you believe were deleted, have a look in the USN journal. The names of the files and the file action (renaming, deletion etc) are all recorded in there.
There a couple of parsers out there to parse the journal file, Jp isn't a bad one
https://tzworks.net/prototype_page.php?proto_id=5

Why is 0x57 an odd choice?

As long as 0x56 and 0x58 are even choices, it sounds fine to me wink .
D

jaclaz

Saw 0x57 in unallocated today and vaguely remembered this post. A bit of Googling found this page

http//www.ocztechnologyforum.com/forum/archive/index.php/t-65424.html

with this comment

I'm not sure there is much that can be done without Trim. When the drive is first encrypted a file is created the size of the free space minus 6GB. This is used as a placeholder to prevent the encryption of the free space. In case there was any sensitive data that at one time resided in the free space the file consists of the hex code "0x57" which to us normal people is the ASCII character code for the letter "W". This speeds up the encryption process and also makes the recovery of any data that was previously deleted unlikely. When the encryption process is finished the placeholder file is deleted. Even though the file is deleted the free space is still filled with "0x57".

Any operation the user attempts at the operating system level I think will be useless. Anything written to the free space is gong to be encrypted and the space will still not be in an erased state.

Microsoft claims there are no disadvantages to using Bitlocker with a SSD. It seems a better approach to dealing with the free space would be to write "0xff" instead of "0x57". Not only would any deleted data be overwritten but from an operational point the space would also be in an erased state. As far as Trim we can only assume it would be triggered when the placeholder file is deleted. If this doesn't happen then there would not be much benefit of having Trim.

Looks like it's Bitlocker that fills the space with '0x57'.

Looks like it's Bitlocker that fills the space with '0x57'.

Nice find ) .

Confirmed from the mouth of the wolf
http//blogs.technet.com/b/bitlocker/archive/2006/07/08/unallocated.aspx

And finally, a bit of trivia the noise that is used to overwrite free space is generated by encrypting a buffer filled with 0x57 (‘W’ in ASCII code). So, if you ever opened an encrypted volume in a disk viewer and wondered what those vast spaces filled with W’s are – that’s most probably unallocated space that has been wiped during encryption.

jaclaz

If you know that names of the documents you believe were deleted, have a look in the USN journal. The names of the files and the file action (renaming, deletion etc) are all recorded in there.
There a couple of parsers out there to parse the journal file, Jp isn't a bad one
https://tzworks.net/prototype_page.php?proto_id=5

Is the change journal enabled by default in NTFS ? will it also keep record if the entire hard drisk was overwritten?