From tom at zwizwa.be Mon Jul 8 22:43:34 2013 From: tom at zwizwa.be (Tom Schouten) Date: Mon, 08 Jul 2013 18:43:34 -0400 Subject: SIMtrace MITM/emulator Message-ID: <51DB4096.8050508@zwizwa.be> Hi List, What is the current status of the MITM support? Anyone working on it behind the scenes? Also, I'd like to gauge how much work would be necessary to implement an emulator mode, with emulator running on PC. I.e. SIMtrace used to doe ATR handshake and then hand over all APDU to host PC over USB. Cheers Tom From ml at mail.tsaitgaist.info Tue Jul 9 01:19:26 2013 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Mon, 08 Jul 2013 18:19:26 -0700 Subject: SIMtrace MITM/emulator In-Reply-To: <51DB4096.8050508@zwizwa.be> References: <51DB4096.8050508@zwizwa.be> Message-ID: <1373332541-sup-497@dennou> Excerpts from Tom Schouten's message of 2013-07-08 15:43:34 -0700: > Hi List, > > What is the current status of the MITM support? Anyone working on it > behind the scenes? > currently no-one. I planned to do it in the next months. > Also, I'd like to gauge how much work would be necessary to implement an > emulator mode, with emulator running on PC. I.e. SIMtrace used to doe > ATR handshake and then hand over all APDU to host PC over USB. > I will mainly implement a APDU forwarder, where the PC will receive the APDU from the phone and can reply kevin > Cheers > Tom From tom at zwizwa.be Tue Jul 9 14:58:50 2013 From: tom at zwizwa.be (Tom Schouten) Date: Tue, 09 Jul 2013 10:58:50 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <1373332541-sup-497@dennou> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> Message-ID: <51DC252A.5000902@zwizwa.be> On 07/08/2013 09:19 PM, Kevin Redon wrote: > Excerpts from Tom Schouten's message of 2013-07-08 15:43:34 -0700: >> Hi List, >> >> What is the current status of the MITM support? Anyone working on it >> behind the scenes? >> > currently no-one. > I planned to do it in the next months. > >> Also, I'd like to gauge how much work would be necessary to implement an >> emulator mode, with emulator running on PC. I.e. SIMtrace used to doe >> ATR handshake and then hand over all APDU to host PC over USB. >> > I will mainly implement a APDU forwarder, where the PC will receive the APDU from the phone and can reply > > kevin Hi Kevin, I need it soon, so I'm making a stab at it. I'll put progress here: https://github.com/zwizwa/openpcd # branch apdufw If you have any suggestions, let me know. I'd be particularly interested in ideas about what representation to use for transporting APDU packets to/from host. ( I had been thinking about SLIP, but it might not be necessary to encapsulate it. ) Cheers, Tom > >> Cheers >> Tom > From tom at zwizwa.be Wed Jul 10 14:14:10 2013 From: tom at zwizwa.be (Tom Schouten) Date: Wed, 10 Jul 2013 10:14:10 -0400 Subject: SIM tracer for Saleae Logic Message-ID: <51DD6C32.7030707@zwizwa.be> Hi List, This might be of interest to folks here. A couple of days ago I found out the Saleae Logichas an SDK that allows you to live stream raw sample data straight into a C++ application. Quite neat, as it can go to fairly high sample rates. Here is a proof of concept version of a live APDU protocol sniffer using the SL: https://github.com/zwizwa/sl-apdu Essentially it's just a UART state machine with some hardcoded ATR parsing (for the specific SIM card I have) which calls into apdu_split from git://git.osmocom.org/simtrace.git after the ATR handshake. I had a look at the ISO7816 parser in the SIMtrace firmware, but it's fairly tied to the hardware. With some refactoring it's probably easy to reuse. ( The sl-apdu repo has a first attempt to a dirty stub approach to run the original AT91 code. Probably not be the way to go.. ) Cheers Tom From laforge at gnumonks.org Wed Jul 10 15:26:09 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jul 2013 17:26:09 +0200 Subject: SIMtrace MITM/emulator In-Reply-To: <51DC252A.5000902@zwizwa.be> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> Message-ID: <20130710152609.GX6004@nataraja.gnumonks.org> Hi Tom, On Tue, Jul 09, 2013 at 10:58:50AM -0400, Tom Schouten wrote: > I need it soon, so I'm making a stab at it. I'll put progress here: > https://github.com/zwizwa/openpcd # branch apdufw thanks! I have a repository at 'git://git.gnumonks.org/at91work.git' which contains (modified) atmel reference code for turning the simtrace into a USB CCID based smart card reader (usb-device-ccid-project directory). This is already integated with the sam7dfu loader, so you will still be able to do DFU based firmware updates. Unfortunately about two years ago I never found the time to continue towards MITM, but this was where I stopped. > I'd be particularly interested in ideas about what representation to > use for transporting APDU packets to/from host. In the ideal world, a MITM firmware would export two USB interfaces: * one CCID class interface for the sim card reader part * one proprietary interface (maybe CDC/ACM based) for the phone-facing part. However, using the AT91SAM7S this is unfortunately not possible, given the small number of USB endpoints :( So my next-best idea was then: * use the CCID reference example from atmel for the card-reader part, this way standard opensc/openct/pcsc-lite drivers can handle the card reader like any other card reader * encapsulate the phone-facing part in the PC_to_RDR_Escape / RDR_to_PC_Escape messages of the CCID protocol So a modified/enhaced CCID driver on the PC would be able to talk to both the sim card and the phone, whereas a standard CCID reader could still work with the SIM like a card reader. > ( I had been thinking about SLIP, but it might not be necessary to > encapsulate it. ) I'm not sure where SLIP would fit into the picture. USB has multiple end-points and is already message ('transfer') based, i.e. not a stream like a serial port where you need something like HDLC or SLIP to transport message through. If you really think you need to multiplex multiple streams over one endpoint or an emulated serial port (god beware), then please consider either using a full-blown TS 07.10 multiplex, or the 'sercomm' layer we use in OsmocomBB between the firmware and the host pc (The 'osmocon') program. This way we either get something standardized (TS 07.10) or something that can benefit from code re-use within the osmocom project. 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 vlastimil.pavicek at centrum.cz Wed Jul 10 17:35:58 2013 From: vlastimil.pavicek at centrum.cz (=?utf-8?q?Vlastimil_P=C3=A1vi=C4=8Dek?=) Date: Wed, 10 Jul 2013 19:35:58 +0200 Subject: =?utf-8?q?Re=3A_SIMtrace_MITM=2Femulator?= In-Reply-To: <20130710152609.GX6004@nataraja.gnumonks.org> References: <51DB4096.8050508@zwizwa.be>, <1373332541-sup-497@dennou>, <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> Message-ID: <20130710193558.963578E6@centrum.cz> ______________________________________________________________ > Od: "Harald Welte" > Komu: Tom Schouten > Datum: 10.07.2013 18:13 > P?edm?t: Re: SIMtrace MITM/emulator > >So my next-best idea was then: >* use the CCID reference example from atmel for the card-reader part, > this way standard opensc/openct/pcsc-lite drivers can handle the card > reader like any other card reader >* encapsulate the phone-facing part in the PC_to_RDR_Escape / > RDR_to_PC_Escape messages of the CCID protocol > Another way could be to encapsulate the phone-facing part commands in APDU commands with CLA value '0xFF' (which is forbidden by ISO-7816) and interpret them in the reader code. Some readers use this trick for similar purposes (i.e. Application <-> Reader communication). Best regards VLP From tom at zwizwa.be Wed Jul 10 21:12:23 2013 From: tom at zwizwa.be (Tom Schouten) Date: Wed, 10 Jul 2013 17:12:23 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <20130710193558.963578E6@centrum.cz> References: <51DB4096.8050508@zwizwa.be>, <1373332541-sup-497@dennou>, <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> Message-ID: <51DDCE37.9000406@zwizwa.be> Hi Harald, Vlastimil, >> git://git.gnumonks.org/at91work.git Great. I'll check it out. Is there anything essential that is missing? On 07/10/2013 01:35 PM, Vlastimil P?vi?ek wrote: > ______________________________________________________________ >> Od: "Harald Welte" >> Komu: Tom Schouten >> Datum: 10.07.2013 18:13 >> P?edm?t: Re: SIMtrace MITM/emulator >> >> So my next-best idea was then: >> * use the CCID reference example from atmel for the card-reader part, >> this way standard opensc/openct/pcsc-lite drivers can handle the card >> reader like any other card reader >> * encapsulate the phone-facing part in the PC_to_RDR_Escape / >> RDR_to_PC_Escape messages of the CCID protocol >> > Another way could be to encapsulate the phone-facing part commands in APDU commands with CLA value '0xFF' (which is forbidden by ISO-7816) and interpret them in the reader code. Some readers use this trick for similar purposes (i.e. Application<-> Reader communication). If there is a provision in the CCID to handle neatly delineated packets in two directions through the escape approach, it's probably best to use it. Do you know if he escape mechanism is universally supported from the PC application side? Cheers Tom From laforge at gnumonks.org Wed Jul 10 21:52:36 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jul 2013 23:52:36 +0200 Subject: SIMtrace MITM/emulator In-Reply-To: <51DDCE37.9000406@zwizwa.be> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> <51DDCE37.9000406@zwizwa.be> Message-ID: <20130710215236.GH6004@nataraja.gnumonks.org> Hi Tom, On Wed, Jul 10, 2013 at 05:12:23PM -0400, Tom Schouten wrote: > >> git://git.gnumonks.org/at91work.git > > Great. I'll check it out. Is there anything essential that is missing? for CCID (card reader operation) not, it is basically the Atmel reference code merged with my DFU loader work and configured for the SIMtrace hardware. However, this is a completely different code base than what I used for the old/current SIMtrace firmware. At that point I simply recycled code that I had written for openOCD many years earlier, when AFAIK there was no at91lib from atmel that could be used. So the 'simple' approach would be to not merge them yet, but have a CCID + phone-side firmware based on at91lib/at91work, but keep the old openpcd derived firmware for tracing. Switching the modes would then require a firmware download. As soon as somebody finds time, the two firmwares could be merged, but my focus would be to have something that can do MITM at all, rather than all features in one firmware image. > Do you know if he escape mechanism is universally supported from the > PC application side? I fear you have to extend the respective CCID driver (libccid in the case of Linux and AFAIK also MacOS). I'm not aware of any standard interface towards application programs to use this. It's only standardized on the USB side. 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 tom at zwizwa.be Thu Jul 11 14:20:54 2013 From: tom at zwizwa.be (Tom Schouten) Date: Thu, 11 Jul 2013 10:20:54 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <20130710215236.GH6004@nataraja.gnumonks.org> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> <51DDCE37.9000406@zwizwa.be> <20130710215236.GH6004@nataraja.gnumonks.org> Message-ID: <51DEBF46.6010802@zwizwa.be> On 07/10/2013 05:52 PM, Harald Welte wrote: > Hi Tom, > > On Wed, Jul 10, 2013 at 05:12:23PM -0400, Tom Schouten wrote: >>>> git://git.gnumonks.org/at91work.git >> Great. I'll check it out. Is there anything essential that is missing? > for CCID (card reader operation) not, it is basically the Atmel > reference code merged with my DFU loader work and configured for the > SIMtrace hardware. > > However, this is a completely different code base than what I used for > the old/current SIMtrace firmware. At that point I simply recycled code > that I had written for openOCD many years earlier, when AFAIK there was > no at91lib from atmel that could be used. > > So the 'simple' approach would be to not merge them yet, but have a CCID > + phone-side firmware based on at91lib/at91work, but keep the old > openpcd derived firmware for tracing. Switching the modes would then > require a firmware download. > > As soon as somebody finds time, the two firmwares could be merged, but > my focus would be to have something that can do MITM at all, rather than > all features in one firmware image. I see. > >> Do you know if he escape mechanism is universally supported from the >> PC application side? > I fear you have to extend the respective CCID driver (libccid in the case > of Linux and AFAIK also MacOS). I'm not aware of any standard interface > towards application programs to use this. It's only standardized on the > USB side. I guess it's best for me to focus on the basic functionality first, and solve the interface problem later in a second iteration when there is time left. Thanks for your input Tom BTW, one thing I noticed in both firmwares is that the LMA in the flash elf binaries is not set correctly. I was using the plain "load" command in gdb to flash the bootloader and app to my AT91SAM7-EK over JTAG (segger blue box), but the app went to 0x0 instead of 0x4000. From tom at zwizwa.be Thu Jul 11 15:36:04 2013 From: tom at zwizwa.be (Tom Schouten) Date: Thu, 11 Jul 2013 11:36:04 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <51DEBF46.6010802@zwizwa.be> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> <51DDCE37.9000406@zwizwa.be> <20130710215236.GH6004@nataraja.gnumonks.org> <51DEBF46.6010802@zwizwa.be> Message-ID: <51DED0E4.4020003@zwizwa.be> > > BTW, one thing I noticed in both firmwares is that the LMA in the > flash elf binaries is not set correctly. I was using the plain "load" > command in gdb to flash the bootloader and app to my AT91SAM7-EK over > JTAG (segger blue box), but the app went to 0x0 instead of 0x4000. > > Here's a fix: [master] tom at zoo:~/at91work/at91lib/boards/simtrace/at91sam7s256$ git diff flash_dfu.lds diff --git a/at91lib/boards/simtrace/at91sam7s256/flash_dfu.lds b/at91lib/boards/simtrace/at91sam7s256/flash_dfu.lds index c228dcc..e3e5147 100644 --- a/at91lib/boards/simtrace/at91sam7s256/flash_dfu.lds +++ b/at91lib/boards/simtrace/at91sam7s256/flash_dfu.lds @@ -45,7 +45,7 @@ MEMORY SECTIONS { . = 0x000000000; - .fixed 0x00104000: AT ( 0x00000000 ) + .fixed 0x00104000: { . = ALIGN(4); _sfixed = .; @@ -55,7 +55,7 @@ SECTIONS _efixed = .; } >flash - .relocate 0x00200028: AT ( SIZEOF(.fixed) ) + .relocate 0x00200028: { . = ALIGN(4); _srelocate = .; @@ -64,7 +64,7 @@ SECTIONS *(.data) . = ALIGN(4); _erelocate = .; - } >sram + } >sram AT >flash .bss (NOLOAD) : { _szero = .; From tom at zwizwa.be Mon Jul 15 16:07:28 2013 From: tom at zwizwa.be (Tom Schouten) Date: Mon, 15 Jul 2013 12:07:28 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <20130710215236.GH6004@nataraja.gnumonks.org> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> <51DDCE37.9000406@zwizwa.be> <20130710215236.GH6004@nataraja.gnumonks.org> Message-ID: <51E41E40.6070907@zwizwa.be> Hi Harald, On 07/10/2013 05:52 PM, Harald Welte wrote: > > On Wed, Jul 10, 2013 at 05:12:23PM -0400, Tom Schouten wrote: >>>> git://git.gnumonks.org/at91work.git >> Great. I'll check it out. Is there anything essential that is missing? > for CCID (card reader operation) not, it is basically the Atmel > reference code merged with my DFU loader work and configured for the > SIMtrace hardware. Did you need to make any modifications to pcscd & libccid? ( apart from additing the USB id to libccid_Info.plist ) What versions did you use? Cheers Tom From peter at stuge.se Mon Jul 15 16:23:31 2013 From: peter at stuge.se (Peter Stuge) Date: Mon, 15 Jul 2013 18:23:31 +0200 Subject: SIMtrace MITM/emulator In-Reply-To: <20130710152609.GX6004@nataraja.gnumonks.org> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> Message-ID: <20130715162331.9328.qmail@stuge.se> Harald Welte wrote: > In the ideal world, a MITM firmware would export two USB interfaces: > > However, using the AT91SAM7S this is unfortunately not possible, > given the small number of USB endpoints :( > > So my next-best idea was then: > * use the CCID reference example from atmel for the card-reader part, > this way standard opensc/openct/pcsc-lite drivers can handle the card > reader like any other card reader > * encapsulate the phone-facing part in the PC_to_RDR_Escape / > RDR_to_PC_Escape messages of the CCID protocol Another method would be type=vendor recipient=device control requests over the default endpoint. This works well everywhere except on Windows. //Peter From tom at zwizwa.be Mon Jul 15 19:32:40 2013 From: tom at zwizwa.be (Tom Schouten) Date: Mon, 15 Jul 2013 15:32:40 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <51E41E40.6070907@zwizwa.be> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> <51DDCE37.9000406@zwizwa.be> <20130710215236.GH6004@nataraja.gnumonks.org> <51E41E40.6070907@zwizwa.be> Message-ID: <51E44E58.3000302@zwizwa.be> On 07/15/2013 12:07 PM, Tom Schouten wrote: > > Hi Harald, > > On 07/10/2013 05:52 PM, Harald Welte wrote: >> >> On Wed, Jul 10, 2013 at 05:12:23PM -0400, Tom Schouten wrote: >>>>> git://git.gnumonks.org/at91work.git >>> Great. I'll check it out. Is there anything essential that is missing? >> for CCID (card reader operation) not, it is basically the Atmel >> reference code merged with my DFU loader work and configured for the >> SIMtrace hardware. > > Did you need to make any modifications to pcscd & libccid? ( apart > from additing the USB id to libccid_Info.plist ) > What versions did you use? > I tried with latest release pcscd & libccid. I removed the BOARD_USB_DFU to avoid error messages related to the DFU USB interfaces. This is what I got from pcscd. Does the error remind you of anything you ran into? Jul 15 15:28:50 zoo pcscd: ccid_usb.c:1065:ControlUSB() control failed (3/87): -7 Success Jul 15 15:28:50 zoo pcscd: ifdwrapper.c:348:IFDStatusICC() Card not transacted: 612 Jul 15 15:28:50 zoo pcscd: eventhandler.c:202:EHSpawnEventHandler() Initial Check Failed on Sysmocom SIMtrace (0123456789AF) 00 00 Jul 15 15:28:50 zoo pcscd: readerfactory.c:338:RFAddReader() Sysmocom SIMtrace (0123456789AF) init failed. Jul 15 15:28:50 zoo pcscd: hotplug_libudev.c:384:HPAddDevice() Failed adding USB device: Sysmocom SIMtrace Jul 15 15:28:51 zoo kernel: [188104.680951] usb 3-2.4.1: new full-speed USB device number 87 using ehci_hcd Jul 15 15:28:51 zoo kernel: [188104.960743] usb 3-2.4.1: New USB device found, idVendor=03eb, idProduct=6129 Jul 15 15:28:51 zoo kernel: [188104.960756] usb 3-2.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jul 15 15:28:51 zoo kernel: [188104.960766] usb 3-2.4.1: Product: ATMEL AT91 CCID DRIVER Jul 15 15:28:51 zoo kernel: [188104.960773] usb 3-2.4.1: Manufacturer: ATMEL Jul 15 15:28:51 zoo kernel: [188104.960779] usb 3-2.4.1: SerialNumber: 0123456789AF From tom at zwizwa.be Tue Jul 16 15:33:26 2013 From: tom at zwizwa.be (Tom Schouten) Date: Tue, 16 Jul 2013 11:33:26 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <51E44E58.3000302@zwizwa.be> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> <51DDCE37.9000406@zwizwa.be> <20130710215236.GH6004@nataraja.gnumonks.org> <51E41E40.6070907@zwizwa.be> <51E44E58.3000302@zwizwa.be> Message-ID: <51E567C6.2020809@zwizwa.be> On 07/15/2013 03:32 PM, Tom Schouten wrote: > On 07/15/2013 12:07 PM, Tom Schouten wrote: >> >> Hi Harald, >> >> On 07/10/2013 05:52 PM, Harald Welte wrote: >>> >>> On Wed, Jul 10, 2013 at 05:12:23PM -0400, Tom Schouten wrote: >>>>>> git://git.gnumonks.org/at91work.git >>>> Great. I'll check it out. Is there anything essential that is >>>> missing? >>> for CCID (card reader operation) not, it is basically the Atmel >>> reference code merged with my DFU loader work and configured for the >>> SIMtrace hardware. >> >> Did you need to make any modifications to pcscd & libccid? ( apart >> from additing the USB id to libccid_Info.plist ) >> What versions did you use? >> > > I tried with latest release pcscd & libccid. I removed the > BOARD_USB_DFU to avoid error messages related to the DFU USB > interfaces. This is what I got from pcscd. Does the error remind you > of anything you ran into? > > Jul 15 15:28:50 zoo pcscd: ccid_usb.c:1065:ControlUSB() control failed > (3/87): -7 Success > Jul 15 15:28:50 zoo pcscd: ifdwrapper.c:348:IFDStatusICC() Card not > transacted: 612 > Jul 15 15:28:50 zoo pcscd: eventhandler.c:202:EHSpawnEventHandler() > Initial Check Failed on Sysmocom SIMtrace (0123456789AF) 00 00 > Jul 15 15:28:50 zoo pcscd: readerfactory.c:338:RFAddReader() Sysmocom > SIMtrace (0123456789AF) init failed. > Jul 15 15:28:50 zoo pcscd: hotplug_libudev.c:384:HPAddDevice() Failed > adding USB device: Sysmocom SIMtrace > Jul 15 15:28:51 zoo kernel: [188104.680951] usb 3-2.4.1: new > full-speed USB device number 87 using ehci_hcd > Jul 15 15:28:51 zoo kernel: [188104.960743] usb 3-2.4.1: New USB > device found, idVendor=03eb, idProduct=6129 > Jul 15 15:28:51 zoo kernel: [188104.960756] usb 3-2.4.1: New USB > device strings: Mfr=1, Product=2, SerialNumber=3 > Jul 15 15:28:51 zoo kernel: [188104.960766] usb 3-2.4.1: Product: > ATMEL AT91 CCID DRIVER > Jul 15 15:28:51 zoo kernel: [188104.960773] usb 3-2.4.1: Manufacturer: > ATMEL > Jul 15 15:28:51 zoo kernel: [188104.960779] usb 3-2.4.1: SerialNumber: > 0123456789AF > > Seems there is a discrepancy between libccid and at91lib driver about the meaning of the slot status bits. (at91lib) cciddriver.c: // 6.3.1 RDR_to_PC_NotifySlotChange #define ICC_NOT_PRESENT 0x00 #define ICC_PRESENT 0x01 #define ICC_CHANGE 0x02 #define ICC_INSERTED_EVENT ICC_PRESENT+ICC_CHANGE (libccid) ccid.h: /* See CCID specs ch. 4.2.1 */ #define CCID_ICC_PRESENT_ACTIVE 0x00 /* 00 0000 00 */ #define CCID_ICC_PRESENT_INACTIVE 0x01 /* 00 0000 01 */ #define CCID_ICC_ABSENT 0x02 /* 00 0000 10 */ #define CCID_ICC_STATUS_MASK 0x03 /* 00 0000 11 */ There is no 0x03 case in libccid, which is what causes the obscure communication error 612. SIMtrace firmware returns 0x03 on startup, regardless of SIM insertion state. I can probably fix this, though I wonder why the problem wasn't there before.. Cheers Tom From tom at zwizwa.be Tue Jul 16 19:47:40 2013 From: tom at zwizwa.be (Tom Schouten) Date: Tue, 16 Jul 2013 15:47:40 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <20130715162331.9328.qmail@stuge.se> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130715162331.9328.qmail@stuge.se> Message-ID: <51E5A35C.4070008@zwizwa.be> On 07/15/2013 12:23 PM, Peter Stuge wrote: > Harald Welte wrote: >> In the ideal world, a MITM firmware would export two USB interfaces: >> >> However, using the AT91SAM7S this is unfortunately not possible, >> given the small number of USB endpoints :( >> >> So my next-best idea was then: >> * use the CCID reference example from atmel for the card-reader part, >> this way standard opensc/openct/pcsc-lite drivers can handle the card >> reader like any other card reader >> * encapsulate the phone-facing part in the PC_to_RDR_Escape / >> RDR_to_PC_Escape messages of the CCID protocol > Another method would be type=vendor recipient=device control requests > over the default endpoint. This works well everywhere except on Windows. Does this work if the device is already bound by another driver - in this case libccid? If so it would probably the simplest of all approaches mentioned so far. From peter at stuge.se Wed Jul 17 12:37:10 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 17 Jul 2013 14:37:10 +0200 Subject: SIMtrace MITM/emulator In-Reply-To: <51E5A35C.4070008@zwizwa.be> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130715162331.9328.qmail@stuge.se> <51E5A35C.4070008@zwizwa.be> Message-ID: <20130717123710.4804.qmail@stuge.se> Tom Schouten wrote: >> Another method would be type=vendor recipient=device control requests >> over the default endpoint. This works well everywhere except on Windows. > > Does this work if the device is already bound by another driver - in > this case libccid? I'll repeat myself: This works well everywhere except on Windows. //Peter From tom at zwizwa.be Wed Jul 17 16:09:48 2013 From: tom at zwizwa.be (Tom Schouten) Date: Wed, 17 Jul 2013 12:09:48 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <20130710152609.GX6004@nataraja.gnumonks.org> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> Message-ID: <51E6C1CC.10007@zwizwa.be> On 07/10/2013 11:26 AM, Harald Welte wrote: > > I have a repository at 'git://git.gnumonks.org/at91work.git' which > contains (modified) atmel reference code for turning the simtrace into a > USB CCID based smart card reader (usb-device-ccid-project directory). > I keep finding treasures. Just found out about the COS. Looks like some of the osmo-cos code can be reused in the SIMtrace MITM. For low level ISO7816 TPDU,APDU code there are at least 3 users: - SIMtrace MITM mode - COS - front end for off-the-shelf LA like Saleae Logic From laforge at gnumonks.org Sun Jul 21 08:25:11 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Jul 2013 16:25:11 +0800 Subject: SIMtrace 3FF / micro-SIM adapter available Message-ID: <20130721082511.GF5573@nataraja.gnumonks.org> Hi! I really don't want to feel this list to be abused for advertisements, but in this case I'm sure it is of actual help to a number of people on this list: The sysmocom web shop finally has a 3FF (micro-SIM) adapter cable available: http://shop.sysmocom.de/products/simtrace-fpc-3ff Please note that (as opposed to the regular mini-SIM) we only have one of the possible four orientations available. This is primarily due to the high manufacturing cost of low-volume flexible PCB projects. We would like to hear from you 1) if you need this adapter in different orientation (which, for which phone) 2) for which phone model you have used this new 3FF adapter successfully 3) what kind of problems you may have encountered using it. Thanks to Kevin Redon for doing the PCB layout of this part. It is freely available as part of the simtrace.git repository since commit eee3243ddaa9e13bc7509a962fade8636b6ed2ab. On a related note: For nanoSIM, I think we would have to go for dual-layer PCB with vias placed inside the actual card contact pads. This will make production cost even more expensive than the microSIM adapter. So unless there's significant interest in a nanoSIM adapter, it's unlikely that we'd have some made. Please let us know if you absolutely want one, and if you're happy to pay even more (e.g. 25-30 EUR) for only that adapter. 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 jfmn at cesar.org.br Tue Jul 23 14:12:31 2013 From: jfmn at cesar.org.br (Francisco Marinho) Date: Tue, 23 Jul 2013 11:12:31 -0300 Subject: rebooting the smartphone. Message-ID: hi guys I have a problem with the simtrace, when I restart the smartphone some APDU are smaller than 8 bits, this is a know issue? Francisco Marinho -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at zwizwa.be Tue Jul 23 17:25:50 2013 From: tom at zwizwa.be (Tom Schouten) Date: Tue, 23 Jul 2013 13:25:50 -0400 Subject: SIMtrace MITM/emulator In-Reply-To: <20130710215236.GH6004@nataraja.gnumonks.org> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> <51DDCE37.9000406@zwizwa.be> <20130710215236.GH6004@nataraja.gnumonks.org> Message-ID: <51EEBC9E.9030303@zwizwa.be> Harald, On 07/10/2013 05:52 PM, Harald Welte wrote: > So the 'simple' approach would be to not merge them yet, but have a CCID > + phone-side firmware based on at91lib/at91work, but keep the old > openpcd derived firmware for tracing. Switching the modes would then > require a firmware download. > How should the licensing work when taking snippets from the at91lib and the SIMtrace/openpcd GPL code? The at91lib code requires the Atmel copyright notice to be retained in derived work. Is that compatible with licensing the whole firmware under the GPL? Cheers Tom From talibudur at gmail.com Tue Jul 23 21:00:14 2013 From: talibudur at gmail.com (Tali Budur) Date: Wed, 24 Jul 2013 00:00:14 +0300 Subject: Fwd: Cellphone can't detect sim card In-Reply-To: References: Message-ID: Hi! I have built 2 units of simtrace hardware recently. All the components came from digikey, I used the bom list from git. The PCBs are electrically tested. When I connected it to the pc, simtrace application can communicate with the device and I can debug it via the FTDI connection. The problem is, when I connect it to a cellphone, cellphone can not detect a sim card. Simtrace can detect vcc on, vcc off and rst signals from the cellphone however, cellphone can not detect the sim card. I used several different cell phones and sim cards. I also checked the connection between the cellhpone and simtrace. Couldn't find a problem. May I kindly request your help to solve the problem? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jul 24 01:27:22 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 24 Jul 2013 09:27:22 +0800 Subject: SIMtrace MITM/emulator In-Reply-To: <51EEBC9E.9030303@zwizwa.be> References: <51DB4096.8050508@zwizwa.be> <1373332541-sup-497@dennou> <51DC252A.5000902@zwizwa.be> <20130710152609.GX6004@nataraja.gnumonks.org> <20130710193558.963578E6@centrum.cz> <51DDCE37.9000406@zwizwa.be> <20130710215236.GH6004@nataraja.gnumonks.org> <51EEBC9E.9030303@zwizwa.be> Message-ID: <20130724012722.GQ6373@nataraja.gnumonks.org> Hi Tom, On Tue, Jul 23, 2013 at 01:25:50PM -0400, Tom Schouten wrote: > >So the 'simple' approach would be to not merge them yet, but have a CCID > >+ phone-side firmware based on at91lib/at91work, but keep the old > >openpcd derived firmware for tracing. Switching the modes would then > >require a firmware download. > > How should the licensing work when taking snippets from the at91lib > and the SIMtrace/openpcd GPL code? The at91lib code requires the > Atmel copyright notice to be retained in derived work. Is that > compatible with licensing the whole firmware under the GPL? Indicating the author of a work is a non-transferrable 'moral right' under EU (and possibly other jurisdictions) copyright anyway, so no matter what the GPL might say, an author can always require his name to be associated with the work. Also, the Atmel copyright notice + disclaimer is only requried in source code distributions, so it is not like the (GPL-incompatible) old BSD license with advertisement clause. In fact, to the contrary, Atmel states "Atmel's name may not be used to endorse or promote products derived from this software without specific prior written permission" So while I'm not the FSF and can make 'official' license interpretations, I wouldn't expect any problem here. If you'd like to get an official opinion by the FSF, feel free to submit the at91lib license header to their legal team. But please keep in mind, that even the FSF can only give an opinion and its interpretation (while being influential and respected) doesn't interfere with the freedom of a court deciding based on its understanding of law. 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 peter at stuge.se Wed Jul 24 04:38:05 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 24 Jul 2013 06:38:05 +0200 Subject: Fwd: Cellphone can't detect sim card In-Reply-To: References: Message-ID: <20130724043805.22631.qmail@stuge.se> Tali Budur wrote: > May I kindly request your help to solve the problem? How could anyone help you when you haven't provided any information about what actually fails? "can't detect sim card" is not a useful error report, it merely describes a symptom. From that it is impossible to say what your problem is. Use an oscilloscope or logic analyzer to investigate various points on the PCB. Use debugging statements inside the firmware to investigate what is going on in the firmware. Provide the mailing list with detailed information about what actually goes wrong. You have to do that investigation yourself. Only then can you actually get some help. //Peter From galersekali at gmail.com Thu Jul 25 18:52:38 2013 From: galersekali at gmail.com (anak galer) Date: Fri, 26 Jul 2013 01:52:38 +0700 Subject: ask about design sim card reader Message-ID: hello , anyone have schematic design sim reader PC/SC , yesterday i'm make some reader but not support with PC/SC apps in here (http://git.osmocom.org/osmo-sim-auth | A smart card reader compatible with pcsc-lite) i think my card support with phoenix reader? and anyone can explain the differences between the PC / SC with phoenix sim reader or etc Regards From tom at zwizwa.be Thu Jul 25 21:37:35 2013 From: tom at zwizwa.be (Tom Schouten) Date: Thu, 25 Jul 2013 17:37:35 -0400 Subject: ask about design sim card reader In-Reply-To: References: Message-ID: <51F19A9F.7050908@zwizwa.be> On 07/25/2013 02:52 PM, anak galer wrote: > hello , > > anyone have schematic design sim reader PC/SC , yesterday i'm make > some reader but not support with PC/SC apps in here > (http://git.osmocom.org/osmo-sim-auth | A smart card reader compatible > with pcsc-lite) i think my card support with phoenix reader? and > anyone can explain the differences between the PC / SC with phoenix > sim reader or etc > > Regards > > the SIMtrace schematic can serve as inspiration. just discard the UART1 PHONE interface. http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Hardware/simtrace_v12_schematic.pdf there is experimental CCID firmware for SIMtrace which works with pcsc-lite see the "SIMtrace MITM/emulator" thread in general if your card reader does not support the CCID USB standard, you are out of luck unless the vendor provides a specific non-CCID driver as a plugin for pcsc-lite. here's a list of CCID devices: http://pcsclite.alioth.debian.org/ccid/supported.html From tom at zwizwa.be Fri Jul 26 20:55:32 2013 From: tom at zwizwa.be (Tom Schouten) Date: Fri, 26 Jul 2013 16:55:32 -0400 Subject: SIMtrace phone-side VCC Message-ID: <51F2E244.7010707@zwizwa.be> Hi folks, Seems not all phones use 3V signaling if the PHONE-side VCC pin is tied to 3V. This one insists on 1.8V : BLU SAMBA JR PLUS Is this trick of tying VCC to 3V standard behavior? For future version of the board, it might be interesting to tie the VCC pin to an ADC input, to detect different voltage levels so the firmware can wait until phone decides to use 3V. Cheers Tom From ml at mail.tsaitgaist.info Fri Jul 26 21:05:57 2013 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Fri, 26 Jul 2013 23:05:57 +0200 Subject: SIMtrace phone-side VCC In-Reply-To: <51F2E244.7010707@zwizwa.be> References: <51F2E244.7010707@zwizwa.be> Message-ID: <1374872611-sup-2133@dennou> Excerpts from Tom Schouten's message of 2013-07-26 22:55:32 +0200: > Hi folks, > > Seems not all phones use 3V signaling if the PHONE-side VCC pin is tied > to 3V. > This one insists on 1.8V : BLU SAMBA JR PLUS how does the phone behave? > > Is this trick of tying VCC to 3V standard behavior? no, it is not standard. It just works (most of the time). And it should not damage the SIM nor the phone. > > For future version of the board, it might be interesting to tie the VCC > pin to an ADC input, to detect different voltage levels so the firmware > can wait until phone decides to use 3V. > this will be done in the next board > Cheers > Tom From tom at zwizwa.be Fri Jul 26 21:19:29 2013 From: tom at zwizwa.be (Tom Schouten) Date: Fri, 26 Jul 2013 17:19:29 -0400 Subject: SIMtrace phone-side VCC In-Reply-To: <1374872611-sup-2133@dennou> References: <51F2E244.7010707@zwizwa.be> <1374872611-sup-2133@dennou> Message-ID: <51F2E7E1.8050405@zwizwa.be> On 07/26/2013 05:05 PM, Kevin Redon wrote: > Excerpts from Tom Schouten's message of 2013-07-26 22:55:32 +0200: >> Hi folks, >> >> Seems not all phones use 3V signaling if the PHONE-side VCC pin is tied >> to 3V. >> This one insists on 1.8V : BLU SAMBA JR PLUS > how does the phone behave? if the at91 doesn't respond, the phone goes through the following power/reset sequence, about 1 second apart: 1.8V 3V 3V 1.8V the at91 seems to mostly interpret the 1.8V serial line correctly, so the phone just starts talking at 1.8V until this eventually goes wrong. > >> Is this trick of tying VCC to 3V standard behavior? > no, it is not standard. It just works (most of the time). > And it should not damage the SIM nor the phone. > >> For future version of the board, it might be interesting to tie the VCC >> pin to an ADC input, to detect different voltage levels so the firmware >> can wait until phone decides to use 3V. >> > this will be done in the next board > good ( next to some GPIOs maybe ;) From laforge at gnumonks.org Sat Jul 27 01:23:48 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 27 Jul 2013 09:23:48 +0800 Subject: SIMtrace phone-side VCC In-Reply-To: <51F2E244.7010707@zwizwa.be> References: <51F2E244.7010707@zwizwa.be> Message-ID: <20130727012348.GC5967@nataraja.gnumonks.org> Hi Tom, On Fri, Jul 26, 2013 at 04:55:32PM -0400, Tom Schouten wrote: > For future version of the board, it might be interesting to tie the > VCC pin to an ADC input, to detect different voltage levels so the > firmware can wait until phone decides to use 3V. this is more or less what we intended to do from the beginning, but somehow there was an error in the schematic so we had to resort on this. If I remember correctly off my head the story goes like this: So the original idea was to always forward the same VCC voltage from the phone to the sim card by means of a switch, and alternatively provide the SIM-side VCC with voltage from a regulator. However, as both the regolator output and the forward-switch output were connected together, and the regulator could not deal with voltage beping present at its output while being disabled, the circuit never worked as expected. We didn't touch the simtrace v1.x hardware for a long time, as Kevin started work on a completely different v2.x hardware years ago. However, due to lack of time and other projects, this never really emerged beyond the early design phase (as far as I know). If I was to do an updated version of simtrace, I would also move to an at91sam3s instead of the at91sam7s, as the former has more USB endpoints enabling the CCID + CDC-ACM simultaneous operation for the MITM mode. 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 tom at zwizwa.be Tue Jul 30 18:15:55 2013 From: tom at zwizwa.be (Tom Schouten) Date: Tue, 30 Jul 2013 14:15:55 -0400 Subject: SIMtrace phone-side VCC In-Reply-To: <51F2E7E1.8050405@zwizwa.be> References: <51F2E244.7010707@zwizwa.be> <1374872611-sup-2133@dennou> <51F2E7E1.8050405@zwizwa.be> Message-ID: <51F802DB.8010200@zwizwa.be> for the MITM, there seem to be a couple of variables to play with (as compared to passive sniffing) that make it a little more reliable: - wait for X number of power cycles, i.e. don't send ATR until the 3V3 one comes up - manipulate ATR: it seems possible to set the voltage class explicitly The power-wait works for the BLU phone I mentioned, and the Nexus One. N1 also starts out with a different voltage (about 2.3V, weird..)