    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