search

yarrick / scsniff

Linux tool for sniffing smartcard communication between card and reader using season interface.
https://code.kryo.se/scsniff/
ISC License
35 stars 9 forks source link

pcap file / wireshark #1

Open laf0rge opened 2 years ago

laf0rge commented 2 years ago

you are correct in that there is no data link type for ISO7816 specifically.

However, the GSMTAP pseudo-header can encapsulate ISO7816 APDUs. You would have to combine the Command-APDU and Response APDU, wrap in in GSMTAP and then you can feed it into wireshark (GSTMAP UDP port 4729) or store a pcap and then open it in wireshark or offline processing.

This is how we're doing it in the Osmocom SIMtrace/SIMtrace2 project (https://osmocom.org/projects/simtrace2/wiki)

yarrick commented 2 years ago

Thanks, I will take a look at that!

https://github.com/osmocom/libosmocore/blob/master/include/osmocom/core/gsmtap.h

yarrick commented 1 month ago

I tried implementing this. I did not use the APDU subtype but the other ones to keep the same granularity of the communication as what is logged. The GSM SIM parser seems be hardcoded to use APDU subtype regardless of what is sent (see attached zipped pcapng file)

scsniff_gsmtap.zip

yarrick commented 1 month ago

Sent https://gitlab.com/wireshark/wireshark/-/merge_requests/16896 to at least fix ATR, could do more if accepted

laf0rge commented 1 month ago

I tried implementing this. I did not use the APDU subtype but the other ones to keep the same granularity of the communication as what is logged. The GSM SIM parser seems be hardcoded to use APDU subtype regardless of what is sent (see attached zipped pcapng file)

I see. Indeed we ever only used the APDU sub-type so far, as SIMtrace + SIMtrace2 always combines the command + response apdu into one packet before sending it to GSMTAP. This is also slightly due to an architectural constraint in wireshark, where it's much easier (programmatically) and more usable from the UI if you have all relevant bits in one packet vs. having to have a separate code module which then puzzles which packets belong together.

In general I've pretty much given up on using wireshark for viewing SIM/UICC/USIM/ISIM/eUICC traces, but use pySim-trace for that now. The advantage is that one can more asily aggregate multiple commands like SELECT + READ BINARY together (in the end, the user cares from whihc file was read, not that those are two separate low-level operations) and we have all the decoders for the file contents in pySim already, so we can provide a decode of the contents of the binary data that was read/written. Like the wireshark decoder, the input format is complete C+R APDUs in various formats (including GSMTAP SIM APDU as used by wireshark).

I know this is all very telecom specific, I'm just sharing the status quo, in case it may be relevant.

Splitting the APDU from the ATR in wireshark definitely makes sense, and it would pave the way for a dedicated ATR dissector plugin.

yarrick commented 1 month ago

Thanks. I will have a look how much work it is to get more TPDU parsing in place - it seems like the current gsm sim code could be mostly reused. New SIM subtypes would be needed for T=1 protocol TPDUs also if I get that far.