Monthly Archives: November 2011

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
3.5.0
 Length   Method     Date    Time   Name
--------  ------  ---------- -----  ----
     260  Defl:X  2011-10-24 17:19  compcheck.sh
       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/bf.sh
  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  update.sh
--------                            -------
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
  • /update.sh  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, update.sh looks like the following:
#!/bin/sh
echo "This is a hacked update.sh script to enable Dropbear SSH"
echo
echo
echo "Arguments given to update.sh are:"
for ARG in $*
do
    echo $ARG
done
if . "/etc/bip.model"; then
    :
else
    echo "Failed to read environment"
    exit 1
fi

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

# 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" "passwd.new"
cp passwd.new /etc/passwd

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

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@172.16.0.180
The authenticity of host '172.16.0.180 (172.16.0.180)' 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 '172.16.0.180' (RSA) to the list of known hosts.
root@172.16.0.180'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.

root@Geutebrueck-xxxxxx:~#

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

 

Investigating the Basler BIP2-1600c (updated)

Marketing verbiage

I have long been looking for the optimal IP camera, not only from picture quality but also from an engineering point of view. BOSCH IP camera such as the NBN-921 have great dynamics but suffer under a lot of Software problem, such as garbled H.263 encoding under high bitrates as well as hardware problems with high heat dissipation. Where as most AXIS camera have adequate firmwares, but abysmal sensor performance.

But fear not for there is a new player on the IP camera market: Basler. Basler is already a big player on the ComputerVision market and extended its product range for security applications.

Now I have made quite extensive research in my demo BIP2-1600c which is branded by Geutebrück as TopBC-1188.

My requirements

Most IP cameras are intended to be used for surveillance of public places with mostly static images and no real-time dependence. But of cause there are countless other applications where good IP cameras are needed — in my case it is outdoor optical character recognition on fast moving objects. Now this requires several unique features:

  • Absolute time synchronization in the millisecond regime for each frame
  • Good dynamic and fast adaptation to lighting conditions
  • Low noise sensor
  • External trigger for picture synchronization
  • High resolution
  • MJPEG stream with at least 10 fps for high-quality (>90) JPEGs

Most of these features cannot be found on typical IP cameras, so I was rather curious who Basler IP cameras handle these demands.

Investigation

Web interface

Basler Webinterface
Basler Webinterface – Stream configuration

The web interface is clean and structured and allows to configure all settings one is used to. Noteworthy exceptions:

  • There is no support for IPv6! Shame on you Basler.
  • Set Area of Interest (AOI) which allows for partial reading of the sensor
  • It is possible to change all settings via a simple HTTP-POST RPC interface – there is no XML-RPC
  • Can sustain one 12.5FPS high-quality JPEG stream at 19Mb/s
  • Each JPEG frame includes EXIF data holding
    •  I/O state infos
    • UNIX timestamp in microseconds!
    • Frame id

Hardware

The BIP2-1600c is a very small and light camera in a nice aluminium casing. Even under load, the camera only warms up slightly. The PCB design is beautiful, featuring a DaVinci DM368 (ARMv5TEJ) from Texas Instruments. The Sensor is interfaces to an Altera  Cyclone FPGA.

Trigger input

The hardware features a trigger input which allows to precisely time each frame which is guaranteed to be taken after up to 7 ms delay.

Real time trigger input and time synchronization

I thoroughly inspected the real time trigger input and time synchronization features of the BIP2-1600c camera. To test the trigger time delay, I used my Olimex STM32P107 which was generating an NTP synchronized second pulse. The pulse was connected to the trigger input of the camera which was itself also NTP synchronized to my host computer which displayed timestamp information on its display.

Using the above setup, the camera was always synchronized to within 8ms but showing a constant 90 ms offset in the JPEG timestamp which still exceeds my greatest expectations.

<update> I inquired about this problem with Basler Tech Support. They basically told me that the timestamp value also includes the exposure time and the sensor reading duration plus some jitter.

Now, instead of correcting for this time duration afterwards wouldn’t it be wiser to subtract the time difference inside the camera? Especially given that different models have different sensors.</update>

Licences

There is one small thing constantly bugging me with the camera though – licences. This camera uses Linux and a great deal of other GPL licensed software. Under the GPL you are required to supply the source code of the software on user demand as well as to notify the user about the GPL software.

Unfortunately, there is no source code downloadable from neither Basler nor Geutebrück. The only information regarding this issue is a small link to the license texts (but not code) on the web interface of the camera, but not in the user manual.

I have requested Basler to provide me with parts of the source code — especially the Linux and u-boot source code. Let’s see how they will respond.

Conclusion

The Basler BIP2-1600c is a great camera with potent hard- and software which has even more potential once the software matures further. I highly recommend looking at this camera.

Outlook

In the next post I will look into hacking this camera and gain root access, so stay tuned.