From ZaytsevAA at ircoc.vrn.ru Wed Apr 6 14:45:29 2011 From: ZaytsevAA at ircoc.vrn.ru (=?UTF-8?B?0JfQsNC50YbQtdCyINCQ0L3QtNGA0LXQuQ==?=) Date: Wed, 06 Apr 2011 18:45:29 +0400 Subject: neighboring cells information Message-ID: <4D9C7C89.7060308@ircoc.vrn.ru> Hello and sorry for my english. Please help me. I need to decode the message D-NWRK-BROADCAST (chapter 18.4.1.4.1 from ETSI EN 300 392-2 V2.3.2). The fact is that I want to receive information of neighboring cells, but do not know how to do it. Standard called following about this message: ?Upon receipt from the SwMI, the message shall inform the MS-MLE about parameters for the serving cell?? How to modify the source code in order to decode this message. Thank you. With best regards Zaytcev Andrey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Apr 6 15:59:52 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 06 Apr 2011 17:59:52 +0200 Subject: neighboring cells information In-Reply-To: <4D9C7C89.7060308@ircoc.vrn.ru> References: <4D9C7C89.7060308@ircoc.vrn.ru> Message-ID: <4D9C8DF8.90801@freyther.de> On 04/06/2011 04:45 PM, ?????? ?????? wrote: > Hello and sorry for my english. Please help me. I need to decode > the message D-NWRK-BROADCAST (chapter 18.4.1.4.1 from ETSI EN 300 392-2 > V2.3.2). The fact is that I want to receive information of neighboring cells, > but do not know how to do it. Standard called following about this message: > ?Upon receipt from the SwMI, the message shall inform the MS-MLE about > parameters for the serving cell?? How to modify the source code in order to > decode this message. Thank you. Do you have a pcap file containing this message? Did you check if wireshark with tetra support is capable of decoding this? From ZaytsevAA at ircoc.vrn.ru Wed Apr 6 16:29:17 2011 From: ZaytsevAA at ircoc.vrn.ru (=?UTF-8?B?0JfQsNC50YbQtdCyINCQ0L3QtNGA0LXQuQ==?=) Date: Wed, 06 Apr 2011 20:29:17 +0400 Subject: neighboring cells information In-Reply-To: <4D9C8DF8.90801@freyther.de> References: <4D9C7C89.7060308@ircoc.vrn.ru> <4D9C8DF8.90801@freyther.de> Message-ID: <4D9C94DD.3050508@ircoc.vrn.ru> 06.04.2011 19:59, Holger Hans Peter Freyther ?????: > On 04/06/2011 04:45 PM, ?????? ?????? wrote: > >> Hello and sorry for my english. Please help me. I need to decode >> the message D-NWRK-BROADCAST (chapter 18.4.1.4.1 from ETSI EN 300 392-2 >> V2.3.2). The fact is that I want to receive information of neighboring cells, >> but do not know how to do it. Standard called following about this message: >> ?Upon receipt from the SwMI, the message shall inform the MS-MLE about >> parameters for the serving cell?? How to modify the source code in order to >> decode this message. Thank you. >> > Do you have a pcap file containing this message? Did you check if wireshark > with tetra support is capable of decoding this? > > > I have no pcap file and i didn`t check in wireshark. I have a file with time sampling, i demodulated it and got the unpacked bits. Then I processed the bit stream with Receiver Program form this http://tetra.osmocom.org/trac/wiki/WikiStart#MailingList. But I exactly assured that there is the message D-NWRK-BROADCAST in the bit stream. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Apr 6 16:41:13 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 06 Apr 2011 18:41:13 +0200 Subject: neighboring cells information In-Reply-To: <4D9C94DD.3050508@ircoc.vrn.ru> References: <4D9C7C89.7060308@ircoc.vrn.ru> <4D9C8DF8.90801@freyther.de> <4D9C94DD.3050508@ircoc.vrn.ru> Message-ID: <4D9C97A9.7070608@freyther.de> On 04/06/2011 06:29 PM, ?????? ?????? wrote: > I have no pcap file and i didn`t check in wireshark. I have a file with time > sampling, i demodulated it and got the unpacked bits. Then I processed the bit > stream with Receiver Program form > thishttp://tetra.osmocom.org/trac/wiki/WikiStart#MailingList. But I exactly > assured that there is the message D-NWRK-BROADCASTin the bit stream. You can ask the decoding program to send messages to the GSMTAP port, you can use tcpdump to record a trace and then look at it with wireshark (1.5.x from svn). The people of the Beijing-Institute-of-Technology were so kind to donate their dissector. This link[1] points to the ASN1 file for the messages, it also provides the D-NWRK-BRDCAST sequence (if you refer for that one). [1] http://anonsvn.wireshark.org/viewvc/trunk/asn1/tetra/tetra.asn?revision=35754&view=markup From 246tnt at gmail.com Mon Apr 18 12:19:18 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 18 Apr 2011 14:19:18 +0200 Subject: Where to store the stack "state" Message-ID: Hi, To add support for traffic extraction, it's necessary to introduce some nothing of "state" in the MAC layer (since the DL_USAGE must be 'remembered' to know how to interpret further data) ... Any suggestion how to achieve that as cleanly as possible ? Having a global doesn't sound that nice, but passing a struct around either. Maybe introduce a pointer to a 'tetra_state' in the primitive struct ? Cheers, Sylvain From mc at sandokai.eu Mon Apr 25 13:32:16 2011 From: mc at sandokai.eu (Marius Ciepluch) Date: Mon, 25 Apr 2011 13:32:16 -0000 Subject: educational samples and theoreticaly ways to get them Message-ID: Hi! My name is Marius and yesterday, though I was in a hurry to catch my train back to HL, I was in Harald's ETSI Tetra presentation. It was great; and I do have a USRP2, portable power supply, a sailing license (there're these big coast-guard towers here). Any implications are theoretically of course at this point. Just a small question: can one expect legal trouble if... accidently though... some Tetra signals found their way into a GR cfile onto some web server and would be shared (here)? Afaik it's not excactly ISM band. And to the second question: what was the name of the recommendable book, that was not marketing foo? I'd like to give the cryptanalysis a try, but before I can say that I have to look at the standards and algorithms. Did anyone already review that? I know that Stephen Glass of the OP25 project did some research on APCO 25. - Which isn't ETSI. Best, Marius -- pgp id: 0xCCCA5E74, mc - at - sandokai.eu http://crazylazy.info/blog, twitter: @wishinet From 246tnt at gmail.com Mon Apr 25 14:03:12 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 25 Apr 2011 16:03:12 +0200 Subject: educational samples and theoreticaly ways to get them In-Reply-To: References: Message-ID: Hi, > Just a small question: can one expect legal trouble if... accidently > though... some Tetra signals found their way into a GR cfile onto some web > server and would be shared (here)? Depends on your local laws. And on the content of the trace as well probably. If there is only broadcast info, I don't think that's a problem. If OTOH there is some cleartext traffic then it probably violates some privacy intrusion law. And if it's not private but law enforcement, then other laws probably supercedes the 'normal' case ... (IANAL,statements based on my understanding of Belgian law which may not be applicable) > I'd like to give the cryptanalysis a try, but > before I can say that I have to look at the standards and algorithms. Did you miss the part about the algorithm being secret and never leaked ? We have no idea what TEA{1,2,3,4} are so there is no public analysis of them ... Cheers, Sylvain Munaut From mc at sandokai.eu Mon Apr 25 14:12:59 2011 From: mc at sandokai.eu (Marius Ciepluch) Date: Mon, 25 Apr 2011 14:12:59 -0000 Subject: educational samples and theoreticaly ways to get them In-Reply-To: References: Message-ID: <472f8b89a3c3b56f6ea4843b8e98098d.squirrel@crazylazy.info> On Mon, April 25, 2011 2:03 pm, Sylvain Munaut wrote: > Hi, > >> Just a small question: can one expect legal trouble if... accidently >> though... some Tetra signals found their way into a GR cfile onto some >> web >> server and would be shared (here)? > If there is only broadcast info, I don't think that's a problem. If > OTOH there is some cleartext traffic then it probably violates some > privacy intrusion law. My question was more related to the listening freqs. I don't have any interest on priviate contents. And furthermore these can be deleted. > Did you miss the part about the algorithm being secret and never leaked ? > > We have no idea what TEA{1,2,3,4} are so there is no public analysis of > them ... > Nope I didn't miss that. Chosen Ciphertext or Known Plaintext attacks might still proof some valueable points. Actually otherwise this would be less interesting. Best, Marius -- pgp id: 0xCCCA5E74, mc - at - sandokai.eu http://crazylazy.info/blog, twitter: @wishinet From 246tnt at gmail.com Mon Apr 25 14:23:03 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Mon, 25 Apr 2011 14:23:03 +0000 Subject: educational samples and theoreticaly ways to get them In-Reply-To: <472f8b89a3c3b56f6ea4843b8e98098d.squirrel@crazylazy.info> Message-ID: <20cf3054a18707838104a1bef284@google.com> > Nope I didn't miss that. Chosen Ciphertext or Known Plaintext attacks > might still proof some valueable points. Actually otherwise this would be > less interesting. Well, yeah but how would you get chosen / known plaintext ? You can't really buy equipment that has TEA support in theory, its distribution is limited. Finding TETRA stuff is already not trivial, but finding some that has TEA is even harder. It's sometime possible to find just the FW files from some "shady connections", but it's unclear if they'd work or if they depend on some HW feature and at > 200 eur per handset not many people are ready to risk bricking them for experiments :p And even then you often don't control enough to know / choose what it sends. Definitely quite a challenge :) But yeah can be fun if you can afford it. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From spaar at mirider.augusta.de Mon Apr 25 16:48:48 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 25 Apr 2011 16:48:48 CEST Subject: educational samples and theoreticaly ways to get them Message-ID: <4db5a5f0.mirider@mirider.augusta.de> Hello Sylvain, On Mon, 25 Apr 2011 14:23:03 +0000, 246tnt at gmail.com wrote: > > It's sometime possible to find just the FW files from some "shady > connections", but it's unclear if they'd work or if they depend on some HW > feature and at > 200 eur per handset not many people are ready to risk > bricking them for experiments :p You can buy handsets with TEA on ebay, you can even buy TEA firmware files for certain handsets on ebay (TEA1, TEA2 and TEA3) are available. I don't know if selling the firmware files is perfectly legal and I don't want to discuss this. But having a handset with TEA firmware does not help much, at least not for Motorola handsets. The reason is that there seems to be no obvious way to put know keys into the handset. From what I heared there seems to exist some sort of obfuscated/encrypted key file which can transfer keys to a handset but I never seen one of those files. If anyone knows more details and/or has a key file with know keys, please let me know. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Tue Apr 26 09:13:38 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 26 Apr 2011 11:13:38 +0200 Subject: legal questions (was Re: educational samples and theoreticaly ways to get them) In-Reply-To: References: Message-ID: <20110426091338.GH3031@prithivi.gnumonks.org> Hi Marius, On Mon, Apr 25, 2011 at 01:32:16PM -0000, Marius Ciepluch wrote: > Just a small question: can one expect legal trouble if... accidently > though... some Tetra signals found their way into a GR cfile onto some web > server and would be shared (here)? Afaik it's not excactly ISM band. This is highly dependent on your jurisdiction and its local laws. We at the OsmocomTETRA project provide only software and no actual communications traces. In Germany I can think of some legal issues related to this, mostly Paragraph 89 Telekommunikationsgesetz: =============== ? 89 Abh?rverbot, Geheimhaltungspflicht der Betreiber von Empfangsanlagen Mit einer Funkanlage d?rfen nur Nachrichten, die f?r den Betreiber der Funkanlage, Funkamateure im Sinne des Gesetzes ?ber den Amateurfunk vom 23. Juni 1997 (BGBl. I S. 1494), die Allgemeinheit oder einen unbestimmten Personenkreis bestimmt sind, abgeh?rt werden. Der Inhalt anderer als in Satz 1 genannter Nachrichten sowie die Tatsache ihres Empfangs d?rfen, auch wenn der Empfang unbeabsichtigt geschieht, auch von Personen, f?r die eine Pflicht zur Geheimhaltung nicht schon nach ? 88 besteht, anderen nicht mitgeteilt werden. ? 88 Abs. 4 gilt entsprechend. Das Abh?ren und die Weitergabe von Nachrichten auf Grund besonderer gesetzlicher Erm?chtigung bleiben unber?hrt. =============== So generally you are not allowed to receive communication that is not destined/intended for * the operator of the radio receiver, or * a licensed radio amateur, or * the general public, or * an undefined group of people (i.e. not destined for anyone in particular) Even if you unintentionally receive such messages, you are not permitted to tell other people of the content of those messages - not even the fact that you have received them. Interesting in connection with this is also ? 206 StGB: =============== ? 206 Verletzung des Post- oder Fernmeldegeheimnisses (1) Wer unbefugt einer anderen Person eine Mitteilung ?ber Tatsachen macht, die dem Post- oder Fernmeldegeheimnis unterliegen und die ihm als Inhaber oder Besch?ftigtem eines Unternehmens bekanntgeworden sind, das gesch?ftsm??ig Post- oder Telekommunikationsdienste erbringt, wird mit Freiheitsstrafe bis zu f?nf Jahren oder mit Geldstrafe bestraft. (2) Ebenso wird bestraft, wer als Inhaber oder Besch?ftigter eines in Absatz 1 bezeichneten Unternehmens unbefugt 1. eine Sendung, die einem solchen Unternehmen zur ?bermittlung anvertraut worden und verschlossen ist, ?ffnet oder sich von ihrem Inhalt ohne ?ffnung des Verschlusses unter Anwendung technischer Mittel Kenntnis verschafft, 2. eine einem solchen Unternehmen zur ?bermittlung anvertraute Sendung unterdr?ckt oder 3. eine der in Absatz 1 oder in Nummer 1 oder 2 bezeichneten Handlungen gestattet oder f?rdert. (3) Die Abs?tze 1 und 2 gelten auch f?r Personen, die 1. Aufgaben der Aufsicht ?ber ein in Absatz 1 bezeichnetes Unternehmen wahrnehmen, 2. von einem solchen Unternehmen oder mit dessen Erm?chtigung mit dem Erbringen von Post- oder Telekommunikationsdiensten betraut sind oder 3. mit der Herstellung einer dem Betrieb eines solchen Unternehmens dienenden Anlage oder mit Arbeiten daran betraut sind. (5) Dem Postgeheimnis unterliegen die n?heren Umst?nde des Postverkehrs bestimmter Personen sowie der Inhalt von Postsendungen. Dem Fernmeldegeheimnis unterliegen der Inhalt der Telekommunikation und ihre n?heren Umst?nde, insbesondere die Tatsache, ob jemand an einem Telekommunikationsvorgang beteiligt ist oder war. Das Fernmeldegeheimnis erstreckt sich auch auf die n?heren Umst?nde erfolgloser Verbindungsversuche. =============== If you read this carefully, you will note "(3) 3." which clearly extends the scope of this law to "Individuals, who are entrusted/assigned to the operation of, manufacturing of or other work with a communications device of a telecommunications operator" So to me (IANAL) tihs means: 1) accidential reception should not be a legal offence 2) sharing/relaying/publishing the content of the communication or even the fact that a communication took place is definitely a legal offence, possibly against two separate laws The most interesting question is: The laws mostly talk about communications between people. I wonder how much of it applies for communication between machines, such as the general broadcast/signalling traffic that is unrelated to an actual user-generated voice, text or packet data content. Also, what about M2M communication. I guess I will have to ask some of my lawyer friends ;) > And to the second question: what was the name of the recommendable book, > that was not marketing foo? Digital mobile communications and the TETRA system By John Dunlop, Demessie Girma, James Irvine; published by Wiley. http://books.google.com/books?printsec=frontcover&id=Kr3ori9Ify4C Sells roughly between 130 and 200 USD. The first chapters are again general marketing / high-level foobar, but after that it walks you through the air interface, the PHY layer, MAC layer, etc. -- - 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 Apr 25 13:48:46 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 25 Apr 2011 15:48:46 +0200 Subject: tetra-rx was missing the LLC layer Message-ID: <20110425134846.GE3031@prithivi.gnumonks.org> Hi! during some work over the last weekend on OsmocomTETRA and reading through many hours of real-world TETRA captures, I have realized that a lot of the data we displayed about the higher protocol layers (like MM, CMCE, ...) was completely bogus. The reason for it is simple and quite obvious: My old code made the assumption that the MLE layer is directly on top of the MAC layer - whereas in reality, there is the LLC layer in between. Not only that, but LLC also takes care of fragmentation and re-assembly, i.e. we were just printing some general nonsense. I've started to fix this in the git master banch and I have some local uncommitted code that actually implements re-assembly. I've successfully decoded some NTP/UDP/IP-in-SNDCP-over-TETRA frames from a real network, but the implementation is a big ugly hack and has many constraints. I will try to clean this up asap and commit it (maybe even later today). This posting is JFYI, so you are not surprised if you now get some completely different output with the same input data. The good part is that we actually get the CMCE messages that tell us when and where will be voice frames that belong together, i.e. we can identify start and end of indivdiual push-to-talk 'segments'. This could be a nice base for extracting them in a useful format. 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 Apr 25 13:51:41 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 25 Apr 2011 15:51:41 +0200 Subject: Where to store the stack "state" In-Reply-To: References: Message-ID: <20110425135141.GF3031@prithivi.gnumonks.org> Hi Sylvain, On Mon, Apr 18, 2011 at 02:19:18PM +0200, Sylvain Munaut wrote: > To add support for traffic extraction, it's necessary to introduce > some nothing of "state" in the MAC layer (since the DL_USAGE must be > 'remembered' to know how to interpret further data) ... > > Any suggestion how to achieve that as cleanly as possible ? > > Having a global doesn't sound that nice, but passing a struct around either. > Maybe introduce a pointer to a 'tetra_state' in the primitive struct ? I have been thinking about the same issue while working on the LLC reassembly, which obviously also needs state. I guess in the end we will have something like a global 'tetra_carrier_state' struct, which then has sub-structs for the logical channels that we see. And as I've now extended the primitive to use a msgb for storing the actual unpacked type-1 bits, I guess we could simply use something out of msgb->cb to point to the 'lchan' (in OpenBSC terminology). Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Tue Apr 26 14:43:42 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 26 Apr 2011 16:43:42 +0200 Subject: tetra-rx was missing the LLC layer In-Reply-To: <20110425134846.GE3031@prithivi.gnumonks.org> References: <20110425134846.GE3031@prithivi.gnumonks.org> Message-ID: > The good part is that we actually get the CMCE messages that tell us when and > where will be voice frames that belong together, i.e. we can identify start and > end of indivdiual push-to-talk 'segments'. ?This could be a nice base for > extracting them in a useful format. Ah nice ! I was wondering how that worked ... Currently I was just using the number in the DL_USAGE field which actually incremented at each segment here IIRC :p Cheers, Sylvain