From: Danny Schwendener IDA Subject: ANTI virus report Date: 18 Feb 1989 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# 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 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 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.