Min Xu <min...@min-info.net> wrote:
> I just recently made some changes to my 1.4 firmware to support
> Man-in-the-Middle modification of ATR because some device apparently
> changes the Vcc to 1.8v after reading the ATR that indicates the card
> supports Class C.
The very fact that you had to do this MITM modification indicates a
flaw in the design of SIMtrace. A *correct* SIMtrace hw design would
allow the phone to put out any of the 3 voltage classes (5V, 3V or
1.8V) in any order of the phone's choosing, be it spec-correct or
spec-violating, would pass *all* of them through to the SIM transparently,
and would reliably sniff the communication between the phone and the
SIM in all 3 classes, whichever ends up being chosen. My primary use
case for SIMtrace is debugging and troubleshooting phone-to-SIM
compatibility problems, i.e., answering questions like why does phone
model ABC reject SIM model XYZ, and the last thing we need is Heisenbug
behaviour where the addition of SIMtrace alters the environment in any
way.
I have a desire to design and build a new SIMtrace board with the
following architecture:
[ASCII art block diagram follows; email needs to be read in a fixed
width font for it to appear correctly.]
+-------------+ +-------+
| dual supply | | |
| xlat buffer +-------+ |
+-------------+ | |
| | |
| +---------------+ | |
| | OD driver for | | |
| | SIM I/O line +--+ |
| +---------------+ | MCU |
| | | | +---------+
| | | | | local |
| | | +--+ SIM I/F |=======\=+
| | | | | driver | S2 |
| | +-------+ +---------+ |
| | |
| | |
Phone ==+==+===============================================\=+== SIM socket
S1
The double horizontal line (made of ASCII '=' characters) in this block
diagram represents the SIM bus, made up of 5 wires: Vcc, CLK, RST, I/O
and Vpp. Yes, I know full well that Vpp has no actual use, but the
existing FPC cables do bring it from the phone to the board, and my
no-Heisenbugs approach is to connect it electrically to the SIM socket
when the 4 actually-used lines are connected through for trace mode,
as detailed below.
S1 and S2 are meant to be 5-pole, single-throw switches, or even
better, a single 5-pole, dual-throw switch combining S1 and S2. S1
and S2 must never be closed (conducting) at the same time, only one or
the other, although having both S1 and S2 open is a legitimate setting
for modes in which the SIM socket is unused. My ideal vision of the
switch component for S1/S2 would be something that functions just like
a relay; I figure that using an actual relay would probably be insane,
but I really want it to function like a relay, thus finding a suitable
electrical switch (less power-hungry than a relay) would require some
investigation.
The component identified as "dual supply xlat buffer" is envisioned as
Nexperia 74LVC4T3144, translating 3 signals unidirectionally from the
any-voltage SIM interface to the fixed-voltage MCU; the 3 signals it
will handle are CLK, RST and I/O. Notice that this path only allows
the I/O line to be sniffed and not driven.
The component identified as "OD driver for SIM I/O line" is envisioned
as Nexperia 74LVC1G07, or perhaps one half of a 74LVC2G07 if the other
half will be used as part of the "local SIM I/F driver" block.
The "local SIM I/F driver" block will consist of a local 3.0 V supply
to be fed to the SIM, a local LVC buffer for driving CLK and RST
(inputs from MCU, proper 3.0V outputs to the SIM), a pull-up resistor
to the local 3.0V supply on the I/O line, and the other half of
74LVC2G07 for driving this line in the proper OD manner. This local
I/O line will also be connected directly to an MCU input.
I envision this device as being able to operate in 4 possible modes:
Trace mode: S1 closed, S2 open. The local SIM I/F driver block is
electrically disconnected, the SIM is electrically connected to the
phone, transparent to all 3 voltage classes, and the firmware must
commit to NOT driving the OD buffer on the left side of the block
diagram. In this mode the presence of SIMtrace should be invisible
(no Heisenbug effect), and the firmware simply sniffs the output from
74LVC4T3144 translating buffer. The tracer will reliably sniff phone
to SIM communication with proper Vih and Vil thresholds no matter
which of the 3 classes is in use, and if we also connect phone VCC to
an ADC input, the trace log can capture the sequence of which voltages
the phone tried in which order.
Card emulation mode: both S1 and S2 open, on-board SIM socket unused.
The MCU will receive CLK, RST and I/O from the phone through the
74LVC4T3144 and talk back to the phone on the I/O line through the OD
buffer. This mode will once again work correctly no matter which
voltage class is chosen by the phone.
Card reader mode: S1 open, S2 closed. In this mode the SIM will always
be operated in class B, never A or C - but because it is now a private
interface between our MCU and the SIM, not involving the phone, I find
this B-only restriction perfectly acceptable. With S1 open, the phone
is disconnected and out of the picture.
MITM mode: S1 open, S2 closed, and the board functions electrically
just like in the card reader mode. But it is really the card reader
mode and the card emulation mode combined, operating simultaneously:
one USART will talk to the phone, the other will talk to the SIM. The
phone can once again apply any of the 3 voltage classes, SIMtrace will
receive from the phone and talk back to the phone through the same
path as in the card emulation mode above, and at the same time the
other USART will talk to the SIM. The physical SIM will operate in
class B no matter which voltage class is used on the phone to MITM
interface.
Now for the big gotcha: although I got the idea outlined above, I
don't know when I will get around to turning it into reality as in
finding specific parts, capturing schematics and spinning out a PCB.
The reason is prioritization: I only got one of me, and right now my
desire to build FC Venus board is a higher priority than this improved
SIMtrace idea. Therefore, if anyone would like to beat me to it,
please go ahead! I have spelled out my idea in some detail above so
people can know what I have in mind, and if someone else feels like
taking my block diagram design and turning it into reality, go for it!
M~
