Hi all,
I'm using pySim-Shell with a SysmoISIM-SJA2 as well as a SysmoUSIM-SJS1 and on both cards I get quite a few "File not found" errors trying to access different EFs. I'll use EF.NCP-IP as an example to illustrate the issue I'm having below. My initial steps when I plug in the card are as follows:
1) ./pySim-shell -p0 2) verify_adm <adm1 key> 3) select ADF.USIM
Now when I run "dir" in ADF.USIM it lists a number of EFs I'm interested in, including EF.NCP-IP. Since this requires service number 80 to be available in EF.UST, I run "select EF.UST" followed by "ust_service_activate 80". This runs without issue.
When I run select ADF.USIM now followed by select EF.NCP-IP, the card returns a "File not found" error. So my questions are:
Is this file not supported on the SJA2 and SJS1? Is there a way for me to add those files to ADF.USIM? Is there a list of the known supported EFs of the SJA2 and SJS1? I looked and couldn't find anything.
Thank you in advance!
Hi Bryan,
On Sun, Jun 06, 2021 at 12:18:48PM -0400, bryan coxwell wrote:
I'm using pySim-Shell with a SysmoISIM-SJA2 as well as a SysmoUSIM-SJS1 and on both cards I get quite a few "File not found" errors trying to access different EFs.
This is more or less expected, given that the card profiles always reflect the time at which they were created. sysmoUSIM-SJS1 was specified in 2014, and it certainly doesn't contain any files that were introduced in later 3GPP releases. At that time, our main goal was to provide a USIM at all, having previously only provided 2G SIMs.
For sysmoISIM-SJA2: It should have most files of 3GPP Rel15. So here it's quite rare you would end up missing some files.
Right now we're working on sysmoISIM-SJA2 v2 (avaliable in ~ 2 months from now) which then is updated to 3GPP Release 16 files, and the first card to also contain BER-TLV EFs.
- ./pySim-shell -p0
- verify_adm <adm1 key>
- select ADF.USIM
Now when I run "dir" in ADF.USIM it lists a number of EFs I'm interested in, including EF.NCP-IP. Since this requires service number 80 to be available in EF.UST, I run "select EF.UST" followed by "ust_service_activate 80". This runs without issue.
The file will be present whether or not you activate the service. The two are completely independent of each other on the CardOS side. Only the UE and the 3GPP specs mandate that those two reflect/mirror each other. To the CardOS, EF.UST is just a file with some opaque binary data. It doesn't know its logical meaning.
When I run select ADF.USIM now followed by select EF.NCP-IP, the card returns a "File not found" error. So my questions are:
Is this with a sysmoISIM-SJA2? I am looking at dumps I created of SJA2 cards and they definitely contain EF.NCP-IP.
Can you please provide a copy+paste of your pySim-shell session with 'set apdu_trace true' while you try to select that file on a sysmoISIM-SJA2?
Is this file not supported on the SJA2 and SJS1?
Only on SJA2.
Is there a way for me to add those files to ADF.USIM?
No, the filesystem is fixed at the profile creation time. This is why I've tried very hard with the SJA2 to include any and all files that I could find in all relevant specs (SIM, UICC, USIM, ISIM, HPSIM) at the time of profile creation - to ensure the maximum flexibility for our users.
Is there a list of the known supported EFs of the SJA2 and SJS1? I looked and couldn't find anything.
Unfortunately it is not available. It would be great if somebody would add a 'brute force scan' to pySim-shell, which basically tries all possible 65535 file IDs, and if it's selectable and a DF, recursively continues to do so.
This approach would be universal and work with all cards, past, present or future. And it would be guaranteed correct, unlike any manually maintained lists in some manual or wiki...
Kind regards, Harald
Harald Welte wrote:
Is there a way for me to add those files to ADF.USIM?
No, the filesystem is fixed at the profile creation time.
I strongly condemn the current policy of all currently available SIM card vendors (both Grcard and Sysmocom) where they refuse to disclose the necessary knowledge to allow individual downstream card owners to freely reformat their file system, even if it means low-level flash reformatting and CardOS image reloading etc. I have written more about this topic earlier:
https://www.freecalypso.org/hg/fc-sim-tools/file/tip/doc/Formatting-thoughts
Unfortunately it is not available. It would be great if somebody would add a 'brute force scan' to pySim-shell, which basically tries all possible 65535 file IDs, and if it's selectable and a DF, recursively continues to do so.
This feature already exists in fc-uicc-tool in my fc-sim-tools suite, my competitor to pySim:
https://www.freecalypso.org/hg/fc-sim-tools/file/tip/doc/Brute-force-search
M~
Dear Mychaela,
On Sun, Jun 06, 2021 at 12:56:23PM -0800, Mychaela Falconia wrote:
I strongly condemn the current policy of all currently available SIM card vendors (both Grcard and Sysmocom) where they refuse to disclose the necessary knowledge to allow individual downstream card owners to freely reformat their file system, even if it means low-level flash reformatting and CardOS image reloading etc.
I believe the sysmocom SIM card products are the most open/accessible SIM card products in the market - and that with a large distance to the classic suppliers of SIM cards. I also believe it is the maximum currently possible open-ness within that market, considering the highly proprietary nature of all known smart card ICs as well as card operating systems.
We once were playing with the idea of a FOSS card operating system (osmo-cos) based on a relatively well documented chinse smart card IC (CC32RS512). However, it never really went anywhere before the chips started to become unavailable.
You are most welcome to create any more open/accessible SIM card products, I would certainly appreciate that. If such products existed, we would have never needed to create the sysmoUSIM/sysmoISIM products and could focus on open source software development.
This feature already exists in fc-uicc-tool in my fc-sim-tools suite, my competitor to pySim:
Please note that I do not see any "competition" in any of the projects you work on. Those are different projects, with as far as I can tell rather different goals. There may be some amount of overlap for some use cases. For those overlapping use cases I would consider "alternative" an appropriate term. For all other use cases they are complimentary.
The Osmocom project does not engage in "competition". We do what we do, people can like it, dislike it, use it, or create alternatives as they please.
Regards, Harald
-
bryan coxwell -
Harald Welte -
Mychaela Falconia