Sunday, April 16, 2006

Proximity Hacks

Visiting the local Fry's I found the infamous USB Wireless Security Lock for... if I'm reading the rebate receipt right... free. The price was right, so I picked one up. I had seen some hacks and descriptions of it previously and the concept intrigued me. Basically it's a wireless USB mouse's guts ripped out and put into a keyfob and a USB dongle. It's recognized as a mouse under Linux, but someone wrote a driver for the 2.6 kernel that seems to create a unique device node for it if you bypass the regular hotplug routines. Another person seems to have created a more mainstream driver and is trying to get it into the latest mainstream 2.6 kernel. Don't know if it actually landed there or not...

Edit: I was able to get things working quite nicely. The example at www.schau.com worked well - thankfully it was written to be as modular as possible. I wrote my own script to lock/unlock KDE's screensaver, and just had to make a few minor hacks to hid-core.c and wslxsctl.c so the USB kernel module would ignore the vendor id / device id of the key and the userspace app would listen to it.

It doesn't appear to be validating the unique ID sent by the keyfob however - so I'll need to code that part.

2 comments:

  1. Anonymous8:30 PM

    I have the same device. I recently found that wslxsctl will gladly read the signal of another FOB and unlock my machine, much to my dismay.

    Were you ever able to make wslxsctl use the unique ID of the FOB? If so, how?

    Please respond to me at vi at sh dot nu. Thanks.

    ReplyDelete
  2. I could never find a good way to generate a unique ID. In general I found the device didn't work as I hoped, but then again neither do bluetooth proximity devices either. It's back to Win+L for me.

    ReplyDelete