public/pysim
1
0
Fork 1
mirror of https://gitea.osmocom.org/sim-card/pysim.git synced 2026-03-25 06:48:33 +03:00
Code Issues Packages Projects Releases Wiki Activity

pySim/transport: fix GET RESPONSE behaviour

Browse Source 
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
This commit is contained in:
Philipp Maier
2026-03-09 16:18:12 +01:00
parent f10af30aed
commit 22ec9a708a
1 changed files with 32 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
pySim/transport/__init__.py
View File

@@ -302,19 +302,39 @@ class LinkBaseTpdu(LinkBase):
prev_tpdu = tpdu prev_tpdu = tpdu
data, sw = self.send_tpdu(tpdu) data, sw = self.send_tpdu(tpdu)
# When we have sent the first APDU, the SW may indicate that there are response bytes # After sending the APDU/TPDU the UICC/eUICC or SIM may response with a status word that indicates that further
# available. There are two SWs commonly used for this 9fxx (sim) and 61xx (usim), where # TPDUs have to be sent in order to complete the task.
# xx is the number of response bytes available.
# See also:
if sw is not None: if sw is not None:
while (sw[0:2] in ['9f', '61', '62', '63']): if case is 4:
# SW1=9F: 3GPP TS 51.011 9.4.1, Responses to commands which are correctly executed # In case the APDU is a case #4 APDU (and only in that case), the UICC/eUICC/SIM may indicate that
# SW1=61: ISO/IEC 7816-4, Table 5 — General meaning of the interindustry values of SW1-SW2 # there is response data available which has to be retrieved using a GET RESPONSE command TPDU.
# SW1=62: ETSI TS 102 221 7.3.1.1.4 Clause 4b): 62xx, 63xx, 9xxx != 9000 # See also:
tpdu_gr = tpdu[0:2] + 'c00000' + sw[2:4] while True:
prev_tpdu = tpdu_gr if sw in ['9000', '9100']:
d, sw = self.send_tpdu(tpdu_gr) # A status word of 9000 (or 9100 in case there is pending data from a proactive SIM command)
data += d # 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': if sw[0:2] == '6c':
# SW1=6C: ETSI TS 102 221 Table 7.1: Procedure byte coding # SW1=6C: ETSI TS 102 221 Table 7.1: Procedure byte coding
tpdu_gr = prev_tpdu[0:8] + sw[2:4] tpdu_gr = prev_tpdu[0:8] + sw[2:4]