With the introduction of using osmocom.construct.{Bytes,GreedyBytes}
in Change-Id I1c8df6350c68aa408ec96ff6cd1e405ceb1a4fbb we don't have a
need for wrapping each instance of Bytes or GreedyBytes into a
HexAdapter anymore. The osmocom.construct.{Bytes,GreedyBytes} will
automatically perform the related hex-string-to-bytes conversion if
needed - and during printing we have osmocom.utils.JsonEncoder that
makes sure to convert any bytes type to a hex-string.
Change-Id: I9c77e420c314f5e74458628dc4e767eab6d97123
The new architecture avoids sim/ruim/uicc specific methods in
pySim.profile and instead moves the profile-specific code into the
profile; it also solves everything within the class hierarchy, no need
for global methods.
Change-Id: I3b6c44d2f5cce2513c3ec8a3ce939a242f3e4901
This was suggested by vyanitskiy during gerrit patch review in
https://gerrit.osmocom.org/c/pysim/+/38049 in order to make the
upcoming eUICC CardProfiles simpler.
Change-Id: Ia7c049b31cb1c5c5bb682406d9dd7a73bcd43185
We're creating a 'pyosmocom' pypi module which contains a number of core
Osmocom libraries / interfaces that are not specific to SIM card stuff
contained here.
The main modules moved in this initial step are pySim.tlv, pySim.utils
and pySim.construct. utils is split, not all of the contents is
unrelated to SIM Cards. The other two are moved completely.
Change-Id: I4b63e45bcb0c9ba2424dacf85e0222aee735f411
pySim/cdma_ruim.py:30:0: W0401: Wildcard import construct (wildcard-import)
pySim/cdma_ruim.py:188:4: W0237: Parameter 'data_hex' has been renamed to 'resp_hex' in overriding 'CardProfileRUIM.decode_select_response' method (arguments-renamed)
pySim/cdma_ruim.py:30:0: C0411: third party import "from construct import *" should be placed before "from pySim.utils import *" (wrong-import-order)
Change-Id: I4c384f37a6a317c6eddef8742572fcfa76a5fc20
It's customary in the SIM card universe to right-pad data with ff bytes.
So far we only test decoders without such padding, which is unrealistic.
Let's also tests the decoders with extra 'ff' padding present.
For some files this doesn't make sense, so we add a _test_no_pad class
attribute that can be spcified to prevent this new "test with ff-padding"
from being executed for the test data of the class.
Change-Id: I7f5cbb4a6f91040fe9adef9da0a1f30f9f156dae
We have a strict "one CardProfile per card" rule. For a modern UICC
without legacy SIM support, that works great, as all applications
have AID and ADF and can hence be enumerated/detected that way.
However, in reality there are mostly UICC that have legacy SIM, GSM-R
or even CDMA support, all of which are not proper UICC applications
for historical reasons.
So instead of having hard-coded hacks in various places, let's introduce
the new concept of a CardProfileAddon. Every profile can have any
number of those. When building up the RuntimeState, we iterate over the
CardProfile addons, and probe which of those are actually on the card.
For those discovered, we add their files to the filesystem hierarchy.
Change-Id: I5866590b6d48f85eb889c9b1b8ab27936d2378b9
As pySim.cdma_ruim was not imported by test_files.py, the unit tests
were apparently never executed and hence didn't pass. Let's fix both
of those problems.
Change-Id: Icdf4621eb68d05a4948ae9efeb81a007d48e1bb7
R-UIM (CDMA) cards are pretty much like the normal GSM SIM cards and
"speak" the same 2G APDU protocol, except that they have their own file
hierarchy under MF(3f00)/DF.CDMA(7f25). They also have DF.TELECOM(7f10)
and even DF.GSM(7f20) with a limited subset of active EFs. The content
of DF.CDMA is specified in 3GPP2 C.S0023-D.
This patch adds a very limited card profile for R-UIM, including auto-
detecion and a few EF definitions under DF.CDMA. This may be useful
for people willing to explore or backup their R-UIMs. To me this was
useful for playing with an R-UIM card from Skylink [1] - a Russian
MNO, which provided 450 MHz CDMA coverage until 2016.
[1] https://en.wikipedia.org/wiki/Sky_Link_(Russia)
Change-Id: Iacdebdbc514d1cd1910d173d81edd28578ec436a
