1. Rebel Simcard Scanner
    1. Hardware architecture
    2. Pinout
    3. Mode of operation
      1. Original UART use
      2. Modified bit-banging use

Rebel Simcard Scanner

The Rebel Simcard folks are selling a relatively inexpensive device for generating SIM card traces as Simcard Scanner.

photograph of full RebelSIM scanner kit

You can find the full kit for less than USD 25 at the  Rebelsimcard shop ( mirror).

Hardware architecture

The Scanner has one small plug-in SIM sized slot and one full-size (ISO 7816-1) slot for your actual simcard.

It also has a small socket for a FPC cable that goes to a small PCB in the size of a plug-in sim.

You put the FPC-attached PCB into your phone (instead of the SIM card) and put the actual SIM inside the Scanner.

Furthermore, you connect it via the USB-B connector to your PC.

The I/O line of the SIM card is wired to the RxD pin (5) of the FT232RL on the Scanner. Unfortunately, the CLK line is not connected, and neither can the device serve as a proxy between SIM and phone.

Pinout

It's possible to use it as smart card physical interface for SIMtrace.

Here the pinout :

Smart Card CON1 CON2 CON3 CON17 USB3
C1-VCC 1 3 1 8 8
C2-RST 2 5 6
C3-CLK 3 7 4
C5-GND 6 4 5 4,9,11,13,15 7
C6-VPP 5
C7-I/O 4 8 6 2 3

pinout of the RebelSIM scanner

Mode of operation

Original UART use

The original RebelSIM users simply use the FT232RL in UART mode and set the baud rate to match that of the actual SIM card reader. Since the baudrate is negotiated in the PPS after ATR, and it depends on the frequency of the CLK signal generated by the reader.

This means you effectively have to use an oscilloscope to measure the bit length (etu) and calculate a matching baud rate which you can then program the FT232R to use.

Modified bit-banging use

By using the FT232 asynchronous bit-banging mode, it is possible to obtain samples of the I/O line, decoding the actual T=0 (or with some SIM cards + phones T=1) protocol.

The unresolved problem with this is that the sample clock of the FT232R seems very unstable. This results in a lot of jitter in the sample stream. Furthermore it is suspected that USB may cause buffer overruns and leads to lost samples.

Harald has been doing a lot of experimentation with this, and unfortunately abandonded the project for now.

Attachments