Let's make sure we don't even bother to ask the card to verify
anything as ADM1 pin which is not either a sequence of decimal digits
or an even number of hex digits (even number of bytes).
Change-Id: I4a193a3cf63462fad73d145ab1481070ddf767ca
We used to support only single-byte tags in bertlv_encode_tag,
let's fix that. The easy option is to simply call bertlv_parse_tag,
as that already supported multi-byte tags.
Change-Id: If0bd9137883c4c8b01c4dfcbb53cabeee5c1ce2b
TLV fields holding an address may still be uninitialized and hence
filled with 0xff bytes. Lets interpret those fields in the same way as
we interpret empty fields.
Related: OS#6094
Change-Id: Idc0a92ea88756266381c8da2ad62de061a8ea7a1
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
So for some weird historical reasons, the same python module is
available as pycryptodome (Crypto.* namespace) and pycryptodomex
(Cryptodome.* namespace). See the following information on the project
homepage: https://www.pycryptodome.org/src/installation
To make things extra-weird, Debian choose to package pycryptodomex as
python3-pycryptodome
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886291).
So in order to support both Debian-packaged and differently-installed
packages, let's switch to pycryotodomex on all platforms/installers.
Change-Id: I04daed01f51f9702595ef9f9e0d7fcdf1e4adb62
When updating files and records there are sometimes huge portions that
are just 0xff. Mostly this is at the end of a file or record that is not
completely used. Lets add a notation to tell PySim-shell how to fill
those sections.
Change-Id: Iedd7887bf7d706878f4a3beca8dbea456404610b
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 had a mixture of tab and 4space based indenting, which is a bad
idea. 4space is the standard in python, so convert all our code to
that. The result unfortuantely still shoed even more inconsistencies,
so I've decided to run autopep8 on the entire code base.
Change-Id: I4a4b1b444a2f43fab05fc5d2c8a7dd6ddecb5f07
At least on Debian 10 and unstable, I'm getting this error for pylint:
************* Module pySim.utils
pySim/utils.py:570:1: E0611: No name 'strxor' in module 'Crypto.Util.strxor' (no-name-in-module)
despite it clearly existing:
>>> import Crypto.Util.strxor
>>> Crypto.Util.strxor.strxor
<built-in function strxor>
So let's suppress the related pylint error.
Change-Id: Iea89e758782a569be953d19892028f083a92c2f1
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
UICC and old SIM cards can be difficult to tell apart without prior
knowledge of the card. The ATR won't tell if the card is UICC or not.
The only remaining option is to try out if the card is able to handle
UICC APDUs. The same is true for 2G SIM cards. It is not guranteed that
every UICC card will have 2G functionality.
Lets add functionality to match a profile to the currently plugged card
by actively probing it.
Lets also add another profile to distinguish between UICC-only cards and
UICC cards that include SIM functionality.
Change-Id: If090d32551145f75c644657b90085a3ef5bfa691
Related: OS#5274
The transport layer provides a method send_apdu_checksw to send APDUs
and to be sure the SW is the expected one. Given that, there is no need
to verify the SW manually. The exception of send_apdu_checksw will catch
the problem and also display the SW in a human readable form.
Change-Id: I9ce556ac0b7bb21c5c5a27170c32af0152255b79
Related: OS#5275
We cannot simply skip anything that has 0xFF as first byte to detect
the padding after the end of a TLV object:
0xFF may very well be a valid first octet of a multi-octet TAG:
Tags of private class (11) with constructed (1) payload will have 0xFF
as first octet.
So let's expand the check to only detect padding in case of either only
a single byte FF being left, or two FF following each other [with
whatever suffix].
Change-Id: I5d64ce9ef1d973804daabae0b15c2e2349e6fab9
The existing {comprehension,ber}tlv_parse_tag() functions are
decoding the tag to a high level of detail. However, all the 3GPP
specs seem to deal with the 'raw' version, i.e something like
0xD1 as a single-byte tag with the class + constructed fields already
shifted next to the actual tag value.
Let's accommodate that with new *_parse_tag_raw() functions.
Change-Id: Ib50946bfb3b3ecd7942c423ac0f98b6c07649224
The function dec_addr_tlv() takes an encoded FQDN or IPv4 address and
fromats it into a human readable string that contains the human readable
form and the encoded hex form. Unfortunately this limits the usecase of
dec_addr_tlv. Lets split the string generation into a separate function
so that we can use dec_addr_tlv universally
Change-Id: Id017b0786089adac4d6c5be688742eaa9699e529
Related: OS#4963
This will replace the hand-crafted codec for EF_SPN
by a struct definition using the construct library.
Old encoders are updated and kept for API compatibility
but are not used internally anymore.
New data structures:
* Rpad(Adapter): Right-padded bytestring (0xff, adjustable)
* GsmStringAdapter(Adapter): Codec for "SMS default 7-bit
coded alphabet as defined int TS 23.038" using
the gsm0338 library.
* GsmString(n): Convenient wrapper of both above
Adjustments:
* utils: update+deprecate old dec_spn(), enc_spn()
* remove refs to deprecated functions
Change-Id: Ia1d3a3835933bac0002b7c52511481dd8094b994
This adds support for a new EF file type: BER-TLV files. They are
different from transparent and linear fixed EFs in that they neither
operate on a byte stream nor fixed-sized records, but on BER-TLV encoded
objects. One can specify a tag value, and the card will return the
entire TLV for that tag.
As indicated in the spec, the magic tag value 0x5C (92) will return a
list of tags existing in the file.
Change-Id: Ibfcce757dcd477fd0d6857f64fbb4346d6d62e63
This will allow us to match INS -> name and add more related
bits in the future (e.g. for decoding APDU traces)
Change-Id: I314ff15186dc05778ea12363cac0a310b6c7713c
Represents DataObject (DO) in the sense of ISO 7816-4. Contrary to
'normal' TLVs where one simply has any number of different TLVs that may
occur in any order at any point, ISO 7816 has the habit of specifying
TLV data but with very specific ordering, or specific choices of tags at
specific points in a stream. This is represented by DataObjectChoice,
DataObjectCollection and DataObjectSequence classes.
Change-Id: Iac18e7665481c9323cc7d22a3cd93e3da7869deb
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
The dec_plmn function takes an hexstring and returns the decoded MCC and
MNC as integer values. The result is then used by the json encoder in
EF_PLMNsel, which means the json output will contrary to the input, use
integer values instead of strings.
This is not correct since there may be leading zeros (e.g. mnc 01 and
001 both exist are different) which must be retained in order to know
the correct length of the MNC.
Related: OS#4963
Change-Id: I393e04836814d992d2a6d0a4e4e01850976d6e81
To prevent missunderstandings when using enc_plmn(), specify the input
and return parameters as Hexstr.
Change-Id: I57cf8e2de357650aef2a06fbffc7615ccb2a45b4
Related: OS#4963
The encoding of EF.MSISDN is a bit unstrutured. The encoder function
does not return a valid result since it lacks the parameters
Capability/Configuration2 Record Identifier and Extension5 Record
Identifier, which are mandatory but can be set to 0xFF. Also the
encoder gets its input from pySim-shell, so it should have some
more input validation, especially when the user encodes an empty
string. The encoder and decoder function also do not have unit-tests.
Since the encoder now adds the missing two bytes by isself this does
not have to be done manually anymore, so cards.py needs to be
re-aligned.
For pySim-shell.py the encoder is used from ts_51_011.py. Unfortunately
it is used wrongly there. The optional Alpha Identifier is required
here as well.
Related: OS#4963
Change-Id: Iee5369b3e3ba7fa1155facc8fa824bc60e33b55b
the export summary is printed after the log entry for the last file
without separation. This is confusing because it looks like if the
summary would refer to the last file only. Lets add a headline to make
clear that the last few lines are the "Export summary"
Change-Id: I90771e525b2b114bdb41a8e90d298ca991c09c3d
Related: OS#4963
This means we can skip a lot of code that manually converts from
bytes to hex before JSON serialization.
Change-Id: I9c9eff0556d9d196e64553b5276e162f69d0c18f
This function is being used e.g. for ADF.USIM/EF.FPLMN entries.
The EF_PLMNsel class also already uses a function by this name, we just
haven't had any actual implementation around.
Change-Id: Iacb45c90bb6491ebb89a477a85ef1f3129b38788
* add type annotations in-line with PEP484
* convert existing documentation to follow the
"Google Python Style Guide" format understood by
the sphinx.ext.napoleon' extension
* add much more documentation all over the code base
Change-Id: I6ac88e0662cf3c56ae32d86d50b18a8b4150571a