ml(a)mail.tsaitgaist.info wrote: Cool! I'd use a more modern chip that is simpler to work with; something like NXP LPC1343 Cortex-M3 with USB or TI Stellaris LM36432 with 10/100 Ethernet. They're both single supply 3.3V chips. The NXP only needs five-size passive support components. I get nonsense messages visiting that page. :\ "needs input" something or other. Maybe you can attach them to the wiki? Christian Vogel wrote: There might be an internal voltage regulator also for this chip, but I would really go with cm3 for a new design. //Peter

Hi! On Mon, Nov 22, 2010 at 01:39:07AM +0100, ml(a)mail.tsaitgaist.info wrote: No, we don't want this. Real phones do things like CLOCKSTOP and we might not want to stop our actual SIM card during that time. The AT91SAM7 can provide the clock on the SCLK0/SCLK1 pin of the USART, there is no need for any external circuitry. simply send a configuration message via USB from the simtrace program. btw: please don't quote the full message at the bottom of your mail, thanks! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

you have to take in consideration the "retransmission" also. the other thiing is that all cards are not 3.3v some are 1.8. that could be read in ATR. so if you want it to be compatible with any phone, you need on one side to give an ATR to the phone that tells it it could work with 3.3v and be able to read the actual sim with 1.8v... I've already done that kind of device a while ago with a FT2232 and scenix microcontroller. (http://88.191.12.21/fakesim.jpg) and I can mim, sniff, read... So i'm familiar with it. -- k2

Harald Welte wrote: After seeing the schematic I tend to agree. I think every sync serial peripheral that I've seen can operate in slave mode like that, and I agree that it's important. I disagree that significant effort would be required. It should be straightforward to use another controller, but since the schematic wouldn't really be much simpler there may not be much point to it. But one thing that I think matters is that it's very easy and cheap to get hold of a really simple (e.g.) LPC1343 development board in neat size that people could use instead of having to build their own hardware. I think that wall clock time would be about same for porting the software and producing a board. ml(a)mail.tsaitgaist.info wrote: Hopefully someone will fix that. Thanks for uploading it! Since the crystal is around 18 MHz this might even work OK as a single layer board, maybe with a solid ground plane on the back for the ambitious. It would be really nice to not have to deal with switches, and just let the host software tell the hardware which mode to use. A USB device control request could do the trick easily. //Peter

Hi Scott, On Mon, Nov 22, 2010 at 09:33:40AM +0200, Scott Weisman wrote: it will simply not work. the phone only implements the READER side interface, but not the CARD site interface. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

MITM is useful to create a generic tool that is able to rewrite APDUs on-the-fly. Like a live apdu patcher. A sniffer only *listens* the sim<->reader lines, without writing anything. It's "passive" in the sense that all it does is listening. 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. 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. And I see that the 3rd edition of ISO7816-3 now mandates that: "No card shall be damaged when the interface device applies a class not supported by the card". 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. Sebastien On Mon, Nov 22, 2010 at 1:21 PM, Scott Weisman &lt;sweisman(a)pobox.com&gt; wrote:

thanls for your comments, and i'm happy to see we agree. regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort. i think we don't need to worry about 5V anymore. Last time I've seen a 5V simcard is 10 years ago. Also, AFAIR those baseband processors that i've seen all are <= 3.3v, even for things as ancient as the calypso. -- Sent from a mobile device, excuse my short response

Also, we could add a SC reader mode, using the CCID USB profile. I linked the SC output to serial port 1 (to be able to control in and output separately) I added NPN transistors to be able to block I/O (for MitM) or completely separate the output from the input (for emulation,reader) To be able to choose between 1.8v (class c) or 3.3v (class b), there is a manual switch. The other solution would be to use logic level shifter. here the drawing : https://gsm.tsaitgaist.info/SIMtrac/v0.3/SIMtrac.ps kevin

I continued the hardware design I added : - a switch, to choose between SIMtrace and normal SC reader. the USB CCID profile could be loaded during boot. VCC can be supplied to power the SC. - switches for the SC presence, included in the sockets - LEDs to show the current mode (green=reader,yellow=emulator,blue=sniffer,red=MitM) - transistor array to control the LEDs, SC connections, and I/O line - line names - .... as I'm not an electrician, could someone check if this could work, resistors/capacitors are missing, .... here the schema : https://gsm.tsaitgaist.info/SIMtrac/v0.4/SIMtrac.ps Kevin On 24.11.2010 09:17, ml(a)mail.tsaitgaist.info wrote:

Hi Peter, On Mon, Nov 22, 2010 at 03:49:09AM +0100, Peter Stuge wrote: Are you sure? Please note that the variant of ISO7816-3 that we primarily want is T=0 in asynchronous mode. Here we actually have I/O asynchronous to the clock (i.e. the clock is not a bit clock), but still want to derive the baud rate off an external clock (with programmable, non-power-of-two divider) Even for the SAM7 what we are doing is not documented, they only describe the T=0 USART mode with internal / master clock in their data sheet. The SAM7 USART is not used in synchronous mode. I'm not saying no other chip can do it, but I find it a very uncommon feature, as there is no regular commercial application to it. You either want a synchronous USART _or_ you want to operate in T=0 / T=1, but in the latter case: why would you ever do something else than implement an actual card reader? ;) You will need to write drivers for the USB device controller (preferrably compatible to what simtrace currently understands, you will need to properly drive the USART, you will need a timer/counter block for waiting time detection and combine all that with the end-of-apdu-detection, nRST logic, PPS, etc. I would be surprised if you need less than two full days for development and debugging all of this. But for what? To what advantage? Even if the schematic lacks 3 or 4 components and is 10 EUR cheaper... who would want to invest that much time in something that is merely a tool that will never be produced in large quantities? Furthermore, a LPC1343 has only one UART, removing the man-in-the-middle option... and even card simulation will be difficult, as the UART has no T=0 mode and thus cannot generate the T=0 specific tri-stating of a single shared Rx/Tx line, and will not do the NACK that will pull the I/O line low during one of the two stop bits. I also agree. People will be either part of two groups: 1) people able to build their own hardware. They can use the SAM7-P64 or SAM7-H64 boards from Olimex (or similar boards) + the RebelSIM Scanner as mechanical adapter 2) people who are not able or interested in building stuff but who prefer to buy a product and simply use it. I don't think there is much room left for people actually building more than '1', i.e. producing the PCB, soldering it, etc. My approach is thus different: I'm discussing whether bitmanufaktur.de wants to include such a product into their (temporarily offline) webshop that also sells the openPCD, openPICC and openBeacon hardware. It looks good, but is likely to happen deep into Q1/2011, as far as I can tell (mostly due to constraints with their overloaded manufacturer). Regards, Harald -- - Harald Welte &lt;laforge(a)gnumonks.org&gt; http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)