SiRFIDaL - Simple RFID authentication for Linux

Ok, It’s working like a charm now - I hope our dialogue doesn’t put anyone off trying your cool project - I just have a way of making things seem difficult.

What was a heinous crime? Inlining config parameters? That person is probably right :slight_smile:

SiRFIDaL started out as a collection of quick-and-dirty scripts I made for my own use, because I couldn’t find anything to perform logging in with “insecure tags” - i.e. UIDs - because the only way insecure tags are somewhat secure is if they’re implanted, and that’s a very, very tiny niche subsection of an already tiny set of users of NFC and RFID under Linux.

But then I wanted them to do this and that, and other people wanted this and that… and before you know it, it’s turned into a somewhat too-large-for-its-own-good project. The problem is, it still has some of the nastiness of the original scripts, namely the inline config parameters, spaghetti code, lack of installer and general here’s-the-code-you’re-on-your-own-ness of it all.

I really should make something pro out of it, but I’m finding it hard to put in the time for that. Oh well… At least it works for you :slight_smile:

Deleting lockfiles on a whim.

I think you are under selling yourself - authentication is no minor thing; even OEM’s long-finger it unless there is a common library that already does what they need and they can get away with adding a few lines to handle their vendor and product ID’s. Add to that a wide range of devices by different manufactures and the rapid changes of things like the Iceman repo and this becomes a real feat.

Well thanks. But believe me, authentication the way SiRFIDaL does it is really trivial, and in fact not that great from a security standpoint, as outlined in the file. But for certain applications, like a standalone workstation with one user in a non-critical environment - and even better, with implanted transponders - it’s plenty good enough.

Problem is, “good enough security” is kind of a red flag in the Unix world and nobody wants to do it. But it’s kind of unavoidable if you want to use dumb implants in a less shitty manner than with keyboard wedges. So I think for us it’s an acceptable compromise.

Your experience convinced me to rework all the scripts so the configuration parameters are fully outside the code - at long last.

If you git-pull the repo now, you’ll find two new separate configuration files - and that should go in /etc, that hold server and client settings totally separately from the scripts proper.

I should’ve done that a long time ago.

1 Like

I discovered git pull origin master to get latest (normally I just delete and do another pull)
adjusted Parameter files and copied them over and its up and running like a charm. Thanks!

Edit: Maybe this repo is worth a mention on the recent primer @amal made even if its Linux (advanced users) or something

1 Like

So currently the autotype script needs to be run manually every time you use it - could it be a service?

Services are system-wide, root-run things. So no.

What you do with the autotype script instead is start it as part of your user session’s startup. I’m not sure how it’s done in Ubuntu (that’s what you use, right?) but in Mint, there’s a Startup Applications menu that you can configure to start applications automatically upon login:

I simply added those two entries manually and now whenever I log in, and get started as me-as-a-user.

You may want to run as a service though: that’s meant to run when no user is logged in yet. All it does it send ENTER when you scan your implant, so you don’t have to do it when you log in, for ultimate laziness factor :slight_smile: There’s a service file for that in the repo.

This is awesome. Thanks appreciate it!!

Glad you enjoy it :slight_smile:

I added a config panel to so it’s easier to associate strings to autotype, windows to autotype them in and UIDs that trigger which string to type: now just focus the target window, hold Shift + Ctrl and scan your implant, and the panel pops up:

Also, I got my new Halo Scanner in the mail today with the newest firmware that reports the temperature. So I added support for that in SiRFIDaL as well: if an implant is scanned with a temperature information that falls outside the range of a living being’s temperature, the UID is invalidated. Perfect to prevent zombies wearing cloned xBTs from logging in :slight_smile:

More seriously: newer Halo Scanner firmwares allow for continuous scanning, so you never have to press the scan button once SiRFIDaL takes control of it.


Oohh, fancy. I had been wondering if I could make an ncurses config for install/setup but this is way nicer.

Also good work on closing the glaring loophole that would have been enabling zombies to scan in and pwn the system!

I finally took the time to make a pre-built .deb package for SiRFIDaL. I rewrote a few things so that it works (almost) right out of the box on Ubuntu and Debian as well as Linux Mint.

The PPA repository is here: All you have to do to install SiRFIDaL is:

  • Add the repository to your APT sources:
curl -SsL | sudo apt-key add -
sudo curl -SsL -o /etc/apt/sources.list.d/giraut.list
sudo apt update
  • Install the package
apt install sirfidal

I went ahead and wrote a PKGBUILD for the Arch AUR for both SiRFIDaL and pyufr (Arch requires that all dependencies are installed, even for optional features, so I had to make a separate pyufr AUR package to fulfill that requirement).

The AUR package is sirfidal-git.

Using any AUR helper, it should automatically pull and install the second AUR package, python-pyufr-git.

It’ll automatically install all files to their correct places, with the locations tweaked properly for Arch-based distros. Configuration must still be done as mentioned in the git repo, and the systemd services are disabled by default to ensure that proper configuration is done first.

Hopefully this helps Arch users get a quick start.


Nice work! now if I could just get my lazy ass around to trying arch again…

That’s great! Thanks!

I really need to give Arch a spin. I’ve been meaning to for some time but I think your contribution gives me an incentive now :slight_smile:

I’ve used a lot of Linux distros in the past 8 years, but I always find myself coming back to Arch. The lack of bloat, combined with setting up things the way I want, makes it a joy to come back to. The install process complexity is a bit overblown online, it’s just reading the Installation Guide on the wiki. Takes me about 10 minutes to do an install, and it has all of the software I use ready for when I do my first boot. The AUR alone is a massive draw for me, I can always install the software I need (even if the software license doesn’t match the ethics of the distro maintainers…)

It’s also nice to always have up-to-date packages. When I ran Debian, even on testing, I’d run into bugs constantly that had already been fixed weeks prior.

If you try Arch at some point and find any packaging issues, feel free to let me know. It’s super easy for me to push changes to the PKGBUILD. I don’t have a lot of the reader hardware (serial readers for instance), so it’s hard for me to 100% confirm that everything works.

If you make any changes to directory structure, try and make a post in this thread (or a README change), so I can make the necessary changes. The package is set up to pull the latest version of the git repo, so any changes in the files themselves will update in the AUR PKGBUILD automatically.

I started out with Slackware back in 1996 or something (so the complexity doesn’t bother me :slight_smile:), then worked professionally with Caldera OpenLinux (which was RPM-based) and finally settled on .deb-based distros because I’ve grown too lazy to fudge around with source packages and such anymore, and pre-chewed Linux distros pretty much Just Work™ nowadays. At least they work plenty well enough for what I want to do.

As for releasing stuff, I don’t want to touch RPM anymore (see above) but I do release .debs because they also Just Work™ for everybody else. Most people don’t like complexity.

I probably won’t. You might have noticed that I keep everything in a flat directory, most of the Python code is self-contained (apart from the clients which use that one single class file) despite making the code really heavy, and everything is kept as “smallest common denominator” as possible - Including the full-ASCII README :slight_smile: I do that on purpose to keep installation complexity and potential runtime problems to a minimum,

Darthdomo: just so you know, I just released SiRFIDaL 1.2.0 which adds a new dependency on a new package, pam_python ( On Arch, it’s this package I believe: AUR (en) - pam-python.

Sorry to change everything so soon since you made the Arch PKGBUILD: I was planning on switching the PAM module to pam_python eventually, but decided to do it after Mekhos mentioned he was unlocking his password manager using the autotyper. pam_python lets the SiRFIDaL PAM module bubble up the authentication token to Gnome Keyring Pam, so that it’ll automatically unlock the keyring from the login credentials, which is a lot cleaner than the autotyper kludge. But of course it means rewriting the PAM module and changing the dependency, which is why I hadn’t done it. But I thought, what the hell… So I did it. Sorry :slight_smile:


All good :+1:

PKGBUILD has been updated, and the new version pushed to the AUR.

1 Like