There are more files where trailing digits are indicated using 'f' and
should be stripped during decode, including EF.MSISDN and EF.VGCS
This is not just a presentation issue, but actually rendered wrong data
before, see the modified test output where our "read_record_uicc.ok"
file contained "bcd_len: 7" but then only 6 BCD digits due to this bug.
Change-Id: I4571482da924a3d645caa297108279d182448d21
As the input phone number ("address") might be of an odd length of
digits, let's use PaddedBcdAdapter to fix two problems:
1) strip any potential trailing f in decoding
2) fix truncation of last digit during encoding
Change-Id: I1e9865e172bc29b8a31c281106d903934e81c686
Depends: pyosmocom Ib5afb5ab5c2bc9b519dc92818fc6974f7eecba16 (0.0.12
EF.SMSP contains up to two addresses: Both are stored in a fixed-length
field of 12 octets. However, the actually used size depends on the
number of digits in the respective number. Let's compute that length
field properly
Change-Id: Idef54a3545d1a5367a1efa2f0a6f7f0c1f860105
* add another set of test data (from a real-world SIM card)
* switch from test_decode to test_de_encode as our encoder now works due
to previous commits.
Change-Id: I8d16e195641bb59b2c26072008f88434692c0cab
There's a 3-bit RFU field that (unlike everything else in USIM/UICC)
considers '1' to be the default. Let's make sure we get that right
during encode.
Change-Id: Ibe24a07f5f73d875d2077fa55471dbfc4e90da23
TS 51.011 Section 10.5.6 refers to clause 10.5.1 (EF.ADN),
and the latter permits UCS2 in addition to 7-bit GSM alphabet.
Change-Id: If10b3d6d8b34ece02dc0350ca9ea9c3f8fbf3c9e
Otherwise we might compute float values and fail encoding like this:
> construct.core.FormatFieldError: Error in path (building) -> tp_vp_minutes
> struct '>B' error during building, given value 169.0
Change-Id: I989669434c7ddee9595ee81a0822f9966907a844
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 unittest for EF.CFIS only runs with _test_decode, but it also runs with
_test_de_encode without any problems
Related: OS#5714
Change-Id: Ib876fd799f871fe64ced2a7b64847ffd09e16ed9
The unittest for EF.ADN can run with _test_de_encode. However, the original
test vectors seem to be from a card with a slightly larger record size, so
they need a bit of re-alignment
Related: OS#5714
Change-Id: I241792e66ee6167be6ddc076453344b6307d6265
The encoding of EF.MSISDN is currently done with enc_msisdn and
dec_msisdn from utils.py. Let's replace this with a construct
based model, similar to the one we already use with EF.ADN
Related: OS#5714
Change-Id: I647f5c63f7f87902a86c0c5d8e92fdc7f4350a5a
In our construct models we frequently use a context parameter "total_len",
we also pass this parameter to construct when we decode files, but we
do not pass it when we generate files. This is a problem, because when
total_len is used in the construct model, this parameter must be known
also when decoding the file.
Let's make sure that the total_len is properly determined and and passed
to construct (via pyosmocom).
Related: OS#5714
Change-Id: I1b7a51594fbc5d9fe01132c39354a2fa88d53f9b
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
When we define positional arguments for the argument parser, we usually
use upper case letters only. However, there are some code locations that
use lower case letters. Let's translate those to capital letters to
have a consistent appeariance.
Related: OS#6531
Change-Id: Iec1ff8262bc6e9cf87c3cbf7b32fa5f753b7e574
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
So far we only had the EF.ICCID and EF.PL within our UICC card profile.
However, a classic GSM SIM card is not an UICC, so the CardProfileSIM
also needs those files.
To avoid circular dependencies, move the definitions from ts_102_221.py
to ts_51_011.py
Change-Id: I6eaa5b579f02c7d75f443ee2b2cc8ae0ba13f2fe
Closes: OS#6485
We do have an is_hexstr function which we should use anywhere
where we expect the user to input a string of hex digits. This way
we validate the input before running in some random exception.
Change-Id: I6426ea864bec82be60554dd125961a48d7751904
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
Now that we have support for the UCS-2 encoding as per TS 102 221 Annex A,
we can start to make use of it from various file constructs.
As some specs say "Either 7-bit GSM or UCS-2" we also introduce
a related automatic GsmOrUcs2Adapter and GsmOrUcs2String class.
Change-Id: I4eb8aea0a13260a143e2c60fca73c3c4312fd3b2
The human representation of a PLMN is usually MCC-MNC like 262-01
or 262-001. Let's add a PlmnAdapter for use within construct, so we
can properly decode that.
Change-Id: I96f276e6dcdb54a5a3d2bcde5ee6dbaf981ed789
The EF.CFIS definition is not identical to EF.ADN, so we cannot recycle
the EF.ADN class to decode EF.CFIS.
Change-Id: Idcab35cbe28332e3c8612bcb90226335b48ea973
There are some pretty intricate rules about how GSM and E-UTRAN are
encoded, let's make sure we fully support both as per 3GPP TS 31.102
Release 17. As part of this, switch to a sorted list of access technologies,
in order to have a defined order. This makes comparing in unit tests
much easier. However, it also means that we need to sort the set
when printing the list of AcT in pySim-read to generate deterministic
output.
Change-Id: I398ac2a2527bd11e9c652e49fa46d6ca8d334b88
This new approach will "fork" separate SimCardCommands instances
for each RuntimeLchan. Higher-layer code should now always use the
RuntimeLchan.scc rather than the RuntimeState.card._scc in order to
make sure commands use the correct logical channel.
Change-Id: I13e2e871f2afc2460d9fd1cd566de42267c7d389
Related: OS#6230
While our base classes (TransparentEF / LinFixedEF) always have the
dsecription as 4th argument after "fid, sfid, name", most of the derived
file-specific classes do not share that same argument order.
As seen in the bug fixed by previous Change-Id I7f32c9fd01094620b68b0e54536ecc6cdbe67903
this can have serious consequences. Let's avoid using unnamed
(positional) arguments for the description text altogether.
Change-Id: Icfb3fd1bae038c54fa14a91aa9f75219d839968c
In some cases, the specs do not specify an absolute record length.
Instead there may be only a minimum record length specified. The card
vendor may then chose to use larger record length at will. This usually
is no problem since the data is usually written from the left and the
remaining bytes are padded at the end (right side) of the data. However
in some rare cases (EF.MSISDN, see also 3GPP TS 51.011, section 10.5.5)
the data must be written right-aligned towards the physical record
length. This means that the data is padded from the left in this case.
To fix this: Let's add a "leftpad" flag to LinFixedEF, which we set to
true in those corner cases. The code that updates the record in
commands.py must then check this flag and padd the data accordingly.
Change-Id: I241d9fd656f9064a3ebb4e8e01a52b6b030f9923
Related: OS#5714
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
Those old flat dicts indicating FID to string-name mapping have long
been obsoleted by the pySim.filsystem based classes.
Change-Id: I20ceea3fdb02ee70d8c8889c078b2e5a0f17c83b
Just like the existing commands for UST/IST: Allow the user to
activate/deactivate individual services. As EF.SST also contains
information about "allocation" of a service, let's have commands for
allocation and activation.
Change-Id: If959d06248cb1a9d2c0a21cdd40d438726cbc5f0
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
Even though _bit_byte_offset_for_service() is a @staticmethod, it's
still available via self, just like any non-static method.
Change-Id: I3590dda341d534deb1b7f4743ea31ab16dbd6912
Lets add test vectors for the per-record/per-file encode/decode of
our various classes for the Elementary Files.
We keep the test vectors as class variables of the respective EF-classes
to ensure implementation and test vectors are next to each other.
The test classes then iterate over all EF subclasses and execute the
decode/encode functions using the test vectors from the class variables.
Change-Id: I02d884547f4982e0b8ed7ef21b8cda75237942e2
Related: OS#4963
ValidityPeriodAdapter() must return integer values when encoding a
value, as only integer values can be expressed in the binary format.
Change-Id: I0b431a591ac1761d875b5697a71b6d59241db87d
When decoding the SELECT response of a clasic GSM SIM without
UICC functionality, we
* did not decode the record length or number of records
* accidentially reported the EF file_size as available_memory (like DF)
Let's fix those two, and also add a comment on how the output dict
of decode_select_response() should look like.
As a result, code like 'read_records' now knows the number of records
and can iterate over them rather than raising exceptions.
Change-Id: Ia8e890bda74e3b4dacca0673d6e5ed8692dabd87
Closes: OS#5874
This file is a optional file specified by TS 51.011, storing the last
numbers dialled. As the EIRENE FFFIS for GSM-R SIM refers to this,
we must implement it to have full GSM-R support in pySim.
Change-Id: I3b7d6c7e7504b7cc8a1b62f13e8c0ae83a91d0f0
Related: OS#5784
We're using a shared class to implement the identical file encoding
for EF.{ADN,SDN,MBDN,BDN,FDN,CFIS}. However, they all point to
different extension files.
Previosly for EF.SDN:
"ext1_record_id": 255
Now for EF.SDN:
"ext3_record_id": 255
Change-Id: I5301d41225266d35c05e41588811502e5595520d
Related: OS#5784
TS 51.011 specifies an "Extended BCD Coding" in Table 12 of Section
10.5.1. It allows to express the '*' and '#' symbols used in GSM
SS and/or USSD codes.
This improves decoding from
"dialing_nr": "a753b1200f",
to
"dialing_nr": "*753#1200f",
Change-Id: Ifcec13e9b296dba7bec34b7872192b7ce185c23c
Related: OS#5784
DF.TELECOM/EF.SDN (Service Dialling Numbers) is specified in section
10.5.9 of TS 51.011 and required by EIRENE for GSM-R.
Let's use the pre-existing EF.ADN decoder to decode this file.
Change-Id: If91332b10138096d465a9dccf90744de2c14b2be
Related: OS#5784
Those files contain a bit-mask of active group IDs stored at the
respective positions in EV.VGCS and EF.VBS. However, the bit-order
of each byte is reversed.
Change-Id: I77674c23823aae71c9504b1a85cd75266edadc6f
Related: OS#5784
In their infinite wisdom, the authors of the EIRENE FFFIS for GSM-R SIM
cards invented yet a new way of encoding data in SIM card files: The
first record of a file may be encoded differently than further records
of files.
Let's add the required infrastructure to pySim so that the encode and
decode methods for record-oriented files get passed in the current
record number.
Change-Id: I02d6942016dd0631b21d1fd301711c13cb27962b
Related: OS#5784
The size should be a *tuple*. In reality we so far passed a set. The
problem with the set is that ordering is not guaranteed, and hence we
cannot assume the first and second item have meaning (minimum vs.
default record length).
Change-Id: I470f4e69c83cb2761861b3350bf8d49e31f4d957
