home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Big Blue Disk 27
/
bbd27.zip
/
FSP.TXT
< prev
next >
Wrap
Text File
|
1988-10-24
|
74KB
|
2,047 lines
FLU_SHOT+, Version 1.4
A Form of Protection from
Viral and Trojan Programs
by
Ross M. Greenberg
and
Software Concepts Design
594 Third Avenue
New York, New York 10016
BBS:(212)-889-6438 1200|2400|N/8/1
FLUSHOT+ is a trademark of Software Concepts Design.
Copyright (C), 1988 by Software Concepts Design.
All Rights Reserved.
Not for Commercial Distribution without written permission by the
copyright holder. Noncommercial copying of this software and this
documentation is encouraged. Commercial Distribution is easily
defined: if you distribute this software, or the enclosed
documentation, for more than your cost of such distribution, then
you're a Commercial Distributor and require our written
permission. Not-for-profit organizations and computer user
groups, and their bulletin board systems (if any) are
specifically *not* considered commercial distributors.
By your using this software, you agree to the terms herein.
Specifically, that you do not have the right to copy this
software except as outlined above, and that you are granted a
license to use this software only by registering this software as
mentioned elsewhere in this document. (Legitimate subscribers to
the Big Blue Disk magazine may have a separate agreement allowing
them to use this code without registering, but the other terms of
this agreement are still to be agreed to before you can use the
program)
You also agree, and signify that agreement by using this
software, that Software Concepts Design and Ross M. Greenberg
will not be held liable for any reason for any cost you may
incur, or any potential income you might lose as a result of
using this software. Finally, this software is provided "AS IS",
meaning that what you see is what you get. If you use this
software and a tree falls on your house, or your spouse leaves
you for someone younger and more virile, please do not bother
having your lawyer call -- it isn't the fault of the software, no
matter what the lawyer tries to convince you!
Table of Contents
I. Introduction
a. What is a Trojan.....................................1
b. What is a Virus......................................4
c. The Challenge to the Worm............................6
II. About the FLUSHOT Series
a. A Brief History......................................8
b. FLU_SHOT+ Features and Enhancements..................9
c. Registering FLU_SHOT+................................10
d. Site Licensing of FLU_SHOT+..........................10
III. Using FLU_SHOT+
a. The FLUSHOT.DAT file.................................11
1. Protecting files from Write Access..............12
2. Protecting files from Read Access...............12
3. Excluding files.................................12
4. Checksumming files..............................13
5. Registering a TSR program.......................14
6. Protecting the FLUSHOT.DAT file.................14
7. Protection Recommendations......................15
8. Allowing "dangerous" programs to run............15
b. Running FLU_SHOT+....................................16
1. Checking CMOS - How often?......................16
2. Checksumming the in-memory table................16
3. Intercepting Direct Disk Writes Through INT13...17
4. What about INT26................................17
5. Turning off the header message..................17
6. Allowing trusted TSR's to work..................17
7. Disabling FLU_SHOT+.............................17
8. Disabling FLU_SHOT+ Toggle Display..............18
9. Forcing FLU_SHOT+ to only use the BIOS..........18
10. Putting FLU_SHOT+ to sleep when run.............18
IV. Interpreting a FLU_SHOT+ Trigger..........................19
V. How Good is FLUSHOT+, Really?.............................24
VI. Reward Offered............................................26
Introduction
What is a Trojan?
=================
Back in the good old days (before there were computers), there
was this bunch of soldiers who had no chance of beating a
superior force or of even making it into their fortress. They
had this nifty idea: present the other side with a gift. Once
the gift had been accepted, soldiers hiding within the gift would
sneak out and overtake the enemy from within.
We can only think of the intellectual giants of the day who would
accept a gift large enough to house enemy soldiers without
checking its contents. Obviously, they had little opportunity to
watch old WWII movies to see the same device used over and over
again. They probably wouldn't have appreciated Hogan's Heroes
anyway. No color TV's -- or at least not ones with reliable
reception.
Consider the types of people who would be thrilled at the concept
of owning their own rough hewn, large wooden horse! Perhaps they
wanted to be the first one on their block, or something silly
like that.
Anyway, you're all aware of the story of The Trojan Horse.
Bringing ourselves a bit closer to the reality we've all grown to
know and love, there's a modern day equivalent: getting a gift
from your BBS or user group which contains a little gem which
will attack your hard disk, destroying whatever data it contains.
In order to understand how a potentially useful program can cause
such damage when corrupted by some misguided soul, it's useful to
understand how your disk works, and how absurdly easy it is to
cause damage to the data contained thereon. So, a brief
technical discussion of the operation of your disk is in order.
For those who aren't concerned, turn the page or something.
Data is preserved on a disk in a variety of different physical
ways having to do with how the data is encoding in the actual
recording of that data. The actual *structure* of that data,
however, is the same between MS-DOS machines. Other operating
systems have a different structure, but that doesn't concern us
now.
Each disk has a number of "tracks". These are sometimes called
cylinders from the old type IBMer's. These are the same people
who call hard disks DASDs (Direct Access Storage Devices), so we
can safely ignore their techno-speak, and just call them tracks.
Tracks can be thought of as the individual little grooves on an
audio record, sort of.
Anyway, each track is subdivided into a number of sectors. Each
track has the same number of sectors. Tracks are numbered, as
1
are sectors. Any given area on the disk can be accessed if a
request is made to read or write data into or out of Track-X,
Sector Y. The read or write command is given to the disk
controller, which is an interface between the computer itself and
the hard disk. The controller figures out what commands to send
to the hard disk, the hard disk responds and the data is read or
written as directed.
The first track on the hard disk typically will contain a small
program which is read from the hard disk and executed when you
first power up your machine. The power up sequence is called
"booting" your machine, and therefore the first track is typical
known as the "boot track".
In order to read information from your disk in a logical
sequence, there has to be some sort of index. An unusual index
method was selected for MS-DOS. Imagine going to the card index
in a library, looking up the title you desire, and getting a
place in another index which tells you where on the racks where
the book is stored. Now, when you read the book, you discover
that only the first chapter of the book is there. In order to
find the next chapter of the book, you have to go back to that
middle index, which tells you where the next chapter is stored.
This process continues until you get to the end of the book.
Sounds pretty convoluted, right? You bet! However, this is
pretty much how MS-DOS does its "cataloguing" of files.
The directory structure of MS-DOS allows for you to look up an
item called the "first cluster". A cluster represents a set of
contiguous ("touching or in contact" according to Random House)
tracks and sectors. It is the smallest amount of information
which the file structure of MS-DOS knows how to read or write.
Based on the first cluster number as stored in the directory, the
first portion of a file can be read. When the information
contained therein is exhausted, MS-DOS goes to that secondary
index for a pointer to the next cluster. That index is called
the File Allocation Table, commonly abbreviated to "FAT". The
FAT contains an entry for each cluster on the disk. An FAT entry
can have a few values: ones which indicate that the cluster is
unused, another which indicates that the associated cluster has
been damaged somehow and that it should be marked as a "bad
cluster", and a pointer to the next cluster for a given file.
This allows for what is called a linked list: once you start
looking up clusters associated with a given file, each FAT entry
tells you what the next cluster is. At the end of the linked
list is a special indicator which indicates that there are no
more clusters associated with the file.
There are actually two copies of the FAT stored on your disk, but
no one really knows what the second copy was intended for.
Often, if the first copy of the FAT is corrupted for some reason,
a clever programmer could recover information from the second
copy to restore to the primary FAT. These clever programmers can
2
be called "hackers", and should not be confused with the thieves
who break into computer systems and steal things, or the "worms"
[Joanne Dow gets credit for *that* phrase!] who would get joy out
of causing you heartache!
But that heartache is exactly what can happen if the directory
(which contains the pointer to the first cluster a file uses),
the FAT (which contains that linked list to other areas on the
disk which the file uses), or other areas of the disk get
corrupted.
And that's what the little worms who create Trojan programs do:
they cause what at first appears to be a useful program to
eventually corrupt the important parts of your disk. This can be
as simple as changing a few bytes of data, or can include wiping
entire tracks clean.
Not all programs which write to your hard disk are bad ones,
obviously. Your word processor, spreadsheet, database and
utility programs have to write to the hard disk. Some of the DOS
programs (such as FORMAT), if used improperly, can also erase
portions of your hard disk causing you massive amounts of grief.
You'd be surprised what damage the simple "DEL" command can do
with just a simple typo.
But, what defines a Trojan program is its delivery mechanism: the
fact that you're running something you didn't expect. Typical
Trojan programs cause damage to your data, and were designed to
do so by the worms who writhe in delight at causing this damage.
May they rot in hell -- a mind is a terrible thing to waste!
Considering the personality required to cause such damage, you
can rest assured that they have few friends, and even their
mother doesn't like to be in the same room with them. They sit
back and chortle about the damage they do with a few other lowly
worms. This is their entire social universe. You should pity
them. I know that I do.
3
Introduction
What is a Virus?
================
Trojan programs are but a delivery mechanism, as stated above.
They can be implemented in a clever manner, so that they only
trigger the malicious part on a certain date, when your disk
contains certain information or whatever. However they're coded,
though, they typically affect the disk only in a destructive
manner once triggered.
A new breed of programs has the capability of not only reserving
malicious damage for a given event's occurrence, but of also
replicating itself as well.
This is what people refer to when they mention the term "Virus
Program".
Typically, a virus will spread itself by replicating a portion of
itself onto another program. Later, when that normally safe
program is run it will, in part, execute a set of instructions
which will infect other programs and then potentially, trigger
the Trojan portion of the program contained within the virus.
The danger of the virus program is twofold. First, it contains a
Trojan which will cause damage to your hard disk. The second
danger is the reason why everyone is busy building bomb shelters.
This danger is that the virus program will infect other programs
and they in turn will infect other programs and so forth.
Since it can also infect programs on your floppy disks, you could
unknowingly infect other machines! Pretty dangerous stuff,
alright!
Kenneth van Wyck, one of the computer folks over at Lehigh
University, first brought a particular virus to the attention of
the computer community. This virus infects a program, which
every MS-DOS computer must have, called COMMAND.COM. This is the
Command Line Interpreter and is the interface between your
keyboard and the MS-DOS operating system itself. Whatever you
type at the C> prompt will be interpreted by it.
Well, the virus subverts this intended function, causing the
infection of neighboring COMMAND.COMs before continuing with
normal functionality of the command you typed. After a certain
number of "infections", the Trojan aspect of the program goes
off, causing you to lose data.
The programmer was clever. But still a worm. And still
deserving of contempt instead of respect. Think of what good
purposes the programmer could have put his or her talents to
instead of creating this damage. And consider what this
programmer must do, in covering up what they've done. They
certainly can't tell anyone what they've accomplished.
Justifiable homicide comes to mind, but since the worms they must
4
hang around are probably as disreputable as they are, they must
hold their little creation a secret.
A pity. Hopefully, the worm is losing sleep. Or getting a sore
neck looking behind them wondering which of their "friends" are
gonna turn them in for the reward I list towards the end of this
document.
5
Introduction
The Challenge to the Worm
=========================
When I first released a program to try to thwart their demented
little efforts, I published this letter in the archive (still in
the FLU_SHOT+ archive of which this is a part of). What I say in
it still holds:
As for the designer of the virus program: most
likely an impotent adolescent, incapable of
normal social relationships, and attempting to
prove their own worth to themselves through
these type of terrorist attacks.
Never succeeding in that task (or in any
other), since they have no worth, they will
one day take a look at themselves and what
they've done in their past, and kill
themselves in disgust. This is a Good Thing,
since it saves the taxpayers' money which
normally would be wasted on therapy and
treatment of this miscreant.
If they *really* want a challenge, they'll try
to destroy *my* hard disk on my BBS, instead
of the disk of some innocent person. I
challenge them to upload a virus or other
Trojan horse to my BBS that I can't disarm.
It is doubtful the challenge will be taken:
the profile of such a person prohibits them
from attacking those who can fight back.
Alas, having a go with this lowlife would be
amusing for the five minutes it takes to
disarm whatever they invent.
Go ahead, you good-for-nothing little
slimebucket: make *my* day!
Alas, somebody out there opted to do the cowardly thing and to
use the FLUSHOT programs as a vehicle for wrecking still more
destruction on people like you. The FLUSHOT3 program was
redistributed along with a companion program to aid you in
reading the documentation. It was renamed FLUSHOT4. And the
reader program was turned into a Trojan itself.
I guess the programmer involved was too cowardly to take me up on
my offer and prefers to hurt people not capable of fighting back.
I should have known that, I suppose, but I don't normally think
of people who attack innocents. Normally, I think of people to
respect, not people to pity, certainly not people who must cause
such damage in order to "get off".
6
They are below contempt, obviously, and can do little to help
themselves out of the mire they live in.
Still, a worm is a worm.
7
About FLUSHOT
A Brief History
===============
The original incarnation of FLU_SHOT was a quick hack done in my
spare time. It had a couple of bugs in it which caused it to
trigger when it shouldn't, and a few conditions which I had to
fix. A strangeness in how COMMAND.COM processed certain
conditions when I "failed" an operation caused people to lose
more data than they had intended -- certainly not my intent!
FLU_SHOT was modified and became FLUSHOT2. It included some
additional protections, protecting some other important system
files, and protecting against direct disk writes which can be
used to circumvent FLUSHOT's protection mechanisms.
Additionally, FLUSHOT2 forced an exit of the program currently
running instead of a fail condition when you indicated that an
operation should not be carried out.
FLUSHOT2 was also now distributed in the popular archive format
(have you remembered to send your shareware check into Phil Katz
for his efforts? You really should. It ain't that much money!).
Next came FLUSHOT3. A bug was fixed which could have caused
certain weird things when you denied direct disk I/O to certain
portions of DOS 3.x.
The enhancements to FLUSHOT3 included the ability to enter a 'G'
when FLUSHOT was triggered. This allowed FLUSHOT to become
inactive until an exit was called by the foreground task. So,
when you used some trustworthy program which did direct disk I/O,
you wouldn't be pestered with constant triggering after you enter
the 'G'. Primarily this was a quick hack to allow programs such
as the FORMAT program to run without FLUSHOT being triggered each
time it tried to do any work it was supposed to.
Additionally, a CMOS RAM check was installed. If a foreground
program attempted to change CMOS memory, you'd be advised.
What the heck is CMOS memory, you might be asking. Good
question. In AT class and better machines, certain important
parameters (such as the type of hard disk you're using, or how
much memory there is in your machine) are stored up in special
non-volatile memory, called CMOS.
If this gets changed, you might have a problem when you reboot.
FLUSHOT3 sends at least one little slimebucket back to the
drawing board, because it will restore the CMOS and prevent this
hassle from occurring.
8
About FLUSHOT
FLU_SHOT+ Features and Enhancements
===================================
This release of FLU_SHOT has a new name: FLU_SHOT+. Because
FLUSHOT4 was a Trojan, I opted to change the name. Besides,
FLU_SHOT+ is the result of some real effort on my part, instead
of being a part-time quick hack. I hope the effort shows.
FLUSHOT is now table driven. That table is in a file which I
call FLUSHOT.DAT. It exists in the root directory on your C:
drive. However, I'll advise you later on how to change its
location so that a worm can't create a Trojan to modify that
file.
This file now allows you to write and/or read protect entire
classes of programs. This means that you can write protect from
damage all of your *.COM, *.EXE, *.BAT, and *.SYS files. You can
read protect all of your *.BAT files so that a nasty program can
not even determine what name you used for FLU_SHOT+ when you
invoked it!
Additionally, you can now automatically check programs when you
first invoke FLU_SHOT+ to determine if they've changed since you
last looked at them. Called checksumming, it allows you to know
immediately if one of the protected programs has been changed
when you're not looking. Additionally, this checksumming can
even take place each time you load the program for execution.
Also, FLU_SHOT+ will advise you when any program "goes TSR". TSR
stands for "Terminate and Stay Resident", allowing pop-ups and
other useful programs to be created. A worm could create a
program which leaves a bit of slime behind. Programs like
Borland's SideKick program, a wonderful program and certainly not
a Trojan or virus, is probably the best known TSR. FLU_SHOT+
will advise you if any program attempts to go TSR which you
haven't already registered in your FLUSHOT.DAT file.
Finally, FLU_SHOT+ will also now pop-up a little window in the
middle of your screen when it gets triggered. It also will more
fully explain why it was triggered. The pop-up window means that
your screen won't get screwed up beyond recognition -- unless
you're in graphics mode when it pops up. Sorry, 'dems the
breaks!
9
About FLUSHOT
Registering FLU_SHOT+
=====================
FLU_SHOT+ is not a free program. You're encouraged to use it, to
distribute it to your friends and co-workers. If you end up not
using it for some reason, let me know why and I'll see if I can
do something about it in the next release.
But, the right to use FLU_SHOT+ is contingent upon you paying for
the right to use it. I ask for ten dollars as a registration
fee, plus a four dollar shipping and handling fee. This entitles
you to get the next update shipped to when available. And allows
you to pay me, in part, for my labor in creating the entire
FLU_SHOT series. I don't expect to get my normal consulting rate
or to get a return equal to that of other programs which I've
developed and sell through more traditional channels. That's not
my intent, or I would have made FLU_SHOT+ a commercial program
and you'd be paying lots more money for it.
Some people are uncomfortable with the shareware concept, or
believe that there ain't no such thing as Trojan or Virus
programs, and that a person who profits from the distribution of
a program such as FLU_SHOT must be in it for the money.
I've created an alternative for these folks. I'll call it
"charityware" [first called that, to my knowledge, by Roedy
Green]. You can also register FLU_SHOT+ by sending me a check
for $10 made out to your favorite charity. Be sure to include a
stamped and addressed envelope. I'll forward the monies onto
them and register you fully.
Of course, if you wish, you can send me a check for more than
$10. I'll cash it gladly (I'm no fool!).
[Subscribers of the Big Blue Disk are still encouraged to
register this program, although a special arrangement with Big
Blue allows them to distribute this program without requiring
that subscribers of the program register it. However, if you
don't register it diorectly with us, you won't be entitled to any
technical support from us, nor will you be advised of future
releases. For more information, contact Big Blue directly.
They're pretty reasonable folks and can provide you with very
good technical support.]
Site Licensing of FLU_SHOT+
===========================
So, you run the computer department of a big corporation, you got
a copy of FLU_SHOT+, decided it was wonderful and that it did
everything you wanted and sent in your ten bucks. Then you
distributed it to your 1000 users.
10
Not what is intended by the shareware scheme. *Each* site using
FLU_SHOT+ should be registered. That's ten bucks a site, me
bucko! Again, make the check out to charity if you're
uncomfortable with the idea of a programmer actually deriving an
income from their work.
However, if you've really got 1000 computers, you should give me
a call. As much as I'd like to get $10 for each site, that
wouldn't be fair to you. So, quantity discounts are available.
Shipping and Handling
=====================
Each order for FLU_SHOT+ must also include a $4 shipping and
handling charge. Sorry, but the economics don't allow me not to.
11
Using FLU_SHOT+
The FLUSHOT.DAT file
====================
FLU_SHOT+ is table driven by the contents of the FLUSHOT.DAT
file. This file normally exists in the root directory of your C:
drive (C:\FLUSHOT.DAT).
A little later in this document you'll see how to disguise the
data file name, making life tougher for the worms out there. But
for the purposes of this document, we'll assume that the file is
called C:\FLUSHOT.DAT.
The FLU_SHOT+ program will read this data file exactly once. It
reads the data from the data file into memory and overwrites the
name of the data file in so doing. A little extra protection in
hiding the name of the file.
This data file contains a number of lines of text. Each line of
text is of the form:
<Command>=<filename><options>
Command can be any one of the following characters:
P - Write Protect the file named
R - Read Protect the file named
E - Exclude the file named from matching P or R lines
T - The named file is a legitimate TSR
C - Perform checksum operations on the file named
The filename can be an ambiguous file if you wish for all
commands except the 'T' and 'C' commands. This means that:
C:\level1\*.COM
will specify all COM files on your C: drive in the level1
directory (or its sub-directories). Specifying:
C:\level1\*\*.EXE
would specify all EXE files in subdirectories under the C:\level1
directory, but would not include that directory itself.
You can also use the '?' operator to specify ambiguous characters
as in:
?:\usr\bin\?.COM
would be used to specify files on any drive in the \usr\bin
directory on that drive. The files would have to be single
letter filenames with the extension of 'COM'.
Ambiguous file names are not allowed for the 'T' and 'C' options.
12
Using FLU_SHOT+
Protecting files from Write Access
==================================
Use the 'P=' option to protect files from write access. To
disallow writes to any of your COM, EXE, SYS, and BAT files,
specify lines of the form:
P=*.COM
P=*.EXE
P=*.SYS
P=*.BAT
which protects these files on any disk, in any directory.
Protecting files from Read Access
=================================
Similarly, you can use the 'R' command to protect files from
being read by a program (including the ability to 'TYPE' a
file!). To prevent read access to all of your BAT files, use a
line such as:
R=*.BAT
Combinations of R and P lines are allowed, so the combination of
the above lines would prevent read or write access to all batch
files.
Excluding files
===============
Programmers in particular should find usage for the 'E' command.
This allows you to exclude matching filenames from other match
operations. Assume you're doing development work in the
C:\develop directory.
You could exclude FLU_SHOT+ from being triggered by including a
line such as:
E=C:\develop\*.*
Of course, you might have development work on many disks under a
directory of that name. If you do, you might include a line
which looks like:
E=?:\develop\*.*
or
E=*\develop*
13
Checksumming files
==================
This line is a little more complicated than others and involves
some setup work. It's worth it though!
A checksum is a method used to reduce a files validity into a
single number. Adding up the values of the bytes which make up
the file would be a simple checksum method. Doing more complex
mathematics allows for more and more checking information to be
included in a test.
If you use a lie on the form:
C=C:\COMMAND.COM[12345]
then when FLU_SHOT+ first loads it will check the validity of the
file against the number in the square brackets. If the checksum
calculated does not match the number presented, you'll be advised
with a triggering of FLUSHOT, which presents the correct
checksum.
When you first set up your FLUSHOT.DAT file, use a dummy number
such as '12345' for each of the files you wish to checksum.
Then, when you run FLUSHOT, you should copy down the "erroneous"
checksum presented. Then, edit the FLUSHOT.DAT file and replace
the dummy number with the actual checksum value you had copied
down. Voila! If even one byte in the is changed, you'll be
advised the next time you run FLU_SHOT+.
But wait! There's more! Not available in stores!
Sorry. I got carried away.
Seriously, there is more. When a "checksummed" file is loaded by
MS-DOS, it will, by default, be checksummed again. So, if you
had a line such as:
C=C:\usr\bin\WS.COM[12345]
the venerable old WordStar program (still *my* editor of choice!)
would be checksummed each time you went to edit a file.
Of course, you might not want the overhead of that checksumming
to take place each time you load a program. Therefore, a few
switches have been added. The switches are place immediately
after the ']' in the checksum line:
C=C:\usr\bin\WS.COM[12345]<switch>
These switches are:
,n - will only checksum the file only 'n' times. Only
one digit allowed.
14
- - Only checksum this file when FLU_SHOT+ first
loads. ',1' and '-' are equivalent.
+ - Only checksum this file when it is loaded and
executed, not when FLU_SHOT+ first loads
Therefore, if you wished to only check your WS.COM file when you
first loaded the FLU_SHOT+ program, you'd specify a line as:
C=C:\usr\bin\ws.com[12345],1
or
C=C:\usr\bin\ws.com[12345]-
If you wished to checksum your program called "MY_PROG.EXE" only
when it was used, try:
C=C:\path\MY_PROG.EXE+
Registering a TSR program
=========================
Any unregistered TSR program which is run after FLU_SHOT+ will
cause a trigger when they "go TSR". You can register a program
so no trigger goes off by specifying it in a line such as:
T=C:\usr\bin\tsr_s\sk.com
which will keep FLU_SHOT+ from complaining about sk.com. Make
sure to take a look at the '-T' option, specified in the next
section.
Protecting the FLUSHOT.DAT file
===============================
Obviously, the weak link in the chain of the protection which
FLU_SHOT+ offers you is the FLUSHOT.DAT file.
You would think that you'd want to protect the FLUSHOT.DAT file
from reads and writes as specified above. However this, too,
leaves a gaping security hole: memory could be searched for it,
and it could be located that way. A better alternative exists.
In the distribution package for FLUSHOT+ exists a program called
FLU_POKE.COM. This program allows you to specify the new name
you wish to call the FLUSHOT.DAT file. Simply type:
FLU_POKE <flushot_name>
where <flushot_name> represents the full path filename of your
copy of FLU_SHOT+.
You'll be prompted for the name of the FLUSHOT.DAT file. Enter
the name you've selected (remember to specify the disk and
15
directory as part of the name). Voila! Nothing could be easier.
Protection Recommendations
==========================
Here's a sample FLUSHOT.DAT file, basically the same one included
in the archive. Your actual checksums will differ, and you may
want to modify what files and directories are protected.
Obviously, your exact needs are different than mine, so consider
this a generic FLUSHOT.DAT:
P=*.bat
P=*.sys
P=*.exe
P=*.com
R=*AUTOEXEC.BAT
R=*CONFIG.SYS
E=?\dev\*
C=C:\COMMAND.COM[12345]-
C=C:\IBMBIO.COM[12345]-
C=C:\IBMDOS.COM[12345]-
Allowing "dangerous" programs to run
====================================
In some cases, though, you'll still want the ability to ler
"trusted" programs to run -- even if they are potentially
dangerous. A good example of this is the DOS FORMAT program:
here is a program specifically designed to overwrite the data on
your disk in such a way that it would be difficult, at best, to
recover. Yet, the program is a necessary part of your day-to-day
computer usage.
Therefore, the 'X=' switch has been added in to allow a program
such as FORMAT to run without interruption. THIS IS A POTENTIAL
SECURITY HOLE. To prevent an 'X=' program from being corrupted,
I suggest you also include any 'X=' program as both a 'C=' and a
'P=' program as well: any writes to the file would cause
FLU_SHOT to trigger, and you wouldn't be able to run a modified
program without first giving FLU_SHOT permission. Use 'X='
sparingly. I'm rather uncomfortable with it myself.
16
Invoking FLU_SHOT+
Running FLUSHOT+
================
For extra protection, after you've run FLU_POKE, you should
rename the FLU_SHOT+ program is something unique and meaningful
to you, but not a worm.
Assuming you didn't rename it, however, you could invoke the
program simply by typing:
FSP
when at the prompt. That's all there is to it. When you're
satisfied, you can add it to your AUTOEXEC.BAT file, after all of
your trusted programs have run.
But there are some options you should know about:
Checking CMOS - How often?
==========================
The CMOS, as described earlier in this document, is a spot
wherein a worm can just make things a bit miserable for you when
you next boot your system. However, FLU_SHOT+ allows you to
protect the contents of your CMOS against such a worm.
*CMOS Only exists on AT class and better machines!!!*
You must specify the '-C' option when you invoke the FLU_SHOT+
program in order to have your CMOS safeguarded. There is a check
done whenever DOS is accessed to determine if the CMOS has
changed. This causes a slight performance penalty. CMOS is
checked on a regular basis -- a reasonable trade-off between the
utility of the CMOS check and the annoyance of a slight
performance degradation. The default is set to one second. You
may modify that default, if you wish, by using the '-In' option,
where the 'n' represents how frequently, in seconds you wish to
have CMOS checked.
Checksumming the in-memory table
================================
Since the wily worm may well be able to thwart some of the
efforts of FLU_SHOT+ by playing nasty games with the in-memory
copy of the FLUSHOT.DAT file, FLU_SHOT+ will also check this
table against a checksum it generates on a regular basis. If the
table gets corrupted, you'll be advised of it. This table is
checked with the same frequency as the CMOS is checked, and this
frequency can, therefore, be changed with the '-In' option as
well.
17
Intercepting Direct Disk Writes Through INT13
=============================================
The default operation of FLU_SHOT+ is to intercept and examine
every call to the direct disk routines. You can *disable* this
by including the '-F' switch on your command line:
FSP -F
This is not recommended, but exists primarily for developers who
can't use the constant triggering one of their programs may
cause.
What about INT26
================
Similarly, the same exists for the direct writes which normally
are only made by DOS through interrupt 26. Again, I do not
recommend you disable the checking, but if you desire to do so,
use the '-D' switch.
Turning off the header message
==============================
If you've no desire to see the rather lengthy welcome message
which is displayed when you first use FLU_SHOT+, use the '-h'
switch.
Allowing Trusted TSR's to Work
==============================
Normally, you'd load all of your trusted TSR's before FLUSHOT+ is
loaded from within your AUTOEXEC.BAT file. However, you might
want to use SideKick once in a while, removing it from memory as
you desire. This could cause some problems, since SideKick, and
programs like it, take over certain interrupts, and FLU_SHOT+
could get confused about whether this is a valid call or a call
that shouldn't be allowed. Normally, FLU_SHOT+ will trigger on
these calls, which is safer, but can be annoying. If you use the
special '-T' switch upon program invocation, then calls which
trusted TSR's (those specified with the 'T=' command in your
FLUSHOT.DAT file) make will be allowed. Understand, please, that
this basically means that calls made by a Trojan while a trusted
TSR is loaded may not be caught. Please, use this switch with
caution!
Disabling FLU_SHOT+
===================
There may be times when you're about to do some work which you
know will trigger FLU_SHOT+. And you might not want to be
bothered with all of the triggering, the pop-up windows and your
need to respond to each trigger. If you look in the upper right
hand corner of your screen, you'll see a '+' sign. This
indicates that FLU_SHOT+ is monitoring and attempting to protect
your system. Depress the ALT key three times. Notice that the
'+' sign' turned into a '-'? Well, FLU_SHOT+ is now disabled,
18
and will not trigger on any event. If you depress the ALT key
three more times, you'll see the '-' turn back into a '+' -- each
time you depress the ALT key three times, FLU_SHOT+ will toggle
between being enabled and disabled.
Disabling FLU_SHOT+ Toggle Display
==================================
Alas, there are graphics applications which will be screwed up be
the '-' or '+' in the upper right hand corner of your display.
Therefore, if you depress the CTRL key three times, you'll be
able to toggle the display capability of FLU_SHOT+. The default
configuration of FLU_SHOT+ is to "come up" with display turned
on. You can reverse this capability if you include the '-G' (for
graphics) switch on your command line when you run FLU_SHOT+.
Forcing FLU_SHOT+ to only use the BIOS
======================================
Certain machines are not totally compatible with the IBM BIOS,
which is the BIOS for which FLU_SHOT+ was written. Because
FLU_SHOT has to be able to deal with the hardware in a pretty
direct manner in order to "pop-up" a screen, these machines were
not able to use FLU_SHOT. If you specify the '-B' switch in your
command line when you first run FLU_SHOT+, then only the BIOS
will be used for screen output. This is *drastically* slower
than direct screen memory writes (the method used unless you
specify to use the BIOS), but at least it works.
Putting FLU_SHOT+ to sleep when run
===================================
One of the idiosyncrasies of DOS is how a batch file is
processed. Basically, DOS opens the batch file, reads the next
command, closes the batch file, executes the command, and then
starts over again until the batch file is exhausted of commands.
This would, normally, not be a problem, but can become when you
opt to place the FLU_SHOT command line in your AUTOEXEC.BAT file
*and* you've opted to Read Protect (with the 'R=' option) the
AUTOEXEC file itself: you'll be advised that some program is
reading this protected file. Not a big deal, really, but
certainly a hassle when you fist boot up your system. Therefore,
protections within FLU_SHOT are not turned on a certain amount of
time. The default is set to ten seconds, or until you enter a
key. You can modify the default "sleep" time by entering a '-Sn'
option on the command line, where 'n' represents the number of
eighteenths of a second (1/18) you wish to have FLU_SHOT+ sleep
before becoming active. Since you will most likely have
FLU_SHOT+ as one of the final commands in your AUTOEXEC.BAT, you
probably won't have to modify this parameter, but the capability
exists, nonetheless.
19
Interpreting a FLU_SHOT+ Trigger
================================
So, you've run FLU_SHOT+, and you're at your C> prompt. Great!
Now stick a blank disk which you don't care about into your A:
drive and try to format it.
Surprise! FLU_SHOT+ caught the attempt! You have three choices
now: typing 'Y' allows the operation to continue, but the next
one will be caught as well. Typing a 'G' (for Go!) allows the
operation to continue, disabling FLU_SHOT+ until an exit from the
program is made. When FLU_SHOT+ is in the 'G' state, a 'G' will
appear in the upper right hand corner of your screen.
Any other key will cause a failure of the operation to occur.
When you've got FLU_SHOT+ running and you get signaled that there
is a problem, you should think about what might have caused the
problem. Some programs, like FORMAT, or the Norton Utilities or
PC-Tools, or DREP have very good reasons for doing direct reads
and writes to your hard disk. However, a public domain checkbook
accounting program doesn't. You'll have to be the judge of what
are legitimate operations and which are questionable.
There is no reason to write to IBMBIO or IBMDOS, right?
Wrong!
When you format a disk with the '/S' option, those files are
created on the target diskette. The act of creating, opening up
and writing those files will trigger FLU_SHOT+ as part of its
expected operation. There are many other legitimate operations
which may cause FLU_SHOT+ to trigger.
So will copying a COM or EXE file if you have those protected
with a 'P=' command. FLU_SHOT+ is not particularly intelligent
about what is allowed and what isn't. That's where you, the
pilot, get to decide.
Here's a fuller listing of the messages which you might see when
you're using FLU_SHOT+:
Checking ===><filename>
This message is displayed as FLU_SHOT+ checks the checksum on all
of the "C=" files when you first invoke FLU_SHOT+. The files
must be read in from disk, their checksum calculated and then
compared against the value you claim the checksum should equal.
20
If the checksum does *not* equal what you claim it should (which
means that the file may have been written to and might therefore
be suspect), a window will pop up in the middle of your screen:
+===============================================================+
| Bad Checksum on <filename> |
| Actual Checksum is: <checksum> |
|Press "Y" to allow, "G" to go till exit, any other key to exit.|
+===============================================================+
This message simultaneously advises you there is a problem with
the checksums not matching, shows you what the checksum should be
and then awaits your response.
Except for the initial run of FLU_SHOT+, if you type a 'Y' or a
'G', then the program will load and execute. Typing any other
key will cause the program to abort and for you to be returned to
the C> prompt. When FLU_SHOT+ is in the 'G' state, a 'G' will
appear in the upper right hand corner of your screen.
If this is the initial run of FLU_SHOT+, however, you'll be
advised of the program's actual checksum, but FLU_SHOT+ will
continue to run, checking all remaining "C=" files in the
FLUSHOT.DAT file.
If you're running a program and you see a screen like:
+================================================================+
| ? WARNING! TSR Request from an unregistered program! |
|Number of paragraphs of memory requested (in decimal) are:<cnt>|
| (Press any key to continue) |
+================================================================+
you're being advised that a program is about to go TSR. If this
is a program you trust (such as SideKick, of KBHIT, or a host of
other TSR programs you've grown to know and love), then you
should considering installing a "T=" line in the FLUSHOT.DAT file
so that future runs of this program will not trigger FLU_SHOT+.
However, if you get this message when running a program you don't
think has any need to go TSR (such as the proverbial checkbook
balancing program), you should be a little suspicious. Having a
TSR program is not, in of and of itself, something to be
suspicious of. But having one you don't expect --- well, that's
a different story.
Most TSR's "hook into" an interrupt vector before they go TSR.
These hooks might intercept and process key strokes ("hotkeys"),
or they might hook and intercept direct disk writes themselves.
In any event, FLU_SHOT+ (in this version!) doesn't have the
smarts to do more than advise you of the TSR'ing of the program.
If you're truly suspicious, reboot your machine immediately!
21
If a program attempts to write directly to the interrupts which
are reserved for disk writes, FLU_SHOT+ will also be triggered
and you'll see something like:
+===============================================================+
|====>Direct Disk Write attempt by program other than DOS! <====|
| (From Interrupt <xx>) |
|Press "Y" to allow, "G" to go till exit, any other key to fail.|
+===============================================================+
where the <xx> represents either a 13 (indicating a direct BIOS
write to the disk) or a 26 (indicating a direct DOS write).
Again, pressing a 'Y' or a 'G' allows the operation to continue,
pressing any other key will cause the operation to return a
failed status to DOS, and the operation will not take place. When
FLU_SHOT+ is in the 'G' state, a 'G' will appear in the upper
right hand corner of your screen.
If an attempt is made to format your disk, which may be a
legitimate operation made by the DOS FORMAT program, you'll see a
message such as:
+===============================================================+
| ====>Disk being formatted! Are You Sure?<==== |
| |
|Press "Y" to allow, "G" to go till exit, any other key to fail.|
+===============================================================+
which follows similarly to the direct disk write operations. You
should question whether the format operation is appropriate at
the time and take whatever action you think is best.
If one of your protected files is about to be written to, you'll
see a message like:
+===============================================================+
|Write access being attempted on: |
| <filename> |
|Press "Y" to allow, "G" to go till exit, any other key to fail.|
+===============================================================+
where <filename> represents the file you're trying to protect
from these write operations. Your red flag should fly, and you
should question why the program currently running should cause
such an operation.
22
You may also see the same type of message when one of your "Read-
Protected" files is being accessed:
+===============================================================+
|Read Access being attempted on: |
| <filename> |
|Press "Y" to allow, "G" to go till exit, any other key to fail.|
+===============================================================+
Again, the same red flag should fly, but it doesn't mean that
you're infected with some nasty virus program! It could be
something harmless or intended. You'll have to be the judge.
+===============================================================+
|Open File with Write access being attempted on: |
| <filename> |
|Press "Y" to allow, "G" to go till exit, any other key to fail.|
+===============================================================+
If you see the above message: Don't Panic! When a program opens
a file, it may open the file for different types of access. One
access method prohibits writing to the file. Another allows you
to write to the file. However, lazy programmers (myself included
in this category from time to time) will often open a file for
read *and* write access, even though they have no intention of
ever doing a write into the file. FLU_SHOT+ isn;t smart enough
to be able to figure out what a program *might* do in the future,
so it will alert you to an attempt to open the indicated
protected file with write access allowed. Again, you'll have to
consider whether the program opening the file is a "trusted"
program or not and you'll have to then decide what action to
take.
There are three separate messages you'll see if a program
attempts to rename a protected file (you'll only see one of these
messages at a time, though):
+===============================================================+
|FCB Rename being attempted on source file: |
|FCB Rename being attempted on target file: |
|Handle Rename being attempted on: |
| <filename> |
|Press "Y" to allow, "G" to go till exit, any other key to fail.|
+===============================================================+
This indicates what type of operation is attempting to rename a
protected file. FCB's are a relic of the older CP/M days, and
"handles" are a newer concept, a little more modern. In any
event, this tells you that a file is being renamed. It is
possible that a trojan or virus writer will attempt to rename an
existing protected file to some other name, then rename a
trojaned or virused program in its stead. FLU_SHOT will alert yu
to this action: again, though, you'll have to decide what to do
about it.
23
+===============================================================+
|Delete being attempted on: |
| <filename> |
|Press "Y" to allow, "G" to go till exit, any other key to fail.|
+===============================================================+
Pretty much self-evident as to what's happening here, there are
very few reasons why one of the files you've opted to protect
should be deleted.
Finally, you may see a message like:
+===============================================================+
| ====>CMOS has been changed!<==== |
| |
| Hit "Y" to continue, any other key to restore CMOS. |
+===============================================================+
which indicates that your CMOS has been changed while you weren't
looking. Or maybe you were: if you're running a setup program
which changes the date or the time, or the disk type attached to
your AT class machine, this message should pop up. Losing your
CMOS is not fatal, but can be an annoyance. If you hit a 'Y',
then the new setting of the CMOS will be stored and you'll be
able to continue, with alerts to any other change to the CMOS.
Any other key will result in the original setting of the CMOS
being restored.
24
How Good is FLUSHOT+, Really?
FLU_SHOT+ is a pretty handy piece of code. But, it can't
absolutely protect you from a worm. No software can do that.
Discussed below are some hardware devices which no worm can get
through.
There are ways around FLU_SHOT+. I'm of two minds about
discussing them, since the worms out there are reading it this,
too. So I'll only discuss them in passing. And I'll tell you
what I use here to protect myself from worms. First, though, a
little story to tell you what it's like here, and how I protect
myself from getting wormed.
The RamNet Bulletin Board System site I run is open access. No
need to register, or to leave your phone number or address,
although a note to that effect is always appreciated. As
mentioned above, I dare the worm to try to affect the disk of
somebody who can fight back. A couple of of worms have tried and
I have a nice collection of Trojans and viruses. Obviously, I
run FLU_SHOT+ on my board, along with checking incoming files
with CHK4BOMB. My procedure for testing out newly uploaded code
involves me doing a backup, installing all sorts of software to
monitor what is going on, and doing a checksum on all files on
the disk. I then try out all of the code I get, primarily to
determine if the code is of high enough quality to be posted.
After testing out all of the weeks uploads, I run the checksum
program again to determine of any of my files might have been
modified by a worm's virus program.
Recently, what looked like a decent little directory lister was
posted to the board. For some reason I've yet to fathom,
directory aid programs seem to be the ones which have the highest
percentage of Trojans attached to them.
This directory aid program listed my directories in a wonderful
tree structure, using different colors for different types of
files. Nice program. When it exited, however, it went out and
looked for a directory with the word "FLU" in it. Once it found
a directory with a match in it, it proceeded to try to erase all
of the files in that directory. An assault! No big deal. That's
what backups are for.
But it brings up an interesting point: I was attacked by a
clever worm, and it erased a bunch of files which were pretty
valuable. All of the protection I had would have been for naught
if I didn't use the first line of defense from these worms: full
and adequate backup.
I've spent three years of my life developing one particular
software package. Imagine what would have happened if that had
been erased by a worm! Fortunately, I make backups at least once
a day, and usually more frequently than that. You should, too.
Now, I quarantine that machine as well. I spent a couple of
25
dollars and bought a bunch of bright red floppy disks. The basic
rule around here is that Red Disks are the only disks that go
into the BBS machine, and the Red Disks go into no other machine.
You see, I *know* that there is some worm out there who is gonna
find some way to infect my system. No matter what software
protection I use, there *is* a way around it.
You needn't be concerned though -- you're making backups on a
regular basis, right? And, you aren't asking for trouble. I am,
I expect to find it, and it is sort of amusing to see what the
worms out there are wasting their efforts on.
At this point, Trojans and Viruses are becoming a hobby with me:
watching what the worms try to do, figuring out a way to defend
against it, and then updating the FLU_SHOT series.
However, there is a possibility that the FLU_SHOT series (as well
as other protection programs which are just as valuable) are
causing an escalation of the terms of this war. The worms out
there are sick individuals. They must enjoy causing the damage
they do. But they haven't the guts to stand up and actually do
something in person. They prefer to hide behind a mist of
anonymity.
But you have the ultimate defense! No, not the FLU_SHOT+
program.
FULL AND ADEQUATE BACKUPS!
There are a variety of very good backup programs which can save
you more work than you can imagine. I use the FASTBACK+ program,
which is a great little program. I backup 30Megs once in a
while, and do an incremental backup on a very frequent basis.
There are a variety of very good commercial, public domain, and
shareware backup programs out there. Use them! Because, no
matter what software protection you use, somebody will find a way
around it once day. But they can't find a way around your
backups. And, if you (and everyone else) do regular backups,
you'll remove the only joy in life these worms have. They'll
kill themselves, hopefully, and an entire subspecies will be
wiped out -- and you'll be partially responsible!
My advance thanks for helping to exterminate these little
slimebuckets. But that brings me to something else.
26
Reward Offered
Somebody out there knows who the worms are. Even they must have
someone who is a friend. True, I can't think of any reason
someone would befriend a worm. But somebody who doesn't know
better has.
Well, I'm offering a reward for the capture and conviction of
these worms.
Enough already with software protection schemes, hardware
protection schemes, or any protection at all. It shouldn't be
required, dammit!
Here's the deal:
In this archive is a form called REWARD.FRM. If you're a
software or hardware manufacturer, or you have some software or
hardware you don't need, consider filling out that form, and
donating it to a worthy cause. I don't know what the legal and
tax ramifications of that donation would be. I'm not a lawyer
and we can cross that bridge when we get to it.
Anyway, if you know one of these worms, turn them in! Call me
up, send me a letter, a telegram, or leave a message for me on my
BBS. Indicate who you *know* is worming about. I'll keep your
name confidential.
It is surprisingly easy to get the authorities in on this --
they're as concerned about what is happening to our community as
we are. I'll presume that they'll end up putting a data tap on
the phone line of the accused worm. Then, when he next uploads a
Trojan or a virus to a BBS, he'll get nailed. The authorities
are pretty good about this stuff: they'll not tap a phone or take
any action whatsoever without adequate proof. Will your dropping
a dime on this worm be adequate proof? I don't know. Again, a
bridge to cross when we approach it.
However, assuming that this slimeball gets nailed, you'll get all
of the software and hardware which other people have donated. And
the satisfaction of knowing that you've done a Good Thing, that
you've helped an industry and community continue to grow. This
*is* your community, and the vast majority of people in it are
good people who shouldn't have to fear from your friend. Your
friend is not really a friend: he uses you to justify his own
existence. When someone uses you like that, they're not a
friend, they're a leach. And you've probably got better things
to do then let somebody use you like that.
Most importantly, the worm out there won't know if one of his
friends has already turned him in. So he won't know if his phone
is tapped. If *I* were a worm, and considering what kind of
friends I would have, I'd be sure that somebody dropped a dime on
me. And therefore an intelligent worm (perhaps I'm giving the
worm too much credit?) must presume that their line is tapped and
27
that they're gonna go to jail if they continue what they're
doing.
So just stop, you miserable little lowlife, huh? You're going to
be arrested. You're going to have to put up with indignities
which even you don't deserve! Your equipment will be
confiscated. You'll never get a job in the industry. You're
going to go to jail.
All because one of your friend's actually has a conscience and
knows what is right and what is wrong. And what you're doing is
wrong.
So, let me get back to the kind of programming I enjoy --
productive programming. And turn your programming to useful,
interesting, and productive programming. You have the talent to
do something useful and good with your life. What you're doing
is hurting the industry and hurting the community which would
welcome someone with your talents with open arms.
And the satisfaction of helping far surpasses the satisfaction
you must get from hurting innocent people.
So just stop.
Sincerely, Ross M. Greenberg
28
