SIM card related Projects » SIMtrace 2

I'm observing the following weird situation when using the following setup:

pySim-shell --pcsc/ccid--> CardMan3121 --> simtrace2(cardem) --> simtrace2-cardem-pcscs --pcsc/ccid--> sysmoISIM-SJA2

pySIM-shell (no card)> equip
Waiting for card...
Autodetected card type: sysmoISIM-SJA2
Info: Card is of type: UICC
AIDs on card:
 USIM: a0000000871002ffffffff8907090000 (EF.DIR)
 ISIM: a0000000871004ffffffff8907090000 (EF.DIR)
 ARA-M: a00000015141434c00
EXCEPTION of type 'RuntimeError' occurred with message: '6e00: Checking errors - Class not supported'
To enable full traceback, run the following command: 'set debug true'

And indeed, looking at the communication, the SIM card responds with a 6300 to the final "select MF" apdu:

DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 c0 00 00 2f 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_pb_and_tx(pb=c0, tx=62 2d 82 02 78 21 83 02 3f 00 a5 09 80 01 71 83 04 00 01 8d 08 8a 01 05 8c 04 26 1a 00 00 c6 0f 90 01 70 83 01 01 83 01 81 83 01 0a 83 01 0b , len=47)
DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=9000)
DLGLOBAL INFO =====================================
DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 a4 00 04 02 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_pb_and_rx(pb=a4, le=2)
DLGLOBAL INFO => DATA: flags=0x02 (FINAL ), 2f 00 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=6124)
DLGLOBAL INFO =====================================
DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 c0 00 00 24 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_pb_and_tx(pb=c0, tx=62 22 82 05 42 21 00 2b 08 83 02 2f 00 a5 06 d0 01 20 d2 01 0b 8a 01 05 8b 03 2f 06 04 80 02 01 58 88 01 f0 , len=36)
DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=9000)
DLGLOBAL INFO =====================================
DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 b2 08 04 2b 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_pb_and_tx(pb=b2, tx=ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff , len=43)
DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=9000)
DLGLOBAL INFO =====================================
DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 a4 04 04 09 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_pb_and_rx(pb=a4, le=9)
DLGLOBAL INFO => DATA: flags=0x02 (FINAL ), a0 00 00 01 51 41 43 4c 00 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=9000)
DLGLOBAL NOTICE => IRQ STATUS: flags=0x13, fi=9, di=6, wi=10 wtime=9600 (RESET VCC CLK )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x12, fi=9, di=6, wi=10 wtime=9600 (RESET CLK )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x10, fi=9, di=6, wi=10 wtime=9600 (RESET )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x0, fi=9, di=6, wi=10 wtime=9600 ()
DLGLOBAL NOTICE => IRQ STATUS: flags=0x10, fi=9, di=6, wi=10 wtime=9600 (RESET )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x0, fi=9, di=6, wi=10 wtime=9600 ()
DLGLOBAL NOTICE => IRQ STATUS: flags=0x1, fi=9, di=6, wi=10 wtime=9600 (VCC )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x3, fi=1, di=1, wi=10 wtime=9600 (VCC CLK )
DLGLOBAL NOTICE => PTS req: ff 10 96 79
DLGLOBAL INFO =====================================
DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 a4 00 04 02 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_pb_and_rx(pb=a4, le=2)
DLGLOBAL INFO => DATA: flags=0x02 (FINAL ), 3f 00 
 DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=6e00)

so what's happening here? We are issuing a CLA byte of 00 after having most recently selected the ARA-M application. Apparently this is not a supported CLA byte within ARA-M.

However, why does this not show up when accessing the card directly? Because the card-reset happening between selcting ARA-M and the final "SELECT MF" (00 a4 00 04 02 3f 00) is not properly detected, and we don't execute it on the card.

DLGLOBAL NOTICE => IRQ STATUS: flags=0x13, fi=9, di=6, wi=10 wtime=9600 (RESET VCC CLK )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x12, fi=9, di=6, wi=10 wtime=9600 (RESET CLK )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x10, fi=9, di=6, wi=10 wtime=9600 (RESET )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x0, fi=9, di=6, wi=10 wtime=9600 ()
DLGLOBAL NOTICE => IRQ STATUS: flags=0x10, fi=9, di=6, wi=10 wtime=9600 (RESET )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x0, fi=9, di=6, wi=10 wtime=9600 ()
DLGLOBAL NOTICE => IRQ STATUS: flags=0x1, fi=9, di=6, wi=10 wtime=9600 (VCC )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x3, fi=1, di=1, wi=10 wtime=9600 (VCC CLK )

So we see various changes of RESET/VCC/CLK lines reported by the firmware, but our "Detect reset and pass it on to the remote card" logic triggers on the following logic:

        if ((flags & CEMU_STATUS_F_VCC_PRESENT) && (flags & CEMU_STATUS_F_CLK_ACTIVE) &&
            !(flags & CEMU_STATUS_F_RESET_ACTIVE)) {
                if (last_status_flags & CEMU_STATUS_F_RESET_ACTIVE) {
                        /* a reset has just ended, forward it to the real card */
                        bool cold_reset = true;
                        if (last_status_flags & CEMU_STATUS_F_VCC_PRESENT)
                                cold_reset = false;
                        LOGCI(ci, LOGL_NOTICE, "%s Resetting card in reader...\n",
                                cold_reset ? "Cold" : "Warm");
                        osim_card_reset(card, cold_reset);
                }
        }

1. VCC + CLK must be present while RST is absent, and
2. previously, RST must have been active

In the sequence used by the CM3121 (or at least as reported by the carem firmware), RST is turned off as VCC is turned off, so second condition above doens't hold true.