Elk Cloner is the first known computer virus that has spread "in the wild", i.e., outside the computer system or lab it was written in. It was written around 1982 by a 15-year-old high school student named Richard Skrenta for Apple II systems.
Elk Cloner spread by infecting the Apple II's operating system, stored on floppy disks. When the computer was booted from an infected floppy, a copy of the virus would automatically start. The virus would not normally alter the working of the computer, except from monitoring disk access. When an uninfected floppy was accessed, the virus would copy itself to the disk, thus infecting it, too, slowly spreading from floppy to floppy.
Like many of the early viruses, Elk Cloner did not cause any deliberate harm, although some sources suggest that it could harm disks not containing the operating system. Like many of the early viruses, however, it did cause annoyance: on every 50th booting the virus would display a short "poem", as follows:
Elk Cloner: The program with a personality
It will get on all your disks
It will infiltrate your chips
Yes it's Cloner!It will stick to you like glue
It will modify ram too
Send in the Cloner!
Annoyance in fact was the raison d'tre of the virus. Its 15-year-old author previously had the habit of giving out pirated computer games to his friends, but games modified such that they would stop working after a given number of games. This scheme guaranteed a high level of annoyance: by the time those friends grew to like the programs the programs would stop working, usually with some "humorous" message (at least as judged by their author). After a while those friends learned never to allow Skrenta near their disks. Here came Cloner, which could annoy friends without Skrenta physically gaining access to their disks.
According to contemporary reports, the virus was rather contagious, successfully infecting the floppies of most people Skrenta knew (including his math teacher), upsetting many of them (including the said math teacher). Part of the "success", of course, was that people were not at all wary of the potential problem (virus infection could have been avoided by not inserting floppies into computers without hard-booting them before), nor were virus scanners or cleaners available. The virus could still be removed but it required an elaborate manual effort.
Size: 2030 bytes. (9 Blocks) Type: Memory-resident parasitic prepender. Infects: Commodore 64 Basic files.
As with all Commodore 64 programs, BHP began with some code written in Basic. This code consisted of a single line, a SYS call to the assembler code, where the rest of the virus resided. Unlike many programs, the virus code built the address to call dynamically. This may have been written by a very careful coder, but it proved to be unnecessary because the address did not change in later versions of the machine.
Once the assembler code gained control, it placed itself in the block of memory that was normally occupied by the I/O devices when the ROM was banked-in.
A side-effect of memory-banking was that it was a great way to hide a program, since the program was not visible if its memory was not banked in. This is the reason why BHP placed its code in banked memory. After copying itself to banked memory, the virus restored the host program to its original memory location and restored the program size to its original value. This allowed the host program to execute as though it were not infected. However, at this time the virus would verify the checksum of the virus?s Basic code, and would overwrite the host memory if the checksum did not match. An interesting note about the checksum routine is that it missed the first three bytes of the code, which were the line number and SYS command. This made the job easier for the person who produced the later variant of the virus. Although the later variant differed only in the line number, this was sufficient to defeat the BHP-Killer program, because BHP-Killer checked the entire Basic code, including the line number.
The virus checked whether it was running already by reading a byte from a specific memory location. If that value matched the expected value, the virus assumed that another copy was running. Thus, writing that value to that memory location would have been an effective inoculation method. If no other copy of the virus was running, the virus would copy some code into a low address in non-banked memory, and hook several vectors, pointing them to the copied code.
The virus hooked the ILOAD, ISAVE, MAIN, NMI, CBINV and RESET vectors. The hooking of MAIN, NMI, CBINV and RESET made the virus Break-proof, Reset-proof, and Run/Stop-Restore-proof.
Once the hooks were in place, the virus ran the host code. The main virus code would be called on every request to load or save a file.
The ILOAD hook was reached when a disk needed to be searched. This happened whenever a directory listing was requested, and could happen when a search was made using a filename with wildcards, or the first time that a file was accessed. Otherwise, the drive hardware cached up to 2kb of data and returned it directly. The virus called the original ILOAD handler, then checked whether an infected program had been loaded. If an infected program had been loaded, the virus restored the host program to its original memory location and restored the program size to its original value. Otherwise, even if no file had been loaded, the virus called the infection routine.
The ISAVE hook was reached whenever a file was saved. The virus called the original ISAVE handler to save the file, then called the infection routine. The infection routine began by checking that the requested device was a disk drive. If so, then the virus opened the first file in the cache. The first file in the cache would be the saved file if this code was reached via the ISAVE hook, otherwise it would be the first file in the directory listing. If the file was a Basic program, then the virus performed a quick infection check by reading the first byte of the program and comparing it against the SYS command.
If the SYS command was present, the virus verified the infection by reading and comparing up to 27 subsequent bytes. A file was considered infected if all 27 bytes matched. If the file was not infected, the virus switched to reading data from the hardware cache. The first check was for a standard disk layout: the directory had to exist on track 18, sector 0, and the file to infect had not to have resided on that track.
If these checks passed, the virus searched the track list for free sectors. It began with the track containing the file to infect, then moved outwards in alternating directions. This reduced the amount of seeking that the drive had to perform in order to read the file afterwards.
If at least eight free sectors existed on the same track, then the virus allocated eight sectors for itself and updated the sector bitmap for that track.
The virus wrote itself to disk in the following manner: the first sector of the host was copied to the last sector allocated by the virus, then that first sector was replaced by the first sector of the virus. After that, the remaining virus code was written to the remaining allocated sectors.
The directory stealth was present here, and it existed without any effort on the part of the virus writer(s). It was a side-effect of the virus not updating the block count in the directory sector. The block count was not used by DOS to load files, its purpose was informational only, since it was displayed by the directory listing.
After any call to ILOAD or ISAVE, the virus checked whether the payload should activate. The conditions for the payload activation were the following: that the machine was operating in ?direct? mode (the command-prompt), that the seconds field of the jiffy clock was a value from 2?4 seconds, and that the current scan line of the vertical retrace was at least 128. This made the activation fairly random. The payload was to display a particular text, one character at a time, while cycling the colours of the border The serial number that was displayed was the number of times the payload check was called. It was incremented once after each call, and it was carried in replications. It reset to zero only after 65,536 calls.
Screenshot © CSDB, Description © Peter Ferrie
In these days I was travelling around for the Chaos Computer Club to give talks and interviews to the media about computer viruses. In one of these discussions an IBM manager declared that "Computer viruses for PC's do exist, but it is not possible to write a virus for an IBM mainframe."
Whenever I think something can be done and someone else is denying that - well, I certainly give that something a try.
The first widely publicised replicating network program was the Christmas Tree (CHRISTMAS EXEC) which paralysed the worldwide IBM VNet private electronic mail network on 17th December 1987.
It was written by a student at the University of Clausthal-Zellerfield, WestGermany. He claimed that the program, written in the VM/CMS operating system language REXX, was designed to send Christmas greetings to his friends within the university. The first known infection was at 1300 GMT on 9th December at Clausthal-Zellerfield (EARNnode DCZTU1).
However, the program escaped onto the European Academic Research Network (EARNet) which, ironically, had been established with IBM financial backing and assistance. EARNet is linked to BitNet in the United States which in turn is connected to VNet, a network used by IBM to communicate with customers and suppliers. The first infection on Vnet occurred on 15th December 1987. This network was brought to a temporary standstill two days later. The program read the addresses of communication partners in the user files NAMES and NETLOG and sent a copy of itself to all addresses contained therein. Users found the message `Let this exec run and enjoy yourself!' posted in their mail-boxes. If the program was run the following greeting appeared:
*
*
***
*****
*******
*********
************* A
*******
*********** VERY
***************
******************* HAPPY
***********
*************** CHRISTMAS
*******************
*********************** AND MY
***************
******************* BEST WISHES
***********************
*************************** FOR THE NEXT
******
****** YEAR
******
Further investigation of the EXEC file diplayed the line:
/* browsing this file is no fun at all just type CHRISTMAS from cms */
The program messages terminated with ERASECHRISTMAS EXEC by which time the program had propagated itself, like a chain letter, to all mailbox addresses contained in the users address file. In common with PC viruses, this program needed to be executed or `run' to replicate. Unlike a virus, the Christmas Tree did not incorporate any of its own code into a host program.
The Christmas Tree was the first program known to have caused wide area network paralysis and amply demonstrated the need to educate network users to be wary of running unfamiliar executables (EXEC, CLIST, program), however intriguing a filename or on-screen instruction might be.
On December 22, 1988 at 21:52 (swiss time) a decnet worm was released from a European HEPNET node NEDCU2:: (20.117; interger form 20597::) onto the DECnet Internet. This worm has been called the "Father Christmas" Worm, since it's ultimate goal was to send mail to users from Father Christmas. The worm performed several key functions:
Rivpas is a proof-of-concept script written in SAP's application development language, Advanced Business Application Programming (ABAP) language. This sciprt is supposed to show that a virus can be written for this platform, however, the sample is intentionally made not to replicate.
First the script attempts to find the SAP's report directory and tries to find functions and reports to infect.
If an suitable object is found, the virus will try to inject its code in there.
The virus sets the username of an infected object to "Virii" and uses this as a infection marker.
[Analysis: Katrin Tocheva and Sami Rautiainen, F-Secure Corp.; April 15th, 2002]
There's also the article published in Newsbytes
THIS PROGRAM IS A TOTALLY NEW WAY OF DISTRIBUTING VERSIONS OF SOFTWARE THROUGHOUT THE 1100 SERIES USER COMMUNITY. PREVIOUS METHODS REQUIRED THE DELIBERATE AND PLANNED INTERCHANGE OF TAPES, CARD DECKS, OR OTHER TRANSFER MEDIA. THE ADVENT OF 'PERVADE' PERMITS SOFTWARE TO BE RELEASED IN SUCH A MANNER THAT IF SOMEONE CALLS YOU UP AND ASKS FOR A VERSION OF A PROCESSOR, VERY LIKELY YOU CAN TELL THEM THAT THEY ALREADY HAVE IT, MUCH TO THEIR OWN SURPRISE.
Ever heard the one about the self-reproducing ANIMAL program that spread throughout systems and colonised new machines? Here's the story, both as it actually happened, and recounted in the press as a "computer urban legend" 10 and 15 years after the fact.