# HG changeset patch # User Mychaela Falconia # Date 1616448512 0 # Node ID a754d4f117cff0c5134848253ee780add0ada9d9 # Parent 812779459ddd83cc0526bbe85c1e437a5484d194 doc/Formatting-thoughts: new article, split from Sysmocom-SIM-notes and updated for Grcard situation diff -r 812779459ddd -r a754d4f117cf doc/Formatting-thoughts --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/Formatting-thoughts Mon Mar 22 21:28:32 2021 +0000 @@ -0,0 +1,50 @@ +Thoughts on card (re)formatting +=============================== + +ETSI and 3GPP specs give many more degrees of freedom to SIM card issuers than +just the content of various EFs: the card issuer gets to decide which DFs and +EFs will be present vs. which ones won't be present at all, and for many EFs +the size (allocated space) is variable per the specs and up to the card issuer. +In the case of record-based EFs, both the record size and the number of records +are often left up to card issuers to tune as desired. + +In the Mother's opinion, a truly programmable SIM would be one where every +downstream owner of each card (not just the initial factory or the party putting +up big bucks for a large custom production run) can do a full reformat: erase +the file system and then create whatever tree of DFs and EFs she desires, with +full control over each file's allocated size, structure and access conditions. + +The problem, however, is that the people who work with big bucks and who control +SIM card manufacturing have taken away our community's ability to freely +reformat our programmable SIMs downstream of the factory. To the best of our +knowledge, there has only ever been one SIM card model in the entire history of +Osmocom community that supported downstream reformatting, and this model was +sysmoSIM-GR1: + +https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM + +But Grcard company no longer sells that original card model, and for their new +card model (GrcardSIM2, branded sysmoSIM-GR2 or FCSIM1) there is no published +documentation for how to erase the card file system and recreate it differently. +We can only guess that this ability probably exists, but Grcard people are +refusing to disclose the secret knowledge of how to do it unless we pay them +some ginormous sum of money. + +The current offering from Sysmocom (sysmoISIM-SJA2) does not fare any better in +this regard. These cards are natively UICC, and in the world of UICC there +exist partially standarized commands for creating and deleting files, defined in +ETSI TS 102 222. However, these commands are only partially standardized: the +ETSI spec gives the general principles and the command structure, but many of +the details as to exactly what needs to be put into the TLV structure fed to the +CREATE FILE command in order for that command to succeed constitute proprietary +knowledge. Our experiments with this CREATE FILE command on sysmoISIM-SJA2 were +unsuccessful. The only way how the file structure of Sysmocom cards would +become truly editable by end users would be if Sysmocom were to publish at least +one fully worked-out example of a real CREATE FILE command that creates some +dummy non-standard file just to prove it working, followed by a working example +of a DELETE FILE command that deletes this newly created file, restoring the +card to its original state. However, we reason that Sysmocom would probably be +willing to do this support work only if someone paid them for it on an hourly +support basis, or ordered a large custom batch of cards from them and required +this support knowledge as part of that deal - and we (FreeCalypso) are not +currently in a position to pursue either of those two routes.