25C3: Total Overload

In my 10+ years of CCC congress, I've never been trying to run any significant project at the hackcenter so far. In the first couple of years I was just hanging out there, chatting with people and working on stuff here and there, operating FTP sites (like the trial we once had with then-experimental ext3 vs. Reiserfs on machines with Gigabit Ethernet interfaces [I was operating the ext3 one]). The years following that I was trying my best with the audio+video recording and streaming - with mixed results, as all people from that time remember. I was just trying to help, digital A/V not being my particular area of expertise.

So this year I decided it would be a good idea to do some serious GSM protocol side development at the hack center, which would complement the talk I was giving on running your own GSM network.

So far so good. The only day where I really could hack the way I wanted was on Day 0 (the day before the event officially started) and Day 1. Friends with various backgrounds started to join and help with issues here and there. Everyone was excited by the numerous new possibilities a project like this provided.

However, starting with Day 2, and particularly Day 3 and Day 4, the amount of constant interruptions by various people was simply unbearable and brought the development close to a complete halt. Not only that, it caused severe lack of sleep, stress levels even beyond what I had ever experienced before, and I developed a cold and even some fever.

In general, I am completely disappointed by many of the crowds. I would have assumed that most people _know_ that frequent interruptions lead to inproductivity, and that they would also know and understand that a project that literally hundreds (if not thousands) of people are excited about cannot answer RTFM style questions that everyone would have been able to read up by themselves on wikipedia or similar sites. Sure, there were some exceptions to that rule. But overall, it was a very unpleasant experience.

So from next year on, I will certainly refrain from running any kind of project in the hackcenter. I will be a regular attendee, possibly speaking on some kind of subject or the other, preferably on the last day so people won't drive me nuts with their never-ending questions.

The DDoS attack on the GSM/BS11/OpenBSC hackers, combined with the overcrowded 25C3 has in the end led to a point where the only two talks that I've been able to attend were the ones in which I was speaking.

"Thank you" :(

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).

If you're at the 25C3: Don't miss the DECT talk

If you're at the 25C3, I strongly recommend visiting the DECT security talk. Trusty me, you won't be disappointed.

It's one of the most exciting thigs that I've been seeing happening recently. Finally, some more people transcending beyond boring Internet security and moving into other areas of communications security that are desperately needing more research.

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.

The "Deutsche Bahn" experience

Given that I'm a person who constantly interfaces with a very international crowd and travel a lot, I used to be quite positive about the great railway system Germany had. The comfortable travel in high-speed trains, with power outlets under your seat, from one city center to another city center faster than you would ever be with an airplane. Just enter a train, sit down, hack for something like five hours straight the entire trip.

Now I know that the railway company "Deutsche Bahn" has had its fair share of trouble in recent months with technical problems and what not. But given the fact that those problems (resulting in less trains/cars being available) exist for some three months now, I would suppose that they deal with this properly

Having said that, the online ticketing and reservation system made a reservation in a car that doesn't actually exist in the train that I'm using today. So I was confident that I had a reserved seat for the five hour trip back to my family in southern Germany. What a misconception :(

How difficult can it be to update the reservation system with those trains / car numbers that actually operate? Or at least refuse to make reservations at all, if you cannot guarantee them? It would probably be a couple of SQL updates here and there in the database.

This is not the kind of quality that I expect from DB. And I won't even start to complain about the complete lack of heating in this particular car. There we are in hyper-modern, super-silent train cars at 200+ kph, in the middle of winter, without heating. Yes, I can wear a jacket, sure. But my fingers are freezing from typing at this temperature. And no, gloves + keyboard don't make a good combination. Maybe I should start bringing an electrically powered heater net time, given the fact there is a power outlet...

Klangstabil in concert @ Schlagstrom

Last night was the greatest fun I've had in a long time. I've attended a Klangstabil concert as part of the Schlagstrom Industrial/Noise events in Berlin.

There is probably not much music that provokes as many endorphines to be released in my body as some good, loud, noisy and rhythmic electronic music :) Klangstabil have been one of my favorites for quite some time, but this concert was the first of their concerts that I actually attended. Now after it, I'm asking myself why. Probably due to the fact that contrary to some others I actually think the latest album "Math and Emotion" is great. Will make sure not to miss another concert in the future. promise!

I remain speechless, fascinated, moved. Happy.

First-time visit to (South) Korea in January

Despite being a business trip (more details might be disclosed later, after it has happened), I will talk about this in the 'personal' section of my blog.

I'll be in Joungin-City and Seoul for about 10 days in early January. Most of them are probably spent with busy working days, but the weekend is definitely free for some sight seeing and the like.

I've always been excited about Korea (for whatever reason), and it is definitely one of the major countries in South-East-Asia that I haven't visited yet. I know it is culturally very difficult and probably hard to get adjusted. Some business travellers rank it as higher difficulty than Japan, let even aside China or Taiwan.

In any case, I'm happy to go there and get a first impression. Too sad that it's the wrong (cold) time of the year. But well, the first trip doesn't have to be the last.

Some almost two more weeks will be spent again in Taipei, where I am looking forward to some exciting appointments, before I seem to be heading for some more work in India in February, potentially visiting FOSDEM before.

FreeSmartphone.Org (FSO) developer meeting in Braunschweig

Yesterday I had the pleasure of attending a developer meeting of the FSO core developers Mickey, Daniel, Stefan and Jan in Braunschweig, Germany.

So far my actual involvement with FSO code has been minimal, apart from some profiling here and there, as well as a couple of comments/opinions, mostly offline and not on the mailing lists. I think this is sad, since FSO is the best thing that ever happened inside Openmoko. Focussing on the actual platform/architecture/middleware, standardizing and implementing the interfaces by which application programs interface with the actual device.

So while I haven't been able to contribute much to the python reference implementations, I hope I can contribute a bit more in the future. Also, my involvement with Swisscom Innovations as well as the gnufiish project will probably sooner or later drive me into touching some more FSO code.

It was good to hear the various reports and to see how much thought is given to the various details. Most notably was the quite lengthy debate about how a suitable battery / power supply API should look like. The devil is in the details.

As far as my actual work at the meeting is concerned: I've been asked by the FSO guys to show them how to play back PCM audio into a GSM voice call, and how to record a GSM voice call. Allegedly nobody has ever done this inside Openmoko again, after I demoed it ages ago, most likely still on GTA01.

The resulting information can now be found in the wiki. Unfortunately the actual capture is not working, apparently due to a ASoC driver kernel bug which I tried to debug but gave up after some intermediate results, since my understanding of the audio subsystem is limited and I have tons of other tasks.

The other bit I've been working on is a serial port LED trigger, i.e. the ability to make a LED class device blink if RX or TX activity is detected on a serial port. The code is not finished yet, but will be hopefully soon.

We've also been talking a bit on how to integrate keyboard-based devices with FSO, i.e. how the framework should indicate this to the window manager. The key part is that we're not as much interested in the actual existence of the keyboard, but the fact of whether it is slided out or not (for devices with a slide, such as the glofiish M800 or the TyTN/Kaiser).

Some further bits were spent with Stefan trying to hook up the libertas GSPI driver with the S3C24xx SPI host driver in order to get WiFi to work in project gnufiish.

VIA submits SD/MMC driver to mainline kernel

Just a quick note, one more GPL licensed Linux kernel driver from VIA is on its way to get integrated into mainline: The SD/MMC driver.

Sure, there is some minor feedback with requests for code changes here and there, but generally the code looks good, so the journey into mainline could be fast.

Please note that I was not involved in writing the driver or any review. VIA's engineers have done this entirely on their own.

glofiish M800 keyboard driver

I've been hacking on a glofiish M800 keyboard driver, and most of it is now implemented. Even the Caps and Fn LED are in operation, and sliding out the keyboard causes a led_trigger to enable the keyboard backlight.

However, I still get the timing wrong when to read the CPLD. In most cases it works, but sometimes I get bogus characters and the like. Also pending: A more comprehensive keymap, plus support for the Fn-shift-key.

Free Software Foundation lawsuit against Cisco

As covered at lwn and other sites, the Free Software Foundation (FSF) has filed a lawsuit against Cisco. This came as a big surprise to me, but a very welcome one.

At gpl-violations.org, we had our fair share of dealing with Cisco (and particularly Linksys, a Cisco division). Never we have received any entirely satisfactory response. Sure, when you notify them of some GPL infringement, they will take some steps here and there. But in all those years, I have not seen a case where there was a thorough response. Whatever was disclosed as 'GPL source' was incomplete, didn't compile, and with the next firmware release there was again no source code for that new release. And then came the next product, sourced-in from a different OEM, and the entire process had to re-start from scratch.

Yes, they have gone and hired some engineer[s] to explicitly deal with the GPL related issues, like they have taken other steps in the right direction. But it was always superficial. Never addressing the problem at the root, i.e. have a proper in-house business process and supply chain license management to ensure the next product is not yet again a copyright infringement on GPL licensed software. It is so easy to resolve at the source, and so hard to fix later.

So the FSF's decision to take this problem to court is the most appropriate response that one can think of. A company of the size of Linksys clearly has the manpower, skill and resources - as well as the economic power on their suppliers - to once and all resolve any GPL licensing issues they might have. Not only to the bare minimum that they might think, but all the way to leave any legal grey area whatsoever. Only if there is a demonstration of a _factual_ legal risk rather than a virtual legal risk, they will get the motivation necessary to just 'stay clean' and not try to bend the license to its extremes.

So you might think "why did you (i.e. gpl-violations.org) not take it to court?" For once, I only hold copyright on certain parts of the Linux kernel, and not for large amounts of code they use. Also, a number of the particularly problematic products were not shipped into the German jurisdiction, and thus a case could not be made over here. Furthermore, many of the violations are not as clear black or white as most of the other cases that we take on. So the amount of work and resources required in such a case would probably draw away too much attention from all the other cases that we have.

But once again, I really welcome the FSF's action. It's funny how the historic cycle closes. Originally I started gpl-violations.org because I thought the FSF strategy was not aggressive/efficient enough in making Linksys/Cisco GPL compliant in the infamous WRT54G case five years ago. Now, it seems that even the tolerance and patience of the FSF has found an end.

Oh, and don't get me wrong: I never wanted to criticize the FSF for what they did back then. They had and have their own strategy of what they think about their own copyright. It's just that my strategy was different. It's up to every author or rights holder to decide which legal strategy fits best.

ALSA SoC driver working on E-TEN glofiish M800

After some hacking on this on the airplane back from India, and some finishing touches today, the audio output on the M800 is now working under Linux. The AK4641 codec driver and M800 ASoC device driver are to be found in the gnufiish git tree.

What I yet have to verify are the interconnections with the GSM Modem audio, as well as the FM radio. At least general audio playback is working, both through the earphone and ringtone speakers, as well as on the headset.

Received a Google/Android/T-Mobile G1

Due to a friendly person in Taiwan, I have now received a Google/Android/T-Mobile G1 device. Not that I'm interested in actually using it as my regular phone, but just to play a bit around with it. I've already had a chance to use the device for a bit, and I think it's surprisingly unimpressive. Mechanical quality of the swivel and keyboard is OK but definitely not as good as e.g. the HTC Kaiser/TyTN2.

What I'm much more interested in is to confirm my my earlier suspicions on the lack of openness of Android, or at least the actual devices based on Android.

As it seems, in fact it only accepts cryptographically signed kernels, and the signatures that are accepted are not signatures of the user who has bought and owns the device, but rather the signatures of Google/Android/T-Mobile/HTC.

I still think it's extremely weird that you actually buy a device, and then don't own it. I would have no problem if the device is rented from the manufacturer or the mobile network operator. Sure, then in this rented device, only they control what kind of software you use. But this is not the case. People buy it, pay money, legally own the device but technically don't.

I've seen that there are some hacks, including one one that puts the engineering bootloader on the G1. Sure, there will always people who exploit known security issues in hardware, ROM or software, just like the guys who work on Linux on the iPhone, or the now-proclaimed-dead Motorola MAGX platform. However, this doesn't address my point. Those kind of hacks will be closed at least with the next hardware release, and they can only be performed by a really small portion of the actual users (owners).

A truly open device (including mobile phone) has to give the user the freedom of choice what code he runs... Just like on the PC. You can run any OS you want, any App you want. Hell, you can even go ahead and write your own OS if you want. And the G1 is definitely not giving you that kind of freedom.

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.

Back to Berlin

After almost one month of travels (Berlin->Paris->Bangalore->Delhi->Taipei->Delhi->Bangalore->Mumbai->Bangalore->Paris->Berlin), I'm finally back to Berlin. It always feels good to be home, and in fact I'm probably home for more than three consecutive weeks, something that doesn't happen very often.

It has been an exciting time, and I've made quite a bit of progress on both the GSM scanning side as well as on the gnufiish (Linux for E-TEN glofiish) side. Still, lots of work remains, and it's a challenge to see how much time I can spend on it.

During the next couple of weeks I'll be working on VIA related stuff. Most of it is behind-the-scenes work, but I'm also actually going to work on some actual code again. What a relief ;)

Obviously, there is also still a lot to be done on the GSM base station + GSM network front. The interested hacker might already have figured out that I'll be co-presenting with Dieter Spaar on how to run your own GSM network at the 25C3, but I'm mentioning at this blog anyway for the sake of completeness. The code will be released at the 25C3, and we'll hopefully also have some fun at the GSM hackers desk in the hack center.

With some luck, I'll be heading for Taiwan and (for the first time) Korea in January 2009. The other news about 2009 is that I'll likely spend more time than before in India.

Availability of Bollywood DVDs in Bangalore

I've been visiting Bangalore many times throughout the last five years. Every time I've spent a visit to "Planet M" on Brigade Road for buying some Bollywood DVDs.

And for some unknown reason, the size of the racks with Bollywood DVDs is shrinking from year to year. And with it, obviously the choice...

What you can get are sort of the last five major blockbusters, and tons of cheap re-releases of old movies from the seventies through nineties. But what about the last five years? What about anything that was released recently but is no longer part of the top-10? _nothing_!

Oh, and then you can get tons of Bollywood VCDs. But who wants that low quality? It's definitely no pleasure to watch a VCD. Even DVDs have way too little resolution to capture e.g. the details of costumes in a lot-of-people-dancing kind of scene.

It's really sad. Are people no longer buying those DVDs? Do Bollywood fans go to different places? Where should I go in Bangalore for a decent selection? Hints welcome, please send e-mail.

As a side note, yesterday I've also been at Planet M in the Esteem Mall. It's sort of a joke. Never seen a CD/DVD store that small. Obviously no choice at all.

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.