The RISKS Digest
Volume 13 Issue 13

Saturday, 8th February 1992

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

What next - pizza over UUCP?
Peter J. Scott
Re: New Caltrans AVI spec
Chris Hibbert
Re: Dutch police arrest hackers
Martin Minow
Re: Confusing Telephone System Overload Message
David Shepherd
Re: Radiation underdosages
Nancy Leveson
Re: Another Radiotherapy Error
Don Tyzuk
Re: Le Canard Enchaine
Bertrand Meyer
Charlie Mingo
VIRUS WARNING - DaVinci Discovers Michelangelo (PC)
Kenneth R. van Wyk
CERT Advisory - Michelangelo PC Virus Warning
CERT
Michelangelo & the "Fix" Utilities
A. Padgett Peterson
Info on RISKS (comp.risks)

What next - pizza over UUCP? [UUCPizza?]

Peter J. Scott <pjs@euclid.JPL.NASA.GOV>
Fri, 7 Feb 92 17:15:30 -0800
A colleague just gave me this juicy tidbit.  Seems that his brother-in-law was
with the 82nd Airborne and, upon assignment to Fort Bragg, was given an office
that had never been used.  He plugged a phone into the jack and the phone
immediately rang.  No, it wasn't telemarketers; he was greeted with a modem
tone instead.  Hung up.  Phone immediately rang again.  This repeated 24 hours
a day until the Army put a trace on the call.  The trace led to, get this, a
Coca-Cola machine.  The manufacturer had built into these vending machines the
capability to call the bottling company when they were getting low on supplies
and order more.

Unfortunately for my friend's brother-in-law, the bottling company that owned
this machine in particular wasn't interested in this option, so they didn't
change the default telephone number that was programmed into the machine, and
which was happened to be set to, you guessed it, the office at Fort Bragg.

The Army cut the telephone cable on the Coke machine.  (I guess they weren't
armed at the time.)  This brand of vending machine also has the capability of
signalling via modem that it was out of change, full up on money, or had been
broken into ("Help, I've fallen over and I can't get up...").
                                              [Not high enough on Coke?  PGN]

I suppose modern machines just use FDDI.  Maybe PGN could add a few candy
machines to the RISKS distribution?

Peter J. Scott, Member of Technical Staff    |   pjs@euclid.jpl.nasa.gov
Jet Propulsion Laboratory,  NASA/Caltech     |   SPAN:  GROUCH::PJS

  [The RISKS archives remind us of an earlier episode with Coke machines,
  reported 15 Jan 1985 in the Washington Post, describing a business
  from which hundreds of phone calls were billed mysteriously nights and
  weekends even though no one was in the building.  Yes, their Coke machine
  was trying to phone home.  See ACM Software Engineering Notes, vol, 10, no
  2, April 1985, p.8, four months before we started the on-line RISKS!  By the
  way, the latest SEN RISKS index is in the January 1992 SEN issue, just out.
  The New Orleans SIGSOFT '91 Proceedings are in the December issue.  PGN]


Re: New Caltrans AVI spec (Agre, RISKS-13.09)

<xanadu!hibbert@uunet.UU.NET>
Fri, 7 Feb 92 18:21:44 PST
I also received a revision of the specification for Automatic Vehicle
Identification (AVI) equipment that Phil Agre talked about in Risks 13.09, and
that I've talked about here before.  I'm much happier than Phil was with the
new draft.  It still has lots of problems, not the least of them the lack of
attention to security.  However, they've done just what I wanted on the subject
of privacy.

I testified before a CalTrans hearing in October on the spec, and a state
Senate Judiciary Committee hearing on Privacy in December, and it appears that
my message got through.  The new draft doesn't leave room for an identifier of
the vehicle or the driver in the communication packets.  At the hearing in
December, Senator Bill Lockyer, the chair of the committee, made it clear to
the head of CalTrans and to Les Kubel, who is responsible for collecting
comments, that they were going to support anonymity in their system.  That's a
major victory.

On to the rest of the spec.  First, it won't be easy to forward a copy of the
spec via EMail.  The current draft is presented as a marked-up copy of the
previous ones, even though it has changed massively.  All deletions are
presented with strike-through, insertions have double-underline, and all
unchanged text has a single underline.  Besides making it very difficult to
read, this also means that a scanner isn't going to be able to figure it out.
Oh well.

Phil misinterpreted some of the spec in his message, and asked some questions
that I can answer.

    From: pagre@weber.ucsd.edu (Phil Agre)

    the state envisages attaching [the box] to your car that
    broadcasts your car's vehicle identification number (VIN)
    when pinged by a roadsite transmitter.

They aren't going to use VIN.  The spec mentions a Reader ID number which is a
32 bit field that would identify the reader unit.  This is as opposed to the
first version, which said VIN, and the second that said "Character-based ID,
identifying the vehicle.

   would it be necessary for every car on the road to have one of these
   transmitters.

All the CalTrans folk and vendors I've talked to say that there's no need for
every car to have one in order to collect tolls.  Some are willing to say that
they expect "other forces" (maybe DEA or INS?) to try to make this kind of
equipment usable for tracing people's movements.  There may have been attempts
to make this be standard equipment on new cars.  Lockyer appeared to say that
the California AVI spec had better not support this "feature".

    Caltrans has generalized the proposal; the "AVI" equipment
    is no longer specifically aimed at toll collection but is
    now intended to support a much wider range of applications.

I'll have to look at the old spec, to figure out why, but I always
understood this to be the intent.  I specifically remember that the
previous version said that more packet types could be added later to
serve other purposes.

    I cannot understand how automatic toll collection could
    work unless every car has a transponder.

The spec doesn't talk about it because it's not part of the technology being
designed.  The following is my guess, based on how I'd build such a system.
For corroboration, we should ask someone who uses the existing systems in
Dallas, New Orleans, or elsewhere what their systems do.  I would expect any
such (toll-collection) system to be prepared for vehicles without a
transponder.  Some vehicles will be from out of state, some batteries will die.
So, you just have cash lanes.  This also allows you to take care of the cars
with boxes that have run out of credit: As you approach the toll point, a
sensor queries your box to find out how your balance stands.  If your account
is low, you see an overhead sign directing you to use the cash lane.

This doesn't make it possible to collect tolls every half-mile, but it's fully
capable of supporting toll roads like the ones we currently have, or private
toll roads, which could be limited to vehicles which had the units.

Phil is right, however that there are lots of other issues which are left
unaddressed by the spec.  The folks at CalTrans aren't interested in listening
to these, so you might as well address them to your state congresscritter.
There's a new draft with a new deadline of February 28, so if you want a copy
or to comment on the spec itself, write to:

       Les Kubel, Chief
       Office of Electrical and Electronics Engineering
       Department of New Technology, Materials and Research
       PO Box 19128
       Sacramento, California  95819-0128

Chris


Re: Dutch police arrest hackers (RISKS-13.11)

Martin Minow <minow@ranger.enet.dec.com>
Fri, 7 Feb 92 17:54:12 PST
I must strongly disagree with the following comment in the discussion
of the damages caused by the Dutch hacker's break-ins:

>If restoring back-ups costs tens of thousands of guilders, something is
>terribly wrong at the VU. Every system manager that uses a legal copy of the
>operating system has a distribution version within easy reach.

Rebuilding the operating system for a small workstation takes at least
a half-day. Re-editing all site-specific files, such as pasword files,
network host tables, mail aliases, and all site-specific privileged
files will certainly take several more days. For a large site with
networked disks and distributed resources, the cleanup must extend to
all other systems that the transgressors may have reached. This is
a difficult and non-trivial task.

Please do not assume that I agree with other statements in the article.

Martin Minow  minow@ranger.enet.dec.com


Re: Confusing Telephone System Overload Message (McCulley, RISKS-13.09)

David Shepherd <des@inmos.com>
Fri, 7 Feb 92 10:51:30 GMT
Here in the UK the BBC had a quiz on a Saturday night show - during the show
they asked a simple question and you phoned in the answer and a randomly
selected person with the correct answer was phoned back at the end and told
what prize a "celebrity" had won for then (the quotes are due to the fact the
the first "celebrity" was Eddie the Eagle - the UK's famously bad ski-jumper).
The next week British Telecom announced that during the show 1.25 million calls
had been attempted on the line, but only 7,000 had been answered by the BBC!

In the past the BBC have had phone polls e.g. on capital punishment
when that was  being debated in parliament, and people complained that
the 50-50 result was due to the capacity of the phone system and not
public opinion as both lines seem to have become overloaded.

david shepherd: des@inmos.co.uk or des@inmos.com    tel: 0454-616616 x 625
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq


Radiation underdosages

<leveson@cs.washington.edu>
Sat, 08 Feb 92 16:03:53 -0800
Does anyone have any other information about this than the newspaper article?
The account in the Independent doesn't make it sound like it was a computer
error although the article appears to blame the computer.

      The following article about faulty computer control of radiotherapy
      treatment is reprinted in its entirety ...

      A computer programming error meant that ...

But it later says that:

      The physicist who made the mistake by introducing an unnecessary
      correction factor when a new planning computer was installed in 1982 ...

Medical physicists compute the dosage to be given to the patient (using
physicians instructions about desired treatment).  If the physicist did not
know how to compute a proper dosage, it does not matter whether the computation
was done by hand, on a calculator, or by a computer.  It seems strange to blame
this on a programming error.  Did the physicist really do the programming?  Was
there treatment planning software already installed on the computer and the
physicist just entered some factors (i.e., data)?  If the programmer was told
by an expert to implement a particular formula that is incorrect, how could
this error ever be found by testing or any other method that involved software
engineering techniques? If a person drives a car into a fence, is it reasonable
to blame the car?

This is not at all related to what happened with the Therac-25.
                                                                     nancy


Re: Another Radiotherapy Error

Don Tyzuk <841613t@aucs.acadiau.ca>
Sat, 8 Feb 1992 13:54:18 GMT
With regard to computer risks in general:

I think it is time to establish licensing of software engineers, and that there
should be an independant review body for such critical software of the sort
that we literally place our lives directly in its care.

Many programmers of such systems have no knowledge whatsoever of the techniques
of reliable programming. They were the scientist, or expert, or whatever on the
object under software control, and were chosen to write the program because
they could hack out something that worked.

Consequently, they turn out spaghetti. Do you want your child to be the next
Therac victim?

The moniker "software engineer" is used a little loosley, for my mind. I think
there is a place for real software enginners, with the education in applied
science that it implies.

A program (5 years in Nova Scotia) of
    2 years of applied science
    3 years of software science
    professional experience.
    comprehensive examinations.
    membership in a professional society of engineers.
    a provincial license.
    a review committee.

No, I am not an engineer.

Donald Tyzuk     Wolfville, Nova Scotia   841613t@aucs.acadiau.ca


Le Canard Enchaine

Bertrand Meyer @ Interactive Software Engineering Inc. <bertrand@eiffel.com>
Sat, 8 Feb 92 12:55:21 PST
> By coincidence, it was written by a certain Jerome Canard (and no jokes about
> his brother Donald, please! :-).     <It's an old canard, anyway. PGN>

Of course not a coincidence. As every reader of Le Canard
knows, ``Jerome Canard'' is a pseudonym. The choice of pseudonym
indicates that articles with this signature are probably written by
the editor-in-chief, or at least a quite senior editor.

> [Anyone know exactly which region the "Hexagon" is?]

Please think for half a second, or look at a map.  ``The Hexagon'' means
France.  It's a term favored by bureaucrats and journalists. (``Today, at the
four corners of the Hexagon, ...'' is a famous parody of technocratic style.)

``Le Point'' is one the four major weekly news magazines. (The others are Le
Nouvel Observateur, L'Express and L'Evenement du Jeudi.)
                                                            Bertrand Meyer
  [Also noted by Martin Minow  <minow@ranger.enet.dec.com>]


Re: Strasbourg A320: Duck Writes in Duck

Charlie Mingo <Charlie.Mingo@p0.f70.n109.z1.fidonet.org>
08 Feb 92 13:01:31
[...] The term came into use in the 1960's after the loss of Algeria had
blurred the French sense of where their borders lay.  (Not too long ago, France
included much of Africa and the Middle East, along with bits of the Caribbean,
Latin America and Pacific Oceana.)

    The term is the French equivalent of "the lower 48" in the US.


VIRUS WARNING - DaVinci Discovers Michelangelo (PC) [VIRUS-L V5 #21]

"The Moderator Kenneth R. van Wyk" <krvw@CERT.SEI.CMU.EDU>
Tue, 4 Feb 1992 09:40:50 EST
VIRUS-L Digest   Tuesday,  4 Feb 1992    Volume 5 : Issue 21

Date:    Tue, 04 Feb 92 08:22:01 -0500
From:    "Kenneth R. van Wyk" <krvw@cert.sei.cmu.edu>
Subject: VIRUS WARNING - DaVinci Discovers Michelangelo (PC)

[Moderator's note: I received the following press release by FAX.  Any typos
are no doubt mine, not DaVinci's.  krvw]

News Release

DaVinci Systems Corporation, P.O. Box 17449, Raleigh, North Carolina 27619
Tel: (919) 881-4320   Fax: (919) 787-3550

Contact: Chris Evans, Vice President of Marketing, DaVinci Systems Corporation,
(919) 881-4320

         DaVinci Discovers Michelangelo Virus
          Warns users of possible infection

RALEIGH, North Carolina, February 1, 1992 - DaVinci Systems announced today
that a recent shipment of eMAIL 2.0 demonstration disks and 30-day kits may be
infected with a computer virus known as Michelangelo.  Approximately 900
customers and potential customers were sent the infected disks.  Of these, over
600 were DaVinci resellers.

DaVinci Systems immediately notified its resellers of the problem via
electronic mail and will mail a new set of disks to all recipients of the
infected disks by February 6th.  DaVinci Systems also advises anyone who has
received a DaVinci eMAIL 2.0 demo disk or 30-day kit between January 20, 1992
and January 31st, 1992 not to use the disks they received.

According to Bill Nussey, President of DaVinci Systems, "While there is only a
slim chance of one of our customers contracting the Michelangelo virus from
these disks, we wanted to take every possible precaution."

The Michelangelo virus sits passively on infected machines until March 6th
(Michelangelo's Birthday) when it corrupts data on a user's hard disk.
FORTUNATELY, THE VIRUS CAN ONLY BE CONTRACTED BY BOOTING UP AN INFECTED FLOPPY.
Because the infected disks are not bootable, most users who have received these
diskettes will not contract the virus on their machine even if they run the
demo or install the software on their hard disks.  The only way users could
catch the virus from an infected disk is if they inadvertently boot up their
computers with the infected floppy in driver A while the drive door is closed.

DaVinci officials are still investigating the source of the virus.  Although
DaVinci's master disks are routinely checked for viruses, the virus software
used apparently did not detect Michelangelo.  "We are now using multiple
virus-detection products and insisting that our duplicating contractors also
check for viruses", said Nussey.

The Michelangelo virus can be detected by Microcom's Virex version 2.l1 or later
or by McAfee Associates shareware program VIRUSCAN version 7.9v84 or later.
DaVinci users and resellers can download VIRUSCAN from DaVinci's BBS at (919)
881-4342.

Based in Raleigh, North Carolina, DaVinci Systems Corporation is the leading
independent supplier of LAN-based electronic mail applications.  The company's
products run under acknowledged personal computer network and operating system
standards such as MS-DOS, Microsoft Windows, and Novell Netware.  DaVinci
Systems is at P.O. Box 17449, Raleigh NC 27619.  Telephone (919) 881-4320,
(800) DAVINCI.  FAX: (919) 787-3550.

The product names and trademarks referenced are the trademarks or
registered trademarks of their respective companies.


CERT Advisory - Michelangelo PC Virus Warning

CERT Advisory <cert-advisory-request@cert.sei.cmu.edu>
Thu, 6 Feb 92 15:57:37 EST
CA-92:02                        CERT Advisory
                  February 6, 1992
                         Michelangelo PC Virus Warning

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a personal computer virus known as
Michelangelo.  The virus affects IBM PCs and compatibles.  A description
of the virus, along with suggested countermeasures, is presented below.

I.   Description

     The Michelangelo virus is a computer virus that affects PCs
     running MS-DOS (and PC-DOS, DR-DOS, etc.) versions 2.xx and
     higher.  Note, however, that although the virus can only execute
     on PCs running these versions of DOS, it can infect and damage PC
     hard disks containing other PC operating systems including UNIX,
     OS/2, and Novell.  Thus, booting an infected DOS floppy disk on
     a PC that has, for example, UNIX on the hard disk would infect
     the hard disk and would probably prevent the UNIX disk from
     booting.  The virus infects floppy disk boot sectors and hard
     disk master boot records (MBRs).  When the user boots from an
     infected floppy disk, the virus installs itself in memory and
     infects the partition table of the first hard disk (if found).
     Once the virus is installed, it will infect any floppy disk that
     the user accesses.

     Some possible, though not conclusive, symptoms of the
     Michelangelo virus include a reduction in free/total memory by
     2048 bytes, and some floppy disks that become unusable or display
     "odd" graphic characters during "DIR" commands.  Additionally,
     integrity management products should report that the MBR has been
     altered.

     Note that the Michelangelo virus does not display any messages on
     the PC screen at any time.

II.  Impact

     The Michelangelo virus triggers on any March 6.  On that date,
     the virus overwrites critical system data, including boot and
     file allocation table (FAT) records, on the boot disk (floppy or
     hard), rendering the disk unusable.  Recovering user data from a
     disk damaged by the Michelangelo virus will be very difficult.

III. Solution

     Many versions of anti-virus software released after approximately
     October 1991 will detect and/or remove the Michelangelo virus.
     This includes numerous commercial, shareware, and freeware
     software packages.  Since this virus was first detected around
     the middle of 1991 (after March 6, 1991), it is crucial to use
     current versions of these products, particularly those products
     that search systems for known viruses.

     The CERT/CC has not formally reviewed, evaluated, or endorsed any
     of the anti-virus products.  While some older anti-virus products
     may detect this virus, the CERT/CC strongly suggests that sites
     verify with their anti-virus product vendors that their product
     will detect and eradicate the Michelangelo virus.

     The CERT/CC advises that all sites test for the presence of this
     virus before March 6, which is the trigger date.  If an infection
     is discovered, it is essential that the user examine all floppy
     disks that may have come in contact with an infected machine.

     As always, the CERT/CC strongly urges all sites to maintain good
     backup procedures.

The CERT/CC wishes to thank for their assistance: Mr. Christoph Fischer of the
Micro-BIT Virus Center (Germany), Dr. Klaus Brunnstein of the Virus Test Center
(Germany), Mr. A. Padgett Peterson, P.E., of the Technical Computing Center at
Martin-Marietta Corp., and Mr. Steve R. White of IBM's Thomas J. Watson
Research Center.

If you believe that your system has been compromised, contact CERT/CC or your
representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC), Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).


Michelangelo & the "Fix" Utilities - free through March 6th

A. Padgett Peterson <padgett%tccslr.dnet@uvs1.orl.mmc.com>
Fri, 7 Feb 92 09:37:29 -0500
     This virus has really surprised me. When I first say it, my thought was
"yet another STONED" (and not as well written), but it seems to be spreading &
spreading & spreading...  If Rob Slade's estimate is right, for every report we
see, there are at least three other infected computers that we don't. March 6th
may just be interesting.

     Some time ago I did a number of experiments concerning boot sectors in
general since we seemed to have good protection from DOS viruses but few people
were working at the BIOS level before DOS ever starts. IMHO, since over 50% of
the reported infections begin at the BIOS level, then that is where the
checking should start.  The first experiments (written in 1988) were a set of
integrity checking programs, two of which were CHKMEM and CHKBOOT (now
FREEWARE) that could be used to detect all "common" viruses - I presented a
paper on this at last year's Virus & Security Conference in New York (March 12
& 13 this year call (800)835- 2246 x190 for info - plug).

     These operate from the DOS level. About two years ago, I began studying a
BIOS level approach - at this point the Intel PC is a fully functioning
computer with access to all peripherals, it is just not yet a DOS (or Unix or
OS/2 or...) computer.

     The first result was the DISKSECURE program that was designed as a
technology demonstrator & performed BIOS level integrity checking and
protection of the MBR, hidden sectors, and DOS boot record.  Many researchers
seem to like it as an additional layer of protection.

     DISKSECURE's biggest limitation was that it could do nothing about a
floppy boot (only hardware can prevent this) and I was and am convinced that a
global solution had to be software based - not for technical reasons but for
logistical and economic ones.

     The next effort was SafeMBR - a BIOS level Master Boot Record replacement
that performed integrity checking on the system and which would halt a boot if
"something" was wrong and used lessons learned in DISKSECURE to avoid conflicts
with the incredible array of disk controllers, BIOSes, and DOS variants that
exist. SafeMBR is FREEWARE.

     Late in 1991, I extended the SafeMBR concepts to a similar floppy disk
replacement SafeFBR to provide a generic floppy disk boot record replacement
with warning messages.

     Concurrently with SafeMBR, I addressed the "floppy boot" problem as far as
possible with software, a TSR (512 bytes needed & can be loaded "high") was
written to intercept the Ctrl-Alt-Del sequence and test for a floppy in drive
A. If one is found, the reboot is denied. This taught me more about the inner
workings of the BIOS and the Interrupt Controller. NoFBoot was the result and
is also FREEWARE.

     The final parts FixMBR and FixFBR were extensions of this concept used to
install SafeFBR and SafeMBR. FixMBR came from hours spent disinfecting machines
infected by MBR viruses and was designed to automate the repair based on the
fact that ALL leave an intact partition table SOMEWHERE. Given an intact
partition table, all that is usually necessary is to replace the MBR program.
Generally I use the SafeMBR code to do this.

     For some time, I was hesitant to release these techniques but then along
came the Azusa virus...

     FixFBR works essentially the same way except that only four Boot Parameter
Blocks are needed (does not work with 2.88 Mb floppies yet). Since it also
incorporates the CHKBOOT techniques, it will also flag potentially infected
disks.

     This last is the key to the concept. None of these programs (well maybe
NoFBoot) will prevent a virus infection.  What they will do is to detect
viruses almost immediately.  Flag the "anomaly" in a way the user cannot
ignore, and provide a recovery mechanism. They do not "identify 1000 viruses"
but will tell you that "something" has happened at the BIOS level without going
resident.  They are designed as one layer in a layered protection (I use four
layers myself).

     Similarly, either CHKBOOT or FixFBR will detect the Michelangelo virus on
floppy disks and report them as "suspect".  FixFBR will then remove the
problem.

     To me this is a vital element in fighting malicious software, knowing
early on that "something" has happened and isolating the abnormality to as
narrow range.  I personally believe that if these techniques were used
globally, those viruses responsible for over half of reported infections:
Stoned, Azusa, Aircop, Brain, Joshi, & Michelangelo would quickly disappear.

     But today there appears to be a very real threat: Michelangelo that needs
to be addressed. I have never seen so many reports of a virus in so short a
time before and am particularly disturbed about the number of "shrink-wrapped"
reports.  Consequentially, while normally I "suggest" a nominal SHAREWARE fee
($1.00) for the two "FIX" utilities, from now until 7 March, 1992, payment
requirements are suspended and they may be freely used, posted, & transmitted
without limitation so long as they are not modified.
                                                           Padgett
               padgett%tccslr.dnet@mmc.com

PS: I know that the current version of these programs is in FIXUTIL2.ZIP and
may be found in directory msdos.antivirus at urvax.urich.edu (141.166.1.6 -
thanks Claude).

Note: this is my hobby, my employer has nothing to do with this.

    Programs in FIXUTIL2.ZIP

    Length  CRC-32    Name
    ------  ------    ----
      1331  449b4371  CHKMEM.COM
      2189  2753290a  FIXFBR.EXE
       368  72b99d29  SUMFBOOT.COM
      1357  77936de4  CHKBOOT.EXE
      2219  332bf466  FIXMBR.EXE
      4885  3e04a29b  FIXFBR1A.DOC
       749  3f347828  CHKSMBR.EXE
       368  cccf71a5  NOFBOOT.COM
      2602  63f3d358  NOFBOOT.DOC
      4461  a1408395  CHK.DOC
       366  4c0e9c20  VALIDATE.24
     26118  8138037e  FIXMBR24.DOC
     ------            -------
         47013            12 files

Please report problems with the web pages to the maintainer

x
Top