What about support for an ESP-RFID-Tool?
That’s a Wiegand datalogger. It captures UIDs from another reader and logs them for later retrieval by penenetration testers (or bad guys, depending on the use case). It’s not a reader.
I know what it is, but if it was supported then you could use any Weigand reader, by providing it with power and attaching an ESP-RFID-Tool. I actually use one with an unconnected HID reader as a test platform. I am assuming that you are not supporting Weigand natively, this would be an easy way to expand the supportable readers.
Well kind of. Among other things, SiRFIDaL supports any old reader that shows up as a character device or PTY in the system and outputs UIDs in LF-terminated text lines. So it’s more a hardware problem than a software support problem: if you manage to connect your Wiegand reader and it shows up in /dev, you’re good to go.
Typically, you want to do that with a Wiegand-to-serial converter. Or, you may have some board that reads Wiegand readers and makes the data immediately available through telnet, or with a HTTP server, or with a HTTP client that connects to a fixed server. SiRFIDaL supports all those schemes too.
But the key here is that it should get the UIDs in real-time. To my knowledge, the ESP-RFID just sits there and collects UIDs it sees on the Wiegand interface and stores them in memory, to be retrieved at a later date. That’s not what SiRFIDaL is for at all. Unless I’m mistaken and the ESP-RFID does have a mode to report UIDs in real-time that I’m not aware of, in which case, it might be supported depending on how it’s done.
I would have to check… I will dig mine out and let you know.
I’ve added support for the Halo Scanner to SiRFIDaL, thanks to the help of the manufacturer.
If you think this is cool and you like how they treat our little community, drop them a line next time you order a Halo Scanner.
Of course, video proof is needed 
This is me locking / unlocking my session with my xBT:
Incidentally, I recently did a major code cleanup of SiRFIDaL. The new codebase is quite a bit more efficient if you have a lot of readers connected, and more importantly, the settings make a lot more sense.
Also, as a recap, here is the list of devices that SiRFIDaL now supports - quite a bit more than what it started with by now:
- PC/SC readers (ACR122U and others)
- Serial readers
- Halo Scanner
- HID readers (aka keyboard wedges, e.g. KBR1)
- NFC-enabled Android devices (e.g. old cellphone you want to turn into a tabletop reader)
- Proxmark3
- Chameleon Mini / Tiny
- Digital Logic uFR, uFR Nano, uFR Nano Online
- Ethernet readers that push data to HTTP servers
- Ethernet readers that serve up data as a TCP server
3 Likes
Hi Rosco, are you able to give any clues as to why my ubuntu setup isn’t working?
I’ve enabled my pm3 in the parameters section, and pointed the client part to the git folder (in my home directory)
However, when I run sirfidal_getuids.py and then interrupt with ^C I get the following msg;
Traceback (most recent call last):
File “/usr/local/bin/sirfidal_getuids.py”, line 99, in main
with scc.sirfidal_client() as sc:
File “/usr/local/bin/sirfidal_client_class.py”, line 47, in init
self.connect(socket_path = socket_path)
File “/usr/local/bin/sirfidal_client_class.py”, line 66, in connect
self._sock.connect(socket_path)
FileNotFoundError: [Errno 2] No such file or directory
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/local/bin/sirfidal_getuids.py”, line 142, in
sys.exit(main())
File “/usr/local/bin/sirfidal_getuids.py”, line 136, in main
sleep(.2) # Wait a bit before reconnecting in case of error or timeout
KeyboardInterrupt
Also, if I run sudo sirfidal_useradm.py -a
it returns-
Error: [Errno 2] No such file or directory
This seems to indicate the socket file isn’t found, meaning the server isn’t running. Did you start sirfidal_server.py?
You can open another console and start it manually to check that it works, or permanently start it as a service if you followed the installation instructions in the README using systemctl enable sirfidal_server then systemctl start sirfidal_server
Also, the server needs to run as root, in case it wasn’t obvious.
(And yes, I realize at some point I really should package it properly )
I didn’t manually try and start it before, because I had started and enabled via systemctl as per the README.
After running sirfidal_server.py as root just to test now, I get:
Traceback (most recent call last):
File “/usr/local/bin/sirfidal_server.py”, line 301, in
from setproctitle import setproctitle
ModuleNotFoundError: No module named ‘setproctitle’
I followed the readme, regarding config files and pam, but omitted the steps for Sound, Android, uFR
Okay that’s something I failed to add in the readme. Try this as root:
apt-get install python3-setproctitle
Bingo!, and I can now see the fake proxmrk3.log file and the socket connection in my /tmp directory.
Next point, if I try to …_useradm or …_getuid there is no reading happening, and the DT RFID-diagnostic card confims the proxmark isnt even trying
That would seem to indicate the Proxmark3 listener in the server has some kind of problem. Try running the server manually in the console (as root) with the -d parameter. It’ll dump runtime error messages on the console. That should tell you what’s wrong with it.
You should see the PM3’s lights flashing quite a lot if the listener is talking to it.
yes, listner has a problem alright… It DIED!
sudo sirfidal_server.py -d
[server] Started
[proxmark3_listener] [proxmark3_#1] Started
[proxmark3_listener_sigchld_handler] [proxmark3_#1] Proxmark3 client died
[proxmark3_listener] [proxmark3_#1] [Errno 13] Permission denied: ‘/usr/local/bin/proxmark3’
permissions for that folder are: drwxr-xr-x 22 root root 4096 Nov 22 17:11 proxmark3
and within that folder point of interest is
-rwxr-xr-x 1 root root 17037 Nov 22 17:11 pm3
Ah ok I see the issue.
The client parameter in the server should point to the executable, not the directory it runs in. Mine installed the binary in /usr/local/bin, while yours made a /usr/local/bin/proxmark3 directory and there’s a pm3 binary inside it. Or so it seems.
So the parameter in the server should be /usr/local/bin/proxmark3/pm3 in your install.
One way to find out exactly where the executable is located is to run which pm3 (if your PM3 client binary is called “pm3” of course, which seems to be the case on your machine).
thats correct - I was thinking there may be an issue reading the directory in my home dir, so I coppied the whole git to that location.
Ive updated it to client field pointing at /usr/local/bin/proxmark3/pm3 (that shouldn’t have .py at the end should it? Edit:Never mind- I see its a script not .py)
which pm3 does not respond with anything - is this because it needs to be added to my PATH variable?
after a reboot, stoping the service with systemctl, then running manually currently gives:
[proxmark3_listener] [proxmark3_#1] Started
[pcsc_listener] [pcsc_readers] Started
[pcsc_listener] [pcsc_readers] No readers
[proxmark3_listener_sigchld_handler] [proxmark3_#1] Proxmark3 client died
[proxmark3_listener] [proxmark3_#1] Error reading Proxmark3 client’s stdout
[pcsc_listener] [pcsc_readers] No readers
[pcsc_listener] [pcsc_readers] No readers
by the way I love that your code has provisioned for multiple readers of the same type and concurrent serials with differing baud, thats really thorough
The thing with the PM3 client is this: the SiRFIDaL server calls it as if it were an ordinary user (as root, but still as if it was run manually) and then issues commands to it.
So if you (as root) can manually cd into /tmp, invoke the absolute path of the PM3 client’s executable as declared in the server parameters and get a prompt, it should work with the server too - because essentially, that’s exactly what the server does.
If the PM3 client throws a fit when you try to run it manually that way, it’ll throw a fit when the server tries to run it too. And that manifests itself as the server telling you the PM3 client died (because most likely it started then immediately stopped) and telling you it can’t read its stdout because, well, the client has died
It’s kind of a hacky thing to do, talking to the PM3 through the interactive client that way. It would be much better if the SiRFIDaL server talked to the device directly. Unfortunately, the PM3’s API is quite a moving target, and the only things that can be relied upon to be somewhat stable from one release to the next is the PM3 client’s user-facing commands. Hence this kludge.
By the way, which client / firmware are you running? Iceman’s? I seem to recall his client compiled as a proxmark3 binary, not pm3, so that’s a bit surprising.
Thanks! It wasn’t like that until recently. But I run multiple readers on my machines, and so does one user in an industrial setting that needed 10 of them connected at the same time. So I recently took the time to turn my huge pile of copy/pasted stuff into a more nicely organized and more versatile pile of copy/pasted stuff
yes, I tried it just after I wrote my last response- sudo /usr/local/bin/proxmark3/pm3 works fine although I notice this message just after the PM3 launch artwork-
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-root’
Correct -its the iceman version, here is the displayed info.
[ CLIENT ]
RRG/Iceman/master/v4.14434-89-g85fb51564 2021-11-17 22:27:14
compiled with… GCC 11.2.0
platform… Linux / x86_64
Readline support… present
QT GUI support… present
native BT support… present
Python script support… present
Lua SWIG support… present
Python SWIG support… present
[ PROXMARK3 ]
firmware… PM3 GENERIC
[ ARM ]
bootrom: RRG/Iceman/master/v4.14434-89-g85fb51564 2021-11-11 21:51:00
os: RRG/Iceman/master/v4.14434-89-g85fb51564 2021-11-17 22:27:39
compiled with GCC 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
I wonder, could it be something regarding permission to access the USB device, do I need a udev rule or something?
It should work without any special permissions, since the server runs as root.
One question: does /dev/ttyACM0 exist when the PM3 is connected? The server will literally try to run the command /usr/local/bin/proxmark3/pm3 /dev/ttyACM0 as defined in your parameters. If the serial device file doesn’t exist, that will cause the PM3 client to quit immediately.
Yep, it’s /dev/ttyACM0