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