The FreeDOS FDSHIELD malware shield monitors DOS sessions and helps block dangerous activity typical of trojan horses, viruses, malware, and human error. It is not a virus scanner and does not check known virus signatures, but only monitors for known risky behavior. FdShield is designed for FreeDOS (www.freedos.org), but will also run on other DOS versions including the OS/2 DOS box. FdShield is © by Eric Auer 6/2004-3/2005. It is free open source software under GNU public license (v2, see www.gnu.org).
FdShield is not interactive and cannot be unloaded. It simply denies writes that are prohibited, and halts the DOS session if obvious virus style activity is detected. This approach prevents the user from incorrectly allowing dangerous activities and makes it harder for malware to bypass the protection.
It would be trivial for malware which knows about FdShield to disable it, but most DOS viruses are much older than FdShield. Attempts to disable shields which were 'in' 10 years ago, like VSafe, are detected by FdShield, a trap aimed especially at 'smart' malware, but the unprotected RAM means that FdShield is vulnerable to being disabled on-the-fly. And users will often be able to skip loading FdShield at all at boot time.
It might be a good idea to check disk caching setup before using FdShield.. FdShield flushes the more common caches to disk when it enters disk write protection mode. It is still possible that unwritten data gets lost when FdShield decides to halt the DOS session in reaction to malicious activity which it could not prevent beforehand. If you use delayed-write caches while disk or boot sector protection is on, DOS will fail to notice the write denial until the write-delay has elapsed, so delayed-write caches should not be used with disk write protection. Boot sectors are only written by FORMAT, SYS and similar lowlevel tools, so if such tools are not used, boot sector protection can be used even in combination with delayed-write caches. Be warned that FORMAT, FDISK and other disk tools can fail in the middle of processing when they hit boot sector protection. The same can happen with some BIOS virus protection functions.
FdShield can't prevent boot sector viruses on floppies from infecting the hard drive, so be sure to set CMOS to boot from the hard drive first. Virus protection works best if the protection is loaded before the virus. In particular, if you would boot from an infected diskette before loading FdShield, the shield would not help much anymore. There is the inconvenience of having to change CMOS when you really do need to boot from a floppy or CD-ROM drive, but a boot sector virus is far more inconvenient.
A note to OS/2 users. If you use dual boot, when you are in native DOS, hard disk boot sector protection (/B) could block the boot sector swap, although OS/2 seems to be able to bypass the protection (using non-DOS disk drivers). However, the system file write protection (/x /X) switch will block config/kernel file swap. Conclusion: Do not use "boot /os2" while FdShield /x or /X is active.
Use the FdShield command to monitor your DOS session and help
block trojan and viral activity.
Syntax:
FdShield [/v][/t][/T][/x][/X][/b][/B][/w][/W]
where:
Recommended settings:
Reminders:
Some basic protections are that FdShield halts the current session if it thinks there is an active virus. It also blocks certain file control block (FCB) based mass deletes where the extension contains wildcards.
FdShield watches for attempts to disable TBAV, VSAFE, or VWATCH, common antivirus monitors. It simulates their system interfaces and attempts to use them to disable the simulated monitor should trigger the freeze/reboot function, though this is not guaranteed.
Options /t or the more restrictive /T will help prevent trojans and other programs from going resident against your will. FdShield also watches the device chain for driver additions and modifications. However, it should be noted that DOS viruses often go resident without telling DOS about it, so they can bypass FdShield protection. If you only want to know if something stays in RAM, use /v, but that will not check the device chain. When using TSR denial, you must load all needed TSR programs before you load FdShield, as FdShield halts the DOS session when further TSRs show up. Using the lowercase /t makes exceptions for the DOS extenders RTM and CWSDPMI, which are used by many demos and games. Other DOS extenders like DOS4GW and DOS32A load as shells or libraries, not as resident programs, so they are not affected by TSR protection. If FdShield is loaded with /t, it halts the DOS session if any program except RTM or CWSDPMI goes resident against the will of the user who activated /t protection. The stricter /T option does not even allow RTM or CWSDPMI to load. Programs which can go resident and should therefore be loaded before you activate the /t or /T protection include:
If you find that you can't use /T or the more permissive /t because you trigger needed TSRs too often, at least use the /v option. That allows FdShield to at least warn you when a program goes resident. For more discussion, see the advanced issues section.
Option /v shows messages about virus-shield detection calls, attempts to sabotage anti-virus shields, programs going resident, attempts to low-level format hard drives. Also shows messages about disk or file write attempts if they are blocked by other options. Regardless of switch status, attempts to mess with virus shields, except simple detection calls, all show a message on screen. Under a native DOS, the system then halts and requires a manual reboot. Under a DOS-OS/2 box or similar environment, it simply closes the current DOS session. The /v switch modifies this, providing a 20 second delay before the session closes, and in a native DOS, it then automatically reboots. For details on interpreting FdShield messages, see the advanced issues section.
The /x or /X option should help limit the spread of viruses and the damage done by trojans and user errors. The /x option provides significant write protection for program (com, exe, and sys) files, preventing deletion, renaming, and modification while permitting some safe ways of program file creation. But many programs, for example most exe packers and compilers, use potentially overwriting ways of exe creation. FdShield blocks those accesses if system file write denial is enabled. So these programs will not be able to create exe programs. You have been warned. The /X option even denies safe (never overwriting) file creation, and adds bat files to the protected class. FdShield can decide to force file access modes to read-only instead of completely blocking the access. The access failure is delayed until programs actually try to write to the file in that case. This is needed for programs which always try to open files in read-write mode even when they only read from the file later. Warning: Long file named based access to program files is not blocked. Renaming a file to a program file (e.g. "ren temp.bin new.com) is allowed with /x protection but blocked by /X protection.
One problem with the /x and /X options is that they make the PC less fun to use and can interfere with too many programs. For example, some programs open their EXE file in read/write mode and may even modify it. This interaction is mitigated by converting the request to open in read-only mode. This allows many of these programs to run (e.g., Gasoline demo, Sint, Show 1.4). Those that actually attempt to write (e.g., Show 1.4) will have the write denied, but they may fail to notice. SHOW, for example, gets the license display wrong because of the write block.
Using only /x or /X also protects against user errors. Pilot error accounts for a lot more damage than one might expect, and if that's the main risk, these options can help protect program and system files.
Option /B helps prevent multipartite viruses from spreading to hard drive boot sectors. This only works if you load FdShield before the virus, and it does not work in OS/2 or Windows NT DOS boxes, but these operating systems claim to prevent int 13 and 26 writes to the hard drive on their own. You can also use BIOS boot sector virus protection functions. Some of them have a list of known-good operating systems, so you cannot use them while you have less widespread operating systems in use. Do not use /B option or BIOS virus protection when you want to SYS, FDISK or FORMAT your hard disk.
Option /b helps prevent boot sector viruses from spreading to floppy disks, but it will spoil the formatting of floppy disks. Solutions: Reboot without FdShield before you format. Or use deltree as a format replacement -- which only works as far the exe delete protection of /x does not spoil it, of course. This protection does not affect OS/2 or Win32 FORMAT programs, even if you start them from within a DOS box!
Options /w and /W together offer write-protection. Option /w write-protects the floppy disk and is generally harmless. However, option /W will cause writes to hard disks and to ramdisks and all other FAT drives (like ZIP drives) to fail. When used alone, this can can freak out DOS because DOS does not accept writes to non-removeable drives to fail. But if you use both /w and /W, FdShield activates a "pretend that all files are readonly" mode, which will usually prevent DOS from even trying to write to the readonly disks and thereby avoids the freakout. If you do run into a panic of this sort, it's annoying because you can't get out of the error message and have to reboot. But if you could, you couldn't save your data anyway, because your hard disk is write protected... Note that these write-protect options do not work in OS/2 and maybe also Windows NT DOX boxes.
As mentioned elsewhere, using FdShield's TSR protection can be problematic with transient resident programs. Sound card FM drivers come to mind. But a bigger issue is that many dos programs, including basically all DJGPP-compiled programs (e.g. dosfsck) as well as dos games (see sources such as www.dosgames.com) and dos demos (see sources such as www.scene.org) require DOS extenders for DOS protected mode interface (DPMI) memory support. DPMI memory is available without these extenders in DOSEMU (www.dosemu.org) and the OS/2 and Windows DOS box. But the extenders are essential in freedos (www.freedos.org). or MS-DOS. For this reason, FdShield's standard TSR protection (/t) provides loopholes for two of the more common extenders:
If DPMI support is preloaded in your environment, use the FdShield's /T (uppercase) option instead. If you don't need to allow RTM, and your DOS already provides DPMI services so CWSDPMI is not needed (common in DOS boxes), you can use /T instead of /t protection to get a bit of extra protection.
You can also preload DPMI support in FreeDOS and MS-DOS. DPMIONE is a good alternative to preloading CWSDPMI, but neither works nicely in combination with the RTM DOS extender. See Obscure hints
If you can't use FdShield's strict /T or somewhat permissive /t, you might look into using a startup menu or using the TSR utilities. A bootup menu could let you select which (if any) resident support drivers you want preloaded. You might have one option load DPMIONE, supporting CWSDPMI applications; another load RTM, supporting RTM applications; and a third loading neither, for smoother operation of DOS4GW/DOS32A applications. Sound drivers might or might not be loaded. This will complicate \autoexec.bat (or possibly \config.sys) but can work around otherwise intractable problems. Another possibility would be to look into the use of The TSR Utilities (tsrcom35.zip, tsrsrc35.zip). They permit marking memory above TSRs and can remove a chain of them at need, so you might be able to reconfigure your setup without rebooting. But that approach might reduce security. Details of either approach must be left to the reader, since everyone's needs are different.
A typical FDShield block message might read:
FDSHIELD: 0021 Attempt to replace program Registers AX BX CX DX DS: 3CD0 A947 0000 0D06 0476 Program: COMMAND at 0476 FILE: test.sys
This includes a summary of what interrupt call was halted, what function was attempted, by what program, and what the target file was, if available. It may also indicate the drive the way the interrupt does. In the above example, the high half of AX, 3C, indicates the manner of replacing the file. The class code 0021 tells that a DOS function got blocked.
Class codes are usually interrupt numbers: 13 is BIOS disk services, 16 is keyboard interface (VSAFE sabotage check uses this), 21 is DOS services, 26 is DOS lowlevel disk services, 2700 is an old method to go resident, 2F is the multiplexer (used by some of the sabotage checks), 2F13 is an interface to modify DOS disk access (used by Windows), 40 are BIOS diskette legacy services. Other values are used by other sabotage checks.
For interrupt 13 and 40, the last two digits of DX contain the physical drive number: 0, 1 for A:, B:, and 80, 81... for hard disks. For interrupt 26, the last two digits of DX are the drive letter (0 is A:, 1 is B:, 2 is C:, and so on).
Preloading a DOS extender so that you can use /T, to block even resident DOS extenders from loading after FdShield, is an interesting idea but is problematic because of the various extenders that may be needed.
FdShield was written by Eric Auer (see software list). This ridiculously long manual was drafted by Walt Gregg <walt*w-gregg.juneau.ak.us>. This page has been tested to meet web content accessibility guides 1.0 priority 1 checkpoints and to be valid HTML. However, email addresses have been deliberately munged. You'll need to correct them to send us mail.