This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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 at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)