About KeyStroke Encryption

[AceStryker]

I need to create a KeyStroke encryption, i studied about it and the theory is this:

• Check the keystate before keyloggers do it
• Cancel the action of the key
• get the active window
• Simulate a virtual key in this window

I can make the last three items, but the first one is where i need help...How can i solve this?

[pritaeas]

Am not sure you can. You can create a keyboard hook, but so do the loggers. I don't think you can say for sure which of the apps receives the keystate first.

[AceStryker]

It will be a global hook right?I don't know how i do that...

[pritaeas]

http://delphi.about.com/od/windowsshellapi/a/keyboard_hook.htm

[Morten Brendefu]

That link was indeed a nice one for my personal purposes.:*

However.
As it goes, the hook is inserted in some Windows API.
I am pretty sure that some viruses can access the keyboard directly via hardware.
All in all, Windows API does just that too, and if you ask a windows API for keyboard events, then this is controlled by this API first. In other words, your program will not be the first to read the keyboard.

Without actually knowing 100% sure, I think the method to use is best done via Assembler code and redirecting Keyboard scan interrupt to your own assembler routines for then to direct the flow of control back to original address of original interrupt.

Back in the old days, before I fell in love with Turbo Pascal, I wrote some simple ASM code on the commodore 64 that redirected interrupts.
A much simpler computer with easier memory handling, but the basics of computers has not changed. Even the most advanced and sophisticated computer today depends on the same basic stuff of interrupts for many actions.
With the layer of Windows on top, it is not easy to find the right information on how to be allowed to change such an interrupt after Windows have started up.

My best suggestion is to write an assembler program, A kind of Keyboard Driver, one that loads into computer memory BEFORE windows starts up.
Windows Keyboard API should then lock its handler onto your driver, and hence leave your driver in first control of the keyboard.

Even if a keylogger is installed afterwards using windows, I think the OS will protect against direct access to interrupts(To a certain extent, and always methods to use to circumvent this for the knowledgeable ones) and leave your driver intact as the first possible place where keyboard input go.
I think a standard keyboard logger would access windows API in such a way that it is "First in que" to get the input, and if well written, it would also contain some code to prevent other software to gain "First in que access".

I hope my thoughts does not kill the curiosity. Maybe some other developers out there have some better insight in how to make this driver, and maybe how to be able to communicate (write interface to driver) so that it can be used via Delphi.
Many Linux developers really enjoy making code in assembler. Maybe something to search for in such a user group.

Just an idea and some thoughts.:twisted:
Best regards.
Morten, Norway

[pritaeas]

You are right about writing a driver, although that can be done in C, but not in Delphi.

[AceStryker]

@Morten Brendefu

It seems a good idea, i know the base of assembly, can you help me out with this?Maybe some functions i may use...

[Morten Brendefu]

I would love to help you out if I only could.
My skills in assembly language is "only" useable on the old Commodore 64.
I would not know how and where to insert or change adresses of interrupts.
I just have many ideas, and only a few of them is within my reach so far :D
I could elaborate a little bit further on your problem. It may help, but I can not make code towards it except hinting about the possible structure and method of how to do it.

As soon as any computer is turned on, the BIOS starts loading. The BIOS involves a keyboard handler that can be used from assembler.
I suppose it should be possible to examine the memory with some tool, and actually make a copy of this keyboard assembler code.
Then you may alter the code to your likings. write it to someplace suitable in memory and redirect interrupt to this code instead of letting interrupt point to BIOS code.

I think that is basically what a keyboard driver program should do, and could do.
I suppose the code itself is not big at all. less than 2-300 byte maybe.
The tiny size should make it possible to find a location for it that is compatible with windows, and also mask it so that windows does not rewrite that particular area of memory.

If I were to really make an effort into making a keylogger myself, I think I would try to disassemble one that already exist just to learn how they have made it.
I am sure many old assembler books have examples of how to access various interrupts and redirect them. This including Keyboard interrupt.
I dont think many newer books on assembly have this because nowadays software is written like turkeys and chickens are bred..
Today, people find a "component" here and a "component" there. they write a few lines and have made the "greatest" program ever. Finished compiled program is maybe 30 megabytes and does little more than what old style developers could fit into 64 kilobyte of "proper" coding.
The "great authors" of many current books tell in great detail how to use components and already made API's, but if really wanting to go back to the basics and "bottom" of the art of coding, I would suggest reading a few older books.
Not sure if everybody agrees with me, but that is ok too.:twisted:

Although saying I can't help much, I did come up with a nice link. Maybe something of use. I wish you good luck :-)

:cool:http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/Chapter_20/CH20-1.html:cool:
Best regard,
Morten, Norway.

[Morten Brendefu]

The link I provided gave insight in how the keyboard interfaces with computer also.
It gave me a nasty idea.
Make an electronic device that plug into your computer. Plug your keyboard into this device. connect cable from device into serial or usb port.
Make a program With Delphi or Turbo Pascal to access the keyboard buffer in device and change the data as you may find useful. release changed data into computers keyboard port.
Of course, you need to make this electronic device first, but no other software based keyloggers would get your key-inputs before you do with your special design combination of electronics and software.
If you get rich on this idea, please send me a postcard:twisted:
Best regards.
Morten, Norway.