OpenBSC

openbsc@lists.osmocom.org

10 participants
4188 discussions

Sharing my mixed success story with Grcard SIMs
by Mychaela Falconia 06 May '21

06 May '21

Hello Osmocom community, I made some posts here earlier this year about my attempts to obtain some programmable SIM cards from Grcard (a well-known Chinese manufacturer of SIM and other smart cards) that are GSM SIM only, without USIM or ISIM applications - but I just realized that I never posted anything regarding the final outcome of those escapades. The present post is intended to summarize what I obtained and what I learned through that venture. The first point to be noted is that Grcard make many bazillion different card models, but frustratingly, they never let me see any kind of catalog of their different offerings. Instead what happened is that when I first approached them back in January and told them what I was looking for in very basic terms (I simply said that I wanted a GSM-only SIM card without any USIM or ISIM stuff), they offered me one of their card models based on those stated requirements, they first sent me a few sample pieces of this card model they selected for me, and then I ended up ordering 200 pieces of that same model with my own custom printing on the cards. The card model which Grcard offered to me back in January and of which I got 200 pcs a month ago in April turned out to be exactly the same in technical terms as the one that was once sold by Sysmocom as sysmoSIM-GR2: https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2 As I understand it, Sysmocom had that sysmoSIM-GR2 as an offering back in late 2013, thus it was quite surprising to see that Grcard still readily sell that exact same model 7 and a half years later - but they do. As a result of having done a ton of work with these cards over the past few months, I now know a lot more about them than is said in the scant Osmocom wiki page above, and a lot more than the little bits of knowledge embedded in pySim code from 2013 supporting this model. Extensive write-ups about these cards can be found in my fc-sim-tools repository, but here is a basic summary of the good and the bad: The good: * These GrcardSIM2 aka FCSIM1 cards are truly native GSM 11.11 SIM, and do not speak the unwanted-innovation UICC protocol at all. * F=512 D=8 speed enhancement (the only SIM speed enhancement mode called for in the original GSM 11.11 spec and the only one implemented in most classic GSM MS hardware such as Calypso) is supported by these cards, thus if your GSM MS firmware has this speed enhancement enabled (at least with TI platform, many legacy fw versions have it disabled - don't know about other GSM chipset vendors), your phone will talk to the SIM at about 50781 bps, instead of the circa 8737 bps you get with the basic non-enhanced F=372 D=1 mode. * The security model on these cards works the way it is supposed to: they initially ship with a known default SUPER ADM key, but if you change both ADM5 and ADM11 (SUPER ADM) keys to your own secrets, then the card becomes fully secure in the traditional SIM security sense. I personally don't understand and will likely never understand what is so wrong with letting your paying service subscribers know their own Ki and letting them clone their SIM if they so wish, but if you wish to replicate the traditional security model where you program Ki and change ADM keys to some secret, you *can* do it with FCSIM1 cards. Standard PIN1/PIN2/PUK1/PUK2 can be freely reset if you authenticate with ADM5 or ADM11, but if you change those ADM keys to secrets, then the PIN system becomes fully secure too. Contrast the situation with Grcard's earlier model (sysmoSIM-GR1) where anyone can freely reset both regular and ADM PINs without any authentication, meaning no security whatsoever. * All 3 of COMP128v1, COMP128v2 and COMP128v3 are supported. I naturally choose COMP128v3 for my own deployments - A5/1 is weak enough to begin with, no need to weaken it further by reducing the effective key length to just 54 bits with COMP128v1 or v2. * As far as I can tell, there are NO unwanted STK applications on these cards. Harald said here earlier that Sysmocom's business relationship with Grcard ended when Grcard started shipping cards with some preinstalled STK applications displaying some pop-up messages in Chinese, but I see no evidence of any such applications being present on the FCSIM1 cards I got from them this year. I have tried issuing a feature-generous TERMINAL PROFILE toward the card (listing support for all common SAT features), and the SW response was 9000 - no matter what I tried, I never got the card to respond with SW of 91xx, indicating some proactive SIM command - thus as far as I can tell, these SIMs never issue any proactive commands. * The best good of all: no MOQ! Instead of being forced to buy 1000 or more cards and have them go to waste because I will never find that many people who have the same pattern of technology likes and dislikes as I do, I was able to buy just 200 cards - I could have ordered as few as 100, but I ordered 200 because they were cheap - and I got those 200 cards with my own custom printing and with my choice of form factor cut - I chose 2FF-only, of course. The bad: * The free reformatting ability that existed on sysmoSIM-GR1 has been taken away. On sysmoSIM-GR1 you could erase the card file system and recreate your own tree of DFs and EFs according to your own liking (with you deciding which files to include or omit, what size to allocate for each file, and what access conditions it should have), but those proprietary APDU commands from GR1 don't work on GrcardSIM2 (FCSIM1), and the official answer from Grcard is that such downstream reformatting is not allowed. I am guessing that what I want probably *can* be done by reformatting the card flash and reloading their CardOS at a lower level, but needless to say, Grcard won't divulge any of the knowledge that would be needed for such an endeavor. * The fixed formatting these cards came with (which we have no way of changing per above) is far from ideal: EF_AD is only 3 bytes and not 4, some files that aren't absolutely critical but would be nice to have like SDN and ECC are missing, and the allocated record size for EF_ADN is only 28 bytes, allowing only 14 characters for the contact name field. Contrast with old T-Mobile USA SIMs that have 44-byte ADN records (30 characters for contact name), or current Sysmocom cards that have 34-byte ADN records, allowing 20 characters. Grcard people told me that they can change this file system layout to a different one with MOQ of 10000 pcs, but of course such MOQs are absolutely not acceptable for "just for love" applications like mine. * There is no OTA programming capability on this card model. I was hoping that I could program EF_MSISDN over the air (yes, I know full well that a phone doesn't need to know its own MSISDN to make or answer calls, but all classic GSM phones have a menu command for "Show my number" or whatever it's called, and that's what EF_MSISDN on the SIM is for) like I can do on sysmoUSIM-SJS1 and sysmoISIM-SJA2 cards, but nope, this functionality just isn't there. Grcard folks were telling me that they have some other card model that supports OTA, but I never got a straight answer out of them as to whether that other card model is also GSM SIM only, or if it is UICC/USIM/ISIM - I suspect the latter, which would be totally uninteresting to me. * The worst badness of all is that Grcard people absolutely hate customers who ask too many technical questions, and when pressed, they typically respond only with non-answers. There is basically NO technical support of the kind we got used to in highly technical communities like Osmocom with vendors like Sysmocom, instead they are used to dealing with sales and marketing types. I also got the impression that selling to R&D customers is very foreign to them, instead they are set up for making cards for operator/MVNO type of customers who let the card vendor do all of the programming at the factory and don't get into any real technical stuff themselves. So here is what we got: https://www.freecalypso.org/members/falcon/pictures/SIMs/FCSIM1_front.jpeg https://www.freecalypso.org/members/falcon/pictures/SIMs/FCSIM1_back.jpeg The cards depicted in those photos are quite real, they are sitting right here at my FreeCalypso HQ in California, and they work in the sense that I can program everything including IMSI, Ki and COMP128v3 selection. I haven't set up my own GSM network yet - I already acquired a couple of nanoBTS units (one for 850 MHz, one for 1900 MHz), but I still need to acquire a better server machine for running Osmocom CNI software. Much like any other feeling and soulful human, I have a deep-rooted urge to share my work with others. When it comes to the present SIM card venture, I am doing everything I can to share my work with the community in 3 ways: 1) The software I developed for programming these cards is free to the world, with an explicit public domain license statement: https://www.freecalypso.org/hg/fc-sim-tools/ My fc-sim-tools suite is a direct competitor to pySim, written in C instead of Python, and split into separate fc-simtool and fc-uicc-tool for the two very different protocols that exist for talking to SIM cards. Oh, and my tools can be used to program Sysmocom webshop cards too, not just my Grcard-based FCSIM1. 2) If anyone else would like to buy similar cards from Grcard, I will be happy to put you in touch with my contact there and guide you through the process - and by encouraging anyone with a commercial interest to buy directly from Grcard instead of me acting as a reseller, I explicitly disavow any thought of commercially profiting from any related venture or acting as any kind of commercial entity myself. 3) If there is anyone in the world who shares my core philosophical position whose wording is imprinted on the plastic on my FCSIM1 cards (see the pictures above) and would like to get a few of these cards, please let me know, and I will be glad to send you however many cards you need, for the cost of shipping only, or at most covering my own cost of ordering more cards in the highly unlikely event that I get enough interest to run down my stock. In hacking fellowship, Mother Mychaela Hasta la Victoria, Siempre - 2G forever!

1 0

pySim ModuleNotFoundError: No module named 'construct'
by Niels ten Oever 03 May '21

03 May '21

Hi all, I am a happy user of pySim - thanks a lot for the work on it. Unfortunately, I think something broke during recent updates that might have to do with software versions. I went through a full reinstall and have done all the software installations mentioned in the README.md, but when I do: $ ./pySim-read.py -p0 I get: Traceback (most recent call last): File "./pySim-read.py", line 31, in <module> from pySim.ts_51_011 import EF, DF, EF_SST_map, EF_AD File "/home/gagarin/Data/pysim/pySim/ts_51_011.py", line 324, in <module> from construct import * ModuleNotFoundError: No module named 'construct' I tried: $ sudo pip3 install construct Requirement already satisfied: construct in /usr/local/lib/python3.8/dist-packages (2.10.67) But that did not solve the issue. Any pointers are very welcome. All the best, Niels PS FYI: $ cat /proc/version Linux version 5.8.0-50-generic (buildd@lgw01-amd64-051) (gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0, GNU ld (GNU Binutils for Ubuntu) 2.35.1) #56-Ubuntu SMP Mon Apr 12 17:18:36 UTC 2021 $ lsusb | grep OMNI Bus 001 Device 033: ID 076b:3031 OmniKey AG OMNIKEY 3x21 Smart Card Reader -- Niels ten Oever, PhD Postdoctoral Researcher - Media Studies Department - University of Amsterdam Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas https://nielstenoever.net - mail(a)nielstenoever.net - @nielstenoever - +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 Read my latest article on Internet infrastructure governance in New Media & Society here: https://journals.sagepub.com/doi/full/10.1177/1461444820929320

5 9

comparison of open source 4G and 5G implementations
by Niels ten Oever 30 Apr '21

30 Apr '21

Hi all, Slightly inspired by the excellent responses I got today on this list on another problem I wanted to ask a question about the comparison of open source 4G and 5G implementations. While there are several lists that provide overviews of said open source software for 4G and 5G networks [0], I have not found a paper, blogpost, or table that compares the implementations in a meaningful manner. Does such an overview exist, if so, could you point me to it, or if it doesn't exist, do you think such an overview would be helpful? Have a great weekend. Niels PS If this is the wrong list to post this (kind of) question to, feel free to tell me so :) [0] for instance https://github.com/ravens/awesome-telco and https://github.com/calee0219/awesome-5g -- Niels ten Oever, PhD Postdoctoral Researcher - Media Studies Department - University of Amsterdam Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas Affiliated Factulty - Digital Democracy Insitute - Simon Fraser University https://nielstenoever.net - mail(a)nielstenoever.net - @nielstenoever - +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 Read my latest article on Internet infrastructure governance in New Media & Society here: https://journals.sagepub.com/doi/full/10.1177/1461444820929320

1 0

Announcement of "OsmoDevCall" on April 23, 2021
by Harald Welte 18 Apr '21

18 Apr '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at April 23, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by horiz0n: "YIG & YANG (Yet ANother yiG driver)" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will briefly introduce the working principles of YIG (Yttrium Iron Garnet) microwave circuits, their applications and finally conclude with a presentation of a recently developed driver circuit. Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Announcement of "OsmoDevCall" on April 9, 2021
by Harald Welte 07 Apr '21

07 Apr '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at April 9, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation: pySim-shell - the next generation of pySim 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: For more than a decade, pySim-prog has been the tool to configure/program SIM cards in research/lab/private cellular networks. Originally designed for very simplistic GSM-only SIM Cards, it was extended again and again to cover more use cases and parameters. There is a limit as to how far one can go with stuffing everything into command line arguments. In 2021, pySim-shell was created as the next generation tool. It features interactive navigation around the file system, editing capabilities, backup and restore of all [known] files, ... Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

WIP / RFC for pysim 'next generation;' aka pysim-shell
by Harald Welte 07 Apr '21

07 Apr '21

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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

6 17

Question about establishing stable internet link between UE and HNB connected to our developed network core.
by morteza ali Ahmadi 26 Mar '21

26 Mar '21

Hi, osmocom team members. In order to have an internet connection in UE, we have run OsmoGGSN project to set up GGSN. Also, SGSN is developed in our system. At this step, UE connects to our network core and we can query to an arbitrary site in the UE browser and we see the answer of the query without any problem and everything is OK. But after about 30 or 40 seconds, UE sends "Deactivate PDP Context Request" with SM Cause "SM Cause: Protocol error, unspecified (111)" and the connection is reset and a new "Activate PDP Context Request" is required. What is the reason and how can we solve it? -- *When there is much light, The shadow is deep...*

4 5

Idea for 2021: Regular "OsmoDevCall"
by Harald Welte 25 Mar '21

25 Mar '21

Dear Osmocom community, as the pandemic continues and physical meetings are out of the question for the forseeable future, it would be a good idea to have a periodic virtual online meeting of the interested Osmocom community. I was thinking of a format where we would serve two major purposes: 1) technical talks about osmocom relevant topics - ideally current/recent developments * can be pre-recorded to avoid any problems with technical setup, streaming, ... * should ideally have a Q+A session at their initial "airing" during one OsmoDevCall 2) unstructured solicited social event (USSE) * random chat in audio (optionally video) * not recorded, obviously The recording of the technical presentation should then be permanently made available (like the presentations of our prior OsmoCon / OsmoDevCon). Not every OsmoDevCall would neccessarily need the two parts, but I think it would be great if we can make that happen. We could also have e.g. a two-weekly schedule for the USSE and a monthly schedule for the technical presentation. We'd need somebody to volunteer to "manage" the "broadcast" side of this, preferably somebody with at least some prior exposure to online events (like the c3voc). I'm using https://osmocom.org/issues/4928 to collect a tentative list of topics. Feel free to add your ideas there, as well as any comment/ feedback you may have. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 5

where to send pySim patches
by Riemer, Björn 18 Mar '21

18 Mar '21

Hello list, we are working on extensions to pySim for the sjs2 card mainly to make our 5G phones to accept our network. How should we send this patches? Via this mailing list or should we wait a little longer until Harald finished restructuring the mailing lists? Best Regards Bjoern

4 4

sysmoISIM-SJA2 clock stop discrepancy
by Mychaela Falconia 10 Mar '21

10 Mar '21

Hello esteemed masters of Osmocom and Sysmocom, As I am doing some experiments with sysmoISIM-SJA2 cards in order to make a contingency plan in case I am not able to buy cards from Grcard beyond the 5 sample cards I got in February (my contact person there hasn't been responding to email for the past 3 days), I have noticed a discrepancy between this card's ATR and the file characteristics byte it returns in response to SELECT in the GSM 11.11 SIM protocol, regarding allowed levels for clock stop. My sysmoISIM-SJA2 cards (bought from the webshop in late Jan into early Feb) return the following ATR: 3B 9F 96 80 1F 87 80 31 E0 73 FE 21 1B 67 4A 4C 75 30 34 05 4B A9 The TA byte for T=15 indicates allowed voltage classes and allowed levels for clock stop. On this card this byte equals 0x87, meaning all 3 voltage classes (good), but also indicating that when the clock is stopped, it should be HIGH. However, the file characteristics byte returned in response to SELECT (both MF and DF_GSM) in the GSM 11.11 SIM protocol is 0xB1; decoding this byte per 3GPP TS 51.011, it says "clock stop allowed, no preferred level". Thus the file characteristics byte says that there is no preferred level, yet ATR says that HIGH level is preferred - or not just preferred, but required? (7816-3 seems to say it is only a preference, not a requirement; I seem to recall some other spec that said it's a requirement, but I can't find it now.) This discrepancy poses a potential problem if these cards are to be used in classic GSM/2G dumbphones whose original firmwares are based on the reference from TI. That reference fw code does not look at ATR for the purpose of determining allowed clock stop levels (most classic SIMs didn't have that T=15 TA byte in their ATR, it became commonly present when UICC/USIM stuff came along), instead it looks at the file characteristics byte returned in response to SELECT of DF_GSM. Furthermore, if the file characteristics byte says that there is no preferred level for clock stop, TI's reference fw configures the hw to leave the clock LOW during idle. I can only reason that other classic dumbphone firmwares (from other chip vendors) may very likely do the same: GSM SIM specs (11.11 and 51.011) don't require ME implementations to look at T=15 bytes in ATR, instead they direct MEs to follow the file characteristics byte. Can someone from Sysmocom officially confirm whether or not it is OK to operate sysmoISIM-SJA2 cards with clock stop at LOW level, contrary to ATR asking it to be HIGH? I have done a limited test of putting one of these cards into an FCDEV3B (with this aspect of the firmware left unmodified, so the clock line was low during idle) and the SIM interface appeared to still be alive after some deep sleep (clock stop) cycles. However, it was a very limited test, and I don't have my own network set up yet to make a more thorough test - and in any case, an official confirmation would be much better than anecdotal observations. TIA, Mychaela

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC