SIM card related Projects » pySim

There is something wrong with MF/ADF.ARA-M. When it is selected, the following happens:

pySIM-shell (MF)> select ADF.ARA-M
Traceback (most recent call last):
  File "/home/owner/.local/lib/python3.7/site-packages/cmd2/cmd2.py", line 2129, in onecmd_plus_hooks
    stop = self.onecmd(statement, add_to_history=add_to_history)
  File "/home/owner/.local/lib/python3.7/site-packages/cmd2/cmd2.py", line 2559, in onecmd
    stop = func(statement)
  File "./pySim-shell.py", line 641, in do_select
    fcp_dec = self._cmd.rs.select(path, self._cmd)
  File "/home/owner/work/git_master/pysim/pySim/filesystem.py", line 1238, in select
    select_resp = f.decode_select_response(data)
  File "/home/owner/work/git_master/pysim/pySim/filesystem.py", line 192, in decode_select_response
    return self.parent.decode_select_response(data_hex)
  File "/home/owner/work/git_master/pysim/pySim/filesystem.py", line 371, in decode_select_response
    return profile.decode_select_response(data_hex)
  File "/home/owner/work/git_master/pysim/pySim/ts_102_221.py", line 696, in decode_select_response
    fcp = fcp_tlv.parse(fcp_base['62'])
KeyError: '62'
EXCEPTION of type 'KeyError' occurred with message: ''62''
pySIM-shell (MF)> 

after that all files in the directory are gone and it is not possible to select MF anymore. That is why export only works once. As soon as it hits ADF.ARA-M the problem is triggered. (The tree command also triggers the problem.)

dexter wrote in #note-1:

after that all files in the directory are gone and it is not possible to select MF anymore.

Are you sure it's not just simply us sending the wrong CLA byte? Maybe ARA-M requires different CLA than normal UICC/SIM.

What I can see so far is that the select works. It returns with 9000, but once ADF.ARA-M the new CLA seems to get valid and that gets us trapped because we cannot even select the MF anymore using the UICC APDUs.

pySIM-shell (MF/ADF.ARA-M)> select MF
EXCEPTION of type 'RuntimeError' occurred with message: '6e00: ARA-M - Invalid class'

I've played around a bit with various CLA values, and if 0x80 is used, the resposne suddenly becomes "6D00 == invalid instruction". So the applet supports CLA=0x80 but no INS=0xA4 (SELECT).

Looking at the source code seems to confirm this: https://github.com/bertrandmartel/aram-applet/blob/master/aram/src/main/java/fr/bmartel/aram/AccessRuleMaster.java#L77 - any CLA != 0x80 is rejected, and the only INS supported are STORE_DATA and GET_DATA.

I've filed an issue with the ARA-M applet project at https://github.com/bertrandmartel/aram-applet/issues/7

In future cards we can of course install an applet with explicit de-select capability. However, until that point, I think it is best if we black-list the ARA-M AID from export. After all, there are no files specified in he ARA-M specification.

reading https://www.win.tue.nl/pinpasjc/docs/apis/jc222/javacard/framework/Applet.html and https://stackoverflow.com/questions/26816690/what-is-the-functionality-of-selectingapplet-method-in-javacard2-2 it looks lmore like the SELECT APDU should be captured/interpreted by the JCRE (java card runtime environment)...

And indeed, selecting other AIDs still works. IF I send "00a4040410a0000000871002ffffffff8907090000" after the "export" (e.g. via the new "apdu" command added in https://gerrit.osmocom.org/c/pysim/+/27165), one can get back to the USIM application, and from there again perform "select MF". So this sounds like the best approach to implement.

Maybe thre's an Application ID for "no application", but in general we should select some other application and resolve this.

I have thought through various solutions. They are all hackish. I think where the problem hurts the most is during export, because it prevents that export can print its summary. Here is a patch to resolve this part:

https://gerrit.osmocom.org/c/pysim/+/28162

Apart from that I do not think that the problem hurts much. EF.ARAM is at the end of the file system tree, so we get everything we need.

What I didn't try yet is to implicitly select the parent when going one level up in the file system tree, maybe JCRE is able to interpret that correctly.

I have checked it apdu 00a404... seems to be the only SELECT variant that works, so we cannot use the P2 option "Select parent DF of the current DF"

dexter wrote in #note-7:

I have thought through various solutions. They are all hackish. I think where the problem hurts the most is during export, because it prevents that export can print its summary. Here is a patch to resolve this part:

https://gerrit.osmocom.org/c/pysim/+/28162

Apart from that I do not think that the problem hurts much. EF.ARAM is at the end of the file system tree, so we get everything we need.

That is true only right now for one type of card in one use case. Bad assumption. Maybe reset the card after every application? Or have a blacklist of known AIDs that require some kind of reset or explicit select of ADF.USIM afte the export?

In general, the pysim shell should return the card to the state it had before the export, so that any subsequent command (including another export) will work after an export, from the same cwd as before calling export.

(GlobalPlatform Card Specification section 6.4.2.1 "Application Selection on Basic Logical Channel" may explain this behavior)

(The issue came up again in the following ticket: #6116, which is basically a duplicate of this one)