

From --

 <The Restaurant at the End of the Universe  609/921-1994  10 Megs/1200/2400>


 ____________________________________________________________________________
/                                                                            \
|                      HOW TO WRITE A VIRUS PROGRAM                          |
|                                  by                                        |
|                                  The Cheshire Cat                          |
\                                                                            /
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

        For people who have nothing else to do but cause unprecidented havoc
     on other peoples systems, this is something you should read.  To begin
     with, I'd like to explain briefly to the ignorant readers of this, what
     exactly a virus program is.  A virus program is in the genre of tapeworm,
     leech, and other such nasty programs.  I will show clearly, one possible
     application of it, on an Apple system, and I will demonstrate how easily
     this little pest could lead to wiping out most of someone's important
     disks.  Here we go!

        One day, while I had little else to do, I was reading an computing
     article in some obscure science magazine.  As it happened, the article
     discussed a growing problem in the computer community about the danger
     of virus programs.  Someone quoted in the article said that they wrote
     a very simple virus program and put it on the univerisity computer as
     a test.  All the program did was look through the computers memory,
     and devices (tape drives, hard drives, etc...) for stored programs, and
     when it found one, it would search through the program for itself.  If
     it didn't find anything, it would find an empty spot in the program, and
     implant itself.  This may not sound too exciting, but this little program
     was actually part of another program (maybe a word processor, or spread-
     sheet, or maybe even zaxxon) and whenever someone ran that program, and
     executed the little virus stuck inside it, the virus would stop program
     execution (for a time period that even us humans wouldn't notice) and do
     its little job of infecting other programs with itself.   This example
     of a virus was harmless, but even so, after only 4 hours the whole system
     had to be shutdown and the whole memory core dumped because the virus had
     begun to fill up too much space and it was using up all the mainframe's
     time.  I don't think it would have been so easy if this professor had
     just done this experiment on his own and had not got permission or told
     anyone about it.  Think of the havoc!!
         Well, that has taken up too much time discussing already, so I'll
     add only one more thing before we get down to business, that REAL
     viruses are extemely BAD.  They usually are designed as time bombs that
     start erasing disks, memory, and maybe even backups or the operating
     system after they have been run so many times, or after a certain date
     is reached.  Someone did this to a bank one time (and by the way he was
     never caught!)  He was given the task of designing their operating system
     and security, and he decided he wasn't getting paid enough, so he devised
     his own method of compensation.  Every so often, the computer would steal
     a certain amount of money from the bank (by just CREATING it electronic-
     ally) and would put it in an account that didn't exist as far as the bank
     or the IRS or anybody knew, and whenever this guy wanted, he went to
     the bank and withdrew some money.  They aren't sure how he did it, but
     he probably visited the electronic teller as often as possible.  As I
     said, the authorities still haven't found him, but after several years
     of his leech program being in service, it "expired."  They assume that
     he set it up to destroy itself after so long, and when this little
     program was gone, the bank suddenly was missing several million dollars.
     Now, I wouldn't recommend doing this sort of thing, but then again, who
     said crime doesn't pay?
          Now to discuss the application of this to a Personal Computer is
     very simple.  When I decided to do this, I figured it would be easiest
     to stick my program in the DOS, so that I would always know where to put
     another copy of my virus while it was reproducing itself, and that it
     would be easier to explain why the disk drive is running when it starts
     to initialize your disks.  For those who have a copy of Beneath Apple DOS
     it would be easy to find the space to put in the program.  If you don't,
     I tell you a few places that are not used (or where you can put it and
     it won't be noticed) but I'd recommend getting the book anyways - it's
     an excellent tool for doing these sort of things, and useful even if you
     don't.  As suggestions for where to put it (if you choose to infect DOS),
     you could use BCDF-BCFF which is still unused, or BFD9-BFFF, which WAS
     unused, but has since been used in updates of DOS.  Likewise, I would
     also suggest using space taken up by junk like LOCK or UNLOCK commands.
     Who the hell ever uses them?  Think about it, when was the last time you
     used the lock command?  Get real.  If you don't like that, how about
     MAXFILES.  I've only used that in a program once in my entire life.  I
     know people who couldn't even tell you what it does.  That would make me
     feel safe about sticking a virus there.
           But now comes the part that will be harder for the inexperienced,
     but easier as long as you know what you're doing.  By the way, you've
     been TOTALLY wasting your time reading this if you don't understand
     assembly, because you HAVE TO in order to accomplish a task such as this.
     But, don't fret, you could insert a little BASIC code into some dumb
     utility (like an program whose only function is to initialize disks) that
     would put itself on the disk, as it initializes it (probably as the hello
     program) and would work from that aspect.  Of course, it would be easier
     for a less experienced person to detect, but who really cares!
           As I was saying, however, you now have to write the code.  If you
     work in an area where you are limited memorywise (like I did) it can get
     tough at times.  The only way I got through it was by referring to
     documented listings of all of DOS that I got somewhere, and using bits
     and pieces of routines from other things as much as I could.  When I
     was done, I had a copy of DOS that when it was booted into the computer,
     would work completely properly (except for maybe some bizarre circum-
     stances that I didn't bother testing for), but when someone CATALOGed a
     disk, it did a few different things.  It would first load up the VTOC as
     usual, but then it would jump to MY routine.  In this instance, it was
     very easy to use the VTOC which contains many unused bytes to house my
     counter.  I would increment it, check if it was time to destroy the disk,
     and then execute an INIT, or just save the VTOC.  Then it would save
     three more sectors to the disk.  One was the place where DOS branched to
     my routines, the others were my actual routine.  And thus was born a
     virus.  I guarentee that if anyone has experienced a problem with their
     disks, it was not my fault because I have not yet implemented the virus.
     No one has pissed me off enough to warrant its use.  Even worse is the
     fact that it could backfire (after being distributed across the country,
     I don't doubt I'd end up with it also) because not only was it very well
     planned, but you don't even notice any sort of a pause.  The virus
     executes itself so fast that there is little more than a microsecond of
     a pause while the catalog is going on.  I tried comparing it to a normal
     catalog, and found I couldn't tell the difference.  The only way this
     thing wouldn't work is if the disk it was cataloging wasn't DOS 3.3, and
     if that happened, it would probably screw the disk anyways.  I know
     there are people who will abuse this knowledge, so you may wonder why I
     even bothered writing it.  The fact is that it isn't important to shield
     people from this knowledge, what is important is for people to know that
     can be done, and perhaps find a way to prevent it.  Just consider what
     would happen if someone starting putting a virus in a DDD ][.2.  First of
     all, everyone would get a copy of it and use it.  Only a few would be
     that interested to check what these new updates to it were.  And perhaps
     within a month, whenever you tried to unpack a program, it would instead
     initialize the disk with your file on it.  So, like I said, beware of
     those that would jeapordize themselves and would do such a thing.  Of
     course, I wouldn't hesitate to drop my "bomb" on a few leech friends of
     mine who don't have modems, but thats a different story.  I don't have
     to worry too much about getting the "cold" back from them.  They'll be
     too screwed up to worry about trading disks.  Well, I've said too much
     already.  Please keep my name on this file if you put it on your BBS,
     ect..., but I don't really care if you want to put your local AE line
     number, or whatever up at the beginning too, just give me credit where
     I'm due.  Thank-you, and good luck, and, as I said before, be careful
     out there!!

                       FROM  --  THE CHESHIRE CAT
                        written: 12/30/85
=-=-=-= If you need to reach me for more information, try E-mail on =-=-=-=
=-=-=-=-=-=-=-=-=-=-= OSB systems (215)-395-1291 =-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-= I may offer a listing of my virus's coding if there is =-=-=-=-=-=-
=-=-=-= significant interest.  But I leave you now, The Cheshire Cat -=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

L5>