The autumn of 1987 really seemed to get the ball rolling with regard to virus research. The first message to awaken interest was sent by one “LUKEN” of Lehigh University. For all the damage that the Lehigh virus caused, we should at least be grateful that it brought us our Peerless Leader (aka krvw).
Not all students are mini-hackers: not all students are even semi computer literate. Student consultants at universities and colleges are presented with a steady stream of disks from which files have “mysteriously” disappeared. In November of 1987, however, it appeared that certain of the failed disks were due to something other than user carelessness.
The Lehigh virus overwrote the stack space at the end of the COMMAND.COM file. (Early reports stated there was no increase in file size: later research showed an increase of 555 bytes in the size of infected files.) When an infected COMMAND.COM was run (usually upon booting from an “infected disk”), the virus stayed resident in memory. When any access was made to another disk, via the TYPE, COPY, DIR or other normal DOS commands, any (and only) uninfected COMMAND.COM files would be infected. A counter was kept of infections: after four infections the virus would overwrite the boot and FAT areas of disks with contents from the BIOS.
The primary defense of the virus was that, at the time, no one would have been looking for it. The date of infected COMMAND.COM files was altered by the virus, and, when attempting an infection on a write protected disk, the virus would not trap the “WRITE PROTECT ERROR” message (a dead giveaway if all you were doing was a DIR).
The virus was limited in its “target population” to those disks which had a COMMAND.COM file, and, more particularly, those which contained a full operating system. Admittedly, in those heady bygone days, more users kept copies of the operating system on their disks. However, the virus was also self-limiting in that it would destroy itself once activated, and would activate after only four “reproductions”. To the best of our knowledge, the Lehigh virus never did spread off the campus in that initial attack. (It is, however, found in a number of private virus collections, and may be “released” into the wild from time to time. As noted, it has little chance of spreading today.)
The “Jerusalem” virus
In the MS-DOS world the Stoned virus is currently the most successful virus in terms of the number of infections (copies or reproductions) that the virus has produced. (Boot sector viral programs seem to have an advantage among microcomputer users.) Among file infecting viral programs, however, the Jerusalem virus is the clear winner. It has another claim to fame as well. It almost certainly has the largest number of variants of any virus program known to date.
Initially known as the “Israeli” virus, the version reported by Y. Radai in early 1988 (also sometimes referred to as “1813” or Jerusalem-B) tends to be seen as the “central” virus in the family. Although it was the first to be very widely disseminated, and was the first to be “discovered” and publicized, internal examination suggests that it was, itself, the outcome of previous viral experiments. Although one of the oldest viral programs, the Jerusalem family still defies description, primarily because the number of variants makes it very difficult to say anything about the virus for sure. The “Jerusalem” that you have may not be the same as the “Jerusalem” of your neighbour.
A few things are common to pretty much all of the Jerusalem family. They are file, or program, infecting viri [viruses], generally adding themselves to both COM and EXE files. When an infected file is executed, the virus “goes resident” in memory, so that it remains active even after the original infected program is terminated. Programs run after the program is resident in memory are infected by addition of the virus code to the end of the file, with a redirecting jump added to the beginning of the program. Most of the family carry some kind of “date” logic bomb payload, often triggered on Friday the 13th. Sometimes the logic bomb is simply a message, often it deletes programs as they are invoked.
David Chess has noted that it is a minor wonder the program has spread as far as it has, given the number of bugs it contains. Although it tends to work well with COM files, the differing structure of EXE files has presented Jerusalem with a number of problems. The “original Jerusalem”, not content with one infection, will “reinfect” EXE files again and again so that they continually grow in size. (This tends to nullify the advantage that the programmer built in when he ensured that the file creation date was “conserved” and unchanged in an infected file.) Also, EXE programs which use internal loaders or overlay files tend to be infected “in the wrong place”, and have portions of the original program overwritten.
The history of the Jerusalem virus is every bit as convoluted as its functionality and family. The naming alone is a fairly bizarre tale. As mentioned before, it was originally called the Israeli virus. Although considered unfair by some, it was fairly natural as the virus had both been discovered and reported from Israel. (Although the virus was reported to slow down systems that were infected, it seems to have been the “continual growth” of EXE files which led to the detection of the virus.) In an effort to avoid anti-semitism, it was referred to by its “infective length” of 1813 bytes. For COM files. For EXE files it was 1808 bytes. Sometimes. It varies because of the requirement that the header of an EXE file is divisible by 16. (All quite clear?)
One of the early infections was found to be in an office belonging to the Israeli Defence Forces. This fact was reported in an Associated Press article, and, of course, made much of. It also gave rise to another alias, the I.D.F. virus.
When the virus was first discovered, it was strongly felt that it had been circulating prior to November of 1987. The “payload” of file deletion on Friday the 13th gave rise to conjecture as to why the logic bomb had not “gone off” on Friday, November 13th, 1987. (Subsequent analysis has shown that the virus will activate the payload only if the year is not 1987.) The next following “Friday the 13th” was May 13th, 1988. Since the last day that Palestine existed as a nation was May 13th, 1948 it was felt that this might have been an act of political terrorism. This led to another alias, the PLO virus. (The fact that Israel celebrates its holidays according to the Jewish calendar, and that the independence celebrations were slated for three weeks before May 13th in 1988 were disregarded. The internal structure of the virus, and the existence of the sURIV viral programs seems to indicate that any political correspondence is merely coincidence.)
Yet another alias is “sUMsDos”, based upon text found in the virus code itself. This was, on occasion, corrupted to “sumDOS”.
The name “Jerusalem” has gained ascendancy, possibly due to the McAfee SCAN program identification. (He certainly must be responsible for the “B” designation for the “original” version.) Of course, the great number of variants have not helped any. Because a number of the variants are very closely based upon each others code, the signatures for one variant will often match another, thus generating even more naming confusion. This confusion is not unique to the Jerusalem family, of course, and is an ongoing concern in the virus research community.
Although it is difficult to be absolutely certain about pronouncements as to the provenance and family history of viral programs, it is almost certain that the Jerusalem virus is, in fact, two viral programs combined. Among the Jerusalem “family” are three “sURIV” variants (again, named for text in the code.) It is fairly easy to see where “virus” 1, 2 and 3 come from. sURIV 1.01 is a COM file infector, COM being the easier file structure and therefore the easier programs to infect. sURIV 2 is an EXE only infector, and is considerably longer and more complex code. sURIV 3 infects both types of program files, and has considerable duplication of code: it is, in fact, simply the first two versions “stuck” together.
(Although the code in the sURIV programs and the “1813” version of Jerusalem is not absolutely identical, all the same features are present. The date of the “payload” is April 1 in the sURIV variants. There is also a “year” condition: some of the payload of the sURIV variants is not supposed to “go off” until after 1988.)
Perhaps this explains the “popularity” of the Jerusalem virus as a “template” for variants. The code is reasonably straightforward and, for those with some familiarity with assembly programming, an excellent “primer” for the writing of viral programs affecting both COM and EXE files. (There is, of course, the fact that Jerusalem is both “early” and “successful”. There are many copies of Jerusalem “in the wild”, and it may be simply availability that has made it so widely copied. Its “value” as a teaching tool may simply be an unfortunate coincidence.)
Of course, not every virus writer who used the Jerusalem as a template showed the same good taste and imagination in what they did with it. Not all of them even fixed the obvious flaws in the original. The “variations” tend to be quite simplistic: there are a number of “Thursday the 12th”, “Saturday the 14th” and “Sunday the 15th” programs. (Some of the “copy cat” virus authors added errors of their own. One of the “Sunday” variants is supposed to delete files on the “seventh” day of the week. Unfortunately, or perhaps fortunately for those of us in the user community, nobody ever bothered to tell the author that computers start counting from zero and Sunday is actually the “zeroth” day of the week. The file deletions never actually happen.)
Robert M. Slade’s history is available here with permission of Robert M. Slade. Please do not further use the material without obtaining your own permission to use it.
 Robert Slade Computer Virus History |
|
 |
 |
| Chapter 5 Apple Virus | Chapter 7 (c) Brain |