home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
PC World 1998 December
/
PCWorld_1998-12_cd.iso
/
software
/
Antiviry
/
ThBy
/
APPNOTES.TX_
/
APPNOTES.TX
Wrap
Text File
|
1998-10-06
|
12KB
|
234 lines
AppNotes.Txt
============
In this file you can find teh following information:
1) Word 6.0/7.0 versus Template Problems
2) Word 6.0/7.0 - Word 8.0
3) AllFiles versus AllExec
4) De EZ-DRIVE driver
5) DOS Append
1) Word 6.0/7.0 versus Template Problems
========================================
One of the effects of an infection with WordMacro viruses under Word 6.0 or
7.0(a) is that documents only can be stored as templates. The reason is
quite simple: only templates can become infected and therefore any document,
which has been infected, will be changed to a template by the virus.
Otherwise, the virus would never be executed. The distinction of a WordObject
being a template or document is just one bit.
Nevertheless, this bit is the cause of all the problems.
What actually happens when you disinfect an infected Word 6.0 or Word 7.0(a)
file? The macros disappear. So far, so good. The problem is what to do with
the Template bit. Just resetting it will not do. Original templates will turn
into a document and all template data (customizations, toolbars, usermacros,
stylesheets, etc) will be lost.
The database used by TbScan has been updated where possible to take care of
this problem. For about 50 percent of the viruses, the difference between an
infected document and an infected template can be spotted on the actual
infection. When we encounter an infection where this is possible, we will
reset the Template Bit if the infection was on a document (local infection),
and if the infection was on a template (global infection), we will not touch
the Template Bit.
There is also the possibility that we can not see the difference.
In those cases, we apply the following rule: if the extension of the file is
.DOC (default document extension), we will reset the Template Bit, otherwise
we will not touch it.
2) Word 6.0/7.0 versus Word 8.0
===============================
Many users are starting to use Word 8.0 now and our support people are
getting the same question repeatedly: 'We had an infected Word 6.0 or Word
7.0(a) document which we disinfected with TbScan. When we load this document
in Word 8.0, it claims that there are macros inside the document, which will
be executed when the document is opened. Did we or didn't we disinfect the
document?'
To really understand this issue, let's explain a bit about the differences
between Word 6.0 and Word 7.0(a) on the one hand and about Word 8.0 on the
other.
Word 6.0 and Word 7.0(a) make use of the macrolanguage WordBasic.
Word 8.0 is using VBA5 (Visual Basic for Applications Version 5.0) and is
much more powerful than WordBasic, and not downwards compatible with WordBasic.
To insure maintenance for the users who have built their macros in Word 6.0
or Word 7.0(a), Microsoft has built in a WordBasic to VBA5 translator.
It is a one-way translator and functionality of the macros after translation
is not guaranteed.
When a user loads a Word 6.0 or Word 7.0(a) document in Word 8.0, Word 8.0
will automatically translate the previous Word format into the new Word
format. However, if it detects the presence of macros, Microsoft's anti-virus
techniques jump in and Word 8.0 will present a box which informs the user
the document has macro's and asks the user if the macro's should be skipped.
We realize that the presence of this box may raise a few questions.
TbScan did remove the macros from your infected document. Nevertheless, Word
8.0 does not know this. How is this possible?
Our research team has discovered, after some research, that Word 8.0 is
'not that smart' handling older types of documents. When it opens a Word 6.0
or Word 7.0(a) document, it will look at the area where the Macro Table is
stored. In addition, when there are macros listed in that section, it will
present the box above. Microsoft does not check whether the file is a template
or not and does not check if the macros 'present' are deleted or not.
To prevent this box from popping up, we have added some functionality to the
scanner when cleaning and erasing macros. In cases where, after cleaning a
document, no further macros are present and no other Template Data are
present, we will remove the Macro Table from the document.
The user will not be bothered again by Word 8.0 when the user loads a
previously infected Word 6.0 or Word 7.0(a) document.
3) AllFiles versus AllExec
==========================
Release 8.03 of TbScan will have two 'at first glance' similar switches:
AllExec (AE) and AllFiles (AF). There is an important difference between the
two switches though. With the appearance of macro viruses everybody has
started to scan using the old AllFiles switch because documents and templates
can have any extension. The scan process slowed down and scan times increased.
TbScan is known, among other items, for its speed. The old AllFiles switch
really was time consuming as All Files were scanned against All Viruses. Thus,
any non-executable extension was scanned not only for macro viruses, the
intention of the user, but also for all binary viruses. At that time the old
AllFiles switch was appointed another function: Scan All Files for All Macro
Viruses. Exactly what the users wanted and no redundant overhead in time.
In version 8.03, the functionality Scan All Files for All Viruses was
reinstated and has been put behind the command line switch AllExec (AE).
By default, all executable files and OLE2 files (Word/Excel) are scanned.
Additional option: When To Use What Switch?
- To scan all files for macro viruses, use the AllFiles (AF) switch. In the
Windows versions, this is the 'non executable scan', which can be found in
"Options"
- To scan all files for all viruses (macro and binary), use the AllExec
Switch, which is called 'scan all (non-executable) files as executables'
in "Advanced Options"
We expect the AllFiles switch to be used most frequently, since macro viruses
have become increasingly important. As the spread of macro viruses grows each
day, we offer updates on macro virus detection at least once a week on our
web-site (http://www.norman.nl) and ftp-site (ftp://ftp.norman.nl) with the
file TbScan.Def to ensure the most secure solution possible. But remember:
even when you have updated your product with the latest definition file, there
are at least a dozen macro viruses out there which nobody has seen yet and
which are thus undetected.
4) EZ-DRIVE
===========
Problem:
I have an enhanced IDE disk of 1 Gigabyte and I have created
one large partition on it. Afterwards my system got infected and
now I am unable to clean it.
Explanation:
The ROM BIOS is unable to support large disks. Most enhanced
IDE disks are able to act as two different drives, working
around the ROM limitations. However, if you create just ONE
but very large partition, this workaround can not be used
anymore. Instead, EZ-DRIVE puts a special resident program on
the first track of your disk. It takes care of the BIOS
translations necessary to access the disk. Since the first
track of a disk is supposed to contain the partition table and
master boot record, it features some stealth capabilities, by
hiding itself and acting as if these sectors are there.
Actually, it works exactly the same as some advanced bootsector
viruses. Now, supposed you get infected by a bootsector virus.
Several things may happen:
1) A multipartite virus got active after the EZ-DRIVE driver was
executed. The virus made a copy of the master boot record (this
is what it sees since EZ-DRIVE is active and hides itself). Now,
if the system boots, the virus becomes resident and tries to
execute the original master boot record. It should however
execute the EZ-DRIVE driver, but doesn't know that. The system
now tries to boot without the necessary BIOS translations and
becomes inaccessable.
2) The virus executes after booting from a diskette and makes
correctly a copy of the EZ-DRIVE driver, and puts itself in the
space behind the master boot record, which is usually not used.
EZ-DRIVE however uses this space, but now it is overwritten.
When the system boots, EZ-DRIVE will be loaded by the virus, but
is partly overwritten and doesn't work anymore.
3) The virus contains its own bootsector loader. The virus
interprets the EZ-DRIVE driver as a partition table, and tries
to boot from the bootsector pointed by by the assumed partition
table. A system crash will be the result.
An anti-virus system even makes things worse. Depending on the
anti-virus product, the virus, and the EZ-DRIVE version, it may
see one of the following sectors when it tries to read the
partition sector:
1) The original master boot record.
2) The EZ-DRIVE driver.
3) The virus.
Things will usually work OK when you scan the system for viruses,
but a problem will occur if you try to repair an infected system.
Workaround:
Boot from a clean diskette. Do NOT use the EZ-DRIVE feature to
load the EZ-DRIVE driver before booting from the diskette. Put the
diskette into the drive and close the drive before switching on
the machine. Now use TbUtil to make a safety backup of your
partition table.
An even better approach is to divide the drive into two (or more)
partitions and not use the EZ-DRIVE large partition feature.
This gives you additional benefits like a faster disk response,
less slack space (because of the smaller cluster sizes), and the
ability to separate the code from the data files, making maintenance
and disaster recovery much easier.
MEMORY OPTIMIZERS
Problem:
Some memory optimizers, like MemMax, MemMaker and Optimize, will
not work properly if used in combination with the resident TBAV
utilities. The resident TBAV utilities can act as device drivers
as well as normal executables, depending on the way they are
loaded, and this confuses some memory optimizers. The TBAV
utilities also hook themselves into DOS for better virus
protection, and they can not be moved in memory once loaded. Any
attempt to do so will hang the machine.
Workaround:
Remove the TBAV utilities from the AutoExec.Bat file and/or
Config.Sys file and run the memory optimizer. Add the TBAV
utilities again to the AutoExec.Bat and Config.Sys file, and
highload them if desired.
5) DOS APPEND
=============
Problem:
The /X switch of the DOS APPEND command is very dangerous: if
you APPEND a directory with /X and then delete *.BAK when no
such files exist in the current directory, then the .BAK files
in the APPENDed directory will be deleted instead. APPEND is
able to 'fool' programs by accessing another file than the file
requested by the application, if a file with the same name
exists in another directory. This also applies when one of the
TBAV utilities needs to consult an Anti-Vir.Dat file: The
Anti-Vir.Dat file of another directory might be accessed instead
of the intended one.
Workaround:
TbSetup and TbScan switch off APPEND automatically if they
detect that it has been loaded, but the resident TBAV
utilities don't. It is therefore recommended to be very
careful if you need to use the APPEND /X option and to
switch it off as soon as you don't need it anymore.