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.