Very Computer

I had recently three different PCs that ended up with a
corrupt partition table. Two of them were OS/2 PCs, one was
a WfW PC. First I was not suspicious since it occured during
the Merlin installation. I installed Merlin just fine, but
after some time my spooler got messed up, command line
sessions hung, etc., so I decided to reinstall Merlin. When
I tried to reinstall it told me I did not have 35MB free
space and it started FDISK. FDISK showed an incredibly
messed up partition table. I erased all partitions created
an installable partition and continued the installation.
When the computer rebooted it could not boot. It did not
complain that there was no boot disk, it did not even try
the floppy drive. The cursor was just blinking. I tried the
install several time, the same result. I even went to back
DOS, FDISK-ed the hard drive, installed DOS, but it did not
boot. Finally I tried to install boot manager. It worked.
Although the size of the boot manager partition was 7Mbyte
instead of the 1Mbyte. This all happened on a SCSI drive.

A few days after a WfW PC crashed, it had a messed up
partition table, and after repartitioning and installing DOS
it could not boot. Same symptoms as with the OS/2 PC, but I
did not try to install OS/2.

Yesterday another OS/2 PC died, it had Warp 3 on it, and it
had an IDE drive. Same symptoms, junk in the partition
table, OS/2 or DOS can be installed but it cannot boot. I
tried boot manager at both the beginning and the end of the
free space. It did not work and the boot manager partition
was the usual 1Mbyte.

After talking to others two things are possible:

1. The sector 0 of the disks got damaged, and the SCSI disk
could recover from it since it does not store the partition
info on sector 0 alone as the IDE disks do.

2. Some virus did that.

I looked up the working mechanism of the known boot
sector/master boot record viruses. They infect the boot
record if somebody boots from an infected floppy. This was
not the case in either of the above cases. Also I do not
think that any virus, even in the boot sector can survive an
FDISK. So I am almost sure these were hardware problems, but
maybe not.

So if anybody knows about a virus that would do it please
send me an e-mail. Or if you know any other explanation.

Thanks for any help.

Gy* Vizkelethy

Both our problems are caused by inconsistencies in how different OS's see the
numbers of heads and cylinders on the disks. My story will enlighten you
about how such problems can arise, even if the source of your problems is
different.

Last summer in preparation for installing Merlin and WinNT, I spend about 2
months playing with repartitioning, and investigating how OS/2, DOS and my
BIOS handle LBA and CHS with the DOS FDISK, the OS/2 FDISK and Partition
Magic. I've got all those problems well sorted out and am using a number of
OS's without problems.

My machine is currently set up with System Commander to boot MS DOS 6.2, PD
DOS 7, Win95, OS/2 2.1, OS/2 Warp for Windows, OS/2 Warp Connect and Merlin. I
have 3 EIDE hard drives, 1 GB, 2 GB and 1 GB. I installed Merlin on an HPFS
partition on the third hard drive.

My BIOS supports 4 hard drives (ASUS Pentium 166 machine) and I've got the
first two hard drives set up with LBA in the BIOS. Since OS/2 automatically
uses LBA for HD's connected to the first disk controller (controller 0), by
configuring the BIOS to use LBA, both DOS and OS/2 see 64 heads and the same
number of cylinders for drives 0 and 1.

Due to a bug in OS/2's disk drive IBM1S506.ADD, OS/2 cannot use LBA on disks
connected to other drive controllers. Hence, I configured my third hard drive
on disk controller 1 as CHS (16 heads), which means it has cylinders beyond
1023 which only OS/2 can use. This way, both DOS and OS/2 see the drive with
16 heads, which is as consistent as it is possible to get.

I set all this up with Partition Magic, which I run in both DOS and OS/2. My
setup gives me partition tables that are consistent when seen from DOS and
OS/2. This allows me to resize and move partitions from either DOS or OS/2.
The only limitation is that I cannot work with any partitions on my third hard
drive beyond cylinder 1023 when I run Partition Magic in DOS. I can if I run
it in OS/2.

I installed Merlin in an HPFS partition that uses roughly cylinders 500 to
1023 on my third hard drive. Since the BIOS must be able to load the MBR to
boot, this partition will only boot if it doesn't not go beyond cylinder 1023.

Merlin boots and runs just fine from my third hard drive, although I did have
those "corrupted partition table" messages during the install.

Now I'll explain what I did that produced the corrupted partition table
problem.

Before the first instal of Merlin, I had done disk partitioning from Warp
Connect using OS/2's FDISK. The partitions that I had set up in advance didn't
have to be changed during the install, other than to mark one installable.
Merlin installed flawlessly, however, SWAPPER.DAT ran out of space because I
only allowed 200 MB for Merlin and I installed everything including all the
Java stuff.

All the problems occurred during my second install of Merlin. I started the
second install by booting Warp Connect, running Partition Magic, and deleting
the old Merlin partition. Then I recreated the partition and resized it to 250
MB. Then I shut down and began the second intall of Merlin.

When I got to the point where Merlin ran FDISK so I could mark the partition
installable, all the partitioning that I had done in Partition Magic was gone.
FDISK just saw a lot of empty space. That's problem #1. Something's wrong.

The failure of FDISK to see that partition suggests that the Merlin install
programs FDISK might not be seeing the drive with the same number of heads
and cylinders as Partition Magic did.

I exited the install, rebooted with Warp Connect, and repartitioned again
using FDISK. Then I reran the install. This time, when the install ran FDISK,
the partitioning I had created in Warp Connect was there. So there seems to be
a problem when the partitioning is done with Partition Magic. Maybe it has
something to do with the fact that my third hard drive is on a second disk
controller and doesn't use LBA because of the bug in IBM1S506.ADD.

Partition Magic and the Warp Connect FDISK both see all my drives with the
same numbers of heads and cylinders. But the partition tables they write
are slightly different. OS/2's FDISK has a few quirks, which Partition Magic
complains about as minor errors in the partition tables. Perhaps those OS/2
FDISK quirks are what the Merlin install FDISK likes to see in order to accept
the prexisting partitioning.

Now to continue my story. I expected the rest of the install to be a repeat of
the first, which went very smoothly. No such luck. When the time came to
reboot during the install, the two installs were very different.

During the reboot of the first install, the System Commander menu came up. I
tried to continue the install by booting off the HPFS partition where I was
installing Merlin. That gave a "non-system disk" error. Then I tried again and
booted the Boot Manager partition. THat contined the install (without the BM
menu appearing.) So the install process appears to write a new boot record in
the BM partition which is supposed to be active. When the system boots BM, it
continues the install.

During the reboot of the second install, I got the "corrupted partition table"
error message from my BIOS.

Solution: I booted DOS from a floppy disk and found that I could still access
all my hard disk partitions. My data was still there. I ran the System
Commander Reinstall program. System Commander saves backup copies of the
partition tables and boot record. It recreated the boot record and fixed the
partition tables from its backup copies.

After that I rebooted. System Commander came up. I then booted Boot Manager.
That continued the install, and everything went fine after that. Merlin is
now working fine.

Now for the explanation. The second Merlin install seems to have corrupted the
partition tables on disk 0. The best way to explain this is that when FDISK
runs during the install, it sees a different number of heads and cylinders.
If it does anything that requires rewriting the partition tables, it writes
corrupted ones.

Perhaps FDISK got confused by the fact that hard drives 0 and 1 use LBA while
drive 2 uses CHS. On the second install I made some disk partition changes
that I didn't with the first install. On the second install, the partitiion
where I was installing Merlin on drive 2 was slighly too big. I had to
recreate that partition 1 MB smaller to get it below 1024 cylinders so I could
mark it installable. That should have written new partition tables for drive
2. However, FDISK corrupted the partition tables on drive 0. Why? Perhaps
repartitioning disk 2 caused FDISK to think that all my drives were using CHS.
Maybe it "refreshed" the partition tables for drive 0 using CHS instead of LBA
when it wrote the new MBR to the BM partition that is needed for the reboot
during the install.

The most reasonable explanation of these problems is that when FDISK runs
during the install of Merlin, it sees the drive with a different number of
heads than when I partitioned it. There is a simple way to check (which I
haven't done). Boot with the install disks. Go to a command line, and then run
the text mode OS/2 version of Partition Magic. Use PARTINFO.EXE to display the
partition tables. Modify them with FDISK and use partinfo to see if they new
ones have a different number of heads.

I'm pretty sure your partition table corruption is coming from inconsistent
setups between OS/2 and your BIOS. Maybe WfW is using 32-bit disk access that
is inconsistent with DOS and that is also corrupting your partition tables.

I hope this helps.

--
------------------------------------------------------------

Department of Chemistry | compuserve: 70740,3135
University of Alberta   | ftp://hydra.chem.ualberta.ca
Edmonton AB, T6G 2G2, Canada
http://entropy.chem.ualberta.ca/faculty/clarke/home.htm

[Mailed and Posted]

)I had recently three different PCs that ended up with a
)corrupt partition table. Two of them were OS/2 PCs, one was
)a WfW PC. First I was not suspicious since it occured during

[SNIP]

)A few days after a WfW PC crashed, it had a messed up
)partition table, and after repartitioning and installing DOS

[SNIP}

)Yesterday another OS/2 PC died, it had Warp 3 on it, and it
)had an IDE drive. Same symptoms, junk in the partition

[SNIP}

)2. Some virus did that.
)
)I looked up the working mechanism of the known boot
)sector/master boot record viruses. They infect the boot
)record if somebody boots from an infected floppy. This was

See below...this is not always true.

)not the case in either of the above cases. Also I do not
)think that any virus, even in the boot sector can survive an
)FDISK. So I am almost sure these were hardware problems, but

Again see below...this also is not always true.

)maybe not.

The common thread here is a messed up partition table.  It sounds very
much like you got hit by the Monkey virus.  It resides in the Master
Boot Record and actually relocates the partition table to a different
physical location.  This is why FDISK displays junk.  Due to the
partition table being relocated FDISK is just reading random data at the
physical location it expects to find the partition table.  The monkey
virus can be transmitted to a hard drive by simply doing a DIR command
on an infected floppy (BTW, this is true for most boot sector virii).
In fact any "access" of an infected floppy can cause a boot sector virus
to be loaded into memory due to the way PC hardware works.  The first
time you access **ANY DISK OF ANY TYPE** the first thing that happens is
that the boot sector is "read" into memory to determine the size and
type of drive/disk it is.  Once the virus code is in memory it gets
written to the Master Boot Record on the hard drive(s) and from that
point on it will be written to any non-write protected diskette you
access in any way.

I would suggest that you pay a visit to either "ftp.mcafee.com" or
"www.mcafee.com" and get the latest virus scanner from there.  As of
about 6 months ago McAfee's virus scanner would detect but not remove
the Monkey virus.  However, McAfee has on their site a special utility,
written by a third party, that was designed to get rid of the Monkey
virus.  This utility has been around for about 3 years now.

)So if anybody knows about a virus that would do it please
)send me an e-mail. Or if you know any other explanation.

A few more suggestions. Create a boot disk on a known clean system with
both McAfee's Scan and the Monkey eradicator.  Write protect it and boot
up on the problem systems from this floppy and run the check.  If this
determines that you have been hit by the Monkey virus then I would
highly suggest that you check any floppy disk you have that has been in
any of the systems while in a non-write protected state because there's
a good chance some of them have been infected also.  In fact, if you do
have the Monkey virus on your hard drives, it just about had to have got
there via an infected floppy disk.

BTW, both DOS and OS/2 FDISK do **NOT** normally touch the Master Boot
Record.  Using the DOS FDISK with the /MBR parameter or the OS/2 FDISK
with the /NEWMBR parameter does rewrite the Master Boot Record.
However, this usually will not work with the Monkey virus since the
virus code is written as a physical continuation of the normal boot
sector code and is not overwritten with the /MBR or /NEWMBR parameters
to FDISK.

)Thanks for any help.

Hopefully this will be of some help to you.  I do hope I'm wrong since
being in the computer hardware service business has caused me to have to
deal with this one many times.  I can be a real nightmare.

)Gy* Vizkelethy

--
Ron McGlade - Team OS/2
EMail ID: ronmc     EMail Domain: ibm.net or primenet.com

Quote:>The common thread here is a messed up partition table.  It sounds very
>much like you got hit by the Monkey virus.  It resides in the Master
>Boot Record and actually relocates the partition table to a different
>physical location.  This is why FDISK displays junk.  Due to the
>partition table being relocated FDISK is just reading random data at
the
>physical location it expects to find the partition table.  The monkey
>virus can be transmitted to a hard drive by simply doing a DIR command
>on an infected floppy (BTW, this is true for most boot sector virii).

Quote:>In fact any "access" of an infected floppy can cause a boot sector
virus
>to be loaded into memory due to the way PC hardware works.  The first
>time you access **ANY DISK OF ANY TYPE** the first thing that happens
is
>that the boot sector is "read" into memory to determine the size and
>type of drive/disk it is.  Once the virus code is in memory it gets
>written to the Master Boot Record on the hard drive(s) and from that
>point on it will be written to any non-write protected diskette you
>access in any way.

Quote:>I would suggest that you pay a visit to either "ftp.mcafee.com" or
>"www.mcafee.com" and get the latest virus scanner from there.  As of
>about 6 months ago McAfee's virus scanner would detect but not remove
>the Monkey virus.  However, McAfee has on their site a special utility,
>written by a third party, that was designed to get rid of the Monkey
>virus.  This utility has been around for about 3 years now.

Quote:>BTW, both DOS and OS/2 FDISK do **NOT** normally touch the Master Boot
>Record.  Using the DOS FDISK with the /MBR parameter or the OS/2 FDISK
>with the /NEWMBR parameter does rewrite the Master Boot Record.
>However, this usually will not work with the Monkey virus since the
>virus code is written as a physical continuation of the normal boot
>sector code and is not overwritten with the /MBR or /NEWMBR parameters
>to FDISK.

"fdisk /mbr" will fix the problem unless the monkey virus has decided
to place itself in an extended partition table ... which is unlikely
since most computers don't even have a secondary partition table, and
because any secondary partition table is re-created if you just
re-create your partitions.

There's no way to make a virus an "extension" of the original MBR
code - if you don't change the MBR code - then your virus doesn't
get called.  The monkey virus mostlikely creates a small header
in the MBR to load whatever sectors it is keeping itself in - then
jumps to them - they in turn set up the virus's hooks (probably
hooks the floppy's interrupt so that it can throw the virus to
every disk that goes into the drive), then loads the real
partition table, a copy of what your original table was), and
jumps to it - the system then appears to boot up normally and you
never notice that the virus was there becuse nothing that the
computer does after bootup is dependent on the MBR code on disk
- it just relies on the memory copy for partition information
and that memory copy is of course the normal table.

None of this is really of any consequence to you :) Just either
run "fdisk /mbr" or get mcaffe's tools for removing the virus.

D.A.Braun
______________________________________________________________

Meridian Software

Andrew Grygus  -  California Republic
---------------------------------------
Resist Microsoft!

:>
:>
:>>No virus can infect a computer as a result of doing "dir" on a disk.
:>>The virus needs to be executed to begin it's hacov - and nothing from
:>>a floppy is executed during a "dir".  The idea that a virus could
:>>get on your computer that way is on par with the idea of an email
:>>virus. :)

Since I started that thread I think I should report how it
ended. I finally found out that on one OS/2 PC with Warp 3
it was the Monkey_b virus. I also found one diskette that
contained that virus. On my own OS/2 PC where I had a messed
up partition table I could not find the virus (installing
boot manager fixed the problem, before I thought about the
virus).

I am entirely sure, that the other OS/2 PC that was infected
by the Monkey_b virus has not been booted from floppy since
OS/2 was installed. (According to McAfee the Monkey_b
infects a system if the system is booted from an infected
diskette.) On the other hand the diskette that contained the
virus infected another PC (WfW) when the owner of the OS/2
PC was working on a co-worker's PC while his was down. That
diskette does not contain any executable file. It has only
Excel and WordPerfect files on it.

Gy* Vizkelethy

Quote:>The common thread here is a messed up partition table.  It sounds very
>much like you got hit by the Monkey virus.  It resides in the Master
>Boot Record and actually relocates the partition table to a different
>physical location.  This is why FDISK displays junk.  Due to the
>partition table being relocated FDISK is just reading random data at the
>physical location it expects to find the partition table.  The monkey
>virus can be transmitted to a hard drive by simply doing a DIR command
>on an infected floppy (BTW, this is true for most boot sector virii).
>In fact any "access" of an infected floppy can cause a boot sector virus
>to be loaded into memory due to the way PC hardware works.  The first
>time you access **ANY DISK OF ANY TYPE** the first thing that happens is
>that the boot sector is "read" into memory to determine the size and
>type of drive/disk it is.  Once the virus code is in memory it gets
>written to the Master Boot Record on the hard drive(s) and from that
>point on it will be written to any non-write protected diskette you
>access in any way.

Felix Cruz
SofTouch Systems, Inc.

Would anyone like to repair a corrupted virus ?

;-))

Hi !

--

//----------------------------------------------------------------------------
// Julien R. Pierre - 1-941-366-5355
// Developer of Digital Sound & Music Interface for OS/2 (DSMI/2)
// http://www.netsrq.com/~madbrain/        - DSMI/2 homepage
// http://www.polsci.wvu.edu/Madbrain/     - personal page
// Certified OS/2 Engineer - Multimedia Applications Developer
//
// You're throwing it all out the Windows!

: Hi !

: >Would anyone like to repair a corrupted virus ?
: >
: >;-))

: Are you talking about MS Windows ?

        There are just a very small handful of OS/2 viruses, compared to
the thousands of DOS-based virii.  I'd guess your partition table is
screwed, or you're combining 30 and 72 pin SIMMs on your motherboard.

--

TEAM OS/2                                    

 SMSB> )maybe not.

 SMSB> The common thread here is a messed up partition table.  It sounds very
 SMSB> much like you got hit by the Monkey virus.  It resides in the Master
 SMSB> Boot Record and actually relocates the partition table to a different
 SMSB> physical location.  This is why FDISK displays junk.  Due to the
 SMSB> partition table being relocated FDISK is just reading random data at the
 SMSB> physical location it expects to find the partition table.  The monkey
 SMSB> virus can be transmitted to a hard drive by simply doing a DIR command
 SMSB> on an infected floppy (BTW, this is true for most boot sector virii).
 SMSB> In fact any "access" of an infected floppy can cause a boot sector virus
 SMSB> to be loaded into memory due to the way PC hardware works.  The first

I thought the only way a boot sector virus could infect a HD was by accidentally booting to the foppy.  The virus will jump from the HD to the floppy, but cannot access the boot sector unless booted to.

GK

:  SMSB> )maybe not.
:
:  SMSB> The common thread here is a messed up partition table.  It sounds very
:  SMSB> much like you got hit by the Monkey virus.  It resides in the Master
:  SMSB> Boot Record and actually relocates the partition table to a different
:  SMSB> physical location.  This is why FDISK displays junk.  Due to the
:  SMSB> partition table being relocated FDISK is just reading random data at the
:  SMSB> physical location it expects to find the partition table.  The monkey
:  SMSB> virus can be transmitted to a hard drive by simply doing a DIR command
:  SMSB> on an infected floppy (BTW, this is true for most boot sector virii).
:  SMSB> In fact any "access" of an infected floppy can cause a boot sector virus
:  SMSB> to be loaded into memory due to the way PC hardware works.  The first

Check out http://www.uwm.edu/~gwc/os2 for a solution to the Monkey Virus
problem
:
: I thought the only way a boot sector virus could infect a HD was by
: accidentally booting to the foppy.  The virus will jump from the HD
:to the floppy, but cannot access the boot sector unless booted to.
:
Nope. I've been infected a couple of times by disks from my kids' school,
and those disks weren't bootable.

: GK

--

http://www.uwm.edu/News                                      FAX:414/229-6443

Chojnacki)5 Nov 1996 18:36:31 GMT writes:
:>
:>:  SMSB> )maybe not.

[snip]

Quote:>:

I also think that you must boot from an infected diskette to be hurt by a Boot
Sector virus. When I say boot this doesn't mean firing up any operating system
but only starting the PC with the infected diskette in A: . When you format a
diskette with the bootable attribute, then the boot sector contains the base
code that will instruct the PC to load the OS from the diskette ; if the
diskette is formatted as a non bootable diskette, the boot sector still
contains some code that is executed : the one that displays 'non system disk
or disk error' on your screen. If the diskette is infected, the code contained
in the boot sector is modified in such a way that it loads the virus before
doint its own job : the diskette can be bootable or not bootable.
But, as far as I know, the code contained in the boot block is only activated
at Boot time and not when you access the infected disk for anything else :
issuing a DIR comand or even copying a filefrom the diskette to your Hard
disk.

This is what I beleived to know, please correct me if I'm wrong. Having never
be able to find the time for writing such a beast (not sure I'll be able too
also) I cannot pretent to have an expert knowkledge of these.

writes:

Quote:>:
>: I thought the only way a boot sector virus could infect a HD was by
>: accidentally booting to the foppy.  The virus will jump from the HD
>:to the floppy, but cannot access the boot sector unless booted to.
>:
>Nope. I've been infected a couple of times by disks from my kids'
school,
>and those disks weren't bootable.

Andrew Grygus - California Republic
-----------------------------------
Resist Microsoft!

Quote:> : I thought the only way a boot sector virus could infect a HD was by
> : accidentally booting to the foppy.  The virus will jump from the HD
> :to the floppy, but cannot access the boot sector unless booted to.
> :
> Nope. I've been infected a couple of times by disks from my kids' school,
> and those disks weren't bootable.

                                Joelle Nebbe