Hi all,
I'm thinking of starting a project that would allow us to * perform SIM and USIM card pre-personalization * read/dump and explore [U]SIM contents interactively * perform SIM card simulation
The idea is to start with some generic data structure that can represent the filesystem tree (DFs, EFs) and their "external" properties, i.e. file type, size, permissions, FID, SFID, etc.
This data structure could also have the actual file content associated with each EF.
The second step would be some code that can take that data structure and program a freely-programmable card (like sysmoSIM-GR1) and create the files according to that structure.
Another module would implement card-simulation (via BT SAP, SIMtrace or virtual PC/SC card). After all, only a few instructions have to be imilpemented if the filesystem and its content is already in a generic data structure that the program can access..
Next step would be to associate parser and generator routines for the content of each individual file as it is specified in TS 11.11.
After that has been done, we could think of representing the FS tree and the parsed contents of each file in some kind of graphical / user friendly representation. The idea here is that the UI code would be generic and not know any of the actual ecnoding/decoding of the EF content.
The biggest question is what language to use for this. Some kind of object orientation might very well resemble the idea of a 'file object' in a tree, with many different file types, each having it's own parser/encoder.
On the other hand, Erlang's bit field syntax would probably come very handy in terms of encoding/decoding the various EF content. However, at least once we start to want some kidn of UI, Erlan really sucsk. Also, almost nobody here reads/writes Erlang [yet?].
Writing all this in C seems like a bit much of an effort, probably even more so on the UI side. However, we already have quite a bit of C code for parsing/generating things like LAI, etc. which are stored like 04.08 inside the sim card files.
Python might be a good idea in terms of tons of available libraries/modules, object orientation and good UI bindings. The biggest problem here is that my python skills are really limited so far, so my productivity might not be as high as I expect.
The individual components could even be written in different languages, but then we would have to have some common format for exchanging data back and forth - which might not be worth it, given the small scope of the project.
any ideas / comments / feedback?
Well,
If you know Erlang, C and C++, python you will learn Python fast! And the advantage is that Python has some projects in which they can be leveraged, for example:
http://pyscard.sourceforge.net/ http://michau.benoit.free.fr/codes/smartcard/card/
Recalling also that wrappers between Python and Erlang or C are relatively simple...
[]s
./alberto -fabiano -vvv
On Sat, Nov 26, 2011 at 16:12, Harald Welte laforge@gnumonks.org wrote:
Hi all,
I'm thinking of starting a project that would allow us to
- perform SIM and USIM card pre-personalization
 - read/dump and explore [U]SIM contents interactively
 - perform SIM card simulation
 The idea is to start with some generic data structure that can represent the filesystem tree (DFs, EFs) and their "external" properties, i.e. file type, size, permissions, FID, SFID, etc.
This data structure could also have the actual file content associated with each EF.
The second step would be some code that can take that data structure and program a freely-programmable card (like sysmoSIM-GR1) and create the files according to that structure.
Another module would implement card-simulation (via BT SAP, SIMtrace or virtual PC/SC card). After all, only a few instructions have to be imilpemented if the filesystem and its content is already in a generic data structure that the program can access..
Next step would be to associate parser and generator routines for the content of each individual file as it is specified in TS 11.11.
After that has been done, we could think of representing the FS tree and the parsed contents of each file in some kind of graphical / user friendly representation. The idea here is that the UI code would be generic and not know any of the actual ecnoding/decoding of the EF content.
The biggest question is what language to use for this. Some kind of object orientation might very well resemble the idea of a 'file object' in a tree, with many different file types, each having it's own parser/encoder.
On the other hand, Erlang's bit field syntax would probably come very handy in terms of encoding/decoding the various EF content. However, at least once we start to want some kidn of UI, Erlan really sucsk. Also, almost nobody here reads/writes Erlang [yet?].
Writing all this in C seems like a bit much of an effort, probably even more so on the UI side. However, we already have quite a bit of C code for parsing/generating things like LAI, etc. which are stored like 04.08 inside the sim card files.
Python might be a good idea in terms of tons of available libraries/modules, object orientation and good UI bindings. The biggest problem here is that my python skills are really limited so far, so my productivity might not be as high as I expect.
The individual components could even be written in different languages, but then we would have to have some common format for exchanging data back and forth - which might not be worth it, given the small scope of the project.
any ideas / comments / feedback?
--
- Harald Welte laforge@gnumonks.org
 ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 11/26/2011 07:12 PM, Harald Welte wrote:
Hi all,
I'm thinking of starting a project that would allow us to
- perform SIM and USIM card pre-personalization
 - read/dump and explore [U]SIM contents interactively
 
Hi,
the GUI part is missing but are you aware of https://github.com/znuh/simdump?
holger
On Sat, Nov 26, 2011 at 09:14:15PM +0100, Holger Hans Peter Freyther wrote:
On 11/26/2011 07:12 PM, Harald Welte wrote:
Hi all,
I'm thinking of starting a project that would allow us to
- perform SIM and USIM card pre-personalization
 - read/dump and explore [U]SIM contents interactively
 Hi,
the GUI part is missing but are you aware of https://github.com/znuh/simdump?
ah, yes, thanks for the reminder. After quickly reading through it, ther is _some_ overlap, though really only some.
I've meanwhile wasted some time I don't have with prototyping some of the data structures and concepts in good old C. It's far from being complete, but I've attached it for your reference.
Hi all,
I already made some SIM tools, which I call softSIM. It can already dump all the data (files) from the SIM (into an XML), sometimes even parse it, and this dump can be used to simulated a SIM (using BT SAP). More details are available in the wiki article. http://bb.osmocom.org/trac/wiki/softSIM
It only handles SIM (I had no need to play with USIM), and is in ruby (not the best language if we want to use it in SIMtrace), but it works great and it can be used as inspiration for re-implementation. Writing a writer or UI based on this code would not take me long, if the existing tools are accepted as base.
I'm quite interested in write a reader/writer/simulator in C, but I have not that much time (I use it for SIMtrace at the moment). But I'm happy to help, or do it later on.
kevin
Excerpts from Harald Welte's message of Sat Nov 26 19:12:45 +0100 2011:
Hi all,
I'm thinking of starting a project that would allow us to
- perform SIM and USIM card pre-personalization
 - read/dump and explore [U]SIM contents interactively
 - perform SIM card simulation
 any ideas / comments / feedback?
Hi Harald,
I'm thinking of starting a project that would allow us to
- perform SIM and USIM card pre-personalization
 - read/dump and explore [U]SIM contents interactively
 - perform SIM card simulation
 The idea is to start with some generic data structure that can represent the filesystem tree (DFs, EFs) and their "external" properties, i.e. file type, size, permissions, FID, SFID, etc.
This data structure could also have the actual file content associated with each EF.
you might wanna have a look at oFono source code. At least for reading EF and parsing them we have extensive support. Check src/simutil.[ch] and src/simfs.[ch].
Same if you care about the SIM Toolkit support. It has support for parsing the majority of data structures you find there.
Regards
Marcel
Hi Marcel,
good to hear from you !
On Mon, Nov 28, 2011 at 06:00:34PM +0100, Marcel Holtmann wrote:
This data structure could also have the actual file content associated with each EF.
you might wanna have a look at oFono source code. At least for reading EF and parsing them we have extensive support. Check src/simutil.[ch] and src/simfs.[ch].
I will check, thanks for the hint. However, I believe you are mostly dealing with DFtelecom, i.e. things like SMS, contact data, etc. - not so much with issues like preferred operator list, Kc, TMSI, SIM service table, etc.
But I will RTFS first, before making any more assumptions...
Regards, Harald
Hi Harald,
This data structure could also have the actual file content associated with each EF.
you might wanna have a look at oFono source code. At least for reading EF and parsing them we have extensive support. Check src/simutil.[ch] and src/simfs.[ch].
I will check, thanks for the hint. However, I believe you are mostly dealing with DFtelecom, i.e. things like SMS, contact data, etc. - not so much with issues like preferred operator list, Kc, TMSI, SIM service table, etc.
actually we doing native EF handling as well. The whole directory structure and all fancy difference between 2G and 3G SIM cards. oFono does way more than any other open source telephony stack I have ever seen. And we do get these things right, I might add :)
But I will RTFS first, before making any more assumptions...
Just have a look. You might be able to re-use some parts since the whole code is actually in C. Or at least get you started somehow. Depending on what your goal is this code might be useful or not. It is somewhat tight to our way of handling modems.
Regards
Marcel