VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Making Windows 95 Compatible Viruses


[Back to index] [Comments]

Traditionally, viruses are msdos based, and as such are made for msdos. Until recently, most dos viruses worked without problems under windows 3.x in a dos box. Now, however, with the advent of windows 95, many existing viruses either crash the computer or corrupt files under it. Because a large number of potential victims use dos software without leaving windows, it is *imperative* that you do what you can to enable your virus to work without causing a disturbance. This article deals with potential compatibility problems and in most cases provides workarounds.

Note: Some of the information in the SFT section has not been completely tested due to lack of interest on my part. I try to avoid using system file tables whenever possible.

Memory Residency

Usually, no upper memory is available while in windows. If you want your virus to have a chance to spread, you should also include a routine to use other parts of memory, namely conventional memory or the HMA. This shouldn't be a problem.


You must not patch the dos kernel while in windows. This will cause some pretty spectacular hangs, including the infamous blue screen that has a particularly annoying habit of popping up while you're doing something important. Use normal interrupt hooking if windows - or any other dos multitasker for that matter - is detected. I check for the presence of DPMI, which usually indicates a multitasker is present. Most people don't use QDPMI or any other DPMI host while in plain dos, so it is a pretty good check. Don't use normal enhanced windows int 2fh checks because windows has an option to hide its presence from DOS programs that check for it in this manner.

Size/Full Stealth

Most protected mode control programs and OS's always make a habit of reflecting the interrupt back to real mode. Although this makes for a (small) performance decrease, it is good programming because it allows real mode interrupt hooks to have an effect. Windows 95 does not reflect most common interrupts back to real mode UNLESS you hook the interrupt using dos functions 35h/25h. That means to get full stealth for dos programs in windows you MUST MUST MUST MUST MUST use shitty dos function ah=25h to hook interrupts or you will cause some major file corruption!!!! In addition, you will have to hook functions 714eh/714fh for dir stealth under programs that are Long File Names aware (ie COMMAND.COM and 4DOS.COM).

Example of LFN stealth:

FindStealth:    Call AllowInt
                jc ReturnFar                    ;this should work???
                test word ptr es:[di+18h],111b
                jnz ExitStealth                 ;checks date of last modification
                sub word ptr es:[di+20h],CodeLength
                sbb word ptr es:[di+22h],0
ReturnFar:      popf
                Retf 2
Int21Handler:   cmp ax,714eh
                je FindStealth
                cmp ax,714fh
                je FindStealth

Thanks to Sep for pointing this out, although I'm not sure that he was aware of the requirement to use DOS functions for interrupt hooking.

Other LFN functions you may want to intercept include:

ax=716ch LFN open/create I'm pretty sure it doesn't use SFTs, might want to just do a complete disinfection.
ax=71a6h Get file info by handle Mask size and date/time fields
ax=71a9h Server Create/Open file Probably just disinfect file totally.

System File Tables

Although system file tables have the same format under DOS 7, apparently not all entries work the same while in a dos box. Only the entries relevant to the average full stealth virus will be discussed here.

Modification of offset 2 (open mode) within the SFT has no effect! This shouldn't be a problem for read stealth, but if a file being written to is opened write-only, you're basically screwed if you need to read from the file. The best solution I can think of is to check for files being opened write-only and changing them to read/write. This shouldn't cause too many problems. Other entries that have no effect when modified include 0dh (file time), and 0fh (file date).

Modification of some other entries has no effect unless you have hooked int 21h using function ah=25h. This includes offset 11h (file size), and offset 15h (offset within file).


Because of the large amount of time required to make the v86 -> pmode -> v86 switch, interrupts are significantly slower. Interrupts in the main loop of a poly engine can cause a delay of several seconds while the virus decrypts. If speed is a major concern to you, either don't use interrupts in your poly engine or don't put them in the main decryptor loop.


In Dos 7, many of the COM files that come with win95 will not run properly when their size is modified. Merely copying the last 7 bytes to the end of the virus and adding the virus' size to the last 2 bytes will allow them to work. For more info, see the article on DOS 7 COM files in Turmoil #1.

Boot Viruses/Multipartites

Windows warns users if the MBR has been modified. Int 13h stealth won't help you here, sorry. If this message bothers you, you can detect windows' execution and disinfect the MBR like gold-bug.

Windows will not use its 32 bit disk drivers if Int 13h has been hooked. This slows the shit out of windows.

Int 13h write access is prohibited. However, there is an easy workaround. Instead of calling Int 13h via an INT instruction, use pushf and call far. Thanks to Phoenix/CG for pointing out this rather obvious workaround.

HD port reads/writes won't work under windows. Not much you can do about it, except detect it and use int 13h instead.

Multipartite viruses that wait for an int 13h read of a sector with MZ at the start (ie an EXE header) before hooking int 21h will fail, because IO.SYS itself is an EXE under MS-DOS 7.

These are the main incompatibility problems I have come across, but they are not by any means all of them. Careful testing under multiple platforms will enable you to create a more dependable, problem-free virus.

By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka