MITM is useful to create a generic tool that is able to rewrite APDUs on-the-fly. Like a live apdu patcher.<br><br>A sniffer only *listens* the sim<->reader lines, without writing anything. It's "passive" in the sense that all it does is listening.<br>


<br>The timing is VERY important, a man in the middle will introduce latencies that can be *very* easily detected. It is essential that in a sniffer, all lines between the sim and the reader are directly, electrically connected, without any repeating hardware in the middle.<br>


<br>> the other thing is that all cards are not 3.3v some are 1.8<br>In ALL situations, Vcc shall just be forwarded from the reader to the card. You can use an ADC line and a voltage divider to measure this line. This is important since a cold reset can be executed by the reader, and that will interrupt Vcc.<br>


<br>And I see that the 3rd edition of ISO7816-3 now mandates that:<br>"No card shall be damaged when the interface device applies a class not supported by the card".<br><br>So the voltage is not important. My opinion is that in practice, all SIMs vendors, that will want their cards to work on the largest number of phones, will support all the 3 voltage classes (5,3.3,1.8V). If not, you cannot destroy a card by applying any of these 3 supply voltages.<br>


<br>Sebastien<br><br><div class="gmail_quote">On Mon, Nov 22, 2010 at 1:21 PM, Scott Weisman <span dir="ltr"><<a href="mailto:sweisman@pobox.com" target="_blank">sweisman@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


<div dir="ltr">Thanks Harald. Is there a doc somewhere to explain what that means? I'm confused, because to me "reader" and "sniffer" have sufficiently overlapping meanings. What does a SIM sniffer sniff?<br>



<br><div>What benefit is there to support a MITM use case?</div><div><br></div><font color="#888888"><div>Scott</div></font><div><div></div><div><div><br><div class="gmail_quote">On Mon, Nov 22, 2010 at 1:29 PM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Scott,<br>
<div><br>
On Mon, Nov 22, 2010 at 09:33:40AM +0200, Scott Weisman wrote:<br>
<br>
> I'm no expert on this (I think that's pretty obvious), but wouldn't it just<br>
> be easier to buy one of the supported Osmocom phones, which already has all<br>
> the hardware needed and a library of code, and make the code with that?<br>
<br>
</div>it will simply not work.  the phone only implements the READER side interface,<br>
but not the CARD site interface.<br>
<div><div></div><div><br>
--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>>           <a href="http://laforge.gnumonks.org/" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
                                                  (ETSI EN 300 175-7 Ch. A6)<br>
<br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br>