Project

General

Profile

Issue #1909

Old French SFR SIM with PIN code setup card not detected

Added by Denis 'GNUtoo' Carikli 2 months ago. Updated 9 days ago.

Status:
New
Priority:
Normal
Category:
SIM card not recognized
Target version:
Start date:
02/06/2019
Due date:
% Done:

0%

Spent time:
Resolution:
Device:

Description

I've found a SIM card that isn't detected by libsamsung-ipc:
  • On the Galaxy S 2 (i9100) with libsamsung-ril and libsamsung-ipc, the card "isn't detected"
  • On an HTC Dream, it asks for a PIN.

As I don't know if the issue is the same than the other ones, and that I can easily reproduce it, I started looking at it from scratch and gathered logs on the Galaxy S2 both with this sim and another SIM that is working and that was setup to ask for a PIN code.

I've also removed the STK Android application that is part of stock Replicant installation to look if it would work without, but it didn't. All the test mentioned below were carried out with the STK Android application removed.

I still need to look deeper in the relevant source code, but I found that the main differences between the working and the non-working SIM card were:
  • The non-working SIM card sends proactive Sim Toolkit commands, which were observed with simtrace and through libsamsung-ipc logging: libsamsung-ipc/samsung-ril receive a IPC_SAT_PROACTIVE_CMD command very early on and continue sending one or more of such commands.
  • With the non-working SIM card, the Android framework didn't manage to retrieve the SIM ID, whereas that sim ID can clearly be found in the logs gathered with simtrace. After trying to get the SIM ID, with the working SIM card, we have "insertedSimCount = 1" in the logs whereas with the nonworking we have: "insertedSimCount = 0"

good-orange-sim-no-stk-app-with-simtrace_until-sim-pin.pcap.pcapng.gz (80.3 KB) Denis 'GNUtoo' Carikli, 02/06/2019 08:00 PM

good-orange-sim-no-stk-app-with-simtrace_until-sim-pin.log View (305 KB) Denis 'GNUtoo' Carikli, 02/06/2019 08:01 PM

bad-sfr-sim-no-stk-app-with-simtrace.pcap.pcapng.gz (72.7 KB) Denis 'GNUtoo' Carikli, 02/06/2019 08:01 PM

bad-sfr-sim-no-stk-app-with-simtrace.log View (278 KB) Denis 'GNUtoo' Carikli, 02/06/2019 08:02 PM

History

#5 Updated by Denis 'GNUtoo' Carikli 2 months ago

Working Orange SIM:

02-06 13:47:56.903  2786  2786 D SubscriptionInfoUpdater: handleMessage : <EVENT_SIM_LOCKED_QUERY_ICCID_DONE> SIM1
02-06 13:47:56.903  2786  2786 D SubscriptionInfoUpdater: sIccId[0] = 89330178269030170700
02-06 13:47:56.903  2786  2786 D SubscriptionInfoUpdater: All IccIds query complete
02-06 13:47:56.903  2786  2786 D SubscriptionInfoUpdater: updateSubscriptionInfoByIccId:+ Start
02-06 13:47:56.903  2786  2786 D SubscriptionInfoUpdater: insertedSimCount = 1

Whereas on the nonworking SFR SIM we have:

02-06 13:45:10.553  2773  2773 D SubscriptionInfoUpdater: handleMessage : <EVENT_SIM_LOCKED_QUERY_ICCID_DONE> SIM1
02-06 13:45:10.553  2773  2773 D SubscriptionInfoUpdater: Query IccId fail: java.lang.NullPointerException: Attempt to read from null array
02-06 13:45:10.553  2773  2773 D SubscriptionInfoUpdater: sIccId[0] =
02-06 13:45:10.553  2773  2773 D SubscriptionInfoUpdater: All IccIds query complete
02-06 13:45:10.553  2773  2773 D SubscriptionInfoUpdater: updateSubscriptionInfoByIccId:+ Start
02-06 13:45:10.553  2773  2773 D SubscriptionInfoUpdater: insertedSimCount = 0

And for the First STK message on the nonworking SFR SIM we have:

02-06 13:44:53.590  1941  2192 D use-Rlog/RLOG-RIL-IPC: xmm626_sec_modem_fmt_recv: Received FMT message
02-06 13:44:53.590  1941  2192 D use-Rlog/RLOG-RIL-IPC: xmm626_sec_modem_fmt_recv: Message: aseq=0xff, command=IPC_SAT_PROACTIVE_CMD, type=IPC_TYPE_INDI, size=18
02-06 13:44:53.590  1941  2192 D use-Rlog/RLOG-RIL-IPC: ================================= IPC FMT data =================================
02-06 13:44:53.590  1941  2192 D use-Rlog/RLOG-RIL-IPC: [0000]   10 00 D0 0E 81 03 01 05  00 82 02 81 82 99 03 00   ........ ........
02-06 13:44:53.590  1941  2192 D use-Rlog/RLOG-RIL-IPC: [0010]   01 02                                              ..
02-06 13:44:53.590  1941  2192 D use-Rlog/RLOG-RIL-IPC: ================================================================================
02-06 13:44:53.590  1941  2192 D use-Rlog/RLOG-RIL-IPC: Unhandled IPC FMT message: IPC_SAT_PROACTIVE_CMD

#6 Updated by Denis 'GNUtoo' Carikli 2 months ago

I looked rapidely at the log of the Orange SIM, however I didn't find IccID (89330178269030170700) in the samsung-ipc messages (I tried to look for 33 and 9833 as this is how it appears in simtrace traces). I'll have to investigate more on this side. I also looked at the Java side of the RIL but didn't find enough information yet on how the SIM filesystem abstraction work.

#7 Updated by Denis 'GNUtoo' Carikli 2 months ago

Here we can find the ICCID (98:33:10:87:62:09:03:71:70:00):

02-06 13:47:56.902  1942  2203 D use-Rlog/RLOG-RIL-IPC: xmm626_sec_modem_fmt_recv: Received FMT message
02-06 13:47:56.902  1942  2203 D use-Rlog/RLOG-RIL-IPC: xmm626_sec_modem_fmt_recv: Message: aseq=0x26, command=IPC_SEC_RSIM_ACCESS, type=IPC_TYPE_RESP, size=13
02-06 13:47:56.902  1942  2203 D use-Rlog/RLOG-RIL-IPC: ================================= IPC FMT data =================================
02-06 13:47:56.902  1942  2203 D use-Rlog/RLOG-RIL-IPC: [0000]   90 00 0A 98 33 10 87 62  09 03 71 70 00            ....3..b ..qp.
02-06 13:47:56.902  1942  2203 D use-Rlog/RLOG-RIL-IPC: ================================================================================

#8 Updated by Denis 'GNUtoo' Carikli 2 months ago

Here's (still for the Orange SIM) the command to select the EF.ICCID file (0x2fe2):

02-06 13:47:56.895  1942  2207 D use-Rlog/RLOG-RIL-IPC: xmm626_sec_modem_fmt_send: Sent FMT message
02-06 13:47:56.895  1942  2207 D use-Rlog/RLOG-RIL-IPC: xmm626_sec_modem_fmt_send: Message: mseq=0x26, command=IPC_SEC_RSIM_ACCESS, type=IPC_TYPE_GET, size=6
02-06 13:47:56.895  1942  2207 D use-Rlog/RLOG-RIL-IPC: ================================= IPC FMT data =================================
02-06 13:47:56.895  1942  2207 D use-Rlog/RLOG-RIL-IPC: [0000]   B0 E2 2F 00 00 0A                                  ../...
02-06 13:47:56.895  1942  2207 D use-Rlog/RLOG-RIL-IPC: ================================================================================

#9 Updated by Denis 'GNUtoo' Carikli 2 months ago

I'm not totally sure about the last one. I'll look into the code to confirm. The ril_request_sim_io has some insights on how it works:

int ril_request_sim_io(void *data, size_t size, RIL_Token token)
{
[...]
    memset(&request_header, 0, sizeof(request_header));
    request_header.command = sim_io->command;
    request_header.file_id = sim_io->fileid;
    request_header.p1 = sim_io->p1;
    request_header.p2 = sim_io->p2;
    request_header.p3 = sim_io->p3;

    sim_io = NULL;

    request_size = ipc_sec_rsim_access_size_setup(&request_header, sim_io_data, sim_io_size);
    if (request_size == 0)
        goto error;

    request_data = ipc_sec_rsim_access_setup(&request_header, sim_io_data, sim_io_size);
    if (request_data == NULL)
        goto error;
[...]
    rc = ipc_fmt_send(ipc_fmt_request_seq(token), IPC_SEC_RSIM_ACCESS, IPC_TYPE_GET, request_data, request_size);
    if (rc < 0)
        goto error;
}

#10 Updated by Denis 'GNUtoo' Carikli 9 days ago

After reading more about the protocol, I found out that the packets order didn't make any sense in the trace I got, because I didn't notice that wireshark didn't order them by time by default for some reason.

This is why I had a hard time understanding the link between them.

Once fixed, here's now what the part that the interesting part from the pcap trace:

No    Time        Protocol    Length    Info
13    25.070965442    GSM SIM        67    ISO/IEC 7816-4 SELECT File EF.ICCID : Response ready, Response length is 27 
14    25.071061474    GSM SIM        92    ISO/IEC 7816-4 GET RESPONSE 
15    25.081092359    GSM SIM        75    ISO/IEC 7816-4 READ BINARY Offset=0 

In the third packet/TPDU we can see in wireshark the following as APDU payload wihich is the SIM ID (ICCID): 98330163019072174071
which is transmited as 98 33 01 63 01 90 72 17 40 71 on the wire.

#11 Updated by Denis 'GNUtoo' Carikli 9 days ago

We also see more clearly that the SIM ID is queried right at the beginning, so it most probably cannot be related to Sim Toolkit(STK) as it appear way later in the conversation between the SIM and the modem.

The trace has precise timestamps in the Ethernet encapsulation. I'll use that to corelate it with the logcat -b radio.

Here's the trace from the very beginning:

No    Time        Protocol    Length    Info
8    23.809625449    GSM SIM    79    3 9e : 00f5 
9    25.048405378    GSM SIM    67    ISO/IEC 7816-4 SELECT File MF 
10    25.062601808    GSM SIM    67    ISO/IEC 7816-4 SELECT /EF.ELP : Response ready, Response length is 30 
11    25.062696862    GSM SIM    95    ISO/IEC 7816-4 GET RESPONSE 
12    25.062775503    GSM SIM    75    ISO/IEC 7816-4 READ BINARY Offset=0 
13    25.070965442    GSM SIM    67    ISO/IEC 7816-4 SELECT File EF.ICCID : Response ready, Response length is 27 
14    25.071061474    GSM SIM    92    ISO/IEC 7816-4 GET RESPONSE 
15    25.081092359    GSM SIM    75    ISO/IEC 7816-4 READ BINARY Offset=0 
[...]

#12 Updated by Denis 'GNUtoo' Carikli 9 days ago

  • Device deleted (Galaxy S 2 (I9100))

The galaxy Nexus is also affected, and probably all other devices using libsamsung-ipc libsamsung-ril

Also available in: Atom PDF