Dear Osmocom community, pySim-prog was nice when there were only 5 parameters on a SIM that we could program, and where the use case was pretty limited. Today, we have SIM/USIM/ISIM cards with hundreds of files and even more parameters to program. We cannot add a command line argument for each file to pySim-prog. Instead, this introduces an interactive command-line shell / REPL, in which one can navigate the file system of the card, read and update files both in raw format and in decoded/parsed format. The idea is primarily inspired by Henryk Ploetz' venerable cyberflex-shell, but implemented on a more modern basis using the cmd2 python module. You can see the very first prototype in the laforge/shell branch of pysim.git You can do things with it like this: ===> Start-up and authenticate with adm pin ---------------------------------------------------------------------- $ ./pysim-shell.py -p 0 Using PC/SC reader interface Autodetected card type: sysmoISIM-SJA2 AIDs on card: ['a0000000871002ffffffff8907090000', 'a0000000871004ffffffff8907090000'] Welcome to pySim-shell! pySIM-shell (3f00)> verify_adm 92990895 ---------------------------------------------------------------------- ===> interactive help ---------------------------------------------------------------------- pySIM-shell (3f00)> help Documented commands (use 'help -v' for verbose/'help <topic>' for details): ISO7816 Commands ================ read_binary select_adf select_file update_binary update_record verify_chv pySim Commands ============== intro verify_adm USIM Commands ============= read_ehplmn ust_service_activate ust_service_deactivate pySim-shell built-in commands ============================= alias help macro quit run_script shell edit history py run_pyscript set shortcuts ---------------------------------------------------------------------- ===> more interactive help ---------------------------------------------------------------------- pySIM-shell (3f00)> help read_binary usage: read_binary [-h] [--file-id FILE_ID] [--offset OFFSET] [--length LENGTH] [--record-nr RECORD_NR] Read binary data from a transparent EF optional arguments: -h, --help show this help message and exit --file-id FILE_ID File ID --offset OFFSET Byte offset for start of read --length LENGTH Number of bytes to read --record-nr RECORD_NR Number of record to read ---------------------------------------------------------------------- ===> navigating the FS and reading files ---------------------------------------------------------------------- pySIM-shell (3f00)> select_file 7f20 ['622c8202782183027f20a509800171830400018d088a01058b032f0601c60f90017083010183018183010a83010b'] pySIM-shell (3f00/7f20)> read_binary --file-id 6f07 089910070000400310 ---------------------------------------------------------------------- ===> interaction with local filesystem, i.e. I/O redirect + shell commands ---------------------------------------------------------------------- pySIM-shell (3f00)> select_adf a0000000871002 pySIM-shell (a0000000871002)> select_file 5f3b pySIM-shell (a0000000871002/5f3b)> read_binary --file-id 4f20 > /tmp/f pySIM-shell (a0000000871002/5f3b)> !cat /tmp/f ffffffffffffffff07 ---------------------------------------------------------------------- ===> piping output through shell tools like grep ---------------------------------------------------------------------- pySIM-shell (3f00)> read_ust | grep 86 Service 86 - Allowed CSG Lists and corresponding indications ---------------------------------------------------------------------- ===> enabling/disabling services ---------------------------------------------------------------------- pySIM-shell (3f00/7f20)> ust_service_activate 123 pySIM-shell (3f00/7f20)> ust_service_deactivate 123 ---------------------------------------------------------------------- It's a very first prototype, but it is really promising. The major tasks I see to make this go anywhere is: * have "File" class with encoder/decoder methods, which are registered automatically with a 'file system' layer that knows about the DF/ADF hierarchy ** this allows us to have a "read-decoded" command, which will call the decode method of the file, automatically resolved by the selected FID/path * automatic mapping of file-name -> FID and FID -> file name ** when printing (like in the path), use the human-readable names ** allow users to use human-readable names in SELECT * decode + display the TLVs / FCPs after a SELECT (like cyberflex-shell * ability to enable/disable APDU trace * dynamically register/deregster commands based on the path, i.e. offer USIM commands only when in ADF_USIM We have quite a bit of that infrastructure in the c-language libosmosim, (part of libosmocore.git), but unfortunately not in python :/ Let me know if anyone is interested in joining this effort. Regards, Harald -- - Harald Welte &lt;laforge(a)gnumonks.org&gt; http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

On Jan 11, 2021, at 8:10 AM, Harald Welte &lt;laforge(a)gnumonks.org&gt; wrote: Hi Bryan, thanks for reaching out. By now most of the APIs/architecture is sorted out, so you could a) make sure that ts_51_011.py (sim) / ts_31_102.py (usim) / ts_31_103.py (isim) contain class definitions for all of the files specified in the latest Release 16 3GPP specifications b) write encoder and decoder methods within the EF classes for the various files of interest. See the EF_IMSI() as an example. The Decoder method should return a python dict (possibly a hierarchy of dicts) and return the binary representation, while the encoder method should take the dict and produce the binary representation. Regards, Harald -- - Harald Welte &lt;laforge(a)gnumonks.org&gt; http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

In theory, you should be able to remove the respective applications from most java based cards with the right credentials

via SCP02. Did you try?

sysmocom can certainly also provide such cards, should you have a related requirement.

It requires creating a card profile without ADF.USIM + ADF.ISIM, which certainly can be done.

One clear disadvantage of using SIM without USIM functionality even on a 2G radio network is that you can never use mutual authentication between network and phone (which is a pure protocol related aspect, so it could be implemented in any phone/baseband whose software can be modified - including FreeCalypso.

I have been using srsLTE for about 5 years now, and about 3 years ago physical USIM support was added to it.

Naturally it is a very thin layer, pretty much only supporting requesting 3G AUTH vectors from the card,

however it is written in C or C++ (I can't remember right now which). Maybe it is useful for you :).

For the "right credentials" part, I have a 10-pack of sysmoISIM-SJA2 cards which I bought with ADM keys included. The key material email from your webshop gives ADM1 and KI[CDK][123] for each card - are these the right credentials?

I am afraid the learning curve will probably be too steep for me to climb at this moment - but I am making a mental note to read up on SCP02, whatever it is, when and if I get the mental space for it.

What would be the MOQ and minimum order total cost for the following?:

* Application customization: either classic GSM only or classic GSM plus USIM (TBD), but no ISIM;

* 1FF+2FF-only cut, with the 2FF piece being fully solid w/o 3FF or 4FF cuts;

* Custom printing.

Just how much control do you have over your cards?

Your docs give the impression that your vendor/supplier more or less forced you into a new CardOS platform by declaring EOL on the one you had for SJS1

and the comments in your Python code for programming Ki/OPc/etc make it sound like these aspects were something you had to reverse-eng from what your vendor gave you, rather than something you actually designed yourselves.

I mean, if your own team had actually designed the custom non-standard files for storing keys and algorithm selections, surely you would not have come up with the awkward design where you have to repeatedly store into each of SIM, USIM and ISIM, without making it clear at all whether or not these files are all linked or separate...

If you were to make a version without ADF.ISIM or without both ADF.ISIM and ADF.USIM, what would the architecture look like for storing Ki (or K/OPc) and algorithm selections?

I am also concerned about the following stanza in sysmo_isim_sja2.py: sysmo_isimsja2_algorithms = ( (SYSMO_ISIMSJA2_ALGO_COMP12V1, 'COMP128v1'), (SYSMO_ISIMSJA2_ALGO_COMP12V2, 'COMP128v2'), (SYSMO_ISIMSJA2_ALGO_COMP12V3, 'XOR-2G'), (SYSMO_ISIMSJA2_ALGO_MILENAGE, 'MILENAGE'), (SYSMO_ISIMSJA2_ALGO_SHA1AKA , 'SHA1-AKA'), (SYSMO_ISIMSJA2_ALGO_XOR, 'XOR'), ) Why is SYSMO_ISIMSJA2_ALGO_COMP12V3 mapped to 'XOR-2G' and not 'COMP128v3'?

Does sysmoISIM-SJA2 (and presumably any custom config based on your current SJA2 CardOS) actually support COMP128v3 or not?

Then the actual linked vs. separate arrangement on the card should be documented - meaning explicitly document what is shared/linked vs.

07.04.2021 dátummal, 2:41 időpontban Mychaela Falconia &lt;mychaela.falconia(a)gmail.com&gt; írta: Harald Welte wrote: And just how do you get the card to tell you what selectable file IDs exist? I haven't seen anything like an ls operation in either the classic GSM 11.11 SIM protocol or the UICC protocol, thus the only way (that I know of) to find out what selectable file IDs exist is to do a brute force search of the 16-bit file ID space at every directory level. First select MF, then try selecting every possible 16-bit file ID from 0000 to FFFF (only skipping 3F00 for MF itself), and note which return something other than "not found" error. Follow up with a GET RESPONSE command for every SELECT which succeeded, parse the response, and report the findings. For all found file IDs which turn out to be DFs when the response is parsed, note those DF file IDs, and then repeat the brute force search inside every found DF - and then in any found nested DFs too. This brute force search is implemented in fc-simtool and fc-uicc-tool programs in my fc-sim-tools suite, my competitor to pySim: https://www.freecalypso.org/hg/fc-sim-tools/ As one would naturally expect, such brute force searches are painfully slow - IIRC, bfsearch-mf of sysmoISIM-SJA2 (just the MF tree, ADF trees have to be searched separately with bfsearch-adf) took about an hour, using HID Omnikey 3121 card reader, same model as the one currently sold in Sysmocom webshop - using an o'scope, I observed that it clocks the card at 4.8 MHz, almost up to the spec limit of 5 MHz. Because these brute force searches are so slow, I collect the captures and check them into my source repository under the data directory - so if you are curious to see what undocumented proprietary files exist on both Sysmocom and Grcard SIMs (whose existence cannot be discovered in any other way than this bfsearch), just look in the repository linked above. :-) I am not able to run pySim-shell on my Slackware system without expending more effort than I can currently justify, but I have glanced at the Python code, and I don't see anything like the just described brute force search - nor do I see it issuing any kind of secret undocumented ls-type APDU commands to the card - thus I am guessing that this 'tree' command displays nothing more than the tool's hard-coded knowledge of what files "should" exist at each given directory level, rather than what is actually found to exist. If I got this part wrong, then someone please explain what this command *actually* returns, and how it obtains this knowledge - I don't know of any way other than a brute force search. M~