This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Christian Gagneraud chris at techworks.ieOn 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 > -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/