G'Day Folks,
On Mon, Mar 17, 2008 at 03:06:00PM -0700, Dan Mick wrote:
> Salman Jamali wrote:
> > I am willing to log keystrokes from a list of processes that I wish to.
>
> Faisal Mansoor wrote:
>
> > I am trying to write a keylogger using dtrace for all kinds of
> applications.
>
> School project?
:)
It is a topic that can lead you through some interesting OS internals,
and also a sensational example of DTrace's systemic observability. It
should make for a computer science assignment that students would enjoy.
Is this for keystrokes from the locally attached keyboard, or for keyboards
on remote clients who are running software on the server? The approach is
different for each; here I'll quickly describe locally attached keyboards,
whose codepath of keystroke events would be something like this:
keyboard
driver
|
stream I/O
|
syscalls
|
libc
|
Xorg
|
syscalls
|
socket
|
X11 library
|
application (eg, gnome-terminal)
|
syscalls
|
child library (eg, libc)
|
child application (eg, bash)
...
Everything is observable using DTrace - pick a layer and start tracing.
Finding keystroke events is much easier than most things, as it is
easy to inject known workloads (hit the "a" key 23 times) and frequency
count which probes fired.
Examples of tracing keyboard events can be found in typewriter-0.75
(http://www.brendangregg.com/dtrace.html - which I haven't updated in a
long time. (If anyone has trouble hearing sound properly, try changing
"cat file > /dev/audio &" to "audioplay file &", which seems to make it
work much better for x86/amd64 audio drivers.))
In typewriter.d I simply hardcoded the keycode for the enter key. There
are many better ways to get this if you are interested in the entire keymap,
such as we are for keyboard sniffing.
Here is one technique:
----------------
#!/usr/sbin/dtrace -s
#pragma D option quiet
#pragma D option switchrate=10
BEGIN
{
trace("Tracing... Hit Ctrl-C to end.\n");
}
fbt::kbtrans_keyreleased:entry
/self->seen == 0/
{
this->key = args[0]->kbtrans_lower.kbtrans_keyboard->k_normal[arg1];
printf("%Y %s: %#x \"%c\"\n", walltimestamp, probefunc, this->key,
this->key);
self->seen = 1;
}
fbt::kbtrans_keyreleased:return
{
self->seen = 0;
}
----------------
Example output:
# ./keysniffer.d
Tracing... Hit Ctrl-C to end.
2008 Mar 18 02:43:38 kbtrans_keyreleased: 0x79 y
2008 Mar 18 02:43:38 kbtrans_keyreleased: 0x6f o
2008 Mar 18 02:43:38 kbtrans_keyreleased: 0x75 u
2008 Mar 18 02:43:39 kbtrans_keyreleased: 0x20
2008 Mar 18 02:43:39 kbtrans_keyreleased: 0x68 h
2008 Mar 18 02:43:39 kbtrans_keyreleased: 0x61 a
2008 Mar 18 02:43:39 kbtrans_keyreleased: 0x76 v
2008 Mar 18 02:43:39 kbtrans_keyreleased: 0x65 e
2008 Mar 18 02:43:40 kbtrans_keyreleased: 0x20
2008 Mar 18 02:43:40 kbtrans_keyreleased: 0x62 b
2008 Mar 18 02:43:40 kbtrans_keyreleased: 0x65 e
2008 Mar 18 02:43:40 kbtrans_keyreleased: 0x65 e
2008 Mar 18 02:43:40 kbtrans_keyreleased: 0x6e n
2008 Mar 18 02:43:40 kbtrans_keyreleased: 0x20
2008 Mar 18 02:43:41 kbtrans_keyreleased: 0x30 0
2008 Mar 18 02:43:41 kbtrans_keyreleased: 0x77 w
2008 Mar 18 02:43:42 kbtrans_keyreleased: 0x6e n
2008 Mar 18 02:43:42 kbtrans_keyreleased: 0x33 3
2008 Mar 18 02:43:42 kbtrans_keyreleased: 0x64 d
^C
That's just one way to do it, from many DTrace makes available. Hitting
up Xorg, as Alan said, may be better - as you get to see it after xmodmap
translations (for those of us using dvorak keyboards ;).
When writing such tools, I'd suggest people to write a disclaimer similar
to what I put at the top of shellsnoop:
# This program sounds somewhat dangerous (snooping keystrokes), but is
# no more so than /usr/bin/truss, and both need root or dtrace privileges to
# run. In fact, less dangerous, as we only print visible text (not password
# text, for example). Having said that, it goes without saying that this
# program shouldn't be used for breeching privacy of other users.
DTrace can be used for some alarming security attacks - but other tools
could be used for the same attacks. We don't want IT departments to ban
DTrace based on security misunderstandings, rather, to understand that the
actual issue is that of root privilege delegation - as it is with other
tools. :-)
Finally, if someone is reading this thread because they are interested
in "logging" keystrokes (from the subject) - be aware that dtrace can drop
events when under heavy load (safety valve). This behaviour would need to
be carefully understood before an auditing framework could be successful.
Brendan
--
Brendan
[CA, USA]
_______________________________________________
dtrace-discuss mailing list
[email protected]
