Be Skeptical of All Code - Not Just the Funny Stuff
Most keyloggers don't admit to being keyloggers!
Feb 8, 2025
Should you be more skeptical of code that is a “self-admitted keylogger” than code that purports to be useful? I’m not so sure.
Last week I made a global caps lock key. It’s a joke project 1 - a small client that keeps caps lock in sync for everyone running the client.
It’s a joke, but it’s real - I did make this and it does work. It’s good to commit to the bit!
It has been relatively popular on various social media platforms. So I’ve heard from a lot of strangers about it. And a comment I keep hearing is:
This is a massive risk and it’s insane that anyone has installed it!!
I don’t fully disagree. But I’d like to stress one point: this code requires no special permissions on Windows or Linux 2.
MacOS does require a relatively general accessibility permission for the code to be able to send keystrokes to your computer - but you have to grant that permission to the terminal that’s running the program, not my script.
If you’re on one of those platforms, any code a stranger gives you could be doing the exact same thing. If you want to be intellectually consistent, I think you should apply the same mindset to any other program whose source you haven’t read.
At least my code is an easy to read open-source 200 line python script!
Arguing with myself
Maybe I’m not being totally fair. Here are a few thoughts
Caps Lock is special
It’s a lot easier to access the state of caps lock than it is to intercept every key someone types, and that’s a good thing.
My program doesn’t work by intercepting caps lock key presses. Instead it polls the caps lock state - it checks whether it’s currently on or off and compares that to a past value. Platforms make this relatively easy to do - reading from /sys/class/leds
on Linux, for example - and that kinda makes sense.
So maybe it’s more accurate to say “any script you run on Linux could read the state of your caps lock key and if you don’t read the source you’d have no idea.” That’s a little less scary.
Although I don’t know how difficult it is to write a python script that intercepts every keystroke, or what permissions it would need on various platforms. Do you?
This code explicitly targets the keyboard
Let’s say I was trying to make a malicious program that targets your keyboard. Would it be more effective to:
- Make a funny program that explicitly interfaces with your keyboard
- Make a funny program that doesn’t explicitly interface with your keyboard
- Make a useful, innocuous tool and smuggle something in, xz-style
I’m not sure!
But I don’t think that “code that explicitly interfaces with the keyboard” is the obvious winner. What was stopping me from adding something malicious to flappy bird in Finder or my chrome extension that ran Brick Breaker in Google Calendar?
I mean the real answer is “I’m not looking to write malicious software.” But setting that aside, I guess it’s “the programs are open source and someone could have read the code.”
But ultimately those were programs that I put on the internet and let strangers run. They could do anything!
This code talks to a server
I am more sympathetic to this point. My code talks to a server, so that server is also a target. If it was compromised, someone could attempt to send malicious data to users of my program.
I tried to handle this by making my protocol dead-simple. The server sends the string “1” or “0” back to clients and nothing else. Clients check for exactly that string in the messages they receive, and drop all other input without logging what it was.
data = await get_latest_message(websocket)
if data == "1" and current_state == False:
set_capslock_state(True)
current_state = True
last_state = True
elif data == "0" and current_state == True:
set_capslock_state(False)
current_state = False
last_state = False
elif data == "0" or data == "1":
# consistent
pass
elif data is None:
# no update
pass
else:
print(f"ignoring invalid data...")
There’s no parsing beyond whatever the python websocket
library does to give me a string, and I pass a hardcoded value to set_capslock_state
instead of passing in the message from the server.
So I think that helps. But I still take the point here. There is an additional target here.
That said, and I apologize that I keep repeating this point but I think it bears repeating:
Any script whose source you have not read could also be talking to a server, and it could be doing something really dumb
This code passes input from a server directly to a tool that controls my keyboard
So I don’t think that this is actually true. My set_capslock_state
function takes in a boolean and then runs a hardcoded command based on that boolean.
But I understand how, if you haven’t looked at the source of my script, you might believe this.
Concluding
I could keep going. And I am not sure that I am fully on my own side here: I am sympathetic to why this project triggered alarm bells for some people.
But those comments triggered the same reaction that I have when I see complaints about installing something with curl website.com/install | bash -x
or whatever.
Yes, it’s possible that the script is malicious. Yes, you can even make your server detect the curl $site | bash
pattern and serve a different script in that case.
But if you don’t read the code before you run it, it doesn’t really matter.