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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

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"<laforge@gnumonks.org> Komu: Tom Schouten<tom@zwizwa.be> 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

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.

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

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

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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

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

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

Tom Schouten wrote:

...

...

...

Another method would be type=vendor recipient=device control requests over the default endpoint.

Well... I tried this for the CDC and I get "Device or resource busy".

What did you try exactly?

It doesn't work if the device is already opened by another process or a kernel driver.

There is always a kernel driver for every single interface, also when using libusb. It is just a different kernel driver. It is not possible to communicate with a USB device without a kernel driver, also using libusb. "open the device" is not really a significant concept with USB, it is much more important what happens with individual interfaces. libccid uses libusb to claim the CCID interface, but that is distinct from the default endpoint.

It seems plausible a USB device can only be opened once,

That's not the case however.

so you're can you elaborate on what you are referring to by "it works well everywhere" wrt "already bound by another driver" ?

Please describe what you've done in more detail instead. //Peter

Tom Schouten wrote:

dh = dev.open()

This opens the device.

dh.claimInterface(0) # -> usb.USBError: could not claim interface 0: Device or resource busy

This tries to claim the interface which is already claimed by usb-serial.

dh.controlMsg(1,1,[0,0,0,0])

This performs a control request over the default endpoint, which doesn't belong to any interface at all.

...

...

It seems plausible a USB device can only be opened once,

That's not the case however.

I see. I'm confusing device and interface.

Yes.

So basically, I would add another interface to the USB firmware, which then can be claimed by a different process.

You can do control requests without having claimed any interface. If you add an interface then it might actually work on Windows too, but I'm not sure. //Peter

On 08/09/2013 09:59 AM, Tom Schouten wrote:

On 08/09/2013 09:06 AM, Peter Stuge wrote:

...

...

So basically, I would add another interface to the USB firmware, which then can be claimed by a different process. You can do control requests without having claimed any interface.

This seems to be the case only if an interface on the device is not claimed already.

dev = find(idVendor=0x03eb, idProduct=0x6129) dh = dev.open() dh.controlMsg(1,1,[0,0,0,0]) # no error when CCID interface is not claimed, busy otherwise

ha! it depends on bmRequestType (9.3.1 in usb11.pdf) a VENDOR request (bmRequestType = 0xC0) does make it through to the firmware, while STANDARD requests seem to be limited. so to make it work on windows, I guess these then should be INTERFACE instead of DEVICE requests?

Tom Schouten wrote:

USB vendor control requests draft works - previous was all PEBKAC.

Glad to hear that!

Peter, thanks for the idea!

You're welcome. Thanks for working on it! //Peter