Advent of Computing - Episode 169 - Dellinger's Viruses

Episode Date: October 26, 2025

In 1981 Joe Dellinger attempted to create the perfect computer program: a virus that spread silently. In 1982 a revision of that virus broke containment. It would have remained completely hidden if it wasn't for an obscure Apple II game. Today we look at the story and motivation behind that virus, and how it slipped into the sands of time. Or... did it!? The truth is if you have an Apple II it may be infected with Dellinger's virus!  

The Jargon File, one of my favorite guides to digital folklore, has a very detailed entry for this thing called the Hacker Ethic. Makes sense that I'd spill a lot of ink over it because it's a pretty important and subtle topic. Part of the definition states, quote, The belief that system cracking for fun and exploration is ethically okay as long as the cracker commits no theft, vandalism, or breach of confidentiality. Hackers love to bend and break things, to see what makes a computer tick, to uncover the why and how. In the course of that obsession, sometimes you end up violating more, let's say conventional ethics. You end up breaching the security of a network. You wind up with files you probably shouldn't have access to.

You make some software that should probably not be shared that widely. In these cases, it's not just intent that matters. The digital realm is special because it's non-physical. You can break into a computer without breaking anything. You can steal a file without depriving its owner. How can you say you've been stolen from if you still have the original copy sitting on your hard drive? Thus, we enter this gray zone.

It's not just intent that matters. it's not just impact, it's also the totality of conduct. In this context, normal questions shift in meaning. Considering should I becomes useless in the face of a hacker's obsession. We see different factors come into focus. Can I even do it? And how can I do it without repercussions for myself or others? For any good hack, the aspect of stealth is crucial.

The hacker doesn't want to be interrupted. In some cases, they may breach a system, take a look around, and disappear without anyone ever finding out. In other cases, the hack may end with a grand reveal of the vulnerability or the tricks they used. It's this very aspect, stealth, that makes hacking so interesting and so difficult to document. How do you deal with a story that's meant to be kept hidden? Where would you even look for any confirmation?

of that tale. Welcome back to Spook Month here on Advent of Computing. I'm your host, Sean Hasse, and this is episode 169, the Dellinger viruses. To close out October, I've managed to squeeze in a virus episode. Viruses have, of course, been a mainstay of my Spook Month coverage for years, But it's getting harder and harder to find ones in my time range that I haven't talked about. Today, we'll be looking at a series of viruses developed for the Apple II computer. These viruses, created by one Joe Dellinger and maybe some of his college buddies,

bear a certain resemblance to another virus. That is, elk cloner. What, you don't remember the elk cloner? It was the program with personality. Elk Cloner was written by Richard Scranta in probably 1982. It targeted the Apple 2 and hid on the boot sector of floppy disks. It spread via software piracy. And crucially, it was meant as a funny gag.

Elk cloner didn't destroy anything. It just mocked its victims with a little message as it spread around. Dellinger writes his viruses around the same time as Elk cloner. In fact, he may have started before Screnta. I've characterized this early era of viruses as a period of practical jokes and experimentations. I want to see if Delinger follows that pattern. Did he program for good, for evil, or for a couple of hearty laughs?

Before we start, we need to do my sourcing corner. This is one of the few cases where my main thing. source is, well, the horse's mouth, as it were. Most of this story comes to us from Delinger directly in a series of emails and posts on the early internet. This is also one of the main issues with a lot of these early viruses, and a reason I haven't covered every virus under the sun. When it comes to malicious software and maliciousness around software, you have issues in reporting. Early victims of digital crime don't want to report them because they can damage reputations. That's especially true for businesses. We've seen that pattern whenever we

talk about early computer crime. I mean, we literally saw it a few weeks ago with the MetLife hack we discussed. There are also some events that are so small they don't really bear reporting. Some hacks, tricks, freaks, and even viruses fall into this category. The early 80s is still very early days for computer viruses. There isn't a public consciousness about the threat of viruses. So there isn't really a reason or even a pathway to report on virus outbreaks. You won't find newspaper articles covering this kind of stuff quite yet. All this is to say we need to view Delinger's story with some healthy skepticism.

It may just be folklore or it may be real. The thing is we can't really verify it with any corroborating sources, and that's partly just because there wouldn't have been any corroborating sources in the period. We'll need to address that as we go today. The earliest emails I can find from Delinger date back to 1987. That's after a number of well-known viruses hit the scene, and after some initial academic work about viruses is published. With that in mind, what exactly is the story?

Well, it starts in 1981 at Texas A&M University, where Delinger was just an undergrad student. Delinger and a group of unnamed friends start toying with a very dangerous idea. Texas A&M was a big Apple II campus, and campus was full of software pirates. This was kind of the order of the day back then. Copy protection didn't really work yet, and what did would be circumvented pretty easily. so most software in the wild was pirated, or at least a large amount of software was on copied floppy disks. However, that didn't always work out very well. From Dellinger in a 1990 article, quote,

I noted that most games were damaged in various sorts of ways, but they were almost always still playable despite the damage. For example, there was one popular Star Trek game in Basic that had occasional garbage control characters in non-critical, REM and print statements. Space War games often had random junk replacing some pictures on the ships, etc. I decided that I could explain this by invoking a sort of evolution, end quote. This wasn't the most wild jump in logic.

Computers tend to feel a little bit alive. Back then, that was especially true. Machines were so much more simple and so much less reliable. Plus, they were probably more unreliable, machines in the hands of poor undergrads. Why would you even consider putting money towards new floppy disks and drives when your old one works most of the time, and you're surviving off computer science department pizza parties?

Dellinger's next leap in logic is where we get down this path toward danger. Evolution is, of course, an optimizing process. So could this digital form of evolution be optimizing? And if so, where could it lead? What would be the evolutionarily perfect program? This is essentially the thought process behind genetic algorithms or genetic programming. You make a program that can evolve over time and eventually lead to some optimized program. That program is then set loose in a specific environment.

As it evolves, it fits that environment better. Its fitness increases. But another way, it solves a given problem space. Dellinger and Coe wouldn't get quite as theoretically sophisticated as that. Instead, they wanted to do the evolving on their own. They envisioned what the end stage of that evolutionary process might look like and tried to create that program, the perfect program. The environment here was simple.

Delinger's Apple II computer and his personal collection, of floppy disks stored in his dorm room. So, what did these students think was the perfect program? Simply put, a virus. Now, we can argue about naming convention here. By 1987, Dellinger is calling his program a virus. Would he have called it that in 1981? Probably not. That wasn't really in the lexicon yet, at least not in any wide-scale sense. But I'm going to use the term since, well, it's applicable, and that's what Delinger calls it by the time he's writing publicly about his software. To be a little more specific, Delinger wanted to develop a completely silent virus. His logic here is simple. The key measure of fitness is reproduction,

as in how many copies of the program exist. Games get pretty high scores in that department thanks to piracy. But that's a manual process. A better route, a more optimized route, will be fully automated reproduction, a program that copies itself around without any human intervention or with very limited human intervention. The best kind of self-reproducing program would do so undetected because then there'd be no reason for anyone to interfere with its reproduction. Hence, a virus with no symptoms, a quiet virus for silent reproduction, as it were. The virus would spread from disc to disc, doing nothing but incrementing a counter every time it made it to a new host. It turns out that the no symptom part would be the most

difficult constraint. Spreading is easy, but staying hidden without any side effects. Well, that's another story. These computers are so simple, and their file systems are so primitive and so small that it's hard to hide anything. A first attempt was running by 1982, but according to Dellinger, it was too destructive. We don't have details, but it must have done something pretty nasty. He considered it a total failure. A second version, sometimes called Virus 2, was created using lessons learned from Virus 1.

It's with Virus 2 that we start to see what could have gone wrong with its predecessor. These were boot sector viruses. When the Apple 2 boots from a floppy disk, it reads a specific sector from that disk into memory. That sector is treated as a program and executes immediately. That same method is used by many computers. It's super handy, super simple, and very exploitable. Virus 2 hid around that boot sector, specifically, it modified the boot information for Apple DOS 3.3 disks.

That's pretty specific. It means that Virus 2 could only spread to disks that contained that exact version of DOS. Why would Dillinger target such a specific victim? Well, there's two reasons. The first was stealth. DOS 3.3 had a very large unused region of data inside its boot sector, or boot sectors, but we'll get to the specifics later. That region was always set to a pile of zeros,

and it was always in the same place. That gave virus two a comfy spot to hide in. The second comes down to Dellinger's goal of non-harm. In order to exploit that free space, you have to make sure that free space exists and is 100% never used. That specific hidey hole only existed in DOS 3.3. At least, that was the only place where Delinger could verify that spot existed reliably and safely.

A new version of Apple DOS may use that spot for new code, or it may use that spot for variable storage. So throwing a virus into that area would be destructive. It would cause harm and symptoms. I think it's likely that virus one failed because, well, it didn't respect the hidey hole in the correct way. Dillinger explains that most of Virus 2's code was dedicated to making sure it infected the correct type of discs with that free space. He makes that sound tricky, which to me sounds like it took a while to work out. It would make sense that Virus 1's flaw had something to do with those checking routines. They probably just weren't developed enough yet.

Once hidden, Virus 2 could hitch a ride into memory. As the Apple 2 booted, that boot sector was loaded. Virus 2 became resident in RAM, and it was ready to run. The next time a disk was used, virus 2 would copy itself into that disk's boot sector as long as it was the exactly correct version of DOS 3.3. It turns out that many disks in 1982 met that criteria. When it transferred over, the virus would increment that generation counter.

That way Dillinger could see how. how well the virus spread. At first, this was totally self-contained. Dellinger only experimented with his own disks. That made this pretty close to a research project. He was able to track how the virus spread during his usual use of his Apple 2. And in that capacity, things worked out pretty well. The generation counter went up.

Discs were infected and no harm was ever done. That would be a nice ending, but it's not the entire story. You see, virus two would break containment. Things went so well in this quarantine testing that Delinger and his friends got a little lax with security. They started toying around with the virus on other Apple twos. Thus, the virus started to spread outside Delinger's dorm room.

At first, this was fine, until one of his friends graduated. That unnamed friend went to grad school at the University of Illinois Urbana-Champaign. He took his floppy disks with him. That meant that Virus 2 came along to university. It wasn't long before the program was tearing through the new campus. It spread rapidly thanks to the classic practice of software piracy. As students copied all those floppies, Virus 2 snuck around. At first, it was harmless just as designed.

That was the point. But eventually, it led to a weird issue. Just like its predecessor, Virus 2 had a flaw, and it had to do with that fancy hidey hole. To explain the probable problem, we got to look at exactly how an Apple 2 boots into Apple DOS. When the machine goes to boot, it reads that first sector off the disk. that loads in what's known as the first stage of the bootloader.

This program is small and only does one thing. It reads the next nine sectors off disk. Simple, right? Dillinger says that Virus II expanded that a little. It made DOS's actual resident code take up 10 sectors. It would have also had to modify the first stage bootloader to load 10 instead of nine sectors. That magic 10th sector contained the virus. The actual infection modified a few chunks of DOS 3.3.

It had to, as I mentioned, adjust the first stage bootloader to load the extra sector. It also had to hook itself into DOS 3.3's existing code so it could be triggered. It was just a little more complex than an extra sector of data. Apparently, that didn't play well with some programs. It wasn't entirely uncommon for early home computer programs to do, well, some funky and possibly dangerous stuff to memory. We're talking about overriding chunks of memory, modifying running code, that sort of thing, touching things you're not supposed to touch.

One of those games was called Congo. It didn't play well with Virus 2. Congo was a real game for the Apple 2. In fact, it seems to have been a bit of an obscure title. At least, it's obscure these days. In the game, you pilot a boat down the Congo River, avoiding themed obstacles. The game was spread around by pirates at the University of Illinois. There's some joke there about pirates on a boat, but I'll leave that as an exercise to the reader.

As copies of Congo were made, an infected disc gone into the mix, so virus two would spread with it. If you boot it up and played from an infected disc, then Congo had some kind of graphical glitches. Delinger describes it as screen smearing. It's likely that Congo was trying to reuse some of that Heidi Hole memory that Virus 2 was using, which led to the unfortunate behavior. For Delinger, this was another failure. Virus 2 did have a symptom. It just happened to be a little bit obscure.

This is also a neat illustrative point of why you should stick to documented behavior. Remember how last time we talked about the perils of undefined op codes? When you stray from documented behavior, there's no guarantee that your code will actually work. In this case, Delinger is using memory and space on disk that's technically reserved. You're not supposed to use it. It's something that DOS 3.3 isn't using at the time. but an expansion to DOS might use it, another program might use it. The space is only incidentally free at the time.

In this case, Congo is likely running into that chunk of memory. The result is unexpected behavior. This could have all been avoided if everyone just stuck to the documentation, but I digress. When Dillinger learned of this failure, he set to work on an improved version of his code. Virus 3. The goal of this new virus was to, again, spread with no symptoms. But there is a secondary goal, kill virus 2. As this new virus spread, it should replace all versions of virus 2, and its fingerprint should prevent virus 2 from propagating to upgraded discs. But how would you make sure that the virus truly had no symptoms? Well, you need to hide things better. To quote,

The goal for Virus 3 was that it should take up no room in memory and no room on disk, end quote. That sounds like a bit of a riddle. This is also a spot where Dellinger's story gets a little odd. He says that the trick was to put Virus 3 in, quote-unquote, unprotected memory. The Apple 2 didn't really do protected memory. I think he means that Virus 3 was stored in a location on the floppy day, that was normally used for files. So if you're looking at a floppy disk like a table,

then after the boot sector, there's some special region for file system data. Then there's a larger region that's where a file data is actually stored. The special file system data on the disk tracks where files are stored in the larger region of storage. But there's nothing stopping you from storing data in some special data data in some special sector and just not tracking it in the file system tables. That would hide your data from Apple DOS in a pretty non-destructive way.

But the risk here is if you're doing that, you are way off-spec. If another program tries to write a file the correct way by referencing the table that describes where data is stored on disk, then your secret file would be overwritten. But for Delinger, that was actually a plus. It meant that if another Congo scenario came up, then the virus would get overwritten. No harm, no foul, just some good, clean fun. This is also where the story ends. Virus 3 is unleashed at the University of Illinois, and nothing is ever heard again.

Delinger moved from Texas A&M to grad school at Stanford, and virus 3 would come with him. but it was meant as a perfect asymptomatic virus. It spread in complete silence. It can be found by checking a very specific location on disk, but that's it. There's no way of knowing if your Apple II floppies are infected with the virus, unless you know exactly where to look. As far as stories go, this is a pretty fun one, right? A virus is invented and refined.

It's made to be completely covert. It's so stealthy, in fact, that it's a very fun. it even disappears from its creators. You gotta love that kind of stuff. This also fits nicely into the older pattern of viruses and hacks. Dellinger went to great pains to make sure that his viruses were non-damaging. It's 100% intended as an experiment, as a way to see if this evolutionary code thing was even possible.

There's no ill-will here, just curiosity and good, clean fun. You can see the same pattern show up in viruses like Elk Cloner or The Creeper. I mean, you can even see a similar ethos at play with the MetLife Weather Service hack we talked about earlier. It's a very different approach to computer mayhem that comes out of a very different time. When Delinger sits down to write Virus 1, there are no laws on the books for prosecuting computer crime. Security isn't entirely an afterthought, but there isn't all that much.

thought paid to it? Then our final question, were Dellinger's viruses real? Should we believe his story? This is one where we have no corroboration. And believe me, I've been looking around for period references to viral outbreaks. There just isn't anything out there to back up Delinger's story. The details, however, make some sort of sense. I choose to believe that these viruses were real, but you may disagree. The only way to settle that argument would be to find evidence of the virus in the wild. Luckily, Dellinger tells us how. The virus left a signature, its generation counter.

If you have an Apple DOS 3.3 disk, boot it up and look at memory location B6E8. You may see the markers of virus three. It's the word gin, GEN, followed by a seven-digitig. number, and then TAMU for Texas A&M University. Try it for yourself. I'd love to hear if you find the virus hiding your own floppy disks. All right, that brings today's tale to an end. That also brings Spook Month 2025 to its conclusion. Is there a lesson here to learn? Maybe a moral to all these digital ghost stories? Actually, this year I think I've accidentally fallen into a bit of a theme. If you're going to program or work on computers, which I don't always recommend,

then make sure you stick to the documentation. Don't use illegal op codes, don't use random chunks of seemingly free memory, and don't use some weird out-of-band way to send data back and forth. Conversely, if you're on the other side of the equation, designing things for programmers to use, then assume your users are going to do something unexpected. A mistake or oversight can easily lead to a security hole, or just to something strange. Well, that's it for me. I hope you all have a happy Halloween.

I'll see you in two weeks with a normal episode of Advent of Computing. As always, thanks for listening. You can find links to everything at advent ofcomputing.com, and I hope you have a great rest of your day.