scsniff - Smartcard sniffer for Linux, by Erik Ekman <erik@kryo.se>

Records communication between smartcard and reader, captured with
a smartcard data logger (also known as "season interface"),
and splits the traffic stream into packets.


Features:

- Basic parsing of ISO 7816-3
  * 'Answer to Reset' (ATR)
  * 'Protocol and parameters selection' (PPS)
  * Data exchange (using T=0 or T=1 protocol)
  to identify packets and their data direction.

- Follows baud rate and protocol changes seen in ATR & PPS messages.

- Expects new reset being sent after a few seconds of no communication,
  and detects unexpected resets (warm reset or deactivate).

- Identifies transfer direction for most T=0 data fields.

- Handles direct and inverse convention.


How to build:

Run `make`.


How to run tests:

With the check library (https://libcheck.github.io/check) installed,
run `make check`.


How to use:

You need a data logger which captures the smartcard communication and converts
it to RS-232 serial. The smartcard reset pin is expected to be connected to
Carrier Detect or Ring. If your logger has it connected to another pin, update
the RESET_PIN define in serial.c. See the ioctl_tty(2) manpage for details.

You need to know the starting baud rate being used. This depends on the clock
frequency used by the reader. If you can measure it while the reader is active,
the baudrate should be the frequency divided by 372. Nonstandard baudrates are
common, so your port (or USB adapter) needs to handle custom baudrates.

If you know what a specific card sends as ATR (Answer to reset, shown by
pcsc_scan tool) you can test different baud rates until scsniff can see the
same reply. It is normally around 9600 baud - try going up or down by
increments of 500 until you get the same result. In my testing I use 10500 for
the reader in my laptop and 5600 for a bank authentication device.

Once you have found the correct baudrate scsniff will output any communication
between the reader and the card. It will show the direction of the traffic when
it can be inferred (missing for some T=0 payloads).  With a data log similar to
the examples below, use the ISO 7816-3 (for transport layer) and 7816-4 (for
application data) specifications to decode the traffic.


Not yet supported:

- Saving data as pcap. There is not yet a datalink format that is suitable for
  intercepted ISO 7816-3 smartcard communication. Wireshark also does not yet
  have a dissector for ISO 7816-3 traffic.

- Detecting in ATR if CRC 16 error checking is enabled for T=1 protocol.

- Fully inferring data transfer direction for T=0 based on command parameters.


Sample session:

$ ./scsniff /dev/ttyUSB0 5600
== Opened /dev/ttyUSB0
== Speed: 5600 baud
== Waiting for reset..  Done
+0.023680s | CARD>>> | 3B 7F 18 00 00 43 55 32 69 AA 20 00 32 20 20 20 20 20 20 00
+0.072785s | CARD<<< | FF 10 13 FC
+0.083557s | CARD>>> | FF 10 13 FC
== Switching to 93 ticks per ETU (22400 baud) after PPS
+0.106063s | CARD<<< | 00 CA 01 00 00
+0.109960s | CARD>>> | 6C 16
+0.111310s | CARD<<< | 00 CA 01 00 16
+0.115236s | CARD>>> | CA
+0.115794s | CARD>>> | 43 6F 6D 62 4F 53 20 55 42 53 20 41 63 63 65 73 73 20 43 61 72 64
+0.128261s | CARD>>> | 90 00
^C


$ ./scsniff /dev/ttyUSB0 10500
== Opened /dev/ttyUSB0
== Speed: 10500 baud
== Waiting for reset..  Done
+0.017285s | CARD>>> | 3B FF 13 00 00 81 31 FE 45 43 44 32 69 A9 41 00 00 20 20 20 20 20 20 00 53
== Switching to protocol T=1 after ATR
+1.267620s | CARD<<< | 00 C1 01 FE 3E
+1.277641s | CARD>>> | 00 E1 01 FE 1E
+1.284177s | CARD<<< | 00 00 0C 00 A4 04 00 07 62 76 01 FF 00 00 00 41
+1.307725s | CARD>>> | 00 00 02 67 00 65
+1.324823s | CARD<<< | 00 40 0B 00 A4 04 00 06 A0 00 00 00 01 01 4D
+1.347225s | CARD>>> | 00 40 02 67 00 25
+1.362452s | CARD<<< | 00 00 11 00 A4 04 00 0B E8 2B 06 01 04 01 81 C3 1F 02 01 00 25
+1.398115s | CARD>>> | 00 00 02 6A 82 EA
+1.413817s | CARD<<< | 00 40 14 00 A4 04 0C 0F D2 33 00 00 00 45 73 74 45 49 44 20 76 33 35 4C
+1.446093s | CARD>>> | 00 40 02 6A 86 AE
^C