-----BEGIN PGP SIGNED MESSAGE-----

(Nothing above this line is part of the PGP signed document)

Scorch                                Version 1.02 (for PC compatibles)
======                                =================================
Copyright (c) 1996-99 Iolo Davidson   ALL RIGHTS RESERVED


                       YOU MUST READ THIS
                       ==================

This software remains the property of Iolo Davidson.  The software is
not sold, nor are any rights in the software sold.  Iolo Davidson grants
a limited licence to use the software subject to the user accepting all
of the conditions expressed in this documentation.

Unless otherwise stated in writing and signed by Iolo Davidson, this
software and documentation is provided as is, without warranty of any
kind.  Iolo Davidson specifically disclaims all warranties, express or
implied, including, but not limited to, any implied warranty of
merchantability or fitness for a particular purpose.  The entire risk as
to the quality and performance of the software and instructions is with
you.  Should the program prove defective, or should the proper
functioning of the program cause any problem, you assume the cost of all
necessary servicing, repair, or correction.

In no event unless required by applicable law or agreed to in writing
will Iolo Davidson be liable to you for damages, including any general,
special, incidental, or consequential damages arising out of the use or
inability to use the software (including but not limited to loss of data
or data being rendered inaccurate or losses sustained by you or third
parties or a failure of the software to operate with other programs),
even if Iolo Davidson or other party has been advised of the possibility
of such damages.


Limited licence
===============

This program is shareware.

Anyone may try it out for a short period for free.  Thirty days ought to
be plenty.

Anyone may use it indefinitely on a single computer for their own
private and personal use for free.

Anyone may give copies of it to others, or distribute it on computer
bulletin boards or by Internet ftp, provided that the full package is
always distributed intact and not incorporated into any other program or
product, and that absolutely no charge is made.

This software may not be distributed as part of a commercial product
(such as a collection of shareware on a CDROM) or as part of the
promotion of a commercial product (such as a magazine cover disk)
without express written permission from Iolo Davidson.

If the software is used professionally, or in the course of a business
(including the business of government, civil service, or security
services), or for the purposes of commerce, then a registration fee must
be paid.

To register Scorch, send Iolo Davidson one pound (UK currency) or two
dollars (USA currency) for each computer on which it is to be installed.
Cheques or postal money orders only, please.


Iolo Davidson                    Telephone   0870 742 1148
Scrubbetts                             FAX   0870 742 1148
Bagpath
Tetbury                      International   +44 870 742 1148
Gloucestershire                        FAX   +44 870 742 1148
GL8 8YG
Great Britain                        Email   iolo@iname.com
                                             iolo@tesco.net


New in Version 1.02
===================

Another new web address, so I'm not putting it in the initial screen 
anymore.  Also, the /win3 switch now sets the /nodel switch as well.

New in Version 1.01
===================

Nothing.  I just needed to change the Web address.  I may also have 
fixed a small bug affecting the cursor on some machines (but not mine, 
so I can't be sure).

What it is
==========

Scorch (SCORCH.COM) is a secure file overwrite utility that has been
optimised for speed when used on large files.  Use it instead of the DOS
delete (DEL) command when you want the file to really be deleted.

                      -------------------
                      |     WARNING     |
                      -------------------

      SCORCH MAKES IT IMPOSSIBLE TO RECOVER OVERWRITTEN FILES
      WITH UNDELETE UTILITIES.  IF YOU USE THIS PROGRAM,
      OVERWRITTEN FILES WILL BE GONE FOR GOOD.  THIS PROGRAM
      CAUSES PERMANENT DATA LOSS.  THAT IS WHAT IT IS FOR.
      YOU HAVE BEEN WARNED.

Several levels of security are offered, from a one pass overwrite which
is quick and secure enough for the purposes of ordinary privacy, to
multipass overwrites which take longer but make the data difficult to
recover even with extraordinary techniques.

Each file overwrite is followed by a "file commit" call to make sure
that the write happens on the disk, and not just in a disk cache.  After
the overwrites, the file pointer is invalidated, the file is renamed so
that remnants of the original name cannot be found in the directory
(this doesn't work properly under Windows 95-98), and the file time and
date are zeroed.  Finally, it is deleted.


How to use Scorch
=================

Scorch may be run from the DOS command line or incorporated into batch
files.

You MUST specify a filespec for the file or files that you wish to
overwrite on the command line following the program name, and this
filespec MUST be enclosed in square brackets.  This is a safety feature,
to prevent people who are not familiar with the program accidentally
wiping files.  There is no other backstop, no "Are you sure?" prompt or
the like. If you type this command, it will just do it.  You have been
warned.

If you fail to supply the filespec in the correct form, Scorch will
refer you to this document without doing anything else.  This is
for your protection.

The filespec may contain wildcards, just like the DOS delete command.

While Scorch is overwriting a file, it displays the name followed by a
spinning activity indicator.  The spinner may stop and start if disk
buffering is active.  When it finishes overwriting the file, it confirms
the number of overwrites and the elapsed time, in minutes and seconds to
the nearest second.  If it is unable to find the file, or the file
is write protected, then it will display a suitable error message.

If you use Windows, Scorch should work in Windows DOS session.  It uses
ordinary documented DOS calls, nothing that should cause Windows any
difficulty.  Windows may stop you accessing some files, however, for any
purpose and Windows 95 and 98 interfere with Scorch's attempts to blank
filenames, even in a DOS session.

It is not sensible to use Scorch with "delete tracking" software of the
type which stores deleted files for later recovery.  The two are meant
to do opposite things.  If you wish to use such software, do not also
use Scorch.


Options
=======

You MUST enclose the filespec in square brackets when Scorching a file.
The filespec may include wildcards and drive and directory
specifications, just like the DOS delete command.  For instance, to
overwrite a file called FRED.TXT in the currently logged drive and
directory you would use:

scorch [fred.txt]

To overwrite all files with an extent of .TXT in the \BADGER directory
on drive C: you would use:

scorch [c:\badger\*.txt]

You may select extra overwrites by specifying a command line switch when
the program is run.  Otherwise Scorch will default to overwriting once.
For instance, to overwrite three times, you would use:

scorch [c:\badger\*.txt] /three

The switches for the number of overwrites are:

      /zero             (for use when testing other options)
      /one
      /two
      /three
      /four
      /five
      /six
      /seven

Other switches:

      /invert
      /noinvert         (original default)
      /del              (original default)
      /nodel
      /silent
      /win3             (also sets /nodel)
      /valid
      /makedefault

If you want the file to be overwritten but not deleted, then specify the
/nodel switch, like so:

scorch [c:\badger\*.txt] /three /nodel

You may want to do this to check what happens to the file contents when
a file is overwritten by Scorch.

Scorch overwrites files to 32K boundaries, to make sure that slack
cluster space at the end of files is overwritten.  This will be noticed
when files are not deleted as an increase of size in most files.  You
may specify the /valid switch to limit overwrites to the original file
size.  The /valid switch also causes the original name, file pointer,
date, and time to be left in the deleted directory entry.  Some people
may desire this so that deleted entries in their directories do not
betray the use of a secure deletion utility.

PLEASE NOTE- The extra space overwritten does NOT affect other files,
anymore than adding another page to a word processor document would.
Ordinary well-behaved DOS calls are used for all overwrites, and DOS
knows better than to overwrite other files.  I get a lot of questions
about this from people who think that a security utility must be low
level or badly behaved somehow.  Scorch is neither of these things.

Scorch has a special extra inverting overwrite which inverts each bit of
the file on the first pass.  This inverting pass is additional to the
other overwriting passes.  For details of why this may be desirable, see
the section on "Propeller-head issues".  The inverting pass can be
selected by specifying the /invert switch in addition to any others.
You can test how this works by adding the /nodel and /zero switches as
well as /invert, and examining the file afterwards.

For use with Windows 3.x swapfiles, there is a switch that will cause
the very beginning of the file not to be overwritten.  This is to stop
Windows complaining that the file is corrupt the next time you go into a
Windows session.  Some people seem to have this problem, others don't.
Specify the /win3 switch when wiping a Windows 3.x swap file if you have
that problem.  The /win3 switch will also set the /nodel switch.  The
swap file is found in the root directory, and is usually called
386SPART.PAR.  It will be a hidden, system file, and to make it
overwritable by Scorch, you will have to run this command:

attrib -h -s 386spart.par

If you don't want Scorch to display text on screen when it runs, you can
specify the /silent switch in addition to any others.

More than one switch may be specified.  If more than one switch is
specified for the number of overwrites, or conflicting switches for
other options, only the more secure switch will take effect.

The switches may be specified in upper or lower case, and must be
separated from each other and from the program name with spaces.
Misspelled or non-existent switch specifications will be ignored without
error messages.


Changing the defaults
=====================

You can permanently change the shipping defaults for the number of
overwrites, deletion on or off, and inversion on or off, by specifying
the options you wish to change by command line switches in the
normal way, and adding the /makedefault switch, like this:

scorch /nodel /four /invert /valid /makedefault

When using the /makedefault switch, you do not need to specify a file
name.  If you do specify a file name, it will be ignored.  Changing the
default settings causes the copy of SCORCH.COM that is being run to have
data written to it.  This means that the PGP signature provided for the
original executable will no longer verify on the changed copy.

In order to allow the defaults to be changed back to the original
settings, switches have been provided to select the original default
settings as well as for the optional settings.

Scorch reports the new defaults when you use the /makedefault switch.
If you want to see what the current defaults are, run scorch with just
the /makedefault switch and no others.  When you run Scorch to delete
files, it reports the settings that you have selected from the command
line where they differ from the defaults.

The /silent and /win3 switches cannot be set as the defaults.  This is
for reasons of safety.


How it works
============

All overwrites are performed using standard DOS calls.  Files with the
read only bit set will not be overwritten (they would not be deleted by
the DOS delete function either).  You will see an error message saying
the file was not deleted.  If you have specified a filespec containing
wildcards, the program will carry on deleting the rest of the matching
files, if any.

If the extra inverting overwrite pass has been selected with /invert,
Scorch reads the original data from the file, inverts each bit, and
writes it back before doing the rest of the overwrite passes with
pseudo-random garbage.  This inversion is designed to counter the
supposed "magnetic remanence" attack (see "Propeller-head issues").

Files are then overwritten with garbage generated by a pseudo-random
number generator. The garbage generator produces a highly incompressible
pattern which does not repeat for 128 kilobytes.  This should be
sufficient to defeat all current disk-doubling inline disk compression
software, which would try to compress any repetitive overwrite pattern
down to a few bytes, leaving much of the original file content
untouched.  Those who are concerned by this issue may well reflect that
magnetic storage hardware is now very inexpensive.  The pseudo-random
number generator is reseeded from the system clock at the beginning of
each overwrite pass so that each pass writes different bytes to each
part of the disk.

Overwrites are performed from a 32 kilobyte buffer, mostly for speed.
Smaller buffers require more DOS calls to write the same amount of
garbage, which accounts for part of the reason that some other file
overwrite programs take as much as ten or twenty times as long as Scorch
to overwrite large files.

There is another reason to use a buffer of this size, though.  The
overwrites always use the whole buffer, so that files are overwritten in
multiple 32K chunks, even though the file may not be that long.  This
clears the unused space at the end of the last DOS cluster or allocation
unit on the disk, sometimes called the "cluster slack space", as well as
the part of the file that you see when you read the file itself.  This
slack space can otherwise harbour the contents of previous files that
happened to be on that part of the disk, and those contents can be found
by investigation with a sector level disk reader.

As a consequence of this feature, if you use the /nodel switch you will
find that overwritten files have grown to the next 32K boundary, unless
they were exactly a multiple of 32K in size to begin with.  This has no
consequences except the use of a bit more disk space if you keep all
your overwritten files.  In practice, you won't be doing that.  However,
if you don't want files to be overwritten beyond their original lengths,
you can prevent it by adding the /valid switch.  The /valid switch will
also preserve the original filename, pointer, date and time when files
are deleted.

After each overwrite pass, a DOS "file commit" call is performed on the
overwritten file, to make sure that the data is physically written to
the disk, not just to a disk cache in memory.  This should force writes
through software disk caches, but will probably not have any effect on
hardware disk caches, such as caching disk controllers with their own
memory.  It is not possible to to be sure how every caching system will
respond, so it is up to the user to satisfy himself as to the
performance of this software on his own equipment and software.  You may
see the activity display spinner start and stop when disk write caching
is active.  It will spin much faster when it is writing to cache memory,
but then have to wait while the cache commits the file to disk.

If the /nodel or /valid switch has not been specified, the file is then
truncated by a zero length write to the beginning of the file, the date
and time are zeroed, and the file is renamed to a single character,
prior to performing the standard DOS delete (the /valid switch on its
own will not prevent the DOS delete).  This has the effect of setting
the directory entry to point to cluster number zero, an invalid cluster,
as the first file cluster, and the file length to zero.  This will stop
file undeleters from finding even the overwritten remains of the file.
No remains of the original filename, time, or date will be visible in
the directory.  (NOTE THAT WINDOWS 95 AND 98 DEFEAT THIS OPTION)

Scorch cooperates with my other secure deletion utility, Real Delete, to
allow them both to be used together without speed penalty.  Scorch is
much faster than Real Delete, because Scorch uses a much larger write
buffer.  It can do this because the program size is not an issue for
Scorch, whereas it is important for Real Delete because Real Delete is a
memory resident program (TSR).

Real Delete turns ordinary DOS delete calls into secure, overwriting
deletes, automatically.  This is great for dealing with temporary files
that get created and deleted by applications without your knowledge.
However, this automatic action would mean that when Scorch has finished
overwriting a file and finally deletes it from the file system with a
DOS call, Real Delete would then start overwriting it AGAIN, and it
would take longer to do so than Scorch did.

To avoid this, Scorch signals Real Delete that it has already taken care
of the overwriting for the file in question.  That way, you can install
Real Delete to secure your normal deletions and the unseen ones that
your applications do for themselves, and still get the speed benefit of
using Scorch for particularly big files, such as Windows swap files.
This cooperative signal exchanging is only available in Real Delete
version 1.03 or later.  If you have an earlier version, you should
update it for use with Scorch.


Propeller-head issues
=====================

Speculation about the possibility of recovering the "original" contents
of a disk even after it has been overwritten seems to prey on the minds
of people who use software like Scorch.  Rumours about the abilities of
government agencies with special equipment abound on security related
internet newsgroups.  Lurkers in such groups are exhorted to overwrite
multiple times, or even to keep sensitive data only on floppies and burn
the floppies when through with the data.

In practice, however, a single overwrite will render your data
unrecoverable.  There is no commercial data recovery service that offers
to do recovery where data has been overwritten even once, and I know
people working for one of the best of these services that have tried to
do it.  It just isn't a practical proposition.

That does not mean that the speculation is entirely without foundation.
There are two techniques which can in theory recover earlier data from
overwritten disks.  One uses off-track reading, and the other uses
magnetic remanence.

Off-track reading relies on the fact that the disk heads are never
exactly aligned on the same track twice, an effect that is heightened
after a period of wear or when a floppy disk is written to in two
different drives.  This means that the remains of an earlier write may
be found running along the edge of the track of the latest write.  That
such data can be recovered has been demonstrated by investigation using
a scanning electron microscope.

However, it is not practical to recover data using this technique,
because the remnant track is too narrow to be read by practical drive
heads, even if they could be located precisely enough to stay on the
remnant track without picking up the much wider and stronger recently
written track.  Scanning the whole of the disk with an electron
microscope and interpreting the results would be extraodinarily
expensive.  Furthermore, there is no guarantee that the remnant track
contains the data that you are after.  On a hard disk, it is more likely
to be the original formatting pattern or a file written long ago than a
file recently written, due to intervening wear and changes in
micro-alignment.

The magnetic remanence technique relies on the fact that writing to a
disk does not entirely reverse the existing magnetism that is there
already.

Say that the magnetic polarity of an individual bit can vary on a scale
of -100 to +100.  The drive will recognise anything between, say, +20
and +100 as a one, and anything between, say, -100 and -20 as a zero (I
have no idea what the actual figures are, and they probably vary from
manufacturer to manufacturer).  The write head therefore does not have
to do a one hundred percent job of changing the existing magnetism to
write to the disk, which is just as well, because it can't do so
reliably.

Now it ought to be obvious that if you overwrite a zero with a zero, the
resulting bit will be closer to -100 on the scale than if you overwrite
a one with a zero.  The write head generates the same magnetic field to
write to both bits, but one of them is already most of the way to the
maximum possible.  Both bits will read as a zero to a standard digital
drive mechanism, but with special electronics, you could read the
relative strength of each bit in analogue form and see that they were
different on the scale of -100 to +100.

It should therefore be possible in theory at least to read through a
drive and interpret all the strong ones and weak zeros as "used to be a
one", and the strong zeros and weak ones as "used to be a zero".  In
fact, theoretically you ought to be able to extend that to read several
"layers" into the past, as three subsequent writes of a one in the same
spot would be stronger than two ones overwriting a zero, and one write
of a one over a zero over a one would result in a somewhat different
magnetic strength than two subsequent writes of a one over a zero.  I
think you get the idea.

The trouble is that this only works in theory.  In practice, the
possible magnetic strength of any particular bit varies a great deal in
comparison with other bits on the drive.  The coating itself is just not
that consistent.  So our imaginary scale is only -100 to +100 on
average, and some bits may allow -90 to +120, or vice versa.  Other
variables affect the "force" applied by the write head as it travels
across the surface, such as minor variations in the distance between the
head and the surface, or the polarity of the preceding bit.  This is,
after all, why standard drive electronics are designed to read the
magnetic pattern in a digital fashion, ignoring the minor analogue
irregularities.

Data recovery experts have told me that their experiments at trying to
recover overwritten data by analysing magnetic remanence have shown
that there is something to the theory, but that it is not usable in
practice.  A human being might be able to make out bits and pieces of
a text file recovered in this way, by using the context of a few
characters to guess what others imperfectly recovered might have been,
in the same way that you can understand what this worg is supposed to
be, but it is not possible to automatically recover files in bulk, or
do more than make good guesses about part of the contents of text files.
And this is after a single overwrite.

Nor is it likely that better equipment for reading the drive in an
analogue fashion would make much difference, as the inconsistencies are
in the mass produced drive that is being investigated, not in the
specialised equipment that is doing the reading.  If this were
practical, data recovery specialists would be offering it as a
commercial service.  They can charge thousands of pounds for recovering
data on a disk that has merely corrupted its filing system; there is no
way that they would pass up the money they could get for recovering
overwritten data, if they could do it.

These two theroretical concerns are the reason for the often seen advice
to overwrite multiple times.  In the case of off-track remains of
earlier writes, repeated overwrites have a better chance of slightly
slopping over both sides of the track that one desires to overwrite than
a single pass would of exactly covering the original track, assuming
certain ammount of play in the head positioning mechanism.  In the case
of magnetic remanence, sufficient multiple overwrites reduce the remnant
attributable to the original material to below the noise level, even in
theory.

Scorch has an extra measure to reduce magnetic remanence, in its
optional inversion pass.  Writing the inverse of the existing data, bit
for bit, reverses the effect of the last write (that which put the data
that we wish to expunge in place) equally for every bit.  This should
cancel out the remanence effect for both the original data layer and the
inverted layer once further random overwrites have taken place.  This
feature is, to the best of my belief, unique to Scorch.

Concern over these theoretical issues is not sensible for most users.
Certainly they are not of any importance for those concerned solely with
personal privacy.  Most people are more at risk in real terms from
Windows swap files, temporary files created and insecurely deleted by
applications or print spoolers without the user even knowing of their
existence, and dirty DOS disk buffers and cluster slack space preserving
the content of random bits of files all over the place.  Concern for the
number of times you overwrite the copy of the data you happen to know
about just doesn't deal with these other issues.

This being the case, why have I taken the trouble to include options for
action that I obviously consider to be misdirected overkill?  There are
four reasons:  Firstly, it was easy to put them in (it has taken me
longer to expound on the issues here than to write the options into the
software).  Secondly, I have worked in a commercial environment, where
the wise software writer gives the customer what he needs (so the
software does the job), and then gives him what he wants (so that the
software sells).  Thirdly, there are some people who have legitimate
reasons to specify multiple overwrites and other features, like an
employer who demands that they do so.  And fourthly, I am a bit of a
propeller-head myself, on the quiet.


Windows issues
==============

Microsoft Windows uses a swap file which saves snapshots of the computer
memory to disk.  This means that any data at all, whether you mean it to
be saved to a file or not, may end up on the disk.  The Windows swap
file is ordinarily not deleted, nor overwritten except when Windows
saves new snapshots of memory.  The swapfile can save memory from
Windows DOS sessions, as well as when working in Windows.

You can reduce this problem by Scorching the swap file after each
Windows session.  Scorch was developed especially for use with the
Windows 95 swap file.  Swap files are generally very large, so Scorch
was optimised for speed when overwriting large files.  It is ten or
twenty times faster than some other file wipers.

Windows 95 normally doesn't give you an opportunity to Scorch the swap
file when you shut down, so you will need to alter your computer setup
to use it.  You can make the scorching automatic, by following the
instructions below.  (Some notes for using this with Windows 98 follow
the Windows 95 method)


There are three things you need to do.


1- Alter your virtual memory (swap file) settings
.................................................

The first thing you must do is go into Windows 95 and change your
virtual memory settings.  If you don't do this, the windows swap file
will have been insecurely "deleted" by the time that the file wiper
gets to it, so the contents will remain on the disk.  Also, the
standard Windows 95 swap file grows and shrinks constantly, so any part
of the disk could have contents of this file on it.  To stop this, we
set the file to a constant size, and that stops it being shrunk to
zero when we shut down Windows too.

Here is how to proceed:

 Select "My Computer" from the desktop.
 Select the "Control Panel" folder.
 Select the "System" icon
 Select the "Performance" tab
 Press the "Virtual Memory" button

That gets you to the Virtual Memory settings.  Now:

 Click the switch for "Let me specify my own virtual memory settings"

 Set both "Minimum" and "Maximum" boxes to the same number.  (This
    will be the number of megabytes in your swap file, I use 32.  You
    may want more.  Too small a swap file will affect performance.)

 Click "OK"

 Shutdown and restart Windows (there will be a prompt inviting this).

 After the restart, close all the open folders, panels, etc.

 Shut down Windows from the task bar, selecting "Restart the computer
   in MSDOS mode" from the panel when it appears.  This is in
   preparation for the next part of the task.


2- Change the boot sequence to boot into DOS
............................................

Next, you have to stop your computer booting straight into Windows 95.
There are two different ways to do this, but only one is useful for our
purposes (an earlier edition of this doc file had this wrong).

Edit the C:\MSDOS.SYS file to change "BootGUI=1" to "BootGUI=0".  You
can also add a line saying "Logo=0" so you don't get the initial
graphic screen.  Essentially this restores the way that Windows used
to work in version 3.x.

MSDOS.SYS is a hidden file, so you must enter:

  attrib -h -r -s \msdos.sys

at the command line in order to make it accessible for editing.  Use a
plain ASCII DOS editor to edit the file, not a word processor.

Windows 95 may not let you do these things in a Windows DOS box, which
is why you were advised above to exit Windows 95 via the shut down
command and restart in MSDOS mode.


3- Run Windows via a DOS Batch file
...................................

Lastly, you must write a DOS batch file to use when you want to run
Windows 95.  This is so that when you shut Windows down in future,
execution will return to the batch file, and further commands can be
processed, in particular, a secure deletion of the swap file.  The batch
file should look like this:

 cd \windows
 win
 mode co80
 cd\
 scorch [win386.swp] /nodel

I named the batch file W.BAT so that I can run Windows just by typing
"w" and Enter.  If you name it WIN.BAT, it could get confused with
WIN.COM in the WINDOWS directory when you come to run it.

The "mode co80" line makes the "it is OK to turn off your computer"
Windows shut down screen go away and returns you to the command line
prompt.  The next line returns you to the root directory, so that Scorch
will be able to find the swap file.

Scorch then overwrites the swap file.  This takes about one second per
three megabytes on my computer.  You should wait for Scorch to finish
overwriting before turning off your computer.

If you find that Windows 95 does not return you to DOS at shutdown, or
Scorch does not run, two possible problems should be investigated.
First, if Windows is set to use some kind of "green" power management,
often found on laptops, it may be that during shutdown Windows turns off
the power before ever getting to DOS.  Second, for Scorch to work, the
executable (scorch.com) must be in the root directory or in a directory
that is specified in the DOS PATH environment variable (such as
c:\windows) or the DOS command line processor won't be able to find it.

I am grateful to a Scorch and Windows 98 user for the following
modifications to the above routine which may serve as a guide to using
the same method of swapfile wiping in Windows 98:

1. In Windows, go to
My Computer\ControlPanel\System\Performance\Virtual memory.  Click "Let
me specify my own virtual memory settings".   Enter identical settings
in both boxes.   I suggest 150 Mbytes.   Click OK.   Windows will tell
you what you've done and complain and ask you if you are sure you wish
to continue, click YES.   Windows will then want to re-boot.  Allow it
to do so.   After re-booting you can see the file in Windows Explorer as
Win386.SWP.   If you run games which require large swapfiles, or run
many programs simultaneously, you may need to increase the size.

2. As the system is re-booting, follow the screen instructions to enter
setup.  In setup, go to the Power tab and change "Automatic Power
Management" to "disabled".  Follow the screen instructions to save and
exit.

3. After you are back at Windows, find the MSDOS.SYS file.  This is
hidden and read-only, so you will need to go to MyComputer|View|Folder
Options|View|Advanced Settings|Files and Folders|Hidden Files.  Check
the "show all files" option, then "apply" and "OK".  When you find the
MSDOS.SYS file, right click to Properties.  Click Properties and uncheck
"Read-only" under Attributes, then "apply" and "OK".  Next, right-click,
select "Open with...", UNCHECK the "always use this program to open
...", and open with notepad.  Edit the C:\MSDOS.SYS file to change
"BootGUI=3D1" to "BootGUI=3D0".  Save the change, close, and replace the
check in the "Read-only" box under Attributes.

4.   Use Notepad to write the following simple Batch file.   Put it in
the root of your C: drive.   Give the batch file a name.   I suggest
W.bat, but any convenient letter or name will suffice, but NOT Win.bat
or confusion will occur with the Win.com which starts Windows.   Add it
as the last line of your Autoexec.bat file.   This will ensure that your
computer will go to Windows on startup as normal and that the wipe will
take place automatically on shutdown.

W.bat

CD\WINDOWS
Win
Mode co80
cd\
Scorch [win386.swp] /nodel
Scorch [any other file(s) you want wiped]

Windows will start just as before, except that the "Starting Windows 98"
screen will blink once as the W.bat file takes over from the
Autoexec.bat file.


How safe are you now?
.....................

Not very.  You still have many copies of bits and pieces of your deleted
files in dirty disk buffers and slack cluster space all over your disk.
You will also have temporary files that were created and insecurely
deleted by applications and print spoolers without you even knowing
about them.  You may even have some Windows WP files that contain bits
of other files within them, which people can see if they use the right
tools to look.  But at least there won't be copies of whatever Windows
last had in memory all over your disk.

If you feel that you need a higher level of security, then have a look
at Real Delete, my TSR file wiper, which will take care of many of the
issues above, and try out my Scour utility.  Consider working in DOS
only.  Also look at inline disk encryption like SecureDevice,
SecureDrive, or SFS, available elsewhere.


=========================================================
Copyright (c) Iolo Davidson - September 1996 - April 1999
=========================================================


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: ascii

iQCUAwUBNwhZIaCCHWDgRg99AQFvyAPyAvPJAxZbZLyEKwhJnqfybVO4RZl33tuN
52oq3njRY0EkStaBM5a447WDS6oFJ6GKERyB8YHWG+tHhIppzXdghbZqwYI6lIDT
opBx/TekQK7nQpAt6zfYvnfQ+awmLrjJdo/Yx3AzDge891TFM9wPgnQjkwwbaLGb
kqhBx4fG6g==
=Bp28
-----END PGP SIGNATURE-----
