Low-level hardware interrupts..

[frog]

While I was reading about debugging I came to the realization that it is possible to look for certain low-level interrupts using your CPU's registers(using debug registers to set hardware breakpoints). There is a thread on this site about a Python key-logger and I think about all that abstraction before you even make a call to the Windows API for polling keyboard events. Then I started thinking about how the Windows API actually polls the keyboard. Obviously there is code that interacts with the keyboard on a lower-level(this would be your device-driver) to accomplish this. The question is how..

As far as I know a major component of this lower layer is called the BIOS interrupt table, which seems to be a standard index for referencing different devices and services built into the computer and access to some of the different functions they provide.

I'm sure there is more to it to interpret the codes and display the correct corresponding character, but I'm curious if anybody knows anything more about the process of catching the interrupt..

Here is the BIOS interrupt call list, which shows the relevant keyboard interrupts as follows:

4Fh​

Keyboard Intercept

​00h​	Read Character
​01h​	Read Input Status
​02h​	Read Keyboard Shift Status
​05h​	Store Keystroke in Keyboard Buffer
​10h​	Read Character Extended
​11h​	Read Input Status Extended
​12h​	Read Keyboard Shift Status Extended

So my basic assumption is that the pseudo-code goes something like this(logically concerned):

Code: (c) [Select]


if(interrupt == "0x4FH") {
    inputChar = "0x00H"
    shiftStatus = "0x02H"
}

// some logic to handle shift-status and interpretation..

print resultChar

Does anybody have solid information regarding catching these low-level interrupts?
If so, can you provide any sort of example?

[Xires]

Typically direct hardware interaction requires that you be in a different CPU mode called 'real' mode.  Most operating systems will operate in 'protected' mode.  Standard system calls are generally made via syscall().  Direct ASM can also be used.  For hardware interaction, unless you have a library that makes it more easily available, often you'll be using ASM.

[frog]

Thanks for the reply. I need to use assembly for the task no doubt but I'm hoping to get away with c/c++ and some inline asm. I overlooked this snippet on the wiki for the 'BIOS interrupt call' page on wikipedia:

Code: (asm) [Select]

mov ah, 0x0e
mov al, '!'
int 0x10
So the interrupt being called is 'int 0x10' which is being used to print the "!" character to the screen. I assume invoking keyboard interrupts is done in a similar fashion. So my answer lies somewhere between an assembly reference, a BIOS interrupt reference, and the trial & error involved. I was able to affirm this possibility after I came across a BIOS interrupt list[1]. The following is from that list:

KEYBOARD - GET KEYSTROKE

AH = 00h
 Return:
AH = BIOS scan code
AL = ASCII character 

Notes: On extended keyboards, this function discards any extended keystrokes, returning only when a non-extended keystroke is available. The BIOS scan code is usually, but not always, the same as the hardware scan code processed by INT 09.  It is the same for ASCII keystrokes and most unshifted special keys (F-keys, arrow keys, etc.), but differs for shifted special keys. Some (older) clone BIOSes do not discard extended keystrokes and manage function AH=00h and AH=10h the same. The K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended keystrokes (same as with functions 10h and 20h), but will always translate prefix E0h to 00h. This allows old programs to use extended keystrokes and should not cause compatibility problems

Reference:
 [1]: http://www.ctyme.com/intr/rb-1754.htm

[Xires]

What is it, exactly and with adequate detail, are you trying to do?  Are you wanting to build a low-level keylogger?  As mentioned previously, most OSes will prevent you from being able to directly execute BIOS interrupts.  This is usually done via 'trapping' interrupts and having them handled by some other code designed to emulate the desired effect.  In essence, especially for Windows, you cannot build a low-level keylogger(or pretty much anything else that uses BIOS interrupts) without finding a way around the kernel.  One of the recommended methods might be to load some code before the Windows bootloader that you can access via a virtual device driver from within Windows.  Whilst this could provide a needed interface to the lower levels of hardware interaction that you're seeking, it is still complicated software and should be designed with care.  Also keep in mind that, again, BIOS interrupts are typically executed in 'real' mode, not 'protected' mode.  Executing a mode switching whilst putting the whole OS on hold temporarily('cause it tends to freak out) just to execute a single BIOS interrupt to do something like grab a key stroke is going to not only be a PITA but also very potentially disastrous.

[frog]

Yes, I want to see if it's possible to make something that would run as OS independent as possible(all except the loading and cleanup process). I'm trying to get as much info as I can, so thank you for the  reply. I'm realizing after reading your post that this is going to be a project best supplemented with a book on rootkits. I was hoping that you could just make a device driver that would dispatch the 'real-mode' keyboard events to and from user-land; kind of like a side-project while windows continues to run. Is this not feasible? What are the implications when it comes to restriction of this type of behavior regarding the kernel?

[MrFreeze]

Most keyloggers, as in - the ones used to intercept passwords for banking and other online accounts, are generally applications that run 'over' the applications theyre meant to intercept passwords from.
 
There was a popular World of Warcraft password keylogger some time ago that simply affixed itself over the login screen and when someone typed in their information, it first went to the keylogger and then to the webportal. I had thought that most were similar, but if what youre suggesting is feasable, Id like to hear how/if you can figure out a way to make it work.

[frog]

Most keyloggers, as in - the ones used to intercept passwords for banking and other online accounts, are generally applications that run 'over' the applications theyre meant to intercept passwords from.
 
There was a popular World of Warcraft password keylogger some time ago that simply affixed itself over the login screen and when someone typed in their information, it first went to the keylogger and then to the webportal. I had thought that most were similar, but if what youre suggesting is feasable, Id like to hear how/if you can figure out a way to make it work.

Right, I understand how user-land keyboard hooks and intercepting keyboard messages from applications works. I'm trying to get more information on something that operates lower-level than the previously mentioned..

[MrFreeze]

Right, I understand how user-land keyboard hooks and intercepting keyboard messages from applications works. I'm trying to get more information on something that operates lower-level than the previously mentioned..

If you can figure out a way to make your way work, dude - Id love to hear about it. Seems like a real pain, but reading through your posts again, seems like youre onto something...hopefully lol

[frog]

If you can figure out a way to make your way work, dude - Id love to hear about it. Seems like a real pain, but reading through your posts again, seems like youre onto something...hopefully lol

Amen. I'm in it for the long haul; working 2 different jobs and trying to keep good relationships inevitably prolongs these types of things for me. All I know is that if I can program something in user-land in C then I could most definitely learn what I need to and eventually achieve my goal.

[Xires]

As I've explained, you cannot use BIOS interrupts in Windows because they are intercepted.  As unfortunate as it is, it's just part of the way that the system works.  You cannot use any of the truly low-level ASM that you're wanting to use because the CPU is running in 'protected' mode.  If the system has started Windows, then the lower-level BIOS calls are inaccessible directly.  If you load something before the CPU switches from 'real' mode to 'protected' mode then when it actually makes the switch, that software is no longer running and it's useless at that point.  The lowest that you can get, within Windows, is via the kernel itself.  Your best bet for a keylogger is to create a [virtual] device driver that interposes itself within the rest of the scheme to intercept keyboard I/O prior to handing it off to the normal driver for processing.  You will still likely want some userland process, though at this driver level you can hide that process's existence.  The userland process will be able to suss out other properties, like which website one visits & what input box someone clicked on, that would be important for information gathering.

Putting all of this together; you need to learn to build a rootkit.  This also gets you closer to interfacing directly with the hardware and more options may open.  I would suggest, personally, not trying to replace the keyboard driver altogether but ensure that you understand how it works.  You'll be receiving messages quickly and you cannot afford to let the system wait on your code so trying to compress scancode logs at this level would be a poor idea.  Separate & modularize your code.  You can hand it off to other things to do the extra work for you.  All you need running at ring0 is something that intercepts & forwards keyboard input and possibly something to hide & manage your processes.  Designing the code for this is easy, getting it into ring0 is not as easy.  Additional research on rootkits will help you.



Please be respectful of the knowledge that you are seeking and the minds that help you find it.

[frog]

You've given me invaluable insight in regard to my goals, and defined a path that will undoubtedly benefit me in other future projects. Thank you Xires.

[p_2001]

As I've explained, you cannot use BIOS interrupts in Windows because they are intercepted.  As unfortunate as it is, it's just part of the way that the system works.  You cannot use any of the truly low-level ASM that you're wanting to use because the CPU is running in 'protected' mode.  If the system has started Windows, then the lower-level BIOS calls are inaccessible directly.  If you load something before the CPU switches from 'real' mode to 'protected' mode then when it actually makes the switch, that software is no longer running and it's useless at that point.  The lowest that you can get, within Windows, is via the kernel itself.  Your best bet for a keylogger is to create a [virtual] device driver that interposes itself within the rest of the scheme to intercept keyboard I/O prior to handing it off to the normal driver for processing.  You will still likely want some userland process, though at this driver level you can hide that process's existence.  The userland process will be able to suss out other properties, like which website one visits & what input box someone clicked on, that would be important for information gathering.

Putting all of this together; you need to learn to build a rootkit.  This also gets you closer to interfacing directly with the hardware and more options may open.  I would suggest, personally, not trying to replace the keyboard driver altogether but ensure that you understand how it works.  You'll be receiving messages quickly and you cannot afford to let the system wait on your code so trying to compress scancode logs at this level would be a poor idea.  Separate & modularize your code.  You can hand it off to other things to do the extra work for you.  All you need running at ring0 is something that intercepts & forwards keyboard input and possibly something to hide & manage your processes.  Designing the code for this is easy, getting it into ring0 is not as easy.  Additional research on rootkits will help you.



Please be respectful of the knowledge that you are seeking and the minds that help you find it.

Thank you
I always wondered why we use software interrupts in asm..
Is this why?

[Xires]

frog; You are most welcome.

p_2001; Most likely, yes.