Thanks for help. This tool is awesome and having people like you build projects like this (and share them, and debug them live on the forum) is what makes it a community; rather than a forum attached to an online shop where we all ask "is it soon ™ yet?"
will reduce poll_throttle a little
You bet 
Increase the throttle. Decreasing it makes it busier (it polls more often).
I’ve updated the server so that it logs stdout and stderr from the PM3 client and the Android client also, to make troubleshooting easier. Also there’s a provision to use the pm3 wrapper instead of the proxmark3 client directly now.
I’ll try grab the latest again then because I had multiple versions of sirfidal_server.py and somehow it started reporting proxmark client died again.
I noted over the last hour that launching the pm3 wrapper automatically connects where as running the binary from client/proxmark3 requires “hw connect” before its ready to go.
Really? That’s strange because at least once when you ran the server with the proxmark3 executable, it started flashing - meaning it connected rightaway.
Still, it’s quite possible that an explicit connect command needs to be issued now. I’ll have to try with the latest and greatest PM3 client. Everything keeps changing in that thing - not to mention, compatibility between firmware and client versions. It’s really annoying to try to chase the latest changes and keep up.
Of course, in case it wasn’t obvious, as long as the server is active on the Proxmark3 with the client it started, the PM3 is unusable If you run another client manually, it would probably crash the client started by the SiRFIDaL server.
By the way, make sure you don’t run several servers at the same time. They should avoid tripping on each other because the socket file should be locked, but I noticed it’s not always super reliable. If several instances of the same thing are running, they’ll be in a race and strange things will happen. In doubt, do a ps ax | grep sirfidal_server and see if only one instance of each process is running.
I was going circles a bit with the config in the server vs the config in /etc/sirfidal_server_parameters.py and indecision about whether I needed the path to point at the directory called config, or the executable within that directory
I did notice that there were socket and socket.lock files in the /tmp directory even though I had stopped the service with systemctl aaaand I may have then deleted them in a moment of frustration…was that bad? 
The main script tries to execute /etc/sirfidal_server_parameters.py, and anything declared in that script will override what was declared in the main script before it tries to execute it. I added this more or less for myself because I wanted to leave the default parameters untouched in the main script, while keeping my normal parameters separate, so I don’t accidentally commit garbage into the repo.
If you keep the settings separate, it won’t complain next time you do a git pull.
If I’m honest, that’s something else I should clean up. I did it the lazy way, by inlining the settings in the main script (and then splitting them off in a separate Python file, but really it’s the same thing). But the settings should really be a JSON file or something.
Zapping the socket and the lock doesn’t hurt anything other than the running server if one is running. They’ll be recreated next time you start the server.
Phew, on a separate matter that I was reading somewhere a person was saying that was a heinous crime.
It totally makes sense for development, my ADHD brain just freeeaks out about strange stuff… I had copied the Parameters section verbatim from server file, and so inside /etc/sirfidal_server_parameters.py was the “config_file=…” (pointing at itself) so I got some sort of neural circular reference 
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
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
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 README.security 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 - sirfidal_server_parameters.py and sirfidal_clients_parameters.py 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.
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
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, sirfidal_autotype.py and sirfidal_autolockscreen.py get started as me-as-a-user.
You may want to run sirfidal_auto_send_enter_at_login.py 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 There’s a service file for that in the repo.
This is awesome. Thanks appreciate it!!
Glad you enjoy it
I added a config panel to sirfidal_autotype.py 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
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!
