WIP / RFC for pysim 'next generation;' aka pysim-shell

Mychaela Falconia mychaela.falconia at gmail.com
Wed Apr 7 00:40:54 UTC 2021

Harald Welte wrote:

> * we now have a 'tree' command to list the filesystem hierarchy

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:


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.


More information about the OpenBSC mailing list