Bug #5254

Error in programmin Ki with PySim-prog

Added by abouillot 7 days ago. Updated 4 days ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


When using pySim-prog, the value of the Ki written on the card is shifted by on hex digit to the left and an extra 0xFF is written at the end. pySim-prog display the values as passed as parameters, but not the actual written values.

./ -p 0 --iccid=8988211910000000987 --pin-adm=11111111 --mcc=214 --mnc=03 --imsi=214030123456789  -k 00ffeeddccbbaa998877665544332211@

Using PC/SC reader interface
Ready for Programming: Insert card now (or CTRL-C to cancel)
Autodetected card type: sysmoISIM-SJA2

Generated card parameters :
 > Name     : Magic
 > SMSP     : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
 > ICCID    : 8988211910000000987
 > MCC/MNC  : 214/03
 > IMSI     : 214030123456789
 > Ki       : 00ffeeddccbbaa998877665544332211
 > OPC      : 8d772bbc604afa494ebc8ff6a71c14df
 > ACC      : None
 > ADM1(hex): 3131313131313131
 > OPMODE   : None
Programming ...
Warning: Programming of the ICCID is not implemented for this type of card.
Programming successful: Remove card from reader

I haven't found a way to read the Ki value using pySim-shell or pySim-read, so I used to verify the card content.

./ -a 11111111 -k

sysmoISIM-SJA2 parameterization tool
Copyright (c)2019 Sysmocom s.f.m.c. GmbH

Trying to find card with ATR: 3B 9F 96 80 1F 87 80 31 E0 73 FE 21 1B 67 4A 4C 75 30 34 05 4B A9
Initializing smartcard terminal...
 * Card not detected!
Trying to find card with ATR: 3B 9F 96 80 1F 87 80 31 E0 73 FE 21 1B 67 4A 4C 75 31 33 02 51 B2
Initializing smartcard terminal...
 * Card not detected!
Trying to find card with ATR: 3B 9F 96 80 1F 87 80 31 E0 73 FE 21 1B 67 4A 4C 52 75 31 04 51 D5
Initializing smartcard terminal...
 * Detected Card IMSI:  214030123456789
   USIM Application installed

 * Remaining attempts: 3
 * Authenticating...
 * Authentication successful
 * Remaining attempts: 3

Reading KI value...
 * Initalizing...
 * Reading...
 * Current KI setting:
   KI: ffeeddccbbaa998877665544332211ff


The value recognized by the network is indeed the key as read by

Both tools are used in their most recent version, retrieved last week.

Associated revisions

Revision 80901d6d (diff)
Added by laforge 4 days ago

commands: fix update_binary() with non-zero offset

In Icc240d5c8c04198640eb118565ea99f10ba27466 we introduced support for
writing files > 255 bytes by splitting the write into multiple chunks.

However, at the same time, that commit broke support for writing data at
non-zero offsets. Unfortunately, this is used extensively within
pySim-prog e.g. for writing K + OP/OPc data to sysmoISIM-SJA2 and sysmoUSIM-SJS1

This commit fixes the related problem.

Change-Id: Ie1aeaab29701946233ed73db3331039690d695da
Fixes: Icc240d5c8c04198640eb118565ea99f10ba27466
Closes: OS#5254

Revision 611dd783 (diff)
Added by laforge 3 days ago

commands: Fix read_binary() for non-zero offset

Similar to the fix in Ie1aeaab29701946233ed73db3331039690d695da
for update_binary(), read_binary() also contained a bug when treating
non-zero offsets.

Change-Id: Ic5c2f0ad1c1ec9c4e9c97e72895382f7b6fa9470
Related: OS#5254


#1 Updated by laforge 7 days ago

  • Priority changed from Normal to Urgent

#2 Updated by laforge 7 days ago

  • Assignee set to laforge

#3 Updated by laforge 4 days ago

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

I can reproduce the problem.

  • is correctly reading and writing K
  • is indeed dropping the first byte, shifting everything to the left by one byte, and not overwriting the last byte of K

In order to improve the situation, and to move away more from legacy tools and towards pySim-shell, I've now added more read/write capabilities of the SJA2 specific non-standard files to pySim-shell.

The actual bug seems to have been introduced by

commit 2e6dc03f345150353ecc796f18614c02256bd2df
Author: andrew-ma <>
Date:   Sat Jul 31 22:18:24 2021 -0700

    Allow update_binary function to write more than 255 bytes

    The T0 protocol (selected in transport/ does not support extended APDU, so 255 bytes is the maximum number of bytes that can be transmitted at a time.  We can divide large data into 255 byte chunks.  The read_binary function already has code to read more than 255 bytes, so we can just adapt it to the update_binary function.

    Change-Id: Icc240d5c8c04198640eb118565ea99f10ba27466

which changes the semantics of the update_binary() method when a non-zero offset is used.

#4 Updated by laforge 4 days ago

  • % Done changed from 20 to 80

#5 Updated by laforge 4 days ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)