Today I've found a bit of time to start my reverse engineering efforts on the E-TEN glofiish DX900. In case you don't know what that is: It's E-TEN's latest PDA-phone model, 2.8" full-VGA touch-screen, GPS, WiFi, Bluetooth, 3.5G and dual-sim (it has a 2G modem next to the 3.5G modem). It runs the Samsung S3C6400 application processor. It is so new, that it doesn't even yet have FCC approval. Luckily it was available in Taiwan at PDA king for NT$ 16,900.

It seems like a great device. There's basically only one big flaw: It runs Windows Mobile. And it does that in a really bad way. From how sluggish and unresponsive the UI is, you can clearly see that they don't use any of the 2D acceleration functions of the S3C6400 hardware.

Now in order to get rid of Windows Mobile, we need to discover more about the device hardware. The first step for that is HaReT, the Hardware Reverse engineering Tool. Unfortunately the S3C6400 is so new that HaReT doesn't yet have support for it. So I had to dig into the code and add support for it. You can find the preliminary patch here.

The information that I was able to dig out using the first round HaReT can be found at this DX900 gnufiish.org wiki page. As expected even before touching the device:

• the 2G modem connects to a UART
• the 3.5G modem is SPI slave just like in the M800
• the wifi is still Marvell 8686 connected to SPI
• the GPS is still SIRF3 connected to a UART
• the buttons still are the same, some connected to GPIO some not

I won't have much time to work on this right now, as too many other higher priority tasks are pending. But it seems like the DX900 is a nice s3c6400 based device to play with, and a Linux port to it is not really further away than for the M800 or X800

One of the projects that I'm hosting (and which I've helped to initiate) on gnumonks.org is the deDECTed.org project about security research and analysis of the DECT protocols.

Like I've pointed out in many of my presentations and here in this blog, there are many communication systems in use today which don't even remotely receive as much scrutiny as TCP/IP, the Internet and the PC world. RFID is one of them, which is why I helped to get OpenPCD, OpenPICC, librfid and other projects started. My recent work on GSM protocol analysis as well as OpenBSC are of similar nature. And deDECTEd.org is doing the long-neccessarry scrutiny to evaluate practical DECT cordless telephone security.

As it seems, the news about the insecurity of most cordless phones has made its way into mainstream news, and the website is now getting thrashed quite a bit, despite running on a dual-core Opteron with quite a bit of RAM and fast SCA disks. Which is good. This means that people are indeed caring about the confidentiality of their cordless phones. It's a pity that the industry missed that fact and is shipping outdated technology way beyond todays state-of-the-art in IT security. Proprietary symmetric ciphers, weak RNGs, no user indication if the protocol falls back to no encryption, etc.

I've changed one of my e-mail signatures a couple of years back to a quote from the ETSI DECT spec: "Privacy in residential applications is a desirable marketing option". A Marketing option. Not something anyone would have to give much thought about. I hope the hardware vendors will now get sufficient public pressure to get their act together...

It's also great to see Patrick McHardy of netfilter.org fame now work on implementing a DECT protocol stack for the Linux kernel. Very exciting work.

The only sad thing is that all I can do is sit back and watch. I so much wanted to work on this project, but never got a chance. There are too many high-priority things going on, and I'm basically spending all my time in exciting (but unpaid) GSM protocol related work right now.

Today I was invited to present at the Taiwanese Institute for the Information Industry about two topics.

The fist talk was on How to write code compatible with the Linux Coding Style and submit patches to the mainline kernel, a seminar that I have given a number of times before, but which still raises a lot of interest.

The second talk that the III requested was surprising: About the gnufiish.org project, an effort to port Linux to E-TEN glofiish PDA phones. It is a very low-level hacker-oriented talk, and I was surprised that I should give it in front of an audience consisting of software developers working for "the industry". But I think it was received very well, and maybe it has made some people to start thinking about why people have to go to that extreme (reverse engineering) rather than some hardware vendor actually embracing the Open Source revolution and helping those people to make more software run on their devices.

Today I had the pleasure of being invited to have lunch with by Professor Bo-Yin Yang of Academica Sinica, Chen-Mou Cheng from National Taiwan University as well as some research assistants.

It was good to hear that they are working among other things on RFID security, and that they're excited about analyzing actual real-world systems. They also seemed pretty excited about the open source efforts in the GSM world, being a key milestone towards enabling more practical security research in that area

I hope to stay in touch and am looking forward to any publications in those respective subjects.

Had a very productive meeting today with various representatives from ASUS about how to make sure they don't continue their rather unfortunate series of GPL violations in the last year.

It was a very good and productive atmosphere and I'm confident that they are now committing the required resources and effort in fixing the mostly organizational issues that prevent them every so often from fulfilling their obligations under the GPL.

But in the end, what counts are hard facts. Let's look at the situation again in one year and see what kind of progress one of Taiwans leading companies has made in this regard.

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

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

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

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

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

This is a question that I've been asking myself ever since the first eeePC was released. Sure, there are other problems like bad keyboards and mechanical design (with the exception of the HP mininotes) and too small / low-res displays. But the question that bothers me most is: Why do those supposedly-so-power-saving new processors still need a fan in those systems?

I am the happy owner of a Panasonic Let's Note CF-R5. It was bought in September 2006, where it was already end-of-life. It does not have nor need a fan, the Intel U1300 (1.06GHz) CPU and the Intel IGP chipset are doing quite fine without it. So why are the supposedly less power-consuming later systems like Intel Atom built with fans? It's really annoying to me. I don't want this kind of noisy design. It sucks. It is a clear sign of bad engineering.

So far, the only replacement for the CF-R5 that I would consider is a CF-R7 or CF-R8. A netbook faster than the CF-R5 without fan could make me reconsider.

Just as a quick update: VIA has silently released more hardware manuals about current-generation products at ftp://ftp.vtbridge.org/Docs/. We will try to make this the premier location for all hardware related documents, and will also copy those from linux.via.com.tw as well as those from x.org to that new site.

Once again, if you are working on some Free Software and require certain VIA hardware manuals, please contact me and I'll do my best to make it available.

Just in case you're interested: Kwanghyun La has put up some pictures from the barbecue that I enjoyed with the kernel developer team there.

I've just finished one exciting week at Samsung LSI (the group inside Samsung responsible for the System-on-a-Chip line like the s3c24xx, s3c64xx as used in Openmoko, TomTom and E-TEN glofiish devices). Specifically, I had one week of close contact with the team there developing the Linux kernel port and drivers for those products.

I do not want to go into too many details here in public, but it was a very productive week, and I think everyone involved is drawing a very positive conclusion. Let's hope the actual results from the now-improved understanding of the Linux and FOSS development model will be of mutual benefit to the community as well as Samsung. I'm also hoping for better and faster integration of Samsung's codebase into mainline Linux.

Parts of this Openmoko-triggered drive can be already seen on git.kernel.org, where Samsung LSI has started to push their current development trees to.

Since this is not the first time that I'm trying to lobby for more understanding of the Linux development process, the benefits of going mainline, etc. - I wonder if this kind of work should not be done in a much more scaled and proactive way by somebody like the Linux Foundation. Especially in the embedded world, there are many companies who are probably very interested, but just don't know where to start or whom to talk to. There just is no (or no easily identifiable) entity catering to their needs - and since they are always busy with developing new products and working on ports for other operating system, the initiative should probably come from the outside.

Right now this field is left to embedded distributors who have their own agenda and are always only representing a small fragment of the Linux stakeholders

So today I arrived in South Korea, after a one day stop-over in Taipei (following a flight connecting in Abu Dhabi). I've arrived at about 6pm local time and had a 90minute bus ride to the hotel in Yongtong-gong. So besides check-in and a quick stop at the convenience store, I didn't yet do much.

Some first impressions, in no particular order:

• Heating like crazy. This first occurred to me in the airport, but became more of an issue in the bus. I was actually sweating with my long-sleeved shirt, without any jacket. The hotel has a default temperature of 28 degrees Celsius, not only in the lobby but in every room. you can adjust it, but as soon as you leave the room, it resets to 28. So the setting is not very useful, considering that a floor based heating has a very high latency, since the entire floor tiles are heated up and dissipate heat even hours after adjusting the temperature.
• The hotel clerk asked me in the elevator what kind of power plug my laptop had, and if I needed any kind of adaptor. Furthermore, he actually showed me the LAN cable and indicated "IP address automatic" ;)
• After a first try, that automatic IP address is actually a public IPv4 address. Wasn't there something about IP addresses running out in Asia? Weird, but definitely very welcome! Traceroute indicates all intermediate routers in Korea don't have any reverse lookup. Even more weird ;)
• The hotel room has flat screen plasma TV and a PC (running Windows, so I just disconnected the screen and run it in multi-head. Interestingly, the VGA and audio inputs of the plasma TV are connected with the PC at the desk, so you can play back video from the Internet or DVD's on your plasma TV. That's way better than crappy pay-TV in western countries :)
• Samsung is apparently so big, that they have a dedicated bus stopping at this hotel, taking people to the company twice every morning. A sign in every hotel room indicates this fact :)
• I totally love the sound of the language. To me, it actually sounds even better than Japanese.

So I remain thrilled what happens next. Not sure how much time I will have during the week, depends how busy it is at work.

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

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

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

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

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

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

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

"Thank you" :(

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I remain speechless, fascinated, moved. Happy.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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