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.

Tunneling/Patching:
        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
                pushf
                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).

Polymorphics:
        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.

ENUNS Files:
        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.