Copyright Robert M. Slade, 1992
In the earliest computers it was vital that you knew the initial state of the computer. It was also important that no remnants of other programs remain. (It is hard enough to debug programs now: you don't need extraneous "noise" to deal with.) An instruction was often implemented that had only one function: it would copy itself to the next memory location and then proceed on to that location. Thus, by starting this instruction at the beginning of memory, the entire memory space could be "filled" with a known value. This single instruction could be seen as the first viral type program.
As computers progressed, it became possible to run more than one program at a time in a single machine. It was, of course, important that each program, and its associated data, be contained within certain bounds, or partitions. Inevitably, there were programs which "broke the bounds", and would either perform operations on the data or programs belonging to different procedures, or actually transferred control to random areas and tried to execute data as program instructions. Random operations and damage would result. Attempts to trace the "path" of damage or operation would show "random" patterns of memory locations. Plotting these on a printout map of the memory looks very much like the design of holes in "worm-eaten" wood: irregular curving traces which begin and end suddenly. The model became known as a "wormhole" pattern, and the rogue programs became known as "worms". In an early network of computers a similar program, the infamous "Xerox worm", not only broke the bounds within its own computer, but spread from one computer to another. This has led to the use of the term "worm" to differentiate a viral program that spreads over networks from other types. The term is sometimes also used for viral programs which spread by some method other than attachment to, or association with, program files.
(Programmers being who they are, the development of such rogue programs became a sport. This is now enshrined in the game of "Core Wars". A program is run which "simulates" a computer environment. A standard set of instructions, known as "Redstone code", is used to build programs which battle each other within the simulated environment. The objective is survival. The use of such tactics as attack, avoidance and replication is of interest to virus research, as is the trade-off between complexity of design and chance of destruction.)
"Password trojans" are extremely popular in the university and college environments (where most of the new security breaking ideas and pranks tend to come from anyway). These programs can be extremely simple. An easy "painting" of the screen with a facsimile of the normal login screen will generally get the user to enter their name and password. It is quite simple to have a program write this information to a file, or even mail it to a specific account. Most of these programs will then send back a message to the user that the login has been denied; most users will accept this as an indication that they have either a mistake in entering the login data or that there is some unknown fault in the system. Few question it even after repeated refusals. Some programs are sophisticated enough to pass the login information on to another spawned process: few users even know enough to check the level of nesting of processes.
(A famous, if relatively harmless, prank in earlier computers was the "cookie" program which ran on PDP series computers. This program would halt the operation that the victim was working on and present a message requesting a cookie. There are consistent reports of viral programs following this pattern, including a very detailed report of a "Spanish Cookie" virus, however the author has never seen any such program. In the absence of such data I have, regretfully, come to the conclusion that this is another piece of computer folklore which has mutated into legend.)
Another, lesser known, prank has a closer relationship to current viral programs. In the RISKS-FORUM Digest (6-42) in March of 1988 there was a detailed outline of the use of the "intelligent" features of Wyse 75 terminals. This was a specific instance of a general case of the use of intelligent peripherals for security cracking. In this case, the terminal had a feature which would allow keys to be remapped from the host system. Another feature allowed the keys to be called for from the host. This allowed email messages (actually only the subject line) to be composed which would remap a key to correspond to the "kill process and logout" command, and then have the command submitted by the terminal. With only a little thought, an email virus could be written taking advantage of this fact.
Hi Fred.
(Just kidding.)
In the early 1980s, Fred Cohen did extensive theoretical research, as well as setting up and performing numerous practical experiments, regarding viral type programs. His dissertation was presented in 1986 as part of the requirements for a doctorate in electrical engineering from the University of Southern California. This work is foundational, and any serious student of viral programs disregards it at his own risk.
(Dr. Cohen's writings are available for purchase from: ASP Press, PO Box 81270, Pittsburgh, PA 15217, USA.)
Dr. Cohen's definition of a computer virus as "a program that can 'infect' other programs by modifying them to include a ... version of itself" is generally accepted as a standard. On occasion it presents problems with the acceptance of, say, boot sector viral programs and entities such as the Internet/UNIX/Morris worm. However, his work did experimentally demonstrate and theoretically prove many vital issues.
I cannot, in one column, describe the sum total of his work. In my opinion, the most important aspects are the demonstration of the universality of risk, and the limitations of protection. His practical work proved the technical feasibility of a viral attack in any computer system environment. (This feat was achieved within a closed environment and could not, by its nature, have predicted the social and psychological factors which have contributed to the pandemic spread of viral programs "in the wild".) Equally important, his theoretical study proved that the "universal" detection of a virus is undecidable. Although monitoring and analytical programs have a place in the antiviral pantheon, this fact means that they, and, in fact, all other antiviral software, can never give 100% guaranteed protection. Without this early work, it is likely that some toilers in the antiviral vineyards would still be pursuing that elusive grail.
I would not say the same of trojans. I distinguish between a prank and a trojan on the basis of intent to damage. The Trojan Horse was the gift with betrayal inside; so a trojan horse program is an apparently valuable package with a hidden, and negative, agenda.
Trojans are sometimes also referred to (less so now than in the past) as "arf arf" programs. One of the first was distributed as a program the would enable graphics on early TTL monitors. (That should have been a giveaway: such an operation was impossible.) When run, it presented a message saying "Gotcha. Arf, arf." while the hard drive was being erased.
Trojan programs are spread almost entirely via public access electronic bulletin boards. Obviously, a damaging program which can be identified is unlikely to be distributed through a medium in which the donor can be identified. There are, as well, BBSes which are definitely hangouts for software pirates, and act as distribution points for security breaking tips and utilities. These two factors have led to a confusion of trojan programs, viral programs and "system crackers" which has proven extremely resistant to correction. It has also led to a view of BBSes as distribution points for viral programs. (Recently our local "tabloid" paper's computer columnist, normally better versed than this, dismissed the availability of antiviral software to combat Michelangelo by saying that no self respecting company would ever use a BBS.) This in spite of the fact that the most successful viral programs, boot sector infectors, cannot be transmitted over BBS systems, at least not without sophisticated intervention (generally at both ends of the transfer.)
In the fall of 1989, approximately 10,000 copies of an "AIDS Information" package were sent out from a company calling itself PC Cyborg. Some were received at medical establishments, a number were received at other types of businesses. The packages appeared to have been professionally produced. Accompanying letters usually referred to them as sample or review copies. However, the packages also contained a very interesting "license agreement":
"In case of breach of license, PC Cyborg Corporation reserves the right to use program mechanisms to ensure termination of the use of these programs. These program mechanisms will adversely affect other program applications on microcomputers. You are hereby advised of the most serious consequences of your failure to abide by the terms of this license agreement."Further in the license is the sentence: "Warning: Do not use these programs unless you are prepared to pay for them".
The disks contained an installation program and a very simplistic AIDS information "page turner" and risk assessment. The installation program appeared only to copy the AIDS program onto the target hard disk, but in reality did much more. A hidden directory was created with a nonprinting character name and a hidden program file with a nonprinting character in the name was installed. The AUTOEXEC.BAT file was renamed and replaced with one which called the hidden program, and then the original AUTOEXEC. The hidden program kept track of the number of times the computer was rebooted, and, after a certain number, encrypted the hard disk. The user was then presented with an invoice and a demand to pay the license fee in return for the encryption key. Two major "versions" were found to have been shipped. One, which waited for 90 reboots was thought to be the "real" attempt: an earlier version which encrypted after one reboot alerted authorities and was thought to be an error on the part of the principals of PC Cyborg.
The Panamanian address for PC Cyborg, thought by some to be a fake, turned out to be a real company. Four principals were identified, as well as an American accomplish who seems to have had plans to have sent 200,000 copies to American firms if the European "test" worked. The trial of the American has just been suspended, as his bizarre behaviour in court is seen as an indication of "diminished responsibility".
The idea was sparked by a speculation regarding "evolution" and "natural selection" in pirated copies of games at Texas A&M: the "reproduction" of preferred games and "extinction" of poor ones. This led to considerations of programs which reproduced on their own. (I see no reason to doubt the author's contention that there was no malice involved: this was, after all, the first case that we know of. Indeed, it was Joe's contention that a virus had to be relatively "benign" in order to survive.)
Apple II computer diskettes of that time, when formatted in the normal way, always contained the disk operating system. Joe attempted to find the minimum change that would make a version of the DOS that was viral, and then tried to find an "optimal" viral DOS. A group came up with version 1 of such a virus in early 1982, but quarantined it because of adverse effects. Version 2 seemed to have no negative impact, and was allowed to "spread" through the disks of group members.
Eventually security was relaxed too far and the virus escaped to the general Apple user population. It was only then that the negative impact of the virus was seen: the additional code length caused some programs, and one computer game in particular, to abort. A third version was written which made strenuous efforts to avoid the memory problems: parts of the coding involve bytes which are both data and opcode. Version 3 was subsequently found to have spread into disk populations previously felt to be uninfected, but no adverse reactions were ever reported.
(For those who have Apple DOS 3.3 disks, location B6E8 in memory, towards the end of track 0, sector 0 on disk, should be followed by eighteen zero bytes. If, instead, the text "(GEN xxxxxxx TAMU)" appears, the digits represented by the "x"s should be a generation counter for virus version 3.)
The story has an interesting postscript. In 1984, a malicious virus was found to be spreading through the schools where all this took place. Some disks appeared to have some immunity. These immune disks turned out to all be infected with version 3.
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 defence 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.)
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, 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.
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 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.)
The Brain "family" is prolific, although less so than Jerusalem. (Seemingly, any "successful" virus spawns a plague of copies as virus-writer-wannabes use it as a template.) Again, like the Jerusalem, it seems that one of the lesser variants might be the "original". The "ashar" version appears to be somewhat less sophisticated than the most common "Brain", and Brain contains text which makes no sense unless it is "derived" from ashar. Brain contains other "timing" information: a "copyright" date of 1986, and an apparent "version" number of 9.0.
Brain is a boot sector infector, somewhat longer than some of the more recent BSIs. Brain occupies three sectors itself, and, as is usual with BSIs, repositions the normal boot sector in order to "mimic" the boot process. As the boot sector is only a single sector, Brain, in infecting a disk, reserves two additional sectors on the disk for the remainder of itself, plus a third for the original boot sector. This is done by occupying unused space on the diskette, and then marking those sectors as "bad" so that they will not be used and overwritten. The "original" Brain virus is relatively harmless. It does not infect hard disks, or disks with formats other than 360K. (Other variants are less careful, and can overlay FAT and data areas.)
Brain is at once sly and brazen about its work. It is, in fact, the first "stealth" virus, in that a request to view the boot sector of an infected disk, on an infected system will result in a display of the original boot sector. However, the Brain virus is designed not to hide its light under a bushel in another way: the volume label of infected diskettes becomes "(c) Brain" (or "(c) ashar" or "Y.C.1.E.R.P" for different variants). Hence the name of the virus.
Well, it's quite simple really. In one of the most common Brain versions you will find text, unencrypted, giving the name, address and telephone number of Brain Computer Services in Pakistan. The virus is copyright by "ashar and ashars", so we have two brothers running a computer store who have written a virus. Simple, right?
(Oh, the danger of simple answers.)
First of all, Alan Solomon's analysis and contention that ashar is older than Brain is quite convincing. Also, in the most common version of Brain, the address text does not appear. Further, it would be a very simple matter to have overlaid the text in the ashar or Brain programs with the address text.
What motive would the owners of Brain Computer Services have for the writing of a virus? One story is that they sell pirated software, a practice that is legal in Pakistan, but not in the United States. Therefore, the infected disks were sold to Americans in punishment for their use of pirated software. Unconvincing. The moral attitude seems quite contorted, Brain would have no reason to "punish" the United States (its major source of software) and the Brain infection is not limited to the western world.
Another story is that Brain wrote some software of their own, and were incensed when others pirated their software. Unlikely. Infected disks would be most likely to be sold by Brain Computer Services, and this would tend to mean that a customer would be more likely to get a "clean" copy if it was pirated. (The hypothesis that Brain is some kind of copyright device is absurd: the virus would then be going around "legitimizing" bootleg copies.)
Given that Brain is relatively harmless it is possible that the virus was seen as a form of advertising for the company. Remember that this is the earliest known MS-DOS virus, and that the hardened attitude against viral programs had not yet arisen. Brain predates both Lehigh and Jerusalem, but even some time after those two "destructive" infections viral programs were still seen as possibly neutral or even beneficial. In those early, innocent days, it is not impossible that the author saw a self-reproducing program which "lost", at most, 3k of disk space as simply a cute gimmick.
The Ohio and Den Zuk variants contain the Brain identification code, and so will not be "infected" or overlaid by Brain. However, Ohio and Den Zuk identify Brain infections, and will replace Brain infections with themselves. Thus, Ohio and Den Zuk may be said to be agents acting against the Brain virus (at the expense, however, of having the Ohio and Den Zuk infections). frisk also found that the Den Zuk version preferentially overlaid Ohio. (This "seeking" activity gives rise to one of Den Zuk's aliases: "Search". It was also suspected that "denzuko" might have referred to "the search" for Brain infections. This turned out not to be the case.)
There is text in both strains which indicates a similarity of authorship. Ohio contains an address in Indonesia, both contain a ham radio licence number issued in Indonesia. Both contain the identical bug which overlays FAT and data areas on non-360K format disks. Den Zuk has the more sophisticated touches in programming. >From all of this, frisk concluded that Ohio was, in fact, an earlier version of Den Zuk.
So it proved to be, in a message from the author. The author turns out to have been a college student in Indonesia who, to this day, sees nothing wrong with what he did. (On the contrary, he is inordinately proud of it, and is somewhat peeved that his earlier creation is "misnamed" Ohio: he's never been there. The name of Ohio was given by McAfee in reference to the place of the first identification of the viral program: Ohio State University.) Den Zuko is his nickname, derived from John Travolta's character in the movie "Grease".
Full details of Fridrik's analysis and his contact with the author are available in Fridrik's article in the Virus Bulletin.
Brain itself is the first known MS-DOS virus, aside from those written by Fred Cohen for his thesis. In opposition to his, Brain is a boot sector infector. One wonders, given the fact that the two earliest viral programs (for the Apple II family) were "system" viri, whether there was not some influence from these earlier, and similar, programs.
Brain is the first example of "stealth" technology. Not, perhaps, as fully armoured as other, later, programs, but impressive nonetheless. The intercepting and redirection of the system interrupts had to be limited in order for the virus to determine, itself, whether or not a target was infected.
The Den Zuk and Ohio variants use the trapping technology which can be used to have a virus survive a warm boot. Although they do not survive, the fact that the <Ctrl><Alt><Del> key sequence is trapped, and that another piece of programming (in this case, the onscreen display) is substituted for the reboot code proves the point. The virus could be made to survive and to "fake" a reboot. (The recovery of the system would likely require a lot of programming and code. This has been pointed out before, and the "recovery mode" of Windows 3.1 probably proves it.)
Den Zuk and Ohio are also "virus hunting viri". This possibility has long been discussed, and these examples prove it can be done. They also indicate that it is not a good idea: Den Zuk and Ohio are far more dangerous than Brain ever was. The Solomon and Skulason analyses are fascinating for tracking the trail of a virus "mutation" through the same, and different, authors. The evolution of programming sophistication, the hesitation to alter the length of text strings, even while they are being replaced, and the retention and addition of bugs form an engrossing pattern to follow.
The story, on Compuserve, had actually started a day earlier. A user had earlier downloaded the same Hypercard stack from the Genie system, and noticed, when he used it, that an INIT resource had been copied into his system folder. (In the Mac world, this generally means that a program is executed upon startup. Many of these programs are "background" utilities which remain active during the course of the session.) The user, noticing that this same file was posted on Compuserve, had put up a warning that this file was not to be trusted.
The moderator of the Forum initially downplayed the warning. He stated that there was no danger of any such activity, since Hypercard "stacks" are data files, rather than programs. Fortunately, the moderator did check out the warning, and found that everything happened as the user had said. Furthermore, the INIT resource was "viral": it spread to other "systems" that it came in contact with. (At that time "system" disks were more common among Mac users, as "bootable" disks were among MS-DOS users.) The moderator apologized, posted the warning, and a number of people started looking into the structure of the virus.
The virus appeared to be benign. It attempted to reproduce until March 2, 1988. When an infected computer was booted on that date, the virus would activate a message that "RICHARD BRANDOW, publisher of MacMag, and its entire staff would like to take this opportunity to convey their UNIVERSAL MESSAGE OF PEACE to all Macintosh users around the world." A laudable sentiment, perhaps, although the means of distribution was unlikely to promote a "peaceful, easy feeling" among the targeted community. Fortunately, on March 3 the message would appear once and then the virus would erase itself.
Brandow at one point said that he had been thinking about the "message" for two years prior to releasing it. (Interesting, in view of the fact that the date selected as a "trigger", March 2, 1988, was the first anniversary of the introduction of the Macintosh II line. It is also interesting that a "bug" in the virus which caused system crashes affected only the Mac II.) Confronted by users upset by the virus, Brandow never denied it. Indeed, he was proud to claim "authorship", in spite of the fact that he did not, himself, write the virus. (Brandow had commissioned the programming of the virus, and internal structure contains the name "Drew Davidson".)
Brandow gave various reasons at various times for the writing of the virus. He once stated that he wanted to make a statement about piracy and copying of computer programs. (As stated before in association with the Brain virus, a viral program can have little to do with piracy per se, since the virus will spread on its own.) However, most often he simply stated that the virus was a "message", and seemed to imply that somehow it would promote world peace. When challenged by those who had found and disassembled the virus that this was not an impressively friendly action, Brandow tended to fall back on rather irrational arguments concerning the excessive level of handgun ownership in the United States. (My apologies on behalf of my countrymen. While few of us like handguns, not many of us show this level of illogic.)
(It is interesting, in view of the "Dutch Crackers" group, the Chaos Computer Club and the Bulgarian "virus factory", that Brandow apparently felt he had a lot of support from those who had seen the virus in Europe. The level of social acceptance of cracking and virus writing shows an intriguing cultural difference between the European states and the United States.)
My suspicion, once again, is that the MacMag virus was written primarily with advertising in mind. Although it backfired almost immediately, Richard Brandow seems to have milked it for all it was worth, in terms of notoriety. For a time, in fact, he was the "computer commentator" for the CBC's national mid-morning radio show, "Morningside" (somewhat of an institution in Canada.) While I never heard of MacMag before the virus, I've never seen a copy since, either. According to the recent news reports, Richard Brandow now writes for "Star Trek".
A resource (named DREW in the Hypercard stack and DR in its viral form) was copied into the System folder on Mac systems. The System folder, as the name implies, is the "residence" of the operating system files. With the resource based structure of the Mac OS, the operating system can be configured and customized by "dropping" resources into the System folder. (MS-DOS users, tired of fiddling with entries in CONFIG.SYS, conflicting TSRs and the like, might be warned that this does not always work as easily as it sounds.)
"Bootable" Mac disks contained a System folder, in the same way that "bootable" MS-DOS disks contain the "hidden" system files and COMMAND.COM. In those days, "system" disks were much more common than they are now. In addition, Mac users would often create "system" disks that would have specialized configurations. (I well remember, at the time, a number of Macintosh programs which would work with one specific version of the Finder only. This would put the user in the position of having to "downgrade" the computer each time it was desired to run these programs.) The Mac OS "opens" each disk inserted into the machine. Therefore, on an infected machine, any diskette which was inserted into the drive would have the MacMag virus into the system folder.
The MacMag viral resource was placed into the folder as an "INIT". This meant that it would be one of the "initial" programs automatically run on system startup. Many, if not most, INITs are background or resident programs which either monitor or support different functions on an ongoing basis. Therefore, this was a perfect position for a virus. On an ongoing basis it would be able to watch for opportunities to spread.
The MacMag virus was not a sophisticated piece of programming. As one of the earliest (one of the (rarely used) names for it was the "Macinvirus") Mac viral programs, it didn't have to be. (Some would say that Mac viri don't have to be sophisticated anyway. Although the Mac world have far fewer viral strains than does the MS-DOS world, infection rates of a given virus have tended to be far higher in Mac populations.) There is no particular secrecy to the MacMag virus. Anyone who looked could find it. Few, however, looked.