macman@ethz.UUCP (Danny Schwendener) (02/17/89)
This is a report on the ANTI Virus. For any information, please contact
me directly at the following address:
Danny Schwendener
ETH Macintosh Support, ETH-Zentrum, m/s PL, CH-8092 Zuerich, Switzerland
UUCP: macman@ethz.uucp BITNET: macman@czheth5a.bitnet
Internet: macman@ifi.ethz.ch AppleLink: macman%czheth5a.BITNET@DASNET#
Note: This is an extract of the full report. Sensitive information has
been removed. The full report has been sent to known authors of
virus detectors and vaccines. Please distribute this version of
the report as widely as possible. I don't have access to CompuServe,
GEnie or CalvaCom.
A. HISTORY
The virus initially appeared in France. So far, it has been signaled in
Paris, Marseille and a few other places in France. Thierry Lalettre, chief
moderator of the Macintosh forum in CalvaCom, alerted by user contributions
in his forum, posted a warning to CompuServe and mailed samples of the virus
to a few authors of macintosh vaccines and viral detectors, including myself.
Note: CalvaCom (formerly Calvados) is Europe's largest commercial electronic
conferencing system, in the same spirit as CompuServe or GEnie, but
mainly directed at owners of Apple products.
B. OVERVIEW
The ANTI Virus is a program that attaches itself to the end of the main
code resource of an application. It patches the main code so that it is
invoked in the first place each time the application is started. An
infected application will try to infect the system heap, if it wasn't
already infected beforehand (the system heap means the part of the system
that has been loaded into memory at boot-time. ANTI does *not* infect the
file 'System').
The virus does nothing hazardous besides propagating itself. It is less
contagious than the INIT29 virus, but more than nVIR.
The hypothesis made by Thierry Lalettre, stating that Apple France
Developer Support Manager Alain Andrieux' program 'Stamp 1.0b5' has
been purposely recompiled by an unknown person to include special
infection code, is wrong. A disassembly of all resources in the
application only showed up that it was infected in a normal way by
the ANTI virus.
Thierry also stated that the virus only attacks applications with
CODE ID=1 named "Main". This is not correct. Actually, the virus
propagates to all applications whose main code entry starts with
a JSR. Most compilers create this type of applications, and some of
them, including MPW, name the CODE ID=1 resource "Main".
Under certain circumstances, the virus also propagates to all other
kind of applications (i.e. the ones which don't start with a JSR).
The virus assumes that the main program entry of the application
to infect is contained in CODE ID=1. This is the case in all normal
applications. Applications whose main routine is contained
in a CODE resource different from ID=1 will either not be infected
or crash.
Portions of the code suggest that the virus has been written as part of
a copy-protection scheme.
C. DETECTION
<some stuff removed>
The virus can be detected by several means:
- it adds 1344 bytes to the CODE ID=1 resource of the file. An infected
application will have grown by 1K. The modification date is changed to
the date and time of the infection.
- it contains seven occurrences of the hex sequence $16252553. The last
occurrence of this sequence is located 43 bytes before the end of the
CODE ID=1 resource. The virus uses this sequence to detect if a System
or an application has already been infected.
- the virus also contains a 9-char. pascal string 'ANTI ' (hence its name)
followed by the hex sequence. The 9-byte string is followed by the
pascal string '#000000'.
- it patches _MountVol and _OpenResFile.
Trap watcher programs like GateKeeper, RWatcher or Vaccine will successfully
prevent infections. There is however a restriction with Vaccine: As the
virus temporarily uses the pointer to the global variables (A5) for
internal tasks, Vaccine will not be able to access the screen to display
a warning alert. If the option "Always compile MPW INITs" is unchecked,
it will beep and wait that the user presses 'y' (allow resource copy) or
'n' (don't allow copy). If the option is checked, Vaccine will allow
the infection without warning the user. So be careful if you use that
option.
The next release of VirusDetective will be able to find this kind of virus
by looking for specific hex sequences.
D. REPAIR
Note: I personnally don't endorse this. Badly repaired applications
may cause much more harm than the virus itself could ever do.
An infected application should be deleted. I'm including this
information for those who forgot to backup their disks.
The virus starts with the following hex sequence:
000000: 6000 0028 0000 0000 1625 2553 0723 3030
000010: 3030 3031 0941 4e54 4920 1625 2553 0723
000020: 3030 3030 3030 xxxx xxxx
xxxx xxxx contains the saved values for the instruction words that
have been patched by the virus.
To repair an application:
1- Be sure you're working in a clean environment (uninfected Finder
and ResEdit).
2- Open the CODE ID=0 resource. Write down the word at position 16
(first word of the third line if opened with ResEdit). This value
tells you at what position within the CODE ID=1 resource you have
to look for the patch, and is usually $0000.
3- Search in the CODE ID=1 resource for the hex sequence I described
above. write down the value I noted as 'xxxx xxxx'.
4- Still in CODE ID=1, find the location of the patch, with the value
you found in step 2. The first word of the patch should be $4EBA.
5- Replace the patch by the two words you found in step 3.
6- Remove the whole virus code (everything from the virus start to
the end of the resource). This step is not absolutely necessary.
D. INTERNAL WORKINGS
<lots of text deleted>
The _MountVol patch works as follows:
- Call original _MountVol
- Check if mounted volume is a floppy drive. If not, exit.
- Check if floppy is old (400K) or new (800K) and if the disk is
single-sided or a double-sided. According to the result, read in either
logical block 192 or 384.
- check for our hex sequence in position 8 of the block. If found, JSR
to the code in position 0 of the sector, then exit.
Note: The virus does not contain any portion of code that writes something
directly to a logical block. Also, the code that will be executed
if the search is successful is not known at this point. This routine
has a strong ressemblance to existing copy-protection schemes. It
is very possible that the virus is part of a copy-protection. I
won't comment on copy-protection per se, but I find using viruses as
part of a product's protection scheme extremely unethical.