Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pcap file / wireshark #1

Open
laf0rge opened this issue Jul 28, 2022 · 5 comments
Open

pcap file / wireshark #1

laf0rge opened this issue Jul 28, 2022 · 5 comments

Comments

@laf0rge
Copy link

laf0rge commented Jul 28, 2022

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
Copy link
Owner

yarrick commented Jul 30, 2022

@yarrick
Copy link
Owner

yarrick commented Aug 18, 2024

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
Copy link
Owner

yarrick commented Aug 18, 2024

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

@laf0rge
Copy link
Author

laf0rge commented Aug 19, 2024

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
Copy link
Owner

yarrick commented Aug 21, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants