response 76 of 205:

Apr 7 16:27 UTC 2002

Are there any good shareware file transfer programs for DOS?  Would like to
use them with a parallel not serial cable.

response 78 of 205:

Apr 8 14:17 UTC 2002

QEMM does interesting things to the video if you put it in config.sys with
too many other lines.  We found emm386/himem.exe in FreeDOS but they are said
not to work with DPMI, yet.  We are probably going back to DR-DOS, which at
least comes with complete help files.  PTS-DOS did not answer any emails yet
and they want you to download the whole 2.3M again to get a copy that does
not have a 60-sec delay.  Half of the 2.3M is a 3-year-old (obsolete) version
of Arachne.  Their download site was running at 1400 bps.

response 80 of 205:

Apr 22 19:50 UTC 2002

Machines that insist on having setup run repeatedly usually have dead
CMOS batteries.

response 82 of 205:

Apr 23 02:01 UTC 2002

The computer started to boot, checked its memory and then went back to the
beginning of boot.  Booted okay in MS-DOS.  Recognized a: c: d: (physical
entities) and e: (virtual drive).  Tried to copy from a: to d: - drive not
ready -- close door.  Jim opened it up and made sure the cable to a: was in
place, then proved he had fixed things by copying from a: to e:.  So then I
try to copy from e: to d: -- drive not read -- close door.  The hard drives
do not have doors to close.  Cannot read files on d: either, or copy from d:
to c:.  Got one very short text file to copy from a: to d: but not an .exe
file.  Tried defrag - did not work.  Tried scandisk - said bad cluster 2 in
FAT and cannot run scandisk.  Jim says this is physical damage to cluster 2
and we cannot find any way to copy these files to another drive.  If we could
copy the files we could then reformat the drive but it needs the first couple
of clusters to work.  It is 200M but it is a nice fast 200M (13 ms access time
and my 400M is 15 ms or is it ns).  Jim thinks maybe we can make a very tiny
D: partition and make the rest E: and not use D:.  

I had all my more interesting and/or complicated programs in D: because it
was faster.  Any ideas on how to get the files moved somewhere else?

We are no longer suspecting the battery but could this problem have anything
to do with the onboard controller or the CMOS?  I suppose we can try another
hard drive as we have plenty of them.  Also plenty of other computers. 
Perhaps we should not have recycled the last one but there can be too much
of a good thing.

response 84 of 205:

Apr 23 19:44 UTC 2002

We may have a new virus. ResQ mentions a Chernobyl virus.  The symptoms:

1.  Computer A (ATT) would reboot in the middle of boot, and then want to go
into setup to identify hard drives.  We recycled it and moved to computer B
(ATT).

2.  Computer B with drives C; and D: from computer A. Will not read from or
write to D:.  Scandisk says bad cluster 2 in FAT.

3. Tried to put in a different slave drive to copy C: to before running ResQ
on D:, but the computer will not autodetect either C: or D: in combination
as master/slave. It will detect either one as a Single (same jumper settings
as slave).  Tried two other drives in combination with these two and with each
other - will detect at most only the master drive, or a single.  (I am not
sure but I think after a while it would not detect master or slave when there
were two drives in together).

4.  Tried various pairs of these four drives in another computer (ComputerC)
and in setup it will not autodetect slave, master, or single drives.  Changec
controller cards with the same results.

If this is a virus, the latest version of F-PROT should hopefully be able to
get rid of it in Computer B (which does detect single drives).  Can we
download directly into C: drive or must it be run off the floppy disk if it
is getting into the MBR?  It is a 2-floppy program by now but freeware.

Which virus might this be?  It is not pre-1996.
Will reformatting and fdisk /mbr clear it from all four drives?
I would rather not lose all the programs on the original two drives,
but perhaps we can clear out the two other drives and see if they will work
together in one of the computers as master and slave.  As a test for viruses.
Will fdisk /mbr be enough on a drive without any files to remove viruses?
(We already formatted one of them and it has no files).  Can viruses get into
controller cards or motherboards??

response 86 of 205:

Apr 23 22:06 UTC 2002

Traditionally, controller cards and disk drives have their firmware in
ROM.  It's possible some might have flash memory, but this wouldn't make
much sense for a personal desktop machine (it's not that uncommon for
server type machines, where the hardware is on a support contract.) Many
newer machines store the bios in flash memory.  For these, it is indeed
theoretically possible to have a "bios" virus.  It's probably not very
likely though -- usually there is a jumper that has to be removed to
enable flashing the motherboard memory, and, and there are enough
differences in bios and hardware that writing a portable virus might be
a bit of a challenge.  386 hardware is probably old enough that this is
unlikely in any event.  So, yes, it's a *potential* problem, but it
should be near the bottom of your list of suspicions.

As a general rule, if you think you have a virus of unknown nature, and
you *really* want to get rid of it, then you should be booting off known
good removable media and reinstalling every scrap of executable code.
In practical terms, that means wiping everything out and restoring from
your last backup.  Doing a low-level format first off would certainly be
a good way to ensure the virus is gone.  Doing a DOS "format c:" isn't a
good way to eliminate a virus, as MS has gone out of their way to try to
presserve as much "useful" data as possible.  A "fdisk/mbr" should
overwrite the boot block (good) but probably won't rewrite any partition
contents or secondary boot records, so isn't guaranteed to eliminate any
viruses.  If you can boot linux from floppy, then you could do a "dd
if=/dev/zero of=/dev/wd0", which will overwrite all partition
information - and that would be a good way to eliminate viruses.  You
could also write a simple machine language program to run under dos
using debug to use bios calls to overwrite the hard disk - but this is
harder.  Or you could overwrite just selected areas of the disk using
debug itself, but this requires detailed knowlege of the disk layout.

When restoring data from your last backup, you need to be very careful
not to restore the virus too.

If you have certain knowledge of your virus, you can circumvent the
format/restore process -- usually -- but this generally means buying up
to date virus software from the right company.  Some of the smarter
modern viruses are smart enough to recognize an attempt to run the
anti-virus program, so it can be a bit of a challenge to eliminate the
virus.  In an office environment, with dozens of machines, this can
easily eat up one or more FTE's, if people aren't careful.

response 88 of 205:

Apr 23 22:40 UTC 2002

MonkeyB Virus

   The MonkeyB virus usually infects the DOS boot record of a diskette or
   the master boot record of a hard disk. When a computer is booted from
   an infected diskette (either on purpose, or accidentally) the virus
   infects the hard disk and loads into memory. When a computer is booted
   from an infected hard disk, the virus loads into memory. While in
   memory, it infects any hard disk or diskette that is used. Infected
   hard disks will be not be accessible by DOS if the computer is booted
   from a non-infected diskette.


So HOW are we supposed to access the drive to get the virus off it?

Another site says of MonkeyB that it encrypts and relocates the mBR to
0,0,3 and uses XOR 2eh to encrypt the original MBR sector.  Do NOT use
FDISK /MBR to fix this.  

(Why not?)

Marcus the Miracle-Worker (of TIFF/WORD97 fame) - how would you approach
this problem if you wanted to keep the data on the disk and did not have a
linux boot disk?

Another site said MonkeyB makes the partitions seem 2-3 times as large as
they really are.

They all say the virus will spread easily from hard drive to floppy drive
and vice versa.  Jim does not recall if he write-protected the disk that
he put into the suspicious computer.

What a waste of the nice sunny weather.

response 90 of 205:

Apr 24 00:24 UTC 2002

But we already know where the mbr has been copied to - 0,0,3.  Too bad I don't
know how to write code to move it back after deleting the encrypted version.
We have a file called something like oldmbr.bin somewhere, I think.

A chat-pal from India said to try McAfee for scanning the drives that will
autodetect but cannot be found when you boot from a floppy.  Said to try first
to boot from c: instead of a:  or boot from a bootable virus-program-disk.

Jim figured out the problem with Hard Drive 5 - his utility files came from
a floppy disk with bad clusters and therefore were not working whereas PCPlus
was working okay as it came from somewhere else.  A multitude of problems.

F-PROT claims to find and disinfect all boot sector viruses.

Marcus, how would OTHER people approach this problem, those who did not want
to write their own virus-removal programs?  Jim is attempting to boot from
a disk with a 1996 version of McAfee, the one that found MonkeyB already, and
then scan the hard drive.  'Not ready reading drive a"'.  Next floppy disk
- he says he is wearing that one out.  The next one booted and is
scanning the original problem drive (cannot copy to or from or run any
programs on it and scandisk said bad cluster 2 in FAT):  ...... no virus
(at least not MonkeyB or anything pre 1996).  Next scandisk, back later.

Along the way Jim discovered that the keyboard would not respond because it
was plugged into the wrong computer.

response 92 of 205:

Apr 24 01:22 UTC 2002

Drive 3 (autodetects but not accessible with DOS) - ran 1996 McAfee,
which said no drive was specified (it was supposed to be automatic) and that
it would check for encrypting viruses, and found MonkeyB and removed it.
Scandisk now runs on it.  This drive was used to make the boot floppy that
probably infected Drive 4 which we will do next.

So we had several unrelated problems and will end up with all virus-free disks
with no physical damage and the files are all usable.  The morals are:
reformat all hard drives and floppy disks before use (and throw out floppies
with bad sectors) or at least virus-check them, and plug all cables in all
the way.  If you don't reformat, delete hidden files.  Keep backup hard drives
of any programs that you don't want to set up over again.

Jim is doing a surface scan and went off to get two gallons of chocolate
chocolate chip (two for $6) ice cream (non-vegan) to celebrate.  Today he also
managed to move the charging circuit from one toy Jeep battery to the other
toy Jeep battery for a friend, as ordered about a year ago.  The kid was a
bit young to drive then anyway, at age 2.5.

I will learn to write virus-removal programs some other time, preferably in
some obscure operating system.

response 94 of 205:

Apr 24 07:49 UTC 2002

The most popular approach for "Other" people seems to be to buy up to
date virus software, and to have good anti-virus practices (such as not
opening random attachments sent in email, etc.)  A less popular approach
seems to be to run MacOS, Linux, or almost anything except Dos/Windows.
This is actually my approach as well - I'd rather read my mail under
Unix, and almost never use Dos.

Yet another approach seems to be to brand virus writers as mass
terrorists, and press for the most stringent criminal legislation
possible.  So far, nobody has demonstrated that this has even the
slightest affect on virus writers.

response 96 of 205:

Apr 24 15:17 UTC 2002

Jim says 'Yeah, sure, ha ha ha'.
We get our viruses not via email (I use Pine at grex) but from the various
hard drives and floppy disks that were donated to Kiwanis by people who did
not know why their computers were not working properly.  MonkeyB was on a lot
of the Kiwanis computers at one time.  Usually we check all disks before use
but we must have somehow forgotten to check one of the two hard drives here.

Turns out, in addition to the virus and the bad system file (io.sys) we
also still have a hardware problem.  The ATT still does not boot properly with
two hard drives.  It asks you to press F1 for setup and then usually refuses
to recognize either of the two drives, or sometimes it will recognize c:. 
Once in a while it will recognize them both, at which point Jim copied all
the info on both drives to the newly disinfected ones in another ATT which
DOES recognize both drives all the time.  The first one, if you press Enter
instead of F1, merrily continues with just c:.  Or you can put in just one
hard drive and it always boots fine with that, so we will save it for use as
a 1-hard-drive computer for a friend or at the building site for CAD.

Both of these computers were not keeping time at first but we must have
loosened something up as they are okay now.

A previous ATT simply stopped booting with only one hard drive.  These
computer were probably in constant use for five years before they were retired
due to problems.  Half of them were hopeless, half of the others had noisy
power supply fans or dirty floppy drives, and the rest have this sort of
problem that shows up only under hard use, intermittently.

Is it the onboard controller or the CMOS that causes an intermittent hard
drive recognition problem?

Jim can now get back to real life - he was informed that his 100' trench has
to be dug, the cable put in, and the trench filled up before Monday so they
can drive a large piece of machinery through that area to put a 30' pole at
the back of the compost heap.  Digging will be fun after two days of computer.
They said he would get 3 weeks notice.

response 98 of 205:

Apr 25 14:46 UTC 2002

The hard drives work in other computers and we tried different cables and all
the computers were at the same temperature - which leaves CMOS or controller.
We can try swapping CMOS around as we have extras.  Thanks.

I think we forgot to reformat one of the hard drives but will remember next
time.

F-PROT for DOS is free download for home use.  No need to 'invest'.

The intermittent problem with hard drive recognition occurs about 90% of the
time so should be easy to follow around if it is hardware linked.

What threw us was that we apparently had three different problems all with
sort of similar results (cannot access files on a hard drive due to virus,
bad io.sys, and bad controller/CMOS).