Project

General

Profile

Actions

Bug #6181

open

Unexpected INS code with simtrace2-sniff: 0x7f

Added by v.marinos 6 months ago. Updated 4 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/15/2023
Due date:
% Done:

0%

Spec Reference:

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

full_registration_4.pcap full_registration_4.pcap 111 KB v.marinos, 09/15/2023 03:34 PM
full_registration_5.pcap full_registration_5.pcap 31.5 KB v.marinos, 09/15/2023 07:25 PM
Actions #1

Updated by v.marinos 6 months ago

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.

Actions #2

Updated by laforge 4 months ago

  • Assignee set to laforge
Actions #3

Updated by laforge 4 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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)