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)