Figure 1: Performance Warning
This paper sets out to examine some of the characteristics of Windows 95 as regards the virus threat -- does the fact that it is different from DOS mean that there is no longer a problem with DOS viruses? Perhaps if you migrate your entire five-million-PC organization to Windows 95, your virus problem will disappear? In Michael Dobbs' brilliant novels of British politics, the beautifully scheming Francis Urquhart would say: 'You might think that, I couldn't possibly comment'. But I have, and I will in the text that follows.
In early January, when I was offered the chance to speak at IVPC'96, the world of Windows 95 viruses was very simple -- there weren't any. Life was straightforward then, and I had intended to speak on the subject of the similarities of Windows 95 to DOS, how the various types of DOS virus affect a Windows 95 system, and what the threats for the future might be.
Then, on January 24, I received a sample (I was far from the first to do so) of what came to be known as Boza, the first virus designed for Windows 95. A couple of hours of analysis was enough to understand 90% of the critter (and the next virus designed along the same lines should take a fraction of that) but the point was that things had changed. No longer could I reassure concerned system administrators on the phone by telling them that, although viruses designed for DOS would do quite a lot of damage on their Windows 95 systems, there were as yet no Windows 95-specific viruses. Explaining that whilst there is one such virus they should not be overly concerned takes much longer.
One of the common urban legends about Windows 95 seems to be that it is, in some way, magically 'protected' against viruses and their poor relations, Trojan horses. It is not easy to see where this belief originated, but it may well be because Microsoft has sold us Windows 95 on the promise that it is 'all new', and therefore so different from what has gone before as to make it necessary to throw out our old ideas of malware and start all over again.
In some ways, it would be nice to believe this, but imagine if you had to throw away all your favourite DOS applications, and replace them with versions for Windows 95. This would require expenditure of both money and time as you learn to use the new versions, and in the case of shareware/freeware applications (which make up a sizable amount of the software that some of us use every day), it is highly likely that Windows 95 versions will never be produced.
In order to allow legacy applications to live on, one of Microsoft's goals in designing Windows 95 must have been to make as many of them work as possible. The obvious way to do this is to make it DOS 7.0, which is what they did, and which in turn is why most DOS and Windows applications work so well. This is a good thing, at least from the point of view of viruses, which like DOS, and which can survive even in an environment which isn't the real thing.
With this in mind, I will first look at viruses which were meant for DOS, as (at least at the time of writing), these are the ones which are most likely to hit the real world user.
Viruses were chosen for testing on the basis of prevalence, using the Virus Bulletin Prevalence Table from January 1996 [2], as this is the best available guide: not to which viruses are in the wild, but to their relative prevalence. I simply worked down the list from the top, until further investigation was unnecessary. Several things became clear quickly; most importantly, the fact that very little has changed since I last looked at this issue in May 1995 [4].
However, one very significant difference is the warning which the user is given: on pre-release build 347, Windows 95 didn't complain in the slightest when you infected it. The release build is far more vociferous -- the dialog box shown in Figure 1 is displayed.
Figure 1: Performance Warning
The good thing about this particular box is that it mentions the word 'virus'. Were it simply to say 'The Master Boot Record on your computer has been modified. Would you like to see more information about this problem?', the average user would probably simply click 'No', and get on with his work. However, the fact that it says 'virus' may well encourage people to sit up, take notice, and call someone who can help.
So, the user clicks 'Yes', and is presented with Figure 2. This dialog is usually accessed via the ubiquitous Control Panel -- it is the 'System' applet. The property page displayed is 'Performance', which serves as a helpful summary of anything that might be wrong with the system. The other pages on the System dialog describe exactly the configuration of your computer and Windows 95's drivers, but for a brief overview of any problems, Performance is the page you want.
Figure 2: System Properties
As can be seen, the virus has introduced two entries in the list, both of which (as it transpires) refer to the same thing. The one the user will examine is the lowest of the two -- 'SEE IMPORTANT DETAILS' is a fairly strong inducement to investigate further. Requesting details results in the appearance of yet another window (by now the screen is more than a little confusing), this time the one shown in Figure 3, which quite rightly points out the other things which may have happened to your system, precipitating the problems that Windows 95 thinks have occurred.
Figure 3: Possible Virus Help
So, at a very basic level, Windows 95 seems to be fully au fait with the problem of boot sector viruses. But, as we will see when we look a little closer in the next section, the awareness is not very complete, and is certainly not sufficient to eliminate the problem.
There are a couple of major issues which need to be considered -- first, the fact that the initial dialog box (Figure 1) is shown on only the first boot after the computer has become infected. Whilst this is less than desirable from the point of view of a virus infection, if the perceived problem is in fact due to something else, the user does not want to be told on every boot.
Before going on to look at the next problem, it is necessary to list
the viruses used for testing. As mentioned previously, these were taken
from the Prevalence Table: Table 1 gives a brief overview of these viruses
and states whether or not Windows 95 gave the dialog box warning when the
system was infected.
| Virus Name | Infects | Intercepts Int | Windows 95 Warning Box |
|---|---|---|---|
| AntiCMOS | MBS | 13h | Yes |
| AntiEXE | MBS | 13h | Yes |
| Empire.Monkey.B | MBS | 13h | Yes |
| Form | PBS | 13h | Yes |
| Jumper.B | MBS | 21h | No |
| NYB | MBS | 13h | Yes |
| Parity.B | MBS | 13h | Yes |
| Quandary | MBS | 13h | Yes |
| Sampo | MBS | 13h | Yes |
| Stoned.Angelina | MBS | 13h | Yes |
| V-Sign | MBS | 13h | Yes |
Table 1: Viruses and their effects
The second problem is the fact that the dialog is just plain wrong. 'The Master Boot Sector of your computer has been modified,' says Windows 95, something which the author of Form would no doubt be surprised to hear, as that virus doesn't go anywhere near the MBS (Master Boot Sector), infecting instead the PBS (Partition Boot Sector). Similarly, we have the puzzling question of Jumper.B (otherwise known as Viresc, French Boot or 2KB) [12]. This virus does hit the MBS, and yet doesn't produce the dialog. Curiouser and curiouser, said Alice.
It appears that the dialog box is bluffing. However, this is entirely excusable, because attempting to describe the real problem it has detected would take much more space than allowed by a simple Windows Message Box (as I am about to illustrate). The only relevant factor that sets Jumper.B apart from the other viruses used here is that it hooks Int 21h (DOS Function Calls) to infect, where the other viruses take the more standard course of hooking Int 13h (ROM BIOS Disk Interrupt) [12].
Pure boot sector viruses use the technique of hooking Int 21h less frequently than that of hooking Int 13h: the latter takes far more effort for little obvious gain. The virus cannot hook Int 21h as soon as it is run, because DOS is not yet present, whereas Int 13h is always available, so such viruses need to devise a mechanism to avoid hooking Int 21h until DOS has started to load. This is usually done by hooking Int 1Ch (System Timer Tick -- called 18.2 times per second by the system Int 8h handler) and examining the Int 21h vector on each tick to see if it has changed, and when it does, only then hooking Int 21h -- Jumper.B uses this technique [12].
Nexiv_Der, a more recent virus, also hooks Int 21h. It does this in a slightly different way from Jumper.B -- it hooks Int 13h and monitors sectors read from the disk for the EXE file markers ('MZ' and 'ZM') [13]. As modern DOS device drivers are of EXE file structure, this monitoring allows the virus to be told when DOS is starting to install such device drivers (for example, EMM386), and only then to hook Int 21h. Once Int 21h is hooked, the virus can infect floppy disks by watching for access to the drives at the DOS level.
Thus, it seems that Windows 95 is not in fact looking to the MBS to detect this particular system anomaly: it is examining the code at the end of the Int 13h vector to determine if it can drive the disks directly -- one of the much-vaunted major enhancements of Windows 95 was that it bypasses the inefficient BIOS disk code (i.e. that accessed via Int 13h) by directly accessing the hardware (the so-called 32-bit disk access). This results in significant performance advantages, but the fact that Windows 3.1 and 3.11 were also able to do this (but it was not then the default mode of operation) is blithely overlooked by pundits. Indeed, if this special mode of disk access is turned off, Windows 95 becomes painfully slow.
There is a further level of complication here. Windows 95 does not simply examine the Int 13h vector: this would produce undesirable affects in a number of circumstances. Readers will recall that Windows 95 allows users to load DOS-mode drivers in CONFIG.SYS and AUTOEXEC.BAT, exactly as did old-style DOS (which I will refer to from now on as DOS Classic). These drivers may legitimately modify the Int 13h vector: were the system merely to examine the top of the Int 13h vector chain (i.e. the most recently hooked-in handler), it would falsely believe that something was wrong.
Particularly technical readers will recall that DOS Classic provided an interrupt function (Int 2Fh, AH=13h) to give applications access to the bottom of Int 13h chain -- usually the BIOS, though it should be noted that DOS Classic's IO.SYS installed a special handler on some systems to compensate for a bug in specific BIOSs, and if this had happened, the address of this handler would be returned instead. To allow Int 2Fh function 13h to work, IO.SYS stored the address of the bottom of the Int 13h chain at address 0070:00B4.
Windows 95's IO.SYS also appears to do this, which is unsurprising considering how similar it is to that of DOS Classic. Later in the boot process, Windows 95 uses Int 2Fh, AH=13h to examine the BIOS' disk handling code, presumably as part of its bid to determine whether or not it can drive the disk system directly.
Now consider what happens if an Int 13h-hooking virus is sitting in the MBS or PBS. IO.SYS: when it retrieves the address of the current Int 13h handler to store for later retrieval by Int 2Fh, AH=13h, it stores that of the virus' Int 13h handler (exactly what happens under DOS Classic). Later in the boot process, Windows 95 obtains this address when it calls 2Fh/13h, examines the handler at that address, and doesn't know it from Adam. The end result, as far as the user is concerned, is the dialog box.
The final point on this topic is the fact that the box does not appear when the drivers are configured not to load -- this is to be expected, as if Windows 95 is not attempting to load the 32-bit disk drivers, it will not notice that anything is wrong.
One of the most important questions regarding boot sector viruses under Windows 95 is 'Do they still work?'. The answer to not entirely cut and dried, and is probably best expressed as 'Only just'.
On a standard system, boot sector viruses will not infect floppy disks
once they are in place on the hard disk. The definition of a 'standard
system' is one on which 32-bit disk access was enabled and working before
the virus infected. Table 2 presents this information in tabular form:
| 32-bit disk access | Graphical User Interface | Infection |
|---|---|---|
| Yes | Yes | No |
| Yes | No | Yes |
| No | Yes | No |
| No | No | Yes |
Table 2: Infection conditions
Fortunately, the first situation is the one in which the vast majority of users find themselves -- in everyday life it is seldom necessary to resort to 'Command prompt Only' mode, and Windows 95 can drive most disk hardware directly. Under these circumstances, infection of diskettes does not take place. In addition, the warning is given, which does not happen in any other mode.
However, if for whatever reason it is necessary to abandon the norm, the virus can infect exactly as it did under DOS. Exactly how often this happens in real-world situations remains to be seen.
Before we move on to discussing how to remove such viruses from machines, it is necessary to consider stealth. This is a very important aspect of boot sector viruses, and to understand what happens, we will need to pry a little more into the inner workings of Windows 95. First, however, a simple description of what does happen -- both DOS and Windows 95 scanners appear to be successfully stealthed by viruses with that capability. But why? It's simple enough, contrary to what one might expect. As described above, when the virus is present, the system is forced to use the Int 13h handler rather than access the hardware directly, as it would prefer to do.
Consider first what happens when a DOS scanner is started. Windows 95 is, of course, obliged to start a new Virtual Machine (VM) for this new application -- this is, after all, the whole point of Windows 95, although the way old versions of Windows dealt with it was not all that different. To do this, Windows 95 boasts something called the VMM (Virtual Machine Manager), which has the unenviable job of pretending to DOS applications as they run that they have an entire DOS-based PC to play with, and not part of a Windows 95 machine -- a fa‡ade for the program, as it were. When a new DOS session is started, the VMM instantiates all sorts of system data and pulls together a pseudo-DOS environment which makes up the new session. One of the things instantiated is, of course, the virus' Int 13h handler. Thus, provided the scanner simply uses Int 13h function 02h (BIOS Read Sectors) to obtain sectors direct from the disk, the virus handler will see the call and be able to modify it as it wishes.
It would seem that the same is true for Windows 95 scanners -- and this is what you might expect. The system has failed to load the 32-bit drivers, thus it must use the Int 13h interface to access the disk. However one tries to read the boot sector (unless, that is, one resorts to port-level access, but that is outside the scope of this paper), the call passes through the virus and is altered. Unfortunately, this conclusion leads us directly to...
...which, simply put, is 'If the virus has enough access to calls to the disk to perform stealth, why can it not infect diskettes?'. The answer? Well, at the time of the conference, I didn't know. However, at the conference, Carey Nachenberg of Symantec was kind enough to fill me in on the reason -- it turns out that the system still uses 32-bit disk access to read and write floppy disks, but not to access the hard disk.
When we think about this, it makes sense -- the message box shown in Figure 1 mentions that it thinks you could have installed some form of low-level disk security (you also get the box if you install Secure FileSystem on a Windows 95 machine). If this is indeed the case, that does not prevent the system from directly accessing floppy diskettes, as these will not be the thing which is encrypted. Another mystery solved...
The worst has happened, your machines are infected with a boot sector virus -- so how do you clean it? As it turns out, it's simple, and exactly the same as for DOS Classic. Only the names have changed.
When you install Windows 95, one of the stages of this lengthy process is the creation of something called a 'Startup Disk'. Note that you are not forced to do this (unlike, for example, Windows NT installation, where creation of the three recovery disks is a necessity), but it is the default course of action, and it seems likely that most people will create one. Whether they still have it when they come to need it is an entirely different question...
The first thing to do if a Windows 95 machine becomes infected with a boot sector virus is to shut down, turn off the PC, insert the Startup Disk (which has, of course, been write-protected ever since it was created, right?), and boot up. You will be left in Command Prompt Only mode, but nothing from the hard disk will have been run, so the virus will not be in memory. With the same provisos as for DOS, you can then execute 'FDISK /MBR' to write the MBS, or 'SYS C:' [If your bootable partition is something other than C, use its letter here instead] to rewrite the PBS (and copy a new set of system files from the floppy to the hard disk).
A couple of things are worth noting here -- first, the MBS laid down by 'FDISK /MBR' is identical to that deposited by DOS Classic's FDISK -- at least for versions 6.20 and 6.22, which were the versions tested. Needless to say, it would not be advisable to use DOS Classic's SYS to clear up a PBS infector, as that would lead your machine to boot DOS Classic.
Second, if you have machines for which no Startup Disk is available, one may be created using the 'Add/Remove Programs' applet in Control Panel -- one of the property sheets is called 'Startup Disk'. It's worth noting that you need to have the Windows 95 CD-Rom or installation disk set handy (or accessible over the network), as the files are copied from there to the floppy.
From DOS 2.0 onwards, 8 bytes (bytes 3h to Ah -- directly after the initial JMP NOP pair) in the PBS have been reserved for something called the OEM label. On floppy disks formatted under recent versions of DOS Classic, these bytes tend to contain the string 'MSDOS5.0'. Windows 95 treats these bytes in a rather odd way.
Under Windows 95, as soon as you access a floppy disk, the system steps right in and writes its own label over these bytes. Note that the floppy does not have to be written to for this to happen -- simply accessing it is enough. The data placed over these bytes appears to be a timestamp of some description; however, the final three bytes always read 'IHC', the derivation of which should be fairly obvious from the title of this paper.
Various guesses can be made as to why Windows 95 would want to do this to floppies, including things like change detection -- so it can tell if the disk has changed in the middle of write operation and hence needs to warn the user that their file will be incomplete. Whatever the reason, it has relevance where viruses are concerned.
Some boot sector viruses use the space reserved for the OEM label to store extra code -- there is no reason why this is not possible; it's just that conventional boot sectors usually stick to the template. If a disk infected by such a virus is used in a Windows 95 machine, the code in the OEM label area will be overwritten, and the virus corrupted. On the majority of occasions, this will simply prevent the virus from working, and any machine booting from that disk will hang. However, it is far from beyond the realms of possibility that a virus will be left in a condition where it still functions perfectly well -- if this happens there may be difficulties with the scan strings which existing products use to detect such viruses if the manufacturer has chosen as part of their string the code which the virus places in the OEM label area.
However, this has not been observed and hence is purely speculative.
In spite of the fact that most viruses in the wild today are boot sector infectors, it is equally true that the majority of new viruses arriving in labs infect files. It is the latter of these two facts which led me to have a brief look at how current DOS file infecting viruses behaves under Windows 95.
The precise manner in which a virus modifies its target file is not of primary interest here -- functionality as basic as file access should cause Windows 95 few problems. Of more relevance is the manner by which the virus chooses files to infect -- is it resident? If so, how does it install itself into memory? How does it hook the interrupts it monitors? Things like this are likely to function differently in the world of the Windows 95 DOS box.
The virus chosen for this category is probably the most famous such virus of recent years -- Kaos4, which readers will recall achieved a wide distribution by dint of being attached to a pornographic animation posted to UseNet in July 1994. When an infected file is run, the virus simply attempts to infect three COM and three EXE files, for which it looks first in the current directory, then along the path.
In a DOS box under Windows 95, the virus works almost without problems. The only slight snag is the fact that the critical error 'Sharing violation reading drive C:' is usually displayed when an infected file is run -- it is my belief that this is because the virus is attempting to open the currently executing file (i.e. itself) to check if it is already infected before infecting it. My standard response of 'Fail' to this error allowed execution of the virus to continue, at which point it successfully infected other files. The same behaviour was observed when an infected DOS application was run from Explorer.
The word 'primitive' is used here to refer to viruses which send themselves resident by means of Int 21h function 31h (Terminate and Stay Resident). This interrupt represents the 'DOS-approved' method for leaving a program behind in memory and returning to the prompt, and so is likely to exhibit special behaviour under Windows 95. The virus chosen for testing in this case was Jerusalem.1808.Standard -- extremely simple and reliable, and in the wild at the time of writing.
Under Command Prompt Only mode and in a DOS box the results are the same: the virus is able to work perfectly well. Unlike Kaos4, I was not able to coax Jerusalem into betraying its presence, and it infected files without difficulty. With DOS boxes, it is important to remember that a virus resident in one box has no effect in another, as they are entirely (at least at this level) separate.
There is, however, an important point to make before we move away from Jerusalem. When an infected DOS application is run from Explorer, the result is that shown in Figure 4. Windows 95 detects the virus going resident, believes it is some form of TSR utility, and cooperatively offers the user the chance to use it before closing the window. The prompt does not actually return (indeed, it should not, as the application has in this instance been run from Explorer), so it is not possible for other programs to be infected in this way.
Figure 4: Pop-Up Support
The virus used here (because it is in the wild) was TaiPan.438 -- this virus goes resident by 'directly modifying the MCB of the current code segment' [10] -- that is to say, the virus is not using the DOS-approved technique described above for leaving an image behind in memory after the prompt returns.
As expected, this virus also works perfectly well in a Windows 95 DOS box, successfully installing itself into memory and infecting files. The difference is that when an infected program is run from Explorer, the box shown in Figure 4 is not displayed -- the goat file simply runs and exits, the DOS box closes, and that's that. An infection will only make any significant progress if the user does a lot of work in DOS boxes, which is something we will see less and less as time goes on.
Link viruses [whilst these are, strictly speaking, separate from parasitic viruses, here they do not merit a section of their own] infect files by modifying the starting cluster entry in their directory table entry to point to the virus code. The virus chosen was Byway.A (aka Dir_II.TheHndV) [11] -- again, one which is currently in the wild.
The behaviour of this virus under a DOS box in Windows 95 is fairly straightforward -- it crashes the system. It installs itself successfully into the box's memory, but fails to infect files which are run. When the user attempts to exit the DOS session, multiple exceptions are generated, which crash first the DOS session and then the whole machine (so much for a protected DOS subsystem).
However, in Command Prompt Only mode, things are different. Here, the virus actually works -- it correctly creates the placeholder file in the root directory, and cross-links executed COM files to it. However, things become strange again -- if the computer restarts in full Windows 95 mode, the machine no longer crashes as described above. Nevertheless, files are still not infected.
In the summer of '95, the virus which came to be called Concept was discovered. This was the first of what would become an ever-increasing number of Microsoft Word macro viruses -- viruses which are written in Word Basic, the programming language supplied with Word 6.0 and (as it turned out) Word 7.0, which is basically Word 6.0 with a couple of new features added and recompiled for Windows 95.
Whilst this paper is not about macro viruses, it is worth noting that one of the many things that set macro viruses apart from other types of viruses is that they work on multiple underlying operating systems. For example, Concept[which was, in January and February 1996, the virus most reported (both directly and indirectly) to Virus Bulletin [2]] works equally well on Word 6.0 for Windows (running on Windows 3.1 or Windows 95), Word 6.0 for Macintosh, and Word 7.0 running on Windows 95. Some of the other macro viruses are not so lucky -- ones which try to reach outside the Word environment (usually as the viruses attempts to perform some form of elaborate trigger) frequently come unstuck in the process.
All the information about what happens when a virus intended for DOS hits a Windows 95 machine, whilst interesting, pales into insignificance when compared with what a native virus could do. However, for the moment (as of March 1996) we are fortunate: there is just one virus, Boza, 'designed for Windows 95'.
In January 1996, the anti-virus community got its first sight of Boza. Figure 5 shows the message box, which credits the author and his friends, and is displayed by the virus when an infected file is executed on the 31st of any month [14]. The virus was written for distribution for issue six of VLAD (Virus Laboratories And Distribution), a electronically distributing virus writing zine, but a version of the virus was leaked to the anti-virus community before VLAD#6 was released.
Figure 5: Boza's Box
Boza is a very simple virus -- when an infected program is run, it infects three other programs before passing control to the host. The virus does not remain resident in memory, and will occasionally mis-infect files -- at least in the version received before VLAD#6 was released. The version in the zine (advertised as a version with the bugs fixed) does not appear to work at all.
The virus works by adding a new section to the end of a Windows 95 executable with the identifier '.vlad', altering various fields within the file header to allow for the new section, and shifting the entry point to it. It is probably fair to say that Boza is not significant for its properties as a virus, and it only achieved such a high level of interest because it is a Windows 95 virus. As such it conveys (in the form of the source code and documentation, both of which are distributed with the virus) a fairly large amount of information about the PE (Portable Executable) file format, knowledge of which is vital for those who wish to write parastic viruses for Windows 95.
Boza is not in the wild, a state of affairs which can reasonably be expected to continue.
Boza aside, how will viruses attack Windows 95 in the future? Of course, it's impossible to say, but it is possible to speculate. With papers with titles like those of [5], [8], and [9], much of the information required is already out there and easy to find, and it can only be assumed that time will bring with it more information. I intend only a brief look at some of the possible methods of attack -- as with all operating systems there are many; most of which have not yet even been imagined.
First, consider [8] -- hidden behind an exceptionally enticing title is an excellent technical paper on the problems of modifying other processes in the protected environment offered by Windows NT and Windows 95. There is far more detail there than is worth covering in this paper, but suffice it to say that it is possible, though not trivial, to fire off a thread in the address space of another process in the system -- the APIs CreateRemoteThread(), ReadProcessMemory(), and WriteProcessMemory() come in handy along the way. A system is described whereby Process A can start a thread in Process B running through an external DLL -- this in itself offers significant opportunities for malware.
However, more dangerous still is the technique mentioned briefly in [8], and again in [9]. They describe the effect of setting a certain field on a certain key in the registry -- the field/key pair in question is:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
If this field is set, then 'whenever the USER32.DLL library is mapped into a process, USER32 retrieves the saved value of this key from the Win32 subsystem and calls LoadLibrary for each of the DLLs specified in the string. As each library is loaded, the library's associated DllEntryPoint (the Win32 equivalent of LibMain) is called with a reason code of DLL_PROCESS_ATTACH so that each library can initialize itself.' [8].
What this means in English is that if this field (the default value of which is NULL) to 'C:\CRACKING.DLL', whenever an application starts, a thread will be created within the new process' address space which starts at the entry point of the DLL (this is referred to by a variety of names, including LibMain, DllMain, and DllEntryPoint, as it is a configurable option on the linker). To put it in even simpler terms, a program can be run alongside the one the user clicked on whenever they run something.
However, in spite of the fact that [9] states: 'It seems that in Windows NT and Windows 95 there's an obscure registry key value...', readers will notice that the key/field path explicity refers to Windows NT. Creating a field on the appropriate Windows 95 does not cause the DLL in question to be called, and even considerable experimentation proved fruitless. On Windows NT, however, the system works -- a small test DLL was used, and every time an application was started, the machine would display a message box. There are limitations: only 32-bit GUI applications cause the DLL to be called; DOS and console-mode applications do not. This is a possible area of concern for Windows NT, but again, that is outside the scope of this paper. A further problem is that a virus using this attack would need special behaviour to allow it to spread between computers.
There is, however, no need to look this deeply into the system to find threats. One of the things Windows 95 does for the user is separate him further from the underlying machine than did the DOS/Windows 3.1 combination.
For example, it is really much more difficult to know what will happen when you click on an icon. Sure, you might think that Microsoft Word is going to run, but there's no guarantee. It is possible to modify the shortcuts so that they point to an entirely different application, but preserve the icon of the original. Given this fact, anything is possible, though it's fair to say that the same thing was perfectly possible under Windows 3.1. Windows 95, however, provides us with many more opportunities for this type of attack.
Readers will notice that neither of the two previous Gedankenattacks require the virus to go resident in memory: I have approached the problem in this way because residency under Windows 95 is more challenging than under DOS Classic -- the dreaded letters 'VxD' (which somehow manages to be an acronym for 'Virtual Device Driver') crop up rather a lot. VxDs are sometimes described as 'the TSRs of the 90s', which seems a little unfair, as they're in fact much more powerful than TSRs ever were. At a basic level, however, the comparison is good: if a Windows 95 developer were asked 'How would I write a program which monitored for file execution and modified the executed files?', he would undoubtedly reply: 'Write a VxD' [I know this because I just asked two].
Space and time prohibit me looking at these things in any great detail, but it is worth mentioning that, although at the moment VxD writing is considered very difficult, it seems likely that it will become better understood, and hence perceived as 'easier' in time. Lack of knowledge and experience will not always be a barrier to writing this type of virus for Windows 95.
In the course of this paper, we have seen that current DOS viruses of various types definitely do not function as advertised under Windows 95, at least when it is running in the standard modes. However, there is without doubt cause for concern, as such viruses will create problems and system instabilities to varying degrees, as illustrated in sections two through four.
For the future, we have any number of possible new threats; and, as stated, most of them can not yet be known. Any and every operating system is open to some form of attack, and Windows 95 is no exception. Exactly what the future will bring is unfortunately impossible to predict, but one thing is certain -- the story of viruses and Microsoft's brand-new bouncing baby, Windows 95, is only beginning.
One computer was used for primary testing -- a Compaq ProLinea 4/66 with 24MB RAM and a 420MB hard disk. An initial install of the release version of Windows 95 was performed from CD, and then a sector level backup utility was used in combination with DOS' Interlink software to take a snapshot of the hard drive and store it on a another computer.
This allowed reinstalls to be done (which was necessary after every infection) in the minimum time possible with the equipment available -- a complete reinstall took just under 13 minutes, and the compression built into the backup software meant that an image of the whole hard disk occupied under 30MB on the other computer.
- 'Unauthorized Windows 95 Developer's Resource Kit', Andrew Schulman;
IDG Books, 1994.
- 'Virus Prevalence Table -- January 1996'; Virus Bulletin, March 1995.
- 'The Interrupt List' release 49 (11/02/96), Ralf Brown et al; available
all over the Internet [specifically, here].
- 'Viruses on Windows 95', Ian Whalley; Virus Bulletin, June 1995.
- 'The Portable Executable File Format from Top to Bottom', Randy Kath;
June 12, 1993, on the Microsoft Development Library CDs.
- 'Peering inside the PE: A Tour of the Win32 Portable Executable File
Format', Matt Pietrek; MSJ, March 1994.
- 'Understanding Windows 95 Memory Management: Paging, Address Spaces,
and Contexts', Matt Pietrek; MSJ, April 1995.
- 'Load your 32-bit DLL into Another Process's Address Space Using INJLIB',
Jeffrey Richter; MSJ, May 1994.
- 'Learn System-Level Win32 Coding Techniques by Writing an API Spy Program',
Matt Pietrek; MSJ, December 1994.
- 'Tai-Pan', Kevin Powis; Virus Bulletin, November 1995.
- 'Byway: The Return of Dir_II', Dmitry Gryaznov; Virus Bulletin, September
1995.
- 'Jumper: Jumping the Gun', Ian Whalley; Virus Bulletin, April 1995.
- 'Nexiv_Der: Tracing the Vixen', Peter Szor; Virus Bulletin, April 1996.
Dmitry Gryaznov, Personal communication; 7 February 1996.