Shareware 1 2 the Maxx

home *** CD-ROM | disk | FTP | other *** search

/ Shareware 1 2 the Maxx / sw_1.zip / sw_1 / VIRUS / FIXUTIL3.ZIP / FIXMBR24.DOC < prev next >

Wrap

Text File | 1992-01-27 | 26KB | 473 lines

FixMBR v2.4 (gamma) FixMBR is a combination recovery/integrity management program for the protection of hard disks. In the case of an Master Boot Record infection FixMBR may be used to restore either the original Master Boot Record or to rebuild it using an original Partition Table taken from either inside the virus or from one of the "hidden" sectors (where most MBR infectors hide them). According to the latest (1991) figures from McAfee Associates, producers of the popular SCAN, VSHIELD, and CLEAN programs, MBR infecting viruses were the cause of over half of all reported infections. FixMBR is designed to provide warning and recovery from such infections. Additionally, FixMBR also provides for capture/storage of an off-line copy of the MBR sector that may be used for reconstruction and capture. FixMBR requires no complicated switches and will prompt for all necessary information and permissions. Further FixMBR will suggest only legitimate partition tables found in the track 0 "hidden" area. User commands are limited to y(es)/n(o)/q(uit) and will be requested when appropriate. On single disk systems q(uit) will terminate the program. On systems having multiple physical disks, q(uit) will skip to the next disk. This is useful when the only activity desired is to back-up the original MBR(s). WARNING Message The only real "caveat"s involve the error checking mechanisms used by FixMBR. When the program starts, the drive table(s) as reported by the system is read and these disk parameters are output. If the CMOS (AT class & 386 and later machines) is corrupt due to battery failure or rogue software, the parameters as reported will probably be different than exist. In this case, the program should be q(uit)ed and the CMOS restored to correct parameters before continuing. The other case is if the disk is not completely allocated to partitions (rare). This would occur if FDISK was not told to allocate all of the disk to active, extended, or non-DOS partitions during the low-level format process. What will occur is that on partition table display a warning message will appear. Should this occur, either check the original partition table values to verify entries or look for another table to use before loading. In most cases a mismatch will indicate a corrupt partition table. Other Functions While FixMBR is designed to install the SafeMBR code for detection of attacks by MBR and partition table viruses, it is also designed to allow easy storage and recovery of original MBR code in the event that the SafeMBR code cannot be used. Suggested Use FixMBR is best utilized before infection or corruption strikes. In this case, run the program, save the original MBR when prompted, select the partition table found in sector one, and allow use of the SafeMBR code. It is further suggested that the saved MBR(s) be copied as .COM file(s) along with the SafeMBR program to a known clean bootable (restoration) floppy that is then write-protected and stored in a safe location. If a printer is connected, Print-Screen may be used to automatically create a hard copy of the selected partition table(s) that should be stored with the recovery floppy. If an Infection Occurs In the event of an identified infection (e.g. STONED), simply boot from the restoration floppy, run FixMBR and increment to the sector in which the virus stores the real MBR (e.g. sector 7) then use this to either restore the original MBR or use the SafeMBR code. In the case of an unknown infection, the best bet would be to select a partition table from a sector other than sector one following a clean floppy boot. In the event that a valid partition table is only found in sector one (e.g. Azusa) then the SafeMBR replacement code must be selected - again only after a known clean floppy boot. Alternatively, the user can use the original MBR stored offline (see MBR8x.DAT below). If used prior to infection, FIXMBR provides for storage of the original MBR code offline in separate programs for each disk. (physical disks, not partitions). These programs will be named MBR80.DAT for the first disk responding, MBR81.DAT for the second disk, etc. When renamed with a .COM extension, these become executable programs that will restore the original MBR. It is very unlikely that a virus will attack the MBR of any fixed disk other than the first (disk 80) since this is the only one in which the MBR is executed, however just in case... FixMBR is designed to operate on ALL physical fixed disks responding as such and will provide for saving all MBRs found. WARNING: Since MBR code is generally unique to each PC, execution of these programs could cause serious data loss if executed on a different machine. DO NOT MIX PROGRAMS. If used in a multiple- PC environment, these files should be renamed to identify with a specific machine. IMPORTANT: For FixMBR to work properly, it is essential that any disk caching software (e.g. PC-Kwik) be turned OFF ! Recovery Using FixMBR Nearly every known MBR infection (with the exception of AZUSA) will store the original MBR sector in one of the hidden sectors (2-11 on MFM and many "translating" drives, 2-26 on RLL drives). For example, the STONED virus and its many variants store the original MBR in absolute sector 7. Furthermore, so that a PC can be booted from a floppy, the partition table MUST be found in absolute sector 1 (see below for a description of the MBR and Partition Table). Consequently, every known non-"stealth" virus keep a copy of the P-Table in its own body. Recovery Using the Original MBR Since it is often necessary to boot "bare" an infected machine, it is recommended that the first step after receipt of FixMBR be creation of a "recovery" disk. The advisability of running FixMBR on a "clean" system and saving the original MBR to a floppy cannot be overemphasized since this is a sure way to recover a system once failure has occurred. For this reason more detail is provided. Step 1: Prepare a bootable floppy disk with the same operating system currently used. Copy the SYS program (may be either .COM or .EXE extension) to the disks. Step 2: Run FIXMBR and respond "y" when it asks if you wish to save the original MBR(s). Step 3: With the bootable floppy in the A: drive, enter the command: COPY MBR*.DAT A:MBR*.COM Step 4: Place a write protect tab on the floppy, label it SafeMBR recovery disk (if you have more than one PC each should be separately labeled - serious loss could occur if the recovery program is executed on a different PC) & store in a safe place. Following infection, easy restoration to the original condition (without SafeMBR code) may be accomplished by executing the MBR8x.COM file(s) after booting from the recovery disk. Recovery using FixMBR (original MBR code) If you have elected not to use the SafeMBR code and the disk becomes infected, then recovery MAY be possible as follows: Run FixMBR but reject (n) the first sector and do not save a copy of the MBR (unless you or someone else wishes to analyze it - the saved file has the extension .DAT and is harmless unless either renamed or otherwise forced to execute. In this case be careful not to mix it with your recovery file. If another sector on the first track is found to have a "possible partition table" either compare it with the original hard copy (see above) or analyze it using the Partition Table description below. If it matches your disk then the sector probably also contains the original MBR code. In any event you can try it by selecting this sector (y) and rejecting use of the SafeMBR code (n). If necessary, repeat for other drives. Recovery Using SafeMBR Code In this case it is generally "safe" to use the Partition Table found in the first sector - select it (y) and permit use of the SafeMBR code (y again). In some cases (e.g. AZUSA) this may be the only recovery method other than using the original MBR code saved offline that will work. The Master Boot Record When the IBM-PC architecture was expanded to allow the use of hard disks in 1982, provision was made for the accommodation of more than one operating system on each hard disk. Accordingly, the first FDISK program permitted up to four partitions or logical disks on each physical disk. While rarely used for multiple operation systems (though systems such as OS/2, XENIX, CMP/86 have exploited this capability), the most common use of partitioning was to allow early DOS versions to accommodate disks larger than 32 Mbytes - the largest disk that DOS prior to Compaq/Zenith 3.31 could accommodate without third party help - by dividing the disk into multiple logical drives. At boot time, the BIOS had to be able to recognize not only that the disk was divided into partitions, but also needed some way to determine which partition contained the operating system to be loaded. This requirement was satisfied by the Master Boot Record. Always occupying the first physical sector on a disk the MBR is divided into two parts: the Partition Table and the Master Boot Record Program - a special code segment that is able to extract the partition table information and to load the first stage of the operating system. Traditionally, this is ALL the MBR code was designed to do, the assumption was made that it was operating in a valid and stable environment, consequently no error checking is done beyond a simple "signature" validation. Since the MBR is very well defined both in both structure and location, it is a target for some of the most successful computer viruses today. The Partition Table Note: hexadecimal (base 16) numbers will be indicated by the suffix "h", other numbers are in decimal notation. The partition table is a 40h (64) byte area in the Master Boot Record that describes the partitioning of a disk. Each 10h (16) byte line describes a single partition: what it is, how big it is, and where it is found on the disk. Some of the information is seemingly redundant, but all is used during the boot process. If booting is done from floppy disk, the MBR sector (the first on the disk) need only contain the partition table, the MBR code segment is not necessary. However, if the fixed disk is to be bootable, then the MBR code segment must be present. The partition table is able to contain a maximum of four entries or logical partitions and versions of MS-DOS (& PC-DOS) prior to 3.31 (sometimes called 3.3+) were only able to address FFFFh (65535) 512 byte sectors for a maximum partition size of 33,553,920 bytes commonly referred to as 32 Mb though not exactly this value. Since a maximum of four partitions are permitted, this gave an effective maximum disk size of 128 Mb, an incredible size in 1982 when a 10 Mb ST-412 disk cost nearly $1000.00 and floppies had just gone from 160kb to 360 kb each. Note: the apparent "loss" of a sector was caused by the fact that the original BIOS did not recognize any disk sector as "0", sector addressing starts with "1". Of course, from the beginning, the partitions permitted a doubleword (four bytes) for the sector numbers rather than a single word (two bytes) so the partition table was from the first able to accommodate much gigabyte disks, a size which began to be exploited with MS-DOS 3.31. However earlier versions were limited to 32 Mb partitions. Prior to 3.31, a number of manufacturers had already provided proprietary means for handling larger disk sizes. EDSI disks commonly used 1024 byte sectors permitting 64Mb partitions. Other manufacturers used extended partition tables by daisy chaining the tables (each logical partition had its own table linking to the next). Still others such as OnTrack's DiskManager used custom device drivers to break the 32 Mb "barrier". However, Compaq's introduction of MS-DOS 3.31, a convention also used by Zenith and DR-DOS finally allowed larger partitions. Microsoft used a slightly different means with MS-DOS 4.x that still required a custom driver to enable programs to used "large" partitions, a requirement that was finally eliminated with the introduction of DOS 5.0. The only important factor to note is that all of these used the same basic partition table (and still do) with only the addition of a "Type 6" partition indicating a "large" (over 32Mb) partition. In any event, the partition table is actually a simple construct - once understood the only limitation to reconstruction of it is knowledge of exactly how the disk is partitioned and even this information, though beyond the scope of this discussion, may be recovered by someone knowlegable in disk structure. Each 10h (16d) byte entry in the partition table is made up of six elements. The first byte (0h) determines which partition is "active" e.g. to be used for booting MS-DOS. This is indicated by a hex "80" in the first byte. All other partitions should have "00" in the first byte. The next three bytes (1-3h) contain information used by the MBR to locate the first sector of the partition in track/head/sector format: the low order four bits (16 max.) of the first byte indicates the head number (the upper four bits are not used), the first six bits of the second byte are the sector number (63 max - 0 is not used). The upper two bits are prefixed to the third byte to generate the track number (1024 max), and the upper nibble of the last byte is the head number (16 max). In theory this should provide for 1,032,192 sectors (at 512 bytes per sector this would allow 516 MB disks) but since few drives have 16 heads or 63 sector tracks, often "translating" controllers or 1024 byte sectors are used to permit addressing large disks. The fifth byte (4h) describes the "type" of partition: 00h indicates "unknown" and is often used by other O/Ss. Type 01 indicates a primary (active) partition with a 12-bit FAT. This is rarely seen except on floppy disks since it can only accommodate 4096 "allocation units". 04 indicates a primary (active) partition using a 16-bit FAT and can be used for partitions containing up to 65,536 "allocation units", 05 is an extended partition, and 06 a "large" partition. Other numbers are used to designate partitions used by other Operating systems such as OS/2 and Unix. Bytes 5-7h contain information used to locate the last sector in a partition the layout is the same as in bytes 1-3h. Bytes 8-Bh and C-Fh are double words indicating the starting sector offset for each partition and the absolute sector count. These are read backwards with the least significant byte first. Thus the first partition begins 00000011h (17) sectors after the MBR and extends for 0000C826h (51,238) sectors - 25 MB). The second partition begins at offset 0000C837h (C826h + 11h) and extends for 00007B2Fh (31,535) sectors (15 Mb). Sample valid Partition Table: 42 MB disk with 2 partitions |A | Start |T | End | Absolute | Absolute | |C | Head/ |Y | Head/ | Partition | Partition | |T | Track/ |P | Track/ | Starting | Sector | |V | Sector |E | Sector | Sector | Count | |E | | | | Offset | | 80 01 01 00 04 04 91 5A 11 00 00 00 26 C8 00 00 00 00 81 5B 05 04 D1 CD 37 C8 00 00 2F 7B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Byte: 0 1 2 3 4 5 6 7 8 9 A B C D E F For a more complete description of the Fixed Disk Partition Table, refer to the *IBM-PC Technical Reference Manual* (IBM), also the QUE book *DOS Programmer's Reference Manual* provides an excellent reference. SAFEMBR v1.6 An integrity checking Master Boot Record program for IBM- PCs and Clones by Padgett. Copyright (C) 1991, 1992: all rights reserved. This program is designed to replace the standard MS-DOS master boot record program with code that does more than just find the active partition and jump to the O/S boot record, SAFEMBR first checks the disk access integrity, its own integrity, and validates the indicated partition. SAFEMBR will detect all known Master Boot Record virus infections including those using "stealth" such as JOSHI, MICHELANGELO, and the EVIL EMPIRE as well as the most common known infector, STONED and its variants. Used in conjunction with NoFBoot (C), the likelihood of an undetected BIOS level infection going undetected drops to near zero. Using the techniques proven by its more rigorous commercial relative, DISKSECURE, SAFEMBR can provide immediate generic front-line detection of viruses both known and unknown for the individual PC. Being a MBR replacement only, SAFEMBR does not go resident and thus does not require any dedicated RAM. Following the IBM/MicroSoft specifications for a MBR, SAFEMBR is effective even with validating BIOSes such as the TANDON and is designed to accommodate "unruly" disk controllers such as the Western Digital WD10002A-27X which may write directly to the MBR. When installed, SAFEMBR will display its logo on each boot. Failure to print the logo could indicate a replacement and is cause for concern. The program CHKSMBR.EXE is provided to allow determination that SAFEMBR code is present. Should an exception occur, the boot will halt with an error message such as "Low Interrupt Vector", "Invalid First Sector", "Invalid Master Boot Record", or "Missing Operating System". The system can then be booted with a floppy disk and investigation made to determine the cause of the exception. It should be noted that many security products using MBR relocation techniques are incompatible with SAFEMBR. If such a product uses MBR redirection to prevent booting from a floppy disk, this will be the case. If use of such a product is necessary, SAFEMBR will have to be removed and the original MBR restored. CHKSMBR The CHKSMBR program is supplied so that the user (or Network Server) can verify that the SafeMBR code has been installed and is intact. Like FixMBR, CHKSMBR has no switches: on invocation it will display either an error message or the SafeMBR logo. It will also return the following DOS Errorlevels for use from within a .BAT batch file or other program. There are some common viruses which simply overwrite the original MBR code (e.g. AZUSA). If the PC is booted from an infected floppy there is no way to prevent this from taking place and there will be no warning that infection has occurred. CHKSMBR is designed to fill this gap by verifying that SafeMBR is still intact on the disk. Errorlevel Returns 0 - Abnormal Termination (disk read error, etc.) 1 - SafeMBR found in MBR (correct response) 2 - SafeMBR NOT found in MBR Thus any return OTHER than 1 indicates a problem. Note: CHKSMBR will operate properly ONLY if the SafeMBR code is loaded onto the system. Padgett Peterson POB 1203 Windermere, FLA, 34786 USA padgett@tccslr.dnet@mmc.com DISCLAIMER: This software is furnished "as is" and all liability for the effects of the use of this software rests entirely with the user. Adequate backups are the best protection from loss. Extensive testing has been made but obviously this cannot include every conceivable combination. SHAREWARE NOTICE FixMBR is SHAREWARE with a suggested remuneration of $1.00 per PC or user supported (volume discounts available). Alternately you may send a class 1 or 2 1966 Pontiac Grand Prix or 1970 Pontiac Trans-Am in a plain brown wrapper to the address above. The SafeMBR code is FREEWARE and may be used as extensively as wished however it is copyrighted material and no changes to the code are permitted without authorization. Note: This distribution consists of six files: FixMBR24.exe - 2,219 bytes - the program CHKSMBR.EXE - 749 bytes - the DOS check program FixMBR24.doc - this document NoFBoot.com - 368 bytes - simple floppy boot protection NoFBoot.doc - documentation Validate.24 - Validation numbers for McAfee's Validate v2.4 - 1992 - Changed Suggested Remuneration v2.4 - 1992 - Added detection and notice for 1k byte sectors v2.3 - 1992 - not released v2.2 - 1992 - Added drive table information and check v2.1 - 1992 - Added early Zenith BR compatibility v2.0 - 1992 - MBR restoration programs made executable. User interface improved. Program restructured. v1.7 - 1991 - Multiple drive handler added v1.6 - 1991 - Fixes "Invalid Partition Table" with unusual table v1.5 - 1991 - First beta version released