On 10/09/12 22:33, Harald Welte wrote:

Hi!

I've been hacking away a bit on a new library 'libosmosim' whihc is scheduled to become part of libosmocore. In fact, as the automake integration has been cleaned up, I'll probably merge it master any day now.

The idea of this library is to

• understand the EF/DF hierarchy if GSM SIM, ETSI UICC and 3GPP USIM
• provide encoding and decoding routines for at least the most important EFs
• decode the binary data into a generic data structure which can be used by some form of a GUI application
• be able to re-encode from the generic parsed structure into the binary form, possibly after modification from the UI
• be able to transact APDUs via T0 and T1 on PC/SC and other reader interfaces, e.g. the OsmocomBB SIM interface

So the primary purpose of this is to be able to have a tool for meaningful (human-readable/writable) modification of all files on a programmable SIM card, such as the sysmoSIM-GR1 (and other cards where you have the ADM PIN that gives you write permission).

Other useful purposes on the horizon of the library could be:

• implementation of a generic SIM/UICC/USIM simulator based on user-created input, or based on 'ripped' SIM cards (well, you have to provide the key in some way).

The current status is still quite experimental, but you can already see the major parts:

• mapping of APDU and TPDU (only T=0 so far) on to 'struct msgb

struct osim_file_ops encode and decode callbacks for a given file

struct osim_file_desc node in the hierarchical description of filesystem tree

struct osim_decoded_data the runtime representation of a decoded file:

struct osim_decoded_element one decoded element in a decoded file

struct osim_card_sw status + bitmask + human readable description

struct osim_card_profile full description profile of card, including filesystem hierarchy, status words and card-specific commands

struc osim_reader_hdl represents a card reader (currently a slot in a reader, not sure really how to represent multi-slot readers like sim-banks yet). primarily consist of osim_reader_ops

struc osim_card_hdl representing a card inside a reader

struc osim_chan_hdl currently just a dummy. intended for logical channel support

most of the existing code is in src/sim/*.c, while some not-yet-cleaned-up example code is in utils/osmo-sim-test.c. There are gaps everywhere all over the place, and I think it will take quite some time to fill those gaps.

Hi,

In which branch can one find this code? Or maybe you have a separate tree somewhere? I couldn't find anything in simtrace git repo nor in openbsc one.

Chris

Current roadmap:

• properly integrate all parts, so with a single call you can read in the tree of all EFs of a card into their in-memory representation

• verify that the APIs for encoding/decoding functions work the way they are before writing 'all' the EF decode/encode routines

• add more decoded element types, such as location area codes and the like

So if you survived this mail until this point, I think you are a prime candidate for contributing some code. Let me know if you're interested in helping out.

Regards, Harald

On 10/09/12 22:33, Harald Welte wrote:

Hi!

Hi,

I've just build libosmocore and ran osmo-sim-test, but it crashes. There's a function signature mismatch between osim_reader_ops.reader_open() and pcsc_reader_open(), the later requires an extra parameter "void *ctx".

Chris

I've been hacking away a bit on a new library 'libosmosim' whihc is scheduled to become part of libosmocore. In fact, as the automake integration has been cleaned up, I'll probably merge it master any day now.

The idea of this library is to

• understand the EF/DF hierarchy if GSM SIM, ETSI UICC and 3GPP USIM
• provide encoding and decoding routines for at least the most important EFs
• decode the binary data into a generic data structure which can be used by some form of a GUI application
• be able to re-encode from the generic parsed structure into the binary form, possibly after modification from the UI
• be able to transact APDUs via T0 and T1 on PC/SC and other reader interfaces, e.g. the OsmocomBB SIM interface

So the primary purpose of this is to be able to have a tool for meaningful (human-readable/writable) modification of all files on a programmable SIM card, such as the sysmoSIM-GR1 (and other cards where you have the ADM PIN that gives you write permission).

Other useful purposes on the horizon of the library could be:

• implementation of a generic SIM/UICC/USIM simulator based on user-created input, or based on 'ripped' SIM cards (well, you have to provide the key in some way).

The current status is still quite experimental, but you can already see the major parts:

• mapping of APDU and TPDU (only T=0 so far) on to 'struct msgb

struct osim_file_ops encode and decode callbacks for a given file

struct osim_file_desc node in the hierarchical description of filesystem tree

struct osim_decoded_data the runtime representation of a decoded file:

struct osim_decoded_element one decoded element in a decoded file

struct osim_card_sw status + bitmask + human readable description

struct osim_card_profile full description profile of card, including filesystem hierarchy, status words and card-specific commands

struc osim_reader_hdl represents a card reader (currently a slot in a reader, not sure really how to represent multi-slot readers like sim-banks yet). primarily consist of osim_reader_ops

struc osim_card_hdl representing a card inside a reader

struc osim_chan_hdl currently just a dummy. intended for logical channel support

most of the existing code is in src/sim/*.c, while some not-yet-cleaned-up example code is in utils/osmo-sim-test.c. There are gaps everywhere all over the place, and I think it will take quite some time to fill those gaps.

Current roadmap:

• properly integrate all parts, so with a single call you can read in the tree of all EFs of a card into their in-memory representation

• verify that the APIs for encoding/decoding functions work the way they are before writing 'all' the EF decode/encode routines

• add more decoded element types, such as location area codes and the like

So if you survived this mail until this point, I think you are a prime candidate for contributing some code. Let me know if you're interested in helping out.

Regards, Harald