Track keyboard and mouse usage
dfaber
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
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
sk...@pobox.com
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
Look PyHook ( http://cheeseshop.python.org/pypi/pyHook/1.4 )
Oooohhhhh!!! Sorry! It's for Windows...
--
MCI
dfaber
Can I just 'cat' them or read in those files?
dfaber
Can I just 'cat' them or read in those files?
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
sk...@pobox.com
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
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?
dfaber
I really appreciate it.
Dennis Lee Bieber wrote:
> On 17 Jul 2006 21:00:09 -0700, "dfaber" <deus...@gmail.com> declaimed
> the following in comp.lang.python:
> 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
> wlf...@ix.netcom.com wulf...@bestiaria.com
> HTTP://wlfraed.home.netcom.com/
> (Bestiaria Support Staff: web-...@bestiaria.com)
> HTTP://www.bestiaria.com/
sk...@pobox.com
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
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
I guess so. Good point.
Diez
francois...@gmail.com
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
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.
Simon Forman
> On 17 Jul 2006 21:00:09 -0700, "dfaber" <deus...@gmail.com> declaimed
> the following in comp.lang.python:
>
>
> I don't think anyone has ported raw X-protocol access to Python.
>
Actually someone did. http://python-xlib.sourceforge.net/ It's old
but it works fine. Speaks X protocol in pure python.
HTH,
~Simon