Harald Welte's blog
   

RSS

Harald's Web
gnumonks.org
hmw-consulting.de
sysmocom.de

Projects
OpenBSC
OsmocomBB
OsmocomTETRA
deDECTed.org
gpl-violations.org
gpl-devices.org
OpenMoko
gnufiish
OpenEZX
OpenBeacon
OpenPCD
librfid
openmrtd
opentom.org
netfilter/iptables

Categories

Archives

Other Bloggers
David Burgess
Zecke
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma

Aggregators
kernelplanet.org
planet.netfilter.org
planet.openezx.org
planet.openmoko.org
planet.foss.in

Ohloh profile for laforge
identi.ca
twitter
flattr
Linked in
Xing

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.


blosxom


Contact/Impressum

       
Fri, 31 Dec 2010
OpenBSC field test at 27c3 over

During the last week I was busy with

  • December 22nd though 24th: Preparing OpenBSC to be ready for the field test at 27c3, i.e.
    • improving the output of the log at "INFO" level to be not too verbose at the expected network load
    • Implement the interface to LCR using a Unix domain socket rather than linking LCR with OpenBSC
    • Configuring all 6 BTS, put them in multi-TRX config, test the setup
    • Manufacturing nanoBTS stacking cable (with their weird RJ-69 plugs that you have to mill a notch off)
    • Install all required software on the machine that will run OpenBSC
  • December 25th and 26th: Setting up the network
    • Physically mounting the nanoBTS units
    • Patching cables throughout the building, installing PoE switches
    • Configuring LCR
    • Interfacing with the Phone Operation Center (POC) via E1 / DSS1
  • December 26th through 30th: Running the network
    • Fixing bugs as they appear (see e.g. zeckes mailing list post
    • Making sure users are happy
    • December 30th: De-installing the network

    I don't have much time now, still have to unpack lots of boxes full of gear. However, I have finally completed my scripts to graph some of the statistical data of the field test. You can see the graphs in the OpenBSC wiki.

    Unfortunately we don't have the same body of statistical data for the previous field tests at 25c3, 26c3 and har2009. However, for all of those three events we have now graphs about the IMSI/Country distribution of all the phones that have ever tried a LOCATION UPDATE with us: 25c3, 26c3, HAR2009, providing some nice statistics on what nationalities are attending the respective events.

[ /gsm | permanent link ]

Tue, 21 Dec 2010
Interview about GSM security (in German)

The major Austrian newspaper Der Standard was yesterday featuring an an Interview with me on GSM security related issues. Being in Austria, the interview is obviously in German language, sorry for all non-German-speaking readers of my blog.

[ /gsm | permanent link ]

Sat, 18 Dec 2010
Preparations for GSM network at 27C3 conference

Behind the scenes, we've been working on preparing the experimental GSM/GPRS/EDGE network at the 27th Chaos Communication Congress. The regulatory authority was nice enough to grant us 6 ARFCN, which we will split to 3 BTS (2 TRX each), resulting in one BTS with 2 TRX on each of the 3 conference building floors.

I've started a page in the 27C3 conference wiki about the GSM network. Please notice that this information is still preliminary at this point.

The wiki page also contains detailed instructions on how you can participate in the test network. I'm hoping a lot of you will bring a dedicated cellphone that you can put the 27C3 SIM inside and participate in the network.

I'm particularly excited about GPRS/EDGE support. We will be handing out official, world-wide routed, unfiltered IPv4 addresses to each and every phone. This means you are free to run port scans or other attacks (please: No DoS) over an unfiltered IP network directly into your mobile phone.

[ /gsm | permanent link ]

Fri, 17 Dec 2010
Learning how GPS _really_ works in order to truly understand RRLP

Back one or two years ago, when I first discovered the RRLP as a mechanism how operators can get very precise GPS positioning of a mobile phone (without any authentication or a way for the user to prevent or at least notice it), I was frankly speaking shocked.

We've done some experiments at HAR2009 and obtained a number of great position fixes, mostly from iPhones. The nice aspect of RRLP is that it is buried down inside Layer3 of the GSM protocol stack in the baseband processor. This is at a much lower level than all the web or App based location based services that are running in an application program in userspace of the application processor.

Now RRLP comes in a number of different flavors. What we have done so far is called ms-based positioning, where the phone works as an autonomous GPS receiver, pretty much like a personal navigation device or any hand-held GPS receiver. So the network simply asks "tell me your GPS coordinates if you know them" and the phone will respond. Some phones ask for assistance data in order to do A-GPS. But that's it.

What has been more of a mystery to me is the ms-assisted GPS RRLP mode, where the phone just performs some measurements and forwards the resulting data to the network. I never really understood the details of how it works, but always wanted to. Last week I finally found some time to do the research required to fully understand it:

The network tells the phone the exact bit timing, Doppler shift and other parameters for each of the satellites that it _knows_ the phone would be receiving given the current cell the phone is registered to. The phone then performs some measurements within very narrow time/frequency/synchronization windows, and passes back the timing of those received signals relative to the current GSM cell signal. Using this information, the actual position estimate will be completely computed inside the network, not inside the phone.

Presumably this ms-assisted mode was implemented to not have to put a full-blown GPS receiver into every phone, requiring sophisticated processing in either hardware or software. Also, this method should be much quicker as the network _knows_ all the current ephemeris data and GPS signal timing, whereas a stand-alone GPS receiver would have to take quite a lot of effort to acquire a signal from cold-start, even if there is some assistance data.

Unfortunately I don't have the time to actually implement the network side for this. It would be a fun project, but I have already way too many of them (and customers who only pay for other features in our Free Software GSM stack).

There's now a RRLP wiki page at security.osmocom.org. As short as it is it still contains more information about RRLP than I could find on any other public source on the network - except the protocol specs.

[ /gsm | permanent link ]

Wireshark patches enhancing IPA Abis/IP dissector accepted

The wireshark project recently accepted two of my patches related to the Abis/IP dissector. The first of them makes the TCP/UDP port numbers that are interpreted as IPA multiplex a configurable preference. This is really useful, as the actual port numbers used in production setups seem to differ from site to site (with no real standard port numbers and only some that are 'best practise'). Without this patch, in many case you always need to click 'Decode as... GSM IPA' every time you open a pcap file.

The second patch adds support for printing the debug messages that the Hay Systems Ltd. HSL Femtocell includes as stream identifier 0xDD in its Abis/IP variant.

I hope I can find some time to clean up / finish some of the other wireshark patches that we have pending for quite some time. The main problem here is that we imported some definitions from OpenBSC, which use gcc extensions and are thus not permissible for wireshark inclusion.

[ /gsm | permanent link ]

Mon, 13 Dec 2010
A US professor who was warning the Indian Government about lack of IT security in Voting machines is being deported from India

According to news reports, J Alex Halderman is refused entry into India and will be deported from the country upon entering. He is one of the authors of the study India's EVMs are vulnerable to fraud which a number of international experts on electronic voting machine security had published in order to warn the Indian government about the flaws in their voting machines.

This is outrageous. Instead of trying to keep those researchers out of the country, the Indian government should invite those experts (who are giving free advice about IT security problems) and have them do a detailed analysis and start an official investigation into why and how the existing machines could ever be used for election purposes.

It seems like the authorities in question have absolutely no clue on how proper incident response is being done. You don't get people to trust your system if you jail activists who outline flaws in voting machines and try to keep foreign experts out of the country. Trust has to be earned. And if there is some serious incident, a public investigation should be started, open to all experts in the field. Trying to cover up by ignoring results of IT security research (academic or otherwise) will not make the system more secure. All this will help is to further undermine trust in the system.

I would like to use this opportunity (and my upcoming trip to FOSS.in/2010) to call upon all my Indian friends: Don't just sit there idle and allow your government to get away with this. The public needs to know how trustworthy the voting machines are. If there are serious objections by academic experts in the field, the system needs to be updated/upgraded or even abolished altogether. Elections are the foundation of a democracy, their results cannot be entrusted to technology that has never received public and independent scrutiny.

UPDATE: It seems that according to indianevm.com, he was only held for 18 hours and later permitted entry into the country. While this is good news in general, it remains unclear why they held him for deportation in the first place, and why the Indian Electoral Commission is so nervous about anyone doing legitimate research on the security of electronic voting in India.

[ /politics | permanent link ]

Sun, 12 Dec 2010
Back from the GPL Compliance Engineering Workshop in Taipei

I've been a bit over a week in Taipei, mainly to co-present (with Armijn Hemel) the GPL compliance engineering workshop at Academia Sinica. The workshop was attended by more than 100 representatives of the local IT industry in Taiwan, from both legal and engineering departments.

I think even only the sheer number of attendees is a great sign to indicate how important the subject of Free Software license compliance has become in the IT industry, and specifically in the embedded consumer electronics market.

I would like to use this opportunity again to thank the OSSF at Academia Sinica for doing a great job in organizing this event.

Thanks also to Armijn, who not only does excellent work at gpl-violations.org but also covered the majority of the presentations at the workshop.

So what did I do the remaining week? Lots of meetings, mostly with companies regarding GPL compliance, but also with old friends like Wolfgang Spraul and Holger Freyther who happened to be in the city at the same time.

I also had some very exciting meetings related to my various GSM related FOSS projects, but it is too early to really say anything about them.

[ /linux/gpl-violations | permanent link ]

Starting to work on drivers for the Mediatek MT6139/MT6140 RF Transceiver

In the last two days, I have finally started to get some initial work done on the OsmocomBB port for the Mediatek chipsets. My current focus is the MT6139/6140 RF Transceiver, including stuff like setting it up for Rx and Tx, computing the VCO/PLL dividers for all ARFCNs in 4 bands for uplink and downlink, etc.

Next will probably be the drivers for the MTK digital baseband BPI (baseband parallel interface) and BSI (baseband serial interface), which are needed to actually use the MT6139/6140 driver, as well as the antenna switch module, power amplifier and other parts of the RF front-end.

I'm not really testing any of this code at the moment, as I'm travelling a lot without access to my Racal 6103 or other GSM handset testing equipment. However, writing even untested code helps me understand the chipset better and is a first step in the right direction. I guess January 2011 will provide more time to continue/complete this task.

[ /gsm | permanent link ]

Wed, 08 Dec 2010
ST-Ericsson releases (and submits) Android GStreamer code

Back in October I blogged about ST Ericsson hooking gstreamer into Android but apparently making that code proprietary. I may have been a bit opinionated at the time. The reasons for not disclosing the code allegedly were that it is assumed to be of no general use. However, it still felt very bad that two Free Software projects are interacting with each other through a proprietary layer.

I've since had a very pleasant contact with the Head of MeeGo Business Development at ST-Ericsson and they have now released and submitted the respective code-bases, like the gst-android git repository and the Audioflinger sink in the gst-plugins-bad repository as well as Android makefiles for all parts of gstreamer.

It is great to see this kind of development, and see that ST-Ericsson is trying hard to do the right thing: Not only releasing their extensions of gstreamer under a GPL-compatible license to their customers, but even actively pushing those changes upstream. Thanks to everyone involved, particularly Andrea Gallo and Benjamin Gaignard.

[ /linux/mobile | permanent link ]

Mon, 29 Nov 2010
Trying to understand Ericsson Abis-IP + OML

I've recently been able to look at packet traces of an Ericsson BTS (which they call RBS) and have been working on understanding their proprietary Abis-over-IP protocol stacking and OML layer.

By now, all equipment makers have migrated their BTS products from classic TDM (E1/T1) lines to some form of IP-based back-haul. However, the GSM specs as published by ETSI and 3GPP still only specify the E1/T1 transport layer, and every vendor seems to invent their own protocol for back-haul.

What we already know (and support) is the ip.access style Abis-over-IP, where they have their IPA multiplex layer inside TCP. Inside that they then have pretty straight-forward 08.58 (RSL) and 12.21 (OML) messages.

With Ericsson, they use a stacking like this: Ethernet, IPv4, L2TP, custom-HDLC, RSL/custom-OML.

The custom HDLC layer (I have called it Ericsson HDLC, or short EHDLC) seems to work quite different from all other forms of HDLC that I've seen:

  • 1 Byte Address
  • 1 Byte Length (including the header!)
  • 1-2 Bytes Control
  • n Bytes Data

The Control octets are just like in any HDLC, i.e. you have U/I/UI/S Frames and see commands like SABME, UA, RR, ... It mostly uses a two-octet control word that has both N(R) and N(S) for acknowledgements. At the beginning they actually do a XID exchange that seems compliant with ISO 8885 (if you cannot find that document, try reading the AX.25 spec instead, its XID is compatible with ISO 8885).

I have not fully understood the Address octet yet. I see lots of changes in the upper three bits, and it seems there is a SAPI or TEI that is the lower 5 bits of the octet.

Having a length field in an HDLC header instead of any flag bytes is indeed very uncommon to see.

The OML layer (called OM2000) is completely proprietary and shares nothing with the GSM specs 08.59/12.21 apart from the three byte header. However, I have managed to build a pretty complete dissector which you can find together with the EHDLC code in this rbs2409 patch which applies on top of the generic wireshark abis_oml.patch

It is my hope that this information (and particularly the dissector) will prove a valuable resource once we add Ericsson BTS support to OpenBSC. If there is anyone who can provide us real BTS (RBS) hardware, please let me know :)

[ /gsm | permanent link ]

Back from DeepSec 2010

I'm back from Vienna where I attended a very exciting DeepSec 2010 conference. This years focus was clearly on mobile security: The GSM security workshop by Karsten Nohl and me, the various talks like All your baseband are belong to us by Ralf-Phillip Weinmann, a talk on Android security auditing / forensics and much more.

In a few days, I'll be leaving for Taipei/Taiwan again. Apart from the one-day GPL compliance engineering course together with Armijn, there will be a number of meetings with various companies - both GPL as well as GSM/3G related.

It will be great to be back to Taipei - unfortunately only for 10 days, which is a real pity. I still miss it a lot.

[ /linux/conferences | permanent link ]

Fri, 19 Nov 2010
Initial mt6235 Linux and u-boot code available

As Marcin announced yesterday on the OsmocomBB mailing list, his initial u-boot and Linux port to the MT6235 baseband processor has been pushed to the git.osmocom.org server. He has also provided some instructions and pre-compiled kernel and u-boot images.

He's now working on the NAND, SD/MMC, GPIO and LCD drivers. If you want to help out, feel free to contact Marcin about this.

Meanwhile, I've been doing a bit of theoretical analysis on the GSM baseband / RF interface of the MT6235, based on the limited documentation that is available to the general public. Seems like it's about time to start with practical experiments soon..

[ /gsm/osmocom-bb | permanent link ]

Announcing Osmocom SIMtrace: A smart card sniffer

During recent weeks I started to do some work related to SIM Application Toolkit (STK / SAT). Debugging this kind of application is hard, as you never really know what exactly is going on between your SIM and the phone, and you don't have the full source code for either of them.

Thus, the need for passively sniffing/tracing the smart card interface between SIM and phone was born. There are commercial solutions which are not only prohibitively expensive, but then they are again proprietary/closed, i.e. you cannot extend them how you want.

There are also some free/open projects like the good old Season scanner, or the slightly more modern RebelSIM Scanner. However, those are really dumb and you have to manually determine the bit-rate using an oscilloscope and then program the UART accordingly. Furthermore, their top speed is often limited. None of this is really useful if you e.g. want to test a variety of combinations between N SIM and M phones, where you don't want N*M times of manual determination of bit-timing on an oscilloscope.

As an alternative solution, I have now created Osmocom SIMtrace. It uses an AT91SAM7S micro-controller as hardware interface between the SIM card interface and USB. It properly sniffs the RST, CLK and I/O lines of the SIM and does auto-bauding, follows negotiation of new bit-rate negotiation via PPS/PTS and re-assembles / segments the APDUs as they come by.

Finally, the APDUs are picked up by a small command-line program that feeds them into wireshark, where you can inspect them like any other communication protocol that you're used to.

The code is still fairly experimental, but for anyone with an interest in this topic it should definitely be possible to reproduce my results.

There is not much specific to SIM cards in this project, by the way. It should work with any ISO 7816-3 T=0 smart card. Adding T=1 is just a matter of software, if you need that protocol..

And now I'm finally off to doing the actual work that I wanted to do.

[ /gsm | permanent link ]

Fri, 12 Nov 2010
A brief history on the withdrawal of the A5/2 ciphering algorithm in GSM

Recently, I wanted to investigate when and how A5/2 has been withdrawn from both GSM networks and GSM phones alike. Unfortunately there was no existing article discussing this history online, so I went through dozens of meeting reports and other documents that I could find online to recover what had happened.

If you don't know what this is all about: It is about the A5/2 air-interface encryption algorithm that was used in certain GSM networks until about 2005-2007.

A5/2 was specified as a security by obscurity algorithm behind closed doors in the late 1980ies. It was intentionally made weaker than it's (already weak) brother A5/1. The idea was to sell only equipment with A5/2 to the countries of the eastern block, while the less-weak A5/1 encryption was to be used by the western European countries.

A5/2 had been reverse engineered and disclosed in the late 1990ies, and has undergone a lot of attention from cryptographers such as Ian Goldberg and David A. Wagner. In a 1999 paper, they already expect that it can be broken in real-time.

It took several more papers until in August 2003, finally, the proponents of the GSM systems (ETSI/3GPP/GSMA) have realized that there is a problem. And the problem was worse than they thought: Since they key generation for A5/1 and A5/2 is the same, a semi-active downgrade attack can be used to retroactively break previously-recorded, encrypted A5/1 calls. The only solution to this problem is to remove A5/2 from all equipment, to make sure the downgrade is not possible anymore.

Starting from 2004 the security related working groups of 3GPP and GSMA thought about removing A5/2, and in the following years they convinced their respective bodies (3GPP, GSMA), and members thereof (operators, equipment makers) to fix this problem.

Ever since that time, it is known that using the same key generation for different algorithms enables down-grade attacks. However, the key generation for the then-new A5/3 algorithm was unmodified. So now that A5/1 has been broken in recent years, even if the operators deploy A5/3, the same model of down-grading attacks to A5/1 can be done again.

I have put down a time-line at the still mostly-empty security.osmocom.org website. Some of the goodies from it:

  • It took from 1999-2007 until this gaping security hole was fixed. Call that incident response!
  • Unnamed Northern American Operators (and the PTCRB) were the biggest blockers to remove A5/2 support from their networks. This is particularly strange since US operators should always have had A5/1 access.
  • As a breaking of the more secure A5/1 was already anticipated even back then, in 2002 A5/3 was first specified. Five years later (2007) there was virtually no support for A5/3 among manufacturers of GSM network equipment
  • It took until January 2009 until the GSMA discussed A5/3 testing with mobile phone makers
  • It took until November 2009 until there was a plug-fest testing interoperability between A5/3 enabled GSM network equipment and A5/3 enabled phones.

And what do we learn from all this?

  • GSM equipment manufacturers and mobile operators have shown no interest in fixing gaping holes in their security system
  • Prior to that first A5/2 attack, they have never thought of procedures for upgrading the entire system with new ciphering systems (i.e. proactive plans for incident response)
  • Even after the A5/2 disaster, they have not learned the slightest bit. The same problem that was happening with A5/1 - A5/2 downgrade attacks can today be done with A5/3 - A5/1 downgrade attacks. And this before the majority of the operators has even started to use the already-7-year-old A5/3 in their production networks.
  • The security work group of 3GPP has had a lot of insight into the actual threats to GSM security even 10 years ago. You can see that e.g. in the Technical Recommendation 33.801. But nobody wanted to hear them!
  • Similar problems exist with the authentication algorithms. It took 12 years from first practical attacks on COMP128v1 until the GSMA is looking at withdrawing it.

[ /gsm | permanent link ]

Sun, 07 Nov 2010
Hashdays 2010 in Lucerne, Switzerland

The last couple of days I've been at #days 2010 in Lucerne / Switzerland. It was the first incarnation of this new IT security conference.

The conference went great, and I think the close-to-200 attendees were a great turnout for the first incarnation of an event. The talks were excellent, as was the delicious food that was served by the Radisson Blu hotel.

The GSM security workshop that David, Karsten and myself held over Wednesday and Thursday was attended by only 7 people, but we had some very lively discussions, particularly with some folks who were working for a GSM operator :)

Most notable about the event is the electronic conference badge, which was developed and produced with a lot of enthusiasm and numerous hours. To be honest, I think I would not have spent that much time on creating this. I mean, developing this type of gimmick is interesting, but then actually manually manufacturing it, without using a SMT line of any sorts - I wouldn't have done that 'just' for a badge. Respects to the team behind that. Hopefully the source code will still get released.

We were also running an experimental GSM + GPRS/EDGE network based on OpenBSC, OsmoSGSN and OpenGGSN, enabling users to run port scans and the like against the carrier-facing side of the IP stack of their own devices. While running this network, I discovered a number of new bugs, mostly in the GPRS stacks of various handsets.

At least one model of Blackberry seems to ignore the MS identity cannot be derived from the network cause of a Routing Area Update Reject message, which we send in case the TLLI of the messages from the phone is unknown. I would expect it to come back with a GPRS Attach Request, but it never does. All it does is to keep re-trying Routing Area Update

The other funny observation is: Several phones, including some iPhone models, react in a strange way if you REJECT them from the GSM network but ACCEPT them on GPRS (Assuming Network Mode of Operation III). They then seem to be perfectly happy with this connection, but will only supply data services and no voice service.

Getting back to the conference, though: The Radisson Blu is an quite costly, upscale hotel. I was really surprised by the type and number of small mistakes they made, particularly with the catering. One day they forget to put the sour cream next to the potatoes - despite a written sign indicating that they are supposed to be with sour cream. Another day they serve some mousse as desert, but there are no spoons placed at the desert buffet. Furthermore, the number of tables they provided during lunch time was always insufficient for the number of people who had lunch. The quantity of food was more than sufficient, though - indicating that it was not a problem of them not knowing the number of people who were eating.

[ /linux/conferences | permanent link ]

All your baseband are belong to us

I'd like to point out the slides of the talk: All Your Baseband Are Belong To Us by Ralf-Philipp Weinmann.

Ralf is one of those few people on this planet who have understood the security implications of now being able to send arbitrary protocol frames (particularly GSM L3 04.08 frames) to mobile phones.

GSM protocol stacks have never been written with the assumption that somebody might send intentionally malformatted messages on the air interface. But at the same time, the GSM network does not authenticate itself to the phone, i.e. everyone who can present a network-side GSM air interface to a phone will be able to exchange arbitrary messages with the phones.

This problem has been outlined in all the GSM security workshops and presentations I have been giving during recent years. Still, apart from Ralf-Philipp Weinmann's work, I have not seen a lot of public research in that area.

Exploiting and owning the baseband processor is a dangerous threat, as the microphone and entire audio path are connected to that very processor. Whoever owns the baseband can turn the mobile phone into a passive surveillance device, commonly called 'bug'. Since application processor and baseband processor are very far apart these days, with various layers of software in between, the user interface will not show any indication of what the baseband processor does.

[ /gsm | permanent link ]

Sat, 30 Oct 2010
u-boot + Linux kernel port to Mediatek MT6235 baseband processor under way

I am really excited about some recent work by Marcin on starting a u-boot and Linux kernel port to the Mediatek MT6235 baseband processor.

Among GSM baseband processors, the MT6235 is a very unusual device. Unlike classic GSM baseband chips, it is not based on an MMU-less ARM7TDMI/ARM7EJS but on an ARM926EJS core. This is a full-blown ARMv5 core on which a standard Linux kernel could run.

The reason for the MT6235 to contain such an 'advanced' ARM core is simple: Mediatek is producing chipsets and reference designs for very inexpensive but feature-rich phones. Instead of going to a full-blown (and expensive) smart-phone design with separate ARM cores for the baseband and application processor, they simply make the base-band processor a bit stronger than needed for the GSM stack, and run the entire rich UI on the same cpu, including TCP/IP stack, touch-screen, web browser, e-mail client, H.264 playback / camera recording, etc.

The original firmware on the Mediatek chipsets is a Nucleus-kernel based software stack which is completely proprietary.

Now the mid-term vision for us is to have a Linux port to the MT6235, and run the OsmocomBB Layer1 (and possibly Layer2) code inside the kernel, while the Layer3 and a user interface program is running as application programs in userspace.

This would allow us to do a very rich user interface (imagine network monitoring modes, protocol tracing, manual cell selection, etc.) while still having to care only about one processor in the system. Furthermore, there are millions of MT6235 based devices, so there will be no shortage of inexpensive hardware to run this code on.

The MT6235 also has a built-in SD/MMC controller (for storing e.g. protocol traces that you take from the GSM network) and it has a fast, dual-mode USB2 high-speed USB controller for connecting it with a PC

Sure, porting our Layer1 to a completely different baseband chipset will be a lot of work, and I don't really have any idea how long it will take us. But I think the vision of such a powerful device (and finally bringing OsmocomBB and the Linux kernel together) should prove a very attractive motivational factor.

This also means: Even if you have no clue about the GSM protocols, you can now start to contribute to OsmocomBB: A lot of Linux kernel drivers for e.g. SD/MMC, USB, frame-buffer, SPI, I2C, PWM and other integrated controllers of the MT6235 need to be written.

Like all Mediatek data sheets, the MT6235 data sheet describing all those peripherals can be found on various places on the Web, including (but not limited to) Chinese developer forums.

It also seems there is at least one MT6235 based phone where JTAG and serial console have been identified (Sciphone Dream G2), which should make debugging and bootstrapping convenient.

[ /gsm/osmocom-bb | permanent link ]

Wed, 27 Oct 2010
The ELCE 2010 keynote by Ari Rauch (Texas Instruments / OMAP)

I've just attended the ELCE 2010 keynote by Ari Rauch, where he was talking about how much TI OMAP is committed to Linux. This doesn't really come as a big surprise to me. The OMAP SoCs are used mostly as Application Processors for smart phones. As TI is not a supplier of APs for Apple, Symbian and Windows Mobile are dead, this really only leaves Linux-based operating systems like Android, Meego, LiMo & co.

One of his main points was we have to be pragmatic, i.e. the customer requirements for performance etc. are key. If there is an open way to fulfill them: fine. If not: fine, too.

The only real question that was asked after the keynote was the usual question of whether there will be any Free/Open graphics drivers for the Imagination GPU thats inside their OMAP3/OMAP4 SoCs. I already predicted the response: We have to be pragmatic about it. TI is trying to convince Imagination to open up, but they are afraid of doing so and don't see what this would gain them.

He further added the statement if there is a competitive more open GPU, they will look into using it.

The other bad taste I got from this keynote is the frequent mention of the industry embracing innovation provided by the FOSS community. Embracing was the very term that Microsoft always used when they started to create their custom versions/dialects of HTML, Kerberos and other standards.

The think that seemed to be missing is any awareness for the sharing attitude: I.e. the industry using the innovations that the community creates, but giving back an equal amount, or at least opening up in response. This cannot be a one-way road where the industry simply taps into the creative potential of the community, to create closed products and profit from stuff they have simply scraped off the community backyard.

[ /linux/conferences | permanent link ]

ST-Ericsson glues gstreamer into Android - and makes it proprietary

It is always surprising what kind of things the industry is coming up with ;)

Here at ELCE, ST-Ericsson has just presented how they replaced OpenCore with gstreamer as the supplier/provider of multimedia encoding/decoding to the Android software stack.

This is definitely an interesting technical solution - probably one that makes sense if you have existing gstreamer modules/drivers.

What really makes me wonder though, is their licensing. To make sure only ST-Ericsson customers can use it, they have implemented a glue layer library that ties into android, and this library is binary-only licensed and distributed under terms that permit to use it together with their hardware.

Isn't it strange? Now the Android software stack is Free Software, and gstreamer is Free Software. But ST-Ericsson needs to put some proprietary blob in the middle. Of course, legally they are allowed to do it: Android is Apache-style licensed and gstreamer is LGPL. But from a moral/ethical/technical point of view, it still is blasphemy to me.

UPDATE: The license is actually a 'standard' proprietary license. There seem to be technical reasons that tie this code to the specific SoC of ST-Ericsson. Nonetheless, I keep my original criticism: It has a bad aftertaste if you combine two FOSS programs by a proprietary layer in between

[ /linux/conferences | permanent link ]

Tue, 26 Oct 2010
GPL compliance workshop on December 2nd in Taipei, Taiwan

The OSSF at Academia Sinica in Taiwan has kindly organized a full-day GPL compliance workshop on December 2nd in Taipei, Taiwan.

Armijn Hemel and myself will be presenting on a variety of topics regarding GPL compliance, both from an administrative/organizational as well as a technical compliance engineering point of view.

I think this is an excellent opportunity to get in touch with product managers and engineers in Taiwan's computing and particularly embedded industry. We definitely still need more awareness in that industry, as the majority of the products in a variety of IT markets are predominantly designed in Taiwan.

So the better the know-how is there, the less GPL violations we will find further down the supply chain and finally in the retail-stores around the world.

Many thanks to the OSSF at Academia Sinica, and specifically Florence Ko and Lucien Lin for making this workshop possible [and giving me a reason to come to Taipei again ;) ]

[ /linux/gpl-violations | permanent link ]

Sun, 17 Oct 2010
The 7th netfilter workshop is coming up

The 7th Netfilter Workshop is just coming up next week in Seville, Spain. Once again it will be hosted at the ETS Ingeneria Informatica of the University of Seville.

I'd like to personally thank Pablo Neira for organizing and hosting the event again in Seville.

As most readers of this blog will know, my current relationship to netfilter/iptables is somewhat dormant. I haven't been writing any code for probably something like five years ago, when I was seriously distracted with stuff like OpenPCD, OpenPICC, OpenBeacon and later the Openmoko project.

Nonetheless, it is always great to learn what Patrick, Pablo, Martin, Jozsef, Yasuyuki and the others have been up to. With a slight chance I may actually still have some advice/ideas or other input I can contribute.

[ /linux/netfilter | permanent link ]

Tue, 12 Oct 2010
GPL violation reports in HTC G2 Android phone

There have been various reports and blog posts about HTC again committing copyright infringement by not fulfilling the GPLv2 license conditions in their latest Android phone, the G2.

While at this point I haven't studied the situation enough in order to confirm or deny any actual violations, let me state this: The number of GPL Violation reports/allegations that we receive at gpl-violations.org on HTC by far outnumber the reports that we have ever received about any other case or company.

In addition, HTC seems to have had a long trail of problems with GPL compliance in their devices. Ever since they have started to ship Android devices containing the Linux kernel, licensed under GPLv2+, we have received those reports.

The reason I have never taken any legal action is merely a result of the fact that HTC seems to first introduce their new devices in the US, then at some point release the corresponding source code before shipping those devices into Europe and Germany. So by the time the devices are sold over here, the legal issues appear to have been resolved before.

Nonetheless, I think it is outrageous for a company of this size and significance in the market to consistently commit copyright violation (or at least walk borderline with it) and thus mistreat the very copyright holders that have created the operating system kernel they use in their devices. The linux kernel developers and the Free Software community as a whole deserve fair treatment.

Also, the competitors of HTC deserve fair treatment: Samsung, e.g. is very forthcoming with their Android phone source code releases. If I was them and would see HTC to fail to comply with the GPL, I would consider filing a unfair competition lawsuit...

[ /linux/gpl-violations | permanent link ]

Sat, 09 Oct 2010
FOSS.in/2010 CfP is closing

I just want to point out: If you haven't yet submitted a proposal for FOSS.in/2010, the FOSS.in/2010 Call for Participation is closing in less than 48 hours!

This means you still have a chance to submit a talk, workout or BoF on your personal FOSS, hacking or otherwise technology related work and actively participate in the event.

FOSS.in is an excellent chance to spread the word about what technical work you have been doing, and to motivate others to participate and join your projects. It's a great opportunity to reach out to the Indian FOSS community, meet old friends and make new ones. Don't miss it :)

[ /linux/conferences | permanent link ]

Thu, 23 Sep 2010
Patrick McHardy explains his Linux DECT stack at Linux Kongress 2010

At linux kongress 2010, Patrick McHardy has just started to give his presentation on the Linux DECT stack he has been working on in the last 1.5 years.

He looked at the deDECTed.org code and found it very limiting, mainly targeted to passively listen into DECT conversations, showing the weaknesses of DSC, DSAA and its implementations. His new DECT stack is meant as a full and generic implementation for receive and transmit.

I'm especially happy to announce that this project will now be hosted under the Osmocom umbrella project at dect.osmocom.org. Right now it only has a README file and the git repository. However, a trac site will be up and running soon.

[ /dect | permanent link ]

Job Offer: GSM baseband security research in Berlin/Germany

If you're following my blog because you have an interest in GSM security related topics, there is currently a very interesting job offer by Frank from GSMK. It is about a job doing research into over-the-air attacks against baseband firmware in real-world GSM/UMTS telephones. Whoever gets the job will likely use/extend OpenBTS, OpenBSC or other GSM foss projects.

So if you're familiar with the GSM/3G protocol specs, have an interest in software security / exploiting and may even have existing exposure to OpenBSC, OpenBTS or OsmocomBB: Please send Frank a message and apply for what I personally consider one of the most exciting opportunities in the IT security industry today.

[ /gsm | permanent link ]

Linux Kongress 2010 in Nuremberg / Germany

Yesterday night I took the train down to Nuremberg, where Linux Kongress 2010 is taking place. It's always nice to meet old friends and colleagues there, including Arnaldo Carvalho de Melo, Patrick McHardy, Lars Marowsky-Bree, Jon Corbet, Jos Vos, Heinz Mauelshagen, Dhaval Giani, Lennart Poettering and many more...

Being on the programme committee might make me biased, but I really think that there is a very impressive talk schedule. What makes me a bit sad is the relatively small audience. I don't know the numbers, but it definitely feels like the lecture halls could hold many more attendees.

[ /linux/conferences | permanent link ]

Mon, 13 Sep 2010
Dell finally releases sources of GPL licensed software on the Streak

Today I have received news that Dell has released the source code of the GPL licensed software on the Dell Streak at http://opensource.dell.com/releases/streak. This includes, among other things, the source code to the Linux kernel they are using on the Qualcomm Snapdragon processor.

This is good news! However, I have not yet checked if that source code release can be considered complete and corresponding as demanded by the GPL. At least it includes a small README file explaining how to build the sources.

I'm not very much into the Android world, but I have heard that Dell is already shipping different Android versions for the Streak. If this is true, then there should be multiple source code releases, one for each binary release they have. If you know more about available firmware versions for the streak, feel free to contact me privately.

Overall, it is great to see this release. On the other hand, it is pretty sad that we've had to do go down the gpl-violations.org enforcement route. Ever since the Streak released in the US months ago, customers are claiming to have contacted Dell forums, emailed Dell Support, asked in the Dell live web-chat and asked via twitter - without the source code being released.

Also, if you are under the impression that the Dell GPL source code as it has been released is incomplete, please let me know the exact technical details of what you think is missing, or why that source code is not matching what is running on your device. Thanks in advance.

[ /linux/gpl-violations | permanent link ]

Thu, 02 Sep 2010
Motorola announces "Ming" phone with Android

For those who don't know: The Motorola Ming was the A1200, a commercially very successful Linux-based phone in China and other parts of Asia, using the EZX software platform, i.e. the kind of hardware that we once built the OpenEZX software.

Motorola has recently announced that they will follow-up with some android based ming phones. It is my suspicion that apart from some mechanical design aspects, those phones will not resemble the ming in any way, neither on the baseband hardware side, nor on the application processor side, and particularly not on the software side.

So it's probably nothing than a marketing coup, trying to connect to successes of the past. Not interesting from the OpenEZX point of view, I guess.

[ /linux/mobile | permanent link ]

Wed, 01 Sep 2010
More GPL enforcement work again.. and a very surreal but important case

In recent days and weeks, I'm doing a bit more work on the gpl-violations.org project than during the last months and years. I wouldn't say that I'm happy about that, but well, somebody has to do it :/

Right now I'm facing what I'd consider the most outrageous case that I've been involved so far: A manufacturer of Linux-based embedded devices (no, I will not name the company) really has the guts to go in front of court and sue another company for modifying the firmware on those devices. More specifically, the only modifications to program code are on the GPL licensed parts of the software. None of the proprietary userspace programs are touched! None of the proprietary programs are ever distributed either.

If that manufacturer would succeed with such a lawsuit, it would create some very nasty precedent and jeopardize the freedom of users of Linux-based embedded devices. It would be a direct blow against projects that provide "homebrew" software for embedded devices, such as OpenWRT and many others.

I've seen many weird claims and legal strategies when it comes to companies trying to deprive developers of their freedom to modify and run modified versions of Free Software. But this is definitely so weird that I still feel like I'm in a bad dream. This can't be real. It feels to surreal.

It's a pity that I cannot speak up more about the specific company in question right now. I'm desperately looking forward to the point in time where I can speak up and speak out about what has been happening behind the scenes.

[ /linux/gpl-violations | permanent link ]

Wed, 25 Aug 2010
Convert RSS feed subscriptions from N810 feed reader to Android com.meecal.feedreader

I'm subscribed to a considerable number of RSS feeds, and so far I actually used to read them all on my Nokia N810, which is more or less permanently located at the bedside table

Now I wanted to import all the subscriptions into an Android RSS feed reader on the Galaxy S. Unfortunately the feed reader that I found most useable doesn't have OPML import. However, looking at its sqlite3 database for feed subscriptions, it was pretty easy to come up with a small perl script to generate "INSERT" statements for all the feeds from the N810 OPML file. In case anyone is interested, the script is available from here.

If you have any suggestions on a good Android RSS reader that can manage large number of subscriptions and put them into a tree/hierarchy of groups, feel free to let me know.

[ /linux/mobile | permanent link ]

Sun, 22 Aug 2010
India jails activist doing research on weak voting machine security

According to several sources such as indianevm.com, Hari Prasad was being arrested. He is part of a team of IT security researchers that gathered evidence to demonstrate how incredibly weak the security of India's voting machines is. For more details, read the indianevm.com article linked above, and the various quotes/links in it.

This is very upsetting. They should jail those who have authorized the deployment of such an insecure system in the first place. Those are the people responsible - not some researchers who go out of their way to uncover the technical problems to warn the general public about the inherent risks of this technology.

I sincerely hope that the authorities will understand the grave mistake they're doing here. Don't shoot the messenger. It's not his fault that engineer, engineering management and/or regulatory government authorities have permitted such a system in the first place.

[ /politics | permanent link ]

Sat, 21 Aug 2010
Started to play with the Galaxy S (GT-I9000) phone

For many years I'm on a more or less consistent hunt for finding a reasonably open and free mobile phone. This started in 2004 with OpenEZX, has continued with Openmoko, project gnufiish and has resulted in a bit of peeking and poking in the Palm Pre. However, none of those projects ever had the success I was hoping for:

  • OpenEZX was never really finished, and only for the 1st generation phones (A780) by the time they were long end of life
  • OpenMoko Neo1973 and FreeRunner were a great project, and they are still the most open+free mobile phones that ever existed. However, they're GPRS only and the hardware is even more outdated now then it was when we created it.
  • gnufiish was an attempt of running software from the Openmoko days (such as freesmartphone.org) on some E-TEN glofiish phones. However, we never could make the SPI-based modem communication work from our re-engineered Linux driver :(
  • Palm Pre is an interesting device, in that Palm provides easy root access, does not attempt to lock the device down with cryptographic signatures and provides full recovery flashing tools by means of WebOS Doctor. But once again, the proprietary communication protocol with the 3G Modem was the big blocker item for using real custom software and not the WebOS stuff they ship.

So I've constantly been on the watch for new devices that are coming out. Most of the phones you can buy in recent years are either running proprietary software like Windows Mobile, Symbian, Apples iPhone-OSX - or they run Android but then use some integrated Qualcomm Smartphone-on-a-chip product. The problem with the latter (from a Free Software point of view) is that Qualcomm is very secretive about their products, does not provide any kind of public documentation, and the ever-increasing integration between application processor and baseband processor makes it more difficult to run custom software on them.

The Samsung Galaxy S (GT-I9000) seemed like a good candidate to me, for several reasons:

  • Samsung does not use cryptographic signature techniques and gaining root as well as flashing the AP software is relatively easy
  • The phone is based on a traditional separate application processor (AP) and baseband processor (BP) design. The AP is a Samsung S5PC110, the BP is some Qualcomm MSM6xxx.
  • High-end hardware, with the S5PC110 running at 1GHz and 512MB RAM
  • Samsung provides excellent "GPL source code offers" containing the Linux kernel used in their firmware - including detailed instructions in how to build it. Also, many of the drivers are included under GPL, such as drivers for all the integrated peripherals of the SoC, some custom components like the USB multiplexor ASIC, etc. as well as the driver for the dual-ported RAM between the AP and BP for the 3G Modem communication
  • The Android RIL shipped by Samsung contains lots of debugging/decoding/dumping code that can make reverse engineering the AP/BP protocol.

So right now I'm in the exploration phase, making myself familiar with the bootloader, the flashing process, the userspace ABI of the custom (GPL licensed) kernel drivers, etc. It's a fairly pleasant experience so far, and I now have a debootstrap'ed Debian lenny on an additional ext2 partition on the SD card. This provides me with an actually useful userland I can chroot() into, such as lsof, strace, ltrace, tcpdump, etc. to do some more exploration of the phone.

The only real ugliness on the software side so far is the use of proprietary Samsung filesystems (RFS/TFS4). The only reason those filesystems existed, as far as I can tell, was to run legacy filesystems like FAT on top of raw NAND or OneNAND flash. This is mainly necessary if you want to export e.g. a FAT partition via USB Mass Storage to a Windows PC. However, the GT-I9000 doesn't have any OneNAND, but only an internal moviNAND (basically a SD-Card in a BGA package that you can solder on the board). MMC/SD cards already include the wear leveling algorithm, so there is absolutely no point (from what I can tell) in running the RFS/TFS4 stack.

In fact, in several forums people are complaining about the slow I/O performance of the Galaxy S, and they have a much better performance when using ext2/ext3 directly on that moviNAND device.

[ /linux/mobile | permanent link ]

Tue, 17 Aug 2010
Doing RFID related research and development again

More or less a bit surprising to me, I got again involved in RFID research, on which I hadn't really done much ever since my involvement in the OpenPCD and OpenPICC projects some five-to-four years ago.

It's a lot of fun, and I didn't seem to forget much. What really bothers me a bit is that the OpenPCD / librfid / OpenPCD integration never really was completed, and that libnfc doesn't work with OpenPCD. Let's hope I'll somehow find some time to change this. It just feels wrong that OpenPCD was the first hardware project created to encourage (security) research into RFID, and now all the current tools only run on the Proxmark or on proprietary readers...

[ /linux/mrtd | permanent link ]

Sat, 14 Aug 2010
Worlds first 20 minute voice call from a Free Software GSM stack on a phone

As Dieter Spaar has pointed out in a mailing list post on the OsmocomBB developer list, he has managed to get a first alpha version of TCH (Traffic Channel) code released, supporting the FR and EFR GSM codecs.

What this means in human readable language: He can actually make voice calls from a mobile phone that runs the Free Software OsmocomBB GSM stack on its baseband processor. This is a major milestone in the history of our project.

While Dieter has been working on the Layer1 TCH support and the setup of the voiceband path in the analog baseband chip (audio ADC/DAC), Andreas Eversberg has been quietly working on getting call control of Layer3 into a state where it can do all the signalling required for mobile-originated and mobile-terminated call.

Combining both of their work together, they have been able to make a 20 minute long voice call from a baseband processor running a Free Software GSM stack. For all we know, it is the first time anything remotely like this has been done using community-developed Free Software. Five years ago I would have thought it's impossible to pull this off with a small team of volunteers. I'm very happy to see that I was wrong, and we actually could do it. With less than half a dozen of developers, in less than nine months of unpaid, spare-time work.

Sure, the next weeks and months will be spent on bringing the code from alpha level to something more stable, fixing known issues and known bugs, etc. But I'm confident the biggest part of the work on the OsmocomBB stack is behind us. Big thanks to the developer team driving this project forward.

[ /gsm/osmocom-bb | permanent link ]

Fri, 13 Aug 2010
Wondermedia WM8505 Linux + u-boot source code

In recent months, a number of alleged GPL-violation reports regarding products (tablet computers, mini netbooks and the like) using the Wondermedia WM850x line of ARM SoCs. People have been contacting me, as I was working as VIA Open Source Liaison, and there is the general belief that VIA and Wondermedia Technology (WMT) are one company.

I had investigated this issue even before there were any reports, and I'd like to publicly state that:

  • Wondermedia is a separate company from VIA, with independent management, making their own business decisions. The 850x SoC development was started inside VIA, but is no longer part of VIA for a long time.
  • Any references to VIA in the source code or old data sheets date from that time before the SoC business became part of Wondermedia
  • I have had assurances from Wondermedia, even before there were any allegations, that similar to VIA they explicitly notify their customers about the GPL and always provide their SDK / BSP as full corresponding source code.
  • Effectively, this means that GPLv2 Section "3a" is used. WMT has provided the Linux and u-boot source code to its customers, and thus has no obligation under GPLv2 Section "3b" to provide it to anybody else (any 3rd party)
  • So, if you buy a product including a WMT SoC and u-boot/Linux, like always, GPL compliance of what has been shipped to you has to be assured by the manufacturer of the product, not the semiconductor maker

Notwithstanding all of the above, Wondermedia was willing to provide the Linux kernel and u-boot source code of their SDK to me, so I can share it with the community. As indicated, they're not legally required to do this and I'm happy they do it anyway to show their good intentions.

You can download the released source code from the gpl-devices.org ftp-server, more specifically here are the latest Linux kernel (modified 2.6.29 android derivative) and u-boot source code archives.

This software is provided without any kind of support. If you see some GPL related legal problems (i.e. you believe it is incomplete), don't hesitate to contact me. To the best of my knowledge WMT (basically a small hardware start-up with small software development team) has no resources to actively push any of this mainline.

[ /linux/via | permanent link ]

Sun, 08 Aug 2010
Working on a document on smartphone hardware architecture

I've started to write upe some information on modern smartphone hardware architecture. It will be in a similar style to what I previously wrote on feature phones and gsm modem hardware, but with a specific focus on smpartphones, their multiple processors, memory sharing, AP/BP interface, audio architecture, etc.

I should have done this a long time ago. In fact, I think I should write more documents like that on various technical subjects. If you want to learn about low-level aspects of modern telephones, there is way too little published information out there.

[ /gsm | permanent link ]

Sat, 07 Aug 2010
On my way to Taiwan for COSCUP

Tomorrow early morning I'll be on my way to Tapei/Taiwan. The main reason for this trip is the invitation to speak at [ /linux/conferences | permanent link ]

Wed, 04 Aug 2010
Official wiki page on GSMTAP created

I've come up with GSMTAP about two years ago while working on airprobe. The goal was to have something similar to what radiotap does in the wifi world: A pseudo-header that adds additional information and context that is not present in the actual message.

Initially, GSMTAP was intended to be a separate link-layer type in the pcap file format, but this would preclude its use in real-time protocol analysis. So I modified it to be encapsulated in UDP packets, which are sent and received using normal UDP/IP sockets.

Over recent years, GSMTAP has not only been integrated into multiple programs of the airprobe project, but is also understood by wireshark. OpenBTS has also decided to adopt the format and can generate GSMTAP messages for debugging purposes.

After creating OsmocomBB, it was taught how to generate GSMTAP messages very quickly, too.

So by now, at least when it comes to Free Software, it is definitely the de-facto standard for capturing/transmitting and analyzing protocol messages from the GSM air interface.

However, until now, there has never been any official "homepage" of the GSMTAP header. This has changed now, the GSMTAP homepage is now part of the OsmocomBB wiki.

[ /gsm | permanent link ]

Playing more with Erlang

Last year I started to occasionally play with Erlang. People who know me as die-hard C coder who tries to avoid C++, Java and Python wherever possible will probably be surprised here now.

I have no intention of changing my general position on programming languages. I don't feel comfortable using something where I don't know and/or understand the immediate impact on how this code will be executed on the actual silicon.

However, if you have a need to play with anything that uses ASN.1, but particularly the aligned/unaligned PER encoding variants, then it is pretty clear that there is nothing available as Free Software that can compare to the Erlang asn1ct/asn1rt modules.

At that time last year I was doing some rapid prototyping with the RANAP protocol, and the progress was quite quick. I never had time to return to that project, so it (and my Erlang skills) were left dormant.

In recent weeks, I have picked Erlang up again - again to work on ASN.1 encoded messages: This time TCAP and MAP. While we still need the in-progress TCAP+MAP implementation in C for OsmoSGSN, there are other tasks at hand where an Erlang-based implementation might yield a much higher productivity.

So right now I'm working on a program that parses/decodes and iterates through every MAP component in a TCAP message and replaces certain fields, re-encodes the entire message and sends it off the wire. Once that is done, I think I'll actually try to do a more complete TCAP server and implement a simplistic HLR for OsmoSGSN testing.

[ /gsm | permanent link ]

Sun, 01 Aug 2010
On the recent news items about the homebrew IMSI-catcher for 1500 USD

Some news sites seem to do very limited research and present it as big news that you can now build an IMSI-Catcher for a budget of USD 1500, using OpenBTS and a URSP.

Let me bring some clarity into this situation:

  • Fundamentally, an IMSI-Catcher is nothing special but a GSM base station (BTS) that is configured to the network country code (NCC) and mobile network code (MNC) of a commercial network operator.
  • In GSM, the phone has no way to authenticate and thus verify the legitimacy of the mobile network. This is like a "rogue access point" in a open (unencrypted/unauthenticated) WiFi network.
  • Thus, anyone who has a device that can run as a GSM base station has the ability to run an IMSI catcher.
  • There are two Free Software / Open Source projects for running your own GSM network, both have first been published in 2008: OpenBTS and OpenBSC.
  • None of those two projects are intended to be used as an IMSI-Catcher but for legitimate operation of GSM networks. However, if a user choses to configure the NCC and MNC of a commercial operator and allow "unknown/unregistered/unprovisioned IMSIs (SIMs) on his network, he will effectively have an IMSI catcher.
  • Such operation is in violation of spectrum usage regulations, even if you have a valid test/experimental license, since that license does not permit you to use somebody else's NCC/MNC.
  • Furthermore, such operation is in violation of criminal law in most jurisdictions. In Germany there is a separate offense in the criminal code, called Paragraph 317 Stoerung von Telekommunikationsanlagen, combined with Paragraph 202b Abfangen von Daten.
  • Furthermore, there are certainly civil claims to be made by the affected operator (and its subscriber) against anyone who unlawfully operates such a fake base station
  • OpenBTS and OpenBSC, as well as the problems resulting from this fake base station attack have been covered in a variety of conference presentations from 2008 through today.
  • Thus, there is nothing new about what has been presented at Defcon 18

Also, the theoretic basics ow how to operate an IMSI catcher are nothing new either. There are even a number of patents covering IMSI catchers, the first that I know of has been patented by Rohde & Schwarz in 2003. Also, see this blog post by OpenBTS founder David Burgess on this topic.

So all that you always needed is a bit of hardware and software to send radio waves containing messages formatted in the way how they are described in the (equally public) GSM specifications as published by ETSI and 3GPP. Commercial, proprietary systems have existed for a decade. From 2008 on, there is some Free / Open Source Software to operate GSM networks. The situation remains unchanged in 2010.

So please, remember this the next time somebody is trying to tell you that this is the latest invention since sliced bread.

[ /gsm | permanent link ]

Sat, 31 Jul 2010
GSM Denial of Service by flooding BTS with RACH requests

At Blackhat US 2010, there was a Talk that (among other things) apparently included the subject of a RACH DoS on GSM base stations, implemented using my Layer1 of the OsmocomBB software.

As some news sites are covering this as "news": This vulnerability has been long known in the field and was - to the best of my knowledge - first demonstrated to a public audience by Dieter Spaar at the Deepsec 2009 conference in November 2009. You can get his slides.

The difficult part for many years has not been to know about the possibility of this weakness. Anyone who has read the GSM air interface specification will inevitably see that there is a limited number of RACH slots and a limited number of dedicated channels. Once you fill more RACH slots than the cell has dedicated channels, and you keep re-filling them at a higher rate than the cell can expire those dedicated channels, you have a DoS.

So rather, the difficult part was to implement it in practise, as traditionally all GSM baseband chipsets have been extremely closed, just like the very software (firmware) running on them. Today, starting from Q2/2010, it is very easy to do a proof-of-concept implementation, as we have created OsmocomBB: An Open Source baseband firmware.

Dieter Spaar's implementation predates OsmocomBB development by the better part of a year. At that time, he had to resort to binary-patching existing proprietary (binary-only) baseband firmware. So I think people should recognize his effort in doing the first practical implementation of that attack.

[ /gsm | permanent link ]

Dieter Spaar has started a blog

Dieter Spaar, who has been involved in various ways with both OpenBSC and OsmocomBB has just started a blog. This is good news and I hope this way he will get a bit more (much deserved) exposure on his great work.

[ /gsm | permanent link ]

Fri, 30 Jul 2010
A real-world practical A5/1 attack using airprobe and Kraken

At Blackhat USA 2010, Karsten Nohl has been presenting on a practical real-world A5/1 cracking attack. For recent years, Karsten, myself and others have been speaking at various opportunities, indicating that a practical attack using readily-available information and tools from the Internet is very possible, and that it is only a matter of time for somebody actually does it.

While Karsten has focused on the actual cryptographic attack, I've been putting in some time in projects like airprobe (a GSM receiver/decoder).

Now finally, a team of friends at the new Security Research Labs (founded by Karsten) in Berlin has put the pieces of the puzzle together.

Airprobe has been extended to fully support decoding of TCH/F (FACCH, SACCH and traffic), as well as SDCCH/SACCH control channels, and to specify the timeslot and physical channel configuration from the command line. Using this, you can

  • decode the AGCH, wait for an IMMEDIATE ASSIGNMENT of a SDCCH
  • decode that very SDCCH and wait until encryption is turned on
  • dump an encrypted burst where you have sufficient known plaintext
  • use a different program to actually recover the A5/1 ciphering key
  • feed that key into airprobe and decrypt+decode the ASSIGNMENT COMMAND of the TCH
  • use airprobe to decrypt+decode that assigned TCH/F

The external program to recover the A5/1 ciphering key is called Kraken and is also available from the SRLabs website.

So what are the limitations? Well, so far this only works on non-hopping cells with a single ARFCN. The limitations are those of the receiver hardware (and SDR software), and not really limitations of the airprobe GSM decoder or the actual software tools.

In the past I would have assumed that non-hopping and/or single-ARFCN cells are rare, but in fact we can find them even inside a big city like Berlin, from at least two of the four German GSM operators. So that's why this attack is very practical, no matter what the GSMA might say.

[ /gsm | permanent link ]

Thu, 29 Jul 2010
I'm still alive ;)

In case you're wondering why there is such a long period with no updates: I've been travelling over the last week and barely had sufficient time to follow my e-mail and get the most high-priority work done. Hope to update the blog soon.

[ /personal | permanent link ]

Sat, 17 Jul 2010
More musings on locked-down mobile phones

In recent days, the story about Motorola locking out its users (and developers) from their more recent Droid phones has made big news. As it seems, the exact functionality implemented by eFuses remains unclear, and the behavior of Motorola might thus not be too different from what has more or less become the industry standard.

For those of you who are not following the mobile world as close on a technical level as people like me do: In the last five years, more and more cellphone manufacturers have used cryptographic code signing to lock-down the software that you can run on the phone. Major parts of the system including the software update mechanism and the bootloader on the device contain a verification process of those cryptographic signatures to ensure that you can only software signed by the phone manufacturer.

I have seen this with the MotoMAGX phones like the ROKR2 v8, various Windows Mobile handhelds from HTC, The non-developer (non-ADP) version of the Google/Android G1 and many other phones.

This puts the user into a strange situation where he buys some hardware from the manufacturer, but yet doesn't have control over what this device does. Just imagine buying a computer, but being limited to run Windows 98 and Office 97 on it. You could not update to a later version of the operating system, and you could not install an alternative operating system such as a version of GNU/Linux. If the computer vendor decides that he will drop support for it, you will not even be able to install security updates to the operating system.

From my point of view, this is an abusive, anti-competitive behavior by the manufacturer. For no reason but his ever-growing hunger for power he makes you completely dependent on his decision. It is not in the control of the user, what operating system or even applications you can install. It is under the control of the manufacturer.

I would accept this if the phone was rented. In this case, I would only pay a small rental fee, but the phone is the property of the manufacturer and I am only using it. But the manufacturer actually sells the device. He wants to be paid the full price, but still not actually hand control over to the buyer.

Compare this with buying a CD-player that has arbitrary restrictions so it would only play CDs from one of the major music labels/distributors like EMI, but not CDs from any of the other publishers, for no technical reason whatsoever. Or buying a TV set that is locked down so you can only watch one TV channel, while you need to buy another TV for a different channel.

I actually think the antitrust authorities should investigate this behavior of the mobile phone industry. Simply compare it with the PC situation and look at the fact how often Microsoft has been judged in some kind of anti-competitive behavior in the PC world. In the mobile phone industry, the situation is worse than it ever was in the PC world, yet we do not see big antitrust cases being brought forward.

And please don't buy those pseudo-arguments that this has any relation to regulatory/FCC approval or the safety of mobile networks themselves. The entire software stack interacting with the mobile network runs on a separate processor (the baseband processor) anyway. It doesn't matter what you install on the application processor. Once again, compare it to laptops: You can insert a 3G miniPCI, expressCard or USB dongle. Inside this dongle you run the communications stack on a processor that is completely different from your main processor that runs your regular OS (be it GNU/Linux, OS X, Windows, Solaris or whatever makes you happy).

[ /linux/mobile | permanent link ]

Fri, 16 Jul 2010
Motorola locking down the DroidX and Droid2 in a nasty way

There are plenty of reports in recent days about the level of locking-down that Motorola is apparently doing on their most recent Android products, the Droid 2 and the Droid X.

This goes as far as to an (I believe unconfirmed) slashdot.org report claiming that not only there is the more or less typical DRM on software (i.e. cryptographic signature validation chain), but there also is an eFuse that that is blown if something happens wrong during the booting process.

To the best of my knowledge (and I'm doing mobile phone reverse engineering for about 6 years now), this is the first time I hear of something like this. If true, it sounds pretty dangerous to me. What if something goes wrong during an update (such as a power failure during software update)? What if you really have a non-correctable multi-bit error in your NAND Flash? In that case, cryptographic verification of the firmware fails and the eFuse would be blown, resulting in your device being a brick. This could eventually backfire massively to Motorola.

The best comment from the slashdot.org thread:
You can legally buy a gun that only shoots in the direction of the person pulling the trigger, but it doesn't mean it's a good idea.

Reading something like this almost makes me very depressed. Motorola is benefitting from the billions-of-dollar-worth development of existing Free Software projects like the Linux kernel, but they now want to take away the fundamental right to run modified versions of that very software. Somebody needs to slap them with a very large trout.

I'm not really surprised that they are doing it, though. Motorola has shown that direction even years ago when they first used SELinux as part of their later pre-Android Linux phones (EZX and MAGX). They didn't use it to enhance the security of the user, but to enhance the security _from_ the user.

Please also note this great post by Bradley M. Kuhn on the subject matter. If you don't know Bradley, he's been doing GPL enforcement for the last 12 years - for the Free Software Foundation and the Software Freedom Law Center. In his post, he actually thanks Motorola to publicly state that they actually want to lock their phones down (as opposed to Apple).

What's even more interesting though is his elaboration on the scripts to control compilation and installation clause of GPLv2. This is indeed something that most people tend to overlook when it comes to GPL[v2] compliance and we see this a lot during our gpl-violations.org work.

And in fact, for a very long time, I have been teaching and educating this fact during my GPL related talks and trainings: In software specific for embedded devices, the scripts to control installation are incomplete, if you do not provide a means to install the software onto the actual device. Where else would you be reasonably install the Linux kernel image that is made specifically to work on such a particular mobile phone model? Due to the custom nature of Linux kernels for embedded targets, it wouldn't even run anywhere else.

I've never taken any such issue to court so far - but it was a frequent dispute in out-of-court GPL enforcement we've been doing at gpl-violations.org. I'm definitely curious to see what will be the first court case addressing that issue. The ever power-hungry manufacturers of mobile phones seem like they deserve it.

UPDATE:
Apparently Motorola has released some statement that denies they use eFuses to brick the device. All it does is to render the device unable to boot until some Motorola-certified/signed/authorized software is loaded on the device again. They did not specify how that could be done, though. Still, even without the eFuse bricking, I find it outrageous that the Industry (including Motorola) expect their customers pay hundreds of dollars for a device that is then still owned by Motorola rather than that very customer. It's like selling something but still retaining ownership of it. Doesn't that make you feel strange, too?

[ /linux/mobile | permanent link ]

Sun, 11 Jul 2010
Implementing the TCAP protocol, heading towards OsmoSGSN SS7 support

The protocol by which traditional GSM core network components interact is called MAP (Mobile Application Part). MAP itself is a user of the TCAP (Transaction Capabilities Application Part) protocol, which in turn runs on a SS7 protocol stack (i.e. SCCP over MTP or M3UA or SUA over SCTP).

For those users of OpenBSC who have a need to interoperate with other GSM networks (roaming), the circuit-switched part of OpenBSC has so far relied on the use of a proprietary MSC (by means of the A interface). This closed MSC then talks MAP/TCAP/SS7 to roaming partners.

However, on the GPRS front, we now have OsmoSGSN. However, as opposed to the BSC on the circuit switched side, the SGSN directly interacts with the core GSM network components (both of the home network and the roaming partners).

So in order to run OsmoSGSN interacting with existing HLRs, we need to add a MAP/TCAP/SS7 interface to it. Once this has been done for the SGSN, we of course can do the same for the MSC-part that is currently integrated with OpenBSC.

As there are existing implementations of SCTP (inside the Linux kernel) and SUA (sualibrary), TCAP is the next step in the protocol stack that needs to be implemented. I've been digging into TCAP for the last week(s), and believe I finally understood every part of its operation.

You can think of TCAP as something that facilitates the transport of request-response type transactions over a datagram oriented transport layer. It intends to have lower overhead than a connection-oriented service (e.g. establishing TCP sessions) and supports features such as aggregating multiple user-messages (called components) in a single actual transport-layer message. The idea is to reduce the overhead of message headers and routing.

TCAP is (unfortunately) specified in ASN.1 and thus requires significant effort to parse and construct. Right now I'm using Lev Walkin's asn1c ASN.1 C code generator to generate the parser and constructor functions. The actual TCAP protocol logic is once again implemented in plain C, using the various concepts and utility functions established in OpenBSC (and now part of libosmocore).

The implementation is making good progress and I hope I can do some early testing in about a week from now, and successively move straight to the MAP protocol, implementing at least those parts that we need for GPRS authentication and attach / routing area updates.

[ /gsm | permanent link ]

Thu, 08 Jul 2010
COSCUP 2010 conference schedule has been posted

The Schedule of the COSCUP 2010 conference has been posted on the conference homepage. I'm happy to see such a large number of talks from a wide range of speakers - including many friends from my time in Taiwan a couple of years back for Openmoko...

As it seems from this chinese blog entry, the organizers were overwhelmed by the number of attendee registrations, with all 610 available seats being occupied within 85 minutes of opening the registration. It seems they are in need of a bigger venue next year ;)

[ /linux/conferences | permanent link ]

Mon, 05 Jul 2010
Family visit is keeping me busy

In case you're expecting a quick response from me these days, please apologize. I'm currently having family visiting me in Berlin, and I very much enjoy being the personal tourist guide for some days...

I shall be back to normal by the end of the week.

[ /personal | permanent link ]

Fri, 02 Jul 2010
Major update in OpenBSC GPRS/EDGE support

Through the last couple of days, I've been in extreme bug-squashing mode for the GPRS/EDGE code base in OpenBSC (mostly the OsmoSGSN program). I'm now at a point where I can reliably establish PDP contexts and access the Internet from a variety of different phones with different baseband chipsets and GPRS protocol stack implementations. All so-far-known bugs regarding fragmentation/reassembly, sequence numbering and other issues have been fixed. There definitely are plenty more, but we first need to find them.

Since it's working reliably now, it's quite fascinating what the various phones do after connecting to the GPRS network. Like Windows Mobile phones sending Netbios Name Service updates (and requests), which I think is funny considering that they are sent to a network that is typically considered to be the public Internet.

But to be fair and not anti-Windows, my Google/Android G1 also makes some https connections back to Google - and I don't know what they are for [yet].

In any case, with OpenBSC, OsmoSGSN and OpenGGSN anyone interested in doing true security (and privacy) research with mobile phones is now able to do so. Using those programs, you can run your own GPRS+EDGE network and can see first hand what your phones are doing on a cellular network, what kind of data they are sending back home. In this setup, there is no packet filtering, NAT, deep packet inspection and no intrusion detection systems between your PC and the IP stack on your phone.

[ /gsm | permanent link ]

Mon, 28 Jun 2010
The reason why you see paging by IMSI in real-world GSM networks

During my work on airprobe and OsmocomBB I've been wondering why you see paging by IMSI in real-world GSM networks.

A quick recap: The IMSI is the world-wide unique serial number of your SIM. Since it is easy to identify and track people, the TMSI was introduced as a temporary identifier that is frequently re-allocated over encrypted channels. The only reason for the TMSI to exist is to prevent tracking of a subscriber by watching where his IMSI appears on the paging channel.

According to the theory, the IMSI is only used when first registering to any GSM network. At that time, a TMSI is allocated to the SIM card in the phone, and this TMSI is used for the next transaction(s). Later, this TMSI is re-allocated and re-allocated, but the IMSI shouldn't show up again in any paging requests.

Even if you switch mobile networks (i.e. in the roaming case), you would once send the IMSI as part of a LOCATION UPDATE REQUEST or IDENTITY RESPONSE, but the network has no need to page the SIM by IMSI.

So far the theory. If you look at the Paging Channel (PCH) of cells in real-world networks, you see a significant (10-20%) amount of paging requests that contain paging by IMSI. This seems strange on first sight, given the theory described above.

I have the following plausible explanation for this:

  • The VLR keeping the IMSI-TMSI mappings doesn't have non-volatile storage. This means at a VLR restart, all the TMSI allocations will be lost, and the network has to resort to paging by IMSI.
  • The VLR has a limited amount of RAM, which can store a limited number of IMSI-TMSI mappings. Especially if the operator is interested in saving money, the amount of memory is insufficient for all subscribers in the network. This means, the VLR will expire some old entries in the mapping table to store new entries. Thus, mobile phones whose last transaction with the GSM network was relatively long ago are likely candidates for such VLR expiration. Once a phone for an expired entry needs to be paged again, paging will happen by IMSI.
  • Last, but not least: GSM networks do not page a phone by the last known cell, but by the last known location area of the phone. A location area might be relatively big. This means that at any cell you will see a lot of paging messages, even for phones that are not even anywhere near this cell. If there is no response within the location area, the MSC might decide to do paging on a larger radius, possibly the entire MSC area. Since such MSC-wide paging is likely to occur for phones that haven't shown activity for a long time (and thus might have moved or disappeared without properly unregistering from the network), those are the exact same phones for which the IMSI-TMSI mappings have expired from the VLR. Thus, the rate of paging-by-IMSI looks disproportionately high.

So the relatively high percentage of paging by IMSI vs. TMSI should not be taken as a measurement with regard to the total number of transactions or even the total number of subscribers. It is simply the mechanics of the network resulting in a distortion of those figures caused by phones that have never properly unregistered from the network.

[ /gsm | permanent link ]

Sun, 27 Jun 2010
Back from OpenBTS workshop

I've just returned back from the First OpenBTS workshop held by David Burgess and hosted by Dieter Spaar in south-east Bavaria (Germany). While I'm not involved with OpenBTS so far (except from using it occasionally), I still thought the community surrounding Free Software / Open Source in the GSM field is small enough to make me participate.

On the request of the participants, I also did a short demonstration of both OpenBSC and OsmocomBB. And just like I managed to crash OpenBTS by accidentally sending invalid messages, my OpenBSC demo crashed at some point [due to a not-yet-known bug regarding SMS delivery. I suppose the intrusive changes of the BSC/MSC split are to be blamed for that. But I don't mind, we need that split...

I definitely had a great time meeting the participants of the workshop. There definitely is a very diverse crowd with equally diverse reasons for their interest in using and/or deploying OpenBTS.

Finally, there was a chance to discuss the need for a common 'application interface' in both OpenBSC and OpenBTS. Using that interface, external applications (e.g. implementing USSD or RRLP) could be written in a way to work with both OpenBTS and OpenBSC. I hope we can get started on this soon and remove another bit of fragmentation in what is already a fairly small special interest community...

Given the excellent weather conditions, the motorbike ride to and from the venue went fine - despite being at 650 km distance from my home.

[ /gsm | permanent link ]

Sun, 20 Jun 2010
Adding frequency hopping support to OpenBSC

During the last couple of days, I've been adding the bits required to support frequency-hopping BTSs in OpenBSC. Now everything looks great in the protocol traces - but unfortunately it still doesn't work, at least not with the Siemens BS-11 that I have access to.

Will continue to try to make it work. The big advantage of having a hopping BTS under our control is that we can define the hopping sequence - something quite useful once we get to the point where we'd like to add frequency hopping to the telephone-side stack (OsmocomBB).

The good news is that I had to fix lots of bugs in the A-bis OML dissector for wireshark that I wrote some time ago. It's now much more complete and definitely a big step further towards eventually getting it included in wireshark mainline.

[ /gsm | permanent link ]

Tue, 15 Jun 2010
A fairy tale about ICCIDs, IMSIs and iPads

One of the big news of the last week is AT&T's leak of 114,000 iPad customer records including the e-mail address and ICCID

While that leak is certainly a big issue in itself, there are some people, most notably Chris Paget, who claim that this is much more serious than generally assumed. The main claim here seems to be that ...in order to translate an ICCID into an IMSI, you need to query the HLR.

I have been reading GSM protocol specifications on every level for the past years, and never have I seen the ICCID being mentioned anywhere. The GSM specifications do not require this information to be stored in the HLR, and the MAP protocol (used on the C interface between MSC and HLR, see 3GPP TS 29.002) does not even know how to encode/specify it.

Also, there is no technical need for it. The ICCID is never used nor needed in any part of the GSM protocol. Also, the GSM network typically doesn't store any information that is not absolutely necessary for its operation. The only identifier of a SIM card that the network protocols care about is the IMSI.

So unless the US operators in question have either some kind of proprietary extensions to both their HLR and the MAP protocol, there is to the best of my knowledge no way how you can relate the ICCID to the IMSI.

And thus, as a result, the IMSI-catcher attack described will not work since you don't know the IMSI of the SIM card (associated with the customer record) that you want to catch.

If anyone can show me hard technical facts about ICCIDs being used in the HLRs of the operators in question, I am happy to post here I was wrong. Otherwise, I would hope everyone else could also come down to the hard technical facts, i.e. which particular MAP message is used for this alleged ICCID-to-IMSI query.

UPDATE: As some people have discovered, the three US operators themselves have decided that they use the same number to generate both the ICCID and the IMSI. So if you have one, you can compute the other. No need for HLR access, no need for the MAP protocol. So the information leak is in fact unrelated to the GSM protocol but simply a matter of how unfortunate those particular three operators assign their unique identifiers.

[ /gsm | permanent link ]

More thoughts on FSF action against Apple over GNU Go

Last week, I blogged about the FSF action against Apple. This week, I intend to add a bit to that.

As it has been pointed out to me, Apple has immediately removed the GPL-infringing software from its app store. This of course means they have refrained from further infringing the GPL. It is not publicly known if they have made a declaration to cease and desist or not.

So yes, by removing the software that was distributed in violation of the GPL terms, Apple has done legally the right thing: Reduce the danger/risk of committing further (knowing) infringement.

The FSF (and probably the Free Software community in general) of course want something else: For Apple to alter their app store terms in a way that would enable software authors to have Apple distribute their GPL licensed software in it. While this might be possible very easily with small modifications to their legal terms and to the implementation of the app store, it is probably not quite easy to make a legal claim and try to force this upon Apple.

Anyone always has the choice to either distribute GPL licensed software compliant with its license terms - or not distribute it at all. If Apple prefers the latter, this is very unfortunate (and you might call it anti-social or even anti-competitive) but something that they can very well do.

The only questions that I see remaining from a legal point of view: What about the previous GPL infringements? What can (and/or has) Apple to do in return to the previous distribution of infringing software? This is where the legal pressure of the copyright holders leaves room for negotiation. Instead of monetary damages (which don't really resolve what the GPL aims to do), there could possibly be a solution where Apple has to provide the GPL license text and complete corresponding source code to the Go program through their app store. And while they're at it, they might just solve the distributing source code for copyleft style licensed software problem in a generic way. Or they might just decide that they're stupid and stubborn and not interested in solving any problems in the first place.

[ /linux/gpl-violations | permanent link ]

Fri, 11 Jun 2010
My take on the FSF action against Apple over GNU Go

About two weeks ago, the FSF announced that it has taken action against the Apple App Store over their distribution of GNU Go. This has apparently set off some people like lefty and triggered a length and wide debate.

I personally very much support the action the FSF has taken. Anyone involved in distribution of copyrighted material is required to do due diligence on checking that he actually has a license to do so. This is not really related to the GPL.

Yes, this means that I can take GPL enforcement action to a retail store that is selling/distributing infringing products, and I can make them provide a declaration to cease and desist from further infringements. Of course, that declaration would only be valid for this single retail store. This is why in our gpl-violations.org work, we always try to go after whatever entity is responsible for the majority or all of those infringements, rather than after a single store owner.

The reason for this is simple: In many cases, it is impossible for you as the rights holder to find out who sold the product to the retail store, and track the entire supply chain back to whoever caused the GPL violation in the first place. Also, some of those entities might reside in a different jurisdiction, so you go after the first element in the supply chain that is in your own jurisdiction, to minimize the legal risk for you as plaintiff and maximize the output in terms of your local market.

But the case with Apple is different. They are not a small retailer down the road, but the entity responsible for providing the infringing software to (almost?) all of its users. They are running that App store as a commercial company and earn money from running it (even if individual apps might be free of charge). Free Software and copyleft licenses like the GPL are a very real phenomenon in the software industry today, so they should better have thought about a proper solution, not just for GNU Go but for the tens of thousands of existing GPL licensed software projects which people might want to port or re-use in iPhone applications.

They are already doing all kinds of verification/checking/review of software for other reasons (things many people might call censoring), and as part of that process they could just as well determine the license of the software, and provide a source code download link from their store. What is the big deal? If they (or other similar app store / market / ... providers) had thought how to address the problem, there are easy and pragmatic solutions to solve them in the architecture of such a app store / marketplace system.

Also, the fact that the FSF is taking legal steps is not wrong. Even if some people might dispute whether they actually have a valid case or not (I believe they do): This is what legal cases are for: To create a clear legal situation for all participants in the dispute, and to set precedent for future similar cases. Even only from that point of view it is good that they're doing this case. At the end of it, the legal situation will be more clear, both for Apple as well as for people who want to distribute GPL licensed software through their store.

[ /linux/gpl-violations | permanent link ]

Sun, 06 Jun 2010
Wanted: Packet traces of the MAP+TCAP based C/Gc interface

I'm looking for any example pcap files (packet traces) of the so-called "C" and "Gc" Interfaces, i.e. the interfaces of the HLR (Home Location Register). If anyone has such pcap files or can generate some, I would very much appreciate it.

The protocol levels I'm interested in is SCCP, TCAP and MAP. The lower layers (MTP) are not important now.

Specifically, I'm looking for traces of any of the following MAP operations:

  • updateLocation
  • cancelLocation
  • restoreData
  • sendParameters
  • updateGprsLocation
  • sendAuthenticationInfo
  • purgeMS
  • sendRoutingInfo
  • sendRoutingInfoForSM
  • reportSM-DeliveryStatus
  • readyForSM
  • noteSubscriberPresent
  • sendRoutingInfo
  • anytimeInterrogation
  • statusReport
  • {register,erase,activate,deactivate,interrogate}SS
  • sendIMSI
  • sendRoutingInfoForGprs
  • insertSubscriberData
  • deleteSubscriberData
  • checkIMEI

If anyone is able to produce the respective traces, I would appreciate it a lot. I'd need them as examples to make sure I fully understand the TS 09.02 in combination with Q.77x before actually starting to implement it...

[ /gsm | permanent link ]

Thu, 03 Jun 2010
First functional HTTP transfer in my own GPRS/EDGE network

Today marks the day where finally, after months of (non-full-time) work, I have made the first successful HTTP connection through my own GPRS/EDGE network.

Ever since we started to seriously get into OpenBSC to run GSM networks, I've been looking forward to running GPRS networks, too. What most people don't know: GPRS is radically different from GSM. It basically only shares the frequencies and timeslot architecture of the physical layer, while having it's own layer1, layer2 and various other protocol layers. Also, its signalling and data completely bypass the usual BSC and MSC components of a GSM core network.

So what I've been working on is now called OsmoSGSN. Using OpenBSC, you can provision an ip.access nanoBTS (or any other BTS with a Gb Interface) to broadcast the GPRS/EDGE capabilities to the handsets. The BTS then establishes the Gb interface (consisting of NS and BSSGP) to the SGSN.

The SGSN takes care of GPRS Mobility Management (GMM) and Session Management(SM) in the signalling plane, as well as the LLC + SNDCP protocol layers. On the other end, it uses the GTP protocol to connect to a GGSN. In our case, this is the OpenGGSN project which I recently adopted.

OpenGGSN then creates a virtual network device (tun0), through which the actual IP packets are entering/leaving the GPRS network. From there you can route and/or NAT them just like any other IP packets.

The current code is still incomplete in many places and known to be unstable. But it's really rewarding that after a long time of development, layer after layer of the stack, finally actual TCP/IP can be provisioned to phones.

The code is in the current master of the openbsc git repository, but I don't think there's much point in trying it just yet. I suppose in a week from now things should be much more stable.

[ /gsm | permanent link ]

Mon, 31 May 2010
The Linux-Kongress 2010 CfP is about to close

The Linux-Kongress 2010 Call for Proposals is about to close.

So if you have anything interesting related to Linux that you would like to talk about at the 2010 incarnation of one of the most traditional Linux conferences, this is your last chance. There is no excuse, do it right now!

[ /linux/conferences | permanent link ]

Fri, 28 May 2010
UPS sends me an invoice over 1 Euro-cent

Yesterday I received this letter from the local UPS subsidiary in Germany.

This is nothing uncommon, as I often import some electronics parts or other equipment from outside the EU, on which I need to pay customs duties and/or import VAT. In such cases, they typically collect an estimated amount as COD (cash on delivery) and then send an invoice about the difference (if any).

The funny part in this case now is: The grand total after subtracting my COD payment is EUR 0.01 - in words: One Euro-cent. They really want me to do a bank transfoer or write them a cheque over 1 cent !?!

One wonders to what grand total the expenses for the paper, printing, postage, banking transfer fees and accounting fees on the UPS side will amount to for processing something like this.

I wonder what would happen if I didn't pay that 1 cent. Would they actually try to sue me? Probably simply stop delivering packets to me, which I cannot afford and thus rather pay that single cent...

[ /misc | permanent link ]

Tue, 25 May 2010
OpenGGSN Version 0.90 released

Only three weeks ago I blogged about OpenGGSN, a seemingly-abandoned Free Software implementation of the GGSN node of the GPRS core network.

Things have developed quite a bit ever since. As the original author didn't respond to any of my mails and sourceforge.net was not able to reach him either, they have approved my the 'abandoned project takeover' (APT) request.

I've now switched the project from CVS to git, removed links to the non-existing openggsn.org homepage and released version 0.90, containing nothing less than a fix for remote DoS vulnerability that was pending for more than 5 years.

So far I'm only exercising the PDP context activation/deactivation parts of OpenGGSN from OsmoSGSN (the SGSN I write as sister-project to OpenBSC), but I hope we can use OpenGGSN in a production GPRS network soon...

[ /gsm | permanent link ]

Mon, 24 May 2010
dfu-util release 0.1 has been announced

Back in the early days of my work at Openmoko, I had come up with the idea to use the standardized USB Device Firmware Upgrade (DFU) protocol for flashing firmware to the Neo1973 and later FreeRunner phones. This encompassed a DFU device implementation that is part of the Openmoko u-boot variant (and has meanwhile been merged in one of the u-boot successor projects) as well as a tool for the host PC called dfu-util.

Since DFU is meant to be device and vendor-agnostic, I tried to code closely to the spec. This meant that it in fact was compatible to other devices, and some folks e.g. used it to flash firmware into their USB-Bluetooth controllers from CSR.

However, there never was any official information how to use dfu-util outside the context of Openmoko, and even more specifically: There never were any official releases.

Stefan Schmidt has stepped up to change this and maintain dfu-util as well as make official releases. The first such release has now been made at the new dfu-util project homepage.

[ /linux | permanent link ]

Thu, 20 May 2010
I'll be presenting at COSCUP 2010 in Taiwan

I have just received the great news that my attendance of the COSCUP 2010 conference in Taiwan is now confirmed. Thanks to COSCUP for inviting me!

I'll be participating in the legal track and presenting on GPL license compliance. The exact title and abstract is not yet decided.

As usual, I'm really looking forward at any chance to visit Taiwan, and the trip this August is definitely no exception. Now I only need to decide how long I'm going to stay before/after the conference...

[ /linux/conferences | permanent link ]

Heading off to Europe's largest Goth festival

Despite lots of very exciting work at this time, and a distinct lack for progress on my various 'just for fun' software/hacking projects, I'll be visiting Wave-Gotik-Treffen from tomorrow on. This means that I'll be listening to some fine music and will hopefully have a most enjoyable time offline.

Don't expect me to read or answer e-mails or get any work (paid or unpaid) until at some point Tuesday next week.

[ /personal | permanent link ]

Wed, 19 May 2010
Doing even more encapsulations than the GPRS Gb interface already has

Back in October 2009, I blogged about the incredibly deep protocol stack on the GPRS Gb interface between a BSS and the SGSN.

Today I had the pleasure of implementing an even more odd variant of the Gb interface, where NS does not get encapsulated in UDP/IP/Ethernet, but in FrameRelay/GRE/IP/Ethernet. The total protocol stack thus then looks like: HTTP/TCP/IP/SNDCP/LLC/BSSGP/NS/FR/GRE/IP/Ethernet, with an optional PPP between IP and SNDCP. If anyone does the math to calculate the total protocol overhead, please let me know[...

The reason for that oddity is apparently that there are Cisco and other routers that can encapsulate Frame Relay in GRE. So using a old circuit-switched SGSN with E1 interfaces and such a router, you can convert from Frame Relay on E1 to Frame Relay on GRE/IP/Ethernet.

Both the Gb Proxy as well as the upcoming OsmoSGSN use the same NS implementation, i.e. they can now both talk NS/FR/GRE and the NS/UDP variants - even at the same time, as the encapsulation is a property of each individual NS-VC.

[ /gsm | permanent link ]

Sun, 16 May 2010
Back from a week of GSM/GPRS protocol coding/testing in Iceland

With only 16 hours delay (which isn't all that much considering the volcanic ash situation) I arrived back in Berlin from one week of OpenBSC software hacking, particularly on the GPRS side of things.

It was really nice to see to what extent OpenBSC software is already used at On-Waves, providing GSM and now also GPRS services to thousands of users.

My work was mostly focused on the Gb-Proxy, a multiplexer/proxy for GPRS Gb links running the NSIP (NS-over-IP) protocol. It combines elements of the idea of a network address translator with that of a proxy, combined with a little bit of packet-based routing. This really makes me feel like I'm back to packet-switched networking, which is great. Especially the fact that we use the VTY code from quagga and its interactive command line sometimes lets you forget that you're not working with classic TCP/IP routing daemons or the like ;)

Aside from that, I continued my work on the upcoming OsmoSGSN, using which we will be able to run an autonomous GPRS network with no dependency on external proprietary components. In this setup, the PCU in the BTS connects over Gb/IP to OsmoSGSN, which then talks over GTPv1 to the OpenGGSN.

Also, work was spent on an abstract rate_counter implementation (now part of libosmocore). The idea is to have a counter that will count certain events (like number of packets/bytes, number of link failures, etc), but also keep a small history about how many of those events happened in the last second, last minute, last hour and last day. There is also common code to store those counters in the database, as well as to print them on the VTY. The new counters are so far only used in the GB-Proxy, but they will soon likely be added to OpenBSC (bsc_hack) and other programs of our Free Software GSM network portfolio.

[ /gsm | permanent link ]

Mon, 10 May 2010
Heading for 4 days of Iceland to work on OpenBSC GPRS

Having just returned from Croatia the day before yesterday, I'm about to head on a four-day trip to Iceland, where I'll be doing some testing and bug fixing of the current OpenBSC GPRS support at On-Waves.

Zecke is also going to be there, working on other aspects of OpenBSC. This will make the trip even more fun!

[ /gsm | permanent link ]

Sun, 09 May 2010
CECT C3100: Not a phone, but a flashlight with integrated phone

I've seen many [mobile] phones in my life, but nothing like the CECT C3100 so far. It's made of the cheapest hard plastic, like cheap kids toys. In addition to the phone keyboard, it has a mechanical switch on its side. If you slide that switch, five powerful bright white LEDs at the top of the phone will turn the entire device into a flashlight.

However, it is one of the most basic phones with one of the older/simpler MTK baseband chips inside (MT6223). Also, as we have determined by a PCB delamination analysis, the test pads next to the MT6223 really are its ARM JTAG pins.

JTAG is something not commonly found in MTK phone designs, but it is definitely a big win for bootstrapping any system-level software such as drivers on the unit.

Right now I don't have the time to work on MT6223, we still have many issues to fix in the current Ti Calypso code. But I can't wait to find time to see if we can extend our hardware support to MTK GSM chipsets...

[ /gsm/osmocom-bb | permanent link ]

Tue, 04 May 2010
GPRS progress in OpenBSC

In recent weeks, I have been able to pick up my work at GPRS support for OpenBSC again. What has been done is:

  • Add OML support to configure nanoBTS for EDGE
  • Add RR (System Information) support to indicate EDGE support
  • Make a OpenBSC + nanoBTS setup inter-operate with an existing SGSN
  • Develop a proxy that can aggregate the Gb-interfaces of multiple BTS into one Gb link to a real SGSN. This way the SGSN has only one Gb link for all the cells under the control of a BSC, as opposed to one Gb link for each and every BTS

What I'm working on now is the actual SGSN implementation. The SGSN is mainly responsible for GPRS mobility management (GMM) and for terminating the Layer2 (LLC) protocol from the MS. This is very different from circuit-switched GSM, where Layer2 (LAPDm) already terminates at the BTS.

The layering stack of GPRS is a real nightmare, I am sure I have indicated this in this blog before. The Current OsmoSGSN code (available from the regular openbsc.git repository) implements the NS, BSSGP and LLC layers, as well as the basic GSM 04.08 GPRS Mobility Management messages like GPRS ATTACH/DETACH and ROUTEING AREA UPDATE. The LLC code is still somewhat limited, but for the time being it is sufficient.

What drove me crazy for a couple of days is the number of parameters that are exchanged at PDP CONTEXT ATTACH time. There are no less than 26 different quality of service (QoS) parameters negotiated (see struct gsm48_qos at the bottom of this link), each of them from a wide range of values. It's almost impossible to imagine more than 1% of all the possible combinations have ever been used in production networks. The QoS parameter negotiation works by the phone sending a list of requested parameters, to which the SGSN responds with its selected parameters. My first thought was: Lets be smart and simply echo back the QoS parameters - the phone must accept what it has requested. That didn't work either: While the QoS structure is the same in both ways, the actual values in uplink and downlink directions are encoded differently. Who on earth defines such an encoding?

Next item was the XID exchange which is at the boundary between LLC and the SNDCP (Sub-Network Dependent Convergence Protocol). It works like this: The phone proposes an endless list of parameters, which the SGSN can evaluate, and then depending on the parameter type either negotiate up or down. According to the spec, sending an empty XID response should mean "I agree with all your parameters". However, at least those phones that I tested were not happy with that. So I decided to simply send back the entire XID block to the phone. And believe it or not, as opposed to the QoS parameters, this time it even worked

So now I'm facing the implementation of the actual SNDCP-to-GTP interworking, which is nothing less but the guts of the SGSN. GTP is the protocol used on the GGSN side. At least this time, GTP is sent directly over TCP or UDP, i.e. the stacking inside the SGSN is only one layer deep, while on the Gb-interface it is four (NS,BSSGP,LLC,SNDCP).

SNDCP interacts with the GPRS Mobility Management, GPRS Session Management (both GSM 04.08 over LLC), the GTP interface to the GGSN, as well as other parts. I expect many pitfalls on the way to getting it working, and given the complexity involved I have already decided to stick much closer to the specification than I usually did with the OpenBSC work. This means properly implementing all the state machines with all their transitions, exceptions and timers. I'm sure it's going to be "fun". The good part of it is: Most of the SGSN will be re-used once we finally get around adding support for 3G/UMTS/WCDMA cells.

[ /gsm | permanent link ]

OpenGGSN - An open source GGSN implementation

As a friend pointed out to me at exactly the right point in time: there already is an Free implementation of a GGSN. In case you don't know what a GGSN is: It is one of the two core components of a GPRS network. So, in order to extend a OpenBSC GSM network with GPRS support, there are two components required: The SGSN (on which I'm working currently, project name OsmoSGSN), and the GGSN. Due to the good news about OpenGGSN, I'm quite confident that I will not need to implement the latter part.

OpenGGSN is not only a Free Software implementation of the GGSN, but it is also licensed under GPLv2, making it compatible with the OpenBSC codebase (which is GPLv2 or later). This means I will be able to link the OpenGGSN-provided libgtp library (implementing both sides of the GTP protocol between SGSN and GGSN) from OsmoSGSN, further reducing the amount of work required to get this working.

However, despite seeming like a fairly advanced/complete implementation of the GGSN specification: OpenGGSN seems like a project that was abandoned many years ago. The latest CVS commit is from 2005, and all of the bug fixes that people have submitted to the bug tracker have not been merged. The homepage is defunct, and the openggsn.org domain name seems to have been expired (and grabbed).

I've tried to contact the author by e-mail about his intentions for the project, let's see if there is any response. Meanwhile, I have generated a git repository from the OpenGGSN CVS repository at sourceforge and applied all the pending fixes to a local branch. See my related mailing list post for more information.

[ /gsm | permanent link ]

Sun, 02 May 2010
Security product technical details need to be disclosed while importing to China

According to this report at The Register, there are some new government regulations about the import of certain security products into China, including Smartcards, firewalls and routers. While importing the goods, the importer needs to submit the technical details to a government panel in order to get the import license.

However, the article claims there are no further details on what exactly needs to be disclosed. Anyone who knows more details: I'd be more than interesting to hear about them - maybe there's even an English translation of the respective law or regulation?

I think it is a most reasonable policy that a country can adopt. Security products whose operation relies on its secrecy are useless anyway. The concept of security-by-obscurity has never worked and has been proven wrong many times, e.g. in the NXP Mifare Classic, DECT cipher/authentication, GSM A5 cipher and many other proprietary encryption schemes.

The only thing the Chinese regulators are doing wrong: According to their rules, the information must be disclosed to a closed government panel. Instead, they should require such information to be published publicly, or at least to be released in full detail to all customers of the respective product.

[ /linux | permanent link ]

Fri, 30 Apr 2010
Attending DORS/CLUC 2010 in Zagreb next week

I'm looking forward to attend DORS/CLUC 2010 in Zagreb/Croatia next week. DORS/CLUC is a small but nice event, with a group of very warm and welcoming organizers. I've been there a couple of times before and always had a very good time.

[ /linux/conferences | permanent link ]

Linux-Kongress 2010: Call for Proposals closes soon

This years will mark the 17th incarnation of Linux Kongress. It is scheduled from September 21st through 24th in the city of Nürnberg (aka Nuremberg), which (as a personal side note) also happens to be the city where I was born and where I've grown up.

The Call for Proposals is out for quite some time, and will last for another month until June 1st. So if you have something exciting to talk about that is related to Linux and of technical nature: Please submit your proposal soon. Looking forward to listening to your presentation at LK2010 :)

[ /linux/conferences | permanent link ]

Thu, 29 Apr 2010
I'll be presenting at the SSTIC 2010 conference

I've been invited (as apparently the only non-french-speaker) to present at the SSTIC 2010 conference in Rennes/France.

There will be two presentations: One about OpenBSC, the other about OsmocomBB. Both will cover the use of the respective projects in the context of doing security analysis on a GSM protocol level.

[ /linux/conferences | permanent link ]

The mid-term future of WebOS seems safe

After HP announced its acquisition of Palm, I think we can be sure that the mid-time future of WebOS seems quite safe. I also expect mechanically much better hardware among the devices they will ship.

However, the acquisition could also mean a shift in politics, i.e. cause the new devices to be locked down with cryptographically signed kernel images. One of the big advantages of the existing Pre and Pixi is that they are not locked down and that as a user you can take full control over the device.

Another policy that might come under re-evaluation is the relationship between the WebOS Application Market and the third-party application installers like Preware.

Lets hope the managers responsible for WebOS future realize that their chance is to be less restrictive and more open than most of the competition - including most Android devices. At least, one could hope, HP has quite some experience with Linux and the Open Source community in other areas of their business.

[ /linux/mobile | permanent link ]

Sony faces class action lawsuit on removing the Linux support on PS3

As reported, a class action lawsuit has been filed against Sony in the US for removing the so-called Other OS feature from Playstation 3. The PS3 was originally advertised as being able to run Linux, and I know a number of people who have bought it for exactly that reason. Removing that feature after the purchase is thus significantly reducing the value of the product to many of its users.

I can only hope that this lawsuit will be successful. After I have bought a product, I own it and I decide what to do with it, not the original manufacturer. There have been somewhat related cases where Amazon removed already purchased books from the eBook readers of their customers. This is simply insane. With the ever growing power that corporations try to achieve over what their customers do or don't do, the outcome of this case might have significant importance for consumer rights in the decades to come.

[ /linux | permanent link ]

Wed, 28 Apr 2010
Chaosradio Express 151: ARM CPU Architecture (German)

I'm a bit late with this: The Chaosradio Express #151 podcast on the ARM CPU architecture has been released a week ago. I had a most pleasant experience spending about 90 minutes getting interviewed by Tim Pritlove.

I'm sorry for all the non-German-speakers. But Chaosradio Express is a German medium, made by and for German hackers :)

[ /ccc | permanent link ]

Tue, 27 Apr 2010
Working on GPRS support for OpenBSC again

This has been on my TODO list for at least the last six months or so: Growing the experimental GPRS branch of OpenBSC into something more useful.

Right now, you can use OpenBSC with a GPRS-capable BTS - but only if you have an existing SGSN to serve the Gb interface of the BTS. This somehow defeats the point. We want to offer a 'GSM network in a box' solution, where no other non-free Software is required to run a fully functional small network.

So right now I'm cleaning up the 08.16 (Network Services) Implementation, and will move my way up through the existing 08.18 (BSSGP) and LLC code that I wrote some time ago.

With some luck, in a couple of weeks we should be able to run a self-sufficient combined GSM + GPRS (+ EDGE) network out of OpenBSC.

[ /gsm | permanent link ]

Sat, 17 Apr 2010
Wikipedia discussion on deleting entry on David Miller

As you can see, Wikipedia has started a discussion on whether or not to remove the Wikipedia entry about DaveM

I think this is pretty hilarious. By now, the Linux kernel is probably running on hundreds of millions of CPUs on this planet, most of them connected to some kind of TCP/IP network. And whom do we have to thank for the quality and scalability of that TCP/IP stack inside Linux: David Miller. He's probably one of the longest-running maintainers of a subsystem that's as essential as the networking subsystem.

And this is just one of his many contributions. The SPARC and UltraSPARC port might not be as important today than they were some time ago, but they have been large contributions nonetheless. And then let's talk about operating vger.kernel.org, the central mailing list host running (among others) what is probably one of the worlds largest mailing lists: linux-kernel aka LKML.

If you think that David Miller is a notable person, then please go to this Wikipedia page and argue that his article should not be deleted.

[ /linux | permanent link ]

Thu, 15 Apr 2010
Becoming a licensee of the Open Invention Network

As has been announced publicly, my sole proprietor company hmw-consulting has become a member of the Open Invention Network.

If you don't know what OIN is about: It's an organization creating a defensive pool of patents that may be used to deter patent aggression against what they call the Linux Environment.

[ /linux | permanent link ]

New binary analysis tool for license compliance audits released

My friends at Loohuis Consulting and Opendawn have just announced the first public release of their novel binary analysis tool.

This is a modular (python) framework facilitating the audit of compiled object code. Using it, you can analyze executable code (programs/libraries) or entire filesystem images or even complete firmware images and search it for strings, symbol tables and the like. Using a corresponding knowledge base, it can match this information against information derived from software source code and thus give some indication of whether a particular source code seems to have been used to create the binary.

It doesn't do actual instruction-level analysis or any of that sort, but it can help to automatize some of the steps that a license compliance engineer so far had to do entirely manually.

Let's hope this is a successful launch and that the project will find contributors to grow beyond the initial feature-set.

Thanks to the nlnet foundation and the Linux Foundation for sponsoring this project. I'm sure it will soon become a vital tool in compliance engineering.

[ /linux/gpl-violations | permanent link ]

Wed, 14 Apr 2010
Paper: Anatomy of contemporary GSM cellphones

During the last days, I was working on an introductory paper on how a GSM cellphone actually works. It is titled Anatomy of contemporary GSM cellphone hardware and should provide a good technical text for anyone who generally is into technology and understands a bit about both software, computer architecture as well as radio, but who still feels like he has no clue what is actually happening inside the phone, particularly the hardware side.

The text does not cover the GSM protocols itself, as there is much more information available on this already.

Feel free to let me know what you think, I'm always happy to extend or clarify it based on your feedback. I hope some people find the text useful.

[ /gsm | permanent link ]

German regulatory authority spectrum auction fails achieving its goals

Right now as I am writing this, the German federal regulatory authority for networks (Bundesnetzagentur) is running an auction for many frequencies in the 800MHz, 1.8GHz, 2GHz and 2.6GHz spectrums.

Officially they claim that the purpose for those frequencies is to improve broadband coverage and close the white spots on Germany's map where no broadband Internet access coverage exists today.

And how do they think to achieve this? By giving nation-wide licenses on that spectrum to the existing cellphone operators.

That's nothing but a contradiction in terms. If they were really serious about closing the so-called white spots on the broadband coverage map, they should give licenses not on federal, not even on state but on municipality level.

The large operators have no interest in bringing coverage into areas that are only sparsely populated. They want to get the largest number of subscriber with the least investment in their (overpriced) infrastructure.

Only small, local or regional companies have an actual interest in improving the broadband coverage in their own region. They understand their local market, they are in contact with the population and regional businesses. They can use much cheaper equipment since they are not part of a large inflexible traditional operator.

However, without providing smaller-areas licenses in any part of the useful spectrum, the German regulatory authority fails to even give a chance to such small/regional companies.

It all smells like the regulatory officials have been bought by the existing carriers/operators. There seems no reasonable other explanation to me.

[ /politics | permanent link ]

Tue, 06 Apr 2010
Some more thoughts on the Yamaha TW-225

A Yamaha TW-225 is my motorbike in Taiwan. Although I often refer to it as my toy bike (compared to the BMW F650ST and FZ6 Fazer in Berlin), it has proven to be a very reliable bike.

Before I cam to Taiwan and bought it, I was used to ride the heavy BMW for almost a decade. Ever since driving school at the age of 16, I didn't ride a small/light bike again (at that time a Yamaha DT80). So initially I was skeptical about the TW-255. Sure, for getting from one place to another inside Taipei it is great. But what about riding further distances and/or in the mountains?

To my own surprise I actually think that it is an almost ideal bike for the conditions in Taiwan (at least those that I encountered so far). It is very light, so you can actually manually move it around easily - very important considering the parking conditions in Taipei. The small weight also means that you don't have to throw around much weight on mountain serpentines.

The engine with its 18 horsepowers is also surprisingly strong, even on steep mountain roads. On the other hands, the engine is not too strong, i.e. it is forgiving in case you make any mistakes. You certainly don't make a wheelie or get your rear tire to slide while accelerating. You also don't run into the danger of a rear wheel blocking when shifting down and being a bit too swift with the clutch.

You can almost do anything with (or to!) the bike and it will tolerate it. You can pull the throttle as you want, make mistakes while shifting gears and whatever else. I've experienced many less pleasant situations with my other bikes, but not with the TW-225 despite plenty of opportunity.

As opposed to the ever-so-popular scooters you have a manual gear, much bigger tires, different center of gravity, better suspension (think of potholes), ... - and most of the scooters also have a weaker engine anyways.

The only two weak points that I could find so far:

  • The brakes could be much more aggressive, saving important time when you have to do a full stop after some unexpected event in the traffic ahead.
  • The seat is ridiculous. I'm by no means tall with my 172cm, but I think the seat TW-225 seat is way too low for me. And god, is it uncomfortable. Not sure if it was designed with an Asian anatomy in mind (the TW-225 is officially selling only in Japan) and if it is less painful for Asians. But thinking of doing more/longer tours through Taiwan, I definitely need a different seat...

Having said this, I'm still looking forward to trying some of the high mountain roads like the central cross-country highway from Hualien to Taichung. Let's see how the carburetor will do once you get to around 3,000 meters of altitude..

[ /personal/taiwan | permanent link ]

Mon, 29 Mar 2010
OpenBTS workshop in June (Pfarrkirchen/Germany)

If you've always been interested in Open Source / Free Software GSM using OpenBTS, you might be interested in the upcoming three-day OpenBTS workshop in Pfarrkirchen/Germany.

The workshop is held by OpenBTS project leader David Burgess, and will cover subjects ranging from OpenBTS installation, configuration and deployment down to actually extending OpenBTS with some custom code.

p.s.: Please don't misunderstand, the workshop really is about OpenBTS not OpenBSC - though there might be OpenBSC folks hanging around ;)

[ /gsm | permanent link ]

Mon, 15 Mar 2010
Holidays in Taiwan

Just in case you are wondering why there are no updates here: I'm currently on holidays in Taiwan and thus not working much on my various projects, i.e. no major updates on this blog until some early/mid April.

[ /personal | permanent link ]

Fri, 05 Mar 2010
OsmocomBB now performing location updating procedure against GSM cell

I haven't had much time for blogging recently, too much exciting work going on at OsmocomBB:

  • we now have simplistic support for Uplink (transmit) on SDCCH/4
  • we have a minimal Layer2 (LAPDm) implementation
  • we can send LOCATION UPDATING REQUEST to the network, and receive the respective response
  • there's wireshark integration, i.e. all packets on the L1-L2 interface can be sent into wireshark for protocol analysis

There are still many limitations, but this is a major milestone in the project: We have working bi-directional communication from the phone to the network!

The limitations include:

  • The cell has to use a combined CCCH (SDCCH/4 on timeslot 0)
  • The cell has to use no encryption/authentication
  • The layer2 is not finished, especially re-transmissions will not work yet
  • There's no power control loop yet
  • There's no timing advance correction
However, most of those are more or less simple we know what needs to be done, its just a matter of getting it done kind of tasks. There are no big unknowns involved, and particularly no further reverse-engineering of the hardware is required.

Also, the existence of a stable bi-directional communications channel between the network and the phone means that anyone interested in working on the higher layers can now actually do so. Completing and testing layer2 as well as RR/MM/CC on layer3 is a major task in itself, and it definitely requires the lower layers to be there.

The other good part is that development of layer2 and layer3 can happen entirely on the host PC, where debugging is much easier and there's no need for cross-compilation and we can use all the usual debugging options (gdb, valgrind, ...)

I'm now almost heading off for holidays (starting March 10), so don't expect any major progress from me anytime soon. I hope other interested developers will be able to take it from here and fill in some missing gaps until I'll get back.

[ /gsm/osmocom-bb | permanent link ]

Mon, 01 Mar 2010
Looking for documentation on sunplus SPMA100B

In the Motorola/Compal C155 phone supported by OsmocomBB, we have found a ringtone melody chip called SPMA100B from sunplus.

As strange as it might seem, this is the only part used in the phone for which we have not been able to find any kind of programming information. So if you know anything about how to program this part from software (register map, programming manual, ...) please let me know!

And no, we don't need electrical/mechanical data sheets, thanks :)

[ /gsm | permanent link ]

Sat, 20 Feb 2010
Restructuring OpenBSC and OsmocomBB code

I've spent the better part of the day with , renaming files/functions/include paths, Makefiles, autotools and the like.

The result of this is a new sub-project called libosmocore that gathers all the shared code between the network-side GSM implementation OpenBSC and the phone-side implementation OsmocomBB. The library is portable enough that it can run on a proper OS (like GNU/Linux) but also be cross-compiled to work on the actual phone without any OS.

On the other hand we now have a master Makefile in OsmocomBB to build libosmocore for host PC and target (phone), as well as the osmocon and layer2 host programs and the phone firmware itself.

Let's hope I can now return to writing actual code...

[ /gsm/osmocom-bb | permanent link ]

Fri, 19 Feb 2010
Announcing OsmocomBB: Free Software / Open Source GSM Baseband firmware

Last, but not least, I am proud to announce the OsmocomBB project publicly. During the last 7 weeks, a small group of skilled developers has been working on this

It has now reached a point where we can

  • scan the spectrum for the strongest signal GSM channels
  • lock onto them and performing AFC (automatic frequency control)
  • decode the SCH burst to obtain BSIC and GSM frame time
  • decode the BCCH of the cell, pass it over to the host PC and feed it into wireshark

Since this in itself is a valuable and useful milestone of the project, it was the ideal opportunity to take this project public.

There's still a lot of work to be done in many areas. Most of them are not even related to the GSM air interface. So if you're familiar with C development on an ARM7TDMI based microcontroller, know your way around I2C and SPI, are familiar with the GNU toolchain for ARM and want to help us out: Please join the baseband-devel mailing list right away!

[ /gsm | permanent link ]

Sat, 13 Feb 2010
In six weeks from bare hardware to receiving BCCHs

After six weeks of full-time hacking, with the help of a few friends, we have made it to receiving actual BCCH data from a GSM cell.

So what does this mean? As I have indicated publicly at the 26C3 conference: Now, that we have managed to create a working GSM network-side implementation (OpenBSC) during the last year, we will proceed to do the same with the phone side.

Initially we spent quite a bit of thinking on building our own custom hardware. But while planning for the first prototype, we realized that it would simply distract us too much from what we actually wanted to do. We don't want to take care of component sourcing, prototype generations, quality assurance in production, production testing, etc. -- All we want is to write a Free Software GSM protocol implementation for a phone.

Unfortunately (as usually in the industry), the silicon and device makers do not publish sufficient documentation about their devices to enable third-party developers to go ahead and write their own software: The never ending problem of Free Software in many areas beyond more-or-less standardized hardware like in the PC industry.

So, if you want to write Free Software for such a device, you have two options:

  • Reverse engineering the existing hardware and writing your code based on that information
  • Building your own hardware and then writing the software you wanted to write.

I've been involved in both approaches multiple times while looking only at the application processor (the PDA side) of mobile phones: OpenEZX and gnufiish are two more or less abandoned projects aimed at reverse engineering. Openmoko was the project that had to build its own hardware as a dependency to be fulfilled before writing software.

If you're not a company and don't want to sell anything, the reverse engineering approach looks more promising. You can piggy-back on existing hardware, don't need to take care of sourcing/production/certification/shipping and other tedious bits.

If you are a company and want to generate revenue, then of course you want to build the hardware and ship it, as it is what you derive your profits from.

So, just to be clear on this: Neither OpenEZX, nor gnufiish nor Openmoko were ever about writing Free Software for the GSM baseband processor, i.e. the beast that exchanges messages with the actual GSM operator network. But this is what we're working on right now.

It's about time, don't you agree? after 19 years of only proprietary software on the baseband chips in billions of phones, it is more than time for bringing the shining light of Freedom into this area of computing.

To me personally, it is the holy grail of Free Software: Driving it beyond the PC, beyond operating systems and application programs. Driving it into the billions of embedded devices where everyone is stuck with proprietary software without an alternative. Everybody takes it for granted to run megabytes of proprietary object code, without any memory protection, attached to an insecure public network (GSM). Who would do that with his PC on the Internet, without a packet filter, application level gateways and a constant flow of security updates of the software? Yet billions of people do that with their phones all the time.

I hope with our work there will be a time where the people who paid for their phones will be able to actually own and control what it does. If I have paid for it, I determine what software it runs and when it send which message or doesn't.

Oh, getting back to what our work: It will be published as soon as it is sufficiently stable and fit for public consumption. You won't be able to make phone calls yet, but we'll get there at some later point this year.

[ /gsm | permanent link ]

Fri, 05 Feb 2010
Symbian is Open Soruce - Really?

In recent news, the Symbian Foundation announced that "All 108 packages containing the source code of the Symbian platform can now be downloaded from Symbian's developer web site". This is great news!

This morning I tried to look at the parts most interesting to me: phonesrv (implementing call engine, cell broadcast and SIM toolkit APIs) and poc (implementing push-to-talk). Their pages don't have the usual "source code" tab at the bottom right which links to mercurial and tarball download pages!

Either I'm too stupid, or I am unable to find any source code for those two components. I'm quite sure something essential like the API's for making phone calls are considered part of the Symbian platform. So how does that match with the statement that all packages containing the Symbian platform can now be downloaded?

[ /gsm | permanent link ]

Wed, 27 Jan 2010
Sorry for new blog updates

I've been busy day and night, hacking away on my latest pet project in the GSM field. In fact, it's been a long time since I've been able to dedicate so much time and energy into one particular project, without many distractions at all. The project is now finally looking quite promising and making nice progress throughout the last three weeks.

If progress continues, I hope in another week I'll be able to reveal what this is all about. I haven't felt this level of excitement since the early days of Openmoko :)

[ /gsm | permanent link ]

Fri, 08 Jan 2010
Illusions about MagicJack at CES

Many people have pointed out the MagicJack Femtocell product that has been announced at CES. I cannot really understand the big hype and news about it. Why? read further...

On the technical side, there is hardly anything new. Using projects like OpenBTS or OpenBSC, you can run your own GSM network and connect it to VoIP. Sure, the retail price of the MagicJack is much lower, but that's the economics of scale. As soon as OpenBSC support for one of the recent femtocells is done, we also have a much lower cost solution to the same problem.

On the legal and business side, I can see many problems for MagicJack:

  • To operate equipment in the GSM or 3G spectrum, you need a license. Since a nationwide GSM operator license is very expensive in about any country of the world, it is economically not an option. Selling the MagicJack devices without a license and leaving the spectrum license to the user will not work, or at least not long, since regulatory authorities and commercial operators are not going to let anyone deploy systems that interfere with their networks.
  • If you keep the Operator's SIM in the phone, and use that SIM on your own network you might at least violate the terms of services of the operator. The SIM card normally belongs to the operator, and it is part of the users business relationship with that operator. As such, you can not really use it with other networks. Sure, if you do this at home with your OpenBTS/OpenBSC installation, nobody will care. But if somebody is doing this commercially, and in a way that affects the sale of talk time of the regular operators, again it will not take long until the commercial operator will sue you.
  • Security. If you run your phone with a "foreign" SIM, you do not know the Ki on the SIM and thus cannot do cryptographic authentication and/or encryption. This is a big security issue. It is once again not an issue in your personal testbed setup, but it is going to be one if you do this at large scale as a mass market product.
  • So, as you can see: It's neither technically something exceptionally new, nor is it something that has a very promising business or legal outlook. The only way how a product like this would work is if it is authorized by the respective operator. But why would the operator authorize something that will take talk time away from his network and thus his revenue stream?

[ /gsm | permanent link ]

Thu, 07 Jan 2010
Planning for a GSM development board

I've finally found enough spare time to work on detailed plans for a GSM development board. The idea here is to have a 100% open hardware design with 100% free software that provides an inexpensive platform for GSM related R&D.

Initially the focus is on having a board that can behave like a GSM cellphone, next steps would be to have a multi-channel frequency-hopping receiver, and finally the option of using it as a BTS.

The idea is fairly simple: Take a commercial off-the-shelf analog baseband and RF circuit for GSM and attach it to a general purpose DSP, add some glue logic and go ahead. But the devil is in the details:

  • You want something where you can still find the parts on the market, but which still has sufficient leaked documentation that you can write an open source driver for it.
  • The requirements for a MS and a BTS are quite different. A phone never needs to continuously receive and transmit in all timeslots, e.g.
  • The requirement for a multi-channel frequency-hopping receiver is mainly a high number of receiver circuits, so the solution needs to scale to a larger number of receivers.
  • The analog baseband circuits often have quite obscure control interfaces which need to be driven. Custom peripherals in programmable logic (CPLD/FPGA) are required.
  • The TDMA nature has strict timing requirements. Normal processors and software-based mechanisms are not sufficient to trigger the required events and their sequencing at a high enough precision.

Anyway, there is sort of a first plan now, and the next weeks and months will be spent with refining the plans and building a first proof-of-concept prototype. Once that has proven to work, we want to go ahead with finishing the design for a real board, to be manufactured in sufficient quantities for interested parties.

Unless you have worked in GSM phone or base station hardware design or have a similar level of EE and DSP skills, please refrain from contacting me right now about how to join the project. We want to focus on getting things going first, then make a public release at a point where there is something that works sufficiently well that we can support a larger community of developers.

[ /gsm | permanent link ]

Sat, 02 Jan 2010
2010-01-02 / 2pm CET: Radio Interview at Deutschlandradio

The German radio station Deutschlandradio Kultur has invited Constanze Kurz (46halbe) and myself for interviews during today's Breitband radio show. We'll be talking about the 26C3, the Chaos Computer Club and - of course - GSM [in]security.

[ /gsm | permanent link ]