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
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
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
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
______________________________________________________________
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).
Best regards VLP
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 Schoutentom@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
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
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.
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@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 = .;
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 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
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
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
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
Hi Harald,
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.
Just to make sure: when you last left the CCID firmware, was it working? Were you able to read a SIM card with pcsclite / libccid ?
I found at least one bug that makes me think something changed in libccid after you had it work (see other post about two kinds of status messages being confused: CCID spec 6.3.1 and 4.2.1)
Cheers, Tom
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
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.
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
On 07/17/2013 08:37 AM, Peter Stuge wrote:
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.
Well... I tried this for the CDC and I get "Device or resource busy". It doesn't work if the device is already opened by another process or a kernel driver.
It seems plausible a USB device can only be opened once, so you're can you elaborate on what you are referring to by "it works well everywhere" wrt "already bound by another driver" ?
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
On 08/09/2013 02:59 AM, Peter Stuge wrote:
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?
# using pyusb 0.x # this is running while CDC is claimed by usb-serial
import usb
def find(idVendor, idProduct): busses = usb.busses() for bus in busses: devices = bus.devices for dev in devices: if ((dev.idVendor == idVendor) and (dev.idProduct == idProduct)): return dev return 'wrong'
dev = find(idVendor=0x03eb, idProduct=0x6119) dh = dev.open() # dh.detachKernelDriver(0) dh.claimInterface(0) # -> usb.USBError: could not claim interface 0: Device or resource busy dh.controlMsg(1,1,[0,0,0,0])
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.
I see. I'm confusing device and interface.
So basically, I would add another interface to the USB firmware, which then can be claimed by a different process. Since all control transfers use the default endpoint, this won't need extra endpoints which we don't have.
Neat. Thanks!
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: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
If you add an interface then it might actually work on Windows too, but I'm not sure.
Harald had already added extra DFU interfaces to the CCID code, so I can have a look at how that works.
//Peter
Tom
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?
USB vendor control requests draft works - previous was all PEBKAC. Peter, thanks for the idea!
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
-
Harald Welte -
Kevin Redon -
Peter Stuge -
Tom Schouten -
Vlastimil Páviček