[comp.sys.ibm.pc.digest] Info-IBMPC Digest V89 #37

Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL (04/10/89)

Info-IBMPC Digest           Sun,  9 Apr 89       Volume 89 : Issue  37

Today's Editor:
         Gregory Hicks - Chinhae Korea <COMFLEACT@Taegu-EMH1.army.mil>

Today's Topics:
                Boot-time anti-viral measures (2 msgs)
                        Disk joining in MS-DOS
                         Novell info locations
                    Request for Network Information
             Floppy drive and accelerator card questions
    HDTST125.ARC - hard disk diag & low level format supports RLL
                   HELIOS, Transputer, MEIKO, Amiga
                        MAXI201 pirate warning

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

Date: Sunday, 19 March 1989  17:18-MST
From: dhesi@bsu-cs.bsu.edu (Rahul Dhesi)
Subject: Boot-time anti-viral measures

         HOW TO PROTECT YOUR MS-DOS MICROCOMPUTER FROM VIRUSES

My method is simple, and guarantees that when my system boots there is no
virus active.  It doesn't guarantee that a virus won't get activated later
when I execute a user program.

1. Always boot from a floppy disk.  Keep this floppy disk write-
protected.  A virus can do *absolutely nothing* to override a
write-protect tab on a floppy disk unless the drive is defective.  On the
boot disk, have a clean copy of the operating system copied from your
original MS-DOS distribution disk.  My CONFIG.SYS file on the floppy looks
contains this line:

   shell = c:\COMMAND.COM c:\ /e:2000 /p

This tells MS-DOS to always load the command interpreter from drive C:
from now on, so that after the boot is completed, I won't need the boot
disk in drive A: any more.  (It also increases the available environment
space at the same time, something you probably need to do anyway.)  This
didn't work properly with MS-DOS 2.x, but it does work with MS-DOS 3.x.

2.   In autoexec.bat on drive A:, I have lines like this:

     c:
     bincmp /COMMAND.COM /bin/XXXXX.COM

The first line changes the current drive to C:.  The second runs a program
that does a straight byte-by-byte comparison of the files /COMMAND.COM and
/bin/XXXXX.COM (which is just an extra copy of COMMAND.COM) and reports
any discrepancy.  It takes but an instant.  (By the way, I have changed
the names to "bincmp" and "/bin/XXXXX.COM" so no virus author can
recognize them easily and write a virus to attack them.  Even if somebody
did, I would know by simply checking to make sure XXXXX.COM had not
changed relative to COMMAND.COM on the boot disk.)

So long as the boot disk and COMMAND.COM on drive C: are not corrupted,
there is no virus active at boot time.  I don't care about the system
files (IBMDOS.COM and IBMBIO.COM) on drive C: because they are not used at
all.

If COMMAND.COM ever changes, bincmp will report an error unless the virus
was smart enough to figure out which the file /bin/XXXXX.COM was and
changed it identically, or if it was smart enough to figure out which the
bincmp program was and change that.  This is very, very unlikely.

Keeping the system immune to a virus *after* you boot is harder, since you
may execute programs that have a virus attached to them.  But if I ever
suspect something fishy is active in memory I simply have to switch the
system off and back on and I know it's not in memory any more.

P.S.  I set my switchar to -, so I can use / in pathnames.  If you don't
do this, just use \ instead in pathnames.  

-- Rahul Dhesi         
UUCP:<backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA:  dhesi@bsu-cs.bsu.edu

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

Date: 25 Mar 89 16:34:46 GMT
From: allbery@ncoast.ORG (Brandon S. Allbery)
Subject: Boot-time anti-viral measures

As quoted from <6231@bsu-cs.UUCP> by dhesi@bsu-cs.UUCP (Rahul Dhesi):
+---------------
| 2.   In autoexec.bat on drive A:, I have lines like this:
| 
|      c:
|      bincmp /COMMAND.COM /bin/XXXXX.COM
+---------------

At a small but possibly worthwhile cost in speed, both bincmp and the copy
of COMMAND.COM could be stored on the write-protected floppy, thus
insuring that they cannot be corrupted by a virus.

Also -- many Mac viruses attach themselves to applications, hook into the
running system, and attach themselves to other applications.  If any PC
viruses work the same way, they don't necessarily *need* to patch
COMMAND.COM or IBM???.COM -- they can still invade your system and
reformat your disk or etc.  Hooking into the operating system simply
insures that they're always activated at boot time -- but what if your
boot sequence runs e.g. CHKDSK, and the virus invades *that*?

++Brandon
 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser

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

Date: Sat, 25 Mar 89 17:53:27 EST
From: karn@ka9q.bellcore.com (Phil Karn)
Subject: Disk joining in MS-DOS

Does anybody know how the JOIN command in MS-DOS works? It provides a
function analogous to "mount" in UNIX, but I can't find the DOS system
calls it must be using. Nothing in the DOS Technical Reference or Ralf
Brown's excellent compendium of 8086 interrupts mentions a function
resembling this, and a quick disassembly of JOIN.EXE revealed no obviously
funny INT calls.

I've been trying to fix a bug related to join.  When you're in the
"joined" file system, a Get Disk Free Space call (DOS function 36H or
Turbo library routine getdfree) on the default drive returns the free
space for the "root" drive, not the one containing the current directory.

Phil

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

Date:     Mon, 20 Mar 89 10:22 CST
From:     <SCOTT%GACVAX1.bitnet@cunyvm.cuny.edu>
Subject:  Novell info locations

This is only a request for info (no flames, please). I've been looking for
a list related to Novell Network information. Can't seem to find anything
out there remotely like what I want. Anybody else seen anything?

Thanks,
Scott Hess

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

Date: Sat, 25 Mar 89 19:13:03 MEZ
From: e47832%trmetu.bitnet@cunyvm.cuny.edu
Subject: Request for Network Information

 I  AM A THIRD YEAR STUDENT FROM COMPUTER SCIENCE DEPARTMENT AT METU IN
TURKEY . I HAVE A PROJECT ABOUT NETWORKS AND NEED INFORMATION ABOUT IBM
NETWORKS , IF YOU HAVE SOMETHING TO TELL PLEASE HELP ME.  

THANKS..
E47832@TRMETU

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

Date: Sat, 25 Mar 89 23:05 EDT
From: <PCOEN%DRUNIVAC.BITNET@CUNYVM.CUNY.EDU>
Subject: Floppy drive and accelerator card questions

   I have a zenith z-157, and I've been thinking of expanding it a bit.
One thing I wanted to do was add two external floppy drives.  I have read
that a standard PC/XT floppy controller can hadle up to 4 floppys if a)
they are run off of two cables, "daisy chained", and b) If the drive #
jumper blocks have the correct pins jumpered.

    Can the z-157 controller (which is part of the parent board) handle
this many floppys?  Will the fact that I don't have a physical B drive (I
have a hard drive in the B slot) throw off the drive count on the jumpers?
Just exactly what is "daisy chaining" in relation to drive controller
cables?  I have yet to read an intelligable explanation of what daisy
chaining is.

    The second question involves accelerator cards, either '286 or '386.
Has anyone managed to get one to work in a z-157?  I know the Intel
Inboard '386 won't work....the machine can't handle the card for some
reason, and apparantly other cards may have similar problems.

    If anyone has any insights into either of these, please pass on any
pointers!  (I'd post this to comp.sys.zenith, except that I don't have
access to it...).  Thanks in advance.

| Paul R. Coen    
Student Operator, Drew University Academic ComputerCenter 
Bitnet: PCOEN@DRUNIVAC       
U.S. Snail:  Drew University CM Box 392, PCOEN@DREW                        
Madison, NJ 07940              

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

Date: Mon, 20 Mar 89 20:15:53 EST
From: "Leslie C. Brown" <lbrown@TBD.BRL.MIL>
Subject: HDTST125.ARC - hard disk diag & low level format supports RLL

I have uploaded the following file to Simtel20 directory
pd1:<msdos.dskutl>

HDTST125.ARC    Hard disk diag & low level format supports RLL

  This program as well as all its earlier versions will do a low level
hard disk format without data loss.  Great for changing the interleave
factor if it was set to a factor less than optimum.  Does not work with
ESDI drives.

Les

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

Date: 25 Mar 89 03:19:40 GMT
From: hubey@pilot.njin.net (Hubey)
Subject: HELIOS, Transputer, MEIKO, Amiga

I am new to netting.  Within the last few weeks, I quickly went through
all groups of interest to me.  I would like to ask for help from  all
those who can:

I have an AMiga 2000 and an Amiga 1000.  I have been reading about the
Transputer, OCCAM and HELIOS for a while in net groups, journals and
magazines .  I have some  info on where to get info on the TRansputer
machine language etc.  WHAT I REALLY WOULD LIKE IS INFO ON THE FOLLOWING:

    1)  What is the transputer---(MEIKO)--that everyone is talking about;
Is it a board, is it a commercially available computer, who makes it?  If
it is a board, on which machine??

   2)  I would like to be able to experiment with the transputer;
preferably on one of my Amigas if such a board is available.  Can I become
a beta site, alpha site??  Sooner the better.  I have been reading
articles in AMiga magazines about it and assume that it is somewhere down
the line.  Can I start without waiting for another couple of years.  I am
a Professor of Comp Sci and most of my educational background is in
Engineering.  I would not mind hacking around a bit but I don't really
have to equipment to go too deeply.

  3)  I read somewhere about a Software Test Programme--sponsored by
University of Glascow or Edinburgh--not sure which.   I am sorry to say
that I don't know exactly how to go about getting more info.

  4)  If I were to try to write a Grant Proposal to the NSF or some other
body to put together a Parallel Machine along these lines, what would I
have to buy and from where--what software etc.

I apologize for taking long but I guess I am of the impatient kind and
could not wait to read more postings to figure things out even if it would
have been more fun  8-).

Thanks in advance all those who will take the time out of their busy
schedules to enlighten me and lighten my mental load.

I prefer email to Pilot.NJIN.NET.......thank you.


H.M. Hubey 

INTERNET:   hubey@pilot.njin.net
RSN  ===>   hubey@OSultrix.montclair.edu
VOICE:      201-279-1603       
201-893-5269   Montclair State College

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

Date: Sat, 25 Mar 1989  18:15 MST
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: MAXI201 pirate warning

Forwarded from GEnie:

Item    0629854                         89/03/25        15:15
From:   MIKLOS.G                        Miklos Garamszeghy
To:     W8SDZ                           Keith Petersen
Sub:    MAXI Disk v2.01

Keith, someone has been uploading a copy of version 2.01 of MAXI Disk to
some BBS's around the US (it has been seen in Wisconsin, Texas, and Boston
so far, but may be in other places also).

This is a COMMERCIAL version of the MAXI Form program (latest v1.53) and
should NOT be on these BBS's.  Please do me a favor, and if you see it on
any of the boards that you are associated with, have it removed with an
explanation of its commercial nature to the SYSOP.

MAXIDisk can be distinguished from MAXI Form by the following features:

        MAXI Disk is a .COM file about 8k bytes long,
  while MAXI Form is an .EXE file about 40k long.

It has been seen under the name of MAXI201.ZIP but may appear under other
similar names.  It has been arced with the DOCs for MAXIForm v1.5 along
with SMAX.COM.

MAXI Disk is menu driven and MAXI Form is command line driven with a
shareware type help and signon screen.

Please pass this along to any SYSOPs on IBM boards with which you are
connected.  (also note that the version of MAXI Disk which is going around
(2.01) has a bug in it that affects some 3.5 inch drives)

Any program called MAXI.ARC or similar that is less that about 39k long
should be suspect.  It is OK to keep the shareware version on BBS's, but
obviously not the commercial version.

Thanks for your help,
Miklos G.
Herne Data Systems Ltd.

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

End of Info-IBMPC Digest
************************
-------