Wireshark packet dissector for GSM 12.21 (A-bis OML)

During the last weeks I've been spending some time to start a wireshark dissector plugin for GSM 12.21, which is the Organization and Maintenance protocol between BSC and BTS. Using this protocol, many aspects of a BTS are configured by the BSC.

I have already implemented the BSC side of 12.21 inside OpenBSC, and OpenBSC contains parsing code and debug logs about what is happening on this protocol. However, I think it is much better to remove most of that debug printing code from OpenBSC and move it into wireshark. Whoever needs per-message debugging, can start wireshark and look at the output - with the advantage of extensive filtering capabilities.

The protocol is quite complex and has many different messages with each their own set of attributes. So the current work is far from being complete, but it's already at a point where it is really useful.

I've put a specific focus on implementing the vendor-specific bits for ip.access, since those are hard to figure out and much more difficult to implement for anyone who hasn't spent as many weeks looking at hexdumps from their Abis-IP protocol as me. Parsing standard 12.21 messages is easy, just read the publicly-available spec and add wireshark code for it.

In case you're interested, the plugin is available from this path in the OpenBSC git tree

GSM wardriving has started

As you can see in this picture referenced by this blog post, somebody is having real fun using the BS-11 and OpenBSC for GSM wardriving.

Please note that the BS-11 is a 200W AC powered device, so you need the entire trunk full of lead batteries and a reasonably sized UPS to provide it with power.

There are much lighter setups using a laptop and a nanoBTS, but then those setups are likely a factor 10 more expensive (and provide less RF power).

But what this all tells us: GSM wardriving has started. More security researchers are looking into GSM security than a year ago, much due to the successful growth of a community around OpenBSC. Many people are only starting with GSM and mainly using/playing with the software, the number of actual contributers to the code is still small...

On a larger scale, you can see that GSM insecurity is finally going to become a much more popular topic, with more people able to demo the various long-known issues such as lack of mutual authentication and insufficient threat models/analysis during protocol design.

OpenBSC now has an API for integration with PBX systems

In recent days, we have finally merged a series of patches from Andreas Eversberg implementing what we call the MNCC [mobile network call control] API. Using this API, it is possible to glue existing PBX or other telephony applications to OpenBSC and thus add GSM extensions to your PBX.

So far, only Linux Call Router (LCR) has been extended to use this MNCC interface. Andreas reports that he has successfully established both mobile originating and mobile terminated calls to GSM extensions of his LCR PBX.

It's great to see this kind of contribution, especially in an area which I personally am not all that interested in... I still want to focus on the actual GSM side of things and implement more features as well as work on stability, the vty/telnet configuration interface, GPRS support and the recently-announced plans for implementing an actual A interface.

Right now, other projects require more time slices, but I'm still spending quite a bit of work on integrating better SMS support, with actual store-and-forward of messages in our SQL database.

OpenBSC on its way to get funded A-interface development

There is more commercial interest in OpenBSC than I expected initially when I started the project as a 'just for fun playground for GSM hacking'. Now we have received an inquiry from a company who wants to fund the development of an actual A interface to OpenBSC. This basically means that somebody wants to hook up OpenBSC to an actual real-world MSC (Mobile Switching Center) of an actual real-world GSM network.

The A interface is the interface between the BSS (BSC + BTS) and the higher levels of the telephony network. The interface is based on SS7 and lives on top of SCCP. There's BSSMAP, DTAP and OMAP. Both connection-less and connection- oriented modes of SCCP are required.

What this means is that OpenBSC's software architecture will shift even further towards the traditional GSM network architecture. So far, we have a "full GSM network from BSC to MSC/HLR in a box" approach. This makes it easy to implement, but is quite restrictive. You cannot route/switch calls to a different network, e.g.

The recent patches posted by Andreas Eversberg already introduce a software interface called mncc into the OpenBSC codebase. While those patches are not merged yet, they are introducing a functional split between the call-control entity on one hand, and the RR and NM as well as Abis RSL/OML functionality on the other side.

When we introduce the A interface, the functional split in the software will be driven even further. We'll first introduce an API at the traditional BSC/MSC split, and then write a BSSMAP/DTAP/OMAP protocol interface to that API.

One thing is for sure: We'll always keep the 'run everything in one box' mode around. This is still the most useful case for small-scale experimentation with GSM.

I'm definitely looking forward to see this project grow. We still have no agenda for things like GPRS/EDGE support, or any kind of handover. But then, development one step at a time is more healthy than trying to do everything at the same time.

I'm really excited to play with the A interface, and to interact with an actual MSC on a protocol level. This sort-of completes my ventures into GSM protocol land, from the Um (on-air) over A-bis to the A interface, one iteration up the network hierarchy at a time.

OpenBSC: Support for multiple BTS / ipaccess-config

Today I've been working on adding support for multiple BTS to OpenBSC. This means, using the [still uncommitted] new code, we can now connect multiple BTS and route voice calls between them. The actual data structures and the bulk of the code were already designed in that way, but the 'input driver' still had a lot of assumptions about talking only to one BTS at any given time.

This feature is currently only available for ip.access nanoBTS, as there is no special need for switching the RTP streams of the actual voice data. The BTS send that data directly between themselves. Dealing with E1/A-bis based BS-11 is slightly more difficult, since the TRAU frames with the voice data need to be

Still, even with two BTS at the same BSC, there is still no support for actual handover. So a handset is either registered to one BTS or the other. This matches a situation where you might have multiple different locations (let's say two branch offices) with one BTS in each location and the ability to make voice calls between mobile phones registered to either one of the branch office BTS's.

Actual handover between adjacent cells is not something that I'm personally interested in, so I'll probably leave this up to some contributor who finds it interesting (or a company who wants to fund me for that particular work). Right now we have more important missing features anyway (like proper SMS store-and-forward).

One other small bit that I implemented today is the ipaccess-config command line tool, serving as a tool to perform the most important initial NVRAM configuration of a new nanoBTS. You can use it to set the IP address of the primary OML Link as well as the Unit ID. From that point on, the BTS connects to the BSC and all further configuration can be done from the BSC.

Podcast about OpenBSC at Chaosradio Express

About a week ago, I had the pleasure of recording a Chaosradio Express (CRE) podcast about the OpenBSC project, as well as briefly addressing other GSM related FOSS projects such as OpenBTS and airprobe.org

As always with CRE, it was a most pleasant experience talking with the host Tim Pritlove and explaining the scope of the project as well as the overall how and why.

Unfortunately, unlike my blog (and most of its readers), the podcast is not in English language. But if you understand German and want to hear more about OpenBSC, I obviously recommend to check it out!

OpenBSC:Work in handling incoming SMS

After returning from my holidays, I've spent the last couple of days hacking on improving the SMS support of OpenBSC. In order to facilitate the intended store-and-forward model, we now store all incoming SMS in a SQL table. Things like validity period or even more esoteric things like SMS compression as per GSM 03.42 is obviously still missing. I try to get it working fist, and leave the gaps to be filled later.

Next will be the code for sending a SMS from an entry in the SQL table, and invoking that code every so often, based on timers and/or events such as a phone registering to the network.

The trickiest part here is how to handle the paging code. We could have a phone call and a SMS, or even more events that all want to page a phone at the same time. There needs to be some kind of arbitration and a queue, deciding what kind of event will first get access to the SDCCH that we have after paging succeeded.

There have also been suggestions to split the SMS processing into a separate process, much like in a traditional GSM network. Sounds reasonable to me, but I am not very familiar with the existing protocols (like UCP) and implementations (like Kannel). So I'll probably leave that as a second step, making the OpenBSC internal SMS handling optional at some later point. UCP would obviously also ease the integration with existing SMS operators (vSMSC and the like).

OpenBSC now has a Cisco/zebra/quagga style telnet interface

Since I'm currently at the BOSSA conference and thus basically on a break in my Brazil holidays, I decided I might as well get some work done and imported the zebra/quagga VTY code into OpenBSC. I used a fork of that code that I used some time ago for a never-announced (but in my public svn) 'cardshell' project.

What this means is that we now have a quite nice shell interface into OpenBSC, where you can interactively explore the data structures with commands like 'show bts 0', 'show e1_line' or 'show timeslot'. Over time, I hope we can easily add also interactive commands for [re]configuration, i.e. reconfigure the BTS on the fly, change administrative state via OML, or set TEI/timeslot configurations or the like.

Importing those bits from zebra/quagga has the advantage the we have things like a history and tab-completion without having to spend much time on it. Also, we can use the same codebase for saving/restoring the current configuration from/to a text file.

To give you an idea, it looks like this:

ideapad.de.gnumonks.org> show bts
BTS 0 is of nanobts900 type, has LAC 1, TSC 7 and 1 TRX
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Site Mgr NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Paging: FIXME pending requests, 100 free slots
  E1 Signalling Link:
    E1 Line 0, Timeslot 1, Type OML
    E1 TEI 0, SAPI 255

ideapad.de.gnumonks.org> show trx
TRX 0 of BTS 0 is on ARFCN 123
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Baseband Transceiver NM State: Oper 'RFU', Admin 0, Avail 'In test'
  E1 Signalling Link:
    E1 Line 0, Timeslot 2, Type RSL
    E1 TEI 0, SAPI 0

ideapad.de.gnumonks.org> show timeslot 0 0 0
Timeslot 0 of TRX 0 in BTS 0, phys cfg CCCH+SDCCH4
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Bound IP: 0.0.0.0 Port 0 FC=0 F8=0

OpenBSC interoperability testing

As expected, it seems that the various different GSM cellphones expose quite big differences in their behavior towards the GSM network. In part this is due to the evolving GSM standard, where features were added over time in a backward- compatible manner, so old phones still work on modern network. The biggest part is probably due to implementation differences in the GSM stack or the particular hardware drivers that glue the stack to the given digital + analog baseband circuitry in the phone.

I have started to collect a number of different phones to test them with OpenBSC, you can see my current collection here: In addition, at the Berlin CCC we also have an old 8W Siemens P1 for testing against Phase 1 GSM phones.

The old Nokia DCT3 phones seem to be the most tolerant ones when it comes to violations of the protocol. I had a number of bugs, such as using the wrong training sequence in the CHANNEL MODE MODIFY as well as ASSIGNMENT COMMAND messages, but they simply ignored it and used the TSC from the SYSTEM INFORMATION. The various Siemens and Motorola phones are way less tolerant, which is good since it enabled me to actually find the respective bug in OpenBSC.

Also, Phase1 support in OpenBSC hasn't really been there so far. We kept asking the phones for their IMEISV, and apparently Phase1 only have IMEI but no IMEISV, leading to us rejecting the LOCATION UPDATING REQUEST. This is also fixed now. The remaining Phase1 problems are:

• correctly dealing with FR (as opposed to EFR) codec
• figure out why they send a MOBILE IDENTITY TYPE 5 instead of an IMSI on establishing a mobile-originated (MO) call

OpenBSC: we now have working TCH/F voice calls

Finally, close to 5am after a long day of hacking, I was able to make the first actual voice calls through OpenBSC. This has been _much_ harder than anticipated, with bugs spread all over various places of the code (my code!) as well as some conceptual shortcomings in my understanding of how the exact interaction between GSM 12.21, 08.58 and 04.08 happens.

Initially I was working with the ip.access BTS, but was stuck and didn't see any progress so I decided to try the BS-11, since that one is at least according to spec as A-bis over E1 is publicly documented. Some six hours of problems in my E1 sub-channel multiplexer and TRAU decode/recode later, I actually had a working voice call. To my big surprise, the delay between two phones at the same BTS is incredibly long. Feels like VoIP between two continents.

I then tried whether the fixes have changed anything for the ip.access situation. And yes, they did! It was working straight away, and the delay is non-existent. Isn't it ironic that the traditional E1 system is much worse than the fancy new IP based system? I really need to hunt down where the delay is introduced in the E1 TRAU frame handling, this is not really acceptable right now.

Some further experimentation discovered that my Motorola EZX phones somehow refuse to work, while all the Nokia ones do. Well, some more bugs to fix down the road. At least conceptually everything is working now.

Progress on OpenBSC

After an intense weekend of hacking, I have made once again quite significant progress with regard to OpenBSC:

• ip.access nanoBTS support is now as good as BS-11 support, i.e. there is no functional difference between what you can do with either of those two BTS types
• As part of this work, A wireshark dissector for ip.access Abis-over-IP as well as some protocol documentation have been created
• simplistic call switching is implemented. This means that you can now register multiple phones to the network, and calls dialled to the extension numbers indicated in the SQL tables will result in paging and ringing of the respective recipient phone. However, voice data is still not routed, even after you pick up the phone.
• internal infrastructure work. OpenBSC now have a TLV parser together with data structures defining the TLV types for every IE in RSL, 04.08 and OML, as well as an internal signalling mechanism where some parts of the code can issue signals while other parts can listen for those signals

This means we're getting very close to being not just an experimental playground but actually doing something useful (like: actual voice calls) soon. SMS switching should also be really easy, in fact much easier than voice call switching. We can already send and receive SMS, but not yet route them through.

Other things on the to do list are: Switch to talloc as memory allocator, cleaning up a lot of the quickly hacked together code, looking for refcount and other resource leaks.

I also want to add an interactive 'Cisco-style' telnet interface for configuration, administration as well as debugging, utilizing the vty code from the quagga codebase

Thanks also once again to zecke for all his help. It's good to not have to care about everything, and just be able to use the working paging layer.

OpenBSC get support for ip.access nanoBTS

I've been contacted by a company who will support further development of OpenBSC, including the integration of support for the ip.access nanoBTS. Those beasts are unlike any traditional BTS, as they don't use a E1 link but rather route everything over TCP/IP. They even use Power-over-Ethernet and look almost as innocent as a WiFi access point.

After yesterdays meetings were finished at 7pm, I spent another eight hours of intense hacking and looking at protocol traces between a commercial BSC and the nanoBTS. It seems like everything is as far as possible according to the relevant GSM specs 08.58 and 12.21, which means adapting OpenBSC will not at all be hard, at least not for the signalling part. I haven't yet looked at the actual voice channels, but I'm confident it will all work out just fine :)

It turns out the abstraction of the input interface and introduction of something like a "BTS link driver" during the last weeks has helped a lot to ease the integration of a completely different BTS with a TCP/IP based link.

Unfortunately I currently have to deal with some rather dull and boring other work, but hopefully will be able to continue a lot over the weekend.

Preparing the second big shipping of GSM BTS

Today I've mostly been in my recently-rented warehouse to prepare the shipment of the next 13 units Siemens BS-11 microBTS

Some people are asking: Why are you doing something like renting a warehouse and taking care of shipping those heavy (48kg each) units?

The answer is simple: I care about IT security, and GSM is (just like DECT or Mifare) one of those massively-deployed systems with much too little security research going on. It has security issues that were known for probably about a decade now, with nobody working on any fix.

In order to encourage more security research (aka 'hacking') of GSM, we need to give the required tools into the hands of more people, and make sure those tools are not too expensive. The BS-11 in combination with OpenBSC will hopefully have this kind of effect: More people playing with the GSM protocols, discovering and releasing protocol as well as implementation weaknesses.

If you ever wanted to see how your mobile phone behaves when you use (in the Internet) well-known attacks such as fuzzing, projects like OpenBSC(+BS11) or OpenBTS finally put you into a position to do so.

OpenBSC: Coding multiplex/demultiplex of TRAU frames

In order to make OpenBSC to actually support switching of the TCH (traffic channels) associated with voice an data calls, we need to implement the following bits:

• A 16kbit sub-slot processor that splits a given E1 slot (64kbits/sec) into its four sub-slots
• TRAU-frame synchronization inside those sub-slots (each of them has different alignment which might also change over time, depending on the distance of the phone from the BTS)
• TRAU-frame decoding (C/D/T bits)
• TRAU-frame uplink to downlink conversion
• TRAU-frame re-encoding
• multiplex of 16kbit sub-slots into E1 timeslot

I've been working on quite a bit of code for this during the last week, but its still not finished yet (and I cannot test, since I don't [yet] have a BS-11 in Taipei).

At some later point we also definitely need to add code to implement the timing adjustments which result from BTS transmit buffer fill level metering requiring us to advance or delay further frames by certain amounts of microseconds. For now I'm just ignoring this, since the BTS is required to buffer the data anyway.

Zecke seems to be debugging the paging code whenever he has time. With some luck we both finish soon and then finally have decent voice calls between phones.

Announcing project OpenBSC

Yesterday I was co-presenting with Dieter Spaar on Running your own GSM network at the 25C3. The talk went quite well, and received an overwhelming response.

Together with the talk, we also announced, described and released the current development version of OpenBSC, a software implementation of the minimal subset of the GSM BSC/MSC/HLR in order to get a GSM BTS up and working.

The code is available in svn, there's a wiki describing it's current status and features (or lack thereof).

Some more progress with the BS11 Abis (BSC) implementation

Very infrequently I've been reporting about my humble attempts in talking the A-bis protocol to the Siemens BS11 microBTS GSM base station.

Since Dieter Spaar and myself are going to have a talk about this at the 25C3 in a couple of days, I'm currently working every minute of each day to get that Free Software BSC-side A-bis implementation going.

While the actual code is getting more and more in shape, I'm now back to fixing the underlying infrastructure: mISDN. The mISDN kernel code base is _really_ hard to understand... if I have problems with it - despite about a decade of experience with network protocols and Linux kernel development - then that probably says quite a bit about it. It would definitely benefit from quite a bit more documentation. Anyway, it's FOSS, so no reason to complain. Use the source, Luke.

So just about one hour before I had to leave to travel to my parents (where I could not take a 48kg GSM BTS with me) I finally had mISDN in shape to be able to support multiple TEIs with different SAPIs on the D Channel of timeslot 1 of the E1 interface carrying A-bis. My userspace code was happily sending and receiving OML (Organization and Maintenance Layer) and RSL (Radio Signalling Link) frames, while the L2ML (Layer 2 Management Layer) is entirely handled by the slightly patched TEI manager that mISDN has in the kernel.

Funny enough, after initializing OML and RSL, the first unsolicited message I got was the error event report about the 'intrusion detection' at the BTS, since I was operating it with open connector panel ;)

So now I've returned to the actual BSC/MSC subset implementation. I'm still confident to finish something that can handle reliably handle voice calls between two handsets registered to that BTS. All on one TRX, no frequency hopping, not using any A5 encryption. POGS (Plain-Old-GSM-System).

I'm very excited about everything that I've learned about the various higher-layer parts of GSM in the last weeks since FOSS.in.

Let's hope that our software plus the presentation at 25C3 can trigger other people to show similar enthusiasm about this topic. There's an almost endless number of opportunities for GSM related security research out there.

GSM hackers meeting at 25C3

There's going to be a meeting of various GSM related hackers at the 25C3. This is exciting, finally some more folks in the FOSS community who are looking at the protocol stack side of things.

We currently loosely coordinated using the wiki page at the 25C3 event wiki.

Understanding the GSM Um Layer 1

More or less involuntarily I ended up spending the better part of the last couple of days understanding all the nasty details of the details about the Layer 1 of the GSM Um (MS-BTS) interface, i.e. the RF interface between your mobile phone and the BTS.

You can find a lot of secondary information about GSM both online and offline, but they all seem to address other issues, like layer 2 and layer3 protocols, even the actual logical channel multiplex (at least to some extent), network planning, etc. - But I've not found anything reasonably detailed about the actual channel coding, TDMA and synchronization, ie. what happens after demodulation and before layer 2. So I had to read the specs. Oh well...

I actually thought that all those parts are already there (in gssm and gsm-tvoid), but in reality that was just something like a proof-of-concept implementation. Restricted to only work on Timeslot 0, not demuxing the individual parts of the CCCH (PCH/AGCH/BCCH/..) and not properly dealing with frame-number counting in case of various receiver overflows or the like.

So I've now started on a new codebase specifically focussed on everything that happens between the differentially decoded GSM bursts and layer 2.

Normally, one would not assume a layer1 to be particularly complex. However, in the case of GSM, it really is. There are various different physical channel configurations, each with their own nasty little differences in the channel coding schemes... plus the synchronous nature with its necessity to know a lot of context and correctly count frames in order to correctly interpret and decode the incoming bits.

So where do we start. Most readers of this blog will know that GSM has 8 timeslots on each RF channel. Each timeslot forms one so-called physical channel, which can assume one of many physical channel configurations.

A physical channel configuration determines not only the particular logical channels residing in the physical channel, but also low-level aspects such as parity, convolutional code, training sequence, tail bits, etc.

In every timeslot on a physical channel we transmit something called a burst. Depending on the physical channel configuration, there can be different bursts:

Normal: A regular burst transmitting 142 bits of data

Frequency Correction: A burst that helps us finding the offset between sender and receiver clock rate, compensate for temperature drift, etc.

Synchronization: A burst for achieving TDMA-frame-number synchronization

Access: A specially (short) burst used in the uplink (MS->BTS) direction to request a channel allocation by the BTS.

Dummy: A burst that is transmitted in otherwise unused/empty timeslots, only on the ARFCN (radio frequency channel) that carries the CCCH/BCCH

All 8 successive timeslots form what is called a TDMA Frame. Every time the timeslot number changes from 7 to 0, the TDMA Frame Number is incremented by the receiver.

For all control channels, four such bursts need to be concatenated and go through convolutional decode and parity to form a 23-byte MAC block. On most, but not all control channels, those four bursts are sent in successive TDMA frames on one timeslot. The notable exception is the SACCH (Slow Associated Control Channel) which accommodates every TCH/F (Traffic Channel) and happens to get one burst at the 13th, 101st, 114th, 202nd, ... TDMA frame. Thus, on such TCH/F channels you need to wait for 202 TDMA frames to obtain the four bursts needed to generate one MAC block. A MAC block is what is then passed up to the layer 2.

Timeslot 0 of the primary radio channel of the BTS is called CCCH (Common Control Channel). It is the only channel about which we can at least make some assumptions about its physical configuration. However, the CCCH carries a number of different channels, such as the BCCH (Broadcast Control Channel), PCH (Paging Channel), RACH (Random Access Channel), SCH (Synchronization Channel), FCCH (Frequency Correction Channel) and possibly a NCH and maybe even a SDCCH/8 multiplexed into it. The "problem" here is that the actual configuration of the logical channels is determined by a layer2 System Information Type 3 message. So you have to work with the minimal guarantees (that there will be a FCCH burst, followed by a SCH burst, followed by four BCCH bursts which give one MAC block, in which you will at some point find the SI Type 3 message telling you how all the other bursts of the CCCH are mapped onto the various other logical channels.

From the System Information messages you can also learn on which timeslot the CBCH (Cell Broadcast Channel) is located. Typically, it is part of a SDCCH/8+SACCH/8C physical configuration. On all the BTS's I've seen protocol traces of (which are not yet that many), this is on Timeslot 1.

A SDCCH/8+SACCH/8C configuration is another weird but more logical multiplex. It consists out of 32 consecutive bursts, four for each of the 8 SDCCH instances that it carries. The following 16 bursts are divided to four, and they alternately serve SACCH0..3 or SACCH4..7. So you basically end up with two 51 multiframes , i.e. 102 bursts, out of which 8 bursts go to each of the SDCCH/8 instances, and four go to each SACCH/8C instance. (102-06 = 6, i.e. 3 bursts are dummy in each 51 multiframe.

For the TCH/F (full-rate traffic channel), the entire viterbi decode and parity is different than the control channels... and which is probably going to be part of another blog post.

Oh, in case you're interested: you can find the unfinished demultiplex code snippets at this git tree

Luckily, with a few days more work, we can actually properly demultiplex and decode all incoming frames, learn about the [dynamic] channel assignments and configurations that the BTS does, and reconstruct at least the MAC blocks for all control channels, if not even the actual speech codec data of the TCH's (on those unencrpted BTS that exist in India). However, actually following a conversation is not possible (and not of interest to me anyway) due to the frequency hopping.

Open source SIM card emulation, SIM card proxying: BLADOX

I've been extremely positively surprised as I recently discovered bladox, a company specializing in providing development tools and custom hardware to simulate, proxy and extend SIM cards. And not only that, they are completely based on gcc + binutils as well as their own open source software. There couldn't be any better playground to play with the SIM interface of any mobile phone.

The general idea is to put an ATMega128 in between your real SIM card and the actual SIM card slot of the GSM mobile phone. On that ATMega128, you can then do whatever you want, e.g. forward only certain commands, such as "perform GSM algorithm" to the actual SIM, and implement the rest in your microcontroller. You can obviously also implement STK applications yourself for demonstration, or you can even block all STK commands and suppress the phone from ever knowing that the SIM actually supports STK.

This is an excellent playground. And it's even sold at a very affordable price. Now if I only had more time to look into all of its exciting possibilities while not forgetting about my other tasks (and paid work) :)

Maybe there are some readers of this blog who are just as interested but didn't even know that such products (and all the example code) did actually exist. Now you know :)

Some more GSM Abis experiments

It's been quite some time since I last mentioned Abis in this blog. Recently, I've again found some time to experiment with Abis. The last two days I was working on porting some proof-of-concept code of a fellow hacker from windows to Linux.

I now also have manufactured all the cables and adapters I need, plus installed a Windows 98 box in order to operate the Wandel+Goltermann MA-10 protocol analyzer that somehow made his way to my lab. The MA-10 can act both a a high-impedance passive sniffer on top of the E1 link (using the Abis Monitor software), or it can actually emulate the BSC by using a terminated E1 Rx+Tx interface and the AbisSim software.

I don't want to talk too much about things that haven't been implemented yet. But in the next weeks, I'll be diving all the way into mISDN and see what needs to be done to make it talk the specific Q.921 dialect that Abis uses.

Stay tuned. I'm working towards a first release at the 25C3 congress in late December.

Extending range of GSM cells by using only 4 channels

Today, while reading IT mainstream magazine "c't", I stumbled across an article about GSM deployments (and popularity) all over Africa.

One of the interesting things in that article was that one Operator had modified their network in a way to only use four timeslots (out of the eight available timeslots) per frequency in order to extend the range of a single cell to something like 70 kilometers.

For those who are not as familiar with the GSM Um air interface: It uses TDMA (multiple devices each get one timeslot on a given frequency). So let's assume we have eight timeslots on one frequency, all the transmitters (handsets) need to be synchronized with regard to that timeslot. Radio travels at speed of light and not with infinite speed. Therefore, since the handsets can be at a lot of distance to the receiver (base station), they might send in the correct timeslot, but the signal arrives out of the timeslot. GSM uses what's called "timing advance" in order to compensate for that effect. The base station tells the handset how much time earlier than the actual timeslot it needs to transmit to ensure arrival within the timeslot.

Now in that African GSM network in question, it seems like even the maximum timing advance is not sufficient. The frame still arrives late, i.e. in the next timeslot. By allocating only every second timeslot, there cannot be any clash and thus the range of a single cell can be extended. This is actually a very cool idea, I would almost call it a "hack", and it is possible within the GSM spec without requiring any change to existing mobile phones!

I only wonder how much of such cool hacks we would see if GSM base stations were more open and available. If there was a full FOSS stack that many people could use on off-the-shelf hardware, it would lead to a lot more innovative experiments and thus innovation. There would suddenly be more than a handful of GSM experts with access to proprietary technology looking at what kind of good, useful, cool and/or creative things one can do...

A Free software 3G protocol implementation: Wireless3G4Free

For quite some time there has been a project called Wireless3G4Free. I suspect it is little known outside a certain academic community. So what is it all about? Creating a FOSS based test platform for wireless 3G systems. Yes, this is the so-called baseband side. The parts that are usually very carefully locked away in the proprietary stack of cellular handsets and other equipments

Even though the project, funded by the European union and implemented at EURECOM in France, is 'finished', it is not as easy as to just use that software and get UMTS connectivity.

First of all, it implements the 3.84MChip/s TDD variant of the physical layer (layer 1), whereas most commercially deployed UMTS systems for cellular access use the FDD variant. For those not as familiar with 3G technology: There's three different layer 1 options: the 3.84MChip/s TDD, the low-chip-rate Chinese TDD variant, and the FDD variant. The layer 1 is separated in two parts, one that is TDD/FDD independent, and the other part that is shared.

Secondly, the Wireless3G4Free project uses IP on the layer 3, as opposed to the actual layer 3 protocol of UMTS (which borrows a lot from the layer 3 protocol for GSM, which in turn borrows a lot from Q.931 / Euro-ISDN).

So if one was to make that code interoperate with UMTS cellular networks, the lower half of layer 1 need to be rewritten for FDD, and layer 3 needs to be implemented.

What is exciting about 3G compared to GSM: GSM uses proprietary ciphers (A5/1, A5/2) for the actual air interface. Those ciphers have leaked quite some time ago, and they're no longer secret (and thus the GSM security is no longer existing), but still people are not supposed to know how it works.

In the 3G world, the corresponding cipher is public. This means that in theory, it should be possible to implement everything in Free Software based on publicly known information. Yes, it is a lot of work. But it definitely can be done.

Before actually using this on any official network, it would obviously need to be certified. Certification for this kind of protocol is a time-consuming and expensive process. It requires development cycles of going to a certified test lab, obtaining test results, going back to actually fixing the problems, re-running the test lab tests, and so on. Nevertheless, Free Software has already proven that this can be done. The isdn4linux project did a full EDSS1 certification some 10 years ago. ELSA, a maker of passive ISDN cards, sponsored that effort. And if you used an unmodified code version, then you were certified. As soon as the source code was changed, you were running an uncertified version. I don't see any big problem why the same scheme should not work for a 3G baseband software stack.

One important question though, is the question of hardware. None of the existing commercial vendors of 3G chipsets will ever provide you with the hardware documentation that you would need or want to run that kind of code on their hardware. It is their business to sell their proprietary 3G stack along with their chip, so they would only loose money if there was any FOSS implementation in competition.

Sure, you can use something like the USRP or USRP2 or any other software defined radio platform. But while that would be ok for a proof-of-concept, it is too large, expensive and power-consuming to be used or 'ported' to any actual handset-type product.

So any possible real-world plan of making this happen would probably go as far as to implement everything based on the USRP, then have a proof-of-concept prototype and then do a modem design based on existing, openly documented RF components and ADC as well as DSP+Processor combination that is suitable for low-power operation.

Sure, I'm just daydreaming. But sometimes you have to dare to dream in order to make things happen. Anyone wanting to turn this idea into a business, let me know ;)

Things I learned about GSM, STK revisited.

During the least couple of days I've had some pretty intense conversations with a number of people on various aspects of GSM, leading me to [re]reading some of the interesting bits of its specification.

There are a number of observations that I don't want to talk about right now, and which will likely be part of my work during the next couple of months.

One thing that ever so often gives me the creeps is STK (Sim Toolkit). To those people involved with GSM, it is no news that with STK an operator can basically remote-control your phone. He can, among other things

• make your phone send SMS
• initiate outgoing calls without your interaction
• initiate outgoing calls and terminate any existing call
• open data connections (GPRS/EDGE)
• launch a browser to any URL
• play tones on your speaker
• access and modify any information (contact, SMS, dial history, even IMSI) stored on the SIM

And the worst thing of it all: You don't even know which of those features your phone implements (most likely all of them). I'm happy to still use a SIM that predates the GSM11.14 (STK) specification.

Now in the advent of projects like OpenBTS, where we can emulate a GSM network side, and in combination with either supplying your own SIM card (or emulating it using a PC), we will finally see a faint possibility of actually testing (and demoing) the never-ending security nightmares caused by this evil monstrosity.

Further studying of Abis protocols, moving towards implementation

The first quarter of 2008 is already gone, and I still haven't found all the time that I wanted to find to play with my BS11 base station[s].

However, I've spent quite a bit of time over the last couple of days further studying the GSM/3GPP 08.5x documents, as well as a thorough read through the mISDN source code.

GSM/3GPP 08.5x describe the layer1, 2 and 3 protocols of the Abis link between BSC (Base Station Controller) and BTS (Base Transceiver Station) in a GSM network. It's modelled on top of a E1 link in PCM30C configuration, i.e. TS0 is for CRC4 and synchronization, TS16 is used for the layer2+layer3 protocols, whereas the other time slots are used for transfer of the actual voice call data.

After looking at the various different driver options on Linux, I have determined that mISDN is the most promising and flexible architecture available. mISDN also has a layer0 + layer1 driver for the NT mode of the HFC-E1 card that I'm using. mISDN is great in a way that every layer is strictly separated from the other layer, and that at any layer parts of the stack can be implemented in userspace using library API.

Thus, I've started to write some mISDNuser based code to attach to the kernel-side hardware and lower-layer drivers. I'm not yet sure if the Q.921 (ISDN Layer2, also called LAPD) of the mISDN kernel side can be reused for Abis or not. The differences between standard Q.921 used on European ISDN and the Abis Layer2 are fairly small, so I hope to get it working with the existing LAPD code.

Unfortunately, I have paid work to take care of, so I will once again be distracted from this most interesting of my toy projects.

Documentation for GSM BTS arrived

Today I finally received PDF's of the Siemens BS-11 GSM BTS. This means that I'll now be able to actually connect the device to power, E1 and RS232.

Unfortunately I'm still lacking the configuration software for the device, and a corresponding E1 card for the Abis interface. Anyway, seems like we're slowly getting there. Maybe during Q1/Q2 2006 I can spend some time actually implementing code for that beast.

Proud owner of a GSM BTS

Starting today, I'm the 'proud' owner of a Siemens BS-11 GSM BTS.

If anyone has documentation on

• The polarity / signal / pin descriptions of the connectors
• The Siemens vendor specific extensions to Abis (The GSM protocol between BTS and BSC)
• Whatever other documentation/information on the BS-11

it would be greatly appreciated if you could contact me.

The whole purpose of this exercise is to do some [security] research in the GSM area, and to see whether it can be done to implement the BSC-side of Abis (and a minimum emulation of HLR, MSC, ..) in order to get a phone to talk to the BTS.

This is yet another of my many toy/pet projects, so please don't expect any even remotely useful code anytime soon. Chances are likely that this project won't go anyway due to lack of time.