Changing Threats, Changing Solutions: A History of Viruses and Antivirus
by David Emm - Senior Technology Consultant, Kaspersky Lab UK - Thursday, 17 April 2008.
The writers of boot sector viruses had no need to implement social engineering tricks to spread their creations. On the contrary, very little user interaction was required beyond inadvertently leaving an infected floppy disk in the drive. At the time, floppy disks were the main means of transferring data from computer to computer and from user to user. So it was almost inevitable that, sooner or later, the user would pass on an infected floppy disk to a friend, colleague or customer and spread the virus.

In the years that followed the appearance of Brain, boot sector viruses were further refined and developed. Whereas Brain infected floppy disks only, most of its successors were designed to infect the hard disk also. In most cases, this meant writing code to the MBR (Master Boot Record). Some, however (notably Form), infected the boot sector of the hard disk. And a small number (e.g. Purcyst) infected both the MBR and the boot sector.

DOS file viruses

Until 1995, boot sector viruses represented around 70% of all infections found in the field. However, they weren’t the only type of virus. This period also saw the emergence of viruses designed to infect DOS executable files, first COM files, then later EXE files. These viruses modified the host file in such a way that the virus code ran automatically when the program was run. There were many different methods used to infect files.

One typical method was to add the virus code to the end of the host file and modify the header of the file so that it loads first the virus code and then the original program instructions. There were several variations on a theme, however. Some viruses inserted their code at the start of the file. A few inserted their code in several locations within the file. And some, called overwriting viruses, replaced the original code entirely: of course, the host program failed to run, so such viruses were not commonly found in the field; their presence was too obvious for them to survive for long. A few viruses chose an alternative infection method. Companion viruses stored their code in a separate ‘companion’ file. For example, the virus might rename the standard RUNME.EXE file to RUNME.EXD and create a new RUNME.EXE containing the virus code: when the user executed the program, the virus loaded first and then passed control to the original program, so the user wouldn’t see anything suspicious. Another alternative was the ‘link virus’, which spread by manipulating the ways files were accessed under the FAT file system used by DOS. The user would receive an infected file (on floppy disk, for example) and run it. The virus loaded into memory created a (typically hidden) file on the disk: this file contained the virus code. The virus would then modify the FAT to cross-link other files to the disk sector containing the virus code. As a result, whenever the infected file was run, the system would jump first to the virus code and run it.

One reason why file viruses were less common than boot sector viruses is that users didn’t often exchange programs, particularly in a business environment. They did exchange floppy disks, but typically to transfer data. That said, there were also file viruses found in the field during these early days. The most successful and fast-spreading of them were designed to go memory resident: these so-called indirect-action file viruses could monitor activity on the system and infect any file the user chose to run. By contrast, direct-action file viruses simply infected a file (or files) when the infected program was run and would then hibernate until the next time an infected file was run: such viruses were much less effective at spreading. One other factor that helped file viruses to spread was the mass distribution of infected media: on a number of occasions this happened through the distribution of infected disks on magazine covers.

Spotlight

Android Fake ID bug allows malware to impersonate trusted apps

Posted on 29 July 2014.  |  Bluebox Security researchers unearthed a critical Android vulnerability which can be used by malicious applications to impersonate specially recognized trusted apps - and get all the privileges they have - without the user being none the wiser.


Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.
  



Daily digest

Receive a daily digest of the latest security news.
  

DON'T
MISS

Tue, Jul 29th
    COPYRIGHT 1998-2014 BY HELP NET SECURITY.   // READ OUR PRIVACY POLICY // ABOUT US // ADVERTISE //