Using simLab or simTrace with other readers?

[E3V3A]

Great Work! Nice to see that Osmocom simTrace SW has finally reached maturity.

However, I am always asking myself why we still use the (Osmocom) SIMtrace? AFAICT, SIMtrce simply provide a USB interface (like any other reader) but with the ISO 7816, T=0/1 options for the USART, and power. Everything else seem rather redundant, like JTAG and multiple serial ports etc.

The USART of the AT91SAM7S is capable of T=0. The documentation only mentions it in clock-master mode, like you would run it in a smart card reader to actively talk to a smart card. However, by using the USART input clock multiplexer, you can use an externally-generated CLK like the one from the SIM card socket of the phone.

Unfortunately, the Rx Timeout feature of the USART is not working in T=0 mode, so I had to re-implement Rx timeout (waiting time) handling by means of the TC (timer/counter) block 0. Due to technical limitations, we will wait up to one byte (12 etu) more than we should.

and from here or here:

Protocol type T The four least significant bits of any interface character TDi indicate a protocol type T, specifying rules to be used to process transmission protocols. When TDi is not transmitted, T=0 is used. T=0 is the asynchronous half duplex character transmission protocol. T=1 is the asynchronous half duplex block transmission protocol.

However, this should be also possible using a Raspberry Pi (or any other embedded Linux device) using its GPIO's and UART's possibly by also tuning the CPU frequency.

So what is the actual communication between the SIMtrace and simLab, needed?
I.e. What would it take to support, let's say an RPi?

[kamwar]

Thanks! SimLab is already supported on rpi with simplified installation process using dockers https://hub.docker.com/r/kamwar/rpi-simlab. I updated the wiki page with this info.

Communication between simLab and Simtrace is based on libusb-1.0.

I don't fully understand your question: 'Using simLab or simTrace with other readers?' SimLab already supports CCID readers but they cannot be used instead of simtrace HW.

[E3V3A]

@kamwar Yes, perhaps I was a bit confusing. What I am saying is, that SIMtrace is just a small piece of HW that intercepts the SIM data using the USART and convert the data into USB. Just to be converted again by the libusb in the host into the original SIM data.

IMO. The conversion into USB should not be necessary at all as the RPi can use it's UART ports for inputting the data directly without any USB involvement, thus eliminating most of the SIMtrace HW. With other words, you just need the SIM shim with a simple level shift circuit with a proper UART setting (or GPIO driver), on the RPi.

So if I have missed something very fundamental that would prevent this, please explain.

[bodziow]

Yes, the hardware can be composed in many various ways. Like you mentioned, it can be done without any USB involvment e.g. by making a small PCB board with two Smart Card/ISO 7816 interfaces (like that Maxim chip), Flex-PCB and SIM slots.Then, the communication with the host (like RPi) via UART or parallel interface. Most of the effort will be required on the Host/SW side, to prepare (or reuse) drivers to handle the communication with the extension board and to bind it togather with the simLAB tool (pyscard library).

We utilzed the simTrace board and USB interfaces as it was the quickest way to build our SIM tool :). It can be easily run on various OSes and extended by adding extra USB card readers. Anyway, I will discuss the matter with Kamil as it would be good to have the possibility to run the simLAB on different interfaces.

[E3V3A]

Hi @bodziow !

I was just having some discussions with the Osmocom guys about the current SIMtrace status. They didn't know about your project, so we are all wondering if your firmware is equal to that used in their FW repositories, or if you have added or modified it somehow since?

Also, please don't get me wrong. The development of the ST is a great piece of work and obviously very flexible by using USB, but for compact embedded devices, such as RPi's etc, all that HW is redundant and expensive. I figure a board with 2 SIM slots, a switch, an ESD chip and power driver, shouldn't cost more than 5-10 EUR in BOM.

Most of the effort will be required on the Host/SW side, to prepare (or reuse) drivers to handle the communication with the extension board and to bind it together with the simLAB tool (pyscard library).

Exactly. I already have some ideas how to recycle and write drivers for the RPi. If you are interested in collaborating, can you please send me an email? (You can find it on their list.)

[bodziow]

Hi @E3V3A,

The simlabTrace firmware is based on Tom Schouten's work (https://github.com/zwizwa/at91work/tree/apdu_phone), which in turn is strongly based on Harald's at91work http://git.gnumonks.org/ project (not on openpcd). We have refactored that source code (i.a. removed unneeded modules), separated reader and forwarder functionality and added some improvements and bugfixes. The most important work has been done on the Python (Host) side.

BR, Szymon

[kamwar]

Let's explain a bit difference between simLabTrace and simTrace firmware

Simtrace firmware is used for card sniffing in passive mode, without interfering communication between SIM and UE. It uses USB only for logging APDU data. Our basic approach when starting simLAB project was to allow MitM connection but it might be also used as a SIM card sniffer.

simLabTrace is APDU forwarder - it receives APDU data from UE, forward it to simLAB and send back the data from simLAB to UE. As Szymon already mentioned, we removed unused files and do basic refactor to split functionality between forwarder code and CCID reader. Most changes in the firmware code are for CCID reader but there are also several fixes and improvements for APDU forwarder.

Although original simTrace firmware should work in passive mode it turned out that sometimes the SIM inserted into the SIM slot is not recognized at all, e.g. simTrace doesn't allow to sniff card reader connection (CCID reader -> simTrace -> SIM in simTrace slot). I can't recall the exact solution for this problem but it was related with PTS procedure.

Major features of simLAB / simLabTrace are:

• Editing SIM files, even on the fly - that means also when UE is connected with SIM. It's really nice feature. I'm not aware that any other software allows it including commercial ones. You can go through SIM filesystem with commands like: cd, pwd, ls. I encourage you to check this editing feature even if you don't have simtrace HW.

• Modify exchanged APDU data (MitM)

• UICC sim card emulation - works quite stable. We tested it on several phones like Iphone5, Samsung Galaxy, NEXUS4, Xperia Z1/Z3.

• SIM router- routing attributes are based on file name or instruction. It's possible to combine even vendor SIMs (without knowledge of ADM codes). SAT is also supported e.g. only SAT commands are routed to the specific SIM

• SIM backup - with one command you might backup whole 3GPP SIM content and use it in emulated card.

• External communication for scripting with dbus and telnet

[E3V3A]

Awesome! @kamwar and @bodziow

Thank you so much for the excellent and precise answer! One last question though.

Does all the features you list above work right now?

I've just made some comments on the osmocom list pointing them your direction. Seeing as it is, that their project need some help in exactly those parts you mention above, I would really love to see you guys work together. Perhaps you can ask if you can push your changes into their repos? Who knows, perhaps they'd even send you a few new HW devices... (They were giving out several LTE nano-cell's last month.)

[kamwar]

All features should work, for sure it would be good to record a video with those features to show how they actually work. I will try to prepare it once I find some free time.

[GGegenhuber]

However, this should be also possible using a Raspberry Pi (or any other embedded Linux device) using its GPIO's and UART's possibly by also tuning the CPU frequency. I'm also trying to figure out whether this is possible.

Not sure if it's possible to run the raspberrys UART in synchronized (USART-)mode, to actually use an external CLK-source - this would be needed for sim card emulation, since the raspberry would need to act as a "slave".

Furthermore, the raspberry has SPI functionality, which might come in handy. However, we'd need SPI slave mode (again to synchronize the CLK for sim emulation) and the raspberry only supports SPI master mode.

The last resort might be to implement everything on a software "bit banging" level - however I've no idea if that would actually work and how stable and reliable it would be.

I already have some ideas how to recycle and write drivers for the RPi. If you are interested in collaborating, can you please send me an email? (You can find it on their list.)

I would love to hear some more specific details. Did you actually put any of your ideas into action?