From 22ec9a708ab4128df9f4dd340df2e263f9ebd539 Mon Sep 17 00:00:00 2001 From: Philipp Maier Date: Mon, 9 Mar 2026 16:18:12 +0100 Subject: [PATCH] pySim/transport: fix GET RESPONSE behaviour The current behavior we implement in the method __send_apdu_T0 is incomplete. Some details discussed in ETSI TS 102 221, section 7.3.1.1.4, clause 4 seem to be not fully implemented. We may also end up sending a GET RESPONSE in other APDU cases than case 4 (the only case that uses the GET RESPONSE command). Related: OS#6970 Change-Id: I26f0566af0cdd61dcc97f5f502479dc76adc37cc --- pySim/transport/__init__.py | 44 +++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 12 deletions(-) diff --git a/pySim/transport/__init__.py b/pySim/transport/__init__.py index f19790c7..15c9caf0 100644 --- a/pySim/transport/__init__.py +++ b/pySim/transport/__init__.py @@ -302,19 +302,39 @@ class LinkBaseTpdu(LinkBase): prev_tpdu = tpdu data, sw = self.send_tpdu(tpdu) - # When we have sent the first APDU, the SW may indicate that there are response bytes - # available. There are two SWs commonly used for this 9fxx (sim) and 61xx (usim), where - # xx is the number of response bytes available. - # See also: + # After sending the APDU/TPDU the UICC/eUICC or SIM may response with a status word that indicates that further + # TPDUs have to be sent in order to complete the task. if sw is not None: - while (sw[0:2] in ['9f', '61', '62', '63']): - # SW1=9F: 3GPP TS 51.011 9.4.1, Responses to commands which are correctly executed - # SW1=61: ISO/IEC 7816-4, Table 5 — General meaning of the interindustry values of SW1-SW2 - # SW1=62: ETSI TS 102 221 7.3.1.1.4 Clause 4b): 62xx, 63xx, 9xxx != 9000 - tpdu_gr = tpdu[0:2] + 'c00000' + sw[2:4] - prev_tpdu = tpdu_gr - d, sw = self.send_tpdu(tpdu_gr) - data += d + if case is 4: + # In case the APDU is a case #4 APDU (and only in that case), the UICC/eUICC/SIM may indicate that + # there is response data available which has to be retrieved using a GET RESPONSE command TPDU. + # See also: + while True: + if sw in ['9000', '9100']: + # A status word of 9000 (or 9100 in case there is pending data from a proactive SIM command) + # indicates that either no response data was returnd or all response data has been retrieved + # successfully. We may discontinue the processing at this point. + break; + if sw[0:2] in ['61', '9f']: + # A status word of 61xx or 9fxx indicates that there is (still) response data available. We + # send a GET RESPONSE command with the length value indicated in the second byte of the status + # word. (see also ETSI TS 102 221, section 7.3.1.1.4, clause 4a and 3GPP TS 51.011 9.4.1 and + # ISO/IEC 7816-4, Table 5) + le_gr = sw[2:4] + elif sw[0:2] in ['62', '63']: + # There are corner cases (status word is 62xx or 63xx) where the UICC/eUICC/SIM asks us + # to send a dummy GET RESPONSE command. We send a GET RESPONSE command with a length of 0. + # (see also ETSI TS 102 221, section 7.3.1.1.4, clause 4b and ETSI TS 151 011, section 9.4.1) + le_gr = '00' + else: + # A status word other then the ones covered by the above logic may indicate an error. In this + # case we will discontinue the processing as well. + # (see also ETSI TS 102 221, section 7.3.1.1.4, clause 4c) + break + tpdu_gr = tpdu[0:2] + 'c00000' + le_gr + prev_tpdu = tpdu_gr + data_gr, sw = self.send_tpdu(tpdu_gr) + data += data_gr if sw[0:2] == '6c': # SW1=6C: ETSI TS 102 221 Table 7.1: Procedure byte coding tpdu_gr = prev_tpdu[0:8] + sw[2:4]