FAT32

New Problems for Anti-Virus, or Viruses?

(version 1.01)

Martin G. Overton

ChekWARE

Virus Researcher and Author of ChekMate.

Email: ChekWARE@Cavalry.com

Tel: +44 (0) 1403 241376
+44 (0) 1403 232937

51 Cook Road,
Horsham, West Sussex,
RH12 5GJ, United Kingdom.

The sudden appearance of FAT32 in service pack 2 for Windows '95 has brought some new complications for both viruses and anti-virus software. What's worse is the update is only available to OEMs to ship on new PCs. It's been dubbed Windows '96-and-a-half, as it is just a short stop from Windows '97 (now finally called Windows ’98).

What are the implications of Microsoft's latest addition to the file system format jungle?

Can the existing anti-virus software handle FAT32?

Can the existing boot and partition sector viruses infect FAT32 successfully, and without making the system unbootable or unusable?

Will file-infecting viruses be affected?

This paper aims to deflate the myths, clarify the differences and report the results of testing the above scenarios.

This paper was written for, and presented at the 1997 Virus Bulletin conference
at San Francisco,USA on October 2nd-3rd 1997.

I would welcome any suggestions for improvement, comments on this paper and it’s content.

This paper will be updated from time to time.

(Martin Overton 8th October 1997)

Introduction

Although this is intended as a technical paper, where possible full and detailed explanations will be given so that any laypersons that may be reading this (hopefully) won’t be too confused. Anyone with a reasonably technical or support background will find the main content of this paper understandable and maybe a little too basic. The virus specific information and test results will be explained as clearly as possible within limited technical parameters of virus nomenclature and related jargon.

As I began to research this paper I was astonished by the lack of testing of Windows 95 with live viruses running under 95. There are plenty of papers and reviews testing Windows 95 scanners against a test set of viruses, but not when active in memory, only as dormant, inanimate images. Only two other papers were found that tested Windows 95 with viruses allowed to go resident and infect the system, and these used a very small set of viruses for testing.

Before jumping straight into the technical results, lets set the scene, as you may not know about the service releases of Windows ’95 and what these bring to the table. So here goes, a potted history...

What is 95B and OSR 2.x?

Whenever a new operating system is released, inevitably some user somewhere finds a problem, which needs to be fixed. Rather than release a complete new version of the operating system, software providers fix errors through ‘service releases’ also known as ‘service packs’.

Service pack 1, released in January 1996 brought Windows 95 (4.00.950) up to version 95A (4.00.950a). Service pack 2 brings Windows 95 up to 95B (4.00.1111), released to OEMs in August ’96, this is not being made generally available. It cannot (legally) be used to upgrade existing machines, it can however be purchased with a new Hard Drive or Motherboard. It is mostly only being pre-installed on new PCs, although some parts of OSR2 can be downloaded from Microsoft’s web site for free. (http://www.microsoft.com)

Toshiba, Dell, Compaq and IBM are already pre-installing 95B on new PCs, many other manufacturers and resellers are planning to ship 95B on forthcoming models.

Windows 95 OSR2 is a service release (service release 2) of Windows 95. It includes all of Service Pack 1, and all of the later patches and fixes currently available on the Microsoft Web site, as well as Internet Explorer 3 and Personal Web Server. It also includes several components currently not available for download, including a new file system, FAT32. Other bugs, which were present in earlier releases of Windows 95, are fixed in OSR2. Though some users complain that other things were broken, c’est la vie!

What is FAT32?

Versions of Windows 95 older than OSR2 (95 and 95A), as well as many DOS versions, use a file system called FAT16 (or FAT12 with DOS 3.30 or earlier versions). The existence of large hard drives has led to large partition sizes, which mean large cluster sizes and wasted space.

To clarify this: Imagine a file that is 600 bytes (characters) in size. On a 1GB FAT16 partition this file would take up not 600 bytes but 16KB (16,384 characters, 1KB =1,024 Characters or ‘Bytes’), wasting over 15KB. On a 1GB FAT32 drive the same file would take up 4KB of space, wasting a lot less space. Below is a table that shows the cluster size used by different sized drives under FAT16 & FAT32.

Although by default, FAT32 will be used on drives over 512MB, it can be forced, though this is not recommended by Microsoft, to work on drives of any size less than 512MB.

To do this you can use FDISK with the /FPRMT switch to enable large disk support (FAT32) on drives smaller than 512MB. Not for non-expert users and don’t expect Microsoft to bail you out it you experience problems. There is also a way to specify the cluster size when the drive is formatted, (FORMAT /z:n) n* 512 bytes=cluster size, e.g. FORMAT C: /z:2 would format the C: drive with 1KB clusters. Be warned though, Microsoft will not support cluster sizes of less than 4KB.

FAT32 supports large drives and partitions (up to 2TB (Terabytes)) whereas FAT16 only supports up to 2GB (Gigabytes). Unfortunately FAT32 formatted drives cannot currently be read or written to by NT, DOS or OS/2 and therefore this is seen as a major headache by support staff. Some major PC manufacturers have taken the stance that installing FAT32 on their system would invalidate the warranty.

If you use FAT32 then you can no longer boot to the previous version of DOS as you could with 95A. You can use third-party boot managers, such as: OS/2 boot manager, NT boot manager, etc. As long as you don’t use FAT32 you will still be able to read and write to the Windows 95B drive from other operating systems.

Other file system improvements include: FAT mirroring, backup of critical areas (such as the DBR), relocatable root directory and dynamic resizing of FAT32 partitions.

How Do I Tell If I’ve Got 95B (OSR2.x)?

Typing ‘VER‘ at a DOS prompt inside Windows 95 produces the following version number information:

95 release version: Windows 95. [Version 4.00.950]

DOS Version: MS-DOS 7.0

95A (OSR1): Windows 95. [Version 4.00.950]

DOS Version: MS-DOS 7.0

95B (OSR2): Windows 95. [Version 4.00.1111]

DOS Version: MS-DOS 7.1

How Do I Tell If I’m Running FAT32 On My Drive(s)?

Simply double-click on the ‘My Computer’ icon on the desktop, and then right-click on the relevant drive icon and selecting ‘Properties’ will show the following dialogue box

The Type entry clearly shows that this local disk is FAT32, not FAT16 or FAT12.

If you use FDISK to create a partition of greater than 512MB and you enable large disk support, then the drive will be set to FAT32 by default.

Drives smaller than 512MB or disabling ‘large disk support’ will ensure that FAT16 is used instead.

Running FDISK on a drive larger than 512MB will display the following message if you have OSR2.x installed.

FDISK can also be used to check to see if your current drive(s) are formatted as FAT12, FAT16 or FAT32. Selecting option 4 from the menu when FDISK is run shows the following:

Why all this fuss?

It seems that Microsoft have once again caused a large amount of confusion regarding it’s new file system. We only have to look back at the confusion of the average user when HPFS and NTFS were released. Even now many users believe that viruses cannot infect under these file systems. As stated in the 1996 Virus Bulletin conference "Although Windows NT was designed as a secure operating system, this security does not include viruses"^[Jones]. This shows that with NT and NTFS that many viruses work fine, others such as macro viruses are hardly inconvenienced unless they try to use API’s or OS specific functions.

Regular lurkers in the Alt.Comp.Virus newsgroup will remember the flurry of posts and threads regarding a certain anti-virus program being criticised for not supporting FAT32. Many came to their defence, such as Vesselin Bontchev, Jimmy Kuo and the incumbent Virus Bulletin editor, Nick Fitzgerald (though at the time he was the Comp.Virus & Virus-L moderator and FAQ maintainer).

Later in this paper I will cover the ‘myths’ some of which were being offered as fact by well-intentioned participants of this newsgroup.

Myth #1?

Windows 95 is so different that viruses cannot infect it.

Of course in reality, very few people now believe this, though this appears to have been one of the common ‘urban myths’ about Windows 95 and it’s near magical protection^[Whalley]. The reason for the myth is understandable as Microsoft’s own marketroids, insisted that Windows 95 was ‘All New’.

It is perfectly clear that although Windows 95 brings some new challenges to the virus writer, many DOS viruses (including MBR and DBR viruses) work adequately under Windows 95 and FAT32. In fact macro viruses are the group of viruses least troubled and inconvenienced by FAT32. Only those that use API’s and other operating system specific calls are likely to fail.

Microsoft’s claim that Windows 95 was ‘All New’ was to say the least misleading. Bearing in mind that Microsoft tried extremely hard to support the vast majority of legacy Windows 3.x and DOS applications, and to be fair to a great extent they succeeded, but at what cost?

Windows 95 still runs on DOS, it’s DOS 7.0, but it’s still DOS with many of its legacy faults that the virus writers can use to their benefit and to your detriment.

Effects on Anti-Virus software?

Effects of Boot Sector [DBR] viruses?

Putting the Boot in

Boot sector [DBR] viruses infect the computer when an infected floppy diskette is attempted to be booted from (assuming that the CMOS boot sequence is the standard A: then C:. If it’s set to C: then A: then standard DBR (and MBR) viruses (excluding droppers) don’t stand a chance^[Overton]). The virus in the infected diskette boot sector will try to go resident and infect the DBR of the hard disk. If successful, and the virus can operate correctly on the host operating system then the virus will try to infect any diskette that is not write protected accessed in the floppy drives of the system.

FAT16 DBR Viruses vs. FAT32

It is not surprising that this group of viruses has the most profound impact on FAT32 partitions, as the Dos Boot Record has been radically changed. "The boot record on FAT32 drives is greater than 1 sector. In addition, there is a sector in the reserved area on FAT32 drives that contains values for the count of free clusters and the cluster number of the most recently allocated cluster"^[MS].

To date (July 97) no FAT32 specific DBR infectors exist. This is not to say that they won’t be created, as virus writers seem to fight to be the first to infect new operating systems or to use new techniques. I predict that we will see a FAT32 specific or FAT16/FAT32 DBR infector before the end of this year, if not sooner. It is only a matter of time after that happens before the first multi-partile virus that can infect the FAT32 DBR will be released.

Infected DBR or MBR? Confused? You Will Be!

When Windows 95 is infected by a DBR or MBR infector, and is first booted, in most cases the following dialogue box is displayed.

Fig 1

Bear in mind that this is only displayed the first time after the original infection. This dialogue box is a step in the right direction for Microsoft, as it actually mentions the word ‘Virus’. This may encourage an infected user to actually use some anti-virus software to check their system for viruses, or maybe not.

The confusing part of this story is that if the DBR is infected this message is also displayed. I would have expected Microsoft to know the difference between a DBR and an MBR, obviously this is not the case!

Many users would simply ignore this message and carry on regardless.

If you select the Yes button on this dialogue box you will see the following detailed dialogue box.

Fig 2

As you can clearly see this informs you that your system is using the MS-DOS compatibility mode for both the File System and Virtual Memory.

It also offers the following information, which the user should be more than a little curious to read, especially as it states:

‘Compatibility mode paging reduces overall system performance’

and

‘Master Boot Record modified --SEE IMPORTANT DETAILS.’

On most systems that are properly configured and not infected by one of the many MBR or DBR viruses, the following dialogue box would be shown instead.

Fig 3

This dialogue box clearly shows that 32-bit access to Virtual Memory and the File System is being used.

It has been said many times that Microsoft looks toward functionality first, security has always been the poor relation and it seems that it is almost an after thought, some of you may feel that I am understating this point.

Microsoft has been of recently talking to many of the anti-virus industries largest players to form a working party on Macro virus issues with Microsoft products. I look forward to the outcome from this undertaking. Unfortunately (for the end user) I predict any expectations will fall short, and the anti-virus industry will be required to charge to the rescue again to thwart the virus foe.

Myth #2?

DBR viruses cannot be removed from FAT32 partitions by non-FAT32 compatible anti-virus software.

Currently there are no FAT32 specific viruses, not to say that they will not be created in the future. Non-FAT32 compatible scanners appear to be unable to successfully remove the current FAT16 DBR viruses.

My findings with the DBR infectors and scanners tested for this paper appear to validate this supposed myth!. Disconcertingly, my results with genuine infections appear to be the completely opposite to some postings by notable researchers on the Alt.Comp.Virus newsgroup.

Is the truth out there?

Test Results

Swiss-Boot.A resisted all attempts to remove it by anti-virus software. It had to be manually removed using SYS C: after booting from a clean boot disk and locking the C: drive with the LOCK C: command.

FORM.A was also resistant to removal, only being successfully removed using Dr. Solomon’s Magic bullet, McAfee 3.0.3 and Vet 9.44, which are all FAT32 aware.

Although some researchers insist that DBR infectors can be removed from FAT32 drives by FAT16 compatible scanners, my tests seem to indicate the opposite. This obviously needs more investigation.

Effects of Partition Sector [MBR] viruses?

Myth #3

MBR viruses cannot be removed from FAT32 partitions by non-FAT32 compatible anti-virus software.

This, you might think after Myth#2, and you’d be excused for thinking this, would be correct. Luckily for most MBR infectors this is not the case. In testing all the MBR viruses were successfully removed, without incident. Why is this the case, when DBR viruses refused to give up without a struggle?

The simple answer is that the MBR under FAT32 is practically the same as under DOS 6.0. Therefore, currently non-FAT32 compatible scanners can (in almost all cases) safely remove MBR viruses from FAT32 drives.

Test Results

This was an interesting group of viruses, especially as all of them were unable to infect floppy disks from within the Windows 95 GUI or DOS boxes run within it. (While I was completing this paper, a new MBR infector was reported that could infect from within the Windows 95 GUI, the virus is known as Dodgy or Ravage^{[Dr. Sol]}). The greatest surprise was how badly some of the MBR viruses fared when trying to infect in ‘MS-DOS Compatibility Mode’ and/or the ‘Command Prompt Only’ boot option mode.

STOP PRESS: Dodgy has been tested and the results added to the table below. This MBR infector can infect floppy disks in all the test modes. It does this by deleting the HSFLOP.PDR file from the WINDOWS\SYSTEM\IOSUBSYS directory. This simply removes the 32-bit floppy driver support, so that next time Windows ‘95 starts, the floppy drive is accessed using standard DOS BIOS routines instead. This type of attack is not new; the Hare family of viruses used this method too. Although in the tests carried out for this paper all Hare samples tested failed to go resident and infect the MBR or any files.

One thing to bear in mind, just because an MBR infector can’t spread does not mean it is not a threat. Take Kampana as an example, even though it failed to replicate in testing, confirmed by at least one third party^[Emm] , it’s payload will almost certainly still trigger (after 400 reboots, it overwrites the hard disk with garbage, then displays its message). Others that refused to spread include: AntiCMOS.A, Jumper.A, Stoned.Standard.A and V-Sign.A.

Some of the test group offered ‘General Failure Reading Drive A:’ messages, these were: Michelangelo, ExeBug.C and Stoned.16.

Quox refused to allow Windows 95 to boot, and would only infect floppy disks entered during the ‘Diskette Read Failure’ message, which could not be bypassed.

Those that performed best, infecting on both 3 & 4, were: AntiEXE.A, Leandro, ParityBoot.B, Ripper, Sampo, Stoned.Azuza, Stoned.Angelina, W-Boot.A and Welcomb.

There were a number of MBR infectors that would only infect under condition 4, these include: Monkey.B, NYB, and Stealth_Boot.C.

All of those that successfully infected the MBR and went resident, apart from Jumper.A caused Windows 95 to report that the MBR had been changed (Fig 1), which dropped Windows 95 file and memory system mode from 32-bit (Fig 3) into MS-DOS Compatibility mode (Fig 2). Interestingly, even though the hard drive is in MS-DOS mode, the floppy driver is still running in 32 Bit mode^[CN] (that is why the floppy disks are not infected within the GUI by the viruses tested even though they infected the hard drives MBR and are resident).

Why did all of the viruses that infected the MBR and went resident except Jumper.A have Windows 95 detect the change? The answer isn’t all that mystical, simply all other tested MBR infectors hook Int 13h and Windows 95 actually monitors the Int 13h vector code for modifications (not the actual MBR or DBR) as this will affect its ability to drive the hardware directly. Not surprisingly most MBR infectors will do just that. Jumper.A on the other hand hooks not Int 13h but Int 21h instead, this means that Windows 95 can’t see the change and therefore the warning messages are not shown.

Filler.A ,Chinese-Fish and both Hare samples refused to even go resident, let alone infect the test systems MBR.

On a clean boot all was fine except as expected for Monkey.B (as it encrypts the MBR), and ExeBug.C (Invalid drive specification when accessing drive C:). Even given these errors, the viruses were still correctly and easily removed, even with non-FAT32 specific scanners.

A number of the test set hung after infecting the hard drive, instead of giving the more usual ‘Invalid system disk Replace the disk, and press any key’ or ‘Non-system disk or disk error Replace and strike any key when ready’messages. This simply needed the system to be rebooted for Windows 95 to load as normal, except for the warning messages (Fig1 and Fig3). The viruse exhibiting this phenomenen were: AntiCMOS.A, Leandro, Parity_Boot.B and Stoned.16.

The really interesting results are when these test results are compared to tests conducted by Ian Whalley^[Whalley]. All the MBR and DBR viruses he tested replicated under FAT16 [4.00.950]. The viruses he tested were: AntiCMOS, AntiEXE, Monkey.B, Form, Jumper.B, NYB, ParityBoot.B, Quandry, Sampo, Stoned.Angelina and V-Sign.

Yet in another test conducted ^[VB2], Jumper failed to infect other floppies as found in the tests carried out for this paper. On the other hand Kampana and V-Sign apparently did replicate in the same test conducted by Virus Bulletin, but failed to when tested for this paper!

But if we look closer these tests^[VB2] were done on a pre-release version of Windows 95 [4.00.347] and this may go some way to explain the anomolies found in this and other tests by Ian Whalley [4.00.950]^[Whalley] and David Emm [4.00.950]^[Emm] when compared with later versions of Windows 95 tested for this paper [4.00.1111].

As you can see the results are somewhat different. Are the different results due to FAT32 and or other changes in OSR 2.x, or something else? I feel that more testing is required to get the diffinitive answer, and unfortunately this is beyond the scope of this paper.

1 = From Explorer (My Computer A:)
2 = DOS BOX Within 95
3 = Restart in MS-DOS Compatibility Mode
4 = Restart, F8 and Command Prompt Only

Effects of File Infecting viruses?

Myth #4

You can’t boot clean from an OSR2 boot disk, the virus is still found in memory.

This rumour has been impossible to verify first hand. I contacted Virus Bulletin and spoke to Nick Fitzgerald (the editor) and he confirmed that this rumour was passed to him via trusted third parties.

The situation, in which this problem appears to occur, is where small drives or small partitions are used. It is possible that after booting from the Windows 95 rescue disk and running your anti-virus software that it may report that the virus is still in memory (even though it really isn’t (this is known as a false positive or ghost positive)). To resolve this issue simply add a CONFIG.SYS file with the following entry: BUFFERS=5, or 8.

It is further suggested to address this problem that you use a DOS 6.x boot disk to clean boot from before trying to remove an MBR infector.

STOP PRESS: After further research I managed to confirm this myth when either McAfee or Norton Anti-Virus was used after a clean boot. The tips suggested were tried and appeared not to alleviate the false alarm problem with these products. All the other scanners tested did not suffer from this false alarm problem.

Test Results

This set of viruses gave the widest range of results, not surprising really when you consider the number of different types of file infecting viruses there are.

A number of viruses that went resident completely refused to infect any files whatsoever. These include old and new viruses, such as: Tequila, Cawber, Die_Hard, both Hare samples and Ginger.

Others just produced the ‘illegal operation’ dialogue box (Fig 4), and refused to do anything more. These included: Goldbug, DarkAvenger.1800 and 2100, Neuroquilla and MacGyver.

Fig 4

A further subset produced the more drastic ‘Fatal Exception xx’ message that invariably ended up with the system either becoming extremely unstable or having to be restarted. These included: ByWay, Green Caterpillar, Tremor and Frodo.

There were a reasonable number of viruses that could survive and replicate successfully within a single DOS box. These included: Anticad.4096.Mozart, Avispa and even old favourites such as Cascade and all of the tested Jerusalem variants.

A few viruses could survive and replicate in all DOS boxes, these were: Barrotes.1303 and Three_Tunes.1784. Both these viruses infected COMMAND.COM, so this may explain why this was possible, although other viruses infected COMMAND.COM but were not viable outside the single DOS box they went resident in, these were: Barrotes.1310.A, CPW.1527, Fairz, Kaos4 and Npox.963.A.

Only one that could infect not only all target files, in all DOS boxes but also could infect DOS files executed from Explorer! This was: No_Frills.Dudley.

Comparing these results with other papers that have tested earlier versions of Windows 95 shows similar results. David Emm’s paper ^[Emm] confirms the findings here with regard to Cascade and Yankee.Doodle and Frodo, but not Tequila. The difference with Tequila may be explained by the use of FAT32 partitions in this paper compared to FAT16 in his tests. The test carried out by Ian Whalley ^[Whalley], confirms the behaviour observed with ByWay, Jerusalem, Kaos4 and Taipan.438.

It appears that the tests carried out for this paper use the largest set of viruses of the known papers written to date. In many ways I can understand why as this level of testing is rather time consuming.

Shall I Compare Thee …. to NT?

As an interesting aside, it seemed useful to compare the results above with those reported by David Aubrey-Jones in his paper on NT^[Jones].

Why, you may ask?

Well the test set of viruses used here is a superset of those used for that paper. Therefore it seems useful to do some form of comparison of how viruses behave under GUI operating systems, well some of you may think so at least, so lets begin….

DBR infectors:

It is interesting that like FAT32, NT does like seem to like DBR infectors. Both Form.A and Boot-437 stopped NT dead in its tracks.

MBR Infectors:

This set of viruses’ results under NT when compared to those reported in this paper is a little more varied. Of those that were unable to infect NTFS, only Chinese Fish also balked at FAT32 infection. The others that refused on NTFS, but did not object to FAT32 were: ExeBug.C, ParityBoot.B and V-Sign.

Those that infected NTFS fine without causing a hang were: AntiCMOS.A, NYB, Ripper, NYB and Stoned.Standard.A. All of these were perfectly able to infect and either refused to infect another host, or spread only under limited circumstances on FAT32.

Those that caused NT to fail to boot were: Kampana.A, StealthBoot.C and Monkey.B. The results on FAT32 were not as drastic as on NFTS, all infected the MBR without incident and went resident. Kampana.A refused to infect any other host, both Monkey.B and StealthBoot.C would only infect under condition 4.

File Infectors:

This set of viruses most closely matched the results of the NT tests on NTFS. Of the 44 successful file infecting viruses used in the NTFS test and in this paper, only 6 refused to infect and spread under FAT32. These were: Die-Hard, HLLC.Even_Beeper.B, Markt.1533, Predator.2448, Sayha and Tremor.

Of the 19 file infecting viruses that refused to operate on NT on NTFS, that were also used in the tests for this paper, 10 refused to work at all or produced error messages. The remaining 9 that failed under NTFS worked at least partially under FAT32. These were: BootExe.451, GreenCaterpillar.1575, Junkie, Maltese Amoeba, Natas.4744, One-half.3544, Pathogen:Smeg.0_1, SVC.3103.A and Tentacle.

It appears that the greater part of the viruses tested under NTFS and FAT32 appear to work at least reasonably, though many shoot themselves in the foot by trying to be too clever.

As stated in the 1996 Virus Bulletin opening address by Steve White "Microsoft has done more to solve the virus problem than the anti-virus industry", this I believe is still true today, although the anti-virus community have not been napping.

FAT32 has brought a new level of problems for the virus writer to overcome. The simpler viruses appear to work best, those that are trying to be clever, use excessive stealth or undocumented or unusual features seem most likely to come unstuck.

It is clear from other papers written on Windows 95 and viruses, when compared to the tests carried out for this paper, that FAT32 has caused more problems for certain classes of viruses. In some situations either causing the virus to be unable to go resident or the more annoying and potentially dangerous situation where the virus is resident, but cannot replicate although the trigger routine is still viable and potentially destructive.

The main viruses that appear to be seriously inconvenienced are the DBR infectors. These in the tests conducted give themselves away very quickly and noticeably.

Macro viruses appear to be the least affected by the appearance of FAT32, which is not surprising in that the operating system that macro viruses run within are currently Word, Excel and WordPro. A small number of these viruses may be caught out, but in the main this is likely to be the main threat to Windows 95 users, at least until FAT32 compatible DBR infectors and more 32-bit Windows 95/NT viruses appear.

Furthermore, it is clear that the anti-virus software tested for this paper, that non-FAT32 compatible scanners cannot remove DBR viruses from an infected FAT32 partition. Of course before long all anti-virus software will have to be FAT32 compatible because it is certain that some miscreant will write a FAT32 DBR infector just to prove it can be done.

The appearance of Dodgy is rather timely, although this is not a FAT32 specific virus it uses known anti-Windows ’95 32 driver attacks. Could this the forerunner to the first FAT32 compatible DBR virus?

Technical Implementation

The following information is supplied to show the changes that have taken place with the advent of FAT32. This not only covers the changes in the DBR but other interrupt routines for disk access and free space detection, amongst others. There is little discussion of the information raised here as I feel that this would be only useful to the virus authors, rather than the AV industry as they already have this information available to them and more besides.

The following are all the valid partition types and their corresponding values for use in the Part_FileSystem member of the s_partition (FAT32) structure.

Microsoft have added two new partition type markers to identify FAT32 partitions, these are 0Bh and 0Ch. Both these partition markers clearly identify the partition as FAT32.

FAT32 File System Structures

With the addition of the FAT32 file system, the BPB, DPB, and DEVICEPARAMS structures were updated to accommodate FAT32 information. Additionally, subordinate structures have been implemented to support the FAT32 file system main structures. These changes are effective for Windows OEM Service Release 2 and later.

BPB (FAT32)
BIGFATBOOTFSINFO (FAT32)
DPB (FAT32)
EA_DEVICEPARAMETERS (FAT32)
ExtGetDskFreSpcStruc (FAT32)
s_partition (FAT32)
SDPDFormatStruc (FAT32)

Note: Many data structures in this section are listed as reserved. This indicates that the user is not to assume or modify the values within these fields. They are used by the file system itself and are not available for any enhancements.

Boot Sector and Bootstrap Modifications ^[MS]

Equipment Used

Dell Optiplex GXi 500

200Mhz MMX Processor

32Mb Memory

2GB SCSI Hard discSCSI (2GB Hard Disk on Adaptec Controller)

• Drive partitioned into 2 x1GB partitions.
• Formatted to FAT32.

Windows 95 OEM OSR 2.1

116 viruses used in the tests were selected from the March 1997 edition of the ‘Wild List’ published by Joe Wells. These were chosen as they are considered to be those most likely encountered by the user-community at large.

Clean Boot Disk

Created by running FORMAT.COM from the WINDOWS\SYSTEM directory with the /S switch and then copying SYS.COM and FDISK.EXE to it.

From: bontchev@complex.is (Vesselin Bontchev)Newsgroups: alt.comp.virus
Subject: Re: McAfee VirusScan 3.0 and Fat32
Date: 11 Apr 1997 12:37:09 -0000
Organization: Frisk Software International
Message-ID: 5ilb9l$m1i@banani.complex.is
References: 3349ba7e.17705931@news.dfwmm.net
NNTP-Posting-Host: banani.complex.is
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
Lines: 62
Xref: demon alt.comp.virus:59264

David Levin (dlevin@dfwmm.net) wrote:
> "Chengi J. Kuo" <cjkuo@alumnae.caltech.edu> wrote:
>
> > 1) A Master Boot Record infection is independent of whether it's on a
> > FAT32 system or not. FAT32 is in boot sectors. If any virus infects the
> > MBR of a FAT32 machine, any present day AV can handle it.
>
> Then why in the activity log when I run your product does it say 'error
> reading boot record'. How can it clean it if it can't read it ?

The error occurs when reading the _DOS Boot Sector_ of the FAT32
partition - not when reading the MBR. The scanners have no problems
reading the MBR of a machine that has FAT32 partitions, finding viruses
in that MBR, and disinfecting them. It's the DBS that is problematic -
but, as Jimmy said, if the scanner reports a problem with that DBS, it
means that the DBS is *not* infected. If it becomes infected, the
scanner will be able to read it and disinfect it too.

> > 2) There are no present day boot sector viruses which infect a FAT32 boot
> > sector and doesn't destroy it in the process. And in so doing, it
> > converts it into a FAT16 infected boot sector. So any present day
> > infected FAT32 system will be detectable by present day AV.
>
> It's one thing to detect a virus, it is another to CLEAN it. If the
> virus converts the FAT32 boot record to a FAT16, how will McAfee CLEAN
> it ?

The scanners in general and McAfee's scanner in particular have no
problems cleaning the boot records of FAT16 partitions. Since the
infected FAT32 partition looks like a FAT16 partition to the scanner, it
will have no problems cleaning it.

> It might be able to clean it to be an uninfected FAT16 boot record,
> but it won't be able to convert it back to the original FAT32 boot
> record

Yes, it *will* be. Trust me - or try it for yourself, if you don't.
However, note that some of the existing boot sector viruses can *damage*
a FAT32 partition and make it non-bootable when infecting it. Removing
the virus won't restore the damage caused by it; you'll have to run SYS
on that partition.

> How can FAT32 McAfee users be 'safe', when if a virus attacks their
> boot sector, McAfee will not be able to CLEAN it or restore it from the
> emergency disk ?

It will be able to CLEAN it. Just as any other disinfector.

> In other words, their hard drive will probably be unusable.

It might be non-bootable, but that would be caused by the virus, not by
the disinfector.

Regards Vesselin

--
Vesselin Vladimirov Bontchev, not speaking for FRISK Software International,
Postholf 7180, IS-127, Reykjavik, Iceland producers of F-PROT.
e-mail: bontchev@complex.is, tel.: +354-561-7273, fax: +354-561-7274
PGP 2.6.2i key fingerprint: E5 FB 30 0C D4 AA AB 44 E5 F7 C3 18 EA 2B AE 4E

From: "Chengi J. Kuo" cjkuo@alumnae.caltech.edu
Newsgroups: comp.virus
Subject: Re: McAfee VirusScan 3.0 and Fat32 (WIN95)
Date: 15 Apr 1997 13:19:14 -0000
Lines: 149
Sender: news@Lehigh.EDU
Approved: virus-l@Lehigh.EDU
Message-ID: 0021.01IHR6JG5DL09FNGZC@csc.canterbury.ac.nz
NNTP-Posting-Host: fidoii.cc.lehigh.edu
X-Date: Sat, 12 Apr 1997 20:24:04 +0000 (GMT)
X-Digest: Volume 10 : Issue 63

David Levin <dlevin@dfwmm.net> writes:

>"Chengi J. Kuo" <cjkuo@alumnae.caltech.edu> wrote:

Sigh. I hated writing my first response and now I must do it again.

Mr. Levin,

It is obvious that you have not been infected on the FAT32 system
and are making assumptions.

>> 1) A Master Boot Record infection is independent of whether it's on a
>> FAT32 system or not. FAT32 is in boot sectors. If any virus infects the
>> MBR of a FAT32 machine, any present day AV can handle it.
>
>Then why in the activity log when I run your product does it say 'error
>reading boot record'. How can it clean it if it can't read it ?

Let me go back to the one point I made previously, "And in so doing, it
converts it into a FAT16 infected boot sector." (see in point 2 below)

No. It *is* clean. If it were infected, the virus would have turned it
into a FAT16 boot sector. And any present day AV would be able to handle
it. Even ones which do not claim to know about FAT32 boot sectors.

Of course, after it's restored, and the next time you reboot, it's
FAT32 and our scanner will refuse to scan it. But it will be clean!

And we will have restored it. (Not just us. Any current day product
will.) But as I noted earlier, the next version will support FAT32.

>> 2) There are no present day boot sector viruses which infect a FAT32 boot
>> sector and doesn't destroy it in the process. And in so doing, it
>> converts it into a FAT16 infected boot sector. So any present day
>> infected FAT32 system will be detectable by present day AV.
>

>It's one thing to detect a virus, it is another to CLEAN it. If the
>virus converts the FAT32 boot record to a FAT16, how will McAfee CLEAN
>it ?

Generally, it cleans by finding the original boot sector. It does this
by knowing, "I've found XYZ. XYZ relocates the original to (cylinder,
track,sector). Get it. Put it back." It matters not what the original
was. (You may now join into the debate between Mr. Bontchev and one of
his customers about the validity of this approach.)

> It might be able to clean it to be an uninfected FAT16 boot
>record, but it won't be able to convert it back to the original FAT32
>boot record since McAfee STILL does not support it (after 7+ months
>since WIN95 OSR2 came out).

This is an incorrect assumption. See above.

> The emergency disk will be no help, because
>unlike Norton, McAfee does not back up the Boot record to the emergency
>disk.

This is correct.

>> 3) What does FAT32 support mean? It means if you're up and running on
>> FAT32, you don't get the "cannot access" message. But if you get that
>> message today, you're clean!
>>
>> The fact is, the same reason why AV had to be rewritten, none of the
>> viruses understand FAT32 either.
>>
>> On the question of whether we support FAT32. Version 3.0 was supposed to.
>> But it didn't make it. But you can find FAT32 support in today's beta.
>> And it will be in 3.0.2.
>
>It is still not on your BETA site. How many more months will it take to
>support FAT32 ?

Are you looking for the DOS version or the 95 version? Only the DOS
version is available there (http://beta.mcafee.com/public/datafiles).
(And the next DOS version will be numbered 3.0.1.)

The next DOS version will be released this month. The other platforms to
follow shortly.

>> So in direct response to the suggestion that McAfee users are not safe
>> if using a FAT32 system, you are incorrect. McAfee users today are safe.
>> And furthermore, there are no boot sector viruses that correctly infect
>> a FAT32 boot sector today.
>
>How can FAT32 McAfee users be 'safe', when if a virus attacks their
>boot sector, McAfee will not be able to CLEAN it or restore it from the
>emergency disk ?

An incorrect statement. I covered that above.

> In other words, their hard drive will probably be unusable.

An incorrect assumption.

> Why is this incapability problem not stated in the
>documentation or in the 'Know Issues' section of the Read Me file ?

Since we made no claims of FAT32 compatibility, I didn't see a need to
have such a warning. Since there are no FAT32 boot sector viruses, there
is no "issue" to be "known."

Now, if we made such a claim and it was not true, that would be an issue
where I would go and berate someone.

> Why is it taking so long to support an operation/disk system that came out
>over 7 months ago ? Your competitors have.

Ah. Someone is questioning my decision making in supporting our users.
(Those were my decisions and they do represent McAfee's position on this.)
[I pulled up my other response to you. But apparently, you changed your
question from "8 months" to "7 months". No matter. It'll be 8 months
soon enough.]

We've been concentrating on macro viruses because *I* think it's
more important. In the 8 months, there hasn't been a native FAT32
boot virus.

Would you ask our "competitors" who support FAT32 how their Office97
support compares to McAfee's? Office97 was released in January. We
had betas available immediately. And we shipped late Feb. The first
Word97 virus was dicovered on a Microsoft Web site late January or
early February. Only 2 products at the time, I believe, could even claim
to be able to handle it. I think we're approaching 10 such beasts
now. I think there's 4 or 5 companies claiming to handle them.

I'm glad there are companies who feel a compunction to supply you with
FAT32 support. One such company you mentioned earlier also claimed
they could detect all Java viruses last year. My marketing people
were on me immediately. "Look," I said, "we detect all the Java
viruses there are. No changes necessary. And a year from now, it'll
still be true." (It's a year now.)

All companies I'm sure have limited resources. I have to assign my
people to where I assess the dangers will be for our customers.

But, as I said, our next version will have FAT32 support. But, I will
also tell those people who do not quickly upgrade to that version.

"Look, we detect all FAT32 viruses there are. No changes necessary.
And many months from now, it'll still be true."

Mr. Levin, unless you're not a user of Word and Excel, you will come to
realize that the time we have spent to crack OLE2 and Office97 (and
de facto, Word6 and 7 and Excel 5) will be more significant to you in
the near term as well as the long run.

Jimmy Kuo
Director, AV Research
cjkuo@mcafee.com

From: Nick FitzGerald n.fitzgerald@csc.canterbury.ac.nz
Newsgroups: comp.virus
Subject: Re: Please clarify some FAT32 issues (WIN95)
Date: 15 Apr 1997 13:19:12 -0000
Lines: 80
Sender: news@Lehigh.EDU
Approved: virus-l@Lehigh.EDU
Message-ID: 0020.01IHR6JG5DL09FNGZC@csc.canterbury.ac.nz
NNTP-Posting-Host: fidoii.cc.lehigh.edu
X-Date: Fri, 28 Mar 1997 10:10:02 +1300
X-Digest: Volume 10 : Issue 63

John Humphries <jh@sherpanet.com> wrote:

> Reading the moderator's note appended to Doug Muth's "Re: onehalf.mbr &
> win95 problem" I'm left somewhat confused. The pre-pended note says
> "...the important thing about booting clean is to do so with a non-Win95
> boot disk...": will files on a FAT32 disk be accessible when booted from
> an earlier version of DOS (e.g., DOS6.22)?

No. MS-DOS 7, build 950 (the one that reports "Windows 95. [Version
4.00.950]" in response to the VER command) and all earlier DOSes (MS and
others) do not "understand" the FAT32 file allocation system *and* could
otherwise be tripped up by other aspects of the FAT32 file system.

My recommendation when facing an MBR infection on a Windows 95 machine is
to boot with a pre-Win95 DOS diskette. This is true of "classic" Win95
and OSR2 systems (whether the latter have FAT32 drives or not). This is
because of a difference in operation between earlier DOSes and MS-DOS 7
that means very often your AV software will warn you that the virus is "in
memory" (and usually refuse to continue!) even though you really have
"booted clean". I recently learned (thanks Ilia) that this ghost positive
problem is easily averted with MS-DOS 7 by the simple expedience of
setting BUFFERS=5 in the CONFIG.SYS file on your boot floppy (for some of
the technical details look in the archives for digests around V10 #50-52--
also Jimmy Kuo addresses some of these issues in a post in this Digest).

> The post-pended note says "...with Win95 OSR2's FAT32 you may need an
> updated DOS AV s/w...": what are some examples of such software,
> especially are there any shareware versions which can freely distributed
> to people?

I'll leave it to the vendors to answer this...

However, the issues are that with FAT32 the (D)OS Boot Sector is not as
simple or rigid a structure as it has been, and a few new avenues of
infection are probably possible under FAT32. The potentially "mobile"
nature of various parts of the FAT32 file system that are accessed after
the MBR during the boot process means that (eventually) FAT32-aware AV s/w
will be necessary. However, although I referred to it as "DOS AV s/w" it
may be that such s/w will require a DOS 7 build 1111 (that which comes
with OSR2) or later to perform FAT32 disk and file I/O.

To the best of my knowledge, as I am writing this, there are no known
viruses that utilize any FAT32-specific attack methods.

> The note goes on "...deal with DBS infectors (see recent thread)...":
> searching through DejaNews about a week ago I was unable to find any
> references to DBS in their comp.virus archive - where can I find this?

There had been several posts mentioning FAT32 support and querying whether
certain products had it or not. Some of these have been posted in the
interim between John submitting his post and my response. Hopefully these
have (helped) answer the question.

> Still more "...MBR infectors should still be dealt with on FAT32 drives
> with 'old' DOS AV's..."; does this mean that we need to boot with a
> pre-FAT32 disk to check for MBR/boot sector viruses and with a FAT32
> disk to check for file infectors and macro viruses?

That will work, but was not (literally) what I meant. Had I written that
more coherently (aka "less hurriedly") I may have written "'old' DOS AV's
should still be able to deal with MBR infectors on FAT32 drives...".

FAT32-aware AVs should be able to deal with MBR, DBS and file viruses (so
long as you work around that false positive problem I mentioned earlier).

> I'm painfully aware that my understanding of these issues is sketchy at
> best, so please answer (or, at least raise) the questions that I should
> have asked about FAT32 (but didn't know enough to frame them) as well
> as the few that I managed to put into words.

Well, you certainly picked up a few too-roughly-sketched-out comments of
mine...

Hope that helps!

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
n.fitzgerald@csc.canterbury.ac.nz TEL:+64 3 364 2337, FAX:+64 3 364 2332
Virus-L/comp.virus moderator and FAQ maintainer
PGP fingerprint = 2E 7D E9 0C DE 26 24 4F 1F 43 91 B9 C4 05 C9 83