Why can't I hook INT 23 in DOS?
Ben Cantrick
I've got one solution working: Just kill any keys (w/int 9) that might lead
to a ^C type of event. This works wonderfully, but it also prevents people
from using ALT-<numeric keypad> keys. They have to be blocked out so that
someone can't type ALT-3, or ALT-259, or ALT-11111 and get a C-break. Using
this approach, you also have to trap int 1b. No big deal, tho. I have a TSR
that does this very well.
My next thought was: Hey, why not just modify the DOS code that sets the
CTRL-BRK flag? But without a good refrence book on the internals of dos to
tell me where to look, I could end up tracing through IO.SYS, MSDOS.SYS,
and COMMAND.COM forever. Also, disabling ^C this way would mean I would
have to take into account all the differences in all the DOS versions and
not modify the wrong chunks of code.
Then I thought: why not just hook INT 23 and make it point to an IRET?
This is ideal! I can let them press CTRL-BRK, or CTRL-C, or ALT-<xxxx> to
their heart's content, and the keyboard handler will pass it along just
like normal. It doesn't require modifying any DOS code, so won't be specific
to any version of DOS or bug-prone like previous methods.
By hooking int 23 and making it do nothing, I can stop the program just
where I want to stop it: right before it does the actual 'breaking out.'
But it doesn't interfere with the keyboard or have to play with dangerous
DOS internals!
You knew it would be too good to be true, didn't you? ;]
Here's the problem: Using the standard DOS services for modifying
interrupt vectors, I can't modify INT 23's vector! I do something like
this:
; Load vector into DS:DX up here...
mov ax,2523
int 21
Guess what? After this, INT 23's vector is unchanged. Great...
Next ploy: Okay... I can't change where it's pointing to. Can I change the
what it points at? Answer: No, it seems I can't. I change the bytes in memory
but the next milisecond I look, they're back to what they were.
Next ploy: Try writing to the interrupt vector table myself. This can be
dangerous, but I want to make it work somehow. So hack together a little
program to make INT 23 point to the same place as int 1c. Code:
mov ax,351c ; Make int 23 point to int 1c. Usually an IRET.
int 21
xor ax,ax
mov ds,ax
cli
mov [8c],bx ; Offset of int 23's IV stored at 0000:008c.
mov [8e],es ; Segment of int 23's IV stored at 0000:008e.
sti
This works great for about a tenth of a second. Then my machine reboots...
Out of this experience come some questions:
1) Is DOS protecting INT 23?
a) If so, why is it doing so and how do I get around the protection?
2) If DOS isn't protecting INT 23, why am I having such a hard time
doing a simple hook on it?
-Ben
--
void goto_college(){ | Ben Cantrick: cant...@rtt.colorado.edu
while(credits<requirements){ | (School) or bcan...@nyx10.cs.du.edu (Nyx)
hairlength++; anime_tapes+=A_LOT;| Ben @ Altered States, Macky @ AnimeMUCK,
credits+=classes-social_life; }} | Macky @ IRC, BGC Otaku @ CU Boulder.
Glen Blankenship
> I'm trying to disable CTRL-C, CTRL-BREAK, and all derivitaves thereof.
[...]
> 2) If DOS isn't protecting INT 23, why am I having such a hard time
> doing a simple hook on it?
Because DEBUG is protecting Int 23h, so that you can use Ctrl-C/Ctrl-Break
to break out of a running program.
(This is actually just a guess, but... looking at the code you posted -
no symbolic names, no "h" on the hex numbers - I'll bet you're writing and
testing this in DEBUG or a similar debugger. The debugger is resetting
the Ctrl-C handler. Try running it outside the debugger. It should work
then.)
---
Glen Blankenship
obo...@netcom.com
g.blan...@genie.geis.com
Raymond Moon
: I'm trying to disable CTRL-C, CTRL-BREAK, and all derivitaves thereof.
[much deleted]
Ben,
I have written my own Ctrl-Break handlers. The techniques that you described
should work. DOS does not protect those interrupts, but I have seen TSRs
that do! What TSRs do you have loaded? Start removing them until the
problem goes away.
I will have to do some research, but when disabling the Ctrl-C handler, you
need to disable another interrupt so that the ^C does not appear on the
screen. I will post another followup when I find that if someone else does
not beat me to it.
Hope that is of some help.
Ray
Hanns Kucer
: You knew it would be too good to be true, didn't you? ;]
:
: Here's the problem: Using the standard DOS services for modifying
:interrupt vectors, I can't modify INT 23's vector! I do something like
:this:
:
:; Load vector into DS:DX up here...
:mov ax,2523
:int 21
:
: Guess what? After this, INT 23's vector is unchanged. Great...
[cut, cut...]
Ok, this is stupid (but could be the case, and would explain a few things):
- Are you shure that you haven't left out the 'h' required for hexadecimal numbers
(atleast in TASM [if RADIX <> 16]) ?
/Hanns
Ben Cantrick
been a great help, and I think I understand why my program is crashing
now, even if I don't know how to fix it.
In article <3bsglu$c...@dgs.dgsys.com>,
Raymond Moon <ray...@dgs.dgsys.com> wrote:
>Ben Cantrick (cant...@benji.Colorado.EDU) wrote:
>: I'm trying to disable CTRL-C, CTRL-BREAK, and all derivitaves thereof.
>
>Ben,
>I have written my own Ctrl-Break handlers. The techniques that you described
>should work. DOS does not protect those interrupts, but I have seen TSRs
>that do! What TSRs do you have loaded? Start removing them until the
>problem goes away.
Believe it or not, I'm running TSR-less. I am runing 4-dos but other than
that, nothing. I have a computer that's just about incapable of running
TSR's of any decent size. 1 meg of ram doesn't go far these days.
>I will have to do some research, but when disabling the Ctrl-C handler, you
>need to disable another interrupt so that the ^C does not appear on the
>screen. I will post another followup when I find that if someone else does
>not beat me to it.
I think the other one is INT 0x1b. INT 0x1b gets called whenever the
CTRL-BREAK key gets pressed. The CTRL-C key does not make an INT 0x1b
happen, tho. Go figure!
My problem, as a wise person told me in email, is this: INT 0x23 is not
a permanant thing. It's the error handler for whatever program happens to
be running, and every time a new program is run, INT 0x23 gets changed.
Each program handles errors in a different way, and INT 0x23 is almost
always different for the different ways each program handles it's own
errors.
Which leaves me with a puzzling delemma: how do you make sure that something
that's always changing stays the same? I suppose I could hook the timer tick
(0x1c) and re-set the vector every timer tick. That strikes me as rather
inefficient and a kludge...
Well, I suppose better a working kludge than no kludge at all. Still,
I wish there was a better way.
Charles A. Fielder
[stuff deleted]
> Which leaves me with a puzzling delemma: how do you make sure that something
>that's always changing stays the same? I suppose I could hook the timer tick
>(0x1c) and re-set the vector every timer tick. That strikes me as rather
>inefficient and a kludge...
> Well, I suppose better a working kludge than no kludge at all. Still,
>I wish there was a better way.
> -Ben
I'm just learning but I thought I heard of someone intercepting the dos
int 21. If you _can_ do this, then all you would have to do look at the
function request for Function 25h (Set Int Vector) and NOT pass it on if
they are trying to reset the vector of interest.
just a thought
--
Charles Fielder
cfie...@nmsu.edu
Dirk Flotsom
Microsoft Press 1991 (C) Microsoft Corporation....
"MS-DOS sets the current CTRL+C handler when starting a program,
copying the address of the parent program's handler to both the
vector-table entry and offset 0Eh in the new program's PSP
[A(pspControlCVector field). Although a program can change the
vector-table entry, it must not change the address in its PSP, since
MS-DOS uses this address to restore the parent program's handler."
So, it seems that it is possible to do, although I don't believe you
have to worry about restoring the vector when your code terminates.
A good reference with examples can be found in:
_ Advanced Assembly Language_, Allen L.Wyatt, Sr., Que, 1992
Good Luck!
James Vahn
> From the _MS-DOS Programmer's Reference_
> Microsoft Press 1991 (C) Microsoft Corporation....
>
> "MS-DOS sets the current CTRL+C handler when starting a program,
> copying the address of the parent program's handler to both the
> vector-table entry and offset 0Eh in the new program's PSP
> [A(pspControlCVector field). Although a program can change the
> vector-table entry, it must not change the address in its PSP, since
> MS-DOS uses this address to restore the parent program's handler."
>
> So, it seems that it is possible to do, although I don't believe you
> have to worry about restoring the vector when your code terminates.
Fooling around with this some time ago, it seemed that
Command.Com reset this vector, but only when the transient
portion was reloaded. Best to restore the vector or it may
point to invalid code, locking the machine.
--
Internet : jv...@short.circuit.com
FIDO : James Vahn 1:346/15.1
--
Steffen Kaiser
>In article <3bsglu$c...@dgs.dgsys.com>,
>Raymond Moon <ray...@dgs.dgsys.com> wrote:
>>Ben Cantrick (cant...@benji.Colorado.EDU) wrote:
>>: I'm trying to disable CTRL-C, CTRL-BREAK, and all derivitaves thereof.
[cut]
> My problem, as a wise person told me in email, is this: INT 0x23 is not
>a permanant thing. It's the error handler for whatever program happens to
>be running, and every time a new program is run, INT 0x23 gets changed.
>Each program handles errors in a different way, and INT 0x23 is almost
>always different for the different ways each program handles it's own
>errors.
That sounds strange, isn't it? But, you know, DOS is single task system,
if you do not exec another program, INT 0x23 stays unchanged.
If you write a TSR, you have to ensure, that INT 0x23 is replaced by your
^Break handler immediatly after the TSR pops up and is resetted to the
program's INT 0x23 just before returning from the TSR.
You only have to reset INT 0x23 to your own interrupt handler, but you
also have to disable ^C == ASCII 3 checking in ALL DOS functions INT 0x33.
By setting OFF, ^C is recognized by only by DOS functions 0x1..0xC.
Borland defines some functions: ctrlbreak(), setcbreak(), getcbreak().
To be very sure, nothing will happen, you must switch stdin into RAW mode,
what means setting bit 5 in Get/Set DevInfo DOS function 0x44 sub 0/1
with file handle 0 (stdin).
--
e-mail:
Steffen...@informatik.tu-chemnitz.de
mail:
Steffen Kaiser
Reichenhainerstr. 37/628
D-09126 Chemnitz