Flashing your own firmware

There are two ways to create new livebox firmware

First, a little about the layout of the memory partitions. The RedBoot loader is firmware that gets the linux operating system up and running. This handles the USB/TFTP flashing of the .DWB file what we know as the “firmware”. When actually there are TWO lots involved. Messing up the RedBoot partition will brick your device and requires a JTAG to recover.

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "RedBoot"
mtd1: 00720000 00010000 "user_fs"
mtd2: 000a0000 00010000 "jffs_system"
mtd3: 0000f000 00010000 "FIS directory"
mtd4: 00001000 00010000 "RedBoot config"
#

Decrypting software from AndyP

Breaking open and mounting the firmware

brett@gumby:~/livebox/firmware$ ./dwbdecrypt firmware_5_04_3-uk.dwb
./dwbdecrypt, V1.10 Program to decode Inventel Livebox (DV-4210) Recovery DWB Files. (c) 2008 Andy Potter
File to Decode                => firmware_5_04_3-uk.dwb
Encrypted Script File         => firmware_5_04_3-uk.dwb.script.encrypted
Decrypted Script File         => firmware_5_04_3-uk.dwb.script.decrypted
Decrypted ASCII Script        => firmware_5_04_3-uk.dwb.script.ascii
Encrypted CRAMFS File         => firmware_5_04_3-uk.dwb.cramfs.encrypted
Decrypted CRAMFS File         => firmware_5_04_3-uk.dwb.cramfs.decrypted
Encrypted SQSHFS File         => firmware_5_04_3-uk.dwb.sqshfs.encrypted
Decrypted SQSHFS File(s)      => firmware_5_04_3-uk.dwb.sqshfs.decrypted
Encrypted Tail File           => firmware_5_04_3-uk.dwb.tail.encrypted
Decrypted Tail File           => firmware_5_04_3-uk.dwb.tail.decrypted
Decrypted Tail Code File      => firmware_5_04_3-uk.dwb.tail.code
Crypt Key File to Write       => firmware_5_04_3-uk.dwb.cryptkey
CSUM file to Write            => firmware_5_04_3-uk.dwb.csum
Crypt Key Length File         => firmware_5_04_3-uk.dwb.cryptkey.length
 
Source File Size              => 0x00501038 5247032 bytes
Script File Data Offset       => 0x00000000 0
CRAMFS/SQSHFS Data Offset     => 0x00001000 4096
Tail Data Starts at           => 0x00500000 5242880
CryptKey Data Starts at       => 0x00501000 5246976
CryptKey Length               => 0x00000030 48 bytes
CryptKey                      => 940003020014A70B9A14858DB83BF11C6633BCA0B26A7555EB5200149F471BA3CE5A0EDE45882FB60BF016186D951ED3
CSUM ??                       => 1885DAAB
Writing firmware_5_04_3-uk.dwb.script.encrypted, Please wait.
Writing firmware_5_04_3-uk.dwb.script.decrypted, Please wait.
Writing firmware_5_04_3-uk.dwb.cramfs.encrypted, Please wait.
Writing firmware_5_04_3-uk.dwb.cramfs.decrypted, Please wait.
Writing firmware_5_04_3-uk.dwb.tail.encrypted, Please wait
Writing firmware_5_04_3-uk.dwb.tail.decrypted. Please wait.
brett@gumby:~/livebox/firmware$ mkdir loop
brett@gumby:~/livebox/firmware$ sudo mount -o loop firmware_5_04_3-uk.dwb.cramfs.decrypted loop
brett@gumby:~/livebox/firmware$ ls -F loop
bin/            etc@        home@        lib/      proc/        sbin/       usr/
dev/            etc_ro_fs/  home_ro_fs/  linuxrc@  root@        tmp@        var/
dev_update.sh*  flasher@    Image*       mnt/      root_ro_fs/  tmp_ro_fs/  webs/
brett@gumby:~/livebox/firmware$

The dwbtool project from DarkFader was supplied with a Windows binary and object libraries. As the cramfs should be manipulated on Linux it's annoying to have to flip back and forward between these two operating system.

DarkFader did not supply libtomcrypt or libtommath in source form. This has been added to the distribution along with a Makefile to simplify the building process on a Linux box.

Download and compile dwbtool.tgz copy the compiled dbwtool binary into your firmware modification area.

To simplify the process of pulling apart and rebuilding a DWB file, we've constructed a small Makefile. Adjust with the firmware version that you have:

FIRMWARE=firmware_5_04_3-uk

all:
      @echo "Targets are extract, build & clean"

extract:
      ./dwbtool -x $(FIRMWARE).dwb $(FIRMWARE).script $(FIRMWARE).cramfs
      # mknod fails if your not root
      sudo rm -rf $(FIRMWARE)-mod
      sudo cramfsck -x $(FIRMWARE)-mod $(FIRMWARE).cramfs

build:
      mkcramfs $(FIRMWARE)-mod $(FIRMWARE)-mod.cramfs
      cramfsck $(FIRMWARE)-mod.cramfs
      ./dwbtool -c $(FIRMWARE)-mod.dwb $(FIRMWARE).script $(FIRMWARE)-mod.cramfs
      ./dwbtool -v $(FIRMWARE)-mod.dwb

clean:
      sudo rm -rf $(FIRMWARE)-mod
      rm -f $(FIRMWARE)-mod.* $(FIRMWARE).cramfs $(FIRMWARE).script mykey

Your firmware build directory will look like this:

$ ls -l
-rwxr-xr-x 1 brett brett  185348 2008-09-18 00:29 dwbtool
-rw-r--r-- 1 brett brett 5247032 2008-09-16 21:11 firmware_5_04_3-uk.dwb
-rw-r--r-- 1 brett brett     580 2008-09-18 01:29 Makefile
$

To use

$ make extract
./dwbtool -x firmware_5_04_3-uk.dwb firmware_5_04_3-uk.script firmware_5_04_3-uk.cramfs
dwbtool v1.01 by Rafael Vuijk (aka DarkFader)
# mknod fails if your not root
sudo rm -rf firmware_5_04_3-uk-mod
sudo cramfsck -x firmware_5_04_3-uk-mod firmware_5_04_3-uk.cramfs
$

Modify whatever file in the $(FIRMWARE)-mod directory you like, in our case this is firmware_5_04_3-uk-mod

brett@gumby:~/livebox/firmware$ ls -l
total 10476
-rwxr-xr-x  1 brett brett  185348 2008-09-18 00:29 dwbtool
-rw-r--r--  1 brett brett 5238784 2008-09-18 01:31 firmware_5_04_3-uk.cramfs
-rw-r--r--  1 brett brett 5247032 2008-09-16 21:11 firmware_5_04_3-uk.dwb
drwxr-xr-x 15 root  root     4096 2008-09-18 01:31 firmware_5_04_3-uk-mod
-rw-r--r--  1 brett brett     339 2008-09-18 01:31 firmware_5_04_3-uk.script
-rw-r--r--  1 brett brett     580 2008-09-18 01:29 Makefile

After you've put whatever you want into the -mod directory build a new .DWB image.

$ make build
mkcramfs firmware_5_04_3-uk-mod firmware_5_04_3-uk-mod.cramfs
Directory data: 16296 bytes
Everything: 5108 kilobytes
Super block: 76 bytes
CRC: 211ccb4e
cramfsck firmware_5_04_3-uk-mod.cramfs
./dwbtool -c firmware_5_04_3-uk-mod.dwb firmware_5_04_3-uk.script firmware_5_04_3-uk-mod.cramfs
dwbtool v1.01 by Rafael Vuijk (aka DarkFader)
Generated key written to file 'mykey'.
./dwbtool -v firmware_5_04_3-uk-mod.dwb
dwbtool v1.01 by Rafael Vuijk (aka DarkFader)
Verification successful.
$

Unfortunately pushing this into the TFTP area and setting up the appropriate link doesn't work.

The RedBoot needs to be reflashed to tell it not to verify the CRYPTO.
see Replacing the RedBoot loader

Importing a new CRAMFS

# /etc/init.d/ramdisk start
Ramdisk initialisation ...
# cd /mnt/ramdisk/rd1
# wget ftp://192.168.1.12/firmware_5_04_3-uk-mod.cramfs
--00:02:09--  ftp://192.168.1.12/firmware_5_04_3-uk-mod.cramfs
           => `firmware_5_04_3-uk-mod.cramfs'
Connecting to 192.168.1.12:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD not needed.
==> PORT ... done.    ==> RETR firmware_5_04_3-uk-mod.cramfs ... done.
Length: 5,234,688 (unauthoritative)

100%[====================================>] 5,234,688      2.50M/s

00:02:11 (2.49 MB/s) - `firmware_5_04_3-uk-mod.cramfs' saved [5234688]

# ls -l
-rw-r--r--    1 0        0         5234688 Jan  1 00:02 firmware_5_04_3-uk-mod.cramfs
drwxr-xr-x    2 0        0               0 Jan  1 00:01 lost+found
# fcp -v firmware_5_04_3-uk-mod.cramfs /dev/mtd1
Erasing blocks: 80/80 (100%)
Writing data: 5112k/5112k (100%)
Verifying data: 5112k/5112k (100%)
#

RedBoot> fis load -b 0x80010000 -m cramfs -f Image user_fs
Partition is : 0xbe430000 - 0x720000
Pas de magic partition finish ...
mlen : 0x442030
begin_tag : 0xbe872000, end : 0xbe872030
 verif KO
 rescue_part_str not set
Run again with img->name = "<Not a string: 0x80FF0500>"Partition is : 0xffffffff - 0xffffffff
66666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666

Looking at the flash.c inventel source code we see that “verif KO” mean the encryption verification failed.

    if (! crypt_verify ((unsigned char *) base, begin_tag - base , (unsigned char * ) begin_tag + 4, siglen,0)) {
      /* OK */
      debug_diag_printf("Verif OK \n");
    } else {
      debug_diag_printf(" verif KO \n ");

This means that we will have to replace the RedBoot loader if we want to be able to TFTP new firmware over to the box, as per DarkFaders patch.

Using a patched version of the RedBoot loader that does not do the crypto check we can get around the issue that we had before.

To replace your RedBoot loader, get the file from above onto your PC. Ungzip it.

HOST LINUX SYSTEM
# ungzip redboot_blueg5.6-patched.gz

If you are using a Windows system you can use http://www.7-zip.org/ which will also uncompress this file.

Now use FTP on the Livebox to pull the unzipped file into /tmp

LIVEBOX SYSTEM
# cd /tmp
# wget ftp://<HOST SERVER>/redboot_blueg5.6-patched

You can also use HTTP if you have a web server running instead where this file is hosted. http://filezilla-project.org/ is a useful Windows based FTP server.

Next, run the command shown below on your Livebox. MAKE SURE THIS IS THE UNCOMPRESSED FILE.

Double / Triple check what you're about to do next. If this goes wrong your Livebox will be bricked and you will need JTAG to recover. Details of pins on http://darkfader.net/livebox/

LIVEBOX SYSTEM
# fcp -v redboot_blueg5.6-patched /dev/mtd0

This allows a tftp_server_for_image_downloads of a .DWB modified image (that was generated using the dwbtool earlier) to flash, verify and execute successfully. You can also use the Windows tool to do the same job

Migrating to the HAH firmware?

Now you have done this you can proceed to replace the inventel 5.04 firmware with the HAH firmware.
Head back to firmware for instructions, you are now on step 4.

Reading Redboot config

Memory block /dev/mtd4 contain values stored in FLASH memory away from the destructive overwrite process of firmware upgrades.

We can use a utility called fconfig to get at this area:

Do not use the write mode. You will mess up your Livebox Config

Compiling up fconfig will allow you to see inside the redboot configuration partition.

# ./fconfig
Low verbosity messages are printed.
Read, write or list Redboot configuration
usage: fconfig [-r|-w|-l] -d dev -o offset -n nickname -x value
'dev' may be a char device, block device or a file
'offset' is the offset in bytes on the device
Supported types:
 - empty
 - bool
 - int
 - string
 - script
 - ip
 - esa
 - netport
Additional switches:
 -v:    Verbose mode, use more to increase verbosity
 -s:    Silent mode, absolutely no messages printed
#

So what parameters exist to be read and/or modified ?

# ./fconfig -l -d /dev/mtd4
Low verbosity messages are printed.
boot_script: TRUE
boot_script_data: fis load -b 0x80010000 -m cramfs -f Image user_fs
exec -c "boot_loader=RedBoot root=1F01 mem=16M" 0x80010000

boot_script_timeout: 20
bootp: FALSE
bootp_my_ip: 0.0.0.0
bootp_server_ip: 0.0.0.0
bt_pin: FALSE
bt_pin_data: 0000
eth0_esa: FALSE
eth0_esa_data: 30:78:30:30:3a:30
gdb_port: 9000
h235_key: FALSE
h235_key_data: 1234567812345678
info_console_force: FALSE
info_console_number: 0
inventel_wireless_magic: -1
net_debug: FALSE
serial_number: FALSE
serial_number_data: 0000000000000000
wep_key: FALSE
wep_key_data: FFFFFFFFFFFFFFFFFFFFFFFFFF
#

Here's how you would use the command to read the boot script timeout in (ms) millisecond.

fconfig -r -d /dev/mtd4 -n boot_script_timeout