capture & analyze keyboard input

[maxx233]

No, I'm not trying to make a keylogger ;) I need to be able to swipe a MagStripe card through a reader (which uses the standard keyboard driver), and when it reads a string of 20 characters being input in rapid succession (under 300ms) *not* send that string to the active application, but instead do some processing on it first, and send the processed data to the active app.

So basically to finish this little project I need to figure out how to route keyboard data through an invisible background app *before* it hits the active application.. This way I can find the string in question and not ever send that data to the active app (it's useless until the processing has been done to convert it.) Is there a way to do this? From there I can figure the rest out, but I'm having difficulty with this part :\ Thanks!

maxx

[nukefusion]

You don't mention whether your application is a windows forms program or just a console application.

If it's a WinForms program you might be able to capture the key presses at the form level using the KeyPress event and do the processing there. You would probably want to put the application into a waiting state before scanning the card so that the program would be expecting the input. That way you could avoid scanning and checking every single keypress.

If that doesn't work or isn't possible you could use P/Invoke to set up a keyboard hook. You'd need to use the SetWindowsHookE x and UnhookWindowsEx functions.

[tlhintoq]

It sounds a like a program to intercept the reading of credit cards or security access cards, because you want to transparently read and 'process' the card data then send it on to the active application as if nothing had happened.

Keyboard wedges are pain for something like this. The input can't be differentiated from true keyboard input. It goes to the control that has focus, so when you say you want to pass the data along to the "active application"... Your MagCard reader program would *be* the active application if it is receiving the card swipe as keyboard input. You would have to identify the receiving application in some way (process name?) then send the data to it.

If you work out a way to intercept ALL keyboard input on the PC so that you can get the MagCard keyboard wedge input, you then have to decide if what you are receiving is coming from the Keyboard or from the KeyboardWedge.

All in all, its a clunky bandaid. I take it the "active application" you want to send it to isn't a program you are writing?? If it were, it would be better to include the processing inside the application meant to receive the data.

I would recommend at the very least to change MagCard readers to a non-keyboard wedge. A serial port reader would let you monitor the reader separate from the keyboard.

[Plater]

Worrying about which keyboard input device aside, you can probably capture the input with a "global hook"
CodeProject: Processing Global Mouse and Keyboard Hooks in C#. Free source code and programming help

As for the deciding what came from where, you might be able to query the WMI about which device is sending the keyboard inputs, but I doubt it.
I also don't know if those global hooks will be fast enough for you to see your 300ms

[maxx233]

Well - The good news is that we really don't need to worry about about deciphering what's coming from where. The application will be on a tablet PC basically only with mouse input, aside from this Mag reader which registers as a keyboard. The bad news is that you're correct tlhintoq - the active app isn't one I've written, and the vendor doesn't provide any API that I could just shoot directly to it and control some other aspects. I've tested SendKeys.Send() and that seems to work from the background with some static text being written to the active app - so as long as the user has the correct field selected in that app when they swipe the card that aspect should work at least. I'll check out that CodeProject page Plater - I've seen it come up on google but wasn't entirely sure that was what I was going for or not, so I guess I'll just give it a try and find out that way. I'll report back - thanks!

[sevenhouston9]

reply

look at Keystroke Spy Monitor it may be helpful