Bug #6181
openUnexpected INS code with simtrace2-sniff: 0x7f
0%
Description
Hello,
I used `simtrace2-sniff` to sniff the messages between my sysmocom SIM cards and a Google Pixel 5, during 5G SA registration. I captured the traffic with tcpdump over port 4729 (pcap file attached).
I am using Open5GS and srsRAN (5G) for the core and RAN respectively. The phone connects to the core successfully and has internet access.
When I replay the captured messages with pySim-trace I get the following error: "ValueError: Unknown CLA=A4 INS=7F". Wireshark also shows the same INS code, as Unknown (0x7f).
I looked at ETSI TS 102 221 V17.1.0 (2022-02), Table 10.5, and couldn't find any reference of APDU with INS code 0x7f.
Do you have any insights on why this APDU is showing up?
Thanks,
Marinos
Files
Updated by v.marinos 8 months ago
- File full_registration_5.pcap full_registration_5.pcap added
Edit: After flashing the latest firmware (0.8.1.66-e6e7), I get the same error, but with different INS code:
`ValueError: Unknown CLA=83 INS=01`
This also doesn't seem to be in the 3GPP standard. Updated pcap is attached.
Updated by laforge 6 months ago
- Status changed from New to Feedback
- Assignee changed from laforge to v.marinos
Sorry to hear about your troubles.
However, the problem is not in the pySim-trace decoder, but in the actual decode. The APDU trace is corrupted. This might be either a problem with physical/bad contact, signal integrity, or anything else in the area of the acquisition of the trace (such as software bug in the simtrace2 firmware, some kind of overrun betwene UART and USB, ...).
If you look in wireshark, everything up and including packet 305 looks fine, but from 306 onwards they are no longer matching the expected APDU structure.
