It's been announced at quite a few places, so you probably already heard about it: Miro 2.0, the new major release of the cross-platform Internet RSS audio/video aggregator and player has been released. Miro is available for Linux, Windows, and Mac OS X, the new release on Linux now features a "native" GTK+ widgets UI (instead of the Mozilla-based HTML widgets of earlier versions) and supports both a xine, as well as gstreamer renderer (for audio and video). I won't even attempt to list all the improvements and new features, please check the release notes and the feature list for details. Overall more than 670 issues have been fixed since the last 1.2.x series release. You can also watch this video (Ogg Theora, 10 MB) for a short introduction in Miro 2.0. Together with the software release, the getmiro.com website, as well as the online Miro Guide have been competely rewritten and are a lot more usable and better-looking than before. Finally, I have uploaded a new Miro 2.0 Debian package to unstable yesterday, by now it should be available from most mirrors. For Debian we're defaulting to xine at the moment, but please consult README.Debian if you want to switch to the gstreamer backend. Please test the new release extensively so the few remaining issues (if any) can be ironed out soon...

As you may know I maintain a Creative Commons licensed photoblog at my website. I'm also cross-posting some of the better photos to my flickr page. Even with my humble, and not really widely-known little photoblog, you can already see the Creative Commons license's effects on media sharing and remixing/reusing kick in. Quite a number of my photos have already been used by other people for various different purposes (blogs posts, articles, even album covers), including some of the "bigger" sites such as the Wall Street Journal Blog or Cult of Mac... Here's the list of places I know of where my photos are used. Please leave a comment if you spot more of them in the wild. I intend to keep this list updated as more of my photos appear elsewhere. (Oh, and I have no idea why people seem to be so obsessed with my "Sugar" photo...) Sugar

• Wallstreet Journal Blog: A Clue for Tumor Survival Lies in How Sweet It Is (blog post)
• Discover Magazine: Blood Sugar Surges May Be Responsible for Senior Moments (article)
• Dear Mark: Sugar Cravings (blog post)
• VentnorBlog: Today is World Diabetes Day (blog post)
• EcoSalon: What Does That Bargain Really Cost? What It Takes to Make 10 Everyday Items (blog post)
• Paradox 365: The sugar cubes (riddle)
• Married to Fitness: Sweeteners Are Everywhere: Look Out for Hidden Sugars! (blog post)
• Charting the Course To Better Health Care (blog post) dead link
• creativecommons.org: CC Q&A and the joy of being reused (blog post)

Clock

• Angel Ortega: Dispersoul 1 (album cover)

Autumn Leaf

• The music of J.D. Warrick: GOING, A. THE LEAVING (album cover)

Scissors

• 20somethingfinance: Is your 401k Match Being Cut? This May be your Hint to Find a New Job (article)

Soccer World Championship 2006

• Nicht nur in China versteht man kein Englisch... (blog post)
• ununun.de: Zu viel des Guten (blog post)

Organized

• Context is King: Organized (blog post)

Dandelion

• Herbal Healthcare: Dandelion (blog post)

Intel Celeron CPU

• Cult of Mac: Intel Unveils Lower-cost Mobile Core 2 Quad (article)

Smoke

• Carbon Trading: Australian Targets Loom (blog post)

Sun and trees

• Let's Read and Find Out!: The sky, the sun, the stars (blog post)

POSIX.1g

• Nyfiken Vital: Nya funktioner och tj nster i Nyfiken vital (blog post)

...goes to: Seagate and/or heise.de (translation here).

As I wrote quite a while ago, I set up a RAID5 with three
IDE disks at home, which I'm using as backup (yes, I know that
RAID != backup) and storage space. A few days ago, the RAID was put to a real-life test for the first time, as one of the disks died. Here's what that looks like in dmesg:

raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
 --- rd:3 wd:3
 disk 0, o:1, dev:hda2
 disk 1, o:1, dev:hdg2
 disk 2, o:1, dev:hde2
[...]
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 4 bytes in FIFO
hdg: dma timeout error: status=0x50   DriveReady SeekComplete  
ide: failed opcode was: unknown
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x50   DriveReady SeekComplete  
ide: failed opcode was: unknown
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x58   DriveReady SeekComplete DataRequest  
ide: failed opcode was: unknown
hdg: DMA disabled
ide3: reset: success
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x58   DriveReady SeekComplete DataRequest  
ide: failed opcode was: unknown
hdg: DMA disabled
ide3: reset: success
hdg: status timeout: status=0x80   Busy  
ide: failed opcode was: 0xea
hdg: drive not ready for command
hdg: lost interrupt
hdg: task_out_intr: status=0x50   DriveReady SeekComplete  
ide: failed opcode was: unknown
hdg: lost interrupt
hdg: task_out_intr: status=0x50   DriveReady SeekComplete  
ide: failed opcode was: unknown

That's when I realized that something was horribly wrong. Not long after that, these messages appeared in dmesg. As you can see the software-RAID automatically realized that a drive died and removed the faulty disk from the array. I did not lose any data, and the system did not freeze up; I could continue working as if nothing happened (as it should be).

 md: super_written gets error=-5, uptodate=0
 raid5: Disk failure on hdg2, disabling device.
 raid5: Operation continuing on 2 devices.
 RAID5 conf printout:
  --- rd:3 wd:2
  disk 0, o:1, dev:hda2
  disk 1, o:0, dev:hdg2
  disk 2, o:1, dev:hde2
 RAID5 conf printout:
  --- rd:3 wd:2
  disk 0, o:1, dev:hda2
  disk 2, o:1, dev:hde2

This is how you can check the current RAID status:

 $ cat /proc/mdstat
 Personalities : [raid6] [raid5] [raid4] 
 md1 : active raid5 hda2[0] hde2[2] hdg2[3](F)
       584107136 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]

The "U_U" means two of the disks are OK, and one is faulty/removed. The desired state is "UUU", which means all three disks are OK. The next steps are to replace the dead drive with a new one, but first you should know exactly which disk you need to remove (in my case: hda, hde, or hdg). If you remove the wrong one, you're screwed. The RAID will be dead and all your data will be lost (RAID5 can survive only one dead disk at a time). The safest way (IMHO) to know which disk to remove is to write down the serial number of the disk, e.g. using smartctl, and then check the back side of each disk for the matching serial number.

 $ smartctl -i /dev/hda   grep Serial
 $ smartctl -i /dev/hde   grep Serial
 $ smartctl -i /dev/hdg   grep Serial

(ideally you should get the serial numbers before one of the disks dies) Now power down the PC and remove the correct drive. Get a new drive which is at least as big as the one you removed. As this is software-RAID you have quite a lot of flexibility; the new drive doesn't have to be from the same vendor / series, it doesn't even have to be of the same type (e.g. I got a SATA disk instead of another IDE one). Insert the drive into some other PC in order to partition it correctly (e.g. using fdisk or cfdisk). In my case I needed a 1 GB /boot partition for GRUB, and the rest of the drive is another partition of the type "Linux RAID auto", which the software-RAID will then recognize. Then, put the drive into the RAID PC and power it up. After a successful boot (remember, 2 out of 3 disks in RAID5 are sufficient for a working system) you'll have to hook-up the new drive into the RAID:

 $ mdadm --manage /dev/md1 --add /dev/sda2
 mdadm: added /dev/sda2

My new SATA drive ended up being /dev/sda2, which I added using mdadm. The RAID immediately starts restoring/resyncing all data on that drive, which may take a while (2-3 hours, depends on the RAID size and some other factors). You can check the current progress with:

 $ cat /proc/mdstat 
 Personalities : [raid6] [raid5] [raid4] 
 md1 : active raid5 sda2[3] hda2[0] hde2[2]
       584107136 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]
       [>....................]  recovery =  0.1% (473692/292053568) finish=92.3min speed=52632K/sec

As soon as this process is finished you'll see this in dmesg:

 md: md1: recovery done.
 RAID5 conf printout:
  --- rd:3 wd:3
  disk 0, o:1, dev:hda2
  disk 1, o:1, dev:sda2
  disk 2, o:1, dev:hde2

In /proc/mdstat you'll see "UUU" again, which means your RAID is fully functional and redundant (with three disks) again. Yay.

 $ cat /proc/mdstat
 Personalities : [raid6] [raid5] [raid4] 
 md1 : active raid5 sda2[1] hda2[0] hde2[2]
       584107136 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

Btw, another nice utility you might find useful is hddtemp, which can check the temperature of the drives. You should take care that they don't get too hot, especially so if the RAID runs 24/7.

 $ hddtemp /dev/hda
 dev/hda: SAMSUNG HD300LD: 38  C
 $ hddtemp /dev/hde
 dev/hde: SAMSUNG HD300LD: 44  C
 $ hddtemp /dev/sda
 dev/sda: SAMSUNG HD322HJ: 32  C

I've been owning a Nintendo Wii for quite a while now, but so far only played an occasional game of tennis or the like. Over the holidays I got The Legend of Zelda: Twilight Princess, which is a really nice game in itself. What is even more interesting though, is that this game allows you to run homebrew software on your Wii. What you usually want to do, is to use the so-called Twilight Hack to install the Homebrew Channel on your Wii (you'll need an SD card and the Twilight Princess game for this). Once the process has finished you won't need the game anymore though. So, here's a quick tutorial on how to install the Homebrew Channel. I basically followed the Setting up your Wii for Homebrew HOWTO from wiibrew.org. Requirements An SD card max. 2GB in size (not an SDHC card!), an SD card reader in your PC or laptop, and the Twilight Princess game (which you must play at least once). Backup First, you'll want to backup your Twilight Princess save games (if any). For that, we format the SD card (it needs a FAT16/FAT32) filesystem.

 $ mkfs.vfat /dev/mmcblk0p1 (you may need to change "mmcblk0p1" to whatever fits your setup)

Now insert the SD card into the Wii, start the Wii, go to Wii Options --> Data Management --> Save Data --> Wii and copy your Twilight Princess save games onto the SD card. Then, poweroff, remove the SD card, insert it into your laptop/PC and copy the save games to a safe place.

 $ mount -t vfat /dev/mmcblk0p1 /mnt
 $ mv /mnt/private ~/zelda_savegames

Twilight Hack and Homebrew Channel Next up: download the Twilight Hack and Homebrew Channel, and put the files on the SD card:

 $ wget http://hbc.hackmii.com/dist/twilight-hack-v0.1-beta1.zip
 $ unzip twilight-hack-v0.1-beta1.zip
 $ cp -r private /mnt
 $ wget http://hbc.hackmii.com/dist/the_homebrew_channel-1.0.1.tar.gz
 $ tar xfvz the_homebrew_channel-1.0.1.tar.gz
 $ cp the_homebrew_channel-1.0.1/boot.dol /mnt
 $ umount /mnt

Now remove the SD card, insert it into the Wii and power-up the Wii. Go to Wii Options --> Data Management --> Save Data --> Wii, delete the Wii Twilight Princess save games, then copy the "Twilight Hack" save game from the SD card onto the Wii (you need to select the correct one for your region). Quit the menu, start Twilight Princess, load the "Twilight Hack" savegame and finally talk to the person in front of you (do not perform any other actions, or the Wii may crash!). Follow the remaining instructions on the screen and you're done. You now have an additional channel named Homebrew Channel where all your homebrew programs/games (and your own Free Software programs you may write/port) will appear. Installing homebrew software So far, there are no real applications in the Homebrew Channel, you need to put all the homebrew software you want on the SD card. There's a huuuge list of applications and games to choose from, many of them Free Software with source code, some however are binary-only. Basically, you put each application in a sub-directory of apps/ on the SD card, the most important file in every sub-directory is always boot.dol. If you have a boot.elf file instead, you'll probably need to convert it using the ELF to DOL converter. Restoring Twilight Princess save games You may now want to restore your Twilight Princess save games onto the Wii, you no longer need the "Twilight Hack" save game. Put your ~/zelda_savegames directory on the SD card and name it private/ again. Insert the SD card into the Wii and copy the save games on the Wii (similar procedure as above). Have fun with homebrew software on your Wii, or even better write your own software or port existing Linux applications/games!

Yes, it's that time of the year again... it's almost Christmas, which means that I once again updated my 10 + 100 Creative Commons Christmas Songs blog article I originally wrote in 2005. That's a collection of a lot of freely downloadable, Creative Commons licensed Christmas music. Some of the older entries in the list are no longer available unfortunately, some only needed a URL update, and I also added more than 30 new songs this year. This currently makes a total of 256 CC Christmas songs (more will probably be added over the next few days), so head over to the full song list and get those downloads started... (Photo: Wikipedia. Author: Malene Thyssen. License: GFDL 1.2 / CC-BY-SA 2.5)

Just FYI, I've updated my Playing Starcraft on Linux using Wine article from a few days ago, adding some more info about:

• Brood War installation.
• Multiplayer LAN games, firewall settings for network gaming.
• Playing Starcraft on netbooks (which works astonishingly well), tested on my One A110 VIA VX800 netbook.

Please read the updated article for details.

Here's a quick intro to what I'm hacking on at university. This is a new omnidirectional robot platform we got in the lab. It's controlled via CanOpen-over-EtherCAT (which is a realtime Ethernet protocol "extension", more or less). As we don't want to deal with any of the Windows software that's usually used for such stuff, we're employing the IGH EtherCAT Master (r1549) implementation (GPL/LGPL) on Linux and it works quite nicely. I hacked together a few shell scripts that invoke the ethercat command line tool with certain parameters to control the motor velocities "by hand", which then soon turned into a "dancing" demo of the robot ;-) See http://www.youtube.com/watch?v=n_vF4NK26fM for the YouTube video of the dancing bot. It's just a quick (hardcoded) hack for now, there's lots of room for improvements, of course (e.g. detect baselines of random music you throw at it). The demo in the background is the fantastic Masagin by Farbrausch. I've also hacked up a small Python script to control the robot with a Wiimote (using cwiid on Linux), which also works quite nicely. I further plan to make a small program for controlling it via a 3D mouse or the like in the future... The longer-term plan for the robot platform is that it'll get a "backbone" and two very nice robot arms for grabbing stuff etc.

If you’ve set up an online shop, are your product photos saying more about you than you intended?

“there’s a huge amount of potentially privacy-sensitive metadata in your typical JPEG as generated by your camera (including camera type, settings, date/time, maybe even GPS coordinates of your location, etc).” Source: jhead - List and modify EXIF fields in JPEG photos [Uwe Hermann's blog]

Even worse, if you’ve been using images from your suppliers or the manufacturers without permission, the metadata can be a dead giveaway. You really shouldn’t be using them without permission anyway, though. If you’re using your own photos, want to remove the camera data and you’re not comfortable using the command line, most graphics editors like GIMP allow you to edit or remove that extra information too (I think it’s on Save As… OK… Advanced Options and untick “Save EXIF data” in GIMP). It’s just a bit slower to convert lots of images with a GUI. (I’d usually do that sort of thing from the command line for TTLLP customers.) One fringe benefit is that removing the thumbnails and EXIF makes the images a bit smaller, so they’re quicker to download!

Here's a quick HOWTO for using Wine to play Starcraft on a Linux machine.

  $ apt-get install wine (as root)
  $ winecfg

The winecfg (graphical) utility will setup some config file defaults in your ~/.wine directory. Click on Graphics and activate Allow DirectX apps to stop the mouse leaving their window. Also, click on Audio (a dialog will pop up, just click OK). This will autodect your soundcard and setup Wine to use it. Under Drives click Add (this will add D:) and change the path to /media/cdrom, so that Wine knows about your CD-ROM drive. Finally click OK to close winecfg and save the settings. The next step is to insert the Starcraft CD-ROM into the drive and start the installer using Wine:

  $ mount /media/cdrom (as root)
  $ wine /media/cdrom/setup.exe

Follow the instructions in the installer until the Starcraft install is finished (you'll need your CD key number), then exit the installer (don't start playing Starcraft right away). The next step is to get the latest patch and get rid of the need to insert the CD-ROM every time.

  $ wget http://ftp.blizzard.com/pub/starcraft/patches/PC/SC-116.exe
  $ wine SC-116.exe

After the patch is installed click OK and Starcraft will be started (very annoying). Leave the game again. We'll get rid of the CD-ROM requirement now:

  $ cp /media/cdrom/install.exe ~/.wine/drive_c/Programme/Starcraft/StarCraft.mpq

That's a pretty big file, it may take a while. You might have to change "Programme" in the path (I have the German Starcraft version). That's it. You can now play Starcraft (without needing the CD-ROM) using:

  $ wine ~/.wine/drive_c/Programme/Starcraft/StarCraft.exe

A good thing is, it even works nice and fast with the open-source nv NVIDIA driver (no need to install the proprietary driver). I noticed one very annoying "bug" with the mouse behaviour at first. The mouse would sometimes just get stuck during the game (which is a total disaster of course, if you're in the middle of a fast-paced game). Left-clicking somewhere would "unstuck" the mouse, but it's still very bad. After many, many hours of reading bugreports and trying various patches I finally found out the root cause for the problem. It's somehow related to my window manager (IceWM); whenever you move the mouse to the bottom of the Starcraft screen (where the IceWM status bar is, even though it's not on top or even visible, and even though Wine/Starcraft runs in full-screen mode!), something funny happens with X11/IceWM and the mouse gets stuck. I haven't yet found out if/which IceWM option could fix this behavior, but I have a small work-around. Just start Wine directly on a second X11 server with Starcraft (without any window manager being involved):

  $ xinit -e '/usr/bin/wine ~/.wine/drive_c/Programme/Starcraft/StarCraft.exe' -- :1

No patches needed (stock Wine from Debian unstable works fine, that's version 1.0.1 right now). I hope this saves other people some debugging time...

jhead is a very nice and very powerful command line utility to mess with JPEG headers (esp. EXIF fields).

  $ apt-get install jhead

It can display/extract a great amount of metadata fields from JPEG files and also extract the thumbnails stored in JPEG files (if any). The following will list all known metadata fields from a sample photo:

  $ wget http://farm4.static.flickr.com/3173/3061542361_60acb0904b_o.jpg
  $ jhead *.jpg
  File name    : 3061542361_60acb0904b_o.jpg
  File size    : 1074172 bytes
  File date    : 2008:11:26 23:38:04
  Camera make  : Panasonic
  Camera model : DMC-FZ18
  Date/Time    : 2008:03:05 15:45:52
  Resolution   : 3264 x 2448
  Flash used   : No
  Focal length : 4.6mm  (35mm equivalent: 28mm)
  Exposure time: 0.0100 s  (1/100)
  Aperture     : f/3.6
  ISO equiv.   : 100
  Whitebalance : Auto
  Metering Mode: matrix
  Exposure     : program (auto)
  GPS Latitude : N %:.7fd %;.8fm %;.8fs
  GPS Longitude: E %;.8fd %:.7fm %;.8fs
  GPS Altitude : 174.00m
  Comment      : Aufgenommen auf dem <a href="http://www.froutes.de/TT00000014_Ars_Natura">Kunstweg Ars Natura</a>.
  ======= IPTC data: =======
  Record vers.  : 4
  Headline      : Felsburg auf dem Felsberg
  (C)Notice     : www.froutes.de
  Caption       : Aufgenommen auf dem <a href="http://www.froutes.de/TT00000014_Ars_Natura">Kunstweg Ars Natura</a>.

As you can see there's a huge amount of potentially privacy-sensitive metadata in your typical JPEG as generated by your camera (including camera type, settings, date/time, maybe even GPS coordinates of your location, etc). You can extract the thumbnail stored in all JPEGs in the current directory with:

  $ jhead -st "&i_t.jpg" *.jpg
  Created: '3061542361_60acb0904b_o.jpg_t.jpg'

Note that the JPEG thumbnail does not necessarily show the same picture as the JPEG itself. Depending on the image manipulation software that was used to create the edited/fixed/cropped JPEG, the thumbnail may still reflect the original JPEG contents (see sample image on the right-hand side). This is a huge potential privacy issue. There have been a number of articles about this some years ago, in case you missed them:

• disLEXia: Hidden data in Document Formats
• disLEXia: EXIF Thumbnail in JPEG images (many sample JPEGs and their differing thumbnails)
• Kevin Cohen: Digital Still Camera Forensics (PDF)

Thus, an important jhead command line to know is the following, which removes all metadata (including any thumbnails) from all JPEG images in the current directory:

  $ jhead -purejpg *.jpg
  Modified: 3061542361_60acb0904b_o.jpg

As you can see the result is that only very basic information can be gathered from the file afterwards:

  $ jhead *.jpg
  File name    : 3061542361_60acb0904b_o.jpg
  File size    : 1052506 bytes
  File date    : 2008:11:26 23:38:04
  Resolution   : 3264 x 2448
  $ jhead -st "&i_t.jpg" *.jpg
  Image contains no thumbnail

I recommend doing this for most photos you make publically available on sites like flickr etc. (unless you have a good reason not to). Finally, see the jhead(1) manpage for lots more options that the tool supports.

Today I had to work with a really old svn repository again, which was still in the old bdb format (not in the newer and recommended fsfs one). This caused quite some problems, like, um... you cannot checkout, update, or commit anything. $ svn co file:///path/to/myrepo
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///path/to/myrepo'
svn: Berkeley DB error for filesystem '/path/to/myrepo/db' while opening environment:
svn: DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.6 doesn't match environment version 4.4 A quick search revealed that this is bug #342508, a solution is/was supposedly mentioned in /usr/share/doc/subversion/README.db4.3 (which does no longer exist in the Debian unstable package). Luckily this blogpost has some details. So, the short HOWTO for upgrading an svn repository of one Berkeley DB version to another one is: $ cd /path/to/myrepo/db
$ db4.4_checkpoint -1
$ db4.4_recover
$ db4.4_archive
$ svnlook youngest ..
$ db4.6_archive -d In this case I upgraded from 4.4 to 4.6 (do "apt-get install db4.4-util db4.6-util" if necessary). While I was at it, I also switched the repository to the fsfs format then: $ svnadmin dump /path/to/myrepo > myrepo.dump
$ mv /path/to/myrepo /path/to/myrepo.bak
$ svnadmin create --fs-type fsfs /path/to/myrepo
$ svnadmin load /path/to/myrepo < myrepo.dump Maybe this is helpful for some other people out there.

Just FYI, I've recently updated the OpenOCD Debian package in unstable. OpenOCD is a Free Software JTAG utility which currently supports quite a large number of JTAG adapters and various CPUs/targets (many ARM and now also some MIPS ones). It's being used by a number of Free Software related projects such as OpenMoko and many others. Here's an example of how you usually use the (new) OpenOCD with a cheapo parallel port JTAG device. First, start the OpenOCD server, providing it an interface config file and a target config file (you can copy/adapt them from /usr/lib/openocd/ interface,target /*.cfg, or use those files directly if they work for your target, of course).

  $ openocd -f parport.cfg -f lpc2148.cfg

Then, in another xterm for example, connect to the now-running OpenOCD telnet server. Here you can now run various commands to probe, control and program the JTAG device(s). Try help for a list of commands. As an example, for flashing a binary onto some LPC2148 eval board you would do something like this:

  $ telnet localhost 4444
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.
  Open On-Chip Debugger
  > reset init
  JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
  srst pulls trst - can not reset into halted mode. Issuing halt after reset.
  target state: halted
  target halted in Thumb state due to debug-request, current mode: Supervisor
  cpsr: 0x800000f3 pc: 0x7fffd2a2
  requesting target halt and executing a soft reset
  target state: halted
  target halted in ARM state due to debug-request, current mode: Supervisor
  cpsr: 0x800000d3 pc: 0x00000000
  > flash write_image /home/foo/program.bin 0
  wrote 1236 byte from file /home/foo/program.bin in 0.533683s (2.261701 kb/s)
  > resume 0

The final resume 0 will start to execute your program on the ARM LPC2148 microcontroller. Check out the openocd info page (info openocd on the command line) for lots more documentation.

Here's a nice opportunity for everyone to learn more about coreboot, a Free Software / Open Source firmware/BIOS for x86 PCs. Ron Minnich, founder of the LinuxBIOS (now called coreboot) project, Peter Stuge of Stuge Konsult, and Stefan Reinauer of coresystems GmbH have given a presentation for the Google Tech Talks series recently. The topic was (of course) coreboot, its history, goals, features and technical details, surrounding tools and libraries such as flashrom and libpayload, as well as an automated test system for running a hardware test-suite upon every checkin in the coreboot repository. A video of the talk, aptly named coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware (134 MB), is available from Youtube, get it for instance via:

  $ apt-get install youtube-dl
  $ youtube-dl http://www.youtube.com/watch?v=X72LgcMpM9k

The talk includes various demos of coreboot and various payloads you can use with coreboot. One nice example is the TINT payload, a Tetris-like game for Linux (apt-get install tint for the curious), which has been reworked to be usable as a coreboot payload. So, yes, you can now put Tetris in your BIOS ROM chip and play it from there (no hard drive required). Other demos included some cluster nodes with coreboot, and a "normal" x86 desktop board booting coreboot + Linux in a very few seconds (much room left for optimizing there though, if you really want to get into fast booting). Check out the full talk for more infos, and if you're willing to give it a try (see the list of currently supported boards), contact us on the mailing list or join the #coreboot IRC channel on Freenode.

Fun stuff I just stumbled over: a personal/human airbag from Japan, supposedly meant for elderly people who might fall and injure themselves. Watch a video of the airbag in action on Youtube (no need for crappy Flash player, you can use youtube-dl for instance). Such a device could be a lot of fun I imagine; make it cheap enough and lots of people will buy it just for fun falling-on-your-back experiments :-)

Here's a great country-folk-rock style tune for your enjoyment... Song: Homeless Bones - Golden Grain (2:30 min, 2.3 MB)
License: CC-by-nc-sa 2.5
Source: archive.org
Purchase from: ?

...next time you write such a piece of malware, how about making it do something useful (instead of nefarious) for a change, say, have your botnet zombies become Tor exit nodes? kthxbye.

This is part 1 of a series on articles about the Firewire security issues mentioned below. For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can

• read arbitrary RAM contents from the victim's system,
• overwrite arbitrary RAM contents with whatever you want,
• and perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more...

All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable. In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment! Papers, Attacks, and Tools Over the years a number of presentations and papers have been released with information about these Firewire issues. Maximilian Dornseif et. al. The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic:

• Pacsec 2004: 0wned by an iPod (PDF)
• 21C3: Hacking with Fire / Feuriges Hacken - Spa mit Firewire (PDF)
• Cansecwest 2005: Firewire: all your memory are belong to us (PDF)

They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs:

• pyfw-20041111.tar.gz: Mac OS X Firewire bindings for Python, various demos
• http://c0re.23.nu/c0de/pyfw/: Other versions of the above code
• pyfw_linux.tar.gz: Linux Firewire bindings for Python (can be used with above demo code on Linux)
• ipod-linux-pyfw.tar.bz2: Instructions (+ disk image) on how to turn your iPod into a Firewire attack tool

Adam Boileau In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools:

• pythonraw1394-1.0.tar.gz: Python bindings for libraw1394 (Linux). Tools: businfo, romtool, 1394memimage
• winlockpwn: Python script which can circumvent a locked Windows XP screen (an arbitrary password will log you in)
• bioskbsnarf: Grabs/shows the BIOS keyboard buffer via Firewire (which often contains your BIOS password)

Peter Panholzer As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know.

• Whitepaper: Physical Security Attacks on Windows Vista (PDF)
• Bugtraq Thread about the whitepaper

David R. Piegdon The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394.

• 2007: OpenChaos: hacking in physically addressable memory (no extra slides)
• Easterhegg 2008: FireWire Hacking: paper (PDF), slides (PDF)
• More papers here...
• http://0null.net/software/SEAT1394/: tools and libraries for pyhsical memory access via Firewire/DMA: 1394csrtool, liblinear, libphysical, debug-sshkey, dump-memory, remote-ps, show-stack, snarf-sshkey, test-all-pagedirs, dmashell, ...

I'll go into much more detail on how the tools are used and what they can do in another follow-up article. Mitigation There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures. Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable... If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you. Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices: Mitigation: Linux Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later). Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below. Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support:

  $ modprobe ohci1394 phys_dma=0

I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless. As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits). Mitigation: Mac OS On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext:

  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore. The tests were done on a Mac OS X Tiger (I think) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X... Mitigation: Windows As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau). The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above). So far I've tested Windows XP SP2/SP3 successfully with Adam Boileau's tools. I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment. Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/... On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-) As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system... Conclusion That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse. I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

Have you ever wondered how long it would take to create a 32768 bit RSA key with ssh-keygen? Well, I did.

   $ time ssh-keygen -t rsa -b 32768 -f ~/.ssh/tmp32768 -N foobar -q
   real    244m31.259s
   user    244m15.664s
   sys     0m4.736s

In other words, on my test system (AMD X2 CPU with 1.8 GHz per core) it took ca. 4 hours. This is likely very dependent on how much entropy you can get (and how fast), so take the numbers with a grain of salt. A second key with 32767 bits (one less) took 16 hours, for instance. The resulting tmp32768 (private key) file is ca. 25 KB big, the tmp32768.pub (public key) file is 5 KB big. There's likely no noticeable performance hit for ssh or scp AFAICS, as all data transfers are done with a symmetrical session key, not the RSA key itself. Only the initial connection "handshake" will take ca. 40 seconds longer... And yes, 32768 is the maximum RSA key size you can currently create with OpenSSH, go file a bug report if that's not enough for you ;-) However, as I then noticed, this key will not actually work. When you put it in some authorized_keys file and try to login, the handshake will fail and the server-side will see the following error in /var/log/auth.log:

  sshd[xxxxxx]: error: RSA_public_decrypt failed: error:04067069:lib(4):func(103):reason(105)

I first thought I found an off-by-one error, but the 32767 bit key (one bit less) didn't work either. After looking through the OpenSSH and OpenSSL code as well as the RSA_private_decrypt(3SSL) manpage a bit, I saw that OpenSSH uses the RSA_PKCS1_PADDING parameter. My current theory is thus that some padding is making the key not work. I'm now creating a key with 11 bits less bits than 32768, let's see what happens. For the record, a key with 16384 bits does work just fine. Anyway, I'll probably report this as "bug" (more a theoretical than a practical problem, though) as ssh-keygen let's you generate RSA keys which will never work in practice...

I've just updated my DIY secure pseudo-DDNS setup using ssh article/HOWTO a bit, in order to make it simpler to set up (no more extra scripts required) and a bit more secure (by using command= and no-port-forwarding,no-X11-forwarding,no-agent-forwarding in the /home/user/.ssh/authorized_keys file, for instance). If you've considered employing such as solution please revisit the article for updated instructions.