Difference between revisions of "RFID"

From YobiWiki
Jump to navigation Jump to search
Line 438: Line 438:
   
 
===Misc===
 
===Misc===
  +
* [http://fenbrook.com/ RFID Solutions]
 
* [http://en.wikipedia.org/wiki/USRP Universal Software Radio Peripheral]
 
* [http://en.wikipedia.org/wiki/USRP Universal Software Radio Peripheral]
 
* [http://www.rfidguardian.org RFID Guardian], see [http://rfidguardian.org/images/1/11/RF40-RevA-Catalog.pdf here] what they want to come with for v4, which is currently in alpha stage, first hardware rollout.
 
* [http://www.rfidguardian.org RFID Guardian], see [http://rfidguardian.org/images/1/11/RF40-RevA-Catalog.pdf here] what they want to come with for v4, which is currently in alpha stage, first hardware rollout.

Revision as of 18:47, 27 July 2010

Middleware: pcscd & libccid

There is no common RFID middleware yet but most readers rely or can rely on PC/SC
pcscd is the Linux daemon to access readers compatible with the PC/SC standard.
Most USB-based readers are complying with a common USB-CCID specification and therefore are relying on the same driver (libccid under Linux).
To dump the readers list supported by libccid of your pcscd install:

 cat /etc/libccid_Info.plist|gawk '
    /ifdVendorID/{
        mode=1
    }
    /ifdProductID/{
        mode=2
    }
    /ifdFriendlyName/{
        mode=3
    }
    {
        inarray=0
    }
    /<array>/{
        i=0
    }
    /<array>/,/<\/array>/{
        inarray=1
    }
    /string/&&inarray{
        match($0,/<string>(.*)<\/string>/,a);
        t[mode i]=a[1]; 
        i++
    }
    END{
        for (j=0;j<i;j++) 
            print t[1 j]":"t[2 j], t[3 j]
    }'

RFID readers

PN53x-based

NXP has a serie of NFC-compatible reader chips: PN531, PN532, PN533.
Here are some readers using one of those chips.

ACR122U

based on PN532

  • docs
    • ISO/IEC18092 (NFC) compliant
    • NFC Tags Access Speed = 212 kbps
    • Support FeliCa card
    • Support ISO 14443 Type A & B cards
    • MIFARE® cards (Classics, DESFire)
    • SAM Socket (optional)
  • To get the Firmware version string in command line: (actual string here is "ACR122U203" as the last 2 bytes are not SW1/SW2 but part of the string)
$ opensc-tool -s FF00480000
Sending: FF 00 48 00 00.
Received (SW1=0x30, SW2=0x33):
41 43 52 31 32 32 55 32 ACR122U2

You can also use scriptor:

$ echo ff00480000|scriptor           
No reader given: using ACS ACR122U PICC Interface 00 00
Using T=1 protocol
Reading commands from STDIN
> ff 00 48 00 00 
< 41 43 52 31 32 32 55 32 30 33 : Error not defined by ISO 7816

We're using a pseudo-ADPU which doesn't return the standard SW1/SW2 error codes, this is why scriptor gives an error which can be ignored and opensc-tool is interpreting wrongly the last two data bytes as ISO7816 error codes as well.
The proper decoding of the received data is:

$ echo ff00480000|scriptor 2>/dev/null |tail -n 1|xxd -p -r
ACR122U203

Tikitag / Touchatag model will return an older version:

ACR122U102

If you get the following error:

Can't allocate Chipcard::PCSC::Card object: No smartcard inserted.

that's because you've a model without SAM support. Place a tag on the reader and try again, it should work.

So that's where a lot of confusion comes into play: the two models behave very differently! See below
Note that this site points out that it also corresponds to a difference of firmware versions

ACR122U-SAM / Touchatag (was Tikitag)

Usage:

  • When there is a SAM inserted, ATR shown is the ATR of the SAM
  • When there is no SAM inserted, ATR shown is a pseudo-ATR = 3B 00
  • So for PCSC there is always a "card inserted"
  • To detect contactless card "insertion", application must do the polling
  • APDUs are sent to SAM
  • To send APDUs to a contactless card, you must wrap them into pseudo-APDUs (FF 00 00 00 ...)
  • To send special APDUs to the reader (to get fw or to control LEDs), just send them

Some more infos here and there about the Tikitag
Some more here
full technical reference of the SAM used in the Tikitag is supposed to be available here. There is a copy available here

ACR122U PICC

Usage:

  • When there is a contactless card, ATR shown is the ATR of the card
  • When there is no contactless card, no ATR
  • So for PCSC there is a "card inserted" if there is a contactless card
  • On contactless card "insertion", it generates a "card inserted" event
  • APDUs are sent directly to the contactless card, which makes this reader fully transparent in this mode
  • To send APDUs to a contactless card, you can also wrap them into pseudo-APDUs (FF 00 00 00 ...)
  • To send special APDUs to the reader (to get fw or to control LEDs)
    • If there is a contactless card, just send the APDUs
    • If there is no contactless card, the CCID Escape command must be used (*)

(*) Here is one small example how to use the Escape command:

#!/usr/bin/python
from smartcard.scard import *
hresult, hcontext = SCardEstablishContext( SCARD_SCOPE_USER )
hresult, hcard, dwActiveProtocol = SCardConnect(
hcontext, 'ACS ACR122U PICC Interface 00 00', SCARD_SHARE_DIRECT, SCARD_PROTOCOL_T0 )
IOCTL_SMARTCARD_VENDOR_IFD_EXCHANGE = SCARD_CTL_CODE(1)
CMD = [0xFF, 0x00, 0x48, 0x00, 0x00]
hresult, response = SCardControl( hcard, IOCTL_SMARTCARD_VENDOR_IFD_EXCHANGE, CMD )
if hresult!=SCARD_S_SUCCESS:
     raise error, 'Failed to control: ' + SCardGetErrorMessage(hresult)
print ''.join([chr(i) for i in response])

This requires also to allow libccid to use the Escape command, you've to set bit 0 of ifdDriverOptions in /etc/libccid_Info.plist to 1:

       <key>ifdDriverOptions</key>
       <string>0x0001</string>
       Possible values for ifdDriverOptions
       1: DRIVER_OPTION_CCID_EXCHANGE_AUTHORIZED
               the CCID Exchange command is allowed. You can use it through
               SCardControl(hCard, IOCTL_SMARTCARD_VENDOR_IFD_EXCHANGE, ...)

In case libccid refuses with a

Firmware (x.xx) is bogus! Upgrade the reader firmware or get a new reader.

you can force it by setting the third bit (0x04) of ifdDriverOptions in /etc/libccid_Info.plist to 1

       <key>ifdDriverOptions</key>
       <string>0x0005</string>
       Possible values for ifdDriverOptions
       1: DRIVER_OPTION_CCID_EXCHANGE_AUTHORIZED
               the CCID Exchange command is allowed. You can use it through
               SCardControl(hCard, IOCTL_SMARTCARD_VENDOR_IFD_EXCHANGE, ...)
       4: DRIVER_OPTION_USE_BOGUS_FIRMWARE 
               Some reader firmwares have bugs. By default the driver refuses 
               to work with such firmware versions. If your reader is rejected
               because of the firmware (log message: "Firmware (x.y) is 
               bogus!") you can: 
               - activate this option but you will have problems depending on the bug

Personally I found the reader quite unstable, it disconnects often from pcscd.
Even with vendor drivers instead of libccid. BTW I've no idea what this vendor version brings extra.

Another issue is that the generated ATR doesn't follow properly the PCSC standard for contactless for ISO14443-4 tags:
Where it should stuff the historical bytes of ATS into the generated ATR, it's stuffing the entire ATS, breaking tag detection done e.g. by pcsc_scan.
Moreover for e.g. a JCOP card, last bytes of the ATS are masked by 0xFF 0xFF 0xFF 0xFF.

Examples:

  • Desfire:
ATS:                        06 75 77 81 02 80
ATR by ACR122U: 3B 86 80 01 06 75 77 81 02 80 00
ATS hist bytes:             80
Expected ATR:   3B 81 80 01 80 80
  • JCOPv2.4.1:
ATS:                        0D 78 77 B1 02 4A 43 4F 50 76 32 34 31
ATR by ACR122U: 3B 8D 80 01 0D 78 77 B1 02 4A 43 4F 50 FF FF FF FF AB
ATS hist bytes:             4A 43 4F 50 76 32 34 31   (=JCOPv241)
Expected ATR:   3B 88 80 01 4A 43 4F 50 76 32 34 31 5E

The problem is known by ACS so they upgraded its firmware and released a v207.
So if you want to buy one, make sure to get at least a ACR122U-A2NR/207F, or newer if exists.
To temporarily fix the JCOP issue on ACR122U203, you can issue another command for full ATS reply: FF CA 01 00 00. This command follows PC/SC standard.

Arygon ADRA

based on PN531

Supported Standards:

  • ISO18092 ( NFC transport protocol)
  • Sony FeliCa
  • NXP Mifare ® family
  • compliant to ISO14443A, ISO14443A – 4 (T=CL)

Communication protocol:

  • ARYGON (HL - high level language), TAMA (LL - low level language)
    • To send TAMA frames, send an ascii '2' as first char, e.g. to get firmware of the PN531:
0x32 0x00 0x00 0xFF 0x02 0xFE 0xD4 0x02 0x2A 0x00
=>
0x00 0x00 0xFF 0x00 0xFF 0x00 (TAMA ACK)
0x00 0x00 0xFF 0x04 0xFC 0xD5 0x03 0x02 0x02 0x24 0x00 (TAMA v=2.2)
echo 32 00 00 ff 02 fe d4 02 2a 00|xxd -p -r|socat - /dev/ttyUSB0|xxd -p
0000ff00ff000000ff04fcd50304022200

Baud rate (passive/active):

  • 106 kBaud, 212 kBaud, up to 424 kBaud
  • USB, seen as a serial port

Apparently they propose a PCSC driver for Redhat 32-bit but it segfaults on a Debian 32-bit

PN531

The PN531 is capable of speaking directly USB so there exist readers consisting simply of the PN531 wired to your Pc via USB.
In that case, the vendorID/productID will be either 04CC:0531 or 054c:0193

Apparently the following products are like that:

PN533

  • Official site: http://www.nxp.com/#/pip/pip=[pfp=53424]|pp=[t=pfp,i=53424]

The PN533 is capable of speaking directly USB so there exist readers consisting simply of the PN533 wired to your Pc via USB.
vendorID/productID may vary, e.g. 04CC:2533 or for SCL3711: 04E6:5591


The following products are embodiments of a PN533:

CL RC632 -based

OpenPCD

Pegoda

  • See http://www.nxp.com/#/pip/pip=[pfp=41960]|pp=[t=pfp,i=41960]
  • Almost no opensource support, just an embryonic one in librfid

Omnikey 5321

  • datasheet
  • ISO 14443 A/B and 15693 ( up to 848 Kbps in the fastest ISO 14443 transmission mode)
  • APIs: PC/SC, Synchronous-API (on top of PC/SC), OCF (Open Card Framework) or CT-API
  • contactless smartcards supported:
    • HID: iCLASS®
    • NXP: MIFARE®, DESFire®, SMART-MX and ICODE
    • Texas Instruments: TagIT®
    • ST Micro: x-ident, SR 176, SR 1X 4K
    • Infineon: My-d (in secure mode UID only)
    • Atmel: AT088RF020
    • KSW MicroTech: KSW TempSens
    • iCODE SLI, iCODE SL2 & LRI 64
    • Contactless 2048 bit key generation in RSA mode (JCOP / SMART-MX)

Installing OmniKey reader under linux:

There are drivers here

But there is also a Debian package pcsc-omnikey
Warning! Don't install it or it will remove libccid!!
It's better to keep libccid if needed for other readers and install the missing RFID driver by hand: (here on a 64-bit platform)

aptitude download pcsc-omnikey
dpkg -x pcsc-omnikey_1%3a2-4_amd64.deb .
cp -a usr/lib/pcsc/drivers/ifdokrfid_lnx_x64-2.6.0.bundle /usr/lib/pcsc/drivers/

See here: you need also to recompile pcscd with libusb:

./configure --disable-libhal --enable-libusb

To do it by repackaging the Debian pcscd:

aptitude install libusb-dev
apt-get source pcscd
apt-get build-dep pcscd
--- debian/rules        2009-01-14 13:54:42.000000000 +0100
+++ debian/rules        2009-01-14 13:46:56.000000000 +0100
@@ -38,6 +38,8 @@
        dh_testdir
        # we add LDFLAGS="-lpthread" for bug #253629
        ./configure $(confflags) \
+               --disable-libhal \
+               --enable-libusb \
                --sysconfdir=/etc \
                --prefix=/usr \
                --enable-usbdropdir=/usr/lib/pcsc/drivers \

Then

dpkg-buildpkg -uc -us

To launch the modified pcsc in foreground, showing ADPUs and debug info: (here pcscd was installed in /usr/local/bin/pcscd-libusb)

pcscd-libusb -f -a -d

UPDATE: I've tried successfully the latest drivers from Omnikey on Debian Squeeze (pcscd 1.5.5) without too much hassle:

  • Get from here either ifdokrfid_lnx-2.7.0.tar.gz or ifdokrfid_lnx_x64-2.7.0.tar.gz depending if you're using a 32 or 64-bit OS.
  • Copy the directory ifdokrfid_lnx-2.7.0.bundle to /usr/lib/pcsc/drivers and the file cmrfid.ini to /etc

That's it. No need to recompile pcscd or to mangle /etc/libccid_Info.plist

SpringCard Prox'N'Roll

Gives a lot of control by means of ADPUs.
Mainly useful to have full access to ISO15693 commands or to perform "strange" things on ISO14443 like sending ISO14443-4 commands to an ISO14443-3 card (which you can also do with PN53x but PN53x doc is under NDA)

Others

ACG LF / OMNIKEY 5534

Adam Laurie is selling via his RFIDiot website some ACG LF readers, either with their native serial interface or with a USB interface.
Those readers are based on a module from ACG, now relabeled as Omnikey since they're owned by HID:
RDLO-0101N0
aka OMNIKEY 5534 Core MultiTag Reader
aka ACG LF MultiTag OEM Module

  • 125 & 134.2 kHz
  • Supports: EM4x02, EM4x50, EM4x05 (ISO 11784/5 FDX-B), Hitag 1 / 2 / S, Q5, TI 64 bit R/O & R/W, TI 1088 bit Multipage

You can modify the default serial port speed by modifying byte 0Ch in EEPROM. Mine is working at 57600 baud.
USB version is actually using a FTDI USB Serial Device converter and so will simply be identified on your linux as the serial port /dev/ttyUSB0

Usage example with RFIDiot tools:

readlfx.py -R RFIDIOt.rfidiot.READER_ACG -s 57600

Usage example in console:

cu -l /dev/ttyUSB0 -s 57600

Short quickref for console usage:

~.   quit cu
!    test continuous read -> ! if active, F if not
c    continuous read      -> poll, any key to stop -> S
dX   set tag settings     -> dH80 gain=2 sampling_time=0
l    login                -> lMIKR -> L=ok X=fail N=no_tag
oX   set tag type         -> oH
o+X  include tag type
o-X  exclude tag type
poff antenna power off
pon  antenna power on
rb   read block           -> rb00  -> 4 bytes
wb   write block          -> wb0011223344
rp   read EEPROM
wp   write EEPROM
s    select               -> poll once
v    get version
x    reset
y    field reset          -> y8080 off time in ms + recovery time in ms

Misc

SDCard shaped

Not sure which ones are actually available for purchase and which ones are just vaporware...

Other Hardware Tools

RFID killers

RFID skimmers

RFID emulators

OpenPICC

Use ARM toolchain, e.g. [1], add arm/bin/ to the path

svn co -r432 http://svn.openpcd.org/branches/sniffonly/openpicc/
cd openpicc
make

You may try later revision but at least r432 is compiling and working.
If you don't get a /dev/usbTTYx to flash the beast, load the driver by hand:

modprobe -r usbserial
modprobe usbserial vendor=0x03EB product=0x6124

If ./at91flash_automatic openpicc.bin failed, edit at91flash => /dev/ttyUSB0 then

./at91flash openpicc.bin

Unplus & replug, you'll get a /dev/ttyACM0

  • Using:

Whatever talking serial:

socat - /dev/ttyACM0,raw,echo=0,crnl,b115200 
cu -l /dev/ttyACM0 -s 115200 
screen /dev/ttyACM0 115200 

h for help, f for field strength measure
To sniff raw data, you've to convert the hexadecimal stream if you want to display it, e.g. with

(echo r;cat)|socat - /dev/ttyACM0,raw,echo=0,crnl,b115200 |xxd

Note that you can still send commands to the OpenPICC, e.g. "r" to stop sniffing, CTRL-D to quit
To sniff and get decoded frames (from reader only, for tag you would need a OpenPCD)

svn co -r432 http://svn.openpcd.org/branches/sniffonly/host/
cd host
make

Usage:

./openpicc-sniff-14443a /dev/ttyACM0

To get just the raw stream:

./openpicc-sniff-14443a /dev/ttyACM0|cut -c 50-|sed 's/\([0-9A-F]\+\) [01]!\? */\1/g'
  • Using under Windows:

Plug it, let Windows finding the new hardware -> search software? -> no -> install from specific location -> search/include/browse -> svn/branches/sniffonly/openpicc/win32driver (OpenBeaconUSB.inf) -> continue anyway
To communicate, use whatever talking serial, e.g. Start->Accessories->Communications->HyperTerminal -> new connection -> COM4 -> 115200/8/N/1/None -> try e.g. "h" -> File -> Save

  • Debug

In case of trouble, you can get more lucky with the debug cable (115200/8/N/1 3v3)

  1. GND
  2. CTS# - shorted
  3. VCC - provided! not to be connected to external Vcc
  4. TXD
  5. RXD
  6. RTS# - shorted

Proxmark III

Originally created by J.Westhues: here, video in action here

  • manual, see also this pdf
  • forum
  • files, require login
  • can read, sniff & emulate
  • 13.6MHz, 125kHz and 134kHz
  • 20090306_proxmark_edo512 version of the firmware/client is currently the latest available, running on both Windows and Linux
  • Some troubles under Linux in USB2.0 mode, better to force USB1.1: Plug the proxmark in an USB 1.1 hub or unload ehci_hcd kernel module
    It may happen that if you send a command to the Proxmark while it's busy (e.g. in simulate mode), you get stuck and even re-plugging the board doesn't help.
    Remove then the ehci_hcd and uhci_hcd modules, then install uhci_hcd again.

Extracting the reader datastream (to be compared with OpenPICC results)

cat dump |grep -v TAG|cut -c 21-|sed 's/!crc.*//;s/\([0-9a-f]\+\)[[:space:]]*/\1/g'|tr a-z A-Z

Getting both directions

cat dump |sed 's/:     /+/;s/: TAG /-/'|cut -c 15-|sed 's/!crc.*//;s/\([0-9a-f]\+\)!\?[[:space:]]*/\1/g'|tr a-z A-Z

Demo: Cloning a Verichip

Update: source code is on Google Code since a few months now and is progressing frequently.
Even if you don't have the board, some tools can be used offline.
To compile the host client without the ARM toolchain:

apt-get install gcc g++ libreadline-dev libusb-dev libqt4-dev pkg-config
make client

IAIK RFID DemoTag

Open RFID Tag

125kHz cloners and emulators

Misc

Software Tools

librfid

librfid is a Free Software RFID library. It implements the PCD (reader) side protocol stack of ISO 14443 A, ISO 14443 B, ISO 15693, Mifare Ultralight and Mifare Classic.
It works mainly with OpenPCD and Omnikey Cardman 5121/5321
It drives directly the readers and so doesn't use pcscd which must be stopped.
See this blog post how to install and use it to read an ISO15693.
To get the tool working properly I had to compile statically the tools (svn r2107), otherwise I get segfaults when trying to read tags:

# apt-get install libusb-dev
$ svn co https://svn.gnumonks.org/trunk/librfid/
$ cd librfid/
$ ./autogen.sh
$ ./configure --enable--ccid --disable-shared
$ make

Then you can read content of ISO15693 from e.g. Infineon, NXP iCode and TI Tag-IT.
Scan for tag: (user must have the right to use libusb, otherwise do it as root)

$ ./utils/librfid-tool -s


Read tag till the first error occurs

$ ./utils/librfid-tool -r -1


Internally it's using the ISO15693 optional command "Read Single Block" but EM Microelectronic Marin cards only support the other optional "Read Multi Blocks" command.
Here is a quick hack to change the librfid read command (but then it won't be able to read NXP iCode which only supports "Read Single Block"...)

--- rfid_layer2_iso15693.c.orig	2010-03-11 19:02:54.000000000 +0100
+++ rfid_layer2_iso15693.c	2010-03-11 19:08:57.000000000 +0100
@@ -45,12 +45,14 @@
 	struct iso15693_request head;
 	u_int64_t uid;
 	u_int8_t blocknum;
+	u_int8_t nrblocks;
 	u_int8_t data[0];
 } __attribute__ ((packed));
 
 struct iso15693_request_block_selected {
 	struct iso15693_request head;
 	u_int8_t blocknum;
+	u_int8_t nrblocks;
 	u_int8_t data[0];
 } __attribute__ ((packed));
 
@@ -166,7 +168,7 @@
 
 	rx_len = sizeof(resp);
 
-	tx_req.sel.head.command = ISO15693_CMD_READ_BLOCK_SINGLE;
+	tx_req.sel.head.command = ISO15693_CMD_READ_BLOCK_MULTI;
 
 	if (handle->priv.iso15693.vicc_fast){
 		tx_req.sel.head.flags |= RFID_15693_F_RATE_HIGH;
@@ -183,12 +185,14 @@
 	if (handle->priv.iso15693.state==RFID_15693_STATE_SELECTED) {
 		tx_len = sizeof(struct iso15693_request_block_selected);
 		tx_req.sel.blocknum = blocknr;
+		tx_req.sel.nrblocks = 0;
 		tx_req.sel.head.flags |= RFID_15693_F4_SELECTED;
 	} else {
 		tx_len = sizeof(struct iso15693_request_block_addressed);
 		memcpy(&tx_req.addr.uid, handle->uid, ISO15693_UID_LEN);
 		tx_req.addr.head.flags |= RFID_15693_F4_ADDRESS;
 		tx_req.addr.blocknum = blocknr;
+		tx_req.addr.nrblocks = 0;
 	}
 
 	//DEBUGP("sizeof: addr: %d sel:%d\n",sizeof(struct iso15693_request_read_addressed),sizeof(struct iso15693_request_read_selected));

RFDump

RFDump is a backend GPL tool to directly interoperate with any RFID ISO-Reader to make the contents stored on RFID tags accessible.

RFIDIOt

RFIDIOt is an open source python library for exploring RFID devices

apt-get install python-pyscard
$ ./mrpkey.py -L
PCSC devices:
   No: 0               OMNIKEY CardMan 5x21 00 00
   No: 1               OMNIKEY CardMan 5x21 00 01
$ ./mrpkey.py -r 1 CHECK
mrpkey v0.1n (using RFIDIOt v0.1s)
 Reader: PCSC OMNIKEY CardMan 5x21 00 01
 Device is a Machine Readable Document
$ ./mrpkey.py -r 1 "EXnnnnnn<cBELyymmddcSyymmddc<<<<<<<<<<<<<<cc"

To fix reader number, edit RFIDIOtconfig.py
In MRZ passport number is coded with 9 chars. Belgian uses only 8 chars so some passport readers need a document number padded with char "<" ("EXnnnnnn<")

To use mrpkey under Windows you need:
python, pyscard, pyserial, pywin32, pycrypto, python imaging library

GNU Radio

GNU Radio is a collection of software that when combined with minimal hardware, allows the construction of radios where the actual waveforms transmitted and received are defined by software. What this means is that it turns the digital modulation schemes used in today's high performance wireless devices into software problems.

pwnpass

RFID tool by 3ric Johanson (get info from rfid on credit cards), presented at Shmoocon 2009
See also this video showing it demo'd
See here(pdf) a technical report of the vulnerabilities of RFID credit cards and here info on PayPass 3000 reader

libnfc

Open source library for Near Field Communication (NFC) using readers based on PN531/PN532/PN533 chips. The library comes with examples demonstrating read, emulation & relay attack by exploiting a "hidden" raw mode of those chips.

To compile:

apt-get install automake1.9 libtool pkg-config libusb-dev libpcsclite-dev libreadline5-dev
./autogen.sh
make
make install

See also nfc-tools, pynfc (python bindings), mtools (GUI) and micmd projects

libndef

This is a C++ library for use in reading and writing messages based on NDEF (NFC Data Exchange Format) Specification.

SpringCard

Offers a SDK for their reader but somehow compatible with e.g. the Omnikey 5321, see here especially the two PCSC-SDK

See also their NFC tools and their Calypso Explorer

SMACADU

Smart Card Digging utilities (Windows)

Cardpeek

is a Linux tool to read the contents of ISO7816 smartcards. It uses a PC/SC reader to communicate with the card, and its GTK GUI represents card data is a tree view. Cardpeek list of supported cards is expandable thanks to a scripting language. Currently, the tool can explore EMV cards, Calypso cards, Moneo cards (french ePurse) and Vitale (french health card) (from SpringCard's Blog)
Installation on Debian: see INSTALL, you need to install also lua5.1 and liblua5.1-0-dev

apt-get install liblua5.1-0-dev automake1.10 libssl-dev libgtk2.0-dev

SCard SOFT

A Russian software company making stuff to explore smartcards

TagEventor

A Linux open-source client for the Touchatag (Tikitag).
It uses the PCSC-Lite daemon and can be run in foreground or daemon mode to make tag events available to user-space applications.

About ePassports

Specific applications

ePassport

MOBIB/Calypso

see dedicated page

Cambio

Mifare Classic

  • crapto1
  • tk-libnfc-crapto1/mfcuk & mfoc, does not work against MFC emulation on e.g. JCOP or Mifare Plus

Privacy

Privacy: Legal European Framework

see the above link for a general introduction and a list of RFID-related items

Miscellaneous articles

Misc documentation

Shopping

Maybe more expensive, less stuffed or for specific material: