Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!paperboy!husc6!contact!ileaf!io!prs
From: prs@io.UUCP (Paul Schmidt)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Password program. Where ?
Message-ID: <2265@io.UUCP>
Date: 3 Nov 90 00:47:53 GMT
References: <90299.144326JFS10@psuvm.psu.edu> <1990Oct30.180312.5734@ccu.umanitoba.ca> <1990Oct31.021421.7987@uokmax.ecn.uoknor.edu>
Reply-To: prs@eng.ileaf.com (Paul Schmidt)
Organization: Interleaf, Cambridge, MA
Lines: 27

In article <1990Oct31.021421.7987@uokmax.ecn.uoknor.edu> norlin@uokmax.ecn.uoknor.edu (Norman Lin) writes:
>
>Just a thought...  if the machine in question is an AT or higher class
>machine, what about the following:  set the CMOS RAM so that it thinks the
>floppy drive isn't there.  Then it will boot from the hard drive, thus
>running whatever password or security program is needed.
>

Probably won't work. At boot time, most BIOSs go out and specifically
look for floppy drives. If they exist, and CMOS says they don't, an
error will be posted telling you to run Setup. Its a safety feature;
if your CMOS dies, you will still be able to boot your machine from
floppy disk.

Besides, unless the security program is a device driver in CONFIG.SYS,
a control-break at the right time would interrupt AUTOEXEC processing
before the security program can be run.



Now, what you _could_ do is set up floppy disks specifically for booting
that contain a hard disk driver that accesses the FAT in non-compatible
ways. You'd have to run the security program off the floppy, and enter
the right password, and so forth.

Unfortunately, that would preclude you from running applications that
access the disk directly, like various popular hard disk utilities.