«

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

"Jay" <> writes:
> 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?

On 30 Jul 2005 01:11:32 -0700, "Jay" <> declaimed the
following in comp.lang.python:

> 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 --
raw_input doesn't return until a <cr> has been entered, at which point
you get all characters up to that point).

> 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.

--
> ================================================== ============ <
> | Wulfraed Dennis Lee Bieber KD6MOG <
> | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

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

Jay wrote:
> 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.
--
Michael Hoffman

Michael Hoffman 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.


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.

wrote:

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

Well, I'll be.
--
Michael Hoffman

[Michael Hoffman]

> Jay wrote:

> > 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.

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.

--
François Pinard http://pinard.progiciels-bpi.ca

François Pinard wrote:

> 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.
--
Michael Hoffman

[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.

--
François Pinard http://pinard.progiciels-bpi.ca