Malware Musings

‘Remember the days of the old school yard?’ Or rather of the old school computer lab. Now that I’ve got this blog thing going, I couldn’t let the 06th of March go by without reminiscing about the Michelangelo virus, and rambling on about viruses ‘back when I was a lad’.

The Michelangelo virus would have been the second virus that I came across, the first one being the reasonably harmless Stoned virus. Given where I was at the time, it would have had to have been either 1990 or 1991, and since the latter matches Wikipedia’s entry, I’m happy to run with that.

Unlike these days when viruses can pretty much guarantee that a computer is connected to a network of some description and ultimately to the Internet, that wasn’t the case back in the early 1990s, at least not for most home users. ‘So’, I hear you ask, ‘how did they spread?’.

Viruses in the early 1990s typically spread by infecting either existing files, the boot block (first sector) of floppy disks, or the MBR (boot block with a partition table) of hard disks. Remember that back then, it wasn’t unusual for a PC to be booted from a floppy disk — after all, hard disks (like the MFM drive I have in an XT) used to be larger than a house brick, and similar in weight too, and for what? A lousy 30 MB of disk space.

Unfortunately I seem to have stopped this XT from being able to boot from its hard disk. A problem which I suspect I caused by moving the XT with an improperly secured (I’m talking screws here, not I.T. security) hard disk, without first pulling the big lever out to engage the ‘shipping lock’.

To compound the problem, the XT no longer seems to be able to boot from any of the 5.25″ floppy boot disks that I have. This is all a bit of a shame as I suspect that that hard disk may contain a copy of the Michelangelo virus which I’d disassembled using good old debug.exe.

Boot block and MBR infecting viruses generally couldn’t use the services of the operating system, because the boot/MBR code gets control before the operating system is loaded. It could sit in memory and wait for signs that the operating system had loaded (look for the interrupt 0x21 vector being modified by MS-DOS for instance, then use it to access MS-DOS’ services), but that would use up valuable bytes of code.

The boot block/MBR viruses would decrement (by two from memory) an area of BIOS memory which was initialised by the BIOS code to indicate how much memory was installed in the machine. This would cause the operating system to think that there was less memory installed than there actually was. This would allow the virus to copy itself to the higher memory addresses (from memory, this was calculated by shifting the decremented BIOS variable left by six bits) and not have to worry about the operating system allocating that memory for something else.

After installing itself in memory, the boot/MBR viruses would typically hook the BIOS disk services interrupt, 0x13. When they saw this interrupt being used to write to (or otherwise access) a disk, they would check to see if they had already infected the disk and if not, infect it.

When overwriting the boot block/MBR, viruses would usually store a copy of the original boot code somewhere. The spot chosen for this was usually the last one or two sectors allocated for the root directory. Unless the disk contained a large number of files/directories in its root directory, these sectors would be unused. The virus would then modify the BIOS memory variable, install an interrupt 0x13 hook, and then load and run the original boot block code.

The Michelangelo virus was the first virus I’d seen that actually did some damage. It used the BIOS interrupt 0x1a to get the current date/time from the real time clock (I can’t believe that I remembered that interrupt number, but then I can still remember some Z80 opcodes from the early/mid eighties — manually assembling code by looking the opcodes up in a table in the back of a book will tend to do that to you. Now if only I could remember more useful stuff like where I put my keys).

Having a real time clock was a bit of a luxury back then — the XT that I had access to didn’t have one, so you had to run the date and time commands from the autoexec.bat file to prompt the user to enter the date and time every time the computer started up.

The Michelangelo virus would retrieve the current date and time (or unspecified register values if a real time clock wasn’t installed) and if this indicated that the date was the 06th March, it would start overwriting disk sectors. Anyone who has ever had to reconstruct a partition table will tell you that if this happens, you’ve got a long night ahead of you.

A lot of the viruses back then tended to stay reasonably quiet. This is in contrast to a lot of today’s viruses that often push CPU usage/network usage/disk usage through the roof thus alerting users to the fact that something may not be quite ‘right.

I forget the conditions under which the Stoned virus would display the ‘Your PC is now stoned’ message, but the Michelangelo virus would do nothing but copy itself, until the 06th of March. If you didn’t turn your PC on on the 06th of March, the virus wouldn’t do anything but continue to copy itself (once the PC was turned back on, obviously).

Some of the boot/MBR viruses would use the momentum of gravity (a reference that I’ve been dying to get in to a blog post, to an advert for an exercise machine) to hide themselves from anti-virus software. They could do this quite easily by hooking the BIOS disk services interrupt, 0x13, and checking for read requests to read the boot block/MBR code. They would then modify the cx (cylinder and sector numbers) and dh (head number), yes, these machines only had 16-bit registers, to read the original boot code that the virus had saved at the end of the root directory, instead.

This meant that any anti-virus software which attempted to check the boot block/MBR of a disk would instead see the original clean boot code and not the virus’ code. This was possible because the virus was getting in to memory and hooking BIOS’ interrupt 0x13 before the operating system and anti-virus software was loading.

For this reason, anti-virus advice back then used to tell you to scan disks from a known clean machine, and anti-virus software would always scan memory before scanning disks/files.

Now with the advent of rootkits and similar stealth tactics, I think that this advice is just as prudent as it was back then. I don’t like using software to scan the system that it is installed upon. Apart from the fact that you can’t be sure whether there is code in memory injecting itself in to new processes, hooking Windows API calls to return clean looking data in place of viral/worm code, or other mischief which may otherwise compromise the results of the virus scan, can you even guarantee that the virus/worm hasn’t tampered with the files belonging to your anti-virus software?

I prefer, instead, to remove the hard disk of a suspect machine and scan it in a known clean system. I also examine the registry files on a known clean system (usually using reglookup under Linux, as this produces text output which can be searched using grep).

So, in the 22 years since Michelangelo, viruses/worms/malware have come a long way and are certainly a lot more sophisticated than they used to be. They can give your new phone number to your ex-partner and put anti-freeze in your fish tank (ah, remember seeing emails about that one!?). Actually, with the increasing intelligence in mobile phones, and their increasing susceptibility to malware, talk of a virus giving your new phone number to your ex-partner may not actually be as far fetched as it once was!

Something tells me that the fun is just beginning.