21 May
2012
21 May
'12
6:42 p.m.
Hi all!
Kevin has done a wonderful job of creating a tool for collaborative
collection of TERMINAL PROFILE data of mobile phones. See:
https://geekblog.kevredon.org/?p=592
https://terminal-profile.osmocom.org/
I'm looking forward to see contributions by all SIMtrace owners. After
all, you no longer need to be a programmer to contribute now. All you
need is a SIMtrace and a couple of phones, which is probably true for
most people on this list.
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)
21 May
21 May
6:53 p.m.
Hey Harald,
nice project ;) thumbs up for Kevin too of course.
Having that, I wanted to ask, do you see a possibility of kind-of
man-in-the-middle with Simtrace?
As it would be nice to test these various scenarios on different phones
we'd need to inject these commands into the communication between the phone
and the sim.
Honestly, I'm not quite sure how this is (not) going to be working
according to the standard and if sneaking in a command wouldn't break the
communication.
Maybe it's a better idea to get all the files from the sim (the ones
readable with PIN should be enough, like IMSI and the ones in TS 11.11),
start-up kind of a simulator of the sim filesystem and only let the RUN
GSM ALGO APDU to go through to the SIM and handle the rest by the
simulator. Using something like that, it sounds easier to inject some
Proactive Commands and similar.
I'd like to know your opinion, as I'm not so deeply familiar with the
low-level stuff (ISO-7816).
Thanks!
Cheers,
Lukas
On Mon, May 21, 2012 at 6:42 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi all!
Kevin has done a wonderful job of creating a tool for collaborative
collection of TERMINAL PROFILE data of mobile phones. See:
https://geekblog.kevredon.org/?p=592
https://terminal-profile.osmocom.org/
I'm looking forward to see contributions by all SIMtrace owners. After
all, you no longer need to be a programmer to contribute now. All you
need is a SIMtrace and a couple of phones, which is probably true for
most people on this list.
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)
7:02 p.m.
On Mon, May 21, 2012 at 06:53:41PM +0200, Lukas Kuzmiak wrote:
Having that, I wanted to ask, do you see a possibility
of kind-of
man-in-the-middle with Simtrace?
yes, the hardware was specifically designed the way to support it.
The main issue is that the respective software (mostly SIMtrace
firmware) hasn't been written yet. It's a couple of days work, but I
myself honestly don't think I'll find much time for it, given the
variety of other projecets like the COS for the CC32RS512, OsmoSDR,
sysmoBTS and many others.
Honestly, I'm not quite sure how this is (not)
going to be working
according to the standard and if sneaking in a command wouldn't break the
communication.
Maybe it's a better idea to get all the files from the sim (the ones
readable with PIN should be enough, like IMSI and the ones in TS 11.11),
start-up kind of a simulator of the sim filesystem and only let the RUN
GSM ALGO APDU to go through to the SIM and handle the rest by the
simulator. Using something like that, it sounds easier to inject some
Proactive Commands and similar.
both approaches are definitely doable. The second one would probably be
easier, as you could reuse e.g. the softsim of Kevin/Nico and simply run
the SIMtrace hardware in "ISO7816 slave" mode. Only once you get a RUN
GSM ALGORITHM, you pass that throguh to the card.
USB-wise, I would suggest to make the SIM-facing side visible as USB
CCID card reader (using libccid / pcsc-lite). The phone-facing side
would be a custom protocol that could be encapsulated in
CCID PC_to_RDR_Escape and RDR_to_PC_Escape messages of CCID.
In the ideal world we would have a multi-function USB device exporting
separat interfaces for this, but the sam7s only supports 4 USB endpoints
and thus we have to somehow tunnel the "card simulation" part through
those Escape commands of the CCID profile.
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)
8:16 p.m.
Harald Welte wrote:
In the ideal world we would have a multi-function USB
device exporting
separat interfaces for this, but the sam7s only supports 4 USB endpoints
and thus we have to somehow tunnel the "card simulation" part through
those Escape commands of the CCID profile.
It's also possible to use vendor-specific control transfers
independently of the interface.
//Peter
10:30 p.m.
Hi Peter,
On Mon, May 21, 2012 at 08:16:08PM +0200, Peter Stuge wrote:
Harald Welte wrote:
yes, but I think the size of the endpoint and the overall nature of
control transfers might not be the best solution, in terms of transfer
speed.
--
- 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)
In the ideal world we would have a multi-function
USB device exporting
separat interfaces for this, but the sam7s only supports 4 USB endpoints
and thus we have to somehow tunnel the "card simulation" part through
those Escape commands of the CCID profile.
It's also possible to use vendor-specific control transfers
independently of the interface.
4366
days inactive
4366
days old
4 comments
3 participants
participants (3)
-
Harald Welte -
Lukas Kuzmiak -
Peter Stuge