Category Archives: Microcontroller

Installing Debian on a Sheevaplug into Flash

Ok, so you are looking for a comprehensive guide on how to install a modern Debian system into the Flash memory of your Sheeva Plug? Your googling has paid of – look no further!

What we will do in this guide:

  • Update the bootloader to a recent version which supports direct booting from ubifs partions. So you can just use the stock Debian kernel without any hassle or SD card.
  • Install Debian to a ubifs filesystem on the Sheevaplug flash.

Continue reading Installing Debian on a Sheevaplug into Flash

HOWTO: Fixing a broken EDID EEPROM with a Bus Pirate v4

This post is about fixing a broken EDID ROM in a monitor. There are several ways to do this. Typically this involves writing the EEPROM with the Windows only tool PowerStrip (see here for a HOWTO) . Here I want to present an alternative solution using the Dangerous Prototypes Bus Pirate – a device which every hardware hacker with self-respect should have anyway. You should already be tech-savvy to attempt this procedure.


So I own 3 Samsung Syncmaster 2343BW with a staggering 2048×1152 pixels of resolution on 23″. When I bought them 3 years ago – this was really amazing. (Nowadays, such monitors are not even for sale anymore… but there is the ipad… Hopefully Apple sets a trend here for higher resolution…

So one of these monitors often suffers from a broken EDID EEPROM. Since this ROM is used to store all important information for Plug&Pray, the monitor not being detected anymore at all. I had this happen to me 3 times during warranty and they always exchanged the whole motherboard.  But unfortunately continues to appear after warranty, so I set out to fix it myself.

Continue reading HOWTO: Fixing a broken EDID EEPROM with a Bus Pirate v4

ChibiOS based STM32 bootloader example

Hi there,

since I’ve finally but my last oral exam for this semester behind me there is more time for me to hack on various stuff again.

Some of you might now that I’m a big fan of of the ChibiOS paired with the awesome STMicrolectronics STM32F series of Cortex-M3 microprocessors. These days I’m more and more into developing products which will run and work i.e. in Belgium. So there is no easy way to just pop by and deliver a firmware update over JTAG or there must be at least one remote controllable computer with a JTAG probe – not an elegant solution.

But there is hope, the STM32 chips do include the possibility to update the Flash ROM from inside a boot loader. Now, there are examples for boot loaders but I found most of them to be too “hackish”. So I set out to write my own boot loader based on ChibiOS. The example is targeting the Olimex STM32P107 development board but should be easy to adapt to other boards. You can find the final result on my github page:

The example includes helper function abstracting the flashing process. The example implementation demos reading the firmware in Intel Hex format from a SD card.



Hacking Basler BIP2 cameras

In the previous post I’ve praised the Basler BIP2 IP cameras for their great hardware and software. But sometimes using the build in software is not enough and the hacker in me always wants to have administrator (root) access to all Linux systems I own, be it my Laptop, Router or just my ebook reader.


Finding a hole

The firmware of the camera is not intended to be accessed by the user. So there is no telnet/ssh interface.

Finding a serial port

First I hoped to find a serial port, which would allow me to communicate with the u-boot bootloader. Sadly, there is only a RS-485 interface in the back of the camera which I could not connect to my laptop. I also tried to probe the PCB which has a 4 pin connector, but there is no serial signal on it.

Probing the firmware update mode

My next step was to investigate firmware updates which can be uploaded via the web interface of the camera. Luckily Basler provides a firmware update for its BIP2 cameras on their webpage.

Cracking the ZIP file

The update file is called FW-3.5.0.bin and is a password encrypted ZIP archive.

$ unzip -l -v FW-3.5.0.bin
Archive:  FW-3.5.0.bin
 Length   Method     Date    Time   Name
--------  ------  ---------- -----  ----
     260  Defl:X  2011-10-24 17:19
       0  Stored  2011-10-24 17:19  data/
      16  Stored  2011-10-24 17:19  data/bf.version
   32768  Defl:X  2011-10-24 17:19  data/image.b_53.ubl.bin
     849  Defl:X  2011-10-24 17:19  data/
  294912  Defl:X  2011-10-24 17:19  data/image.b_60.u-boot.bin
   32768  Defl:X  2011-10-24 17:19  data/image.b_51.ubl.bin
    1323  Defl:X  2011-10-24 17:19  data/check.awk
25436160  Defl:X  2011-10-24 17:19  data/usr.ubifs
   32768  Defl:X  2011-10-24 17:19  data/image.b_55.ubl.bin
  425984  Defl:X  2011-10-24 17:19  data/image.b_25.u-boot.bin
  393216  Defl:X  2011-10-24 17:19  data/image.b_1.ubl.bin
    1307  Defl:X  2011-10-24 17:19  data/info.txt
  294912  Defl:X  2011-10-24 17:19  data/image.b_78.u-boot.bin
   32768  Defl:X  2011-10-24 17:19  data/image.b_57.ubl.bin
  294912  Defl:X  2011-10-24 17:19  data/image.b_96.u-boot.bin
       9  Stored  2011-10-24 17:19  info.txt
     244  Defl:X  2011-10-24 17:19  Readme.txt
   63490  Defl:X  2011-10-24 17:19  ReleaseNotes.txt
    4957  Defl:X  2011-10-24 17:19
--------                            -------
27343623                            20 files


The above investigation yields the structure of the encrypted zip archive. Unfortunately the password used to encrypt this file was vision01 which  was to long to break via Brute-Force (it would have taken 10 days to check up to 8 characters even with GPU support).

Building our own firmware

Knowing that it was impossible to crack the password in reasonable time, I resorted to a new strategy: If we cannot crack the firmware update, why don’t we write a new unencrypted one?

It turns out that this is indeed possible! After some experimentation I found the minimal requirements for a BIP2 firmware upgrade:

  • /info.txt    Holds information which is displayed on firmware update
  • /  Shell script which is invoked on uploading the firmware and upgrade. The output of the script is printed on the web page.
  • Some padding file which inflates the zip file size since the firmware upgrade web interface will complain if the file is too small.

Enable SSH via firmware update

This allows us to execute any command as root user. So after some experimentation I used this way to enable the Dropbear SSH client on camera. The required steps are:

  1. Resetting the root password to a known value to allow remote logins
  2. Enable dropbear in /etc/default/dropbear
  3. Start dropbear service
Unfortunately it is not trivial to reset the root password since the passwd command reads from stdin, so there is no simple way to replace the password. For now, I’ve chosen the simplest way: Replacing /etc/passwd  with a new file with known password.
If we incorporate all theses steps, looks like the following:
echo "This is a hacked script to enable Dropbear SSH"
echo "Arguments given to are:"
for ARG in $*
    echo $ARG
if . "/etc/bip.model"; then
    echo "Failed to read environment"
    exit 1

# Reject non-root callers
if [ `id -u` != "0" -o `id -g` != "0" ]; then
    echo "Script must be called by root:root\n"
    exit 1

# Save zip file name
[ -n "$2" ] && FWFILENAME="$2"

# Print out current ZIP file password
echo Firmware password: `cat /etc/fw_pwd`

echo "Old passwd content was:"
cat /etc/passwd

echo "Set root password to 'pass' by copying new password file..."
unzip -P "$FWP" -qo "$FWFILENAME" ""
cp /etc/passwd

echo "New passwd content is:"
cat /etc/passwd

echo "Activate SSH in config file..."
echo "NO_START=0" > /etc/default/dropbear

echo "Run dropbear SSH server..."
/etc/init.d/dropbear stop
/etc/init.d/dropbear start

echo "Reenable camera application"
camera start

echo "Finished update script, close this window and reconnect to your camera now."

Generated firmware for SSH access

An example firmware can be found here.

Note that all changes made from this script are temporary because the root file system is mounted in RAM. So the camera goes back to normal after one power cycle.

Now you can ssh into your camera and play with it via

ssh root@
The authenticity of host ' (' can't be established.
RSA key fingerprint is 88:24:f0:60:a6:a8:5c:a0:b6:5a:98:03:66:d4:63:3c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
root@'s password: pass

BusyBox v1.17.3 (2010-11-15 09:01:13 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.


Now go forth and play with your new camera. You mostly don’t have to fear to corrupt anything because the root file system is loaded from NAND to RAM during bootup.

root@Geutebrueck-xxxxxxx:~# cat /proc/cpuinfo
Processor       : ARM926EJ-S rev 5 (v5l)
BogoMIPS        : 215.44
Features        : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 5

Hardware        : DaVinci DM368 BIP
Revision        : 0000
Serial          : 0000000000000000