RFIDIOt: Python Tools for RFID and NFC Exploration

What RFIDIOt is and who it targets

RFIDIOt is a collection of tools and libraries for exploring RFID and NFC technology, written in Python. The author describes the project as coming from an idiot's point of view: someone who knew nothing about RFID tags or Python when starting. That framing is honest about the audience. RFIDIOt is for researchers, hardware tinkerers and security testers who want to read and analyse cards directly rather than use a vendor application. It is not a consumer wallet or a payment product. The code is free software under the GNU General Public License version 2 or later, and the copyright runs from 2006 to 2026.

How RFIDIOt talks to readers

The README lists three reader families. libnfc readers based on the PN53x chip, such as the ACR122U and SCL3711, are selected with -R READER_LIBNFC or -f followed by a reader index, and libnfc must be installed separately. PC/SC readers are the default, accessed through pyscard and pcscd with -R READER_PCSC; the subtype is auto-detected among ACS, OMNIKEY and SCM, and both T=0 and T=1 cards are handled. The original ACG and Frosch serial readers use -R READER_ACG or -R READER_FROSCH with a serial port given through -l, for example /dev/ttyUSB0. Any tool accepts -h for its full option list, and docs/readers.md holds per-model launch commands for devices such as the SCL3711, ACR122U, ACR122U-WB-R via -f ccid, OMNIKEY 5321 and Chameleon Ultra. One caveat worth noting: the OMNIKEY CardMan 5321 contact slot works with the open libccid driver, but its contactless 13.56 MHz interface needs HID's proprietary OMNIKEY driver, ifdokccid. With that driver installed the contactless interface shows up as a second PC/SC slot, selected with -r 1.

ChAP.py and EMV card analysis

ChAP.py, short for Chip And PIN, is the headline addition in the Python 3 version. It is a contactless and contact EMV reader that works over both PC/SC and libnfc, with the reader chosen through the standard options such as -f 0 for libnfc or -r 1 for a PC/SC contactless slot. It walks the card through PPSE, AID, GPO and records, decodes the EMV BER-TLV fields including AIP, AFL, the CVM list, CDOL and DDOL, Track 2 split into PAN, expiry and service code, and cryptogram information, and reads the card's transaction log with amount, date, time, currency and ATC per entry. With -c it performs full offline data authentication: it recovers the CA to Issuer to ICC certificate chain from a bundled table of 26 scheme CA keys covering Visa, Mastercard, Amex, CB, JCB, Discover, UnionPay and RuPay, each checked against its EMVCo CAPK checksum, then verifies the card's signature by whichever method the card supports. Those methods are SDA using tag 93, DDA through INTERNAL AUTHENTICATE with a random challenge on contact cards, fDDA using the fast-DDA signature returned in the GPO on contactless cards, and CDA where the signature is combined with the cryptogram. The -g flag sends GENERATE AC for CDA, which is intrusive because it increments the card's ATC. Companion or alias applications such as LINK verify under the primary scheme's CA. The recovery is self-validating, so a wrong or missing key fails cleanly. Running with no PIN argument keeps the tool read-only; a PIN argument sends an offline VERIFY, plaintext or RSA-enciphered with -E, which updates the PIN Try Counter.

Passports, passive authentication and other tools

Beyond EMV, mrpkey.py reads ePassports and passiveauth.py performs Passive Authentication, checking data-group integrity and DS or CSCA trust against a public CSCA master list and flagging a passport as SAFE, TAMPERED or UNTRUSTED. rfidiot-cli.py also reads contactless EMV. The repository contains dozens of scripts for Mifare, HITAG, FDX-B, JCOP and Chameleon Ultra work, plus an Android client and a Java directory, so the scope is much wider than a single reader wrapper. The README points to http://www.rfidiot.org/documentation.html for the full list, which means the documentation lives on the project website rather than in the repository.

Installing RFIDIOt and running a first tool

The README gives a short install sequence. First install the Python dependencies, then run setup.py with sudo.

pip install -r requirements.txt

sudo python3 ./setup.py install

The requirements file pins pycryptodome at 3.20.0 or newer and also lists pyscard, Pillow, pyasn1 and pyserial, with notes that passiveauth.py needs the openssl command-line tool and mrpkey.py needs Pillow's ImageTk plus tkinter. For PC/SC readers the daemon and CCID driver must be installed and running, for example on Debian or Ubuntu.

sudo apt install pcscd libccid pcsc-tools

For libnfc readers, libnfc itself must be installed separately, and the README does not give those steps. Any tool can be queried for its options.

python3 ChAP.py -h

The project declares Python 3.8 or newer in pyproject.toml, so older interpreters are not supported. There is no packaged release to install from PyPI in the repository files, only the source tree and setup.py.

Hardware and driver caveats

RFIDIOt is only as good as the reader stack beneath it. libnfc is a separate dependency with its own build steps, which the README does not cover. The OMNIKEY 5321 contactless interface needs a proprietary HID driver, which limits out-of-the-box use on Linux distributions that ship only libccid. Serial readers need a device path such as /dev/ttyUSB0. The Python 2.7 code is frozen on the python2.7 branch and tagged v1.0-python2.7, and it will not run under Python 3, while this version will not run under Python 2. That split matters if you inherit old scripts. The repository also carries two different version numbers: setup.py reports 1.0 while pyproject.toml reports 1.0.1, so the canonical version is ambiguous.

RFIDIOt versus using libnfc or vendor tools directly

The alternative is to drive libnfc or a vendor SDK directly, or to use a higher-level framework such as Proxmark tooling. libnfc alone gives low-level access to PN53x readers but no EMV parser, no passport passive authentication and no transaction log decoder. RFIDIOt adds those analysis layers on top of reader access, which is the reason to adopt it. The trade-off is that you inherit a large script collection with uneven documentation and no release cadence beyond commits. If you only need to read a Mifare UID, a smaller tool is less work. If you need EMV offline authentication or ePassport validation, RFIDIOt is one of the few open options that ships the logic in Python.

Maintenance, licensing and upgrade cost

The last push to the default master branch was on 2026-10-14, five days before 2026-10-19, so the repository is clearly active. There are no GitHub releases, which means upgrades are commit-based and there is no changelog beyond CHANGES and PY3_NOTES.TXT. The license is GNU General Public License version 2 or later, as stated in the source header and the pyproject classifiers, so redistribution and derivative works carry copyleft obligations; this is a statement of what the files say, not legal advice. Dependencies are modest: pycryptodome, pyscard, Pillow, pyasn1 and pyserial, plus external binaries such as openssl and system daemons. The cost of staying current is tracking those system packages across operating systems, since RFIDIOt itself does not pin a full environment.

Editorial conclusion

Adopt RFIDIOt if you are a researcher or security tester who needs Python-level control over diverse RFID and NFC readers, EMV cards and ePassports, and who can install libnfc or a PC/SC stack. Skip it if you need a packaged release with a stable API, because the repository ships no GitHub releases and setup.py and pyproject.toml disagree on the version. Verify first that your reader is on the supported list in docs/readers.md and that pcscd or libnfc runs on your machine.

Frequently asked questions

Official sources

1. AdamLaurie/RFIDIOt on GitHub
2. Issues
3. Project website
4. README