keylogger in Python

[Jay]

ok, i thought for 2 seconds i might have created a Keylogger in python
but i still have one major think stopping me... PYTHON. when i run the
program i have python create a file named keylog2.log and it then logs
all keys pressed/typed in the python IDE into that file. All i want to
know now is how do i hide or background python so that it will log all
the keys pressed outside of Python.

feel free to play around with my program... but please post ur findings
on my post...
#####################################################
class keylogger:
pass

keylogging = keylogger()
keylog = open("keylog2.log", "w")
text = raw_input()

keylog.write(text)
keylog.close
keylog = open("keylog2.log", "r")
keylog.read

 

[Paul Rubin]

ok, i thought for 2 seconds i might have created a Keylogger in python
but i still have one major think stopping me... PYTHON. when i run the
program i have python create a file named keylog2.log and it then logs
all keys pressed/typed in the python IDE into that file. All i want to
know now is how do i hide or background python so that it will log all
the keys pressed outside of Python.

You are completely confused and keyloggers don't work anything like that.
Why do you want to log keystrokes anyway?

 

[Dennis Lee Bieber]

ok, i thought for 2 seconds i might have created a Keylogger in python

No, all you've done is create a /user mode/ application that
reads ITS system input stream (and not even character by character --

but i still have one major think stopping me... PYTHON. when i run the
program i have python create a file named keylog2.log and it then logs
all keys pressed/typed in the python IDE into that file. All i want to
know now is how do i hide or background python so that it will log all
the keys pressed outside of Python.

A keylogger, at the lowest level, injects itself between the
keyboard driver and the OS dispatcher (for windowing systems, in
particular). It has to be transparent -- your program is consuming the
characters meaning they are not available anywhere else; a key logger
has to "copy" the keys (probably raw key-codes and not characters) from
the input stream without blocking them from reaching the normal
application that want them. That's why, for example, Windows (NT) uses
the <ctrl><alt><del> to get a log-in prompt. That key combination is
handled at the very lowest level of the keyboard driver, and NEVER
passes out to where a user program can intercept it -- meaning one can
not write a "login capture" program to fake a Windows login screen.

Doing key logging is highly OS dependent. Under AmigaOS, one
would inject a key handler at high-priority into the OS input stream
chain (a linked list of priority ordered programs that want to see
input). The logger would receive, on its input port, an OS packet with
the timestamp and key codes, could log it, and then return it to the OS
to be passed to the next program in the chain (some programs consume the
stream and don't pass it on). It was also easy to inject fake events --
a program could inject, for example, disk-change events that other
programs would respond to.

On Windows... I don't know for sure... Chapter 27 of
"Programming Applications for Microsoft Windows 4th Ed." might be of use
(may also be a more up-to-date version available too). It shows some
system call of AttachThreadInput() being used to link a program's input
stream (queue in the book's terminology) to another program so both
receive the same data (I think). You're logger would have to hook into
the process start-up system so that it could link to every process that
might be reading keys.

--

 

[Jay]

yo, thanks for the great input. And the only reason i want to create a
python based keylogger is because there is none. Just a fun project...
But im gonna do some more research on the keyboard drivers and stuff
like that and to learn how to attach my python porgrams into the
sub-processes so that it would instead log every char instead of just
char in the IDE.
thx

 

[Michael Hoffman]

yo, thanks for the great input. And the only reason i want to create a
python based keylogger is because there is none. Just a fun project...
But im gonna do some more research on the keyboard drivers and stuff
like that and to learn how to attach my python porgrams into the
sub-processes so that it would instead log every char instead of just
char in the IDE.

I think this is going to be much harder than you think, and I imagine
this will only end in frustration for you. You will not be able to do it
well with just Python. I would recommend a different fun project.

 

[simonwittber]

I think this is going to be much harder than you think, and I imagine
this will only end in frustration for you. You will not be able to do it
well with just Python. I would recommend a different fun project.

Actually, it's pretty easy, using the pyHook and Python win32 modules.
I use code like this to detect when the user is away from the keyboard.

import pyHook
import time
import pythoncom

def OnKeyboardEvent(event):
print event.Ascii

hm = pyHook.HookManager()
hm.KeyDown = OnKeyboardEvent
hm.HookKeyboard()

while True:
pythoncom.PumpMessages()


Sw.

 

[Michael Hoffman]

Actually, it's pretty easy, using the pyHook and Python win32 modules.

Well, I'll be.

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Michael Hoffman]

Jay wrote:

I think this is going to be much harder than you think, and I imagine
this will only end in frustration for you. You will not be able to do
it well with just Python. I would recommend a different fun project.

I'm just stumbling on that message, and did not follow the whole thread,
sorry if I repeat things already discussed. My point is that Python is
able to do surprising things, given the `fcntl' and `ioctl' modules.

Surely on Linux, logging keys under X-Windows or under virtual terminals
are quite different matters. Let me share a related experience for
virtual terminals. I once had to rush the port on Linux a few QNX
applications, written in C, which were using the QNX term library
for input and display. In console mode, the QNX keyboard is richer
than the Linux one. As users wanted to retain the _exact_ keyboard
functionality, I saw no choice but reading raw scan codes on the Linux
side. So, I wrote a term library emulator as a thin C layer, which was
itself using a Python module (Python was to be transparently embedded by
the emulated library) for doing the bulk of keyboard processing.

It was something pretty heretic to do, I know. But Python was more than
fast enough for handling the low-level keyboard reading, for applications
otherwise all written in C. But it allowed the port to be done quickly.

While debugging such a thing, you often loose the keyboard and with it,
the capability of switching terminals, so you have to devise some extra
machinery for restoring the keyboard into a usable state.

 

[Michael Hoffman]

Surely on Linux, logging keys under X-Windows or under virtual terminals
are quite different matters. Let me share a related experience for
virtual terminals. I once had to rush the port on Linux a few QNX
applications, written in C, which were using the QNX term library
for input and display. In console mode, the QNX keyboard is richer
than the Linux one. As users wanted to retain the _exact_ keyboard
functionality, I saw no choice but reading raw scan codes on the Linux
side. So, I wrote a term library emulator as a thin C layer, which was
itself using a Python module (Python was to be transparently embedded by
the emulated library) for doing the bulk of keyboard processing.

You think this is a suitable beginner project?

And for that matter, it doesn't sound like you were doing keylogging, as
it is usually understood to mean globally logging keypresses, no matter
the application being presented to the user.

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Michael Hoffman]

You think this is a suitable beginner project?

One surely learns a lot!

And for that matter, it doesn't sound like you were doing keylogging, as
it is usually understood to mean globally logging keypresses, no matter
the application being presented to the user.

One possible avenue to keylogging might be to start a shell, over the
keyboard processing layer, presuming the shell do only simple things
over its standard input.

But most likely, the shell is playing termios trickery and such things.
So one might have to use pty's to get a working solution. Agreed, this
is not all evident, and probably too much of a challenge for a beginner.

 

[Michael Hoffman]

[Michael Hoffman]
[Francois Pinard]

One surely learns a lot!

I can agree with that!

 

[Premshree Pillai]

ok, i thought for 2 seconds i might have created a Keylogger in python
keylogging = keylogger()
keylog = open("keylog2.log", "w")
text = raw_input()

keylog.write(text)
keylog.close
keylog = open("keylog2.log", "r")
keylog.read

OMG!

 

[Bengt Richter]

ok, i thought for 2 seconds i might have created a Keylogger in python

[...]

Doing key logging is highly OS dependent. Under AmigaOS, one
would inject a key handler at high-priority into the OS input stream
chain (a linked list of priority ordered programs that want to see
input). The logger would receive, on its input port, an OS packet with
the timestamp and key codes, could log it, and then return it to the OS
to be passed to the next program in the chain (some programs consume the
stream and don't pass it on). It was also easy to inject fake events --
a program could inject, for example, disk-change events that other
programs would respond to.

On Windows... I don't know for sure... Chapter 27 of
"Programming Applications for Microsoft Windows 4th Ed." might be of use
(may also be a more up-to-date version available too). It shows some
system call of AttachThreadInput() being used to link a program's input
stream (queue in the book's terminology) to another program so both
receive the same data (I think). You're logger would have to hook into
the process start-up system so that it could link to every process that
might be reading keys.

I'd go to

http://msdn.microsoft.com/library/e...bouthooks.asp?frame=true#wh_journalrecordhook

for starters. Also, if you have a w32 sdk, you likely have the source for an old windows message "spy" program (in C),
along with makefile and bits and pieces it needs. You could cannibalize to do specifically keyboard-oriented stuff, and
differentiate alt-stuff from plain stuff etc. You can also monitor the activity of individual widgets and whatnot and
copy the messages they receive to change text and resize and all manner of stuff.

Try typing spyxx.hlp and see if spy++ help comes up. Or possibly run an older spy.exe for an
example of interactively selecting what to monitor. Then you could write a C module to provide
a python interface to those capabilities. Have fun ;-)

Regards,
Bengt Richter