padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) (12/05/90)
Thanks to Michael Head, I have had a chance to take a brief look at this infector. If it were not for the vector, it might not be dangerous, however it appears to be being distributed along with Packard- Bell computers. Since these are often sold from general merchandisors, it has the capacity to become widespread among non-computer-literate users. The distribution appears to be on utilities disks provided with the computers. I have not fully disassembled the virus yet but it is a boot sector infector that can be recognised on floppies since the DOS warning messages are not found on the boot sector and the jump parameter of CCh is found in the third byte. Once infected, the virus goes resident in the TOM reducing a CHKDSK total memory return by 4k (640k machine will report 651,264 bytes instead of 655,360 bytes). Only part of the code is stored in the boot sector of an infected floppy. What looks like sloppy programming has the virus store the action in DOS sector 45 (cyl 2 head 1 sect 1) on the floppy, overwriting sector(s) in the files area. Both this sector and the reserved area at the TOM will contain the ASCII string "MusicBug v1.06. MacroSoft Corp.". It looks like this string will be found at 9C00:0210 in memory but cannot guarentee the address yet. Once the rest of it is pulled apart, I can let you know what it does to a hard disk & hopefully a cure. From what I have been told, the sealed envelopes containing the floppy are marked with the same imprint of a blue floppy disk & blue numbers partially overwritten by a red square containing what look like chinese characters as was found with the "Modular Component Technologies" disks that contained the STONED virus a few months ago. Meanwhile, it's getting late, Padgett
padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) (12/05/90)
Just a bit more data (still haven't seen ALL the code) but the virus appears to be 4k long. It is stored in the boot sector (and I would expect in the partition table of a hard disk since Michael Head indicated that it had infected the hard disk) and seven consecutive sectors. The original boot sector is also stored as a single sector. The confusing part is that the virus seems to move the storage sectors around on each infection. Since I have not yet seen the infection mechanism, this is not certain, but the two boot sector samples supplied have differences in the data area used to identify the virus' storage location. This would account for the different effects reported - one sample put the virus right in the middle of where one of the hidden system files would reside. The first sample retrieves the code in seven segments beginning at cyl 2 hd 1 sector 1. The second sample expects them at cyl 0 hd 1 sect 9 (cyl is the same as track). Since I have not yet seen the replication code, the algorithm used is unknown by me as yet. The good news is that Mr. McAfee has just released v71 and it finds the virus in the boot sector, with the ID [Muboot]. Incidently, a new addition to v71 is the ability to add a signature string from an external file a la certain MacIntosh utilities for immediate tests for new viruses. BRAVO. Happy Holidays, Padgett
CHESS@YKTVMV.BITNET (David.M.Chess) (12/05/90)
Looks to me like the MusicBug is finding sufficient unused clusters in the FAT to hold its non-boot-sector code, marking them as used (with FF's, rather than as "bad" with F7's), and writing itself there. Depending on what the FAT looks like at the time of the infection, the position of the clusters used will differ. This also means that CHKDSK will show lost clusters on an infected disk. (I haven't tested this on hard disks yet, only diskettes.) DC
REBILL02@ulkyvx.bitn (Russell E. Billings/HSCC Student Supervisor IV) (12/08/90)
I purchased a Packard Bell Pack-Mate 386X in September, so the VALERT message caused me to immediately check my system. McAfee Scan v71 claimed that both disks mentioned (ComBase and the VGA Utility) were clean. I then went into the boot sectors of both with Norton Utilities, and found the DOS error messages at Sector 0, Cylinder 0, Offset 377. At least some of the PB systems are not infected with MusicBug. Russell Billings Student Supervisor Health Sciences Computer Center University of Louisville, Louisville, Kentucky
padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) (02/23/91)
Have just had a chance to look at the February VSUM and though Patti and I discussed this, evidently the fix did not get into this month's list. In short, you do not have to do a low level format of a hard disk to remove the MBug (though it will certainly work). Earlier I posted the "better" way to remove it, but if you are familiar with the disk and do not mind boot sector patching, restoration using "SYS" is possible. Simply put, the MBug wipes the "reserved" sector value in the boot record. Since a DOS SYS command preserves this value, on boot, the system looks in the wrong place for the FAT. This makes finding the system files difficult. If the disk is a standard MFM or RLL drive, this value is hex 11 (17). Big drives are liable to use 3F (63). If in doubt, the maximum sector value (bits 0-5 of CL return from Int 13 fn 08) is a good start. No guarentees & caveat todo but might retrieve the disk. Padgett