Dec 172017
Prevent un-authorized use of your computer system. Software lock.
File SYSLOCK.ZIP from The Programmer’s Corner in
Category System Diagnostics
Prevent un-authorized use of your computer system. Software lock.
File Name File Size Zip Size Zip Type
RELOCK.ASM 6016 1937 deflated
RELOCK.COM 256 192 deflated
SYSLOCK.ASM 11776 3682 deflated
SYSLOCK.DOC 15744 5950 deflated
SYSLOCK.SYS 384 307 deflated

Download File SYSLOCK.ZIP Here

Contents of the SYSLOCK.DOC file


A Device Driver-Based Password Security System

Version 1.01, 7/10/85
All Rights Reserved: J. C. Kilday Associates, Peaks Island, ME 04108

SYSLOCK is used to discourage unauthorized use of IBM PC's and compatibles.
When the complete "system" is installed on an IBM XT, positive and absolute
protection against unauthorized use of the machine is assured. This protection
can be bypassed only by a knowlegeable intruder opening up the XT box.

Included in this package are the following files:

SYSLOCK.DOC - This documentation
SYSLOCK.ASM - Assembler source code for the security
device driver
SYSLOCK.SYS - Assembled device driver, ready to use
RELOCK.ASM - Assembler source code for companion
RELOCK.COM - Assembled companion program, ready to use

All rights to this system and its programs belong to:

J. C. Kilday Associates
Central Avenue
Peaks Island, ME 04108

You are granted a limited license to use, copy, and distribute SYSLOCK only
under the following conditions:

1) No fee is to be charged for copying and distribution

2) SYSLOCK is distributed as a complete set of files as listed
above and all files are in their original, unmodified state.

I have not had the opportunity to test this package on other than IBM PC's and
XT's. The simple, reversible hardware modification to the XT described herein
may not be possible on other machines, although the software parts of this
system will work.

I would appreciate hearing from users of SYSLOCK and would welcome any & all
suggestions for improvement, identification of bugs (Heaven forbid!), and tips
re: installation on other micros. I may be contacted at the above address, or
through messages left on FIDO #211, Wilmington, DE, 302-764-7522 (24 hrs).

Jack Kilday


The only sure way of implementing password security on an IBM PC is through
use of the device driver facilities first provided with release 2.0 of PC DOS.
Other password schemes relying on batch files to invoke them may be bypassed
by pressing Ctrl-Break as the batch file (usually AUTOEXEC.BAT) begins

Processing of the CONFIG.SYS file (if it exists) on the boot disk cannot be
prevented in the same manner. If the installation code contained in the
device drivers being installed per CONFIG.SYS disables Ctrl-Break, nothing
short of Ctrl-Alt-Del can prevent the installation routines from doing their
duty. If SYSLOCK.SYS is named first in your CONFIG.SYS file, and it exists on
the referenced disk and directory, its installation cannot be prevented at
boot time.

As it is installed, SYSLOCK.SYS requests entry of the system password and locks
up the system until the proper password has been entered. The device driver
consists of 355 bytes of code, of which 275 remain resident for possible later
access by the companion program RELOCK.COM.

SYSLOCK.SYS is designed as a dummy read-only character device driver. Its code
may be accessed by an application which opens the device and requests that a
character be read. This is how the program RELOCK.COM interfaces with it.
By typing: RELOCK the PC is locked up again, requesting entry of the
system password. One could leave the PC in this state and only someone hitting
the power switch could destroy that carefully created RAMDISK environment.
Ctrl-Alt-Del is disabled by RELOCK.COM.

Some security is thus provided for floppy-based systems and it is enhanced by
installing SYSLOCK on all boot/system diskettes.

When considering security for an XT and its data, there is need to disable the
automatic boot attempt from drive A. A method for doing this is described in
this documentation.

The remaining sections cover:



Executable forms of the 2 SYSLOCK programs are SYSLOCK.SYS and RELOCK.COM.

1. Include the following statement in your CONFIG.SYS file:


In the event you have included other device drivers this one may be
referenced first as it is not dependent on any other driver being
installed (e.g., ANSI.SYS).

2. Copy SYSLOCK.SYS to the root directory of the boot/system disk.

3. Copy RELOCK.COM to a disk/directory included in your normal PATH.

4. Reboot the system and enter the password "test" when prompted.
(You may change the password as described in the next section.)

5. Test operation of RELOCK.COM by typing: RELOCK .

That's all there is to it. Now try "breaking it".

SYSLOCK.SYS and RELOCK.COM are compatible with all application environ-
ments I could think of during testing. Use of the inter-application
communications area and user interrupts were avoided so that RELOCK
could always communicate with SYSLOCK when the DOS prompt is present.
Use of the ANSI.SYS screen and keyboard enhancement device driver also
was avoided since it is not always needed or compatible with all


If you have the Macro Assembler (or Small Assembler) the password may be
changed by making the modifications indicated in the SYSLOCK.ASM file
provided and assembling and linking as described in that listing.
Whether or not you have an assembler or work with assembler language,
you may enjoy reviewing the commented source listings of SYSLOCK.ASM and
RELOCK.ASM to see how they generally work.

Alternatively, you may easily change the password in the assembled code
of SYSLOCK.SYS. Sufficient space is reserved for a password of up to 15
characters. The password "test" may be replaced with one of your choosing
by using DEBUG, the Norton Utilities, or other "zapper". A sample session
using DEBUG is presented on the next page.


The sample DEBUG session shown below demonstrates password changes directly
to the assembled SYSLOCK.SYS device driver. The segment value ("929D") shown
in the sample probably does not correspond to what is shown by your system.
The offset values entered and displayed must be the same.

C>debug syslock.sys
-d112 121
929D:0112 04 74 65 73 74 20-20 20 20 20 20 20 20 20 .test
929D:0120 20 20
929D:0112 dbe,'constantinople'
929D:0121 ^C

-d112 121
929D:0112 0E 63 6F 6E 73 74-61 6E 74 69 6E 6F 70 6C .constantinopl
929D:0120 65 20 e
Writing 0163 bytes

The session shown above includes the following steps:

1) Type debug syslock.sys and the system responds with the
hyphen (-) prompt.

2) Type d112 121 and the system responds with the display
similar to that shown above. The first character after ...:112 is the
length of the present password (in hex). The remaining 15 characters
comprise the password space. The present password is displayed at the

3) Type a112 and after the response type db and a single
character indicating the length of your password (in hex: 1 thru 9, a,
b, c, d, e, or f). In the example, a 14-character password is being
substituted for the word "test". Now follow the length character with
a comma and single quote (,') and enter your password of no more than
15 characters. Terminate the password with another single quote ('),
press , and then -.

4) Check your work by typing d112 121 as done in the second

5) Now type w to write the modified SYSLOCK.SYS back to
disk from whence it came.

6) Type q to terminate the DEBUG session. The new
password will be effective after you next boot the system.


No password protection scheme alone can guarantee security on an IBM XT until
its attempt to boot from drive A can be circumvented. A procedure for doing
this is described here. No cutting of conductors or ROM changes are needed.
The procedure takes less than 5 minutes and can be reversed as needed.
It is applicable to an XT with one floppy disk drive and hard disk. I don't
know whether the same would apply to the AT or any other hard disk compatible.
(Would like to hear from anyone having more info on this.)

1. Remove the XT case and locate the flat ribbon signal connector to the floppy
servo board on the top of the drive. Note that a group of 6 conductors have
been twisted, approximately 6 inches away from the connector. This marks the
connector for drive A. You will find a second ribbon cable connector and
cable without such a twist. This is available for use with a 2nd drive if
installed. On a standard XT one is not, so ....

2. Make sure the power is off, remove the signal cable from the floppy drive
board and replace it with the signal cable without the twist.

3. Now locate the switch block on the XT system board. The normal settings for
a single installed floppy drive are switch 7 - ON and switch 8 - ON. Turn
switch 7 to OFF. This informs ROM BIOS that 2 floppy drives are installed.

4. Replace the XT case and turn power on.

5. After the usual memory check, you hear 2 beeps and see a "601" error report.
Also displayed is the message "(RESUME = "F1" KEY )". The system cannot find
a drive A, but we'll get around that in a moment. Press F1 and the normal
booting process is completed from drive C.

6. The system treats the installed floppy drive as drive B. In order to
restore the normal operating environment, issue the following command:


Also insert this command in your AUTOEXEC.BAT file so that normal references
to the floppy drive may be as drive A.

7. At this point your system should operate normally. However, there are some
additional considerations involving the new environment of which you should
be aware. These are discussed in the next section.

8. If you have completed all steps and have installed and tested SYSLOCK.SYS
and RELOCK.COM as described earlier, you are ready to reboot the system.

Note that you always will receive the "601" error report and be required to
press F1 to resume booting. But since you already have decided to require entry
of a password to enable booting, the inconvenience of pressing F1 before entry
of the password really is insignificant.


The hardware modifications installed per the previous section result in the
single disk drive being considered by ROM BIOS and DOS as physical drive B.
The following considerations/conditions apply:

1.Running Diagnostics - The IBM diagnostics diskette cannot be run successfully
unless the hardware modifications are reversed.

2.Use of the ASSIGN command - If any of your batch files use the this command
without drive specifiers (to restore ASSIGNments to "normal"), it must be
replaced with "ASSIGN A=B", which is the new "normal" state.

3.Diskette Formatting - DOS will not format a diskette on a drive involved
in an ASSIGN command. Thus in this new environment neither A nor B can be
used for formatting a diskette unless the following or similar technique is

(Assumes the last ASSIGN executed is ASSIGN A=B)

Create a batch file - FORMAT-A.BAT:

ASSIGN (Restores physical B = logical B)
FORMAT B: [parms] (Executes DOS FORMAT on diskette in the only floppy
ASSIGN A=B (Restores the new "normal" assignment)

4.Single drive operations - The COPY and DISKCOPY (and COMP) commands allow
execution on single drive systems operations between 2 physical diskettes.
Because we have modified the system through a switch setting now indicating a
2-drive system, the flip/flop designation of the single drive as A or B as
needed during COPY and DISKCOPY operations no longer is operational. Alter-
native means, however, are available: DISKCOPYing from floppy to a suitable
RAMDISK, copying by filename to RAMDISK or the hard disk and back to a changed
diskette. (An opportunity for some batch file creativity.)

If these differences to normal operations are too significant for your purposes
and you require a degree of security that this software can provide, I am
sure there are less easily reversed & irreversible hardware modifications
possible. As of this writing, however, I have not explored or considered any.


About 2 weeks ago I came across the first meaningful attempt, in the public
domain, to provide password security on PC's. It is a package developed by
John R. Petrocelli of Schenectady, N.Y., revised as of 4/30/85, and called
PASSWRD4. As it was represented as being device driver-based, I was quick
to download it.

I was pleasantly surprised to find that it worked well and, in the right
environment, was bug free. At about the same time, I was disappointed to
learn that my employer had spent hundreds of dollars for PC-LOCKS for
XT's and that they are grossly ineffective. That started the experimentation
which led to the hardware change I have described here. I am sure others
may already know of it, but I sure couldn't find them when I needed them.

My experiments with PASSWRD4 pointed up additional needs of such a package:
-Remove any reliance on ANSI.SYS screen enhancements. Some
applications (IRMA KEY is one) cannot get along with ANSI.SYS.
-Provide a means for RELOCKing the system through reactivation
of the device driver without using the "user" interrupt vectors
or inter-applications communications areas. Some applications
have the nasty habit of not putting things back the way they
found them.

I decided to take on the challenge of writing SYSLOCK and to dedicate it
to the downfall of those hardware vendors who are making a buck off the
ignorance of us PC users. And what better way to dedicate it than to
leave it in the public domain where I found some of the concepts it
incorporates, thanks to John Petrocelli.

Jack Kilday



Original Version - 7/7/85

Version 1.01 - 7/10/85 -Correction of RELOCK failure to properly exit
after displaying "not installed" message when
SYSLOCK.SYS device driver not installed.
-Revisions and additional info added to doc.

 December 17, 2017  Add comments

Leave a Reply