Groups > comp.os.msdos.programmer > #722 > unrolled thread

INT 09h hooking issues

Started by	jacks <jacks.1785@gmail.com>
First post	2012-08-08 07:52 -0700
Last post	2012-08-10 04:27 -0400
Articles	2 on this page of 22 — 5 participants

Back to article view | Back to comp.os.msdos.programmer

  INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-08 07:52 -0700
    Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-08 20:49 -0400
      Re: INT 09h hooking issues pete@nospam.demon.co.uk - 2012-08-09 05:32 +0000
        Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-09 04:39 -0400
          Re: INT 09h hooking issues Bogus@Embarq.com (Steve) - 2012-08-09 11:44 +0000
            Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-09 20:09 -0400
              Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-09 23:20 -0700
                Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-10 04:26 -0400
                  Re: INT 09h hooking issues Bogus@Embarq.com (Steve) - 2012-08-10 12:08 +0000
                  Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-11 23:10 -0700
                    Re: INT 09h hooking issues pete@nospam.demon.co.uk - 2012-08-12 07:18 +0000
                      Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-12 04:29 -0400
                        Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-14 05:40 -0700
                          Re: INT 09h hooking issues Jim Leonard <MobyGamer@gmail.com> - 2012-08-14 08:29 -0700
                            Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-15 20:14 -0700
                      Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-14 05:30 -0700
                    Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-12 04:01 -0400
          Re: INT 09h hooking issues pete@nospam.demon.co.uk - 2012-08-10 05:27 +0000
        Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-09 08:41 -0700
          Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-09 19:54 -0400
            Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-10 00:11 -0700
              Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-10 04:27 -0400

Page 2 of 2 — ← Prev page 1 [2]

#732

From	jacks <jacks.1785@gmail.com>
Date	2012-08-10 00:11 -0700
Message-ID	<fc763401-96c1-4cf4-bb1d-d4bb8afa3aa7@googlegroups.com>
In reply to	#728

On Friday, 10 August 2012 05:24:33 UTC+5:30, Rod Pemberton  wrote:
> "jacks"  wrote in message
> 
> news:2878c8f7-9cbc-4f80-b7c1-b14216e7f52a@googlegroups.com...
> 
> ...
> 
> 
> 
> > Basically, I want to intercept, PAUSE key and CTRL + ALT + DEL sequence.
> 
> >
> 
> 
> 
> CTRL + C
> 
> CTRL + BREAK
> 
> CTRL + \
> 
> CTRL + S
> 
> CTRL + Q
> 
> SCROLL-LOCK
> 
> ALT + SYSRQ
> 
> PRINT-SCREEN
> 
> CTRL + Z
> 
> CTRL + M
> 
> CTRL + D
> 
> SHIFT + ENTER
> 
> 
> 
> These do various things, but can all break or halt execution too ...  Some
> 
> are for DOS while others are for C compilers, etc.
> 
> 
> 
> > IOWs, in my application the user must not be able to pause the code
> 
> > execution, and must not be able to reboot the system, while application
> 
> > is running.
> 
> 
> 
> Why?  That seems really dangerous ...
> 
> 
> 
> E.g., if you've written a program that simply redirects text to a file while
> 
> searching for a text terminator and it doesn't find it, then you must turn
> 
> off the power switch or the program will fill your entire harddrive.
> 
> Depending on the program, it might overwrite your entire harddrive.
> 
> 
> 
> Personally, I don't use PAUSE much, but I do use CTRL-S and CTRL-Q to
> 
> pause large disassembly listings.  Although, I don't use that as much
> 
> anymore, since DJGPP provides LESS.
> 
> 
> 
> I definately *DO NOT* want CTRL-ALT-DEL blocked for any reason.
> 
> Even though flipping off the power switch takes a hair longer now than it
> 
> once did, although it's still within arm's reach ...  I also don't like to
> 
> see "run-away" networking traffic either, which is why the lock tab on my
> 
> ethernet cable is intentionally removed, i.e., quickly pulled out.
> 
> I.e., if I attempted CTRL-ALT-DEL with your application and it didn't work,
> 
> it's getting deleted.
> 
> 
> 
> DOS saves the Control-Break handler address (Int 23h) and Critical Error
> 
> handler (Int 24h) in an app's PSP.  They can be modified.  I seem to recall
> 
> DJGPP having functions for these, but not OpenWatcom...
> 
> 
> 
> DJGPP has functions to install your own Ctrl-C handler.  OpenWatcom has
> 
> functions to disable or enable Ctrl-C.
> 
> 
> 
> If you must lockout interruptions, e.g., directly accessing hardware, then
> 
> use the CLI and STI instructions.  Both DJGPP and OpenWatcom have C
> 
> functions for these.  IIRC, OW's function also set or cleared the direction
> 
> flag for proper use with their library.  So, it's recommended you use the C
> 
> function in C code even though you could use inline assembly.  CLI won't
> 
> block NMIs (some hardware) or cpu exceptions (or software interrupts).
> 
> NMIs requires a special sequence written to CMOS to disable.
> 
> 
> 
> > The default scan code set after POST is set#1. I didn't modify that via
> 
> > keyboard controller.
> 
> >
> 
> 
> 
> Set #1 is generated by XT keyboards.
> 
> Set #2 is generated by AT keyboards.
> 
> Set #3 is generated by PS/2 keyboards.
> 
> 
> 
> Is this for an original IBM PC XT?  XT keyboards generate Set #1 directly.
> 
> If you have a switch selectable XT/AT keyboard set to XT, then it'll
> 
> generate Set #1 directly too.  Of course, only an XT will recognize the key
> 
> sequences from Set #1 correctly.
> 
> 
> 
> Otherwise, for IBM PC ATs and all modern compatibles, what's used by default
> 
> is Set #2 (AT keyboard) with AT to XT translation.  (Sorry, I said "XT to
> 
> AT" earlier...).  The AT keyboard generates Set #2.  The AT set is then
> 
> translated back to Set #1 (XT keyboard) on the motherboard by the keyboard
> 
> controller (8042 chip or equivalent).  The keycodes are the same:
> 
> 
> 
> Scancode chart:
> 
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.6
> 
> 
> 
> Brief history of why:
> 
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.1
> 
> 
> 
> A operating system can program which scanset it wants and whether to use
> 
> translation or not.  It should match the keyboard set, with or without
> 
> translation.  Unfortunately, OS developer's found that there were various
> 
> problems with using non-translated Set #2 and non-translated Set #3.  This
> 
> is probably mentioned on Andries Brouwer's pages somewhere.
> 
> 
> 
> 
> 
> Rod Pemberton

Hi, yes this is with AT to XT translation, so that by default, the IRQ1 handler will get scan code set#1 scan codes when it read port 60h.

I do agree with Rod, in what he said about not disabling reboot and pause, but I have my own reasons to do this.

The application is to be used roughly, ie by non-techie guys. What if somebody put a notebook/book etc. on right most part of the keyboard, while application is running?

In earlier keyboards, there was not Right CTRL and Right ALT keys and the distance b/w DEL key and left CTRL + left ALT keys is much large, so that it is improbable that someone accidently will trigger CTRL+ALT+DEL sequence.

But now we have right CTRL and right ALT keys too, so that the probability of accidently hitting CTRL+ALT+DEL sequence is much higher, though not by hand, but might be some other object, eg book etc, might trigger that.

Also, this hold true for PAUSE key too. In fact there is much higher probability(even higher than accidently triggering CTRL+ALT+DEL sequence, becoz a single key press will do its stuff) that a pause will be triggered.

The application does not perform read/write on system hard drive, and it is not a network application. It is a simple application.

Actually,  till now what I tried is to hook int9 handler, and first read at port 60h, and then chain to the original handler. 

It is not possible to firs t chain to original handler then process the key, as system will get paused, if someone pressed pause key, even before original handler returns.

For the same reason, I can't hook INT15h, service 4Fh(and I doubt, it is still supported on modern PCs, but I'm not a guru after all. :) )

Is there a better implementation approach than stuffing the keyboard controller, with scan codes?

This would be last option for me. I again doubt(I might be wrong!) that those stuffing commands are still supported on modern PCs.

Now here is (simplified) implementation, what I did for Pause key: 

1. Read the port 60h.

2. If 'pause' variable is set and scan code IS 0xC5, then reset 'pause'  variable, then send EOI to PIC and return.
   DO not chain to the original handler.

3. else if 'pause' variable is set and scan code is NOT 0xC5, then reset 'e1flag' variable, send EOI to PIC and return.
   DO not chain to the original handler.

4. else if 'e1flag' variable is set and scan code is 0x1D, set 'pause' = 1, then send EOI to PIC and return.
   DO not chain to the original handler. Reset 'e1flag' variable

5. else if the scan code is 0xE1, set a flag - 'e1flag' and chain to the original handler.

6. else simply chain to the original handler.

This is only for PAUSE key not for ctrl+alt+del sequence. I removed DEL checking for simplicity to focus on Pause key. 

The problem I'm facing is with PAUSE key. The Ctrl+ALt+DEL sequence handling works fine on all PCs(not more than 3 :) ) I 

have tested. The logic for CTRL+ALT+DEL handling is same except, I simply checked for 0x53 only, and didn't  checked for 0xE0. This will trap both DEL keys - one simple DEL key and other one on the keypad ie numeric (.) key.

When I ran this executable on a PC, it worked fine. By fine I mean that when I press a pause key, the program detected it, and after pressing pause key when I press some extended scan code key eg, Right CTRL, then bios handler sets the CTRL flag(bit2) at BDA(BIOS Data Area) location 400:17h and at location 400:96h
it set bit0, bit 1 and bit2. This is expected.

Bit0 at 4000:96h is cleared   as soon as I pressed some non-shift key, eg alphabet 'A' etc.

But when I ran the program on another PC, as soon as I pressed pause key, the bios handler, sets bit0 at 400:96h to 1, but when I press some alphabet key or shift key(eg right ctrl), it neither reset bit0, not set bit1. It also did not  set CTRL flag at location 400:17h and at bit2 of 400:96h.
This may create havoc for some applications. Also when I exited from my application on this PC, the system didn't respond except when I pressed CTRL+ALT+DEL to reboot it.

It seems to me a BIOS implementation issue, otherwise my program, would not have run correctly on previous PC.

If I never presses pause key, this program runs fine as expected on this PC.
The problem occurs only after I presses Pause key in 2nd PC. On first PC, program runs fine.

I'm lost here, as to how to implement int9h handler, so that it fulfill the purpose reliably. 

NOTE: I deleted the previous post due to some typos, and imp detail missing from (simplified) implementation steps.

[toc] | [prev] | [next] | [standalone]

#734

From	"Rod Pemberton" <do_not_have@notemailnot.cmm>
Date	2012-08-10 04:27 -0400
Message-ID	<k02ghm$jus$1@speranza.aioe.org>
In reply to	#732

"jacks" <jacks.1785@gmail.com> wrote in message
news:fc763401-96c1-4cf4-bb1d-d4bb8afa3aa7@googlegroups.com...
> On Friday, 10 August 2012 05:24:33 UTC+5:30, Rod Pemberton  wrote:
...

I've replied to your earlier post.  For this post, it seems you've only
changed the logic for your routine.  As for implementing your routine by
reading 0x60 first, you're probably on your own with getting that to work
correctly.  Surprisingly, it looks like you were making some progress!
Good luck.

> NOTE: I deleted the previous post due to some typos,
> and imp detail missing from (simplified) implementation steps.

No, you didn't.

This is a Usenet newsgroup.  It's not a Google Group.  You might've deleted
it from Google Groups, or selectively deleted it from Google's archive of
Usenet newsgroups.  As for Usenet, the earlier message was sent, received,
distributed, and permanently archived.  Usenet servers haven't accepted
message deletion commands for many years because of abuse.

Rod Pemberton

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

INT 09h hooking issues

Contents

#732

#734