HOME   HISTORY   EFFECT   TOUR   LESSONS   BIBLIOGRAPHY

Welcome to the Virtual System Invasion

This set of pages is going to illustrate the actions take by the 1988 Worm when it invaded a system. In following this string of pages, you should be able to get a worm's eye view of the invasion.

We could probably start the tour at any point in the worm's activities. There really is no start or stopping point, just an infinite loop or infecting and spreading. However, it seems to make sense to begin with the worm's "main" function. This is called once the worm's files have been loaded into the target system and compiled.


The Main Routine


The first actions of the worm are several security precautions to help prevent detection:

First, it sets it's own the "zeroth" argument to sh. This changes the process name of the running worm to sh. This is the same process name as a Bourne Shell, which is a common process used by users to input data into their terminals. Thus, if someone were to look at a list of the processes running while the worm was in the system, they would see nothing unusual.
The worm's creator didn't want the worm to be easy to capture, since once someone captured a copy of the running worm, it would be possible to deconstruct the code and figure out how to stop it. To this end, the next thing the Worm does is set the maximum core dump size to zero bytes. A "core dump" places a copy of the CPU's running process into memory for further examination. A core dump occurs whenever a program crashes, but can also be forced. Since the worm set the size of the core dump to 0, even if the program crashed, or was forced to crash, investigators would not get a copy of the running worm.
The worm also reads the current time at this point and stores this for seeding the random number generator. This will be used later.
Additionally, when the Worm was executed, it might have been executed with the -p flag, an optional command line argument, followed by a decimal number which was believed to the the process identification number of the current worm's parent.
The rest of the command line arguments that the Worm was executed with are the names of the object files that it needs in order to operate at full capacity. The worm tries to load the files named by these arguments into its address space. If the -p argument was given above, then it also deletes these files after loading them, and later deletes the disk copy of the running worm itself. It also tries to delete the file /tmp/.dumb, although, since this file is never referred to again, it is unclear why it does so. If it fails to load any one of these object files, the worm quits. Otherwise, the worm continues.


Return to the main Worm page.