Avian’s Blog

Third day started with Herald Welte's talk about running your own GSM network (He also had a talk the previous day about the state-of-the-art in smart phone architectures). He bought an old Siemens Base Transceiver Station, connected it to a PC (simulating a Base Station Controller) and basically setup a one cell GSM network using freely accessible GSM specs. The source for his OpenBSC software should be available shortly.

The interesting part was where he was able to get phones of random visitors to connect to his network, recording their IMSI and IMEI numbers and intercepting their SMS messages. They used this to create some statistics of where the congress visitors were from and found at least one telephone with a spoofed IMEI. Herald also announced that he bought all of the remaining stock of this hardware and that he is offering to resell pieces to any interested developers for 300€. The idea was that perhaps in August on HAR there will be an experimental GSM network running (provided somebody manages to solve all the legal problems - transmitting on the GSM band with any significant power requires a license).

In the science track there was Tor E. Bjørstad's guide to new stream cipher designs. He presented eSTREAM, an European project meant to develop new standardized ciphers to software and hardware implementations. The idea is that while AES has been widely deployed and tested it also means that it's the target of most attacks and the goal of the project was to develop alternatives. The project has come up with some promising new ciphers that endured the 4-year long testing period. But as Tor warned, the confidence in a cipher's strength can only increases with time, so AES is still the recommended choice for new software.

Back on the hacking track there was a presentation about breaking into the infamous Storm botnet. A small team managed to reverse engineer the Storm and found out how to present their computer as a controlling node of the P2P command & control structure. With this they could do practically everything they wanted with the computers in the network, from triggering DDOS to recursively disinfect nodes in the network. I wonder when they'll receive a friendly knock on the door from whoever created the botnet in the first place.

The same people also shared some of their experience in building honeypots. The most amusing part: how you can get most attackers to break into their own computer by simply mirroring their connections to your honeypot and recording everything.

Continuing on the same topic, there were also a talk about how to find exploits in Microsoft Office documents (Bruce Dang's ability to read assembly code from an executable written out in ASCII was a bit scary there). Later FX from Phenoelit showed the latest development in Cisco IOS attacks, like how to get stable code execution after a buffer overflow despite the large number of different OS images that are deployed in the wild.

The day ended with Hacker Jeopardy, some kind of a quiz with questions from various topics discussed at the congress. This year the quiz was in German, but was simultaneously translated from German into English for the rest of us.

Here's a couple of random shots around the congress:

This OLPC XO-1 is hanging in the hall, playing music from a playlist that anyone can modify.

A friendly reminder that the German Ministry of Interior is watching you (you can buy this guy's fingerprint molded in plastic on the base floor).

There's always a crowd around when these things are buzzing around the corridors (and occasionally going out of control and crashing into the said crowd).

A lot is going on around open firmware for various things. OpenWRT guys have this nice board in the Hackcenter.

And this was the presentation of the Soviet Underzögersdorf adventure game by Monochrom. Together with revolutionary Soviet music, narration in Russian, security guys in black with sunglasses occasionally arresting random people from the audience and a read waving flag in the background. Oh, and a bunch of beta-test candidates had to prove themselves by doing pushups and making up revolutionary slogans on the stage.

Here's a short summary of what was happening at CCC yesterday. I mostly spent it listening to talks, but I also saw a bunch of interesting hardware laying around the rooms and halls. A curiously-powerful-laser-controlled music synthesizer for example, a flock of flying drones, a home-made miniature replica of the Segway, and so on. I'll take a closer look at them today.

The conference officially started with the keynote of John Gilmore, on of the founders of the EFF. He shared some of his thought on this year's motto, Nothing to hide.

FAIFA is a tool for monitoring various power line communications networks. Last time I looked there was nothing on their homepage yet, but from what I understand it's similar to Kismet for wireless LAN. You can use it for example to keep an eye on your neighbor's network.

Steven Murdoch presented the results of the security evaluation his team did of the UK's chip & PIN payment system. He focused on the PIN entry devices, those little keypads where you enter your PIN. It turned out that once you circumvent physical measures that try to prevent tempering (case switches, sensor meshes), you can easily perform a number of bank frauds. One of the problems is that the contents of the magnetic stripe is stored on the chip unprotected (just like the stripe) and there are still devices out there that only rely on the magnetic stripe for authentication. It's also easy to read the PIN that was entered.

Karsten Nohl from Virginia showed that it is feasible to reverse engineer integrated circuits with some pretty basic equipment. Many trusted devices rely on a secret authentication or encryption key stored in hardware that should not be readable except for the crypto processor on the integrated circuit itself. What prevents you from reading this secret is a scrambling algorithm implemented in hardware using standard-cell technology. What they demonstrated is that you can reverse engineer a standard-cell circuit by polishing away each layer of the IC and taking pictures through a cheap optical microscope. With some adapted face recognition software it's then possible to automatically recognize each cell and get a logic diagram of the circuit, which implements the secret algorithm.

Then there was the iPhone hacking team, which described their work on making it possible to run any software they want on iPhone. The basic message of the talk was basically that if you want to make a device with such restrictions, you should implement them all at once. Apple on the other hand gradually introduced new protection features over time, and each addition was easily broken with the knowledge that was gained from breaking the last one. If everything would be in place right at the start, the job would be much harder.

Jacob Appelbaum from Princeton presented his (last?) talk on the subject of cold boot attacks, that is recovering the contents of the memory after the machine has been rebooted or even turned off for some time. It is practically possible to break any kind of software security this way - when you reboot the machine into your own software there is no OS and no restrictions on which memory you can read, meaning that you get access to all sorts of key stores and authentication tokens that were held in memory when the machine was turned off. He obviously had most fun breaking full-disk encryption systems. The problem is of course that you have to be able to read the memory relatively quickly. The contents of DRAM are gone after a minute or so, so this attack is limited to either a reboot or (with some cooling of the chips) swapping memory chips into a machine you have ready near by.

And finally there was Dan Kaminsky. He presented in his usual way the current problems with DNS infrastructure and the rest of the Internet. His way of talking reminded me of Rodney McKay character, but then again maybe I've just been watching too much science fiction recently.

Yesterday I visited the Deutches Technikmuseum in Berlin. One of the many interesting things I saw there (in fact too many to see properly in a single day) was also a collection dedicated to Konrad Zuse, a German designer of one of the earliest programmable computers.

In addition to being a capable engineer, he was obviously also a capable entrepreneur and an artist. He established a successful early computer company Zuse KG, which was later taken over by Siemens.

I didn't quite got the connection between his paintings and his electronic designs the exhibition was trying to make. What I did find fascinating however is that Zuse oversaw the design and construction of computers that spanned four different technologies: from his first, groundbreaking mechanical computer, through relays and vacuum tubes to discreet transistor circuits.

This is a working replica of Z 1. It's a mechanical binary computer with some electric components. It reads the program from a punched tape, decodes the instructions and executes them using a six registers and a small amount of working memory - the architecture very similar to a modern CPU, except that the program store is separated from data store (no need for that NXE bit then) and that instead of a high speed bus for I/O you have a keyboard and a mechanical display.

The logical circuits are build on the principle of a simple mechanical logic gate, that is constructed out of thin metal sheets. This makes for a much more compact appearance than Babbage's Difference engine I saw in London, which uses columns of wheels to do it's processing.

Z 11, using relay circuits.

Z 22, using vacuum tubes.

Z 23, using discreet transistor circuits.

I've seen a lot of discussion recently (e.g. BoingBoing, xkcd) on the Internet about the possibility of a vehicle moving directly downwind faster than the wind. I don't want to go into that debate, but what did caught my attention was the following cute video that demonstrates the behavior of a cart constructed out of three rollers under a moving ruler:

Theatrical skills of the author aside, what I found interesting is that very few people had any doubts about the validity of the experiment and the explanation given in this video. When I watched it for the first time, I was pretty sure the little plush monkey got it right. And after some back-of-the-envelope calculations I still thought he was tricked. The cart shouldn't be able to move at all.

So I did an experiment of my own and it just confirmed my thoughts. The experiment is easily duplicated and I encourage you to try it yourself.

However, just before posting my notes I realized there is one minor, but important difference between the geometry of the cart I analyzed and the geometry used in the video. I'm now confident that the video is genuine and I'll be posting the corrected calculations after I get back from Berlin.

Meanwhile, below is my original analytical solution followed by a video recording of my version of the same experiment (minus the furry spectators). Mind that it's still correct, it just provides an answer to a slightly different question (see if you can spot the difference).

Let's start with a simpler case of a single roller on a flat surface:

Here v_c is the velocity of the center of the roller relative to the ground, while v_r1 and v_r2 are the velocities relative to the center at different locations along the roller's surface. Remember, the magnitude of v_r is constant around the circumference while it's direction changes around the circumference and is always tangential to the surface.

Obviously, the velocity of the roller's surface at the point where it touches the ground must be 0 relative to the ground or the roller would be slipping. So for that point the following equation is true (subtracting magnitudes, since vectors are parallel and pointed in opposite directions):

Now that we know v_r, we can calculate the velocity of the top point of the roller (adding magnitudes, since vectors are again parallel, but pointed in the same direction):

So, in this case the top point is moving in the same direction as the center and at twice its speed relative to the ground. And this is of course also the speed of any non-slipping ruler that rests on the top of the roller.

This result is expected: if you're moving a large rock by rolling it on tree trunks, you put trunks in front of the rock and pick them up behind it.

Ok, so let's now go on to the cart. The situation is very similar to the previous example. The centers of all rollers are moving with the same velocity, v_c. At the points where the top roller touches the bottom two rollers surfaces must have identical velocities as there is no slipping. From here it follows that the magnitude of v_r is equal for all rollers.

Again, we can write equations for the points where the cart touches to top and the bottom surfaces:

And therefore:

So the ruler at the top can not move relative to the ground as long as it is not slipping. The crucial difference here was that the second roller rotates in the opposite direction to the top one. This changed the sign in the second equation, since vectors v_c and v_r were now pointed in the same direction at the bottom.

As you can see, the radii of the rollers don't even come into play in this calculation. So the final result is identical with arbitrary roller dimensions.

The conclusion therefore is that the ruler is either stationary in respect to the ground or two surfaces are slipping somewhere. It's impossible to move the cart by applying a horizontal force only to the ruler since the bottom rollers will apply exactly the same torque to the top roller, but in the opposite direction.

I've made a series of simple experiments that confirm the theory above. You can see them on video below (or on YouTube, if you can't see the embedded player):

You can see that moving the ruler in the 4th experiment didn't move the cart - it only caused the ruler to slip along the top wheel.

The only way to move the cart is to apply the force to it directly as in the 3rd experiment, or as the last experiment in the video shows, by resting the ruler on the cart at an angle, so that the force of the ruler is no longer parallel to the force of the ground. The force and torque diagram in that case is left as an exercise for the reader.

Again, you don't have to believe everything I said, but do try it yourself if you have any doubts. Experiments are fun and this one really just takes some cardboard and a couple of minutes (or seconds if you have Legos handy).

Last week Bodrato Stefano ported z88dk Z80 development kit to Galaksija using my ROM disassembly and development tools as a reference. Galaksija so joins thirty-something platforms that are supported by this retro software development package.

This means that in addition to the Z80 assembly and the built-in BASIC it is now also possible to develop new software for Galaksija in C. And what's even better, you can also compile and run software, originally written for other vintage (and not-so-vintage) computers. Here's for example a screenshot of Death Star, a game originally written for Texas Instruments TI-86 calculators running on my CMOS replica of Galaksija.

To make development easier, z88dk contains a number of platform independent libraries, from a standard C library to high-level graphics and sound libraries, all of which work out of the box on Galaksija thanks to Stefano. You're limited with the tiny amount of available RAM, of course. Although the C library plugs into the simple terminal emulation routines in ROM, a program using it can quickly get too large. A "Hello, world!" style program with a printf function is 1.4 kB (or around 20% of the total amount of RAM), so don't expect to run just any old Spectrum game on it. Planet of Death text adventure for example takes 13 kB, a bit too much for the original Galaksija's 6 kB (but looking at it, it might just be possible to cram it all in with some clever hacking - anyone up for the challenge?)

The sound library is especially impressive, supporting a number of sound effects and polyphonic synthesis using Galaksija's audio output and a bit banging algorithm (here's a sample recording).

To try it out, you need to have the latest CVS version of z88dk.

Another thing that bothered me about the new Eee is that the Ralink 2860 wireless card isn't well supported on Linux. The problem is that the only driver for this hardware that is currently even moderately useful is the Ralink's own driver. It's basically a Windows driver that has been ported to Linux without much regard to the architectural changes between these two systems.

For example, the driver contains own implementations of lots of components that are already available from other open source projects, like the WPA supplicant, kernel's mac80211 layer and so on. It also has it's own ideas of how to respond to the standard Linux Wireless Extensions API and worst of all, it has no fancy features like multiple virtual interfaces.

There is a project currently underway to support this hardware in the mainstream Linux kernel and the Ralink developers appear to be fixing their code. While I would love to help these efforts I'm a bit short on time lately, so I decided to simply replace the wireless module in the laptop for the time being.

It turns out that 701 and 901 use the same Mini-PCIe form factor for the wireless interface. So giving 901 a working Wi-Fi was just a matter of taking the superb Atheros AR5007EG card out of my old 701 and replacing the Ralink that came with 901.

The only minor problem I encountered with this swap is that I had to completely disassemble 701 to get to the PCIe slot on the bottom side of the motherboard (on 901 it is easily accessible behind the cover on the bottom of the laptop).

I decided to fix one of the more obvious problems with the new Eee 901 myself, instead of sending it back to UK under warranty. It would probably take a month or so for the round trip and even the first time DHL had problems delivering the package to my address. I also have had some issues with this computer that a warranty replacement wouldn't fix. And of course, there's the pleasure of breaking that warranty void label.

I mentioned that the silver row of the four hot keys was a bit flaky on my model: Only the left one worked properly (that's the one that turns off the backlight on the default installation), while the right three required too much force to register a press and didn't give the click feeling.

After taking the computer apart, it was obvious where the problem was: under the upper plastic shell is a long, narrow circuit board that holds four tiny SMD microswitches for the hotkeys. This board is only mounted onto the shell with two screws on each end, with the middle additionally stuck to the plastic with some sticky aluminum tape. This arrangement isn't strong enough to prevent the middle of the board bending under the pressure of the finger pressing down on a key.

When you press the key hard enough, the board bends enough to catch onto the wall of the battery compartment some tenths of millimeter below it, which makes it possible to actually press the key if you put some effort into it.

The solution was obvious: I padded the plastic below the circuit with some layers of Scotch tape, so that it provides better support for the hot keys circuit board (the tape is transparent, so it's a bit hard to see on the picture above - look at the top left end of the shiny battery compartment wall)

Is anybody else having this kind of problems? It seems a bit strange that only my particular laptop would have this flaw.

A couple of days ago I got the following error in the logs of my home server:

Dec 13 18:53:41 chandra kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 13 18:53:41 chandra kernel: Bank 2: 940040000000017a

MCE is short for Machine Check Exception - it's a way for the CPU to tell the software that internal error checking has detected a bit flip in one of the CPU's registers or execution units. Since the error was correctable in this case, nothing happened as far as software was concerned, except for a log message being generated.

One common case when this might happen is if an energetic particle hits the circuit. It creates an ionization path in the semiconductor, which causes a temporary short-circuit and a flip-flop storing one bit of information flips from one state into the other.

A lot of such particles come in form of cosmic rays from space, where they are among other things created by supernovae.

On the other hand, the thing that caused my CPU to hick up could also come from a much closer source, like a wholly unfashionable radioactive decay of an atom in the CPU's package.

I finally gave up to temptation and ordered a new Asus Eee 901 to replace my one-year old 701. What basically convinced me was the larger screen and promises of much longer battery autonomy. Larger SSD drive is also a nice addition, although I didn't find 701's 4 GB drive too restricting.

However, when the package arrived I must say I was a bit disappointed at the changes Asus made.

I got my first bad impression immediately when I picked up the computer out of the box. While the 701 feels robust, 901 looks like it won't take that much beating before it breaks. For example, the display hinge on 701 is tight. It's strong enough that I was able to pick the laptop by the screen without the display moving. It was one of the things that really set 701 apart from other laptops as far as mechanical durability is concerned. 901 on the other hand goes back to a standard loose hinge that moves if you bump the laptop too hard.

Then the are LEDs. Obviously Asus succumbed to the idea that the more LEDs the better. Really, designers of these things should read a thing or two about usability of interfaces: a LED should only be turned on if it means something is worthy of attention of the user. And it should only be blinking if something desperately requires some action.

901 on the other hand has one super bright blue LED on the charger that only tells you it's plugged in (now conveniently covered with black masking tape), two bright LEDs that just tell you the computer is turned on and a battery LED that blinks if the battery is full, but discharging (how surprising is that?).

Also the whole thing seems to be a bit sloppily built. The four silver hotkeys below the screen are bit broken - some only register a press if you press them really hard.

If I go on to the electronics inside, there are some more bad surprises. The Ralink wireless card is a far cry from the superb Mad-wifi-supported Atheros gem in the 701. It's tricky to setup in Linux, doesn't work well with Kismet and it's sensitivity is down in the dumps. I guess it's OK for your day-to-day home and office use, but forget about neighborhood surveillance.

The new 16 GB SSD is also a disappointing: it's very slow and surprisingly this shows the most when browsing the web with Firefox. It will sometimes annoyingly freeze for a second or two when opening a new web page or even when just entering an URL into the address bar. Some tweaks help mitigate the problem, but the bad feeling remains.

Well, not everything is bad of course. The hyperthreading Atom CPU is way faster then Celeron in 701. It also runs a lot cooler and is more comfortable to use. I haven't yet thoroughly tested the battery, but as far as I see Asus held its promise about that. Still, when you upgrade your laptop, you somehow expect that more things will get better than worse.

NewScientist reports that a Hollywood studio has arranged for their latest movie to be transmitted towards Alpha Centauri.

I'm sure any modestly intelligent life out there is already bored full of Hollywood and their recycled ideas. What's interesting though is that the people doing the transmission had to assure the movie makers that their precious intellectual property could not be intercepted by any resident of Earth. Funny, because as I understand the whole idea of this exercise is to provide the video for free to anyone listening on the other end. Which either means that studios don't believe that planets around our neighboring star are inhabited or that they've already shipped a rocket full of DRM encumbered receivers to them.

The report also says that the transmission will be done by Deep Space Communications Network, a company with a cheesy web site that sends any message to the stars for a price. Not surprisingly, they don't provide any technical details of the broadcast, but they do seem to have their own interesting idea of the prime directive. They say that they will only send NTSC or PAL signal (for which you must prove copyright ownership, of course). I guess any aliens with SECAM sets are out of luck then. Oh, and forget about telling those Klingon p'taks to beat it, because they will not send any offensive materials either.

Finally, note that they aren't NASA's DSN. Those guys have more serious things to do than provide marketing campaigns for movie producers.

In approximately two weeks the 25th Chaos Communication Congress will start in Berlin. It looks like this one will be as interesting as every one before it: hardware hacking workshops, talks about hardware, software, secret corners of your file systems and of course moar awsumness.

As always there will be an Eventphone DECT network on the conference and this year I'll actually have a (hopefully) compatible phone with me.

I'll be in Berlin from 26. December to 2. January, so maybe I'll finally also have some time to have a look at some other interesting things in Berlin outside of the congress center. Like some of their museums.

Now I just have to remember to check my laptop's hard drive for any traces of those nasty hacker tools before I step into Germany.