Virus Writer Profile: Qark
Written by Jpanic.
Table of Contents:
About Qark.
VLAD Issue 1 (July 1994).
Virus: Daddy
Virus: Mummy
Virus: Sister
Virus: Brother
VLAD Issue 2 (November 1994).
Virus: VLAD Virus
Virus: Republic
Virus: BIOS Meningitis
VLAD Issue 3 (February 1995).
Virus: Hemlock
Virus: Megastealth
VLAD Issue 4 (April 1995).
Virus: Winsurfer
Virus: Goodtimes
VLAD Issue 5 (August 1995).
Virus: Horsa
Virus: Ph33r
VLAD Issue 6 (February 1996)
VIP (VLAD Infinite Polymorphy)
VSTE (VLAD Surface Tracing Engine)
Virus: Gilgamesh
Virus: Tracevir
Virus: 386
VLAD April Fools Edition (April 1996).
Virus: SySta
Virus: ASMVirus
VLAD Issue 7 (October 1996).
Virus: Goodbye
Virus: Padania
Virus: Memorial
References.
% About Qark %
Qark was an Australian virus writer and member of the virus writing group
'VLAD' (Virus Labs And Distribution). Qark seemed to be the most prolific
member of VLAD with a career spanning 1994 to 1997. Qarks published viruses
were the Incest family (Mummy, Daddy, Sister, Brother), VLAD Virus, Republic,
BIOS Meningitis, Hemlock, Megastealth, Winsurfer, Good Times (not the hoax),
Horsa, Ph33r, Gilgamesh, Tracevir, Padania, Goodbye, SySta, ASMVirus and
Win95.Memorial (co-authored with Quantum). Qark was also the author of the VIP
(VLAD Infinite Polymorphy) engine and VSTE (VLAD Surface Tunnelling Engine).
All of Qarks viruses, except Win95.Memorial, were published in VLAD magazine.
[1]
Back to top
% VLAD Issue 1 %
In July 1994, VLAD Issue 1 came out, including four viruses by Qark - namely
the 'Incest' family. All four members of this family (Mummy, Daddy, Sister,
Brother) cooperated by sharing the original INT 21h vector. If one member of
this family attempted to go memory-resident when another member was already
loaded, the already loaded member would pass the original INT 21h vector on to
the member attempting to go resident. [2]
Back to top
% Virus: Daddy %
'Daddy' was a memory resident infecter of MS-DOS .COM and .EXE files,
including command.com. Daddy's features included encryption targeted against
certain anti-virus products, deletion of anti-virus checksum databases and
directory stealth. Daddy goes memory resident by reducing the size of MCB
(Memory Control Block) of the host if this is the last MCB in the chain. Daddy
then creates its own MCB with owner field set to 0x0008 - command.com and
hooks the INT 21h vector directly. Daddy's decrypter plays a trick with the
CPU prefetch to hamper debugging, as well as F-PROT anti-virus and TBCLEAN
(generic disinfection utility included with Thunder-Byte Anti-Virus). Daddy
infects files when they are executed or opened, or when their dates or
attributes are queried. Daddy also executes it directory size stealth on
FCB findfirst/findnext calls. Daddy uses fairly standard algorithms when
infecting .COM and .EXE files, and differentiates between these two file
formats using the file extension The virus seems to only handle upper-case
extensions. Files were marked as infected by setting the time-stamp value
equal to the date-stamp Daddy additionally deletes several anti-virus checksum
databases: 'ANTI-VIR.DAT' (ThunderByte Anti-Virus), 'MSAV.CHK' (Microsoft Anti-
Virus), 'CHKLIST.CPS' (Central-Point Anti-Virus) and 'CHKLIST.MS (Microsoft
Anti-Virus). Daddy included the text strings:
[Incest Daddy]
by Qark/VLAD
[3]
Back to top
% Virus: Mummy %
'Mummy' was a memory-resident companion infecter - creating an infected .COM
file containing the virus for every targeted .EXE file. Under MS-DOS if no
file extension was specified to execute a file, .COM had priority over .EXE.
These 'infected' .COM files ran the virus, then executed the original .EXE
file. Mummy first executes the original .EXE file when run and then goes
resident by directly hooking INT 21h and calling INT 21h, AX=3100h - Terminate
and Stay Resident. Mummy is encrypted, and also uses a similar prefetch trick
to the one used by 'Daddy', in an attempt to avoid debugging, F-PROT and
Thunder-Byte Anti-Virus. Mummy uses an interesting stealth mechanism.
Companion .COM files are created with the 'hidden' attribute set. When ASCII
FindFirst is called (INT 21h AH=4Eh) Mummy removes the 'hidden' bit from the
requested attributes mask so that hidden files are not enumerated. This leads
to many anti-virus programs not seeing the companion infections. Mummy
includes the text strings:
[Mummy Incest] by VLAD of Brisbane.
Breed baby breed!
[4]
Back to top
% Virus: Sister %
'Sister' was a memory-resident encrypted infecter of MS-DOS .EXE files. Sister
used the same memory allocation method of modifying the MCB's as 'Daddy' (see
above). Like Daddy, Sister checked files by extension but only seemed to handle
upper-case extensions. Also like Mummy and Daddy, Sister played the same CPU
prefetch trick. Once resident, Sister infected files on Execute, Open, Chmod
and Rename calls. Files were marked as infected by placing a 'magic' value in
the MZ header. Sister includes the text strings:
[Incest Sister]
by VLAD - Brisbane, OZ
[5]
Back to top
% Virus: Brother %
'Brother' was a memory-resident encrypted infecter of MS-DOS .COM files,
including COMMAND.COM. Brother goes resident by reducing the size field of the
MCB of the host file if it is the last MCB and moving itself to the now
unallocated space. Once INT 21h is hooked, .COM files are infected on Execute,
Extended Open, Chmod and Rename calls. Files are marked as infected by setting
the 'seconds' field of the time-stamp to 62. Like other members of the 'Incest'
family, Brother checks for file extension but only handles upper-case Brother
also attempts to delete Central Point Anti-Virus and Microsoft Anti-Virus
checksum databases ("chklist.cps" and "chklist.ms"). [6]
Back to top
% VLAD Issue 2 %
In November 1994, VLAD Issue 2 was released. Three viruses were included by
Qark: 'VLAD Virus', 'Republic' and 'BIOS Meningitis'.
Back to top
% Virus: VLAD Virus %
'VLAD Virus' was a memory-resident, polymorphic and size-stealthing infecter
of MS-DOS .COM and .EXE files including COMMAND.COM. VLAD Virus goes memory
resident by reducing size of MCB of the host if it is last MCB in the chain,
and moves itself into the newly created space. The virus also reduces 16-bit
WORD at offset 2 of the PSP - Top Of Memory. The virus then hooks INT 21h
vector directly. VLAD Virus is mildly polymorphic and seems to named 'VIP 0.1'
(VLAD Infinite Polymorphy) by the author, Qark. VLAD Virus uses a similar CPU
prefetch trick to the one used in above mentioned viruses. VLAD Virus also has
some stealth features: on FCB and ASCII FindFirst/FindNext the virus corrects
returned size field of infected file to original file size. The virus uses an
interesting infection marker. That is, lower five bits of low order byte of
the infected files time-stamp is set to lower five bits of high order byte of
the infected files time-stamp Like other viruses by Qark, VLAD virus checks
for .COM or .EXE file extension. This virus now uses INT 21h AH=60h (MS-DOS
Get Qualified Filename), which among other things converts the filename to
upper-case Thus this virus does not infect only handle files with upper-case
extensions like some of the above mentioned viruses. VLAD Virus uses INT 2Fh
(MS-DOS Multiplex) calls to get the SFT (System File Table) entry for the
victim file. The virus uses this system structure to bypass some operating
system calls including lseek, chmod and setting/getting file date/time stamps.
Use of the SFT also allows for infecting read-only files, without modifying
the files attributes. VLAD Virus attempts to delete anti-virus checksum
databases used by Thunder-Byte, Central Point and Microsoft anti-viruses.
These database files are: 'ANTI-VIR.DAT', 'MSAV.CHK', 'CHKLIST.CPS', and
'CHKLIST.MS'. When memory-resident, VLAD Virus infects files on execute, open,
chmod and rename calls. The virus avoids infecting files beginning with
'SCAN', 'TB', 'F-PR' and 'DV.E' as these files may be self-checking. VLAD
Virus includes the text strings:
[VLAD virus]
by VLAD!
[VIP v0.01]
[7]
Back to top
% Virus: Republic %
'Republic' was a memory-resident MS-DOS .COM and .EXE encrypted stealth
infecter, including COMMAND.COM. Republic shared many features in common with
the above mentioned 'VLAD Virus'. The infection schemes, memory-residence, CPU
prefetch trick, use of SFT entries and infection marker are all near
identical The viruses both use INT 21h AH=60h to create an upper-case full
pathname for the victim and share the same FCB/ASCII FindFirst/FindNext size
stealth. The encryption of Republic seems to be mainly aimed at evading TBSCAN
(Thunder-Byte Anti-Virus). The virus implements a 'stealth' scheme: Files are
disinfected on 'open' calls and infected on 'close', chmod, exec and rename.
Republic includes the text strings:
Go the Republic! Fuck off Royal Family!
Qark/VLAD of the Republic of Australia
[8]
Back to top
% Virus: BIOS Meningitis %
'BIOS Meningitis' was a floppy boot-sector, hard drive MBR and Flash BIOS
stealth infecter. This virus seems to be the first Flash BIOS infecter but
according to the source code this feature was never tested. When loading from
an infected floppy or hard disk the virus goes memory resident - allocating 1k
of memory by by decreasing the 16-bit WORD at 40h:13h (BIOS Data Area, size of
conventional memory in kilobytes) and hooking INT 13h (BIOS Disk Services)
directly in the IVT (interrupt vector table). The INT 13h handler carries out
both infection and stealth routines. If an attempt is made to read sector 1,
cylinder 0, head 0 (the first physical sector - MBR or boot sector) action is
taken. If the disk is uninfected the disk is infected, if the disk is already
infected stealth takes place. The stealth algorithm simply reads in the
original sector instead of the infected one, making the disk appear 'clean'
when the virus is ready in memory. When infecting the hard drive, the original
MBR sector is stored in physical sector 2 which is normally unused in an
MS-DOS installation. In the case of floppy disks, sector 14, cylinder 0, head
1 is used - this is the last directory of the root directory on 5.25 inch
1.2mb floppies, but will cause corruption on any other type of floppy disk.
The virus overwrites the partition table of the infected MBR meaning that
booting from an uninfected floppy or running a 'FDISK /mbr' will leave the
hard drive inaccessible When infecting the Flash BIOS, BIOS Meningitis uses
various INT 16h AH=E0h (BIOS Flash routines) calls to manipulate the Flash
memory. The virus first searches the ROM BIOS from segments 0F000h to 0FFF0h
for a 1kb cave of 0 bytes. If such cave is found the virus copies itself to
this space, and patches first 5 bytes of the original INT 19h (BIOS Boot Strap
Loader) handler with a JMP FAR (EAh ssss:oooo) pointing to its own INT 19h
routine. The viruses INT 19h copies the virus to 0000:7C00h (standard boot
sector load address), emulates an infected MBR execution and then does the job
of a standard INT 19h handler - boot from floppy or hard drive. The INT 19h
handler of BIOS Meningitis is very minimal and may not behave in the same
manner as the original BIOS INT 19h handler. The virus may also overwrite the
chipset when infecting the Flash BIOS leading to unpredictable results. BIOS
Meningitis includes the text string:
VLAD
[9]
Back to top
% VLAD Issue 3 %
In February 1995 VLAD Issue 3 came out. Two viruses were included by Qark:
'Hemlock' and 'Megastealth'. In the source code to Hemlock, Qark states:
"Hemlock is the poison that killed Socrates and the way I figure it, what's
good for one Greek philosopher is good enough for another."
This seems to be a reference to 'Aristotle', the VX BBS sysop who turned over
the personal details of at least one North American virus writer to authorities
Back to top
% Virus: Hemlock %
'Hemlock' was a polymorphic, full stealth and multipartite infecter of the
MBR, floppy boot sectors and MS-DOS .COM, .EXE and .SYS files. When loading
from an infected boot sector or MBR, the virus takes several actions. First
the virus sets up its own stack. Next the virus allocated 8 kilobytes of
memory by reducing the 16-bit WORD at 40h:13h (this is the amount of
conventional memory available to the machine according to the BIOS). Hemlock
then attempts to read the 7 sectors containing the virus code to this newly
allocated memory - the virus will go into an (infinite) loop until this read
succeeds. Upon reading the virus, 3 variables are reset related to the hooking
of INT 21h later on and INT 13h (BIOS Disk Services) and INT 09h (Keyboard IRQ
Handler) are hooked directly in the IVT (Interrupt Vector Table). The entire
IVT (Interrupt Vector Table) and the original video mode are also saved. This
is done in an attempt to survive a warm reboot: When CTRL+ALT+DEL is pressed
Hemlock restores the original video mode and IVT, makes sure the machine is
not in protected mode and then issues an INT 19h (BIOS Boot Strap Loader). The
INT 13h hook provides 3 functions - boot sector infection, boot sector/MBR
stealth and hooking INT 21h when MS-DOS is loaded. When attempting to read
physical sector 1 of a disk (boot sector/MBR) if the disk is infected stealth
action is taken, if the disk is uninfected the disk is infected. The boot
sector/MBR stealth mechanism simply redirects reading of the infected boot
sector to the sector containing the original uninfected sector. When infecting
disks the original boot sector/MBR is replaced with the virus boot loader that
takes action as described above. In the case of MBR (hard drive) infection,
the original MBR and virus body are saved in the 8 sectors starting from
physical sector 3 - this space should be unused on a machine running MS-DOS.
When infecting a floppy disk boot sector the virus takes some strange actions:
the virus calculates and allocates the last cylinder of the floppy using the
BPB (BIOS Parameter Block). The virus body is saved to the last cylinder of
the diskette but the original boot sector is placed at sector 14, cylinder 0,
head 1. This leads to the same problem as the afore mentioned 'BIOS
Meningitis' - floppy types other than 5.25 inch 1.2mb may be corrupted. On
infecting the MBR the virus attempts to bypass anti-virus software by using
'tunnelled' INT 13h and INT 15h vectors. The virus attempts to retrieve the
original INT 15h address by checking a hard-coded value in the ROM BIOS:
F000h:F859h. The virus searches segment F000h as well for 5-byte signature of
most AMI-BIOS's INT 13h handler. The INT 13h handler is additionally used to
hook INT 21h when MS-DOS is loaded when boot from an infected disk - four
conditions are used to decide when to hook INT 21h. The first condition to
hook INT 21h is if any write attempt is made to disk. The second is if INT 13h
is called with Hemlocks residency check - this will always come from a file
since infected sectors are not re-executed due to the INT 13h stealth
mechanism. The third is if AUTOEXEC.BAT seems to be read - the virus checks
for the read of a sector starting with '@EC' (case insensitive). The fourth
method to check for MS-DOS loading is the read of the first MZ header - or the
tenth if QEMM (Quarterdeck Expanded Memory Manager) is found to be present.
When infecting .SYS, .COM and .EXE files the virus checks the extension (case
insensitive) but differentiates .COM and .EXE files by checking for MZ marker.
When run from an infected .SYS checks if the virus is already resident and if
the MBR is is already infected and hits the MBR if not. The tunnelled INT 13h
and INT 15h vectors are used as described above. Hemlock does not go memory
resident from infected .SYS files. When run from an infected .COM or .EXE file
Hemlock performs the same actions as with .SYS files and then installs itself
memory resident. The virus allocates memory by ensuring the MCB (Memory
Control Block) of the host file is the last block in the chain and then
reduces its size by the amount required and adjusts the PSP 'top of memory'
field (offset 02h). The virus copies itself to this newly allocated space and
hooks INT 21h and INT 13h directly. The virus then returns to the host. When
infecting .EXE files Hemlock adjusts the 'maxmen' field of the MZ header to
avoid some anti-virus programs self-check (specifically Thunder-Byte). Apart
from this, .SYS, .COM and .EXE files are infected in a standard manner.
The virus increases the date-stamp of infected files by 100 years as an
infection marker. Hemlocks INT 21h handler is used both for file infection and
stealth. On open, execute, chmod and rename calls files are infected. On
'open' calls special 'stealth' action is taken too: Hemlock retrieves the SFT
(System File Table) entry for the infected file and reduces the file length
field to the uninfected size to stop programs reading past the original end
of file and into the virus body. On 'execute' calls special action is taken
too. If the program to be executed is a known archiver (PKZIP, ARJ or LHA)
stealth is disabled to allow the virus to spread - infecting files to be added
to the archive. The same action is taken in the case of disk checking programs
(CHKDSK, NDD, SCANDISK) - this is done to stop these programs reporting file
system corruption because space allocated on disk does not correspond to the
'stealthed' length of the file. When 'TBSCAN' is run Hemlock appends "co nm"
to the command line. This stops TBSCAN from scanning memory and detecting
the virus. When WIN is run (MS-Windows) Hemlock appends "/d:f" to the command
line. This disables 32-bit disk access, allowing Hemlocks INT 13h handler to
stay active. On 'read' calls Hemlock checks if the read attempt is in the first
24 byes of the file and is it is redirects the read to the original file
header making the file appear uninfected. On FCB/ASCII FindFirst/FindNext
calls Hemlock implements 'size stealth' substituting the infected length of the
file with the uninfected length and also hides the viruses date-stamp marker.
On an attempt to retrieve the date-stamp of an infected file, the date-stamp
marker is also removed. Hemlock attempts to disable anti-virus and other
software from single-step tunnelling through its INT 21h and INT 13h handlers
by disabling the Trace Flag. Hemlock is polymorphic in all file infections.
Hemlock includes the text string:
Hemlock by [qark/VLAD]
[10]
Back to top
% Virus: Megastealth %
'Megastealth' was a memory resident stealth multipartite infecter of MS-DOS
.COM files, floppy boot sectors and the MBR. The main feature of this virus
was 'hardware' level stealth. When loading from an infected sector
'Megastealth' sets up the stack and then allocates 2 kilobytes of memory.
Like 'Hemlock' and 'BIOS Meningitis' memory is allocated by reducing the
16-bit value at 40h:13h (amount of conventional memory installed) by 2.
Megastealth then reads in two sectors containing the virus body and hooks
INT 13h, clears a flag to mark if INT 21h has been hooked and if the virus
is a 80286+ (AT) hooks INT 76h (IDE Controller IRQ). Megastealth the issues an
INT 19h (BIOS Bootstrap Loader) to continue with the boot process. The INT 76h
handler is used to implement stealth of the MBR at the hardware level. When
the IRQ occurs, Megastealth checks if it is a read from physical sector 1
(the MBR) by querying values of the IDE Controller (ports 1F0h - 1F7h). If it
is a read of the MBR, Megastealth reads in data of original read attempt from
the IDE data port and then sends values and command to the IDE controller to
read in physical sector 4 (the original uninfected MBR). This algorithm means
that even when using the original ROM BIOS INT 13h handler, the MBR is
stealthed while INT 76h handler is in place. Megastealth disables the INT 76h
handler while infecting a disk. Megastealths INT 13h handler serves three
purposes: to infect boot sectors, to stealth boot sectors and to hook INT 21h
when booting from an infected disk. The INT 13h handler function is very
similar to that of 'Hemlock' (see above). When reading the boot sector/MBR of
a disk, if the disk is infected, the read is stealthed. If the disk is not
infected the disk is infected. Megastealth shares the same peculiarity with
'Hemlock': the track to store the virus body on when infected is calculated
using the BIOS Parameter Block, but the last sector of the root directory used
to store the original uninfected sector is hard-coded, leading to corruption
of all floppies other than 5.25 in 1.2mb ones. Megastealths INT 13h hooks
INT 21h on loading from an infected disk when the first 'MZ' header is read
in. When executed from an infected .COM file, Megastealth first checks if it
is already present in memory and goes resident if not. Memory is allocated in
the same manner as 'Hemlock': if the host MCB is the last in the chain, it and
the 'Top Of Memory' field of the host PSP (Program Segment Prefix) are reduced
in size, and the virus copies itself to the newly created space. Megastealth
then hooks INT 13h, issues a read of the MBR (to infect MBR by INT 13h
handler) and then hooks INT 21h. After this Megastealth restores and returns
control to the host. INT 76h is not hooked when loading from an infected .COM
file. The INT 21h handler is used primarily for one purpose: infecting .COM
files. .COM files are infected on open, execute, chmod and rename calls. The
INT 21h handler also seems to have a debugging feature: on each INT 21h call
the handler displays a '"' (double quote) character in the corner of the
screen if the VGA controller is in a text mode. Megastealth includes the text
string:
[MegaStealth] by qark/VLAD
[11]
Back to top
% VLAD Issue 4 %
VLAD Issue 4 was released in April 1995. Two virus by Qark were included:
Winsurfer (co-authored with Quantum of VLAD) and Good Times. "Good Times" was
named after the "Good Times" email virus hoax, perhaps in an effort to create
some publicity.
Back to top
% Virus: Winsurfer %
'Winsurfer' was a memory-resident win16 infecter of NE (NewEXE - Win16
executables). Winsurfer was written by both Qark and Quantum of VLAD.
According to the source code the Interrupt Service Routine (ISR) was written
by Quantum with the infection code written by Qark. Additionally the source
code mentions some situation in which the NE infection may fail. Although a
win16 virus, Winsurfer used a mix of INT 21h (MS-DOS API), INT 2Fh (MS-DOS
Multiplex) and INT 31h (DPMI - DOS Protected Mode Interface calls). INT 2Fh is
called only once to determine if DPMI/INT 31h is present. INT 21h is called
for file I/O such as open/read/lseek/write/close. INT 31h is used to change
segment protection and to hook INT 21h globally The INT 21h handler serves two
purposes: to provide the viruses residency check and to find NE files to
infect. 'NE' files are infected on INT 21h/AX=4B00h - Execute. Under all
infections Winsurfer calls INT 2Fh to check if DPMI is present, INT 31h to
make its code segment writeable and INT 21h to check if the virus is already
resident in memory. When run from a regular NE executable Winsurfer attempts
a direct-action infection of the Win16 shell (usually Program Manger). This
executable is targeted because it can be relied on as being resident at all
times for the virus to stay resident. The shell is located in three steps:
First the 'windir' environment variable is found. The virus locates this in
the environment segment given by the PSP (Program Segment Prefix) of the host
at offset 2Ch. Next the virus attempts to open an read 'system.ini' in the
Windows directory. Finally the virus attempts to locate the shell by searching
system.ini for the 'shell=' key. When run from the windows shell the virus
goes resident in memory: The virus needs to take no special action to allocate
memory as it stays loaded with the windows shell. INT 31h is used to retrieve
the current real mode INT 21h vector and then set it to the Winsurfers own
INT 21h handler. Winsurfer introduce the 'VLAD' method of infecting NE
executables. This method basically worked by moving the NE header back 8 bytes
making space to add an extra 8 byte entry to the 'Segment Table'. The virus is
appended to the end of the file and the extra Segment Table entry points to
this appended code. Winsurfer first checks the MZ header of the file: Is the
'MZ' marker there? Is the 'Offset of First Relocation Item' (MZ header offset
+18h) 40h or more? (This is a sign of a NE). Is the pointer to the NE header
at offset +3Ch of the MZ header exactly 400h? The victim is deemed to be a
NewEXE file, but no test of the NE header is performed before infection
starts. This could lead to corruption of other types of executables such as
PE, LE, LX etc. The first immediately reduces the pointer to the NE header
at absolute offset +3Ch and the MZ header SP field by 8. Next Winsurfer reads
512 of the NE header from hard coded absolute offset of +400h. The virus reads
the Segment table offset (NE +22h) and adjust several values of the NE header
by 8 if they occur after the start of this table. Values adjusted are: offset
to 'Entry Table' (NE +04h), offset to 'Relocation Table' (NE +24h), offset to
'Resident Names Table (NE +26h), offset to 'Module Reference Table' (NE +28h)
and offset to 'Imported Names Table' (NE +2Ah). Winsurfer reads then
increments the 'Segment Count' field (NE +1Ch) making the assumption there are
less than 256 segments. Winsurfer saves the original CS:IP combination for use
in its single relocation item and then sets CS:IP entry point in the NE header
to future segment index and offset of the appended virus. Winsurfer uses the
'Segment Count' and 'Segment Table Offset' (NE +22h) to calculate the end of
the new Segment Table and move all of the NE header before this location back
8 bytes in 512 byte chunks. Winsurfer uses the 'File Alignment Shift' value
(NE +32h) to calculate the new position of the appended virus and creates a
new Segment Table entry to contain the appended virus code. The new Segment
Table entry has physical and memory size set to the size of the virus, file
offset pointing to appended virus code and adjusted by File Alignment Shift
value and Segment Attributes: 'NonMovable+Relocations'. Winsurfer then writes
the new Segment Table back to the NE header on disk. Winsurfer appends the
virus to the end of the file at the position previously calculated and then
appends a single relocation item for the virus segment after that. The
relocation item is of type '3' (PTR) and flags value 'additive'. Infection of
the NewEXE victim is then complete. [12]
Back to top
% Virus: Good Times %
'Good Times' was a polymorphic memory-resident infecter of MS-DOS .COM and
.EXE files. The source code of Good Times includes a small portion of the
'Good Times' hoax email. Good Times obtains its polymorphic ability by using
the 'RHICE' polymorphic engine by Rhincewind, another member of VLAD. Good
Times used some anti-heuristic structures to avoid heuristic detection. Good
Times used fairly standard methods of infecting .COM and .EXE files, with one
exception: When infecting .COM files the virus would follow and JMP NEAR
(E9h), JMP SHORT (EBh) and CALL (E8h) instructions in an attempt to place the
jump to the virus further inside the file. Only these 3 instructions were
followed. When infecting .EXE files Good Times would avoid overlay files, .EXE
files whos 'maxmem' field was not 0FFFFh and Windows executables. .EXE files
were marked as infected by setting offset 12h (checksum value) of the MZ
header to 'BV' (VB). This caused the virus to avoid infecting files that had
been generically disinfected by the 'Virus Buster' anti-virus. When an
infected executable is run the Good Times checks if it is already resident in
memory, goes memory-resident if not and then returns control to the host. To
allocate memory Goodtimes uses Qarks standard method by reducing the size of
the MCB of the host if it is the last in the chain, as well as the 'top of
memory' field of the host PSP. The virus copies itself to this allocated block
of memory and hooks INT 21h. Good Times INT 21h handler handles the viruses
residency check and infect files on open, execute, rename and chmod calls.
Only files with extensions beginning with 'c', 'C', 'e' or 'E' are infected.
Good Times differentiates between .COM and .EXE files by checking for presence
of MZ header. Good Times included the text string:
Good Times by Qark/VLAD
[13]
Back to top
% VLAD Issue 5 %
VLAD Issue 5 was released in August 1995 and feature two more viruses by Qark:
'Horsa' and 'Ph33r'.
Back to top
% Virus: Horsa %
'Horsa' was a direct-action infecter of the firs uninfected MS-DOS .COM file
in the current directory. What made Horsa was unusual was the use of direct
sector reads and writes (INT 25h/INT 26h) when working with files and
directories instead of using the usual INT 21h calls. This allowed it to
bypass many anti-virus programs. When an infected .COM file was run Horsa
restored the first 3 bytes of the host program, saved the DS register and then
realigned CS:IP so that the virus was realigned to cs:0. This avoided the uses
of delta offset operations through out the virus and also meant that Horsa
be aligned on a paragraph (16-byte) boundary when appended to a victim .COM
file. Once realigned Horsa sets the DTA (Disk Transfer Area) to the heap of
the virus and used an INT 21h AH=4Eh/AH=4Fh (ASCII FindFirst/FindNext) to
find the first uninfected .COM file. Horsa marked files as infected by
setting the low byte of the victims time-stamp so that the low 5-bits were
10h. After this FindFirst/FindNext loop, only INT 25h (logical sector read)
and INT 26h (logical sector write) are used to manipulate files and
directories. Horsa uses the ASCII FindFirst/Next entry to obtain the drive,
first cluster and cluster count of the victim file. Next Horsa obtains the DPB
(Disk Parameter Block) of the drive using INT 21h AH=32h. This provides Horsa
with all the information it needs on the logical drive. Horsa determines
whether the drive is FAT12 or FAT16 by looking at the total number of clusters
of the drive: If there are 0FF8h or more clusters the drive is FAT16,
otherwise it is FAT12. Horsa obtains the cluster containing the directory
entry for the victim file. That is used to update the victims size and mark
the time-stamp as infected. A special case routine is used if the victim is in
the root directory. Horsa reads the first cluster of the victim and stores the
first 3 bytes in the virus body. Horsa appends the virus to the end of the
.COM file (on a 16-byte boundary) allocating clusters and updating the FAT
(File Allocation Table) as needed. Horsa then patches the first three bytes
of the file with a JMP to the appended virus and re-writes the first cluster.
On exiting Horsa flushes the MS-DOS buffers (INT 21h AH=0Dh), restores the
original address of the DTA, restores the segment registers to their original
values and returns control to the host. Horsa has some short comings as noted
by Qark in the virus source code. Firstly, Horsa does not handle the case when
a FAT12 entry spans 2 sectors so 1 in 256 infections on a FAT12 drive will
fail. Secondly, no buffering is used. This can make infection quite slow
especially on floppy disks. Lastly, infecting only the first uninfected .COM
file causes the virus to propagate quite slowly. [14]
Back to top
% Virus: Ph33r %
'Ph33r' was a memory-resident MS-DOS/Win16 infecter of MS-DOS .COM and .EXE
files, and Win16 NE (NewEXE) files. Ph33r was the first cross-platform
infecter running under both MS-DOS and Windows. MS-DOS .COM and .EXE files are
infected in the standard manner, Win16 NE executables are infected using the
same infection scheme as 'Winsurfer' described above. Like 'Winsurfer', Ph33r
uses a mix of INT 21h (MS-DOS API) and INT 31h (DOS Protected Mode Interface)
calls. When run from a MS-DOS .COM or .EXE file Ph33r goes memory-resident in
the standard way: If host MCB is the last in the chain then the size of the
MCB and 'top of memory' field in the host PSP are reduced to allocate memory,
and INT 21h is hooked directly. When run from an infected Win16 file, Ph33r
uses a different method of residency: Rather than direct-action infection of
the windows shell to stay resident, INT 31h calls are used. Ph33r uses INT 31h
to allocated a block of linear memory, align a selector to it, and set its size
and protection attributes. This means that Ph33r can go resident off any
infected file. INT 31h calls are then also used to hook INT 21h. When run from
an MS-DOS .COM or .EXE, Ph33r takes two unusual actions. First a call is made
to INT 16h to disable MSAV (Microsoft Anti-Virus). Secondly the virus attempts
to find the original INT 21h vector by taking advantage of internal MS-DOS
structures: Ph33r gets the MS-DOS data segment by retrieving the "List of
Lists" (INT 21h AH=52h). The virus then checks for a "NOP, NOP, CALL NEAR"
sequence (90h, 90h, E8h) at offset 109Eh of the MS-DOS data segment. If these
are found the virus assumes the INT 21h vector to be at offset 10A0h of the
same segment. This is a check for the A20 line enable code when MS-DOS is
loaded in "high memory". However the hard-coded values mean it may only work
with certain versions of MS-DOS. The infection code used INT 21h file I/O
calls and is shared by both the MS-DOS and Win16 INT 21h handler - this
reduces the size of the virus. Ph33r still however uses a different INT 21h
handler under MS-DOS and Win16. The two INT 21h handlers only have a small
difference: The Win16 handler does not infect on INT 21h AH=6Ch (extended
open), as this is generally not called under windows. The MS-DOS handler does
not infect on INT 21h AH=3Dh (open) as Qark notes that this causes Windows to
crash on loading. Other than this, both INT 21h handlers handle Ph33rs
residency checks and infect on open (either 3Dh or 6Ch), execute, rename and
chmod. Ph33r checks the extension of the victim file and only infects if it is
.CO? (.COM), .EX? (.EXE) or .DL? (.DLL). The virus still examines MZ and NE
headers to decide inner format of the victim file. Ph33r does not infect files
with names ending in 'AN' (*SCAN, *CLEAN), 'AV' (*AV), 'DV' (DV.EXE, DV.COM)
and 'OT' (F-PROT). This is to avoid self-checking anti-virus files. Ph33r
also does not infect files ending in '86' (Win386/Win286.EXE - part of the
Win16 kernel) as this causes windows to crash. All these checks are not case
sensitive. Ph33r includes the text strings:
=Ph33r=
Qark/VLAD
[15]
Back to top
% VLAD Issue 6 %
In February 1996 VLAD Issue 6 was released with 5 contributions by Qark: 2
engines were included - VIP (VLAD Infinite Polymorphy) and VSTE (VLAD Surface
Tracing Engine). Qark also published 3 viruses in this issue: 'Gilgamesh',
'Tracevir' and '386 Virus'.
Back to top
% VIP - VLAD Infinite Polymorphy %
'VIP' (VLAD Infinite Polymorphy) 1.0 was a 16-bit stand-alone polymorphic
engine written by Qark, and was used in his 'Gilgamesh' virus (discussed
below). VIP 1.0 was a 'slow-polymorphic' engine, initialising its random
number generator with the current days date and a 16-bit word from the ROM
BIOS. This made it more difficult for the anti-virus companies to create
large sets of samples to test their scanners. VIP 1.0 used four standard
loop types: 'Standard' which was a classic decrypter loop, 'Call 1' in which
the decrypter recursively called itself each iteration, 'Call 2' in which the
decrypter called the loop after setting up registers and 'Stack' which set SP
to the end of the virus, popped it, decrypted it and pushed it back. The
'Stack' methods were less flexible then other methods: the pointer register
was always 'SP', the decryption operation was always an 'XOR' with no change
made to the decryption key register. Beside 'Stack' method, other decrypter
types used random registers: one or two pointer registers depending on
addressing mode chosen, and a random key register. Besides 'Stack' methods
other decrypter types any addressing modes (besides 06h immediate) were used:
[bx+si], [bx+di], [bp+si], [bp+di], [bx], [bp], [si] and [di]. In the case of
dual register addressing modes both registers were initialised, but only the
first register was incremented/decremented and compared for the loop. The loop
method was always a compare of the pointer register with the offset of the
last word to be decrypted. The loop branch could be a 'JNZ' or a 'JB'. Apart
from 'Stack' method encryption was always an XOR/ADD/SUB of the word pointed
to with the key register and then and XOR/ADD/SUB of the key register with an
immediate constant. The 'Stack' method was only used in .COM infections, the
other 3 methods were used in both .COM and .EXE infections. Apart from the
'Stack' method, decryption was always forward and on 16-bit words. Qark took
some care to avoid heuristic detection of the decrypter loops: VIP 1.0 always
used correct encoding, for example in instructions addressing AX or AL. Certain
junk instructions were not emitted for the first 'n' bytes, for example no
INC/DEC instructions were emitted in the first 15 bytes of the decrypter. Junk
instructions created included: INC/DEC reg16, ADD/OR/AND/ADC/SBB/SUB/XOR/CMP
<reg8/reg16> mem/immediate, MOV reg8/re16 immediate, XCHG reg8/16 reg8/16.
According to the source code, Qark says VIP 1.0 decrypters in about 1 in 300
cases due to a 16-bit memory access at 0FFFFh. Some of the comments in the VIP
1.0 source code seem incorrect, for example: INC/DEC is not emitted in the
first 15 bytes although the source code comments say 20. VIP included the text
string:
VIP V1.0 by Qark/VLAD
[16]
Back to top
% VSTE - VLAD Surface Tracing Engine %
'VSTE' (VLAD Surface Tracing Engine) by Qark was an early attempt at an EPO
(Entry-Point Obscuring) virus. VSTE was used in Qarks 'TraceVir' (discussed
below. VSTE worked very much like a length disassembler to trace the targeted
file until a point was found to patch the victim. VSTE took as arguments a
file handler to the victim file and a pointer to a temporary 300 byte buffer
to read the file contents. VSTE returned a file pointer to the instruction to
be patched and pointer to a buffer containing the first byte of that
instruction on. VSTE did not read the entire file into memory at once (that
kind of memory was not always available under MS-DOS) but lseeked around the
file, following the code and reading 300 bytes at a time. Files accessed by
VSTE were treated as 'raw' with no formatting and the first instruction being
at the very start of the file. This worked for .COM files, but did not
support other formats like MZ .EXE files. VSTE only supported 8086
instructions and stopped at anything 80286+. It is worth noting that VSTE
treated opcode 0Fh as 'POP CS' not an extended opcode, which was only the case
with the 8086 (remember VSTE was released in 1996). Beside following
instructions by their length, VSTE followed JMP/CALL NEAR and JMP SHORT
instructions. Other than 80286+ instructions, VSTE also terminated on
conditional jumps (07xh), JMP/CALL FAR and RET/IRET instructions. [17]
Back to top
% Virus: Gilgamesh %
'Gilgamesh' was a tunnelling, polymorphic, memory-resident retro virus infecting
MS-DOS .COM and .EXE files. Polymorphy is achieved by using the VIP (VLAD
Infinite Polymorphy) engine also by Qark in this issue (discussed above).
Gilgamesh contains some anti-heuristic and anti-debugging structures, and also
attempts to avoid infecting 'bait' files. The first thing done when an
infected file is executed is to issue an INT 21h, AX=5253h. This call serves
4 purposes: It is the viruses residency check. It retrieves the MS-DOS 'List
Of Lists' (used later to tunnel INT 21h). It places IP on the stack to
retrieve 'delta offset' of the virus. Lastly it serves as an anti-debugging
trick since the IP on the stack will be over written if the virus is being
traced. Gilgamesh uses an unusual method of tunnelling The virus retrieves
the INT 21h vector from the IVT (Interrupt Vector Table) and scans the first
1000 bytes for 0EAh (JMP FAR) or 9Ah (CALL FAR). If either instruction is
found Gilgamesh moves on to the destination of the JMP/CALL and begins that
1000 byte scan again. This is done until the virus reaches the MS-DOS data
segment (returned by INT 21h AH=52h) or until no JMP/CALL is found. As
Gilgamesh scans byte-by-byte this may sometimes be unreliable. After this
the virus goes memory-resident. Residency is achieved using the standard method
by Qark: If the host MCB is the last in the chain it is reduce along with the
'top of memory' field in the host PSP, and INT 21h is hooked directly. .COM
files are infected in a quite standard manner. When infecting .EXE files the
virus checks for overlays, 'New Executables' such as NE files and that the
'maxmem' field of the header is 0FFFFh. Some checks are made before infecting
the victim. Gilgamesh will not infect files created on the current data or
files containing numerical digits in their names - this is to avoid bait
files. Gilgamesh also will not infect files beginning with: "SC" (scan,
scandisk), "TB" (all programs in the ThunderByte Anti-Virus sweet), "F-"
(F-Prot), "GU" (Dr Solomans 'Guard'), "AV" (AVP and others), "DV" (dv.exe,
dv.com), "CH" (chk*) and "PR" (progman - windows program manager). INT 21h
AH=60h is used to create standardise, full upper-case path of victim. Gilgamesh
checks for .COM or .EXE extension but differentiates file formats by checking
for MZ marker. When infecting files Gilgamesh deletes checksum databases
belonging to ThunderByte Anti-Virus, Central-Point Anti-Virus, Microsoft
Anti-Virus, AVP (Anti-Virus Pro), Invircible, as well as "chklist.tav" and
"smartchk.cps". Full list of checksum databases deleted is: 'ANTI-VIR.DAT',
'CHKLIST.CPS', 'CHKLIST.MS', 'CHKLIST.TAV', 'SMARTCHK.CPS', 'AVP.CRC' and
'IVB.NTZ' The INT 21h handler of Gilgamesh is quite standard. It performs the
residency check and infects files on open and execute calls. Gilgamesh included
the text string:
=Gilgamesh= by Qark - A VLAD Australia Production
[18]
Back to top
% Virus: TraceVir %
'TraceVir' was a simple memory-resident infecter of MS-DOS .COM files written
to test Qarks VSTE engine (discussed above). When executed TraceVir began by
saving the flags and all registers due to its EPO (Entry-Point Obscuring)
nature. After testing if it was already memory-resident, TraceVir allocated
memory using Qarks standard method of reducing the hosts MCB if it was the
last MCB in the chain, and the 'top of memory' field of the hosts PSP. INT 21h
was then hooked directly. TraceVir then restores the flags and registers,
restores the hosts patched bytes and returns control. Besides handling
TraceVirs residency check, the INT 21h handler infects .COM files on 'execute'
calls. TraceVir does not check file extensions and instead detects .COM files
by absence of MZ marker. TraceVir uses the VSTE engine to place a 'JMP NEAR'
to the virus somewhere in the middle of the host instead of the start, and
appends the virus to the end of file. Files are marked as infected by setting
the low 5 bits of the time-stamp to 02h. The virus is not encrypted. TraceVir
included the text strings:
TraceVir by Qark/VLAD
This virus tests the VSTE engine
[17]
Back to top
% Virus: 386 Virus %
'386 Virus' was a memory-resident infecter of MS-DOS .EXE files. The primary
feature of this virus was use of 80386 instructions and registers. When
executed the virus first checks for the presence of an 80386+ processor: I/O
Privilege Level bits of the flags register are set to 01h (2000h) and if
when flags are set by POPF instruction these bits are non-zero, CPU is 80386+.
Next the 386 Virus checks if it is already memory-resident: INT 21h is called
with EAX='VLAD' if EAX='ROCK' is returned the virus is memory-resident. The
virus goes resident and restores control to the host. Memory-residency is
achieved through standard Qark code. If the hosts MCB was the last MCB in the
chain the virus reduces the MCB and the 'top of memory' field of the hosts PSP.
INT 21h is then hooked directly. Apart from the residency-check, the INT 21h
handler infects .EXE files on 'execute' calls. The 386 Virus does not check
file extensions but instead checks the file for 'MZ' header. Files with the
'maxmem' field of the MZ header not set to 0FFFFh and NewEXE files are
avoided. Files are marked as infected by placing 'VL' in the MZ checksum field
(offset +12h). [19]
Back to top
% VLAD April Fools Edition %
In April 1996 VLAD did something different and released a special 'April
Fools' edition, mainly with 'joke' viruses and articles. Two joke viruses were
published by Qark: 'SySta' and 'ASMVirus'.
Back to top
% Virus: SySta %
'SySta' was a direct-action infecter of MS-DOS .SYS files. SySta infected
MS-DOS .SYS files (MS-DOS Device Drivers) by appending the virus and
pointing the WORD at offset +08h (Interrupt Routine) of the SYS header to the
virus code. Victim files were determined to be valid .SYS files by checking if
the first WORD of the file (+00h - Offset Address of Next Driver) was 0FFFFh.
.SYS files supported multiple drivers in a single file by allowing chained
.SYS headers with the address of the next drivers header held in the first
32-bits of the .SYS header. A value of 0FFFFh indicated that .SYS header was
the last in the list, and most .SYS files contained only a single driver,
hence SyStas check for 0FFFFh at the start of file. When an infected .SYS file
is run SySta sets up a JMP NEAR (0E9h) instruction pointing to the original
Interrupt Routine (saved at infection time) and infected all .SYS files in the
current directory. This is achieved by saving the address of the original DTA
(Disk Transfer Area), setting the DTA to the SyStas heap and entering a ASCII
FindFirst/FindNext loop (INT 21h AH=4Eh/4Fh) for "*.sys". SySta identified
already infected .SYS files by checking if the original Interrupt Routine was
with 1k of the end of the file. SySta included the text string:
SySta by Qark/VLAD
[20]
Back to top
% Virus: ASMVirus %
'ASMVirus' was a direct-action infecter of .ASM (Assembler Source Code) files.
When an infected file (executable assembler from infect .ASM file) is run,
ASMVirus immediately enters a ASCII FindFirst/FindNext (INT 21h AH=4Eh/4Fh)
loop searching for "*.asm". Only the first uninfected file is infected. The
infection process begins by renaming the victim file to '*.as0' and setting
its attributes to 'hidden'. A new .ASM file containing the virus is created in
its place. This new .ASM file begins with a 2-byte comment: ";~". This is the
infection marker, files beginning with these 2 bytes will be considered
infected. Next is the rest of the Assembler header: a code segment is declared
and all segment registers are 'assumed' to be this segment, org 100h directive
is given (the starting address of the assemble file) and the 'radix' is set to
10 (decimal). A label 'start:' is emitted, and then the virus itself is added
to the .ASM files in the form of 'db' (declare byte) statements. 10 bytes of
virus are emitted per line in base 10 (decimal). Once the virus body is
complete, ASMVir ends the .ASM file with and 'ends' directive to end the
segment and an 'end start' to conclude the program and declare the 'start'
label as the entrypoint to the assemble executable. According to Qark, these
.ASM files run under MASM, TASM and a86, and run as both .COM and .EXE files.
ASMVirus included the text string:
ASMVirus by Qark/VLAD
[21]
Back to top
% VLAD Issue 7 %
VLAD Issue 7 was released in October 1996 and was the last edition of the
ezine. Two virus from Qark were included: 'Goodbye' and 'Padania'. Qark
declared his retirement from virus writing at this time, hence the name
'Goodbye'. 'Padania' was dedicated to the Padanian cause: A Northern Italian
region that want independence from Italy. This cause was made well known to
the virus writing community by the Padanian group iKx (international knowledge
exchange).
Back to top
% Virus: Goodbye %
'Goodbye' was a memory-resident infecter of MS-DOS .COM and .EXE files. An
interesting feature of Goodbye was the use of CRC16 algorithm to perform
compares and to mark infected files. Goodbye begins with a strange sequence
of SUB/MOV/DEC/DIV/ADD/XCHG instructions. The purpose of this code is unknown.
When an infected file is run this sequence of instructions is executed, the
virus checks if it is already memory-resident and goes resident if not, and
then control is passed on back to the host. When going memory-resident
Goodtimes uses a slightly different method of allocating memory then most of
the other viruses by Qark. Goodtimes still reduces the size of the host MCB
and "top of memory" field of the host PSP if the host is in the last MCB.
However, after this Goodtimes modifies the host MCB so it is no longer last in
the chain, and creates its own MCB with owner field of 0008h (COMMAND.COM/
System). This stops the UMB (Upper Memory Block) MCB from disappearing leaving
UMB memory inaccessible to MS-DOS. After this INT 21h is hooked directly. The
INT 21h handler handles the already-resident check and infects files on open,
execute, and chmod calls. Files are not infected on 'extended open' but the
infection code still has a check for this. When infecting files Goodbye uses
INT 21h AH=60h to normalise, complete and upper-case the filename. Goodbye
checks for .COM or .EXE extension using CRC16 of the last 4 bytes of the
filename, but differentiates between file formats by checking for 'MZ'/'ZM'
marker (also done with CRC16). Goodbye also avoids infecting files:
tbscan.exe, avp.exe, f-prot.exe, scan.exe, dv.exe and progman.exe. These
filename checks are done with CRC16 as well .COM and .EXE files are infected
in the standard manner, although Goodbye uses an interesting infection marker.
In .COM files, Goodbye stores the CRC16 of the 3-byte JMP to the virus
immediately after the JMP instruction - this gives the first 5 bytes a CRC16
of 0 (zero). The virus does similar with .EXE files: Goodbye sets the
'checksum' field (+12h) of the MZ header to the 18 bytes preceding it to give
the first 20 bytes of the MZ header a CRC16 of zero as well When infecting
.EXE files Goodtimes avoids infecting NewEXE files and files with the MZ
'maxmem' not equal to 0FFFFh. Goodtimes calculates CRC16s a byte at a time
using an 8-bit lookup table, generated at virus start-up Goodbye included the
text strings:
Goodbye everyone!
Viruses were fun, but I've got other things I'd like to do
Qark/VLAD
[22]
Back to top
% Virus: Padania %
'Padania' was a memory-resident and direct-action polymorphic stealth infecter
of MS-DOS .COM and .EXE files. Padania used some anti-heuristic and retro
(anti-anti-virus) code. When executed, infected files immediately call INT 21h
AH=52h (DOS List of Lists). The virus retrieves the segment of the first MCB
(Memory Control Block) and walks the MCB chain. Walking of the MCB chain
serves 3 purposes: First Padania checks for MCBs with owner name beginning
with 'TB' (ThunderByte Anti-Virus) or 'NE' (Nemesis) and immediately returns
control to the host if either anti-virus is found. Secondly, MCBs are checked
to see if Padania is already resident. If the last MCB in the chains owner
name begins with 'DO' (DOS) Padania is already resident and returns control to
the host. Note that 'DOS' owner of is not used by MS-DOS (MS-DOS marks system
MCBs by setting the PSP segment field to 0008h), this is just the name of the
MCB that Padania decides to use. Thirdly, the last MCB is used to go memory-
resident. When going resident Padania allocates memory by reducing the size
of the last MCB and owner PSP 'top of memory' field, marks the affected MCB
as not the last in the chain, and creates a new MCB for itself. This allows
UMBs (Upper Memory Blocks) to still be accessible. When creating the new MCB
Padania marks the MCB as the last in the chain, sets owner PSP field to 0008h
(system) and sets the MCB name to 'DOS'. Padania then copies itself to the
newly allocated memory, passes control to the new copy of the virus and hooks
INT 21h directly. Once Padania is resident it immediately issues an INT 21h
AX=4B00h (execute) this stops some memory-resident anti-viruses from warning
that the INT 21h vector had changed. Padania then infects all files with a
.COM extension in the current directory, but not if the current directory is
on a floppy disk. This direct-action infection is achieved by an ASCII
FindFirst/FindNext (INT 21h AH=4Eh/4Fh) loop that calls INT 21h AX=4300h
(chmod) on the files, causing the memory-resident virus to infect them. After
this control is returned to the host. Padanias INT 21h handler starts with a
code stub very similar to that of the MS-DOS INT 21h handler in an attempt to
fool some people. Padanias INT 21h handler serves 3 purposes: Infection,
stealth and retro abilities. Files are infected on open, execute, chmod and
delete calls. Files are marked as infected by setting the 'seconds' field of
the victims time-stamp to 62. Stealth abilities are implemented on handle read
(INT 21h AH=3Fh), handle lseek (INT 21h AH=42h) calls, ASCII/FCB FindFirst/
FindNext calls (INT 21h AH=11h/12h/4Eh/4Fh) calls and get file time-stamp
(AX=5700h) calls. In the case of read calls, if the read begins in the first
28 bytes of the infected file (modified header) the original uninfected header
is substituted. If the read goes past the original end of the file into the
virus body the read is terminated at the end of the original file. In the case
of lseek call, if the seek is from the end of the file (origin = 02h) then the
call is modified to seek from the end of the original file not the end of the
infected file. In the case of FindFirst/FindNext calls the files size field is
corrected to the original filesize. Padania also has a retro-routine on
execution (INT 21h AX=4B00h). If the file to be executed is a known anti-virus
file (TBSCAN, TBSETUP, AVP, F-PROT, SCAN or AVSCAN), arguments are added to
the command line to disable scanning of memory. Padania takes some intelligent
action concerning its stealth routines. The virus fetches the name of the host
program from the name field of its MCB using INT 21h AH=51h (Get Current PSP).
FCB FindFirst/FindNext stealth is only implemented if current process is
"??MM" (COMMAND.COM). This allows for stealthing of 'dir' command without
'chkdsk.exe' reporting errors. In the case of several archiving, backup and
communications software, read and lseek stealth is disabled, putting the
virus in 'fast-infection' mode. Programs checked for with this feature
include: 'PK' (PKZIP), 'AR' (ARJ), 'UU' (UUENCDOE), 'BA' (BACKUP), 'LH' (LHA),
'RA' (RAR), 'MO' (MODEM), 'SP' (SPEEDISK), 'DE' (DEFRAG), 'CP' and 'MS' (MS
Backup and Central Point Backup). When infecting files, Padania checks for
.CO? or EX? extension. Padania does not infect filenames beginning with: 'AV'
(several anti-virus utilities), 'TB' (ThunderByte Anti-Virus suite), 'IV'
(Invircible), 'PR' (Windows progman.exe) and '-V' (old name for AVP). .EXE
files with NewEXE header or MZ 'maxmem' field not equal to 0FFFFh are not
infected. Padania is polymorphic in all infections. Polymorphic decrypters are
padded to a fixed length of 85 bytes to simplify stealth routines. Padania
includes the following text string:
Padania Virus by Qark/VLAD
This virus is dedicated to all the people in Padania
(Northern Italy) who seek separation from Southern Italy
and to their party Lega Nord.
Questo virus e' dedicato agli abitanti della Padania, in cerca dell'
indipendenza dal sud italia, ed al loro movimento Lega Nord
[23]
Back to top
% Virus: Memorial %
Although Qark announced his retirement in VLAD issue 7, one more virus came out
in the second half of 1997. Win9x.Memorial was co-authored by Qark and fellow
VLAD virus writer 'Quantum'. Memorial was dedicated to Clinton Haines, a young
deceased Australian virus writer. Memorial was a memory-resident oligmorphic
infecter of MS-DOS .COM and .EXE files, and Win9x PE (Portable Executables).
Memorial was the first oligomorphic Win9x virus and also contained retro virus
(anti-anti-virus) features. Although Memorial infected MS-DOS executables as
well, it could not be considered truly cross-platform: It required the
presence of Win9x Operating System to go resident and continue infecting
files. The heart of Memorial was a 12,413 byte VxD file (Win9x LE Virtual
Driver). Memorial used a simple packing algorithm to reduce the file in the
virus body down to 7,508 bytes. When run from an infected MS-DOS .COM file,
Memorial checks if Windows is running and immediately returns control to the
host if this case. Otherwise Memorial issues its MS-DOS residency-check and
takes action if the virus is not already resident. Memorial unpacks its VxD
body to "C:\CLINT.VXD" and goes memory-resident under MS-DOS. MS-DOS residency
is achieved by copying a small stub of code to the second-half of the
Interrupt Vector Table (IVT) at 0:200h and hooks INT 2Fh (MS-DOS Multiplex
Interrupt). The INT 2Fh handler serves two purposes: It handles Memorials
residency check and waits for Windows to load (INT 2Fh AX=1605h). When Windows
loads Memorial initialises a "Win386_Startup_Info_Struc" structure and points
the "SIS_Virt_Dev_File_Ptr" field to its VxD's filename. This causes the VxD
to be loaded during Windows start-up and is preferable to modifying
"system.ini". The MS-DOS stub is 275 bytes of code, plus packed VxD. When run
from a MS-DOS .EXE file Memorial attempts to execute basically the same plan
as with a .COM file but this does not go to plan. Erroneous parameters passed
to the VxD unpacking code cause Memorial to go into an infinite loop, filling
up the C: drive. This effectively makes infected MS-DOS .EXE infections dead
files. When run from an infected PE files, the virus decrypts itself first.
Memorial then uses internal Windows structures to resolve address of Kernel32
procedures 'GetModuleHandleA' and 'GetProcAddress'. These functions are used
to resolve all other Kernel32 and User32 procedures. Next Memorial calls
Kernel32!GetLocalTime for its activation routine. If the date is April 10th
(both the day of Clinton Haines birth and death) Memorial calls
User32!MessageBox displaying a Message box with title:
Clinton Haines Memorial Virus by Quantum/VLAD and Qark/VLAD
and message body:
Clinton Haines, also known as Harry McBungus, Terminator Z and Talon
died of a drug overdose on his 21st birthday, April the 10th, 1997.
During his time as a virus writer he wrote the No Frills family, X-Fungus,
Daemon and 1984 viruses. He was a good friend to VLAD and so we write
this virus in his honour. We hope it's good enough to do him justice.
VLAD Remembers. Rest in Peace
R.I.P.
If the date is not April 10th, Memorial uses Kernel32 calls CreateFileA,
WriteFile, ReadFile, SetFilePointer, CloseHandle and LocalAlloc to unpack and
write the virus VxD to "C:\CLINT.VXD", the same as MS-DOS infections. The VxD
is executed and Memorial passes control back to the PE host. PE infection stub
is 1,360 bytes + 46 byte oligomorphic decrypter When Memorials VxD is loaded,
4 control messages are handled: W32_DEVICEIOCONTROL, INIT_COMPLETE,
SYS_DYNAMIC_DEVICE_INIT and SYS_DYNAMIC_DEVICE_EXIT. In case of first message
the virus returns 0 signalling it does not want to interact with other Win32
applications. In case of second and third message the virus runs its VxD
initialisation code. In case of the fourth message the virus returns 1 to
disallow the VxD from being unloaded. Memorials VxD initialisation code begins
by hooking DOS IFS API (Installable File System) first. This is used to catch
files to infected. Next Memorial takes retro (anti-anti-virus) action
deleting several anti-virus registry keys. From
'\System\CurrentControlSet\Services\Vxd' (statically loaded VxD drivers) it
deletes keys with values: 'VETMON95', 'VETMACRO', 'NAVAP', 'virusafe' and
'WIMMUN32'. From '\SOFTWARE\Microsoft\Windows\CurrentVersion\Run' it deletes
keys: 'NORTON AUTO-PROTECT', 'TBAV for Windows 95',
'Anywhere Antivirus Validation', 'Vshwin32EXE' and 'ViruSafe'. From
'\SOFTWARE\McAfee\ScreenScan' it deletes 'bEnableScreenScan', 'bScanAllFiles'
and 'bScanSubDirs'. From '\SOFTWARE\Cybec\VET Antivirus for Win32\' it
deletes 'Actions\InfectedAction', 'Actions\SuspectAction', 'Memory\Enabled',
'Resident\FileCheck', 'Resident\InfectedAction', 'Resident\SuspectAction',
'Scanning\Scan All Files', 'Scanning\Scan Type', 'Scanning\Skip Renamed',
'Scanning\Subfolders'. From this location it also sets
'Scanning\Extension List' to 'bin, dll, doc, drv, ovl, sys, dot', omitting
.COM, .EXE and .SCR. The Memorial VxD file then allocates two buffers. It
clears the attributes of CLINT.VXD and reads the file into the first buffer,
closes the file and deletes it. The unpacked VxD images is then pack into
the second buffer. When infecting .COM files Memorial checks for .COM
extension and absence of MZ header. Memorial also avoids .COM files ending
with "NS" - this is to avoid Windows 95 "ENUNS" vaccinated files. When
infecting MZ/PE files Memorial checks for .EXE or .SCR extension and
presence of MZ header. MS-DOS .COM and .EXE files are infected by fairly
standard algorithms. In the case of PE files Memorial creates a new last
section containing the virus, increases the section count and modifies the
entrypoint. The 'name' of the last section is 'CLINTON' encrypted with a
random 8-bit XOR. A checksum byte is appended to the section name to mark the
PE as infected. Memorial is oligomorphic in PE infections, capable of creating
96 46-byte long decryptors. Memorials random number generator is initialised
calling 'IFSMgr_Get_DOSTime' on EXE/SCR infections. [24] [25]
Back to top
% References: %
[1] VLAD EZine Archives
http://wiw.org/~meta/
[2] Incest Family Description
VLAD Issue 1 Article.3_1
[3] Daddy Source Code
VLAD Issue 1 Article.3_2
[4] Mummy Source Code
VLAD Issue 1 Article.3_3
[5] Sister Source Code
VLAD Issue 1 Article.3_4
[6] Brother Source Code
VLAD Issue 1 Article.3_5
[7] VLAD Virus Source Code
VLAD Issue 2 Article.4_2
[8] Republic Source Code
VLAD Issue 2 Article.4_3
[9] BIOS Meningitis Source Code
VLAD Issue 2 Article.4_4
[10] Hemlock Source Code
VLAD Issue 3 Article.4_2
[11] Megastealth Source Code
VLAD Issue 3 Article.5_5
[12] Winsurfer Source Code
VLAD Issue 4 Article.4_3
[13] Good Times! Source Code
VLAD Issue 4 Article.5_3
[14] Horsa Source Code
VLAD Issue 5 Article.4_2
[15] Ph33r Source Code
VLAD Issue 5 Article.4_3
[16] VIP Source Code
VLAD Issue 6 Article.4_3
[17] VSTE/TraceVir Source Code
VLAD Issue 6 Article.5_6
[18] Gilgamesh Source Code
VLAD Issue 6 Article.4_2
[19] 386 Virus Source Code
VLAD Issue 6 Article.4_7
[20] SySta Source Code
VLAD Issue AF Article.3_2
[21] ASMVirus Source Code
VLAD Issue AF Article.4_5
[22] Goodbye Source Code
VLAD Issue 7 Article.2_2
[23] Padania Source Code
VLAD Issue 7 Article.3_4
[24] "Junkie Memorial?" - Peter Szor
Virus Bulletin September 1997
http://www.peterszor.com/memorial.pdf
[25] Win95.Memorial Description - Peter Szor
http://www.securelist.com/en/descriptions/58957/Virus.Win9x.Memorial
Back to top