home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / pc / virus / catvir.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  10.0 KB  |  148 lines

  1.  
  2.  
  3. From --
  4.  
  5.  <The Restaurant at the End of the Universe  609/921-1994  10 Megs/1200/2400>
  6.  
  7.  
  8.  ____________________________________________________________________________
  9. /                                                                            \
  10. |                      HOW TO WRITE A VIRUS PROGRAM                          |
  11. |                                  by                                        |
  12. |                                  The Cheshire Cat                          |
  13. \                                                                            /
  14.  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  15.  
  16.         For people who have nothing else to do but cause unprecidented havoc
  17.      on other peoples systems, this is something you should read.  To begin
  18.      with, I'd like to explain briefly to the ignorant readers of this, what
  19.      exactly a virus program is.  A virus program is in the genre of tapeworm,
  20.      leech, and other such nasty programs.  I will show clearly, one possible
  21.      application of it, on an Apple system, and I will demonstrate how easily
  22.      this little pest could lead to wiping out most of someone's important
  23.      disks.  Here we go!
  24.  
  25.         One day, while I had little else to do, I was reading an computing
  26.      article in some obscure science magazine.  As it happened, the article
  27.      discussed a growing problem in the computer community about the danger
  28.      of virus programs.  Someone quoted in the article said that they wrote
  29.      a very simple virus program and put it on the univerisity computer as
  30.      a test.  All the program did was look through the computers memory,
  31.      and devices (tape drives, hard drives, etc...) for stored programs, and
  32.      when it found one, it would search through the program for itself.  If
  33.      it didn't find anything, it would find an empty spot in the program, and
  34.      implant itself.  This may not sound too exciting, but this little program
  35.      was actually part of another program (maybe a word processor, or spread-
  36.      sheet, or maybe even zaxxon) and whenever someone ran that program, and
  37.      executed the little virus stuck inside it, the virus would stop program
  38.      execution (for a time period that even us humans wouldn't notice) and do
  39.      its little job of infecting other programs with itself.   This example
  40.      of a virus was harmless, but even so, after only 4 hours the whole system
  41.      had to be shutdown and the whole memory core dumped because the virus had
  42.      begun to fill up too much space and it was using up all the mainframe's
  43.      time.  I don't think it would have been so easy if this professor had
  44.      just done this experiment on his own and had not got permission or told
  45.      anyone about it.  Think of the havoc!!
  46.          Well, that has taken up too much time discussing already, so I'll
  47.      add only one more thing before we get down to business, that REAL
  48.      viruses are extemely BAD.  They usually are designed as time bombs that
  49.      start erasing disks, memory, and maybe even backups or the operating
  50.      system after they have been run so many times, or after a certain date
  51.      is reached.  Someone did this to a bank one time (and by the way he was
  52.      never caught!)  He was given the task of designing their operating system
  53.      and security, and he decided he wasn't getting paid enough, so he devised
  54.      his own method of compensation.  Every so often, the computer would steal
  55.      a certain amount of money from the bank (by just CREATING it electronic-
  56.      ally) and would put it in an account that didn't exist as far as the bank
  57.      or the IRS or anybody knew, and whenever this guy wanted, he went to
  58.      the bank and withdrew some money.  They aren't sure how he did it, but
  59.      he probably visited the electronic teller as often as possible.  As I
  60.      said, the authorities still haven't found him, but after several years
  61.      of his leech program being in service, it "expired."  They assume that
  62.      he set it up to destroy itself after so long, and when this little
  63.      program was gone, the bank suddenly was missing several million dollars.
  64.      Now, I wouldn't recommend doing this sort of thing, but then again, who
  65.      said crime doesn't pay?
  66.           Now to discuss the application of this to a Personal Computer is
  67.      very simple.  When I decided to do this, I figured it would be easiest
  68.      to stick my program in the DOS, so that I would always know where to put
  69.      another copy of my virus while it was reproducing itself, and that it
  70.      would be easier to explain why the disk drive is running when it starts
  71.      to initialize your disks.  For those who have a copy of Beneath Apple DOS
  72.      it would be easy to find the space to put in the program.  If you don't,
  73.      I tell you a few places that are not used (or where you can put it and
  74.      it won't be noticed) but I'd recommend getting the book anyways - it's
  75.      an excellent tool for doing these sort of things, and useful even if you
  76.      don't.  As suggestions for where to put it (if you choose to infect DOS),
  77.      you could use BCDF-BCFF which is still unused, or BFD9-BFFF, which WAS
  78.      unused, but has since been used in updates of DOS.  Likewise, I would
  79.      also suggest using space taken up by junk like LOCK or UNLOCK commands.
  80.      Who the hell ever uses them?  Think about it, when was the last time you
  81.      used the lock command?  Get real.  If you don't like that, how about
  82.      MAXFILES.  I've only used that in a program once in my entire life.  I
  83.      know people who couldn't even tell you what it does.  That would make me
  84.      feel safe about sticking a virus there.
  85.            But now comes the part that will be harder for the inexperienced,
  86.      but easier as long as you know what you're doing.  By the way, you've
  87.      been TOTALLY wasting your time reading this if you don't understand
  88.      assembly, because you HAVE TO in order to accomplish a task such as this.
  89.      But, don't fret, you could insert a little BASIC code into some dumb
  90.      utility (like an program whose only function is to initialize disks) that
  91.      would put itself on the disk, as it initializes it (probably as the hello
  92.      program) and would work from that aspect.  Of course, it would be easier
  93.      for a less experienced person to detect, but who really cares!
  94.            As I was saying, however, you now have to write the code.  If you
  95.      work in an area where you are limited memorywise (like I did) it can get
  96.      tough at times.  The only way I got through it was by referring to
  97.      documented listings of all of DOS that I got somewhere, and using bits
  98.      and pieces of routines from other things as much as I could.  When I
  99.      was done, I had a copy of DOS that when it was booted into the computer,
  100.      would work completely properly (except for maybe some bizarre circum-
  101.      stances that I didn't bother testing for), but when someone CATALOGed a
  102.      disk, it did a few different things.  It would first load up the VTOC as
  103.      usual, but then it would jump to MY routine.  In this instance, it was
  104.      very easy to use the VTOC which contains many unused bytes to house my
  105.      counter.  I would increment it, check if it was time to destroy the disk,
  106.      and then execute an INIT, or just save the VTOC.  Then it would save
  107.      three more sectors to the disk.  One was the place where DOS branched to
  108.      my routines, the others were my actual routine.  And thus was born a
  109.      virus.  I guarentee that if anyone has experienced a problem with their
  110.      disks, it was not my fault because I have not yet implemented the virus.
  111.      No one has pissed me off enough to warrant its use.  Even worse is the
  112.      fact that it could backfire (after being distributed across the country,
  113.      I don't doubt I'd end up with it also) because not only was it very well
  114.      planned, but you don't even notice any sort of a pause.  The virus
  115.      executes itself so fast that there is little more than a microsecond of
  116.      a pause while the catalog is going on.  I tried comparing it to a normal
  117.      catalog, and found I couldn't tell the difference.  The only way this
  118.      thing wouldn't work is if the disk it was cataloging wasn't DOS 3.3, and
  119.      if that happened, it would probably screw the disk anyways.  I know
  120.      there are people who will abuse this knowledge, so you may wonder why I
  121.      even bothered writing it.  The fact is that it isn't important to shield
  122.      people from this knowledge, what is important is for people to know that
  123.      can be done, and perhaps find a way to prevent it.  Just consider what
  124.      would happen if someone starting putting a virus in a DDD ][.2.  First of
  125.      all, everyone would get a copy of it and use it.  Only a few would be
  126.      that interested to check what these new updates to it were.  And perhaps
  127.      within a month, whenever you tried to unpack a program, it would instead
  128.      initialize the disk with your file on it.  So, like I said, beware of
  129.      those that would jeapordize themselves and would do such a thing.  Of
  130.      course, I wouldn't hesitate to drop my "bomb" on a few leech friends of
  131.      mine who don't have modems, but thats a different story.  I don't have
  132.      to worry too much about getting the "cold" back from them.  They'll be
  133.      too screwed up to worry about trading disks.  Well, I've said too much
  134.      already.  Please keep my name on this file if you put it on your BBS,
  135.      ect..., but I don't really care if you want to put your local AE line
  136.      number, or whatever up at the beginning too, just give me credit where
  137.      I'm due.  Thank-you, and good luck, and, as I said before, be careful
  138.      out there!!
  139.  
  140.                        FROM  --  THE CHESHIRE CAT
  141.                         written: 12/30/85
  142. =-=-=-= If you need to reach me for more information, try E-mail on =-=-=-=
  143. =-=-=-=-=-=-=-=-=-=-= OSB systems (215)-395-1291 =-=-=-=-=-=-=-=-=-=-=-=-=-
  144. =-=-=-= I may offer a listing of my virus's coding if there is =-=-=-=-=-=-
  145. =-=-=-= significant interest.  But I leave you now, The Cheshire Cat -=-=-=
  146. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  147.  
  148. L5>