Eraser performance verified w/ Encase?

[Anonymous]

Hello,

I was just wonding if anyone has ever done any extensive testing to see whether Eraser really completely destroys sensitive data rendering it unrecoverable by Forensics recoverey programs such as Encase?

I recently tried this by wiping the Win386.swp file using Eraserd (V 5.6) in DOS mode. I then rebooted back into windows and immediately used Encase to view the Win386.swp file. I still saw information in the swap file.

I was just wondering if anyone else has tried something similar.

 

[garrett01]

Encase and Eraser

Were you using a Fixed Swap File or was the swap file expanding and reducing in accordance with the needs of the operating system?
If so, then EraserD will only erase the fixed amount of the swap file it sees, it will not erase the enlargements i.e. if it expands it will not erase the expanded size; it will erase just the original size.
If you have not erased the Freespace, then it too will be contaminated with data.
The best way to conduct this type of test is on a brand new machine where you have installed the base operating system. Another idea would be to create files with a known pattern, so that you would be guaranteed that this files data could not possibly have previously existed on the machine and then erase and recover that data.

Garrett

 

[Anonymous]

Thanks Garrett,

I was using a fixed Swap File size of 120 Mb. I believe I first deactivated the swap then did a free space erase then reactivated the swap, rebooted, and checked with Encase and saw data in the Swap.

So then I went to DOS and used Eraserd on the Swap and then checked again with Encase, still seeing random file names and junk in the Swap.

I'm going to try this all again in a more methodical manner when I have free time. This was all originally done out of curiosity, quickly.

Garrett, have you done any similar tests?

Thanks

 

[garrett01]

Yes I have done quite a few tests, as have several users here.
Over the years there have been many other tests done.

There is an app verify.exe that comes with windows eraser where you can see it erasing the data.

Garrett

 

[Sami]

I then rebooted back into windows and immediately used Encase to view the Win386.swp file.

Windows recreates this file every time you start it, unless you have disabled paging. Anyway, to keep it simple, why don't you simply try erasing another file, preferably one containing known data, and see if you can recover it. If you insist on using eraserd.exe, you can use the -nodel parameter to keep the file around after overwriting.

 

[Anonymous]

Hi Sami, Thanks for the reply.

I have previously verified, with Encase, the wiping of other files successfully, but for some reason I've been having problems completely wiping the Sawp file.

I've tried the following:

1. Disable Virtual memory, reboot, wipe free space, re-enable virtual memory to 120Mb, reboot, scan drive with encase and look at win386.swp

2. boot to dos, run eraserd to wipe Win386.swp, boot to Windows, scan drive with encase and look at win386.swp

3. Also tried your suggestion of using the -nodel command with eraserd

In all 3 cases when I looked at the Win386.swp file using Encase, after rebooting, I still saw readable data in the Swap. It looks as most of the file was wiped with random garbage, but there is still some information in there (file names, file paths, commands)

Is there anyway to use the verify.exe program from DOS so I can see what's going on? When I tried to run it from DOS is said "Must Specify ON or OFF".

The only thing I can think of right now is that after I wipe Win386.swp and reboot to Windows, when Windows recreats the Swap file it adds all this readable info into the Swap file before I run Encase.

 

[Gusti]

swp

1) what OS are you using?

2) did you use Norton to fix the position of the SWP file
on your HDD? E.g. at the beginning of the partition?

Otherwise it's newly created on a haphazard place where
garbage may be stored.

 

[Anonymous]

Gusti,

1. I'm running Win98

2. No I haven't done anything to fix the position of the Swap file. Can you elaborate on this?

"Otherwise it's newly created on a haphazard place where
garbage may be stored."

But there shouldn't be any garbage stored anywhere after I've done a Free Space wipe.

 

[Gusti]

Swap

1) Thankyou for Win98. Just wanted to be sure to talk about something
I know.
2) In Norton Utilities, Speeddisk, you may choose what comes first on
the HDD, e.g. the swapfile is a good choice. So when you are using a
fixed size of swp, you may be sure, that it is always using exactly the
same space on the HDD. If you erase it, it will later be rebuilt at exactly
the same place (aka: no garbage possible). The only possibility for
contamination would be the bootup procedure, before the swp is rebuilt.
3) My private security solution is: 512 MB of RAM (Win98 does not allow
more) and NO SWP file at all.
4) I will test my Win98 (with swp), if I can find any residue. Will take a
while
5) May I have your E-Mail address, please, so we do not fill the forum
with too much discussion. Mine is zut.zut@bluewin.ch
Kind regards

 

[Anonymous]

Gusti thanks for the info.

I currently don't use or have Norton Speeddisk, but setting a fixed Swap location sounds like a good plan.

I wish I had 512 Mb of RAM so I didn't need the Swap, but I'm running a very low budget system with 64Mb of RAM so I defintely need the Swap space.

What software do use use to view the contents of your Swap and Unallocated Disk space?

You can contact me at Icepick_2003@yahoo.com

Thanks again,

Ice

 

[Sami]

1. Disable Virtual memory, reboot, wipe free space, re-enable virtual memory to 120Mb, reboot, scan drive with encase and look at win386.swp

Are you sure the data you saw is what you supposedly erased, or is it new data written to the new win386.swp when you re-enabled virtual memory?

2. boot to dos, run eraserd to wipe Win386.swp, boot to Windows, scan drive with encase and look at win386.swp

Again, Windows created a new win386.swp when you started it, after you erased the old file. You need to examine the file after erasing it, before you restart Windows.

3. Also tried your suggestion of using the -nodel command with eraserd

And this is where the -nodel parameter comes in handy. You can probably find a hex editor for DOS somewhere. See what's in the win386.swp file before erasing, erase it with -nodel, and then see what's in the file after erasing. If it contains any of the same data as before erasing, then eraserd failed.

The only thing I can think of right now is that after I wipe Win386.swp and reboot to Windows, when Windows recreats the Swap file it adds all this readable info into the Swap file before I run Encase.

My thoughts exactly.

 

[Anonymous]

swap file

Unless you are running super memory intensive programs, be a heritic and try maxing out your physical memory and turning the virtual memory off! Many people say "don't do this, blah, blah..." but many of us have done it for years with not only no performance hit --- but with actual performance gains! (Windows no longer has to access the drive for memory.) However, don't do this without maxing out your memory or a minimum of 768mb of RAM. It is a controversial subject with some, but again, many, many do this every day with more than pleasing results and no swap/paging file to concern yourself with wiping!

 

[Anonymous]

Let the computer demagnetize first on shutdown

Parts of the Swap file are loaded and held in the temporary memory (RAM). When you shut down and boot to DOS and then ERASE and restart some of those parts of swap file are still held in temporary memory and will be dumped back into the swap file.

The remedy is simple. Turn the computer off and wait about 45 seconds (well beyond hearing the crackle die down). Then boot to DOS and use ERASERD or SCORCH. Then shutdown again and wait 45 seconds and boot into Windows. ENCASE should show no more remnants.

- Bone Digger

 

[Sami]

Re: Let the computer demagnetize first on shutdown

Parts of the Swap file are loaded and held in the temporary memory (RAM).

Nope, that would soft of defeat the entire purpose of having a swap file in the first place. Parts of virtual memory are temporarily stored in the swap file, not the other way around.

When you shut down and boot to DOS and then ERASE and restart some of those parts of swap file are still held in temporary memory and will be dumped back into the swap file.

Not true; when you shut down the operating system, you shut down the virtual memory manager. There is no code left to manage paging.

The remedy is simple.

It should be, considering that there's no problem.

 

[ktesibios]

I did a little checking on my own computer.

I'm using Windows 98; I have a fixed swap file of 300M, located right at the top of the hard drive (it starts in cluster 3).

I booted to DOS, ran Norton Diskedit and used it to look at the c:\directory and the contents of win386.swp, taking note of the location of the swap file's directory entry and also fo several sectors which contained identifiable text. A couple, located near the begining of the swap file, contained what looked like a list of names of various system calls; a whole bunch in cluster 2136 contained text pertaining to ATT Connection Manager.

Then I used eraserd to do a 4-pass wipe of win386.swp.

Then, while still in DOS, I ran Norton Diskedit again and looked at the c:\ directory- the former entry for win386.spw was gone, with the filename set to random letters and the parameters for starting sector, length, etc. set to zero.

I then looked at the sectors whose locations I had noted previously. The text I had seen was gone, replaced with what looked like random data.

Then I ran Windows and immediately launched Norton Diskedit once again (if you try to run it from Windows, it runs in a DOS shell window). Now ther was a directory entry for a newly-created win386.swp. Looking again at the sectors I had examined before, I found that the stuff near the top of the file was back, but the stuff I had seen farther into the file was still random data.

It looks like eraserd is doing an efficient job of erasing win386.swp, that Windows creates a new swap file when it runs. and that the only data that's comon to both the erased and new swap files immediately after launching Windows is stuff that it has to load while it boots, and then shoves off to the swap file.

As you continue to work in Windows, more stuff will get paged off. If you run the same programs and open the same files, it's likely that you can come up with a swap file containing contents similar to the one previously erased- if I log on to ATT worldnet, I'll wind up with the same text strings in cluster 2136 every time- but having the old swap file mysteriously resurrect itself after being erased doesn't seem likely.

 

[ktesibios]

I did a little checking on my own computer.

I'm using Windows 98; I have a fixed swap file of 300M, located right at the top of the hard drive (it starts in cluster 3).

I booted to DOS, ran Norton Diskedit and used it to look at the c:\directory and the contents of win386.swp, taking note of the location of the swap file's directory entry and also fo several sectors which contained identifiable text. A couple, located near the begining of the swap file, contained what looked like a list of names of various system calls; a whole bunch in cluster 2136 contained text pertaining to ATT Connection Manager.

Then I used eraserd to do a 4-pass wipe of win386.swp.

Then, while still in DOS, I ran Norton Diskedit again and looked at the c:\ directory- the former entry for win386.spw was gone, with the filename set to random letters and the parameters for starting sector, length, etc. set to zero.

I then looked at the sectors whose locations I had noted previously. The text I had seen was gone, replaced with what looked like random data.

Then I ran Windows and immediately launched Norton Diskedit once again (if you try to run it from Windows, it runs in a DOS shell window). Now ther was a directory entry for a newly-created win386.swp. Looking again at the sectors I had examined before, I found that the stuff near the top of the file was back, but the stuff I had seen farther into the file was still random data.

It looks like eraserd is doing an efficient job of erasing win386.swp, that Windows creates a new swap file when it runs, and that the only data that's common to both the erased and new swap files immediately after launching Windows is stuff that it has to load while it boots, and then shoves off to the swap file.

As you continue to work in Windows, more stuff will get paged off. If you run the same programs and open the same files, it's likely that you can come up with a swap file containing contents similar to the one previously erased- if I log on to ATT worldnet, I'll wind up with the same text strings in cluster 2136 every time- but having the old swap file mysteriously resurrect itself after being erased doesn't seem likely.

 

[ktesibios]

I did a little checking on my own computer.

I'm using Windows 98; I have a fixed swap file of 300M, located right at the top of the hard drive (it starts in cluster 3).

I booted to DOS, ran Norton Diskedit and used it to look at the c:\directory and the contents of win386.swp, taking note of the location of the swap file's directory entry and also fo several sectors which contained identifiable text. A couple, located near the begining of the swap file, contained what looked like a list of names of various system calls; a whole bunch in cluster 2136 contained text pertaining to ATT Connection Manager.

Then I used eraserd to do a 4-pass wipe of win386.swp.

Then, while still in DOS, I ran Norton Diskedit again and looked at the c:\ directory- the former entry for win386.spw was gone, with the filename set to random letters and the parameters for starting sector, length, etc. set to zero.

I then looked at the sectors whose locations I had noted previously. The text I had seen was gone, replaced with what looked like random data.

Then I ran Windows and immediately launched Norton Diskedit once again (if you try to run it from Windows, it runs in a DOS shell window). Now ther was a directory entry for a newly-created win386.swp. Looking again at the sectors I had examined before, I found that the stuff near the top of the file was back, but the stuff I had seen farther into the file was still random data.

It looks like eraserd is doing an efficient job of erasing win386.swp, that Windows creates a new swap file when it runs, and that the only data that's common to both the erased and new swap files immediately after launching Windows is stuff that it has to load while it boots, and then shoves off to the swap file.

As you continue to work in Windows, more stuff will get paged off. If you run the same programs and open the same files, it's likely that you can come up with a swap file containing contents similar to the one previously erased- if I log on to ATT worldnet, I'll wind up with the same text strings in cluster 2136 every time- but having the old swap file mysteriously resurrect itself after being erased doesn't seem likely.