Making Windows 95 Compatible Viruses
by
Yosha/LT

            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.