tcm@srhqla.UUCP (Tim Meighan) (06/22/89)
A couple weeks ago a poster wanted to know how to set up an AT so that the
AUTOEXEC.BAT could not be interrupted by a CTRL-C or CTRL-BREAK. There
have been a lot of responses, none of which actually work. There is a way
to do it, but it takes a little work and a lot of explaining. Here is what
you have to do:
First, make sure you have the following two lines somewhere in your
CONFIG.SYS file:
BREAK=OFF
DEVICE=ANSI.SYS
The BREAK=OFF line will tell DOS to check for the CTRL-BREAK interrupt only
during certain I/O function calls. (When BREAK=ON, DOS checks for break
during almost all function calls.) Even though the default for break checking
is supposedly OFF, this is good defensive programming that can't hurt. The
DEVICE=ANSI.SYS line installs a keyboard device driver that will let you turn
off the CTRL-C key (but not the CTRL-BREAK key; you have to do something else
for that, explained below.)
Next, your AUTOEXEC.BAT file must have the following as the FIRST TWO LINES:
@ECHO OFF
BRKOFF
Notice right away by the @ECHO OFF that this method requires the use of
DOS 3.3 or later. Sorry, but there is no way to prevent breaking out of
AUTOEXEC.BAT with earlier versions of DOS unless you do nasty, illegal things.
(And even then it probably wouldn't work.) The reason is simple: you can't
have any output to the screen, because as soon as you do, there is a check
for the CTRL-BREAK interrupt, and bang, AUTOEXEC.BAT is stopped cold. All
a user has to do is enter a stack of CTRL-Cs during the boot process (which
queue up in the keyboard input buffer) and the instant ECHO OFF shows up on
the screen, breakout occurs. So the ECHO OFF command itself must not get
to the screen, and the only legal way to do that is with @ECHO OFF.
The BRKOFF line runs a short COM program that does a few interesting things.
You'll have to type this program in yourself using the source listing below;
I used DEBUG and just entered it directly, although you could MASM it. What
BRKOFF.COM does is this:
1. It searches for a $CF byte occuring somewhere in the BIOS ROM
code. $CF is an 8086 IRET instruction, and you need to have
one you can point at to disable CTRL-BREAK. A good place to get
one is in the BIOS ROM; it's a safe bet that it will be there,
unchanged, forever. (Another way of doing this is to make the
program a TSR, but I avoid doing such things when I don't have to.)
2. It changes the CTRL-BREAK vector to point to the IRET instruction.
This is an easy way to make the CTRL-BREAK key stop working forever.
Note that this is NOT the BREAK-HANDLER vector; this is simply
where control is transferred when the CTRL-BREAK key is pressed.
It can be permanently changed; the BREAK-HANDLER vector cannot.
3. It changes the BREAK-HANDLER vector to point to the same IRET
instruction. This will keep any CTRL-Cs that are waiting in
the input queue from doing anything during the rest of the BRKOFF
program. We're going to need to do some output to the screen, and
this will keep us from getting busted when we do so. The break
handler vector is automatically restored by DOS when our program
terminates; in fact, we couldn't permanently change it even if we
WANTED to, which we don't. We just need to turn it off for a
while.
4. It outputs an ASCII string to the screen which re-programs
the CTRL-C key to return a plain ASCII "C" code. This will
permanently disable the CTRL-C key, even once our program
terminates and the break-handler vector is restored. Since
this is an output function call to DOS, the BREAK-HANDLER
routine will be called if the user has been hitting CTRL-C a
lot. But the BREAK-HANDLER is pointing to nothing but an IRET
instruction right now, so all that will happen is that all
CTRL-Cs will be flushed from the keyboard input queue. This
is a good thing -- we want them to go away before our program
terminates.
At this point BRKOFF.COM is done. The CTRL-BREAK is now shut off, and
CTRL-C has been changed to return a "regular" C. The remaining lines of
your AUTOEXEC.BAT can now do whatever you want, and the user will not be
able to stop it.
One other thing: don't forget to disconnect the data cable to the A drive.
This will keep someone from putting in a floppy boot disk and getting
control of the computer. BTW, when YOU want to get control of your
computer back, you can just re-connect the A drive and boot up with a
floppy.
Here's the source for BRKOFF.COM:
100 PUSH DS ;Save DS, then set pointers into BIOS ROM.
101 MOV BX,FE00
104 MOV DS,BX
106 MOV BX,2000
109 DEC BX ;Look for a $CF byte. If one is never found,
10A JZ 11D ;bail out without changing any vectors.
10C CMP BYTE PTR [BX],CF
10F JNZ 109
111 MOV DX,BX ;Found a $CF byte, so set registers to point
113 MOV AX,251B ;to it, then call DOS function $25 to change
116 INT 21 ;the vectors for interrupts $1B and $23.
118 MOV AX,2523
11B INT 21
11D POP DS ;Restore DS, then point to the ASCII string
11E MOV DX,127 ;that will turn off CTRL-C using ANSI.SYS.
121 MOV AX,09 ;Call DOS function $09 to output the string.
123 INT 21
125 INT 20 ;All done, so return to DOS.
127 DB 1B,"[3;67p$" ;This is the ASCII string to turn off CTRL-C.
We now return you to your regularly scheduled newsgroup.
Tim Meighan
SilentRadio