From laforge at gnumonks.org Wed May 2 10:06:04 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 2 May 2012 12:06:04 +0200 Subject: May 09, 7pm / Osmocom meeting in Berlin Message-ID: <20120502100604.GY32252@prithivi.gnumonks.org> Hi all! This is the announcement for the 3rd incarnation of our bi-weekly Osmocom Berlin meeting. May 09, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin The schedule is as follows: 19:00 Introduction / Workshop on Osmocom SIMtrace (Kevin Redon) Kevin will introduce SIM/USIM/UICC cards, present what SIMtrace is and how it works, as well as how to use it to trace communication between SIM card and phone. 20:00 Informal discussions If you are interested to show up, feel free to do so. There is no registration required. If the initial part is not interesting to you, feel free to join us later at 20:00. The meeting is free as in "free beer", despite no actual free beer being around ;) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pavius at gmail.com Thu May 17 22:47:05 2012 From: pavius at gmail.com (Eran Duchan) Date: Fri, 18 May 2012 01:47:05 +0300 Subject: 7816 implementation in SIMtrace Message-ID: Hi list, A few questions regarding the 7816 driver, while I wait for my SIMtrace board to arrive: 1) It is stated in the hardware section that the datasheet for the SAM7S does not specify working as a slave, and this is indeed the case. How did this slave implementation come about? Trial and error or is this an officially supported mode? 2) The SAM3S also has no mention of 7816 slave mode, and I noticed v2.0 of the hardware will be based on this uC. Has this been verified to work? 3) I'm trying to understand why compute_fidi_ratio() returns a multiplication of fi, di instead of division if di > 8. Didn't see anything that states this requirement in the SAM7S datasheet (table 31-5). Thanks! Eran -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri May 18 06:35:05 2012 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 May 2012 08:35:05 +0200 Subject: 7816 implementation in SIMtrace In-Reply-To: References: Message-ID: <20120518063505.GT12145@prithivi.gnumonks.org> Hi Eran, On Fri, May 18, 2012 at 01:47:05AM +0300, Eran Duchan wrote: > 1) It is stated in the hardware section that the datasheet for the SAM7S > does not specify working as a slave, and this is indeed the case. How did > this slave implementation come about? Trial and error or is this an > officially supported mode? It came about by thinking about 7816-3, carefully studying the sam7s manual, some extrapolation how the logic in the IP core might work and a small experiment with an sam7s development board in 2010. Well, if you look at 7816-3, there is really not that much difference between a master and a slave on the bit and byte level. The only real difference is who transmits when, and who generates the clock. As the Atmel USART can be clock master or slave in the non-7816 modes, it seemed probable that this is the same for the 7816 mode. Furthermore, a "passive slave" shall of course not signal any parity error to the master, as it is up to the real slave to determine that. The latter can be explicitly configured in the Atmel USART. > 2) The SAM3S also has no mention of 7816 slave mode, and I noticed v2.0 of > the hardware will be based on this uC. Has this been verified to work? Atmel is known to use the same IP cores in a lot of their chips, and the sam3s is more or less just the sam7s which replaces the arm7tdmi core with a cortex-m3. There are some other improvements like more USB endpoints, but I haven't seen any indication of changes in the USART. > 3) I'm trying to understand why compute_fidi_ratio() returns a > multiplication of fi, di instead of division if di > 8. Didn't see anything > that states this requirement in the SAM7S datasheet (table 31-5). See Table 7 if ISO 7816-3. Di > 0x8 is "divide by 1/2, 1/4, 1/8, ..." which is the same as multipliciation by the divisor. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pavius at gmail.com Fri May 18 08:38:07 2012 From: pavius at gmail.com (Eran Duchan) Date: Fri, 18 May 2012 11:38:07 +0300 Subject: 7816 implementation in SIMtrace In-Reply-To: <20120518063505.GT12145@prithivi.gnumonks.org> References: <20120518063505.GT12145@prithivi.gnumonks.org> Message-ID: Harald, Thanks for your detailed answer. > Furthermore, a "passive slave" shall of course not signal any parity > error to the master, as it is up to the real slave to determine that. > The latter can be explicitly configured in the Atmel USART. Are you hinting that parity generation will not work when configured to be a slave (i.e. external clock)? As I gathered from looking at the code and the schema SIMtrace was designed to also support MitM (though the code is mostly stubs) which would require such a feature towards the phone. > Atmel is known to use the same IP cores in a lot of their chips, and the > sam3s is more or less just the sam7s which replaces the arm7tdmi core > with a cortex-m3. ?There are some other improvements like more USB > endpoints, but I haven't seen any indication of changes in the USART. That makes sense. Has the SAM3S version been prototyped yet? Have you seen this functionality work on the SAM3S USART? > See Table 7 if ISO 7816-3. ?Di > 0x8 is "divide by 1/2, 1/4, 1/8, ..." > which is the same as multipliciation by the divisor. This is rather interesting. I am looking at ISO 7816-3_2006 and there are no such values (Table 8: Di[x] = RFU, 1, 2, 4, 8, 16, 32, 64, 12, 20, RFU, RFU, RFU, RFU, RFU, RFU). However, this source (http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-3.aspx) does show the values you speak of, but starting at Di > 0x9 (as Di[9] = RFU). Am I looking at something wrong? Thanks again! Eran From laforge at gnumonks.org Fri May 18 08:50:25 2012 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 May 2012 10:50:25 +0200 Subject: 7816 implementation in SIMtrace In-Reply-To: References: <20120518063505.GT12145@prithivi.gnumonks.org> Message-ID: <20120518085025.GW12145@prithivi.gnumonks.org> On Fri, May 18, 2012 at 11:38:07AM +0300, Eran Duchan wrote: > Harald, > > Thanks for your detailed answer. > > > Furthermore, a "passive slave" shall of course not signal any parity > > error to the master, as it is up to the real slave to determine that. > > The latter can be explicitly configured in the Atmel USART. > > Are you hinting that parity generation will not work when configured > to be a slave (i.e. external clock)? No. Please read the data sheet. In ISO7816 mode you can explicitly switch that on or off. I guess they put that in for T=1 support. Also, it was my mistake, it is not parity that you're switching, but the explicit nack in the waiting time after a character. > > Atmel is known to use the same IP cores in a lot of their chips, and the > > sam3s is more or less just the sam7s which replaces the arm7tdmi core > > with a cortex-m3. ?There are some other improvements like more USB > > endpoints, but I haven't seen any indication of changes in the USART. > > That makes sense. Has the SAM3S version been prototyped yet? Have you > seen this functionality work on the SAM3S USART? no. They are pin-compatible, so it should be easy to re-work one board with hot air. The bigger differences are in the software (arm vs. thumb2, exception vectors, ...). I think zecke had done some work here in the past, but I'm not sure of the status. > > See Table 7 if ISO 7816-3. ?Di > 0x8 is "divide by 1/2, 1/4, 1/8, ..." > > which is the same as multipliciation by the divisor. > > This is rather interesting. I am looking at ISO 7816-3_2006 and there > are no such values (Table 8: Di[x] = RFU, 1, 2, 4, 8, 16, 32, 64, 12, > 20, RFU, RFU, RFU, RFU, RFU, RFU). I have a paper version of th original spec from 1989, and there it clearly is stated. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pavius at gmail.com Fri May 18 08:57:09 2012 From: pavius at gmail.com (Eran Duchan) Date: Fri, 18 May 2012 11:57:09 +0300 Subject: 7816 implementation in SIMtrace In-Reply-To: <20120518085025.GW12145@prithivi.gnumonks.org> References: <20120518063505.GT12145@prithivi.gnumonks.org> <20120518085025.GW12145@prithivi.gnumonks.org> Message-ID: All is clear :) Thanks! Eran On Fri, May 18, 2012 at 11:50 AM, Harald Welte wrote: > On Fri, May 18, 2012 at 11:38:07AM +0300, Eran Duchan wrote: >> Harald, >> >> Thanks for your detailed answer. >> >> > Furthermore, a "passive slave" shall of course not signal any parity >> > error to the master, as it is up to the real slave to determine that. >> > The latter can be explicitly configured in the Atmel USART. >> >> Are you hinting that parity generation will not work when configured >> to be a slave (i.e. external clock)? > > No. Please read the data sheet. ?In ISO7816 mode you can explicitly > switch that on or off. ?I guess they put that in for T=1 support. ?Also, > it was my mistake, it is not parity that you're switching, but the > explicit nack in the waiting time after a character. > >> > Atmel is known to use the same IP cores in a lot of their chips, and the >> > sam3s is more or less just the sam7s which replaces the arm7tdmi core >> > with a cortex-m3. ?There are some other improvements like more USB >> > endpoints, but I haven't seen any indication of changes in the USART. >> >> That makes sense. Has the SAM3S version been prototyped yet? Have you >> seen this functionality work on the SAM3S USART? > > no. ?They are pin-compatible, so it should be easy to re-work one board > with hot air. ?The bigger differences are in the software (arm vs. > thumb2, exception vectors, ...). ?I think zecke had done some work here > in the past, but I'm not sure of the status. > >> > See Table 7 if ISO 7816-3. ?Di > 0x8 is "divide by 1/2, 1/4, 1/8, ..." >> > which is the same as multipliciation by the divisor. >> >> This is rather interesting. I am looking at ISO 7816-3_2006 and there >> are no such values (Table 8: Di[x] = RFU, 1, 2, 4, 8, 16, 32, 64, 12, >> 20, RFU, RFU, RFU, RFU, RFU, RFU). > > I have a paper version of th original spec from 1989, and there it > clearly is stated. > > Regards, > ? ? ? ?Harald > -- > - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri May 18 19:54:56 2012 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 May 2012 21:54:56 +0200 Subject: FIXED: ATR + first APDU in one message Message-ID: <20120518195456.GP14128@prithivi.gnumonks.org> Hi! FYI: the last git commit (6ea973b79ef8f53a250313f34218680a7b5fb1b4) in the firmware directory has fixed the problem that for certain cards, the first APDU was transmitted together with the ATR in the first GSMTAP message. I am currently trying to fix some other bugs (particularly the known issue regarding high-speed cards) and will make a v0.6 firmware release once that is done. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon May 21 16:42:32 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 May 2012 18:42:32 +0200 Subject: Collaborative database of TERMINAL PROFILE Message-ID: <20120521164232.GP19343@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lukash at backstep.net Mon May 21 16:53:41 2012 From: lukash at backstep.net (Lukas Kuzmiak) Date: Mon, 21 May 2012 18:53:41 +0200 Subject: Collaborative database of TERMINAL PROFILE In-Reply-To: <20120521164232.GP19343@prithivi.gnumonks.org> References: <20120521164232.GP19343@prithivi.gnumonks.org> Message-ID: 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 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 > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon May 21 17:02:56 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 May 2012 19:02:56 +0200 Subject: Collaborative database of TERMINAL PROFILE In-Reply-To: References: <20120521164232.GP19343@prithivi.gnumonks.org> Message-ID: <20120521170256.GR19343@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Mon May 21 18:16:08 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 21 May 2012 20:16:08 +0200 Subject: Collaborative database of TERMINAL PROFILE In-Reply-To: <20120521170256.GR19343@prithivi.gnumonks.org> References: <20120521164232.GP19343@prithivi.gnumonks.org> <20120521170256.GR19343@prithivi.gnumonks.org> Message-ID: <20120521181608.5477.qmail@stuge.se> 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 From laforge at gnumonks.org Mon May 21 20:30:05 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 May 2012 22:30:05 +0200 Subject: Collaborative database of TERMINAL PROFILE In-Reply-To: <20120521181608.5477.qmail@stuge.se> References: <20120521164232.GP19343@prithivi.gnumonks.org> <20120521170256.GR19343@prithivi.gnumonks.org> <20120521181608.5477.qmail@stuge.se> Message-ID: <20120521203005.GX19343@prithivi.gnumonks.org> Hi Peter, On Mon, May 21, 2012 at 08:16:08PM +0200, Peter Stuge wrote: > 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. 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed May 23 07:46:13 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 May 2012 09:46:13 +0200 Subject: TODAY: May 23, 7pm / Osmocom meeting in Berlin Message-ID: <20120523074613.GX19343@prithivi.gnumonks.org> Hi all! This is the announcement for the 4th incarnation of our bi-weekly Osmocom Berlin meeting. May 23, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no particular schedule for now, but if there is interest we can do an introduction + demo of the new sysmoBTS. Also, I'll have my SIMtrace with me, to read out TERMINAL PROFILE from phones for https://terminal-profile.osmocom.org/ . So if you have any phones to read out: Please bring them (with charged battery or charger!) So we'll just meet + talk. There seem to be some SMSC related questions that we would want to adress, so you have been warned ;) If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around ;) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)