From laforge at gnumonks.org Thu Jul 7 07:26:28 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 7 Jul 2011 09:26:28 +0200 Subject: SIMtrace production has started Message-ID: <20110707072628.GF27122@prithivi.gnumonks.org> Hi all, JFYI: The SIMtrace v1.0p bulk production has started. It will take about two weeks for the PCBs to be produced, after that we will do SMT. We expect to get the fully assembled boards by July 27th, which gives us some time for testing + programming before the Camp. We expect the boards to be available at the 27C3, and after that from the sysmocom webshop. Meanwhile, I have discovered that Atmels at91lib includes code for a USB CCID implementation. So we could provide something like a multi-configuration device, that has a default configuration for the sniffer, and a different configuration to behave like a regular CCID smart card reader. I'm not certain when I will get around doing that, but it definitely seems like an interesting option. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ahelblin at cs.uml.edu Fri Jul 8 15:46:56 2011 From: ahelblin at cs.uml.edu (Adam Helbling) Date: Fri, 8 Jul 2011 11:46:56 -0400 Subject: SIMtrace production has started In-Reply-To: <20110707072628.GF27122@prithivi.gnumonks.org> References: <20110707072628.GF27122@prithivi.gnumonks.org> Message-ID: Herald, This is great news. I have been following the list (both osmocombb and the newer SIMtrace one) for sometime. I am looking forward to the SIMtrace boards. I have a friend who is attending the 27C3 and I will be asking him to pick me up a few. Do you have any estimate on pricing at this time? Cheers and nice work! -Adam H. On Thu, Jul 7, 2011 at 3:26 AM, Harald Welte wrote: > Hi all, > > JFYI: The SIMtrace v1.0p bulk production has started. It will take > about two weeks for the PCBs to be produced, after that we will do SMT. > We expect to get the fully assembled boards by July 27th, which gives us > some time for testing + programming before the Camp. > > We expect the boards to be available at the 27C3, and after that from > the sysmocom webshop. > > Meanwhile, I have discovered that Atmels at91lib includes code for a USB > CCID implementation. So we could provide something like a > multi-configuration device, that has a default configuration for the > sniffer, and a different configuration to behave like a regular CCID > smart card reader. I'm not certain when I will get around doing that, > but it definitely seems like an interesting option. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk.kirsten at uni-konstanz.de Thu Jul 14 13:37:47 2011 From: dirk.kirsten at uni-konstanz.de (Dirk Kirsten) Date: Thu, 14 Jul 2011 15:37:47 +0200 Subject: Active Manipulation SIM-ME Message-ID: Hello, We would like to do some active manipulation between our ME and the SIM card. As I understood correctly, the hardware SIMtrace project is just about passive monitoring the traffic in between, am I right? So this seems to be inappropriate for our aims. So we thought about a solution more like the RebelSIM card, which is documented as well in the osmocomBB wiki. Unfortunately, the information given there are also very vague. So maybe it is just outdated: Does anybody worked with the RebelSIM card in a way that they try to manipulate the responses from the SIM (or do something else, except from unlocking their phone)? Is it possible to flash it via SIM card interface?! What we actually want to do is to replace same values, e.g. we want to provide another Kc than the SIM card in fact has (this is solely a research project). So maybe there is some other way to do is, except the approach based on RebelSIM? If so I would be grateful for your valuable feedback. Cheers, Dirk From 246tnt at gmail.com Thu Jul 14 14:08:57 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 14 Jul 2011 16:08:57 +0200 Subject: Active Manipulation SIM-ME In-Reply-To: References: Message-ID: > We would like to do some active manipulation between our ME and the SIM > card. As I understood correctly, the hardware SIMtrace project is just about > passive monitoring the traffic in between, am I right? So this seems to be > inappropriate for our aims. No, the HW can do man-in-the-middle. Cheers, Sylvain From dirk.kirsten at uni-konstanz.de Thu Jul 14 14:26:34 2011 From: dirk.kirsten at uni-konstanz.de (Dirk Kirsten) Date: Thu, 14 Jul 2011 16:26:34 +0200 Subject: Active Manipulation SIM-ME In-Reply-To: References:

Message-ID: Thats great news! So (I guess that ones for Harald Welte) when will the HW be publicly available? You wrote in your last mail to this list on 27C3 - Am I just missing something or wasn't this last December? Did you mean instead 28C3? But this is in December, which is still quite some time... So is there maybe a possibility to get the HW earlier, especially if you already get them in the next week(s)? Cheers, Dirk On Thu, 14 Jul 2011 16:08:57 +0200, Sylvain Munaut <246tnt at gmail.com> wrote: >> We would like to do some active manipulation between our ME and the SIM >> card. As I understood correctly, the hardware SIMtrace project is just >> about >> passive monitoring the traffic in between, am I right? So this seems to >> be >> inappropriate for our aims. > > No, the HW can do man-in-the-middle. > > Cheers, > > Sylvain From 246tnt at gmail.com Thu Jul 14 14:27:37 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 14 Jul 2011 16:27:37 +0200 Subject: Active Manipulation SIM-ME In-Reply-To: References:

Message-ID: Hi, > So (I guess that ones for Harald Welte) when will the HW be publicly > available? You wrote in your last mail to this list on 27C3 - Am I just > missing something or wasn't this last December? Did you mean instead 28C3? He meant CCC camp which is mid-August. Cheers, Sylvain From ahelblin at cs.uml.edu Thu Jul 14 18:07:09 2011 From: ahelblin at cs.uml.edu (Adam Helbling) Date: Thu, 14 Jul 2011 14:07:09 -0400 Subject: Active Manipulation SIM-ME In-Reply-To: References:

Message-ID: Yeah that was how I read it also. While he said 27C3, based on the rest of his email I made the assumption he meant the CCC as well. A friend of mine will be attending, and I'm hoping they are available at the even as well. The MITM should be fairly easy with the hardware solution based on what I've seen go through this list as of late. Cheers! On Thu, Jul 14, 2011 at 10:27 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > So (I guess that ones for Harald Welte) when will the HW be publicly > > available? You wrote in your last mail to this list on 27C3 - Am I just > > missing something or wasn't this last December? Did you mean instead > 28C3? > > He meant CCC camp which is mid-August. > > Cheers, > > Sylvain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jul 14 19:14:16 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 14 Jul 2011 21:14:16 +0200 Subject: Active Manipulation SIM-ME In-Reply-To: References:

Message-ID: <20110714191416.GX25905@prithivi.gnumonks.org> Hi Dirk and others, yes, the hardware is capable of full MITM. We haven't yet written the software (both firmware and host software) for it, but we are confident that it will work. The 100 unit hardware manufacturing is scheduled for mid next week, which should give us ample time for testing, flashing and possibly debugging any issues that may arise during that production run before the camp. And yes, I was referring to the camp as availability time. The price is not fixed yet, but I would expect somewhere in the order of 75 EUR, including a set of four SIM card adapters. This may seem a lot given the BOM cost, but it's actually "just" the production cost plus the hardware cost we had for doing the two prototype runs, plus some amount that we need as a safeguard for dealing with warranty related issues (mandatory legal warranty for products is 2 years in the EU). Also, the SIM card dummy adapters are surprisingly expensive to get hold of :/ All time spent in doing the hardware design (schematics, layout, firmware, host software) is volunteer work by Kevin and me. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Jul 14 19:44:53 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 14 Jul 2011 21:44:53 +0200 Subject: GPL version of SIMtrace Message-ID: <4E1F4735.80406@freyther.de> Hi Harald, it looks like that simtrace (the host application) is licensed under GPLv2? Is this on purpose? holger From laforge at gnumonks.org Thu Jul 14 22:41:25 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 15 Jul 2011 00:41:25 +0200 Subject: GPL version of SIMtrace In-Reply-To: <4E1F4735.80406@freyther.de> References: <4E1F4735.80406@freyther.de> Message-ID: <20110714224125.GH25905@prithivi.gnumonks.org> Hi Holger, On Thu, Jul 14, 2011 at 09:44:53PM +0200, Holger Hans Peter Freyther wrote: > it looks like that simtrace (the host application) is licensed under GPLv2? Is > this on purpose? I took code samples from openpcd host code to create it, that's probably why. I don't think there's a problem to make it GPLv2+ or GPLv3, but let me review that first to be sure. AGPL doesn't really make sense here, as you don't really operate simtrace as a network service with remote access anyway... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ml at mail.tsaitgaist.info Thu Jul 14 14:48:12 2011 From: ml at mail.tsaitgaist.info (tsaitgaist) Date: Thu, 14 Jul 2011 16:48:12 +0200 Subject: Active Manipulation SIM-ME In-Reply-To: References:

Message-ID: <4E1F01AC.9060700@mail.tsaitgaist.info> Hi, On 14.07.2011 16:26, Dirk Kirsten wrote: > Thats great news! > > So (I guess that ones for Harald Welte) when will the HW be publicly > available? You wrote in your last mail to this list on 27C3 - Am I just > missing something or wasn't this last December? Did you mean instead > 28C3? But this is in December, which is still quite some time... He will sell SIMtrace at the CCC Camp (10th-15th august). The schematic and pcb drawing are also available in git. You can produce your own if you want it earlier. Search in the mailing list and wiki for more information. Kevin From ml at mail.tsaitgaist.info Thu Jul 14 14:45:02 2011 From: ml at mail.tsaitgaist.info (tsaitgaist) Date: Thu, 14 Jul 2011 16:45:02 +0200 Subject: Active Manipulation SIM-ME In-Reply-To: References: Message-ID: <4E1F00EE.9030104@mail.tsaitgaist.info> Hi, Here some corrections : On 14.07.2011 15:37, Dirk Kirsten wrote: > Hello, > > We would like to do some active manipulation between our ME and the SIM > card. As I understood correctly, the hardware SIMtrace project is just > about passive monitoring the traffic in between, am I right? So this > seems to be inappropriate for our aims. The hardware can co MitM. Only the software has to implement it. > > So we thought about a solution more like the RebelSIM card, which is > documented as well in the osmocomBB wiki. Unfortunately, the information > given there are also very vague. So maybe it is just outdated: Does > anybody worked with the RebelSIM card in a way that they try to > manipulate the responses from the SIM (or do something else, except from > unlocking their phone)? Is it possible to flash it via SIM card > interface?! The rebelSIM can only sniff, even that is very unstable. This is why we built SIMtrace. > > What we actually want to do is to replace same values, e.g. we want to > provide another Kc than the SIM card in fact has (this is solely a > research project). So maybe there is some other way to do is, except the > approach based on RebelSIM? If so I would be grateful for your valuable > feedback. You can also try the softSIM project. Compile osmocomBB with the SAP support from nion, and use the SAP server. Then you can change everything in software. > > Cheers, > Dirk > > Kevin From spaar at mirider.augusta.de Fri Jul 15 11:45:25 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Fri, 15 Jul 2011 11:45:25 CEST Subject: Active Manipulation SIM-ME Message-ID: <4e202855.mirider@mirider.augusta.de> Hello Kevin, On Thu, 14 Jul 2011 16:45:02 +0200, "tsaitgaist" wrote: > > The rebelSIM can only sniff, even that is very unstable. The Rebel SIM card (the device which goes between the SIM card holder and the SIM card) can do MITM. However one has to write its own firmware for the microcontroller and the hardware is limited (e.g. there is no interface to a PC). Another device is from Bladox, the hardware is quite nice however the full source code of the firmware is not available. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From ahelblin at cs.uml.edu Fri Jul 15 16:14:51 2011 From: ahelblin at cs.uml.edu (Adam Helbling) Date: Fri, 15 Jul 2011 12:14:51 -0400 Subject: Active Manipulation SIM-ME In-Reply-To: <4e202855.mirider@mirider.augusta.de> References: <4e202855.mirider@mirider.augusta.de> Message-ID: True the Bladox product doesn't provide the full source code. But the nice thing is that the creator seems allow for easy hooks and API mechanisms to do do simple MITM things. The issue I have with the Bladox product is that you others enhance the capabilities of the firmware. Even if you wanted to the Atmel chip used has some pretty decent security mechanisms. Regardless, I think that the SIMtrace hardware is going to be a great addition to the space, and I'm looking forward to it. On Fri, Jul 15, 2011 at 4:45 AM, Dieter Spaar wrote: > Hello Kevin, > > On Thu, 14 Jul 2011 16:45:02 +0200, "tsaitgaist" > wrote: > > > > The rebelSIM can only sniff, even that is very unstable. > > The Rebel SIM card (the device which goes between the SIM card holder > and the SIM card) can do MITM. However one has to write its own firmware > for the microcontroller and the hardware is limited (e.g. there is no > interface to a PC). > > Another device is from Bladox, the hardware is quite nice however the full > source code of the firmware is not available. > > Best regards, > Dieter > -- > Dieter Spaar, Germany spaar at mirider.augusta.de > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailman at lists.osmocom.org Mon Jul 18 23:01:19 2011 From: mailman at lists.osmocom.org (mailman at lists.osmocom.org) Date: Tue, 19 Jul 2011 01:01:19 +0200 Subject: Bounce action notification Message-ID: This is a Mailman mailing list bounce action notice: List: simtrace Member: andre at ac.nl.eu.org Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at lists.osmocom.org. -------------- next part -------------- An embedded message was scrubbed... From: Mail Delivery System Subject: Mail delivery failed: returning message to sender Date: Tue, 19 Jul 2011 00:47:05 +0200 Size: 3627 URL: From laforge at gnumonks.org Tue Jul 19 08:58:28 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 19 Jul 2011 10:58:28 +0200 Subject: capacitor at Vcc of the card Message-ID: <20110719085828.GK2015@prithivi.gnumonks.org> Hi all, just before I forget it agan: I recently read in a completely different context that ISO7816 mandates a capacitor being placed very close to the acutak SIM card socket. It would be good to check the specs and see if this is true. If yes, we might add it to the next version of the hardware, just to be sure. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Jul 24 08:55:54 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 24 Jul 2011 10:55:54 +0200 Subject: Roadmap for SIMtrace firmware Message-ID: <20110724085554.GC8595@prithivi.gnumonks.org> Hi all! I just waned to give you a heads-up of where I want to be heading with regard to the simtrace firmware. Right now we still use a hacked add-on to the OpenPCD firmware I wrote some 5 years ago. This was a quick way to get something working, as I knew the code base. It has served that purpose: We quickly had a firmware for sniffing mode. That code had been developed before Atmel started to publish ther at91lib software packages which contain a lot of (probably better tested and more portable) code supporting a wide range of Atmel ARM devices. at91lib is especially strong on the USB side, where there are not only implementations of CDC-ACM (serial), CCID (smartcard reader), mass storage, usb-audio, etc. - but also composite devies out of multiple of the above. So what I have in mind for simtrace now is to move forward using at91lib. However, at91lib does (obviously) not support my sam7dfu boot loader / flasher. DFU has been proven an exremely helpful tool for R&D type projects, where you need quick turn-around times for testing new code in absence of a JTAG setup. Using the SAM-BA loader is pretty annoying even after a short time, the constant cycles of usb-plug/unplug, jumper closing and opeing quickly wears out not only your nerves but even the usb plug or socket. I know people who have built USB cables with a power switch in the Vbus line, but even that does only half the trick. So what I'm now doing is adding linker scripts + startup magic to at91lib so it can build .bin files that can be downloaded using the sam7dfu bootloader on the device, and dfu-util on the host PC. Once that is finished, I intend to: * port over the existing 'sniffer mode' code from the openpcd.git repository and 'glue' it behind a CDC-ACM device. This means that in the future, all operatign systems will only see a serial device with APDUs coming out of them. * use the at91lib-provided CCID code to build a second firmware image for a 'reader mode', where the PC can use simtrace as smartcard reader * later merge the two into a single firmware with two alternative USB configurations * finally, add a 'softsim' mode, where the PC can simulate the SIM card to the phone. I'm not sure what I'll do on the USB protocol side for this. Chances are high it's again CDC-ACM - but this time simultaneously with CCID for the reader side, for man-in-the-middle. The advantage here is that we don't need to work with libusb, which apparently can be challenging for users of legacy operating systems ;) Thus, the ideal situation would be a single firmware image that provides three alternate configurations: Sniffer, Cardreader and MITM. Any help is of course very much appreciated. I'll push my at91lib git tree with sam7dfu support as soon as I've done some testing (I'm travelling and unfortunately forgot my 2.5mm jack USB-serial cable). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jul 30 21:36:20 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 30 Jul 2011 23:36:20 +0200 Subject: Simtrace production hardware Message-ID: <20110730213619.GT6210@prithivi.gnumonks.org> Hi all, the 100 SIMtrace production units have recently arrived from the SMT factory. While this is good news, there are some bad news as well: 1) blocking capacitor C12 too far from LDO causing power oscillations This problem can easily be re-worked by manually soldering a capacitor immediately to the LDO input pin. Even though 60-75% of the units seem to work without the re-work, we're adding it to make sure there are no issues later on. 2) something like 20 to 25% of the units have some problem related to the initial programming of the SAM-BA loader. Everything works fine if the flashing is been done via JTAG, or later using sam7dfu + dfu-util. The problem is still under investigation, but despite something like 6 hours debugging and soldering additional capacitors, even replacing the entire SAM7S have not rendered any results. Please don't ask me to ship some units yet, as we are still testing them. As per our original schedule, we will start to sell them at the CCC Camp and then offer a webshop from the second half of August onwards. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jul 30 21:30:30 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 30 Jul 2011 23:30:30 +0200 Subject: Roadmap for SIMtrace firmware In-Reply-To: <20110724085554.GC8595@prithivi.gnumonks.org> References: <20110724085554.GC8595@prithivi.gnumonks.org> Message-ID: <20110730213030.GS6210@prithivi.gnumonks.org> Status update: On Sun, Jul 24, 2011 at 10:55:54AM +0200, Harald Welte wrote: > However, at91lib does (obviously) not support my sam7dfu boot loader / > flasher. DFU has been proven an exremely helpful tool for R&D type > projects, where you need quick turn-around times for testing new code > in absence of a JTAG setup. Using the SAM-BA loader is pretty annoying > even after a short time, the constant cycles of usb-plug/unplug, jumper > closing and opeing quickly wears out not only your nerves but even the > usb plug or socket. I know people who have built USB cables with a > power switch in the Vbus line, but even that does only half the trick. > > So what I'm now doing is adding linker scripts + startup magic to > at91lib so it can build .bin files that can be downloaded using the > sam7dfu bootloader on the device, and dfu-util on the host PC. this has now been done, the result is available in git://git.gnumonks.org/at91work.git for BOARD=simtrace it will create a *-flash_dfu.bin files, which can be downloaded into a board running sam7dfu using dfu-util. What's missing is the DFU configuration descriptors and the 'switch from application to DFU mode' logic that allows you to flash new application firmware without having to push the bootloader+reset buttons. > * use the at91lib-provided CCID code to build a second firmware image > for a 'reader mode', where the PC can use simtrace as smartcard > reader I've been working on that. However, progress is slow due to various insufficiencies in the Atmel CCID code. Now I'm getting the first couple of ATRs out of it using openct on the PC side. > * finally, add a 'softsim' mode, where the PC can simulate the SIM > card to the phone. I'm not sure what I'll do on the USB protocol > side for this. Chances are high it's again CDC-ACM - but this time > simultaneously with CCID for the reader side, for man-in-the-middle. Unfortunately the sam7s has only 4 USB end points, I almost forgot about that. A CCID device already needs all four of them, so we cannot have a concurrent CDC-ACM device or similar. The only reasonable way seems to be the PC_to_RDR_Escape messages which are built into CCID. This way at least the reader part will be compliant to a standard protocol, only the 'card simulation' part is different. If somebody ever does another version of the hardware, it might be worth using a pin-to-pin compatible SAM3S, which would provide 7 USB endpoints and thus work the way I originally thought in my last mail. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)