Project

General

Profile

Actions

Bug #5714

open

update_record_decoded does not use real record length when writing EF.MSISDN

Added by CHV over 1 year ago. Updated 6 months ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
pySim libraries
Target version:
-
Start date:
10/16/2022
Due date:
% Done:

90%

Spec Reference:

Description

I'm using old regular cards for testing.

Class EF_MSISDN, method _encode_record_hex always assumes a rec_len of 15 which results in misaligned/invalid data if the real record length is different.
The encoded msisdn must always use the last 14 bytes in the record. This can only be achieved when the real record length is used.

Example:

select MF/ADF.USIM/EF.MSISDN
update_record_decoded 1 {"msisdn":"+491234567890"}
read_record_decoded 1
read_record 1

This may also concern updating EF.ADN records.

Actions #1

Updated by laforge over 1 year ago

  • Category set to pySim libraries
  • Assignee set to chrysn

chrysn, would you mind looking into this? Thanks!

Actions #2

Updated by laforge 10 months ago

  • Description updated (diff)
Actions #3

Updated by laforge 10 months ago

  • Assignee changed from chrysn to dexter
Actions #4

Updated by dexter 7 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I think the problem here really is that there is only a minimum length specified by the spec. The spec explicitly allows to use larger record length. I have seen this also with other files while scrolling through the spec (51.011). I think with this in mind we have implemented our class LinFixedEF so that it knows a minimum_length and a recommended_length. However, as far as I can see the recommended_length does not make much sense, after all, its just a recommendation that may or may not be implemented in the card that we are currently working with.

I think what we really need is an information about from which side the data should be padded with 0xff in case the encoded data is shorter than the actual record length. In most cases adding padding on the right side is the only meaningful option, but in the case of EF.MSISDN, padding from the left side would be correct. So, all we need to do is to add a flag to the class model that tells where padding should be added and pass this information down to update_record in commands.py so that it can pad the record correctly.

A testvector:

update_record_decoded 1 {"msisdn":[1,3,"12345678901234567890"]}
expected: ffffffffffffffffffffffffffffffffffffffff0bb121436587092143658709ffff
got:      ff0bb121436587092143658709ffffffffffffffffffffffffffffffffffffffffff

Actions #5

Updated by laforge 7 months ago

On Wed, Sep 06, 2023 at 03:33:32PM +0000, dexter wrote:

I think what we really need is an information about from which side the data should be padded with 0xff in case the encoded data is shorter than the actual record length. In most cases adding padding on the right side is the only meaningful option, but in the case of EF.MSISDN, padding from the left side would be correct. So, all we need to do is to add a flag to the class model that tells where padding should be added and pass this information down to update_record in commands.py so that it can pad the record correctly.

sounds good. Probably best to make that flag optional, so that we only have to specify it in those few cases where padding on the left side is correct (without touching definitions of all other classes). The actual padding code can then use hasattr() to determine if that flag/attribute/class variable is actually set or not.

Actions #6

Updated by dexter 7 months ago

  • % Done changed from 10 to 90

I have fixed the problem now: https://gerrit.osmocom.org/c/pysim/+/34336 filesystem: add attribute "leftpad" to class LinFixedEF

Actions #7

Updated by dexter 7 months ago

  • Status changed from In Progress to Stalled

The patch above now got merged, which means that the problem is technically fixed. But there is still one open question: As we now the reason why the records are larger than the spec defines is that the additional free space is intended to be used as so called "Alpha Identifier" this is basically a string of text that says something like "Your Number: ". The question is now, whether the use of an Alpha Identifier is compatible with our leftpad-approach.

Since everything now works it is not pressing to answer this remaining question. For now we can consider the problem as fixed and set the ticket to stalled.

Actions #8

Updated by CHV 6 months ago

If you want to go with Alpha Identifiers, see TS 131 102, 4.2.26: EF_MSISDN.

The length of the Alpha identifier is not fixed, it depends on the actual EF's record size which varies between different SIM.

One record of EF.MSISDN consists of:
x bytes Alpha Identifier;
1 byte length of number;
1 byte TON an NPI;
10 bytes dialling number;
1 byte Capability/Configuration 2 identifier;
1 byte Extension5 Record Identifier.

So there are x = (record size - 14) bytes available for the Alpha Identifier.

Padding of Alpha Identifier and dialling number is mandatory.

The structure of DF.TELECOM/EF.ADN is very similar.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)