Advent of Computing - Episode 41 - Return of Viruses: The Spread

Episode Date: October 18, 2020

It's time to round out spook month with a return to one of last year's topics: the computer virus. Malicious code traveling over networks is actually a relatively new phenomenon, early viruses were much different. In this episode we examine ANIMAL and Elk Cloner, two early viruses that were meant as practical jokes and spread by hapless computer users. Along the way we will see cases of parallel evolution, name calling, and find out if there is any one origin to the word "virus". Like the show? Then why not head over and support me on Patreon. Perks include early access to future episodes, and bonus content: https://www.patreon.com/adventofcomputing

The Stuxnet computer virus is one of the more strange sagas in recent history. The malicious software had a highly specific target, the control systems used in Iran's nuclear refinement program. Once systems were infected, Stuxnet laid mainly unnoticed, but it slowly caused damage to key machinery. It was subtle, but the virus managed to cause serious delays for Iran's researchers. It was first identified in 2010, but even knowing the problem didn't stop its reappearance. Now, already, that shouldn't sound normal. Stuxnet was developed by some intelligence agency. We don't know who, but they probably got a lot of help from the US government. And it was meant to destroy a single target. Now, that's a far cry from the indiscriminate hackers that are messing around with oblivious

computer users every day. By contrast, Stuxnet is often called the first digital weapon. Facilities in Iran were only the first known target. The virus would show up around the world in the coming years. When it was released, Stuxnet was bleeding-edge technology. It was massively complex and had the potential to do a lot more than just trash industrial machinery. Despite being cut from such high-tech cloth, there's something decidedly old-school about the virus. There's something decidedly old school about the virus.

You see, at first, Stuxnet relied on physical delivery to infect a computer. A lot of really important computer systems aren't actually connected to an outside network. Today, this kind of isolation is called an air gap. But in the past, that was just how computers existed. For Stuxnet to get its digital claws into a computer, someone had to walk up to the target system and plug in a flash drive that contained the malicious software. The theory has even been floated that the flash drive was delivered by some unwitting participant. They may not have even known the dangerous payload they were carrying. In the 21st century, that physical access was the only way to subvert

advanced security measures. But it's following the lead of much earlier viruses. You see, back in the day, before the internet was a common word, computer viruses relied on oblivious people to pass around their malicious code. But the differences don't end there. Besides the vector, code. But the differences don't end there. Besides the vector, early viruses had a much more human face to them. Actually dangerous code is a much more modern invention. In the beginning, most viruses were designed as very complex and very runaway practical jokes. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 41, Return of Viruses, The Spread. Once again, we're in October, which means it's time to look at the spookier side of computing.

This time, we're dipping back into a topic that I covered last year, and that's the ever-frustrating computer virus. If you've ever had to contend with malware, spyware, adware, or, you know, even some bad shareware, then you know a computer virus can be pretty scary. Anyway, in episode 14, I covered the earliest period of the computer virus. It was mostly a discussion of the early theoretical and, surprisingly enough, science fiction writing that floated the idea of malicious code. And then it rounded out with the first real virus. That program, called Creeper, really didn't do much. Using the ARPANET, it was able to jump around from computer to computer, but there were no real issues caused by it. Today, we're picking up from there and looking at the next phase in the evolution of viruses. In the connected world of the 21st century,

the internet is the most common vector for this kind of dangerous code. Creeper came out the gate as a networked bug. But that wasn't the only way that virus was propagated. The story of how computer viruses leave labs and come into more common circulation is, well, it's pretty convoluted. It's a tale of lost code, bored programmers, and unwitting accomplices. So let's dive into the humble computer virus. We'll be looking at how early examples spread through human hands, eventually leading to the first virus on a home computer. We'll also look at how pranks ended up creating a very dangerous idea. And finally, we'll see just how the theory surrounding malicious code changed since von Neumann's first musings all

the way back in 1966. Since it is October, it's only apt that we start this episode with a little bit of a spooky story. In the book The Devouring Fungus, author Carla Jennings describes one early virus like this. Quote, Some even started as games, like Animal, which became a pest when it duplicated like crazy. Created at Dartmouth College in the early 1970s, it asked users to think of an animal, then queried them. Does it have four legs? Does it live in the ocean? Etc. Eventually, the program worked down its knowledge tree until it guessed the animal's identity right and printed, I win. If it was wrong, it printed, tell me something about your animal that's different from all the other animals,

adding new information to its tree and the tree of every other copy of animal in the system. The expanding animal spread like prairie fire, growing so fast that it choked out the system's disk space. The staff destroyed all its copies but one, which someone had saved under a different name, and that copy took off again like a hurricane. Then, a clever staff member released a ferocious new animal, Red in Tooth and Claw, identical to the original, except that when the user signed off, it made two copies of itself, growing through the system much faster than the old program, and destroying any of the old programs that it encountered. Soon, the old animal was extinct, and the new animal king of the wiry jungle. But not for long. The new animal's master programmed it to commit suicide at a certain date, and it disappeared. Now, that sounds pretty bad.

An innocuous-looking game that runs amok, destroying discs and bringing down mainframes. And in the end, the only thing that can stop the wild animal is an even more virulent and dangerous form of the virus. That sounds like some real-life pulp sci-fi, or at least it would be if the story that Jennings told was true. You see, Animal was a real game, and a very real virus. But from there, the details start to differ. The actual story goes something more like this. When 1974 rolled around, the world met the Animal Guessing Game, an instant classic. Haven't heard of this masterclass in game design? Well, then you aren't alone. The game, more often just called Animal, was a popular program on UNIVAC 1100 series mainframes

in the middle of the 1970s. The author, John Walker, would eventually go on to co-found Autodesk, but in 1974, he was just a programmer at an engineering firm, and one that had a little bit too much time on his hands. The initial version of Animal was a fairly straightforward game with a few twists. The game starts by prompting you to think of an animal, and then it asks more questions. Through a series of questions, the computer tries to guess what animal you're thinking of. Basically, it's 20 questions. It's simple, it's fun in short bursts at least, and since it's all text, you can play it at any old terminal you happen to have. And since it's all text, you can play it at any old terminal you happen to have.

The impressive twist was that Animal could learn, or at least it seemed to learn. If the program was unable to guess what you were thinking, then it asked for the right answer, and it filed that game's data away for later reference. This rough style of game was already pretty common on mainframes. We can find examples dating as far back as the 1960s. Sure, it wasn't space war, but guessing games like Animal fit a slightly different niche. You see, in this era, artificial intelligence was becoming an increasingly hot topic. The idea of a thinking machine was, frankly, exciting.

It was becoming part of the zeitgeist, especially amongst computer users of the time. So anything that looked or acted like AI, no matter how rudimentary, well, that garnered a lot of attention. A great example of this was ELISA, a program that roughly simulated human conversation. As you typed back and forth with ELISA, it seemed to pick up on words and phrases, and it gave the illusion of some kind of intelligence. But really, it was just parroting and slightly mutating your inputs based on a set of rules. The program didn't understand what you were actually saying, and it didn't even understand what it was saying back. But it could keep up a bit of an illusion. Animal was very much cast in the same mold as Eliza.

Walker styled the game after its predecessor in a number of ways. But instead of being an open-ended chat program, Animal was a competition. It pitted a human against a computer. And despite not being all that smart, the computer could form complex questions and even learn from its mistakes. Strictly speaking, it wasn't artificial intelligence, but it looked close enough to intelligence that programmers took notice. Once completed, Walker's co-workers took a liking to the program, and it wasn't long until word spread outside of their office. In Walker's words,

Animal, quote, was an immediate hit, and many other Univac users asked me to send them copies of the program. This, of course, was before the days of worldwide data networks, so this involved writing magnetic tapes and mailing them to each requester. What a drag, end quote. and mailing them to each requester. What a drag. End quote. Back in the mainframe days, the community that surrounded computers was a little different. Today, when you want software, you can just go online. You search up exactly what you want and download it. The more astute may even be subscribed to mailing lists or watch certain news sites waiting for interesting items to pop up. Not only was the technology different, but the community was just smaller. Not everyone used a

computer. Personal computers weren't really a thing yet. So we're looking at a group of thousands of users instead of billions. That meant that communities surrounding computers, or usually certain brands or models of computers, were a lot more tightly knit. Companies like DEC, IBM, or Univac all had their own user groups. These groups held meetings, sent out bulletins, and shared the latest rumors and software with each other. And like Walker said, once word got out, there were limited options for distributing software. Users would either

contact the program's author directly and ask for copies, or find a colleague who already had. In either scenario, the programmer, in this case Walker, had a whole lot of work cut out for them. It takes time to write a copy of a program onto tape. And it's not exactly free to mail around bulky digital tapes. Since Animal wasn't commercial software, and Walker still had an actual job, distributing his game just added work on top of existing work. There had to be a better way. Walker's solution was actually an interesting one, but it makes a lot of sense. Why not write a program that distributes software for you? You see, when you're a programmer, every problem looks like a chance for some new code, after all.

In early 1975, Walker set to work developing his solution, a program that he, somewhat menacingly, called Prevade. And this is where Animal changed from an idle-minded game to a real-life computer virus. One of Walker's source code comments explained Pervade like this, quote, This program is a totally new way of distributing versions of software through 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, it's very likely you can tell them they already have it, much to their own surprise."

Here's what I really, really love about that description. Pervade is, in the truest and most original sense of the word, a classic hack. Walker's pulling a computerized prank over other users using some pretty fancy code. You can even hear the humor strewn throughout Pervade's own source code. I can imagine someone calling up Walker and asking for the hottest game on the block, only to find out that Animal was on their mainframe the whole time. All things considered, it's a pretty good joke. It probably got quite a few chuckles, but the joke just happens to come in the form of a computer virus.

All things considered, Pervade is pretty tame and considerate. It works something like this. When a user runs Animal, they get a prompt to, quote, think of an animal. But at the same time, Pervade fires off in the background. While a blissful user pits their wits against the computer, Pervade takes a look at what files and directories the user happens to have access to. If it finds any directory without a copy of Animal, then that's corrected, and Pervade drops in a brand new copy of the game. And that's it. By the time the player is done, every directory they have access to has

its own copy of Animal. On its own, that's just annoying, but it's not dangerous. Pervades interesting because it's a technically simple program, but there's a certain subtlety to it that makes it pretty insidious. Walker wasn't using any exploits or bugs to make animals spread, at least not on the computer side of things. Instead, he was exploiting unaware users. In the underlying file system used by Univac mainframes of the day, and really any modern computer, each file and directory has a certain permission level. This restricts read and write access to either the file's owner or some privileged user with special permissions. Crucially, some files can be shared between

multiple users. If a normal user ran Animal, the program may only spread to a handful of new directories. Most of those folders are probably private to that user, but more often than not, the user will have access to one of these shared folders. And just like that, Animal has now infiltrated a more publicly accessible place. Eventually, another user will come along, see the program, and once run, Animal will spread to all of their folders. This continues until an administrator runs the program. Once that's done, Animal will lodge itself in every directory on the mainframe. And that's it. The infection has gone as far as it can. That's how Animal spreads on a single computer. But the simple game was actually able to hop

mainframes without any sort of network access. And this is where things get a lot more interesting. As I brought up earlier, user groups were an important part of the computing community in this period. Sharing disks and tapes of new programs was just what you do. And this is what Walker was able to really exploit. All he had to do was send off a few copies of this new and improved version of Animal. And from there, the program could grow rapidly. Other Univac users were all too eager to copy and pass around the fun guessing game, all without realizing it contained a computer virus.

So instead of spreading over a network of wires and packets, Walker was able to spread his virus via a network of well-meaning computer enthusiasts. The final piece that I think makes Pervade all the more insidious is that the program could spread without users even realizing it. Since Animal was copied into every directory a user had access to, well, that meant it could find its way onto removable media without a user ever knowing. So an unsuspecting programmer could ship off a disk full of code without realizing a copy of Animal had stowed away. Before the year was out, Animal was on mainframes from San Francisco to Washington, D.C. If we want to get specific, Animal is a very early Trojan horse. It's a virus that hides

itself in a seemingly innocuous program. In this case, a fun and super cool AI guessing game. In trying to get eager players off his back and get a laugh in at the same time, Walker had devised a really good way to spread around dangerous code. But ultimately, Animal was a lot more of a joke than an actual danger. It didn't multiply rapidly, it definitely didn't fill up any disks, and it didn't get replaced by a more dangerous virus. In fact, Animal lived a fairly short life. Walker designed his program to be very fastidious,

and ultimately that would spell disaster for the spreading software. Quoting from Walker, Animal was a very good citizen. It took extensive precautions to avoid even the slightest risk End quote. Now, that change was small, but was enough to make Pervade basically useless. After 76, Animal reverted back to being an innocuous game, almost like nothing ever happened. But it's easy to see how Walker's little joke captures the imagination. A precocious program that seems smart enough to read a player's mind. And it can even spread through thin air. To someone out of the loop, it must have seemed like a digital lifeform was growing before their

eyes. But in reality, it was just some clever code that took advantage of users to spread like a wildfire. Once we arrive in the era of personal computing, things actually get a lot harder for a budding hacker. One of the major reasons that Animal was able to get out of control was the hardware that Walker had at his disposal. The UNIVAC mainframes that he worked with had hard drives that were used for persistent storage, and that actually made a really good home for a computer virus. And since mainframes are pretty complicated shared infrastructure, there's enough space to actually hide something.

Walker's dark machinations would have been discovered instantly if the system only had a handful of files. Animal would be poorly suited to a single-user computer. That being said, personal computers did have one leg up on their big iron counterparts, at least when it came to a platform for viruses. By the 1980s, there were a lot more PCs than there were mainframes. In translation, there was a much larger target for any computer virus. But with the relative simplicity of a home computer and no widespread networking to speak of, a totally new kind of virus would have to be created. So it should come as no surprise that the first virus to spread on home computers was developed in relative isolation. Let me introduce you to our next player,

one Rich Screnta. As with many, he was bit by the computer bug relatively young. In 1980, he was given an Apple II for Christmas, complete with dual floppy disk drives and a screen. From there, it was really easy to get hooked. Programming would become a core part of his life. In the early 80s, the community around home computers was similar to early mainframe-based groups, just, you know, brought down to a bit of a less serious level. Computers had yet to reach every desk in the world, but there were enough users that clubs started to form, usually focused around a single platform. At meetings, users would give talks, show off new programs, pass around discs, and even sometimes be paid visits by traveling computer vendors. It was a really constructive environment, and a great place to grow up as a young programmer.

It didn't take long for Scrintha to become part of the local scene. Quote, I was a member of a computer club in Pittsburgh. I used to copy software and share it with friends. There was a thriving pirate software market and people used to exchange games on software on floppy disks. End quote. Now, this would have been over a decade before anyone heard don't copy that floppy. The key here is that disks were shared early and they were shared often. Copy protection on games and software in the early 80s was either weak or non-existent. So there was no reason not to swap programs with your friends.

What made the system work was mutual trust. If someone handed you a disk that had Oregon Trail written in permanent marker, well, that disk had to contain a copy of the Oregon Trail. Why wouldn't it? But this is a case of a bad apple ruining the bunch. To the then 15-year-old Screnta, it seemed like a disk exchange was a perfect place to play some practical jokes on his fellow user. These started out relatively small. Instead of making a simple copy of a program, he would make some changes. His pranks were simple things, like popping up a secret

message, or randomly shutting down the computer in the middle of a game. In the worst case, an unsuspecting classmate or friend would lose all their save data. But more likely, they'd just be surprised by some enigmatic message popping up on their screen. Sure, these were pretty harmless jokes, but Skrinta was violating his friend's trust. He had to learn that there were repercussions to this kind of behavior. Before long, no one would accept discs from Scrintha. His bad reputation had spread even throughout the small user group he was part of. But here's the thing. Programmers tend to have a funny way of looking at problems,

especially younger and more zealous examples of the species. And Skrinta saw the repercussions of his actions as a major problem. Just like Walker before him, Skrinta was realizing that there were fundamental flaws in how software was being distributed. In this case, one of those flaws just happened to be that no one trusted disks from him anymore. But hey, that's an issue, right? It should come as no surprise that Skrinta took the same approach as Walker. He decided to make software that could distribute itself. So in 1982, he started writing a computer virus for the Apple II. As I brought up earlier, Scrinta was working with a distinct disadvantage.

No viruses yet existed for personal computers, and with good reason. On a single user system, it's hard to hide something. Usually, a user knows all their files. And without a hard drive, it's not as easy to keep software around on the computer. You had to get creative. But this wasn't a problem. As any young hacker, he loved a good challenge. The virus would become known as Elk Cloner. Why the name? Well, honestly, I haven't been able to find any explanation. Luckily, the actual contents of the program are less enigmatic. What makes Elk Cloner such an interesting virus is its method

of infection. You see, the virus doesn't drop a new file on a disk. Instead, Scrinter figured out a way to modify Apple II's disk operating system. As Scrinter put it, quote, The aha moment was when I realized I could essentially get my program to move around by itself. I could give it motive force by having it hide in the resident RAM of the machine between floppy changes, and hitching a ride onto the next floppy that would be inserted. Whoa, that would be cool. End quote. When an Apple II boots up, it normally goes into a basic prompt. But starting in 1978, it was possible to boot a different environment called Apple DOS off a floppy disk. This made it so that you could load up into a more up-to-date operating system. But that also created a very small security hole that Scrinta could pick away at. The initial boot routine on the computer is stored in read-only

memory. You can't modify that without special equipment or swapping around microchips. But the boot sector, the chunk of data on a floppy that holds Apple DOS, well, that was just on a disk. You could rewrite that without any hassle. Anytime you turn on an Apple II with a disk inserted, this starting sector gets loaded into memory, and that makes it a great entry point for malicious code. Al Cloner worked by modifying the Apple DOS boot sector,

so once a computer loaded up an infected disk, Elk Cloner was running in memory right out the gate. There was no noticeable change to the disk unless you very carefully inspected the boot sector, but very few people would ever think to do that. Once loaded, Elk Cloner would copy itself onto any disk that the user put into the infected computer. It handled that by binding onto a handful of AppleDOS commands, such as the command for listing and opening files. Since these commands already

access the disk, a user wouldn't even notice weird floppy activity going on. So technically, weird floppy activity going on. So technically, Scranta was using an exploit to make Elk Cloner work. But the main driver of infection was unsuspecting users. Once a few disks were infected, he could just sit back and watch. As disks traded hands at club meetings, Elk Cloner spread to new computers. By infecting some disks at his school computer lab, the virus was able to make its way throughout the campus. But spreading to other systems was just one part of Elk Cloner's payload. The bulk of the program was devoted to, what else, but pranks. And really, Elk Cloner made a computer seem like it was haunted. Every 50 boots, the program would announce its presence in verse. Quoting from the program, Elk Cloner, the program with a personality. It will get on all your disks.

It will infiltrate all your chips. Yes, it's Cloner. It will stick to you like glue. It will stick to you like glue. It will modify RAM too. Send in the Cloner. Now, that's a pretty blatant tell that something unsavory is going on with your computer, but Screnta included a bevy of smaller jokes leading up to the big reveal. These ranged from clicking the Apple II's speakers to inverting or flashing the screen, rebooting the computer, and even causing intermittent crashes. That's not all very devious, but it's definitely infuriating. Like Animal, Elk Cloner was also careful not to cause any real damage. Scrinta made sure his program checked if the disk was already infected, since repeated writes could eventually hurt a floppy disk. Since only the boot sector was being written to, there was also very little risk of losing any files.

This was a good-humored prank, after all. Scrinta was trying to get in a good laugh, not get pilloried. Despite being deathly hidden away, there were some major hurdles that prevented ElkCloner from becoming a real problem for Apple II users. One was the distribution network. Even with disk sharing as popular as it was, getting the virus into the wider world was unlikely. Technical issues also plagued the virus. Notice your computer was infected? Just take out the disk, turn it off, and turn it back on. Without some persistent storage like a hard drive, there was no way to consistently load Elk Cloner. The other problem for Scrinta was that his program could be, for lack of a better word, inoculated against. Since Elk Cloner was built to do no real

damage, the virus carefully checked disks before infecting them. If it noticed a specific signature that indicated the disk already had a copy of Elk Cloner, then nothing happened. Well, turns out, you can just write that signature to disk on your own. No virus needed. If someone was clued into the program, then they could take simple countermeasures. The virus was able to spread through Screnta's school and the local Apple II user community. But the outbreak stopped there. Besides some angry computer users and reportedly a teacher shouting at Scrinta, there was no real backlash. Any outcry or even novelty caused by ElkCloner died out pretty quickly.

It wasn't prank after all. It wouldn't be long before Scrintum moved on to other, more serious projects. Just like with Animal before it, Alcocloner never caused any damage. Almost as quickly as the virus appeared, it disappeared. Largely due to simple technical limitations. Both of these programs were meant as good-hearted jokes, and once their programmers got a few good laughs in, the viruses would largely fade into obscurity. As fun and light-hearted as these early viruses are, there's

always been something that's bothered me about the whole topic. Now, as listeners know, one of the recurring themes of Advent of Computing is that history is a mess, and computer history seems especially predisposed to becoming a pretty big mess. The field in general is so new that details, well, they can get fuzzy in a really strange way. A lot of little things just don't get properly recorded. Really important documents and sources aren't always preserved, they don't seem important at the time. And with so many people connected to the last century of computing, it's easy for the truth to get twisted. We already saw this with the excerpt from The Devouring Fungus. Animal the program turned out to be a lot less scary than Animal the legend. It seems that research around computer viruses, worms, or

whatever you want to call these spreadable programs is particularly rife with this kind of mischaracterization. I mean, it makes some sense. Viruses are scary. They function with a certain level of agency that most programs just don't have. And there are often dark intentions behind their creation. It's a small leap from talking specific exploits and payload paths to whispering about shady dealings and super hackers. The best example of this phenomenon has actually been staring us right in the face. That's the collective name for all these programs.

Even the history of the word virus gets some inconsistent reporting, and for good reason. virus gets some inconsistent reporting, and for good reason. Just like the stories of malicious code burning like prairie fires, the origin of the term virus gets pretty messy. The most commonly cited route for the term is a 1984 paper written by Fred Cohen, at the time an engineering student at the University of Southern California. There is good reason that Cohen is cited. He was the first to take a systematic approach to the study of computer viruses. In 83, Cohen kicked things off by developing and then testing what he called the first virus. Now, it's a little ambiguous how he became interested in malicious programs. In later interviews, he would state that, interested in malicious programs. In later interviews, he would state that, quote,

when the idea came to me, it was incredibly interesting, and I followed up, end quote. Now, I'd like to speculate that Cohen had either no prior knowledge of viruses or at least very limited exposure to earlier works. In other words, Cohen's first virus is probably another case of parallel invention. But I can't say that with 100% certainty, so take that with a grain of salt. The other evidence I have for the case of isolated development comes down to this. Cohen's work wasn't a joke. I don't mean that in any euphemistic sense. He wasn't trying to play a prank on anyone. don't mean that in any euphemistic sense. He wasn't trying to play a prank on anyone. Cohen started developing computer viruses to test the possible dangers of programs run amok.

He was trying to show how existing computer security could be broken fairly easily. While he would develop a number of viruses, I think his first attempt is pretty indicative of his work. This quote first virus hid inside a new Unix program on a USC mainframe. When a user ran the program, Cohen's virus would infect other files that the user had access to. As more users logged into the system, the malicious code spread from account to account. Eventually, he gained access to the files of the administrator. From there, Cohen would have access to the entire mainframe. I say would have because this wasn't a real viral outbreak. Cohen had permission from USC to conduct this experiment, and the first virus was programmed to be very fastidious as

it spread. No data was lost, nothing was damaged, and every infected file and compromised user was tracked. The point was to study how a virus could spread, not to hack a university mainframe. And over a series of trials, Cohen came to a startling realization. Viruses were not only effective at subverting security, but they could do it very quickly. All told, the first virus took Cohen around 8 hours to program, and it was able to fully compromise a mainframe in under an hour. This technology represented a major risk if used by a more malevolent programmer. In 1984, Cohen published his findings in a paper called Computer Viruses, Theory and Experiments, and this is where

we see the first formal definition of a computer virus. From the paper, quote, We define a computer virus as a program that can infect other programs by modifying them to include a possibly evolved copy of itself. With the infection property, a virus can spread through a computer system or network using the authorizations of every user using it to infect their programs. Every program that gets infected may also act as a virus, and thus the infection grows. End quote. Now, that should speak pretty well for itself. for itself. Cohen is not only describing his own experiments, but the same definition works well for programs like Animal, Elk Cloner, Creeper, and many other viruses. As far as the name virus goes,

Cohen says that one of his professors, Leonard Adleman, recommended it. And really, it makes good sense to describe this kind of program as a virus. But computer viruses goes a lot further than just describing a possible digital plague. Cohen presents a well-rounded discussion of the creation, spread, and eventual impact of a computer virus. And in a lot of places, his theoretical writings line up perfectly with what had occurred at certain Apple II and Univac user groups, with what had occurred at certain Apple II and Univac user groups, at least to name a few places. Cohen explains that viruses really have two main routes to infect computers, either flaws in programs or hapless users. Interestingly, he also claims that not all viruses are inherently dangerous. He even describes a so-called compression virus that

would infect files by compressing them, with user permission, of course. And here, Cohen is really hitting the nail right on the head. The intent is what makes a virus good or evil. Now, that's all material we've seen play out in the real world. Animal wasn't malicious at all, and it spread through eager users wanting to waste server time. wasn't malicious at all, and it spread through eager users wanting to waste server time. Alcheponer was able to get around with a combination of a floppy disk exploit and a culture of piracy, but it still didn't have any ill intent.

But Cohen goes further than just describing viruses. He also gets into the possibility of virus mitigation. Now, he didn't use the exact word, but Cohen describes antiviral software. And this is where his work takes a pretty interesting turn. Cohen shows that it's essentially impossible to protect yourself against viruses. There's no universal solution that will keep your beloved computer safe. Cohen argues that the problem comes down to telling the difference between a virus and a normal program. On its face, that sounds hard, but if you think that, then you're wrong. It's actually impossible. Once compiled and running, a program is just a pile of ones and zeros.

You can't really tell what it does just by looking at it. Characterizing a program just by examining its code is not a trivial process. In this sense, programming is actually an art, albeit a very technical one. A computer can run a program, but you can't really ask it if a program's doing something dangerous. You need a human to accurately do that. Specifically, Cohen posits that the problem of discerning a virus from a safe program is NP-complete. Now, that's a really bold statement, but he does back it up. NP-completeness is basically a way of saying that a problem isn't solvable by a computer in a finite amount of time. These are problems that you either need a human mind or really good artificial intelligence to solve.

So cold reading source code to catch a virus is out. One approach that Cohen puts forward is compiling a database of viral signatures. This would be a list of patterns that you've seen in known viruses. Then you could write a program that looks for those patterns in other files. But he also readily accepts that that approach is inherently flawed. For one, new viruses can be written that you don't know about, at least not until it's too late. That's already frustrating.

But things just get worse. Cohen laid out how you could create what he calls a quote evolutionary virus. Essentially, a virus that can slightly change its payload as it spreads. Now, that could sound a little bit wild, but the code for such a virus is actually pretty simple. Don't think of it as the virus actually evolving or adapting. It's just changing some bits around the payload to avoid detection. The program already has to copy itself as it spreads, so Cohen just adds the extra step of tweaking and changing the new copy of the virus. If it took 8 hours for Cohen to write his first virus, it wouldn't take that much longer to write

one that evolved. If you're smart about how the virus changes, then it makes it actually impossible to detect a signature. Any one of these points that Cohen brings to the table would be important, but combined, it's even more impressive. This is one of those crystal ball moments for me. Somehow, Fred Cohen was able to look into his digital orb and tease out a picture of the future. The definition that Cohen laid out is still perfectly applicable today. He also characterized the cat and mouse game played between the authors of viruses and antivirus software. And perhaps most importantly, Cohen realized that viruses were an unstoppable threat.

Cohen's work is vastly important. It would be wrong of me to deny that. All that being said, he did not coin the term virus in 1984. And, well, this is where we get into that mess that I mentioned earlier. Just like how many early viruses were created in isolation, the name seems to pop up somewhat naturally. The operative problem with this line of questioning comes down to, as always in my life, The operative problem with this line of questioning comes down to, as always in my life, proper sourcing. People weren't exactly posting online about their malicious code back in the 1970s. Since the development of early computer viruses happened in relative isolation, there wasn't all that much ink spilled on the topic for a while, at least until Cohen put word to

paper. Even the nature of early viruses made discussion somewhat scarce. Practical jokes lose their impact if everyone knows about them. This combined means that we don't have all that many contemporary sources to work with. However, with a little digging, an interesting story starts to form. If you listened to last year's virus episode, then you already know one of the complications to the story. In 1970, Gregory Binford published The Scarred Man, a sci-fi short story that described a program called Virus. It spread over telephone lines,

infiltrated mainframes, and stole valuable processing time. In other words, Binford described a virus and even called it by the modern name. The caveat here is that the Scarred Man wasn't very popular. It showed up in a sci-fi magazine and then remained out of print for quite some time. So, that's kind of out. But that's just the start. Names for dangerous software show up in some strange places. Going forward just one year, we come to the 1971 edition of the Unix User Manual, written in large part by Ken Thompson. In the entry for Chone, the command that changes the ownership of a certain file, Thompson explains that there are certain restrictions on the program

in order to prevent, quote, Trojan horses able to misuse others' files. Now, that's not the exact word, but Trojan horse is commonly used to describe a specific type of virus, one that stows away in a seemingly innocent program. I'm thinking here of something like Walker's animal guessing game. Now, it goes without saying that people were writing viruses before Cohen's 1984 paper, but this gives us some more ammo for the argument. This also shows that programmers were using similar language to Cohen's work as far back as the 1970s. At least, this source wasn't unknown to Cohen. He even cites this Unix manual as an early use of the term Trojan horse in some of his papers. While this isn't the exact definition of a virus we're looking for,

I think it's just as important. The language around malicious code was there well before Cohen put pen to paper. But there's one other example that closes the case as far as I'm concerned. This takes us back to a very important lead that I kind of buried at the beginning of the episode. Now, John Walker actually published the source code for Animal. This gets a little confusing, so bear with me. In 1985, Scientific America ran an excerpt of a letter from a certain programmer at MIT, and it described the outbreak of Animal. The article in question was a long piece on what else but computer viruses. It even includes all the programs we've talked about, from Creeper all the way up to Elk Cloner. This version of the Animal

story is, to put it lightly, over-sensationalized. It's pretty close to the interpretation from the devouring fungus that I started the episode with. Animal goes wild on mainframes and is eventually destroyed by a more powerful animal. Now, at the time, Walker was a subscriber to the magazine, so it didn't take long for him to notice something was amiss. As he put it, quote, It's rare enough to hear an urban legend which you know any of the facts, but it's astonishing to read a major magazine and encounter such a story which you not only personally recall, but which you're responsible for, end quote. Walker hammered out a letter to the author responsible over at Scientific America. And, importantly for us, he included a copy of

the source code for Animal and Pervade. Soon thereafter, a correction was printed in the magazine. Now, this little episode is important for two big reasons. Firstly, that the concept of a computer virus was popular enough to get major press coverage as early as 1985. But the best part is that the source code for Animal was actually preserved after its usefulness ended. You can find both the letter and all the source code that was included with it on Walker's personal website, 4MeLab. Now, I gotta say that anytime I run into well-preserved source code, it's kind of a big deal. And in the case of animal, well, it's a really big deal. Not only is the entire program there, but it's fully commented. This gives us a fantastic window into Walker's thinking and development process.

Here's a choice section from the animal source code. Quote, a choice section from the animal source code. Quote, the tag virus controls whether the animal process will spread like one throughout the 1100 series user community. Under that is the definition for a variable called virus. With the comment, go wild. Not only do we have a variable named virus, but Walker's code comment matches the later definition of a computer virus. And this is in 1975. It's years before Cohen started his experiments. From this, it seems clear. The name virus was just so obvious that it was never really coined. It was used because it fit what these programmers were doing. So should Cohen get

credit for his research into viruses? Definitely. But was he the first person to use the term? No. Alright, that does it for this one. The history of the computer virus is, to put things mildly, a bit of a can of worms. For years, viruses have been a real threat to anyone connected to the internet. But that was never the intended purpose. Programs like Animal or Elk Cloner were meant as good-humored jokes. They just happened to come wrapped up in some of the more dangerous code you can write. And when you get down to it, they didn't even have to break anything or exploit any insecure code to actually work. The real vector was the burgeoning user community around computers in the 70s and the 80s. Both John Walker and Rich Scrinta exploited the trust of their colleagues and friends in order to spread their joke. The very idea of a virus was totally new in this era. There was a lack of discussion about

the technology, and really there was a lack of security measures in general. If someone had wanted to do some real harm, well, the opportunity was there. It just happens that the kinds of programmers drawn to viruses really only wanted to get a few good laughs in. It wouldn't be until the middle of the 1980s that anyone took a serious look at computer viruses. Fred Cohen's work went a long way towards codifying what exactly a virus was, and it explained just how dangerous such a runaway program could be. It took a while, but eventually the industry would take notice of Cohen's warning. In the modern day, computer viruses are dangerous, that's a fact, but their

early history has a totally different character. You may even want to call this the golden age of viruses, when no one really knew what they were, and no real harm was done. The era wouldn't last forever, but for at least a decade, viruses were really just fun and games. Thanks for listening to Advent of Computing. I'll be back in two weeks' time with another piece of the story of the computer. And hey, if you like the show, there are now a few ways you can support it. If you know someone else who'd like the show, then why not take a minute to share it with them? You can also rate and review on Apple Podcasts. And if you want to be a super fan, then you can support the show directly through adren of Computing Merch or signing up as a patron on Patreon.

Patrons get access to early episodes, polls for the direction of the show, and bonus content. Right now, I have up a mini-episode on the Enigmatic MIL-STD-1750A microprocessor. It's a mouthful, but it has an interesting history. If you want to listen to that, it's just $1 a month. You get the bonus content and you get to support me. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at AdventOfComp on Twitter. And as always, have a great rest of your day.