Disrespect for election observers in Hessen

My fellow friends from the CCC have tried their best to observer the elections in Hessen (Germany) yesterday. The amount of resistance they've met is more than shocking. If you want to read more about this (in German), I'd suggest reading Frank's blog entry, Holger's blog entry and the official CCC release on this subject.

In fact, in some of the municipalities the election supervisors have received official statements warning them about the CCC's intention to disturb the elections. What nonsense is this ?!?

Having been part of a CCC election observer team in the past, I can only state that this is beyond anything that we've seen before. Why would there be any resistance against quiet and peaceful observation of the elections?

The CCC election observers have absolutely zero history of ever having disturbed an election in any possible way. I'm sure you can ask about any municipality that has had first-hand contact about this. We know the laws and regulations very well, and want to do nothing else but to _observe_ the

Learning about NAS chipsets

For gpl-violations.org, I've been analyzing a number of NAS devices recently. While most of them are based on some kind of more or less general purpose CPU (Intel StrongARM based IOP or e.g. VIA's embedded x86) plus standard peripherals, there appear to be more and more special purpose SoC's for this purpose.

To some extent, this is only a logical development. NAS appliances seem to be a growing market, and the desire to achieve higher integration by e.g. moving the SATA/IDE controllers into the SoC make development easier and reduce BOM cost.

It's quite amazing how much effort some companies actually go through. One series of chips that particularly caught my attention is the Stormlink Gemini series of NAS CPU's, e.g. the SL-3516. Looking at the public data sheets is particularly boring since they only have two pages. Instead of that, I'd recommend looking through the kernel sources that their downstream appliance vendors publish. They actually have hardware crypto, hardware IPsec acceleration, TSO (TCP segmentation offloading), hardware NAT, ...

As if that wasn't enough already, they also now have a dual core variant, which has two ARM920 cores next to the hardware crypto and pimped-up Ethernet controller!

While reading through the code, I made a slightly cleaned up diff against vanilla 2.6.15. It reveals a number of things that I'd like to point out:

• They have actually managed to implement a arch/arm/mach-sl2312 directory (instead of just editing some existing machine), though there seems no distinction between 2312/3516/3518/...
• They have GPL licensed drivers for their entire hardware functionality, not a single bit of proprietary stuff. It even comes with proper license headers and MODULE_LICENSE tags. This is really remarkable, especially for stuff coming from Taiwanese hardware companies. Congratulations!
• They integrate DMA capable RAID5 hardware generation, integrated with the Linux raid code
• They have two OTG capable EHCI USB controllers
• The ARM core they use is a FA526. It seems to originate from (another Taiwanese) ASIC/IP vendor called Faraday. Apparently an independent implementation of the ARMv4 instruction set, allegedly 100% compatible, even including a replica of the ARM ICE/JTAG. Could Faraday be to ARM what VIA is to Intel? In any case, definitely exciting.
• While the vendor-released GPL licensed sources contain support for this FA526 in a fairly decent way, it has not been merged into the mainline kernel. That's a pity. Does anyone know more about this? I think this should definitely be cleaned up and merged mainline.
• they re-use an entry from the mach-types registry for the sl2312. Not only do they use that machine type for all Stormlink SoC, but also the downstream hardware vendors use the same for all their products. not good. Did anyone tell them that registering new machine types is free?
• They're doing some obscure I/O pin sharing between IDE and the flash controller resulting in lots of ugly code. Probably a hardware workaround :)
• They have very invasive code all across the Linux crypto code, probably because they need async crypto support, which the crypto framework of 2.6.15 doesn't yet provide
• They seem to integrate their crypto with cryptoloop, but not dm-crypt
• They seem to be able to store their OS image in NOR, NAND or serial SPI(!) flash
• They have four hardware queues per Ethernet MAC
• They have done some serious hacks to the network stack in order to integrate their TCP offloading engines and hardware NAT. This code is obviously not the most beautiful you have seen. But what surprises me is that they actually have it working, and went all they way to get it developed. And all that for some obscure NAS chipset. I would be interested to learn how many man-years of engineering time they have in that code... Oh, and they do actually have code for TCP-over-IPv6 offloading
• Hardware-accelerated recvfile support

As a summary: Kudos to those who have designed the product, and actually implemented all its features, in purely GPL licensed code. It's just such a pity that none of the code, not even the most generic and clean bits have been merged mainline.

Securitization

As a friend of mine (who has studied political science) recently told me about the process of securitization. Finally I know a word for the process that seems so commonplace in todays politics: Framing something that is actually a minor problem with some criminals into a question of essential survival, thus eliminating any rational debate about it.

Repairing VIA EPIA-ME6000 busted capacitors

Just before Christmas, my vdr powered diskless Linux-based digital video recorder went bust. A bit of testing revealed that the VIA EPIA-ME6000 main board itself must be dead.

I immediately ordered a replacement mini-ITX board without further investigating the broken one, expecting that the replacement might actually arrive before the Christmas holidays. Unfortunately this didn't happen. While replacing the board, I discovered that six of the 1000uF electrolytic capacitors went bust.

So today I finally found a bit of time (it's great to be able to find time to do things again) to try and replace the broken capacitors. Despite the new ones being slightly larger, the board now works again like a charm. And that at a total cost of 1.62 EUR.

So now I have two working mini-ITX boards. Guess I have to either find some use for it, or sell the new one again...

My personal favourite from 24C3: Xbox 360 hacking

I've seen quite a number of presentations live at 24C3 as well as recorded ones in the days following the event. While many of them cover important subjects, there is one lecture that is outstanding: "Deconstructing Xbox 360 Security".

The level of technicality of this presentation was just right. Finally something that went deep down into the technical details. Explaining what kind of flaws they found in the disassembled power PC object code.

I definitely want to see more lectures/presentations like this. Don't be afraid to overload the audience with technical details. Just go ahead with it :)

Also, this presentation has shown how far advanced the game console hacking is compared to mobile phone hacking (at least from what I've seen in the ETC (Ada-developers) and and Motorola hacker communities). The problems are similar: Completely undocumented hardware, cryptographic authentication of code by the boot loader (sometimes down to mask ROM), ...

So I hope that the mobile phone hacker community will grow and more people with this skillet, attitude and time will join. Free your phones!