********************************************* *** Reports collected and collated by *** *** PC-Virus Index *** *** with full acknowledgements *** *** to the authors *** ********************************************* The 4096 virus has spread rapidly in Israel, where it was first reported in October 1989 to the USA and the UK. The FISH virus is based on it. Vesselin Bontchev reported in May 1990: No, we don't have this virus in Bulgaria, at least - not yet. But Morton Swimmer gave me a copy of an infected file. I studied it a bit and now I can say that this is the virus which is the easiest one to get rid of. Just run an infected file - to ensure that the virus is in memory. Then for each directory of your disks execute the commands copy *.com nul copy *.exe nul After this turn the computer off to remove the virus from memory. That's all - your files are no longer infected. ======= Computer Virus Catalog 1.2: "4096" Virus (5-June-1990) ======= Entry...............: "4096" virus Alias(es)...........: "100 years" Virus = IDF Virus = Stealth Virus. Virus Strain........: --- Virus detected when.: October 1989. where.: Haifa, Israel. Classification......: Program Virus (extending), RAM-resident. Length of Virus.....: .COM files: length increased by 4096 bytes. .EXE files: length increased by 4096 bytes. -------------------- Preconditions ----------------------------------- Operating System(s).: MS-DOS Version/Release.....: 2.xx upward Computer model(s)...: IBM-PC, XT, AT and compatibles -------------------- Attributes -------------------------------------- Easy Identification.: --- Type of infection...: System: Allocates a memory block at high end of memory. Finds original address (inside DOS) of Int 21h handler. Finds original address (inside BIOS) of Int 13h handler, therefore bypasses all active monitors. Inserts a JMP FAR to virus code inside original DOS handler. .COM files: program length increased by 4096 .EXE files: program length increased by 4096 Infection Trigger...: Programs are infected at load time (using the function Load/Execute of MS-DOS), and whenever a file Access is done to a file with the exten- sion of .COM or .EXE, (Open file AH=3D, Create file AH=3C, File attrib AH=43, File time/date AH=57, etc.) Interrupts hooked...: INT21h, through a JMP FAR to virus code inside DOS handler; INT01h, during virus installation & execution of DOS's load/execute function (AH=4B); INT13h, INT24h during infection. Damage..............: The computer usually hangs up. Damage Trigger......: A Get Dos Version call when the date is after the 22th of September and before 1/1 of next year. Particularities.....: Infected files have their year set to (year+100) of the un-infected file. If the system is infected, the virus redirects all file accesses so that the virus itself can not be read from the file. Also, find first/next function returns are tampered so that files with (year>100) are reduced by 4096 bytes in size. -------------------- Agents ------------------------------------------ Countermeasures.....: Cannot be detected while in memory, so no monitor/file change detector can help. Countermeasures successful: 1) A Do-it-yourself way: Infect system by running an infected file, ARC/ZIP/LHARC/ZOO all in- fected .COM and .EXE files, boot from unin- fected floppy, and UNARC/UNZIP/LHARC E etc. all files. Pay special attention to disin- fection of COMMAND.COM. 2) The JIV AntiVirus Package (by the author of this contribution) 3) F. Skulason's F-PROT package. Standard means......: --- -------------------- Acknowledgement --------------------------------- Location............: Weizmann Institute, Israel. Classification by...: Ori Berger Documentation by....: Ori Berger Date................: 26-February-1990 ==================== End of "4096" Virus ============================= Report from Jim Bates - The Virus Information Service - October 1990 === 4K/FRODO/I.D.F Virus === The recent hiatus over possible infection by the 4k/FRODO/IDF virus centred on the virus's trigger date of 22nd September. The fact that a bug in the code invariably caused the affected machine to hang when an infected file was executed tended to make most observers dismissive of the problem. As usual, the dire warnings published by some sections of the computer press prior to the trigger date were inaccurate both in their prediction of the number of infected machines and also in the description of the effects of infection. This virus has been known to researchers for nearly a year now and a preliminary report was published in the May 1990 issue of the Virus Bulletin in which mention was made of this virus's capacity to infect data files as well as COM and EXE program files. No mention was made of this fact in the warnings that I saw and I heard no reports from elsewhere that it had been mentioned. Since the infection of data files by 4K can cause both immediate and long term problems for affected users, more detailed information concerning the specific effects of data-file infection has been gathered and is reported here so that future misunderstandings and omissions may be avoided. 4K infects both COM and EXE files by the unusual process of summing the ASCII values of the three characters which comprise the filename extension. If the total value of the extension characters of an uninfected file is 223 (COM) or 226 (EXE) then infection will take place. It should be noted that the individual characters are first OR'ed with 0DF hex and this effectively excludes all characters below 64. The total number of possible file extension which fit these criteria has been calculated at 1161 (including inversions and rotations) and several of them have been noted as common data file extensions. Among these are OLD, MEM, PIF and QLB which total 223, and DWG, LOG and TBL which total 226. The distinction between the two sets is important since the virus necessarily distinguishes between the techniques necessary to infect COM or EXE files and the amount of corruption to the original file contents will be greater for EXE (sum 226) type files. The Effects 4K is a "stealth" virus and contains code which misinforms DOS about the contents and length of infected files. This means that while the virus is resident and operative in system memory, infected files will appear "clean" to the operating system. This also means that such files will similarly appear "clean" to any program using DOS services. Infected data files, if copied to backup disks or tapes will carry the infection with them. The effect of this is remarkably similar to the dBase virus which deliberately sets out to corrupt data files. While the virus is resident, all files will appear clean and application programs will function normally. However, when the virus is removed (by replacing all affected program files), application programs will "see" the corruption introduced by viral infection and the effects will be unpredictable. In one reported incident concerning DWG (drawing) files, the application program aborted with an error when an infected data file was encountered on a clean system - although program function was fine when the machine was re-infected for test purposes. In this instance (EXE type infection), various bytes within what WOULD have been the EXE header were altered by the virus and the 4K of virus code was appended to the end of the file. Since this first section of the file contained vital header information, an error was encountered as soon as an infected file was accessed and the application program aborted. EXE infection from the 4K virus usually changes five fields within the EXE header as follows :- WORD at offset 04H = Number of Pages WORD at offset 0EH = Stack Segment value WORD at offset 10H = Stack Pointer value WORD at offset 14H = Instruction Pointer value WORD at offset 16H = Code Segment value The Cure The original contents of these fields can be recovered from the beginning of the appended section of virus code. On EXE type files where the sum of the extension characters is 226, the original 28 byte header is stored at the beginning of the virus code and may be identified by comparison with the unmodified fields of the header. The actual storage position will always be 4 bytes on from a paragraph boundary (ie: divisible by 16) and will be near the start of the last 4096 bytes of the infected file. Disinfection in this case can easily be accomplished by replacing the original header and truncating the file by exactly 4096 bytes. A similar pattern is used for the infection of COM type files where the sum of the extension characters is 223 but in this case, only the first six bytes of the file are altered and need to be recovered (although the original 28 bytes are saved exactly as in EXE infection). Obviously the effects of such data corruption are unpredictable and will depend upon the type of information and how the relevant application program accesses it. The DWG files mentioned above contained graphic data and this may be peculiarly sensitive to this type of corruption. The extensions mentioned above were selected for mention simply because they are extremely common and may produce strange effects on recently dis- infected systems. Among the COM type extensions - MEM is used by dBase programs as variable storage and may produce errors which could be extremely difficult to trace. PIF files are used by various version of Microsoft WINDOWS and again, the effects will vary and could be intermittent. The QLB extension is used by Microsoft's QuickBASIC environment libraries and infection here will usually produce immediate errors when the programming environment is invoked with an infected library file. OLD is an extension used by many packages and along with QLB it presents a special problem. The fact that infected data files may exist on backup disks may be a problem when data integrity is paramount but the virus code is unlikely to find its way back into the processing stream and thus become "live" again. However, when considering the OLD and QLB extensions (and possibly others), there is a distinct chance of this "dormant" code being re-activated. The QLB files for example are actually in EXE format (with the familiar MZ header word) but they do contain executable code which remains untouched when the COM type infection of 4K is introduced. Thus under certain circumstances, invocation of QuickBASIC's environment may execute the virus code and re-install it in memory to begin the replication process all over again. The OLD extension presents even more risk since there are several program optimisation utilities which rename an original program file with an OLD extension prior to generating a modified file. One of the best known of these is the LZEXE file packing program. LZEXE is an excellent utility in widespread use which produces significant reductions in size when applied to ordinary EXE files. The reduction is done by creating a self-extracting archive of the original program file which unpacks itself in memory when it is run. The original (unpacked) version of the file is renamed with an OLD extension and the danger with 4K infection is that when the packed file becomes infected, a user might delete it and rename the OLD file back to EXE before either using it or repacking it. In spite of the fact that files with an OLD extension are infected as COM files, renaming an infected one as EXE and trying to run it WILL re-infect a system. With infections of the 4K virus, it is therefore plain that ALL files should be checked for infection and replaced with clean copies if possible. Since backups may be corrupted, a good, reliable, disinfection program is a must to recover damaged data files. During tests to confirm some of the effects described in this article, I had occasion to try four 4K disinfection programs and I'm sad to report that two of them did not disinfect the target file correctly and errors occurred even after the virus code was removed. The relevant vendors have been informed and are looking into the problem. VIS Classification - CEARSdD4096A **************************** UPDATE *************************** Update report from Jim Bates - The Virus Information Service - December 1990 === Disinfection Report === During recent testing of the effects of data corruption experienced after an infection of the 4K virus, it was noted that commercially available disenfection routines were not as effective as they claimed to be. These routines were put aside until the 4K problem was completely resolved but they have since been examined in greater detail and the results that were obtained have led to the following discussion of disinfection techniques and the associated pitfalls which may be encountered. The actual process of disinfection must first be defined as returning a file (or disk sector) back to EXACTLY the condition it was in prior to being infected by virus code. This will naturally included the restoration of content, length, attributes, date/time settings and possibly even the cluster location on the disk (for copy protected software). It may well be that restoration of all of the above items is unnecessary in most instances, but there are certainly occasions when they ARE all needed for correct functioning of the appropriate software. While there is an obvious division between Parasitic and Boot Sector virus disinfection, there is the less obvious categorisation between a generic and specific approach. The virus-generic versus virus-specific argument has caused much heated discussion in virus research circles for some time now and it is not the intention to resurrect this once again except where it affects disinfection capabilities. Let us first consider Boot Sector viruses - while these are the most awkward for ordinary users to recover from, they are actually the easiest as far as disinfective software is concerned. Virus-specific disinfection software will contain accurate details of the virus concerned and by using this will be able to locate the original (uninfected) copy of whichever boot sector has been affected. It is then a simple matter of replacing the infected copy with the clean one. Virus-generic software on the other hand, can work in one of two ways - if a clean copy of the various system sectors has been taken and stored prior to any infection, it is a simple matter to repair any infection. Alternatively, it is often possible to reconstruct the relevant sector by specific system reference. Either way, the sector(s) can be repaired without reference to the capabilities of the particular virus as long as the machine is running on a trusted (ie: clean) operating system. Most Boot Sector viruses cause no permanent damage during their infection routine, but there are some (notably the New Zealand or Stoned virus) which can cause damage on certain machine types. In these cases, simple disinfection may not be possible and the user may have to resort to the ultimate option of reformatting the disk. This is probably an ideal place to clear some of the misunderstandings about disk reformatting as a disinfection exercise. Under most MSDOS operating systems, the very first sector on the disk (identified as Sector 1, Track zero, Head zero) contains the Master Boot Record. This is ALWAYS loaded into memory when the machine is booted and it contains the partition table which lists exactly how distinct areas of the disk have been allocated. Now consider a disk which has been partitioned into two separate drives (usually C: and D:), the partition table contains the starting and finishing address of each partition (in absolute terms of Track/Head/Sector numbers) as well as the type, status and other details about it. Users will be aware that if they have a hard disk partitioned in this way, it is easily possible to format either drive C: (first partition) or drive D: (second partition) without damaging data stored on the other partition. Thus it can be appreciated that the ordinary DOS FORMAT command does not affect the entire disk. Even if the physical drive contains only one partition, FORMAT will not touch the Master Boot Sector. So, if a virus has modified the Master Boot Record it cannot be removed by an ordinary format, a special - highly machine specific - low-level format routine is required, followed by reconfiguration and re-partitioning with the DOS FDISK program. Just as the first sector of the physical disk contains the Master Boot Sector, so the first sector of each partition will contain a Partition Boot Sector. If there is more than one partition, one of them will be marked within the Master Partition Table as "active" and the boot sector of this partition will also be loaded into memory when the machine is booted. Obviously, viruses which infect the Partition Boot Record can be destroyed by the normal DOS FORMAT command. Files infected by Parasitic Viruses present a different range of problems for disinfection software. The most secure method of disinfection is still to delete the infected file and replace it with a known clean copy from a verified and protected master disk. However, this may be inconvenient - the master disk may not be readily available - it may itself have become damaged or corrupted - they may not even be a master disk! Whatever the reason, the user may be attracted by the possibility of quick and easy virus "removal" facilities being offered as part of an antivirus package. This is where virus-specific software can become a real boon (always assuming that the particular virus causing you problems is "known" to the software). Most parasitic viruses infect files by appending the virus code to the end of the existing file and then modifying the original file contents so that processing is routed THROUGH the virus code first. In these cases, the virus will usually repair the original file contents so that the host program will continue to function correctly. For these viruses, disinfection is simply a matter of detecting the section of virus code that does the repair and using the details that it contains to effect a permanent repair before actually removing the virus code from the end of the file. The problems arise from two directions - if the virus is of the stealth type, it may fool the operating system to such an extent that any self-checking mechanisms within the host program will "see" a clean file exactly as intended. However, once the stealth characteristics are removed from the system, the actual repair of the file may not be accurate enough to restore the file to full health. This is actually case with at least three software "cure" packages when attempting disinfection of the 4K (Frodo) virus. In this case, the virus code is appended to the host file and aligned on a paragraph boundary. The repair of the header section of the file may be perfectly alright but removing the virus code can leave the small offset used for paragraph alignment. On ordinary program files this caused now problems but on protected files with self-checking routines the extra bytes cause the protection mechanisms to trigger and prevent program operation. On data files, the presence of any extra bytes will of course produce totally unpredictable results. On a machine with large numbers of infected files, there is no doubt that a virus-specific disinfection capability could be an enormous time saver but if the implementation is anything other than 100% it is best avoided. Few implementations of virus-generic recovery software have yet been seen and this may be because the processes involved in preparing this method are somewhat more time-consuming. Nevertheless, given accurate and well written code, this method does promise much. The theory goes as follows :- assume a program exists which will automatically take an exact copy of all specified files (just like a backup!) and stores them somewhere. This program is also capable of replacing the originals with the copies on command. Once the copies have been taken, ANY parasitic virus infection can be cured by simply restoring the copies and rewriting them over the originals. The difficulty is the time and space needed to maintain (and check) the copies. So, if the software is refined so that it no longer copies the whole file but just the sensitive sections which are at particular risk from virus attack, it can be made much faster and will take up less space. Include similar copies of the Master- and Partition-Boot sectors and you have a virus-generic disinfection system which will not only disinfect most known viruses, but also any of the more primitive virus types which have not yet been written! All of the foregoing refers specifically to changes brought about within files by actual virus infection. As mentioned in the report on the NOMENKLATURA virus, corruption introduced by the trigger or payload of a virus is almost invariably incurable. The final solution if you are not sure exactly what is infecting your system is to reformat your whole system at low level and then reconfigure it from scratch with master program files and data from your latest backups. If you DO know what the problem is, such drastic action is unnecessary. If you are using a commercial cure program the best advice would be to verify carefully that the "cured" program exactly matches the clean master file before you go ahead and use it. Once again, there is no substitute for regular, verified backups of data and configuration files. The information contained in this report is the direct result of disassembling and analysing a specimen of the virus code. I take great pains to ensure the accuracy of these analyses but I cannot accept responsibility for any loss or damage suffered as a result of any errors or omissions. If any errors of fact are noted, please let me know at :- The Virus Information Service, Treble Clef House, 64, Welford Road, WIGSTON MAGNA, Leicester LE8 1SL or call +44 (0)533 883490 Jim Bates ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++ end of reports ++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++