Advent of Computing - Episode 66 - Viruses and the PC

Episode Date: October 3, 2021

It's Spook Month on Advent of Computing! Every October we cover the more spooky, scary, and frustrating side of computers. To kick off this year we are looking at viruses again, this time with a special eye to the first infections for IBM PCs and compatible systems. Besides the technical changes, this drops us into an interesting transitionary period. Up to this point viruses had been something of an in-joke amongst hackers and computer nerds, but with the creation of viruses like Brain and VirDem we see them start to enter public awareness. Selected Sources: https://dl.acm.org/doi/pdf/10.1145/358198.358210 - Reflections on Trusting Trust http://web.archive.org/web/20060427081139/http://www.brain.net.pk/aboutus.htm - Brain Computing on Brain Virus https://archive.org/details/computervirusesh0000burg - Computer Viruses: A High-Tech Disease

It could be a science fiction nightmare come to life. In the last nine months, computer viruses, which could subvert, alter, or destroy the computer programs of banks, corporations, the military, and the government, have infected personal computers at several corporations and universities in the United States, as well as in Israel, West Germany, Switzerland, Britain, and Italy. That's the opening of a 1988 New York Times article titled Computer Systems Under Siege. Computer viruses had existed for quite a while at that point, but the late 80s saw them break into the mainstream in a really big way. 1988 was really when the public first took notice of these new viruses, and by that point, many felt it may already be too late. Viruses

were encroaching on desks across the world. They were working their way into offices and even showing up in some supposedly secure sites. Reports were coming in of months of work being destroyed by these digital interlopers. Floppy disks ruined, computers rendered useless, a once logical world torn asunder. We were looking at a new generation of viruses altogether, and one that was far more virulent than any earlier era. But where did these new viruses come from, exactly? And were they all as dangerous as the media made them out to be? Welcome back to Advent of Computing. I'm your host, Sean Haas, and it's officially time for the podcast to start its annual spook month. For long-time listeners, you should know the drill, but if you're just joining us, then allow me to elaborate.

I set aside every October on the show to cover spookier and scarier episodes in computing's history. In general, computers just aren't very scary, especially not on their own. They kind of don't do anything you don't expect. So I tend to cover topics that are more annoying or inextricable than truly frightening. It's really all just meant to be kind of fun. Now, in the past, we've looked at spam mail and spooky mainframe games, but the mainstay has to be computer viruses. If you haven't guessed from the title already, then we're starting up with episode 66, Viruses and the PC. As far as I'm concerned, computer viruses are a really good fit for this type of theme. They're frustrating, dangerous, and they do, in fact, live in a fully

digital world. In the last two virus episodes, we looked at their really early roots. The term itself comes from a short story called The Scarred Man written by Gregory Binford. A lot of early history here is more in the written word than in actual code. We've also looked at the first viruses to break out into the wider world, both on networks and early home computers. This time, we'll be doing much of the same, picking up in 1984. We're going to cover some theory, some practice, and look at a new generation of computer viruses. As absurd as it may sound, the overarching theme here is one of fun. Early computer viruses were written primarily for fun, to play pranks or just to see what was possible. This is truly in line with the hacker ethic. These virus authors were using

computers as a tool for expression and play, definitely not as weapons. That said, we are getting into dangerous territory here, so I guess we need a disclaimer somewhere around. Today, we're going to be looking at the first viruses that infected IBM PCs. Modern computers and a lot of modern operating systems have really strong ties to the PC era, for better or for worse. Some of the general attack vectors and vulnerabilities we're going to be talking about are still roughly applicable today, so I want to be 100% clear that this is a purely academic discussion meant for the purposes of education and entertainment. Most of this information is outdated, but still, it's adaptable. So please don't go around writing and releasing viruses. That's one not very cool,

and depending on the outcome, it can be illegal. You can get in some hot water for that. I don't want listeners getting themselves in trouble over my fun computer history podcast. I would like to consider that admin of computing is a certain type of subversive media, but maybe not on the level of getting listeners arrested. Which brings us, perhaps naturally, to the other big theme that we're going to be addressing this episode. As more viruses started to appear, the powers that be started to get concerned. As more viruses started to appear, the powers that be started to get concerned.

Some viruses start to have real-world consequences, for those infected and for the virus's creators. We're in this transitionary period where outsiders get exposed to the in-joke that is the computer virus. Instead of laughing, they kind of don't get it. Worse, they consider viruses to be a major and malicious threat, which, to be fair, they are a threat. But we'll get up to that later. I think it's time to kick things off and get into our third annual discussion of computer viruses and all their spooky, fun, and dangerous glory. Now, who wants to talk a little bit about computer science? I did say this was going to be an academic discussion,

so put on your academic hats. Maybe it's something like a mortarboard. Anyway, the next big milestone on the way to our modern understanding of viruses is Ken Thompson's Reflections on Trusting Trust. This was a lecture and accompanying paper delivered at the ACM Turing Award in 1983. That year, Ken Thompson and Dennis Ritchie were given this award for their development of Unix. But the dating gets a little bit weird here. The lecture was distributed as a printed article in 1984, so that's usually the

year that's cited for On Trusting Trust. Also, just as an aside, I'd really recommend reading the paper for yourself. It's only two pages, and I really just like Thompson's writing style. It's a little dense due to the subject matter, but it's definitely worth your time if you're interested. On Trusting Trust is a pretty ambiguous title. The lecture is about the dangers of trusting other people's code. The core idea being that not enough people scrutinize what's running on their computer. And I think that's a wonderful sentiment. We can probably all agree with that, especially as computers have become more and more complicated. Do you really know what's going on inside your computer? Can you really verify where a program

or chunk of code came from? The answer is probably no, at least not offhand. I know I couldn't tell you without checking the exact version of the C compiler that I use and which server that binary file came from. I'd have to go look around, and even then, I'd have to put in extra work to verify that the binary on my hard drive is the same binary that I thought I downloaded. The point here is that humans are easy to trick. It's easy to just trust your computer or trust official-looking software. That complacency and trust is only natural, but that can be very dangerous if exploited. Remember, when it comes to computer systems, humans are often the weakest link. Now, to illustrate his point, Thompson describes a particularly insidious virus. Well, it's kind of a virus. He uses the term

Trojan horse, as in a payload that's hidden inside a seemingly harmless package. Thompson builds up on this in stages, and I think that's probably the most reasonable way to tackle this beast. The stage one of his disaster scenario goes something like this, quote, In college, before video games, we would amuse ourselves by posing programming exercises. One of the favorites was to write the shortest self-replicating program. Since this is an exercise divorced from reality, the usual vehicle was Fortran. Actually, Fortran was language of choice for the same reason that three-legged races are popular. End quote. So there you have it from one of the all-time

greats. Video games are, in fact, the problem. All joking aside, what Ken is describing here is sometimes known as a quine. It's just a fun little program that prints out itself. But there are a few other words you could use to describe this type of software. The two terms that I want to pluck out are self-replicating code and generative programming. The first one here is simple. We've run into this before. Self-replicating code is just the classic, dressed-up name for a type of virus. Specifically, this is the really old-school form of viruses. The first description of a virus, all the way back in The Scarred Man, is a self-replicating program. This is also the kind of thing described by von Neumann's paper on automata. However you cut it, this means a program

that can make a copy of itself. It could be for fun, but this technique can also be used to make a more spreadable type of software. That latter term that I used may sound a little strange at first, but it's something that anyone who's programmed should be familiar with. A generative program is just a program that outputs another program. But this term isn't really used to describe viruses. It's specific to a more useful kind of program, a compiler. I'm bringing this up to point out that, at least in practice, a virus can act in a very similar manner to another more innocuous program. In their earliest incarnations, viruses were basically just programs that,

when run, would output another program. By the book, that's what a compiler does. The key difference is that for viruses, they tend to output themselves or something similar to themselves, whereas a compiler is always outputting something new. Here's where some wheels should start turning. Where would be the best place to hide malicious code, specifically a generative program or a self-replicating program? Obviously, it would be suspicious if a program that's normally not generative or self-replicating started outputting new programs. That's a big red flag. If your spreadsheet program all of a sudden starts saving exe files, then something's probably gone very wrong.

Thompson suggests that a good way to keep from getting noticed would be to put your virus inside a compiler, that you could spread malicious code by first modifying the C compiler itself. What Thompson lays out in On Trusting Trust is a truly scary scenario. He describes implanting a Trojan horse in the C compiler in such a way that it would be very difficult to detect or remove. His trick works thanks to the fact that C is self-hosting. This is where the academic part of this discussion really kicks up a notch. Self-hosting means that the C compiler is written in C itself. That's just a little bit of mind-twisting recursion that actually helped make C so popular. Self-hosting makes it easier to port C to a new computer. You basically just need to do a little

bit of assembly to get an initial compiler working on a new system. Then you can compile the latest C compiler and you're up to speed. From there on out, you never need to touch assembly again. You can just work with C even for compiler modifications. Thompson's compiler vector takes advantage of how the self-hosting process is handled. This sounds a little bit confusing, but the compiler itself has to be compiled. When you make a change to the compiler's source code, you then have to recompile it. Then, on subsequent uses, those changes will go into effect. It could be a really simple change. Thompson uses the example of adding handling for a new control character. Or it could be something like changing the compiler to append a lovekin signature to every program it compiles.

to append a lovekin signature to every program it compiles. That's the next stage. While this is definitely a powerful attack vector, it's still pretty sloppy. This is easy to spot. You just look in the compiler's source code for the change, and then you can strip it out, removing the dangerous code, recompiling it, and then everything's back to normal.

The net effect in this example would be that you no longer get binaries that are signed by kin. To get to the next level, you need a way to cover your tracks, a way to keep your code secret, and a way to keep your code self-sustaining. Luckily, we've been staring right at a solution. The final stage that Thompson suggests is the most insidious. You modify the compiler so it always outputs an infected compiler. Once again, this is that weird realm of self-hosting at work. In a really basic sense, the C compiler can tell what it's compiling. You at least have a file name. So you add in some code that can figure out if it's compiling. You at least have a file name. So you add in some code that can figure

out if it's compiling the C compiler. If so, then you can inject your own code to this new compiler. The trick is that you don't just put in the signature or the new escape code. To make the virus self-perpetuating, you add in the code for detecting when the compiler is being compiled, and then the code for injecting your new payload. The result here is that whenever someone goes to recompile the C compiler, your new trojan is added into the code. This means that your tampering is really hard to uncover, and it's much harder to remove. The only way to really remove these modifications would be to get a totally fresh compiler from an uninfected system. You have to start from scratch. This could very much ruin a computer, at least software-wise. We can break this all down to two

main parts. The first part, and the part that matters the most, is the code for perpetuating the species. That's the part that makes it a virus, that allows your program to continue to spread. The second part is what I've referred to as the payload, the actual code that you want to secretly implant. The example I've gone with so far, the Lovekin signature, is on the fun side of things. But Thompson describes a more realistic option. Quote, The actual bug I planted in the compiler would match code in the Unix login command. The replacement code would miscompile the login command

so that it would accept either the intended encrypted password or a particular known password. End quote. That kind of modification is pretty far outside the realm of fun. This is a serious security issue. By modifying the C compiler to implant a backdoor in the login command, you could give yourself access to root. That's the administrative account under Unix.

It's the keys to the kingdom, so to root. That's the administrative account under Unix. It's the keys to the kingdom, so to speak. In total, Thompson is laying out a road to our digital doom. That said, this isn't a particularly practical route. For this nightmare scenario to occur, the attacker already needs a certain level of access. They need to be able to place the original modified C compiler on a disk somewhere. Ideally, you would want to go to some upstream location that people copy binaries or code from. That way, you could get maximum spread. But for that to happen, you need a certain level of trust. I can't just walk into some server room at Bell Labs, hand them a floppy, and say, hey, I made that patch you wanted. That disk would, at least hopefully, get thrown straight in the trash.

Someone like Ken Thompson would have much better luck getting a change into the Unix codebase. At least, he would have at certain points in the development of Unix. The difference between me and Ken is the level of trust that Bell Labs has in him. That kind of trust can be exploited. Trust also factors in on the user side of things. Infecting a compiler is so devious because, like I keep mentioning, it's a program you usually trust. It's a good mix of important and complicated. While basically all programmers end up using a compiler at some point, very few actually know how compilers work. I mean, I don't know enough about the C compiler

to spot the kind of irregularities that Thompson's Trojan would introduce. I'd wager that very few people actually do. Once again, we get back to the human being the weakest link. Now, I want to point out something that's kind of easy to miss in ontrusting trust. You see, there are a few implicit assumptions about the target system here. The easy one is that Thompson is talking about, very specifically, Unix. But let's sweep that under the rug for now. The attack described, infecting a compiler that then infects the login program, is still a very specific target. For this to all work, you need a computer system that relies on persistent storage.

By this I mean a computer that has some type of long-term, rewritable storage that all programs are loaded from. Something like a hard drive or a floppy drive. Ideally, you need a computer that boots off storage. This sounds basic, but let's think about the context here. OnTrusting Trust is delivered in 1983. In the world of mainframes and minicomputers, hard drive storage was just the norm. You basically need a hard drive, or in some cases a good-sized floppy drive, to run Unix. The system is all about files. Unix boots from this kind of persistent storage.

When the computer starts up, it grabs an initial boot program from disk, then hands it control. Over in the world of home computing, we have a slightly different status quo. Up until 1981 or so, most computers booted straight into programs burned into read-only memory. I'm talking about things like Apple IIs, Commodore VIC-20s, TRS-80s, those kinds of microcomputer systems. You turn on the computer and it starts running a program in ROM. You can load up other programs from tape or floppy disk, but in general, that part happens second. These early microcomputers just aren't relying on piles of files in the same way that a Unix computer does. There are fewer places to hide stuff on these smaller machines. That starts to change around the release of the IBM PC. In 1983, IBM released their XT,

basically a PC with an internal hard drive. We're looking at this transitionary period. At least in certain ways, home computers are moving towards the complexity of larger systems. Discs are becoming more central to these types of computers, and disks are increasingly holding lots of files. This change would inadvertently start to open up the floodgates for future viruses. So far, we've been dealing with pretty cut-and-dry information, all verifiable, all very specific. cut-and-dry information, all verifiable, all very specific. That's about to change. It's time to enter into more murky waters. And let's start with a lovely little reading. Quote, In the late spring of 1988, Froma Joslau, a reporter for the Providence Journal Bulletin of Providence, Rhode Island, booted a disc containing the last six months

of her work product, including the notes for the article she intended to write. After writing the article, she entered print, but the screen came up blank, then displayed the following advertising message on her computer monitor. Welcome to the dungeon. Copyright 1986. Bazit and Amjad, PVT Limited. Brain Computer Services. Address and telephone in Lahore, Pakistan, redacted. Beware of this virus. Contact us for vaccination. End quote. That's from a 1989 report on computer viruses compiled at Harvard. The paper, Rogue Computer Programs, is one of these pieces that has an agenda. A lot of coverage of viruses, especially early on, has this kind of spin to it. They present viruses as a new and scary threat that target helpless victims and do so indiscriminately. There's also

the call for updated laws and enforcement policies to penalize the authors of these viruses. To top that all off, this early coverage also tends to be filled with inaccuracies. The virus described in this passage has become known as the brain virus, sometimes the Pakistani brain virus. It sounds sinister, to be sure. It sounds deadly, and it sounds like it could fit into the narrative of bad code written by bad actors. To be 100% fair, rogue computer programs does go into reasonable detail on the brain virus, but it does get one big fact wrong.

This wasn't a dangerous computer virus. The true story of the brain virus is a little fuzzy, partly because of all the media coverage surrounding it. But we do have all the details we need to put together a picture. details we need to put together a picture. The virus was written sometime in 1985 or 1986 at Brain Computing in Lahore, Pakistan. Brain, the virus that is, was co-authored by two brothers, Amjad Farooq Alvi and Bazit Farooq Alvi. Amjad, the elder brother, is the owner of Brain Computing and has often been cited as the primary author of the virus. The most comprehensive account I've found comes from TRT World, which, oddly enough, is Turkey's state-run media outlet.

Anyway, the 2019 article at least has snippets taken from an interview with Amjad. The background provided here is crucial. It's something missing from a lot of other coverage of the brain virus, and it paints a familiar picture. Amjad, like many of us, became enamored with electronics and computers early in life. Quote, My father wanted me to become a fighter pilot. When I was 10 years old, he bought me two books. One was about airplanes and the other about electronic experiments. I just got into electronics.

End quote. From there, his fascination would only increase. Over the coming years, he would go from scrounging for parts to build radios to skiffing classes in favor of scouring the local library. The switch to computers came in 1980, when Amjad got a hold of a Sinclair ZX80. He found that computers were able to scratch that itch a lot of us have, and so he entered into the new digital world. In the early 80s, Amjad started doing side work repairing computers, and in 1982, he got into the business in earnest, starting up Brain Computing as a small repair shop.

As near as I can tell, Brain Computing was initially an odd job kind of shop. They did computer repairs, sold computers, sold components, and also sold software. Later on, Brain would start importing parts to build PC clones out of their offices in Lahore. Brain would start importing parts to build PC clones out of their offices in Lahore. Crucially for our story, Brain Computing was also open to software development contracts. And this is where the Brain Virus comes into the picture. By this point, probably somewhere in 1985, Bazit had also started working at his brother's shop. The two had become pretty adept programmers

and had since upgraded to a PC-compatible computer complete with Microsoft DOS. Just like Ken Thompson and his cohort, the two brothers would spend free time trying to impress each other with their programming prowess. But not all was well for brain computing. You see, the brothers had a problem with piracy. It's not entirely clear how this started, but apparently custom software that they were hired to develop was being passed on to third parties by their clients. While maybe not totally illegal, it's definitely not totally cool to do that. So Amjad and Bazit decided to do something about it. They devised a system to track who was using

pirated copies of their software. This program is what we now know as the Brain Virus. One of the things that overhyped coverage does get right about Brain is that it's a fairly sophisticated program, especially for the time period. It follows the outline laid out in On Trusting Trust pretty closely. Brain exploits a user's trust of the mundane. Brain is widely considered the first virus for the IBM PC, and it's also the first boot sector virus. To explain how this works and why it's so fascinating, we have to get into how the PC boots up and handles hardware. The first thing a computer does when you flip the switch on is look for a boot sector. A tiny piece of code and ROM starts scanning disks, initially starting with the first floppy disk and then moving on down a list of

options. It's trying to find a disk that's marked as bootable and then load in its first sector. That's the first chunk of data on the disk. Once a bootable disk is found, the PC loads the disk's boot sector into memory and then passes it control. From there, the program stored in that boot sector handles bringing up the rest of the system. This usually means loading up and starting key parts of DOS or whatever operating system you happen to be running. This type of boot procedure offers a lot of advantages over older ROM-based computers. If you need to upgrade to a new operating system, you can just swap out a floppy disk. You can, at least in general, have larger, more complicated operating systems because you have more space to store their code.

It also shows a marked change in the relationship between home computers and their data storage. This is part of that march towards more complex systems with more files and more places to hide. The other piece we need to address here is how the PC helps programmers handle disk I.O. address here is how the PC helps programmers handle disk I.O. When you need to do any kind of hardware control on the PC, you most often reach for BIOS procedures. The BIOS are essentially a bunch of helpful subroutines built into the PC's ROM and exposed as interrupts. You don't really need to know how interrupts work here, They're a little complicated, but there are two key things you need to know about them. First, each interrupt is called by its number in the interrupt table. The interrupt for disk I.O., for instance, is hexadecimal 13.

And second, a programmer can add their own interrupts by modifying the interrupt table. can add their own interrupts by modifying the interrupt table. You can also just as easily reassign the number of each interrupt in that table. So with that background, let's get into how the brain virus hides in plain sight. The main part of the virus is a boot sector. More specifically, it's a floppy disk boot sector. In practice, you could probably install Brain on a hard drive, but the virus is programmed to only go after floppy disks. This initial floppy disk sector is 512 kilobytes in size, which isn't quite enough, so Brain spills over into a couple other sectors on the infected disk. After the infected sectors, Brain stores a copy of the original boot sector. After the infected sectors, Brain stores a copy of the original boot sector.

That will come into play later, so just keep in mind that Brain makes a tiny backup of your old boot setup. When you turn on a PC, it starts loading the boot sector. So if you're booting from an infected disk, you go directly into the Brain virus's code. This is crucial because it means that the moment you turn on your computer, brain is in control. That lets the virus pull some pretty sick tricks to keep itself hidden. Once brain is running, it makes some changes to the PC's interrupt table. It rearranges the table so that interrupt 13, the old disk handling interrupt, is changed to interrupt number 6D. This preserves the computer's normal disk I.O. routines, but it leaves a slot open inside the table.

Brain then defines its own interrupt 13. This means that any time a program on an infected computer tries to access a disk, their request is first routed through the brain virus's special disk handler. After the interrupts get shuffled around, brain loads up and then passes control to a copy of your original boot sector. Your computer then continues to boot normally. The boot process keeps brain hidden during normal operation. You just wouldn't notice anything out of the ordinary.

The other interesting outcome of this process is that once the operating system starts booting, brain is no longer running. Interrupt routines are just chunks of inert code somewhere in memory waiting to be called up. So for the most part, brain will not impact your computer's performance. It just sits and it waits. And this is where we get into the really tricky part. For many operations, the brain virus just passes disk requests off to the original I.O. routines. That's why it's renamed them. If you're just writing to a disk, brain doesn't really care. Same if you're reading from a hard disk or even the second floppy disk.

doesn't really care. Same if you're reading from a hard disk or even the second floppy disk. Brain will only take action once you try to read from the computer's first floppy disk. Brain is trying to be really selective about what it touches so it doesn't cause problems. You can find copies of the brain source code online, so at least if you know a lot of assembly language, then you can follow along to see how the process works. You go to read from your first floppy disk, also known as the A drive under DOS, and Brain intercepts the request. Now in control, the virus reads in the boot sector of the floppy disk

and checks if that disk is infected. If not, then Brain installs a copy of itself onto this new disk. That's how the virus is spread. In most cases, that's all Brain actually does. But it has one other trick up its sleeve. You see, Brain actively works to hide itself. If you try to read the boot sector off an infected disk, Brain will change around your request a little.

Instead of passing you back the Brain boot sector, it will load up a copy of your original disk's boot sector. So there's no easy way to find Brain if you're already infected. That said, there are three symptoms that show you may be infected by the Brain virus. If you answer yes to any of these symptoms, then you may want to consult your computer doctor. First, Brain will rename every disk it infects. In the FAT12 file system, that's the file system used by floppy disks at the time, each disk has a label field. During the infection process, the virus will rename the label field to read copyright brain. Second symptom, reads from your A drive will be ever so slightly slower.

Every time you read from the first floppy drive, brain has to load in the disk's boot sector to check if it's been infected. The actual writes used to infect the disk only happen once, but every read you make has an extra sector tacked onto the beginning of the process. That could be hard to notice in practice, but it is there. And the third symptom, perhaps the most interesting on the list, is that an infected disk will have a number of so-called bad sectors. In the FAT file system, you can mark sectors as unused, used, reserved, or bad.

The first options here are pretty self-explanatory, and reserved is usually just used to mark sectors that are for some special purpose. Bad sectors are marked so that software won't try to read or write those sectors. The reasoning for the bad label is pretty simple. Floppy disks can wear out or get damaged. Marking sectors as bad lets you try to work around them and hopefully transfer data to a fresh disk before your disk goes fully bad. Some disk utilities or DOS tools can scan disks and mark faulty sectors, but in practice, all you have to do is flip around a few bits in the fat data structure. Like I mentioned earlier, the brain virus takes up more than just the boot sector. It needs a few other sectors to store

itself. To stay safe, it marks those sectors as bad. That way no one tries to read them or write over them. This isn't as powerful as brain's active deterrence to reading the boot sector, but it still helps keep things on the down low. So if you made a survey of infected disks, it would look like they were all slightly damaged. Maybe this led some to believe the brain was actually damaging floppy disks. All things considered, the brain virus is a pretty mundane intruder, despite how scary the name sounds. As with many other early viruses, brain is a fastidious kind of beast. It will only infect floppy disks. It preserves the boot sector

so your machine keeps functioning normally. And it doesn't really do much with its access to your computer. The only real malicious part is it leaves that scary welcome to the dungeon message. But in normal operation, you'll never see that. That message is stored inside the boot sector. You normally don't look at your boot sector. And like I keep saying, if you're on an infected computer, brain prevents you from even seeing that.

So there have to be some really special circumstances to even see the welcome to the dungeon message. But that leaves us with a strange position here. If brain is so mundane, then why did it cause a scare? And what should we make of the story from the Providence Journal Bulletin? Well, this is where we get into some issues. You see, there's a lot of mythologizing around the brain virus, and I think that's pretty understandable. When the virus hit the scene, it was the first of its kind. The idea of a virus outbreak on the PC was totally new, and that made it pretty

scary. Because of that, the actual history around the virus has been sensationalized, and that process started as early as 1988. The issue for us is that it makes getting the truth of the matter a little more tricky. The official story from Amjad and Bazit is that the virus first spread within Pakistan as people illegally shared software written by brain computing. But then we have a bit of a weird twist going on here. The explanation that I always see reported is that the laws surrounding software in Pakistan were a little lax in the 80s. Because of this, it was technically legal to import foreign-produced software, copy it, and then sell those copies for domestic use. Now, I cannot find out if that's true. I just don't even know where

to start looking for Pakistani intellectual property laws in the 1980s. So, maybe that's an explanation, maybe it's not. That's just what I see reported. According to early coverage, the two brothers liked to pull a certain trick on American tourists. When travelers from the states came through to buy cheap bootleg software, Amjad and Bazit would sell them special discs that were infected with the brain virus. This has also been hard for me to find direct sourcing on. The story of passing off infected discs to American tourists was common in coverage of the virus in the late 80s and early 90s. One of the higher profile stories ran in Time magazine in 1988.

The article is notable because its author actually did get in touch with Brain Computing to get a statement. Here's a snippet just to give you a taste of how this was being covered. Quote, Then why infect American buyers? Because you are pirating, says Bazit. You must be punished. End quote. The actual article must be punished, end quote. The actual article itself was titled after that quote.

Simply, you must be punished. Once again, just like the Harvard virus report, Time is framing the brain virus as an evil program written by evil actors in order to spread destruction. But as near as I can tell, the whole piracy story is actually true. I was able to track down an archive of Brain Computing's own website thanks to the Wayback Machine. The site's About page actually addresses the virus, and particularly the media coverage of the outbreak. From that page, quote,

Bah, retorts Bazit, since that episode, we have lost all faith in the Western media. They quoted us out of context, put words in our mouths, and did just about everything that you would expect from a cheap local publication run by one's own arch-rival. When we read the stories, we could hardly believe that it was carried in what's supposed to be the best news magazine in the world. It was journalism at its yellowest. Bazit's contempt is not unfounded. What no American journalist had the courage to admit at the time was how badly the virus had hurt America's painfully cultivated image of the world's leading copyright protector. Almost overnight, it had shown Americans to be the world's biggest copyright protector. Almost overnight, it had shown Americans to be

the world's biggest copyright violators. End quote. Now, I think there's something really interesting going on here. Brain's official site doesn't deny that the company was selling infected discs to American tourists. Far from it. The site does reference the virus traveling via piracy. They don't come out and expressly say, yeah, we were giving tourists infected discs, but I think that's close enough to lend the narrative credibility. What I really like is that even the virus's authors are addressing how the media has overhyped the brain virus. I'm also pretty sure that Bazit is referencing the specific coverage in Time, since he was interviewed for that piece, and the journalist chose to put the most scary-sounding quote as the title.

But that still leaves the question, was the brain virus actually destroying data? The Providence Journal bulletin story is corroborated in a number of newspapers and magazine articles from the time. There are also reports floating around in the same period of 1988 or so that the brain virus was spreading and destroying disks at colleges and some other newspapers. We know that Amjad and Bazit didn't intend brain to destroy anything. They just wanted to get people to stop pirating their software and maybe play a prank on some tourists. But could it actually damage computers? I mean, maybe.

The way I see it, there are three possibilities, and this comes partly from going over sources and partly from my reading of the source code. Brain can, in fact, accidentally overwrite data. The virus is stored in the boot sector plus a few additional sectors near the end of the disk. The version of brain that I was looking at stores this extra code at a predetermined sector number. The sector number is hard-coded into the program so it doesn't change and it doesn't adjust if something's there.

There's no checks. These are also the sectors that Brain marks as bad in order to prevent tampering. So, conceivably, if you had part of a file in one of those sectors, it would get replaced. Since those sectors are marked as bad, it would appear that your disk was degrading. is bad, it would appear that your disk was degrading. If you weren't an assembly language fiend like myself, then you'd probably just assume that your disk was being destroyed by something. In practice, the most data you could lose would probably be around 3.5 kilobytes. That's the size of the virus plus the backed up boot sector. So sure, you may lose up to 3.5 kilobytes of data on every infected disk, but your disk would still work fine. I'm not convinced that this is what news

stories were reporting at the time. Since these extra sectors are written as soon as Brain infects the disk, the issue would be noticed immediately if it would be an issue at all. This isn't a symptom that lays dormant. Brain hit the streets in 1986. We don't see any reports of disc death until 1988. Maybe it took two years before the brain virus made it to the states and started infecting discs. Maybe infected discs were just sitting on shelves for a few years.

I don't really buy either of those explanations, and I'll get back to this timeline weirdness in a second. Another possible issue is more speculative, but let's talk about it just to cover all my bases. Remember how Brain intercepts all disk reads and essentially tacks on an extra operation? Floppy disks, like every storage media have a limited lifespan. You can only do so many reads and writes before the disk loses integrity. Now, in theory, that means that you could shorten a disk's lifespan by performing unnecessary operations. Will adding an extra sector read to every disk access actually destroy a disk? I don't think so.

Strictly speaking, it will wear out a disk a little bit faster, but I don't think it would be by enough to be noticed. It's a death by a thousand cuts sort of thing. The final possibility, and what I personally think is the most plausible, is that Brain may have been hijacked by bad actors early on. Now, I want to be 100% clear here, this is also total speculation, so maybe don't trust what I'm about to lay out. Anyway, let's just get a little weird with it for a second. Brain was written in assembly language. This matters because there's

a direct mapping between machine code operations and assembly language instructions. You can disassemble a binary program into assembly language really easily. The only thing you lose are label names and any code comments, but you can still figure out what the program is doing. I've actually been working on reverse engineering a different boot sector recently for another project. It's a bit of a puzzle, but it's totally doable if you're familiar with assembly language and the PC boot process. If one was so inclined and had access to an infected disk, it would be possible to make your own version of brain. Call it a new strain. In fact, there are a number of variants of the brain virus. Most of these only change the text

or add hardware support, maybe remove the disk label part of the program. But those are just the reported variations. My wacko theory is that there could have been a more destructive version of the brain virus. Let's say in the two years between the virus's emergence and the first press coverage, someone got a hold of the program. They could have modified it to spread and then actually destroy the file system on floppy disks. Brain was already a stealth-oriented virus, so I don't think it would be out of the question for this new evil brain to also hide its tracks. Maybe it even replaced itself with a more benign-looking boot sector on the way out, or maybe the modifications were so small as to not be noticeable. Of course, that's just my own fantasy. Nothing really backs that up besides the discrepancy between reported impacts of brain and the actual program itself.

It's possible that people just lied to make brain sound more scary. Or possibly to hide the fact that they were using pirated software. There's one other virus that I want to use to close out today's discussion. There's one other virus that I want to use to close out today's discussion. Like I said at the top, this episode is all about the transitionary period where viruses start bleeding into the world at large. This phenomenon started in earnest with hackers and computer nerds playing pranks and having some laughs. In that context, it was all good fun. Eventually, viruses evolve into actual dangerous programs developed with bad intentions.

Sandwiched in the middle, we get this transition. Something like an interstice where these early just-for-fun viruses start turning into more mainstream topics of interest. I've marked that out kind of in my head in this episode as 1984 to 1988, basically between On Trusting Trust and the first press coverage of the brain virus. There are a handful of viruses that fall into this time period. Brain is a notable example because it was the first virus to really sink its teeth into IBM PCs. It's a technically dazzling virus, especially for the time, but it wasn't meant as a tech demo. It was meant for laughs. The last virus I want to cover

this episode is called VirDim, literally shorthand for virus demo. Written in 1986, the same year Brain was unleashed, VirDim was very much meant as a technical demonstration. It also serves as a wonderful example of the paranoia around viruses. You see, not only was the source code for Verdim widely available, but its author published an entire book on viruses. That includes their history, theory, and how to make your very own. The story of Verdim starts with Ralph Berger and the Chaos Computer Club. CCC is a hacker collective that operates primarily in Europe. That may already sound shady, but that's not really the case. Founded in 1981, CCC is primarily interested in security research and activism.

We aren't talking a shady cabal of super hackers prowling the net for targets. For instance, one of the first big press outings for CCC was when they hacked a German bank and temporarily transferred out some funds. The bank had already been warned that there were issues with their security system, but no one listened, so CCC blew up the situation to get the bank to tighten things up. Ralph Berger, the author of Verdamm, is a somewhat enigmatic figure. We know that he was a member of the CCC and that he lived in Germany, but we just don't know much of his background prior to the mid-80s.

but we just don't know much of his background prior to the mid-80s. In 1987, Berger published Der große Computervirenbuch, which literally translates to The Big Computer Virus Book. The next year, a translation was published under the title Computer Viruses, A High-Tech Disease. Most of our good information on Viridem, at least in English, comes from that second printing. Putting that together with a few other sources, an old virus mailing list called VSUM, a few book reviews, and a short interview with Berger, an interesting story emerges. Things kick off in 1986. From what I gather, CCC was interested in viruses, but not so much on personal computers. The club dealt primarily with mainframes and minicomputers.

The bank hack I mentioned was targeted at a mainframe, and so too were a lot of CCC activities. That's just where most members saw interesting opportunities. But Berger was a little different. As the PC proliferated, he saw an enticing option open up. I haven't seen a specific reason why Berger became interested in PCs, but I think we can make an educated guess. For one, the PC and its clones just didn't have any security in place. IBM had designed the PC as a relatively cheap and simple single-user computer. DOS had been programmed as a simple single-user operating system. Security just wasn't really a

consideration or a concern. By contrast, mainframes had been built up as more secure computers for decades. Timesharing had basically made security a must, since mainframes were shared between multiple users. Mainframes were used for mission-critical applications, so a lot of work had gone into hardening these types of systems against threats. That's not to say that these larger machines were impervious to hacking, far from it. They were just more difficult to crack. The other huge draw for the PC was, perhaps ironically, its success. As cheap clones flooded the market, more home computers could all run the same software. There was a large pool of insecure machines just waiting for

something to happen to them. Ralph Berger decided that that something could very well be a virus. Just like with the brain virus, I want to stress that Berger didn't approach building a PC virus with malicious intent. He was more interested in the academic side of things. Berger wanted to show how an effective virus could be developed to exploit this juicy target. Berger's work would also end up falling in line with the CCC's larger goals, either accidentally or intentionally. In 1986, Berger wrote Verdim as a proof of concept showing how a PC could be targeted and infected. It was most likely developed to show off at a 1986 meeting of CCC that covered computer viruses,

but I haven't seen that explicitly stated, so that's just my guess. What set Verdum apart, besides technical details that we'll get into, is how the virus spread. You see, Ralph didn't pass off disks that were secretly infected to unsuspecting victims. He didn't install Verdum on some network-accessible computer. Instead, Berger passed copies of Verdim to other CCC members as part of a larger educational package. Now, I sadly haven't been able to track down the original documentation that Berger packaged with his virus, but an excerpt of it does exist in the 1988 book he wrote. Here's the beginning of those docs,

basically the mission statement for this program. Quote, The verdim.com program contained on this disk is a program for demonstrating computer viruses. Please note the comments for working with computer viruses in this document before starting the program. Otherwise, it could lead to an unintentional spread of the computer virus. Verdim.com was developed to give all Microsoft DOS users the chance to work with computer viruses without the dangers of uncontrolled virus attack. It shows how helpless a computer user is against computer viruses

if he doesn't take appropriate security precautions." end quote. Ooh, that sounds very malicious, right? Like with earlier CCC operations, Verdim was all about education, exploration, and activism. That second part, the exploratory nature, was shared with a lot of other early viruses. But the educational angle here is a little new, at least outside of formal academics. Sure, on trusting trust is something like an academic treatise on computer viruses, but it lacks a level of specifics. The last time we covered viruses here on the show, we spent a lot of time

talking about Fred Cohen's work. He was really one of the first to take an academic approach to the topic. But the key difference here is that Berger was dealing in the fine-grained specifics of how to build a virus, how it can be dangerous, and how it can be thwarted. And it all came complete with annotated source code. So I guess we should get into what Verdim itself actually did. For this, we need to talk a little bit about how DOS works. Simply put, DOS is the most basic operating system possible. It just lets you load and run executable files from disk. That's about it. These executables, at least initially, were all com-formatted files. Once again, this is the most basic of the basic. Com files are just big chunks of executable machine code. When you start a program, DOS loads the proper com file

into memory and then just jumps to the loaded program. There's no security, no checks, no balances, it just runs a binary. Verdim works by infecting these simple com files, and it does so in a very specific way. When the virus is first executed on a fresh system, it looks for a target, starting with the second uninfected com file in the A drive. Verdim starts with the second file because the first one's usually command.com, which is core to the functioning of a DOS install, so that just wouldn't be fair. Once a suitable candidate is found, Verdim sets to work infecting the file. The virus starts by appending the first few kilobytes of the target.com file to the end of the executable.

This saves the original program and makes room for the virus's payload. Into this newly empty spot, Verdim places a copy of itself. When you run a file that's been infected by Verdim, it does two things. First, it carries out the infection procedure I just outlined. That's the whole self-replicating part of this virus. Then, it plays a fun number-guessing game with you. And yeah, I'm dead serious. That's what the virus actually does. That's the malicious payload. VIRDM prints out some identifying information about the virus, including Ralph Berger's telephone number. Then it asks you to guess a number between 0 and x. Every time Verdum infects a new file,

that x value is incremented up to a maximum of 9, so earlier games are easier. If you guess correctly, then Verdum does a quick memory shuffle to rebuild your original program, and then you can continue your day. If you guess wrong, the program ends and you're kicked back to the DOS prompt. Some of the inner workings of Verdim should sound familiar. Just like the brain virus, Verdim is careful not to actually trash anything. Your program remains intact, just with slight modifications. But the specifics are more interesting. Infecting executable files is a really smart vector,

in part because there's so many com files in a standard DOS install. That means you have a whole lot of places to hide your virus. That also makes Verdim pretty hard to get rid of without specialized tools. Brain can be blown away by wiping the boot sector on a disk. DOS even has a command to do just that. But to remove Verdim, you would have to have a very specific check, and you'd then have to very specifically manipulate every com file on a floppy disk. That takes custom code.

We don't have a whole lot of information on the early period of Verdum's existence. We know it was passed around at CCC, and Berger would send a copy of it to anyone who asked. The next big part of our story takes place with the 1987 publication and 88 translation of Computer Viruses, a High-Tech Disease. And I gotta say, this book was released to some of the most angry reviews I've ever seen. The big stumbling block was that a high-tech disease contained, well, the source code for a number of demonstration viruses. Just for example, from a review written for Virus Information Service by Jim Bates, quote,

Information Service by Jim Bates, quote, lights will need to disassemble and debug these programs before they can advance their own modifications. However, this will undoubtedly be done, and new viruses can be expected to use some of the techniques used in Verdim and other demo virus code. End quote. The number of book reviews that call for criminal charges has to be a short list. Berger is definitely in some rarefied air. Verdim's source wasn't included directly in A High-Tech Disease, but the virus is discussed at length. Further, Berger provides a mailing address so readers can request copies of Verdim for themselves. But that's only part of this book. There's a lot more on offer. All things considered, A High-Tech disease is a really thoughtful and thorough discussion of computer viruses.

Details on virus development only make up part of the book. The rest of the text covers the history of this type of spreading software, the risk that viruses pose, and possible mitigation strategies. As far as I'm concerned, it's a much better response than we saw from Harvard. This 87-88 time period was just when viruses were entering the mainstream consciousness. Berger was offering a fantastic resource on the subject for those new to the concept. At least it was more well-researched than a certain Time magazine article. Berger opens things up in what I think is the best possible way.

It summarizes the pattern we've been grappling with this whole episode. Quote, Yet this book may also be a disturbing book. It raises questions about new ways of programming. Computer viruses offer a unique approach to programming, which is just waiting to be expanded upon by young, interested programmers. End quote. A high-tech disease recognizes that, yeah, viruses are scary. They're disturbing. They're a new kind of program,

at least when it comes to home computers. They're dangerous, and they have to be handled carefully. But on the flip side, they're also fascinating. Young and interested programmers were indeed drawn to viruses. In a lot of ways, early computer viruses exemplify the hacker ethic that enthralls a lot of young programmers. It's a program with a motive force all its own, and if written responsibly, the code can even have a bit of a laugh to it. Alright, that does it for our look at some early home computer viruses. This has turned out to be a pretty long episode, so I'm not going to drag things out with a long outro. I just want to close with one final thought.

The success of viruses in the latter part of the 1980s was only possible thanks to the success of the IBM PC. In that first half of the decade, Bill Gates would state the goal of, quote, a computer on every desk and in every home as central to his dogma. With the spread of the PC and its clones, that became a reality, and it happened quickly. This has led to a type of digital monoculture. The same systems are on every desk around the world. While the sheer level of compatibility has been a boon for the industry, it has also made large-scale virus outbreaks possible. The brain virus couldn't have spread from Pakistan to America if the PC wasn't a worldwide power. And verdum wouldn't have been scary. Berger wouldn't have had calls for his arrest if PCs weren't everywhere.

Thanks for listening to Advent of Computing. I'll be back in two weeks time with another piece of computing's past. And hey, if you like the show, there are now a few ways you can support it. If you know someone else who'd be interested, then why not take a minute to share the show 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 through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and assorted bonus content.

Right now I have a new episode up on Turing's Delilah voice encryption machine, so if you want to catch that, head over and sign up. You can find links to everything on my website, adventofcomputing.com. And if you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at Advent of Comp on Twitter. And as always, have a great rest of your day.