Hi all!
Kevin has done a wonderful job of creating a tool for collaborative collection of TERMINAL PROFILE data of mobile phones. See: https://geekblog.kevredon.org/?p=592 https://terminal-profile.osmocom.org/
I'm looking forward to see contributions by all SIMtrace owners. After all, you no longer need to be a programmer to contribute now. All you need is a SIMtrace and a couple of phones, which is probably true for most people on this list.
Regards, Harald
Hey Harald,
nice project ;) thumbs up for Kevin too of course.
Having that, I wanted to ask, do you see a possibility of kind-of man-in-the-middle with Simtrace?
As it would be nice to test these various scenarios on different phones we'd need to inject these commands into the communication between the phone and the sim. Honestly, I'm not quite sure how this is (not) going to be working according to the standard and if sneaking in a command wouldn't break the communication.
Maybe it's a better idea to get all the files from the sim (the ones readable with PIN should be enough, like IMSI and the ones in TS 11.11), start-up kind of a simulator of the sim filesystem and only let the RUN GSM ALGO APDU to go through to the SIM and handle the rest by the simulator. Using something like that, it sounds easier to inject some Proactive Commands and similar.
I'd like to know your opinion, as I'm not so deeply familiar with the low-level stuff (ISO-7816).
Thanks! Cheers, Lukas
On Mon, May 21, 2012 at 6:42 PM, Harald Welte laforge@gnumonks.org wrote:
Hi all!
Kevin has done a wonderful job of creating a tool for collaborative collection of TERMINAL PROFILE data of mobile phones. See: https://geekblog.kevredon.org/?p=592 https://terminal-profile.osmocom.org/
I'm looking forward to see contributions by all SIMtrace owners. After all, you no longer need to be a programmer to contribute now. All you need is a SIMtrace and a couple of phones, which is probably true for most people on this list.
Regards, Harald --
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Mon, May 21, 2012 at 06:53:41PM +0200, Lukas Kuzmiak wrote:
Having that, I wanted to ask, do you see a possibility of kind-of man-in-the-middle with Simtrace?
yes, the hardware was specifically designed the way to support it.
The main issue is that the respective software (mostly SIMtrace firmware) hasn't been written yet. It's a couple of days work, but I myself honestly don't think I'll find much time for it, given the variety of other projecets like the COS for the CC32RS512, OsmoSDR, sysmoBTS and many others.
Honestly, I'm not quite sure how this is (not) going to be working according to the standard and if sneaking in a command wouldn't break the communication.
Maybe it's a better idea to get all the files from the sim (the ones readable with PIN should be enough, like IMSI and the ones in TS 11.11), start-up kind of a simulator of the sim filesystem and only let the RUN GSM ALGO APDU to go through to the SIM and handle the rest by the simulator. Using something like that, it sounds easier to inject some Proactive Commands and similar.
both approaches are definitely doable. The second one would probably be easier, as you could reuse e.g. the softsim of Kevin/Nico and simply run the SIMtrace hardware in "ISO7816 slave" mode. Only once you get a RUN GSM ALGORITHM, you pass that throguh to the card.
USB-wise, I would suggest to make the SIM-facing side visible as USB CCID card reader (using libccid / pcsc-lite). The phone-facing side would be a custom protocol that could be encapsulated in CCID PC_to_RDR_Escape and RDR_to_PC_Escape messages of CCID.
In the ideal world we would have a multi-function USB device exporting separat interfaces for this, but the sam7s only supports 4 USB endpoints and thus we have to somehow tunnel the "card simulation" part through those Escape commands of the CCID profile.
Regards, Harald
Harald Welte wrote:
In the ideal world we would have a multi-function USB device exporting separat interfaces for this, but the sam7s only supports 4 USB endpoints and thus we have to somehow tunnel the "card simulation" part through those Escape commands of the CCID profile.
It's also possible to use vendor-specific control transfers independently of the interface.
//Peter
Hi Peter,
On Mon, May 21, 2012 at 08:16:08PM +0200, Peter Stuge wrote:
Harald Welte wrote:
In the ideal world we would have a multi-function USB device exporting separat interfaces for this, but the sam7s only supports 4 USB endpoints and thus we have to somehow tunnel the "card simulation" part through those Escape commands of the CCID profile.
It's also possible to use vendor-specific control transfers independently of the interface.
yes, but I think the size of the endpoint and the overall nature of control transfers might not be the best solution, in terms of transfer speed.
-
Harald Welte -
Lukas Kuzmiak -
Peter Stuge