reflashing the BT home hub from a linux PC

I mentioned in an earlier post that the home hub hacks site suggested that it might be possible to reflash the BT HH with a genuine Thomson image. That information looked useful because it would mean that the HH could then be unlocked from BT’s network and used on any other ISP’s network. It would also give more functionality to the HH – dynamic DNS for example.

I spent some time over the recent christmas break exploring the references on the home hub hack site and its primary source, a forum on thescream dedicated to hacking the HH. There are several threads on the latter forum and it currently (as at late December 2007) runs to some 850 or more posts over 57 pages, so it takes some reading, but hey, this is research. I then spent some more idle time playing with a variety of the images gleaned from the sources suggested. The bottom line is that I found that it is possible to successfully reflash the HH (running BT’s version 6.11M firmware image) with one of two (modified) 7G images (ZZN1AA6.196.bli and ZZMYAA6.196.bli) only the first of which proved really useful. Since I had some difficulty sourcing the required images – several referenced sites have disappeared or are now password protected ( is good example which is referenced from several sites) – I have placed a gzipped tar archive copy of the v ZZN1AA6.196 image here in both original and unmodified form should you choose to use it. Note however, that in so doing you will be using an image which comes from a completely untrusted source (me) which I have stated is modified, and which may have been modified before I even got my hands on it – so you have been warned.

You may prefer to source an original Thomson image and then experiment for yourself. If so, try the following sites: – but of course you don’t know where he got his images…. – nor where they got theirs. – a fantastic resource from “m8s, ikitty & chick”, but again not an official Thomson site.

Fully trusted images from approved Thomson sites proved to be difficult to find. Thomson does not seem to provide much support directly to the public, preferring to leave partner sites around the world to provide documentation, support and software. I found the Thomson partner sites below of most use: – provides a range of images for various Thomson routers
– these guys provide a good range of both software and documentation. I have used them for details about the ST780WL. Unfortunately, it looks as if you now have to register as a Thomson Partner in order to gain access to the site. – the site is in dutch, but the referenced documentation (which is extensive) is available in english.

and of course the UK based site – provides firmware images and documentation. Just don’t expect much information about earlier hardware such as the 7G.

Wherever you choose to source your image, I am assuming that you will be flashing the hub from a linux box rather than from windows, otherwise you wouldn’t be here. All the other sites discussing the HH seem to assume (not unreasonably) that the reader uses a windows based PC and will thus be able to use windows reflashing tools provided. I don’t and can’t, but no matter – the hub just uses BOOTP to ask for a new image and it is simple to set that up. I used the following approach:

1. Install bootp (or dhcp – your choice) and tftpd from your distro’s repository. I used tfptd-hpa, but there are plenty of other options.

2. Create a local tftpd root directory to hold the files. You will start the tftpd daemon later to run in a chrooted environment with this directory as the root. I chose to use /usr/local/tftpboot.

3. Set the ownership and permissions on that directory to allow the tftpd daemon access. tftp is an insecure protocol which does not require authentication before providing access. Even though you will be running this daemon only for a short while, and only for the specific purpose of flashing a new image to the hub and you will not (or should not) be exposing your linux install to a wider network, it is still good practice to minimise the level of privilege needed. Ideally the tftpd daemon should be run as a completely separate user created solely for that purpose, but it defaults to “nobody”. This may be acceptable in this case.

4. Copy the image file to that directory, rename it BANT-Z, and set the permissions as readable by the tftpd dameon.

5. Create/edit the bootp server database /etc/bootptab as follows:
# /etc/bootptab

# end

This says: set the default tftpd root directory (td) as /usr/local/tftpboot, the boot file home directory (hd) within that directory as the root and the bootfile to supply to the requesting devise as BANT-Z (since this is the name of the file that the hub actually requests). The second line starts with the name of the requesting device (hub) which must map to the correct IP address of the hub. This means that you must have an entry in your local hosts file (/etc/hosts or equivalent) which maps the name “hub” to the default IP address of that hub ( unless you have changed it). The rest of that line specifies the hardware type (ht) as 1 (ethernet), the hardware address (ha) as the 12 digit hex MAC address of your hub (printed on the back in the form “MAC 00147fa55611” or something similar, and the rest as for the default. Note that the bootptab file can have multiple entries for different images for a range of requesting devices, but in this case we have only specified one – the hub.

6. Ensure that you have connected your linux PC to the hub via an ethernet cable and that your PC has a fixed IP address within the same network address range as the one given to the hub. If the hub has the default BT given address, then any fixed address from to will do. The netmask will need to be set to Check connectivity by pinging the hub before starting.

7. Open a terminal session on your PC and start the bootpd daemon as “bootpd” and the tftpd daemon as “in.tftpd -u “username” -l -s /usr/local/tftpboot“. You can leave out the -u username argument if you have opted to run the daemon as default nobody. The -l argument tells the daemon to run in stand-alone mode, the -s argument specifies the chroot directory you have chosen. Check that they are running properly before you go any further.

8. If you have telnet access to the hub (useful) then connect as admin and type “software upgrade” and wait while the hub requests the new image and installs it. This may take a few minutes. If you do not have telnet access then simply press and hold the grey “wireless association” button on the rear of the hub for about 15-20 seconds and the hub will reboot into a mode which starts with a BOOTP request.

9. If you manage to brick your hub, don’t panic. Simply retry the reboot option by again pressing and holding the grey button on the rear of the hub until it again requests a new image. It can be very useful to have open a wireshark/ethereal session capturing traffic whilst you are rebooting the hub. This will allow you to watch what the hub is actually asking for and how you are replying. Bear in mind that you can source HHs from ebay for around a tenner each so if you are at all concerned about bricking your one working router, buy another – hell, buy two or three, nobody really wants them.

The one big drawback with the reflashed hub is that VOIP does not appear to work properly. I use sipgate, and whilst the newly flashed hub registers correctly, I have not yet found a way to make the VOIP system work. If it is simply a case of an incorrect dialplan then I may be able to fix this later, but from comments elsewhere, particularly on thescream, I suspect that the hardware on the board may be sufficiently different to a genuine 7g to cause problems. Whatever, if you simply want a cheap ADSL router, useable on any ISP’s network (or simply as a backup to your existing router) then reflashing a hub is one way forward.

The reflashed BT hub now looks like this (not connected to the phone line, so the DSL is shown as down)

the hub as a 7G router


NOTE. I recommend that you kill both the tfptd and bootpd daemons before reconnecting your PC to a live network. You may also care to consider the cross site scripting vulnerabilities pointed out at Any unpatched hub using old versions of firmware may be vulnerable to the sort of social engineering attacks documented on that site. If you voluntarily choose to expose your router to the net and purposely lock out BT’s capability to upgrade your firmware then you are taking a risk. Personally, I prefer to manage my own risks and to lock out remote administration completely.

Your choice.

Permanent link to this article: