Hi Tom, On Tue, Jul 09, 2013 at 10:58:50AM -0400, Tom Schouten wrote: 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. 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'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(a)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, 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: 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: I see. 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: 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: 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: 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(a)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: 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: I'll repeat myself: This works well everywhere except on Windows. //Peter

Tom Schouten wrote: What did you try exactly? 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. That's not the case however. Please describe what you've done in more detail instead. //Peter

Tom Schouten wrote: This opens the device. This tries to claim the interface which is already claimed by usb-serial. This performs a control request over the default endpoint, which doesn't belong to any interface at all. Yes. 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: 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: Glad to hear that! You're welcome. Thanks for working on it! //Peter