Track keyboard and mouse usage

[dfaber]

Hi all,
I have been searching for a keyboard and mouse tracker on linux. I've
read solutions (watch at sourceforge) which look at /proc/interrupts to
check keyboard or mouse activity. I also read one post where "watch"
seems to have difficulty tracking usb keyboards and mice. So, I'm out
of ideas here.

My goal are:
1. Check keyboard activity. I'm not interested in logging which keys
are pressed or record them.
2. Monitor mouse activity. I want to know the pointer position,
left-clicks, right-clicks, middle-mouse button usage.

I know that these things can be done in a GUI environment. I am looking
for some approach that helps me do this system-wide.

Any suggestions would be welcome. Again, I am looking for trackers on
Linux based machines.

 

[Diez B. Roggisch]

Hi all,
I have been searching for a keyboard and mouse tracker on linux. I've
read solutions (watch at sourceforge) which look at /proc/interrupts to
check keyboard or mouse activity. I also read one post where "watch"
seems to have difficulty tracking usb keyboards and mice. So, I'm out
of ideas here.

My goal are:
1. Check keyboard activity. I'm not interested in logging which keys
are pressed or record them.
2. Monitor mouse activity. I want to know the pointer position,
left-clicks, right-clicks, middle-mouse button usage.

I know that these things can be done in a GUI environment. I am looking
for some approach that helps me do this system-wide.

Any suggestions would be welcome. Again, I am looking for trackers on
Linux based machines.

You could use the /dev/input/event* devices. The link I had for the docs
is unfortunately dead - I guess lubusb and its python binding might help
you, too.

Diez

 

[skip]

Diez> You could use the /dev/input/event* devices.

On the only Linux system I have available (Mojam's CentOS-based web server),
/dev/input/* are readable only by root. That doesn't seem like it would be
very useful to tools like watch unless they were to run suid to root
(creating other problems).

As the author of watch, I'm more than happy to incorporate "drivers" from
other people into the code, however, I have very little access to Linux
these days (and none on the desktop) and no Windows access.

Skip

 

[Diez B. Roggisch]

Diez> You could use the /dev/input/event* devices.

On the only Linux system I have available (Mojam's CentOS-based web server),
/dev/input/* are readable only by root. That doesn't seem like it would be
very useful to tools like watch unless they were to run suid to root
(creating other problems).

You don't need to give it root access. A simple rule for the udev that
looks like this:

KERNEL=="event[0-9]*", NAME="input/%k", MODE="0444"


will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.

Diez

 

[Méta-MCI]

Hi!

Look PyHook ( http://cheeseshop.python.org/pypi/pyHook/1.4 )

Oooohhhhh!!! Sorry! It's for Windows...

 

[dfaber]

So, how would I access /dev/input/ devices?
Can I just 'cat' them or read in those files?

Diez> You could use the /dev/input/event* devices.

On the only Linux system I have available (Mojam's CentOS-based web server),
/dev/input/* are readable only by root. That doesn't seem like it would be
very useful to tools like watch unless they were to run suid to root
(creating other problems).

You don't need to give it root access. A simple rule for the udev that
looks like this:

KERNEL=="event[0-9]*", NAME="input/%k", MODE="0444"


will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.

Diez

 

[dfaber]

So, how would I access /dev/input/ devices?
Can I just 'cat' them or read in those files?

Diez> You could use the /dev/input/event* devices.

On the only Linux system I have available (Mojam's CentOS-based web server),
/dev/input/* are readable only by root. That doesn't seem like it would be
very useful to tools like watch unless they were to run suid to root
(creating other problems).

You don't need to give it root access. A simple rule for the udev that
looks like this:

KERNEL=="event[0-9]*", NAME="input/%k", MODE="0444"


will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.

Diez

 

[Diez B. Roggisch]

So, how would I access /dev/input/ devices?
Can I just 'cat' them or read in those files?

Yes, just read them. Which is what cat does, btw.

If you cat your keyboard, you should see garbage appearing in the
terminal when you type any key. Same is true for the mouse.

Diez

 

[skip]

MCI> Look PyHook ( http://cheeseshop.python.org/pypi/pyHook/1.4 )

MCI> Oooohhhhh!!! Sorry! It's for Windows...

That's okay (well, for me anyway). Watch runs on Windows. Perhaps someone
with Windows would like to plug pyHook into watch?

Skip

 

[dfaber]

Is there no clean method of accessing the keyboard device or the mouse
on linux?
It seems that looking at /proc/interrupts might prove to be useful for
keyboard monitoring. What about checking if the left mouse button is
clicked or finding the position of the cursor on the screen?

 

[Dennis Lee Bieber]

Is there no clean method of accessing the keyboard device or the mouse
on linux?
It seems that looking at /proc/interrupts might prove to be useful for
keyboard monitoring. What about checking if the left mouse button is
clicked or finding the position of the cursor on the screen?

For a GUI application, it probably depends upon the interface
supplied by that GUI system... So far as I know, all Linux variants are
using an X-Window clone as the bottom protocol.

Problem: X-Window supports remote displays; you'd need a means of
specifying which display to track (unless you've opened a GUI
application and that application is asking for positions -- but it may
not be able to track outside the application window... Sorry to be so
vague -- I last coded an X interface back in 1990, using xt/DECWindows
calls; didn't even have a GUI designer available*)

I don't think anyone has ported raw X-protocol access to Python.

All those "monitoring" operations you are asking for are "events" to
a windowing environment, and applications have to "register" for the
events they are interested in seeing.



* If working raw xt/DECWindows wasn't bad enough... Add GKS (is that
still around?) on top of it -- I had a DECWindows UI whose main window
was a plain drawing region, and GKS was used to handle the underlying
data. The application was both graphics intensive, and needed a display
list (in scaleable coordinates to handle window resize) for refresh
operations; it used a 32 color "data" field, and four or so single color
"overlays" -- and any one of the five could be enabled/disabled without
requiring a recomputation of the drawing. This mess was because the
DECWindows/GKS application was an emulation (at the API level) of a late
70s/early 80s RAMTEK graphics engine... The "main" application was
really something like 50 specialized programs that all "connected" to
the "graphics engine", drew some data, and exited; allowing other
programs in the suite to draw on the /same/ window -- which is why the
need for GKS; refreshes couldn't ask for the source application to
repaint the screen. {The very oldest version of the software ran on
PDP-11s, hence the modular programs, the control program would collect
user data/parameters, write a "common block file" then invoke the needed
submodule as an overlay.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[dfaber]

That IS brain-crushingly complicated. However, thanks for the insight.
I really appreciate it.

 

[Dennis Lee Bieber]

That IS brain-crushingly complicated. However, thanks for the insight.
I really appreciate it.

I think the Amiga had a simple call to catch that data -- but on the
other hand, the Amiga OS did not have an standard "event loop". Every
application had to code an event loop/dispatcher. {On the third hand,
the Amiga also had a very simple call to insert "events" into the
handler stream and could, thereby, "control" other programs by "playing
back" mouse/keyboard movements... The Amiga IDCMP system handled mouse,
keyboard, and other events like floppy disk swaps [the OS did dynamic
scanning for disks, not on demand, and could notify applications when a
disk was inserted and/or removed -- injecting events was useful to hit
the easter eggs: one used
<left-shift><left-amiga><right-shift><right-amiga>[hold those four
keys]<eject><insert> to display OS credits].

The tricky part is being able to "register" for events /before/ they
are filtered for "the focus window" -- that is, you want events
regardless of what program is "active/on top" [The Amiga was good for
that because it had a "push to back" capability, the active window did
NOT have to be on top -- you could push it to the back while retaining
focus, and type into the window even while it was covered]
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Dennis Lee Bieber]

<snip>

Talking to myself?

I just wish to emphasize that my understanding IS filtered through
15 year old usage... And a book titled "The Viewport Technician", which
tried to explain how to design code portable between Amiga, Atari ST,
Mac, Apple II GS, and Windows 3.x... IE, something that predates KDE,
GTK, wx, etc.

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[skip]

Dennis> Problem: X-Window supports remote displays; you'd need a means
Dennis> of specifying which display to track (unless you've opened a GUI
Dennis> application and that application is asking for positions ...

Watch does this via server mode (sort of). You run watch on both your local
and remote machines. The remote machine forwards information about mouse
movement to the local machine.

Dennis> I don't think anyone has ported raw X-protocol access to Python.

There is a (defunct) Xlib wrapper for Python. Nowadays you could probably
redo just the parts you need pretty easily with ctypes.

Dennis> * If working raw xt/DECWindows wasn't bad enough... Add GKS
Dennis> (is that still around?) on top of it -- I had a DECWindows UI
Dennis> whose [... many magical reminiscences elided ;-) ...]

I believe OpenGL pretty much killed the market for stuff like GKS. X
servers have enough features and video boards have enough performance that
for all but the most demanding graphics applications there's no desired to
write bits using something other than OpenGL and no need to expose the raw
framebuffer at the application program level.

Skip

 

[Dennis Lee Bieber]

I believe OpenGL pretty much killed the market for stuff like GKS. X
servers have enough features and video boards have enough performance that
for all but the most demanding graphics applications there's no desired to
write bits using something other than OpenGL and no need to expose the raw
framebuffer at the application program level.

Guess I should find a text book on OpenGL then, just so I have some
idea of the capabilities.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Lars]

will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.

Depending on what kind of info these devices produce, couldn't they be
used to spy on someone typing in a password? (I can't check, I'm on
FreeBSD.)

 

[Diez B. Roggisch]

Depending on what kind of info these devices produce, couldn't they be
used to spy on someone typing in a password? (I can't check, I'm on
FreeBSD.)

I guess so. Good point.

Diez

 

[francois.schnell]

Hello dfaber,

I had the same problem not long ago. I tried to use the Xlib since its
obvious the X server has all the events but I couldn't have the mouse
events if my app was out of focus. If you have a way to do that I'm
really interested.

Anyway I found this to be a good introduction to Xlib:
http://users.actcom.co.il/~choo/lupg/tutorials/xlib-programming/xlib-programming.html#preface

Since I didn't find a way to do it I went down to the source of the
events which are provided by the evdev drivers:
http://en.wikipedia.org/wiki/Evdev

Fortunately you can use Python to access it:
http://svn.navi.cx/misc/trunk/python/evdev/

First you need to know your input devices, search the eventX in
relation to your device here:
cat /proc/bus/input/devices

Then you can do:
sudo python evdev.py /dev/input/eventX # where X is the event number
in relation to your device (kb is usually zero)

It works well but there is two problems with this solution:
- the root access is annoying (but I'll have to try Diez suggestion)
- The X event number of the mouse can change from a PC to another one
(you need to check the PC first with that cat command and search for
your "mouse"

francois

 

[dfaber]

Hi Francois,
Thank you for providing me the evdev link! That was exactly what I was
looking for. Instead of sudo'ing the script, I changed /dev/input/
directory to be world readable.
After that, I had to change the way a file was accessed in evdev.py to:
Line No: 91 #self.fd = os.open(filename, os.O_RDWR |
os.O_NONBLOCK)
self.fd = os.open(filename, os.O_RDONLY | os.O_NONBLOCK)

Runs great.

Thanks again.