pySim/sms.py:23:0: W0404: Reimport 'Flag' (imported line 23) (reimported)
pySim/sms.py:54:4: C0103: Method name "fromBytes" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:60:4: C0103: Method name "toBytes" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:120:4: C0103: Method name "fromBytes" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:132:4: C0103: Method name "fromSmpp" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:137:4: C0103: Method name "toSmpp" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:141:4: C0103: Method name "toBytes" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:188:4: C0103: Method name "fromBytes" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:192:8: W0612: Unused variable 'flags' (unused-variable)
pySim/sms.py:209:4: C0103: Method name "toBytes" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:228:4: C0103: Method name "fromSmpp" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:236:4: C0103: Method name "fromSmppSubmit" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:279:4: C0103: Method name "fromBytes" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:306:12: W0107: Unnecessary pass statement (unnecessary-pass)
pySim/sms.py:311:12: W0107: Unnecessary pass statement (unnecessary-pass)
pySim/sms.py:319:4: C0103: Method name "toBytes" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:339:4: C0103: Method name "fromSmpp" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:347:4: C0103: Method name "fromSmppSubmit" doesn't conform to snake_case naming style (invalid-name)
pySim/sms.py:373:4: C0103: Method name "toSmpp" doesn't conform to snake_case naming style (invalid-nam
Change-Id: I8082a01443ef568eebda696239572f0af7b56f1b
In smart cards, we every so often encounter data types that contain a
bit-mask whose length depends on whether or not there are any of the
least-significant bits are set. So far we worked around this with
some kind of Struct('byte1', 'byte2'/COptional, 'byte3'/COptional)
approach.
Let's do thisin a generic way using the new StripTrailerAdapter.
Change-Id: I659aa7247c57c680895b0bf8412f9e477fc3587d
GlobalPlatform requires the use of the KCV for DES + AES keys. Let's
implement that.
(11.8.2.3.3: "For all key types described in section B.6, the Key Check
Value shall be present.")
Change-Id: Ief168a66dee58b56f4126db12829b3a98906c8db
This adds an implementation of the GlobalPlatform SCP03 protocol. It has
been tested in S8 mode for C-MAC, C-ENC, R-MAC and R-ENC with AES using
128, 192 and 256 bit key lengh. Test vectors generated while talking to
a sysmoEUICC1-C2T are included as unit tests.
Change-Id: Ibc35af5474923aed2e3bcb29c8d713b4127a160d
This implementation of GlobalPlatform SCP02 currently only supports
C-MAC and C-ENC, but no R-MAC or R-ENC yet.
The patch also introduces the notion of having a SCP instance associated
with a SimCardCommands instance. It also adds the establish_scp0w and
release_scp shell commands to all GlobalPlatform Security Domains.
Change-Id: I56020382b9dfe8ba0f7c1c9f71eb1a9746bc5a27
Let's simply use the matchingId for filesystem lookup of the UPP file.
This way we can have any number of profiles by simply creating the
respeective files.
Change-Id: I0bc3a14b9fdfcc6322917dd0c69d8295de486950
The DGI encoding is specified in Annex B of the
"GlobalPlatform Systems Scripting Language Specification v1.1.0"
which is an "archived" specification that is no longer published
by GlobalPlatform, despite it being referenced from the GlobalPlatform
Card Specification v2.3, which is the basis of the GSMA eSIM
specifications.
For some reason it was the belief of the specification authors that
yet another format of TLV encoding is needed, in addition to the BER-TLV
and COMPREHENSION-TLV used by the very same specifications.
The encoding of the tag is not really specified anywhere, but I've only
seen 16-bit examples. The encoding of the length is specified and
implemented here accordingly.
Change-Id: Ie29ab7eb39f3165f3d695fcc1f02051338095697
This commit introduces the capability to parse and encode
SimAlliance/TCA "Interoperable Profiles" and apply personalization
operations on them.
Change-Id: I71c252a214a634e1bd6f73472107efe2688ee6d2
This commit introduces
* the osmo-smdpp.py program implementing the main procedures and the
HTTP/REST based ES9+
* python modules for ES8+ and non-volatile RSP Session State storage
* the ASN.1 source files required to parse/encode RSP
* 3GPP test certificates from SGP.26
* an unsigned profile package (UPP) of a SAIP v2.3 TS48 test profile
As I couldn't get the 'Klein' tls support to work, the SM-DP+ code
currently does not support HTTPS/TLS but plan HTTP, so you either have
to modify your LPA to use HTTP instead of HTTPS, or put a TLS proxy in
front.
I have successfully installed an eSIM profile on a test eUICC that
contains certificate/key data within the test CI defined in GSMA SGP.26
Change-Id: I6232847432dc6920cd2bd08c84d7099c29ca1c11
This is the protocol used for the ES8+ interface between SM-DP+ and the
eUICC in the GSMA eSIM system.
Change-Id: Ic461936f2e68e1e6f7faab33d06acf3063e261e7
We cannot fully switch to construct for all of it easily due to
the priority value and the ordering/sorting by priority implemented
in the hand-coded version. But we can at least migrate the
encode/decode of the hnet_pubkey_list via construct.
Change-Id: I4ad5ea57bab37c2dc218e7752d538aa4cdc36ee3
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
TS 102 221 Annex A defines three variants of encoding UCS-2 characters
into byte streams in files on UICC cards: One rather simplistic one, and
two variants for optimizing memory utilization on the card.
Let's impelement a construct "Ucs2Adapter" class for this.
Change-Id: Ic8bc8f71079faec1bf0e538dc0dfa21403869c6d
While we do have the _test_de_encode data driven tests for file
definitions, we don't yet have something similar for derived classes of
BER_TLV_IE. This means that TLVs used outside of the filesystem context
(for example, decoding the SELECT/STATUS response, but also eUICC and
other stuff) do not yet have test coverage.
This commit just adds the related test code, but no test data yet.
Related: OS#6317
Change-Id: Ied85f292bb57fde11dc188be84e3384dc3ff1601
on some systems, the output would otherwise contain colored status
words, which in turn mean the test otuput no longer matches the expected
output.
Change-Id: Icb700f6e85a285748e00367a398975aa5e75dec5
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
Without this the diff between expected and actual output is truncated
and one instead reads the following output:
Diff is 844 characters long. Set self.maxDiff to None to see it.
We actually want to see the full diff to see what's not matching.
Change-Id: I6e89705061454191b6db1255de7fe549ad720800
When we initialize the reader, we currently tell only which type of
interface we are using, but we do not print the reader number or the
device path.
Let's extend the messages so that the path is printed. To prevent
problems with integration-tests, let's also add an environment variable
that we can use to detect when pySim runs inside a integration-test.
Related: OS#6210
Change-Id: Ibe296d51885b1ef5f9c9ecaf1d28da52014dcc4b
At the moment we only verify that no exceptions occurred but the output
is not yet verfied.
Related: OS#6094
Change-Id: I3aaa779b5bd8f30936c284a80dbdcb2b0e06985c
We now have pySim-shell and pySim-trace. Let's give pysim-test.sh a more
distinctive name so that it is clear to which program it refers.
Related: OS#6094
Change-Id: I438f63f9580ebd3c7cc78cc5dab13c9937ac6e3a
pySim-trace has no test coverage yet. Let's use a script to run a
GSAMTAP pcacp through it and check that no exceptions are raised.
Related: OS#6094
Change-Id: Icfabfa7c59968021eef0399991bd05b92467d8d2
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
There are some functions / classes which are only needed by the legacy
tools pySim-{read,prog}, bypassing our modern per-file transcoder
classes. Let's move this code to the pySim/legacy sub-directory,
rendering pySim.legacy.* module names.
The long-term goal is to get rid of those and have all code use the
modern pySim/filesystem classes for reading/decoding/encoding/writing
any kind of data on cards.
Change-Id: Ia8cf831929730c48f90679a83d69049475cc5077
Rather than writing one test class with associated method for each
OTA algorithm / test, let's do this in a data-driven way, where new
test cases just have to provide test data, while the code iterates over
it.
Change-Id: I8789a21fa5a4793bdabd468adc9fee3b6e633c25
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
This introduces a hierarchy of classes implementing
* ETS TS 102 225 (general command structure)
* 3GPP TS 31.115 (dialects for SMS-PP)
In this initial patch only the SMS "dialect" is supported,
but it is foreseen that USSD/SMSCB/HTTPS dialects can be
added at a later point.
Change-Id: I193ff4712c8503279c017b4b1324f0c3d38b9f84
This introduces a new pySim.apdu module hierarchy, which contains
classes that represent TPDU/APDUs as exchanged between
SIM/UICC/USIM/ISIM card and UE.
It contains instruction level decoders for SELECT, READ BINARY and
friends, and then uses the pySim.filesystem.Runtime{Lchan,State} classes
to keep track of the currently selected EF/DF/ADF for each logical
channel, and uses the file-specific decoder classes of pySim to decode
the actual file content that is being read or written.
This provides a much more meaningful decode of protocol traces than
wireshark will ever be able to give us.
Furthermore, there's the new pySim.apdu_source set of classes which
provides "input plugins" for obtaining APDU traces in a variety of
formats. So far, GSMTAP UDP live capture and pyshark based RSPRO
live and pcap file reading are imlpemented.
Change-Id: I862d93163d495a294364168f7818641e47b18c0a
Closes: OS#5126
The DataObject is some weird / rarely used different code than the
normal TLV encoder/decoder. It has apparently so far only been used
for decoding, without testing the encoding side, resulting in related
bugs.
Let's fix those that I encountered today, and add a test case.
Change-Id: I31370066f43c22fc3ce9e2b9ee75986a652f6fc4
We have a number of integers with variable-length encoding, so
add a Construct for this. Naming inspired by GreedyBytes.
Related to https://github.com/construct/construct/issues/962
Change-Id: Ic6049b74ea3705fda24855f34b4a1d5f2c9327f7
when encoding the AcT value bit 11 is correctly set
when NG-RAN is present in the string representation,
however the decoding of bit 11 was missing.
Adds tests for the decoder as well.
Change-Id: I910df28c4c59ec94cce9603377786325f6d8c1a3
When the Access Technology Identifier encoder sets the bits for E-UTRAN
it does not respect that bit "100" is also a valid bit combination that
encodes E-UTRAN WB-S1 and E-UTRAN NB-S1. Lets encode this bit
combination if the user is just specifying "E-UTRAN" without further
spefication of WB or NB.
The decoder only looks at bit 14 and decodes "1xx" always to "E-UTRAN".
This is not specific enough. Lets make sure that the decoder is
complementary to the encoder.
Change-Id: Ibfe8883a05f9ad6988d8e212cb9a598229954296
Related: OS#4963
The function dec_xplmn_w_act(), which is also used by
format_xplmn_w_act() is using integer numbers as MCC/MNC representation.
This causes various problems since the information about leading zeros
gets lost.
Change-Id: I57f7dff80f48071ef9a3732ae1088882b127a6d4