Does NOD32 "correct" or "adjust" FAT32 BPB Total_Sector_Count?

I am the author of a freeware drive cloning utility, called Copy+. This software is explicitly designed for cloning drives from a popular PVR in the UK.

I currently have a problem open with a user, where I am seeing the FAT32 Total_Sector_Count value at offset 0x20 in the BPB being modified upwards from the expected value (as would normally be set by the PVR during formatting). It appears this change is being made by some third party software on the users PC (i.e. not by Windows). This particular user has NOD32 installed as his AV product.

The situation is thus:
The PVR partitions the entire drive, up to the maximum LBA limit, as a FAT32 Extended INT13 partition.
It then creates a FAT32 file system within that partition, but always rounds down the Total_Sector_Count value recorded in the BPB to an exact multiple of 240 x 63 = 15,120 sectors.
This means that there are almost always spare sectors at the end of the volume that could have been allocated to extra clusters in the FAT.
However when mounted on Windows the BPB Total_Sector_Count is being increased, effectively adding the extra clusters on to the end of the volume.

I realise that this process is normally safe on regular FAT32 volumes, when the BPB Sectors_per_FAT value allows for sufficient padding at the end of the FAT to map the extra clusters so created. I can also see how a virus might attempt to hide in these unavailable clusters on malformed volumes, and why a virus scanner or disk management software might attempt to make corrections.

Unfortunately the software in the PVR (over which I have no control) also uses the total number of clusters (as calculated from the Total_Sector_Count value) to determine the offset of the non-FAT32-standard video recordings. Increasing the Total_Sector_Count value therefore has a direct effect on the PVRs ability to make future recordings on any disks modified in this way.

I would therefore like to know:
Does NOD32 "correct" the BIOS Parameter Block Total_Sector_Count value?
If it is not NOD32, does anyone have any ideas what might be making the adjustment?
Is there any way of inhibiting this behavior?

Thanks in advance.

 

Well, there are several places in NOD32 that allow scanning of the boot sectors. I do not know the details of how NOD32 handles them, but it is conceivable that this could be a factor. Here are the places I would look:

AMON --> Setup --> Detection --> Scan boot sectors on --> uncheck "Access" and "Shutdown"

NOD32 --> Run NOD32 on-demand scanner --> Actions --> Boot sectors --> No action.
NOD32 --> Run NOD32 on-demand scanner --> Setup --> uncheck "Boot sectors" (probably not necessary if the above has been set to "no action")

Command line invocations of the NOD32 scanner include the flags /scanboot- and /scanmbr- if you want to exclude these from the scan.

It is nice to see developers who take such an active role in addressing their users' problems.

 

[Updated to request additional information. AG]

Hello,

I am checking with our engineers to see if there are any situations in which this would occur.

Can you tell me if the customer experiencing the problem is using v1.1.0.5 or v1.1.06 beta of Copy+ and whether or not XTVFS v1.0.0.0 is installed as well?


Regards,

Aryeh Goretsky

 

Thanks Aryeh,

Sorry, I haven't been around to check back on replies to my post.

They were using the previous 1.1.0.4 release, and didn't have the XTVFS drivers installed (I've been Beta testing them for a while, but only released them publicly the other week). Also he said that he has turned off the on-access scan. If you require a back-level copy, or images of XTVFS volumes, contact me and I can easily send you these for testing. However nothing has changed in any of my releases that would be causing this behaviour. Please note that the disk that is being adjusted is the source drive, which is opened read-only by my software.

FYI: The drivers are just a re-build of the Microsoft fastfat file system driver, but one which returns the read only volume return code on attempts to write to the drive. There's also a custom file system recogniser which installs itself before the standard windows one. It intercept mount attempts for XTVFS volumes (OEM name in the boot sector is EBSNET) and loads the modified fastfat driver, which then mounts the volume. All other FAT/FAT32 volumes are ignored, and therefore handled by the standard Windows file system recogniser and fastfat driver.

I'm not sure if the above would prevent whatever is attempting to correct the boot record? However it does stop Windows creating recycle bins and sytem volume information folders, which was the main objective.

Anyway, thanks for looking into this for me. And also thanks to alglove for his suggested configuration settings. Do not hesitate to get in touch if you require more details.