Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[asbokid]

Hi SecTSys!

Welcome to Kitz!

..With regards to the USB slot.

The router has got a boot sector, and a USB Port. - I saw the post with the html page that looks a promising thing... has anyone tried booting with reset pressed whilst having a bootable USB Stick with the software to flash the BT HH 3.0b already on it, using and attempting all various and prior mention button combos possible.

It's a good idea. What is "the software" though? It's quite possible that the kernel driver will try to auto-mount a USB drive, and perhaps execute a certain binary file on the drive, if the file is found. To pursue this avenue would involve running those processes in a system trace utility to see what file(s) they are looking for.  May be a dead-end avenue though..

Also, maybe there's an exploit in the Samba/SMB implementation of the HH3.0b, which the PsiDOC team found with the other models of Home Hubs.

Something else that i have seen done before though that was at a convention i attended... is to create a virtual infrastructure that can possibly fool the HH3 into believing that it is connected to the internet - discovering the IP address that the router trys to connect to when looking for a connection to update its firmware. then mimicking that - with instruction to to flash the firmware with software that you want (that is compatible and not going to brick it) essentially getting the BTagent in the router to give up it's secrets somehow.

the key with this would be to grab the info as it leaves the router and before it gets to the openreach modem whilst capturing the data - maybe that could reveal something.

That's definitely do-able.   There seem to be two methods for remote access to the firmware of these devices - and not just the HH3.0b. There is a periodic 'CPE phone home' method, and then there is a remotely-initiated network connection to the device.  There's probably some blur between the two. Maybe the same CPE binaries found in the firmware serve in both roles, Either way, there is very limited documentation.  Burakkucat has, however, discovered some function prototypes for btagent in a GPL code release for the Arcadyan firmware of a hitherto un-released Openreach VDSL2 modem. That would make a good starting point for discovering how btagent actually works.

I know that this is pretty old school - but what about older methods of revealing things such as "lsof"   you probably know all this stuff but i went back over some of the old school techniques, using something like "netstat -tupac" running in realtime whilst having your connection between the homehub and the modem might reveal some open ports or even connections that the router attempts to make and what ports and such are being used to do it with and even more so at what point in the process does the router open these ports in order to try and obtain this information.

I am certain that if any unlocking of software is to be done - it will be through the USB - or from an external source. and the access to ports and other fun things will otherwise be closed off to the internal Ethernet network.

An interesting package full of Chinese electro-trickery just arrived.  It includes some TSOP48 flash memory cradles that I plan to install to the PCB of the BT HH3.0b (and other devices).  The cradle could allow arbitrary changes to be made to the flash memory, using a separate programmer.  Perhaps the difficulty here is that the root file system of the HH3.0b seems to have a digital signature - a signature which is verified by the bootloader (and maybe the kernel) - and that signature is there to prevent file system modification.

The signature verification mechanism could either be disabled in the bootloader, or a faked signature could be generated for the modified file system (to cause a hash collision).  Both potentially very difficult things to do though.

This seems to be a new trend - the use of digital signatures for embedded firmware of DSL CPE.  Whereas, previously, security-through-obscurity techniques were used, e.g. the use of trivial tweaks to the file system compression algorithm,  to foil end-user modifications.

cheers, a

[asbokid]

Emulating the update infrastructure wouldn't work as BTAgent uses public key encryption and we only have access to the device key(s).

Maybe we could generate our own keypair and drop the public key into place in the firmware, overwriting the Beatie one     Incidentally, BT has used the same crypto keypair in multiple products over some years now. Which means that literally millions of devices are secured by an identical key. Here's hoping that BT is keeping that private key in a well-secured vault! 

I did briefly consider 'recording' the update process using Honeywall to grab the update file but it's rather impractical as I've no way of predicting when BTAgent would actually do an update check and decrypting the data stream might prove rather complicated.

At the moment I'm looking into system emulation. It might be possible to determine what we need by actually getting the bootloader/cfe running in an emulator.

First I have to find a suitable emulator of course and there are so bloody many to chose from 

I was looking at QEMU but it doesn't really seem suited to emulating embedded systems and would probably require more patching that I'm capable of. Particularly as I'm not familiar with it's internal architecture.

However I've just gotten access to OVP this morning - the one listed on the MIPS Technologies website - which looks promising going by the website blurb.

But I'm sure we're all far too familiar with difference between marketing nonsense and reality 

A suitable MIPS32 Linux kernel has now been built using buildroot for QEMU. The file system of the HH3.0b is mounting okay as the root file system of that MIPS system running in emulation on a PC.  The  process can be documented for others interested.    Lots of problems yet to solve before the emulated system is very useable. Some of those problems are quite complex. e.g.  The Home Hub's userspace code is trying to read various bits of config data - including the username and password for the login shell - from a special area of the flash memory.  In emulation where flash memory isn't there, that read() isn't going to work.     It's possible, in theory for QEMU to intercept those system calls to read the flash.   However, if the QEMU docs are up-to-date, the low-level glueware for those reads is working for ARM platforms but not MIPS, apparently.   Also, there are six or seven kernel modules in the Broadcom builds for which there is no public source code.  So the xTM/xDSL driver layers are never going to work in emulation (no doubt much to Broadcom's relief!)

Getting the Home Hub's network daemons up and running in QEMU on a PC would be a good basis for moving the hack along. strace, the system call tracer could be attached to those server processes to see what's going on under-the-hood.

cheers, a

[Howlingwolf]

Maybe we could generate our own keypair and drop the public key into place in the firmware, overwriting the Beatie one 

Surely that would only work if we already have access?

Incidentally, BT has used the same crypto keypair in multiple products over some years now. Which means that literally millions of devices are secured by an identical key. Here's hoping that BT is keeping that private key in a well-secured vault!

The one thing they are good at is keeping secrets. I'll certainly give them that 

A suitable MIPS32 Linux kernel has now been built using buildroot for QEMU. The file system of the HH3.0b is mounting okay as the root file system of that MIPS system running in emulation on a PC.  The  process can be documented for others interested.    Lots of problems yet to solve before the emulated system is very useable. Some of those problems are quite complex. e.g.  The Home Hub's userspace code is trying to read various bits of config data - including the username and password for the login shell - from a special area of the flash memory.  In emulation where flash memory isn't there, that read() isn't going work.     It's possible, in theory for QEMU to intercept those system calls to read the flash.   However, if the QEMU docs are up-to-date, the low-level glueware fo those reads is working for ARM platforms but not MIPS, apparently.   Also, there are six or seven kernel modules in the Broadcom builds for which there is no source code.  So the xTM/xDSL driver layers are never going to work in emulation (no doubt much to Broadcom's relief!)

Getting the Home Hub's network daemons up and running in QEMU on a PC would be a good basis for moving the hack along. strace, the system call tracer could be attached to those server processes to see what's going on under-the-hood.

cheers, a

I'm planning a slight different approach. Start off with a minimal emulation platform with just the processor, ram and flash memory - using the flash dump kindly supplied by your good self

Log all the I/O attempts and then start adding whatever emulated peripherals I can until I get it running. It'll probably take a while but you never know, We might get lucky and identify the update process trigger from the I/O log.


One thing which did make me smile. I was reading through the OVP docs and it all seemed strangely familiar...

Then it suddenly struck me. The way their platform framework is put together is very similar to the methodology Peter Graham and I developed for emulating 8bit processors back in the early 80s 

Their's is rather more sophisticated of course... 

[SecTSys]

The one thing they are good at is keeping secrets. I'll certainly give them that 

Agreed... but if there is a secret then it must be shared, - otherwise it's just plain rude!!!

    A suitable MIPS32 Linux kernel has now been built using buildroot for QEMU. The file system of the HH3.0b is mounting okay as the root file system of that MIPS system running in emulation on a PC.  The  process can be documented for others interested.    Lots of problems yet to solve before the emulated system is very useable. Some of those problems are quite complex. e.g.  The Home Hub's userspace code is trying to read various bits of config data - including the username and password for the login shell - from a special area of the flash memory.  In emulation where flash memory isn't there, that read() isn't going work.     It's possible, in theory for QEMU to intercept those system calls to read the flash.   However, if the QEMU docs are up-to-date, the low-level glueware fo those reads is working for ARM platforms but not MIPS, apparently.   Also, there are six or seven kernel modules in the Broadcom builds for which there is no source code.  So the xTM/xDSL driver layers are never going to work in emulation (no doubt much to Broadcom's relief!)

    Getting the Home Hub's network daemons up and running in QEMU on a PC would be a good basis for moving the hack along. strace, the system call tracer could be attached to those server processes to see what's going on under-the-hood.

    cheers, a

I'm planning a slight different approach. Start off with a minimal emulation platform with just the processor, ram and flash memory - using the flash dump kindly supplied by your good self

Log all the I/O attempts and then start adding whatever emulated peripherals I can until I get it running. It'll probably take a while but you never know, We might get lucky and identify the update process trigger from the I/O log.

both methods would in appearance be worth testing. good luck...

[asbokid]

Maybe we could generate our own keypair and drop the public key into place in the firmware, overwriting the Beatie one 

Surely that would only work if we already have access?

The same BTAgent software is found in binary form in most CPE from BT. Those binaries/closed source libraries can be run in a MIPS emulator.

I'm planning a slight different approach. Start off with a minimal emulation platform with just the processor, ram and flash memory - using the flash dump kindly supplied by your good self

Log all the I/O attempts and then start adding whatever emulated peripherals I can until I get it running. It'll probably take a while but you never know, We might get lucky and identify the update process trigger from the I/O log.

Good luck! You're on your own with that one!

One thing which did make me smile. I was reading through the OVP docs and it all seemed strangely familiar...

Then it suddenly struck me. The way their platform framework is put together is very similar to the methodology Peter Graham and I developed for emulating 8bit processors back in the early 80s 

Their's is rather more sophisticated of course... 

Aha.  If that was the Dr Peter Graham of umanitoba.edu, then he's a proper Unix beardie!  What was the development?

cheers, a

[asbokid]

Hi Guys,

Here's how to build a MIPS32 system that will run in emulation on a PC (a Debian/wheezy Linux install).

The root file system of the BT Home Hub 3.0b is mounted by a Linux kernel built for the MIPS Malta evaluation board.  The Malta board is a $3000 development platform that is supported by QEMU the open-source processor emulator. [1]

MIPS Malta ATX factor evaluation board

Firstly, install QEMU - the processor emulator. See [2]

Code: [Select]

$ apt-get install qemu qemu-user-static
The 32MB NAND flash image for the BT Home Hub 3.0b (f/w revision V100R001C01B031SP09 [2011-06-01] ) can be downloaded from here. [3]

First we extract the jffs2 root file system image from that NAND image

Code: [Select]

$ dd if=hh3.0b.V100R001C01B031SP09_L_B_t2011-06-01_22_39.eccstripped.bin of=hh3.0b_jffs2_be skip=$((0x8000)) count=12173332 bs=1
Convert that bigendian jffs2 image to little-endian bytesex for mounting on an x86 PC:

Code: [Select]

$ jffs2dump --bigendian hh3.0b_jffs2_be --endianconvert=hh3.0b_jffs2_le
Mount the HH3.0b jffs2 root file system at /mnt/hh3.0b_jffs2_le

Code: [Select]

$ modprobe mtdblock
$ modprobe mtdram total_size=300000
$ dd if=./hh3.0b_jffs2_le of=/dev/mtdblock0
$ mkdir /mnt/hh3.0b_jffs2_le
$ mount -t jffs2 /dev/mtdblock0 /mnt/hh3.0b_jffs2_le
Create an empty 100MB file

Code: [Select]

$ dd if=/dev/zero of=hh3.0b.ext2 bs=512 count=$((0x30000))
Make the file into an ext2 image and mount it under /mnt/hh3.0b_ext2

Code: [Select]

$ mke2fs -F hh3.0b.ext2
$ mkdir /mnt/hh3.0b_ext2
$ mount -t ext2 -o loop hh3.0b.ext2 /mnt/hh3.0b_ext2
Copy contents of (little-endian) jffs2 filesystem into our mounted ext2 file system

Code: [Select]

$ cp -ar /mnt/hh3.0b_jffs2_le/* /mnt/hh3.0b_ext2
This is what we've got:

Code: [Select]

$ ls -l /mnt/hh3.0b_ext2/
total 1392
dr-xr-xr-x 2 root 1101    2048 Jun  1  2011 bin
drwxrwxrwx 3 root root    1024 Jun  1  2011 BTAgent
-rw-r--r-- 1 root root  187416 Jun  1  2011 cferam.000
drwxrwx--- 2 root 1102    1024 Jun  1  2011 config
drwxr-xr-x 3 root root    1024 Jun  1  2011 dev
dr-xr-xr-- 8 root 1102    1024 May 31  2011 etc
drwxrwxrwx 5 root root    2048 Jun  1  2011 lib
lrwxrwxrwx 1 root 1101      11 Jun  1  2011 linuxrc -> bin/busybox
drwxr-xr-x 2 root root    1024 Jun  1  2011 mnt
drwxr-xr-x 2 root root    1024 Jun  1  2011 proc
dr-xr-xr-x 2 root 1101    1024 Jun  1  2011 sbin
drwxr-xr-x 2 root root    1024 Jun  1  2011 tmp
dr-xr-xr-x 3 root 1101    1024 Jun  1  2011 usr
drwxrwx--- 2 root 1102    1024 Jun  1  2011 var
-rw-r--r-- 1 root root 1202746 Jun  1  2011 vmlinux.lz
We can disable login authentication by modifying /etc/inittab as follows (viz the respawn line)

Code: [Select]

$ cat /mnt/hh3.0b_ext2/etc/inittab
::sysinit:/etc/init.d/rcS
::respawn:/bin/sh

# tty2::askfirst:-/bin/sh
#::ctrlaltdel:/bin/umount -a -r
Now unmount our ext2 fs image and our jffs2 image

Code: [Select]

$ umount /mnt/hh3.0b_ext2
$ umount /mnt/hh3.0b_jffs2_le
And that is the HH3.0b root file system sorted out, ready for the emulator


Now we can build a MIPS32 Linux kernel that will run in QEMU emulation on the PC
To do that, we will use the buildroot cross-compiler toolchain (latest stable version).  See [4]

Code: [Select]

$ wget http://buildroot.uclibc.org/downloads/buildroot-2012.05.tar.bz2
$ tar jxvf buildroot-2012.05.tar.bz2
$ cd buildroot-2012.05
We will use the default kernel config for the MIPS Malta Development Board (MIPS 32r2|OABI32|BE)
This is just illustrative. We can tweak the kernel build and userspace options properly later:

Code: [Select]

$ cp configs/qemu_mips_malta_defconfig .config
$ make
# [verify and confirm config options]
$ make
(simmer for 20-50 minutes depending on core speed. Zzzz!)

Hopefully, we now have a Linux (3.3.7) kernel built for the Malta board and our root file system (hh3.0b.ext2) for the BT Home Hub 3.0b.

Together, the kernel and the rootfs can be built into a complete MIPS32 system to run in emulation on the PC.

(Lots of tweaking needed - see all the errors about missing (Broadcom) kernel modules, flash partitions, network interfaces, etc.,etc.)

Start QEMU with the following command line options:

Code: [Select]

$ qemu-system-mips -M malta -kernel output/images/vmlinux -nographic -hda hh3.0b.ext2 -append "root=/dev/hda"
And away she goes!:

Code: [Select]

Linux version 3.3.7 (asbo@home) (gcc version 4.5.3 (Buildroot 2012.05) ) #1 SMP Fri Aug 17 03:22:58 BST 2012
Config serial console: console=ttyS0,38400n8r
bootconsole [early0] enabled
CPU revision is: 00019300 (MIPS 24Kc)
FPU revision is: 00000000
Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 000ef000 @ 00001000 (ROM data)
 memory: 003dc000 @ 000f0000 (reserved)
 memory: 07b33000 @ 004cc000 (usable)
Wasting 39296 bytes for tracking 1228 unused pages
Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  Normal   0x00001000 -> 0x00007fff
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000000 -> 0x00007fff
PERCPU: Embedded 7 pages/cpu @81103000 s4672 r8192 d15808 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32511
Kernel command line: root=/dev/hda console=ttyS0,38400n8r
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Primary instruction cache 2kB, VIPT, 2-way, linesize 16 bytes.
Primary data cache 2kB, 2-way, VIPT, no aliases, linesize 16 bytes
Writing ErrCtl register=00000000
Readback ErrCtl register=00000000
Memory: 124988k/126156k available (2871k kernel code, 1168k reserved, 704k data, 196k init, 0k highmem)
Hierarchical RCU implementation.
NR_IRQS:256
CPU frequency 200.00 MHz
Console: colour dummy device 80x25
Calibrating delay loop... 847.05 BogoMIPS (lpj=4235264)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Brought up 1 CPUs
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
vgaarb: loaded
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0x10000000-0x17ffffff]
pci_bus 0000:00: root bus resource [io  0x1000-0x1fffff]
pci 0000:00:0a.3: quirk: [io  0x1100-0x110f] claimed by PIIX4 SMB
vgaarb: device added: PCI:0000:00:12.0,decodes=io+mem,owns=none,locks=none
pci 0000:00:12.0: BAR 0: assigned [mem 0x10000000-0x11ffffff pref]
pci 0000:00:0b.0: BAR 6: assigned [mem 0x12000000-0x1200ffff pref]
pci 0000:00:12.0: BAR 6: assigned [mem 0x12010000-0x1201ffff pref]
pci 0000:00:12.0: BAR 1: assigned [mem 0x12020000-0x12020fff]
pci 0000:00:0a.2: BAR 4: assigned [io  0x1000-0x101f]
pci 0000:00:0b.0: BAR 0: assigned [io  0x1020-0x103f]
pci 0000:00:0b.0: BAR 1: assigned [mem 0x12021000-0x1202101f]
pci 0000:00:0a.1: BAR 4: assigned [io  0x1040-0x104f]
Switching to clocksource MIPS
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 128 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 128 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: Enabling device 0000:00:0a.2 (0000 -> 0001)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 244
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: Enabling device 0000:00:12.0 (0000 -> 0002)
cirrusfb 0000:00:12.0: Cirrus Logic chipset on PCI bus, RAM (4096 kB) at 0x10000000
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Uniform Multi-Platform E-IDE driver
piix 0000:00:0a.1: IDE controller (0x8086:0x7111 rev 0x00)
PCI: Enabling device 0000:00:0a.1 (0000 -> 0001)
piix 0000:00:0a.1: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1040-0x1047
    ide1: BM-DMA at 0x1048-0x104f
hda: QEMU HARDDISK, ATA DISK drive
hda: UDMA/33 mode selected
hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive
hdc: UDMA/33 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
ide-gd driver 1.18
hda: max request size: 512KiB
hda: 196608 sectors (100 MB) w/256KiB Cache, CHS=195/255/63
hda: cache flushes supported
 hda: unknown partition table
ide-cd driver 5.00
ide-cd: hdc: ATAPI 4X DVD-ROM drive, 512kB Cache
cdrom: Uniform CD-ROM driver Revision: 3.20
pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
pcnet32: PCnet/PCI II 79C970A at 0x1020, 52:54:00:12:34:56 assigned IRQ 10
pcnet32: eth0: registered as PCnet/PCI II 79C970A
pcnet32: 1 cards_found
mousedev: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
VFS: Mounted root (ext2 filesystem) readonly on device 3:0.
Freeing prom memory: 956k freed
Freeing unused kernel memory: 196k freed
init started: BusyBox vv1.9.1 (2011-06-01 22:36:10 CST)
starting pid 741, tty '': '/etc/init.d/rcS'
/bin/startbsp: line 22: cannot create /dev/mtdblock2: No such device or address
/bin/startbsp: line 23: cannot create /dev/mtdblock3: No such device or address
/bin/startbsp: line 24: cannot create /dev/mtdblock4: No such device or address
mount: mounting /dev/mtdblock2 on /var/module failed: No such device
mount: mounting /dev/mtdblock3 on /config failed: No such device
mount: mounting /dev/mtdblock4 on /var/middleware failed: No such device
Loading drivers and kernel modules...
insmod: cannot insert '/lib/extra/pktflow.ko': Success
insmod: cannot insert '/lib/extra/bcmfap.ko': Success
insmod: cannot insert '/lib/extra/bcmxtmcfg.ko': Success
insmod: cannot insert '/lib/extra/adsldd.ko': Success
insmod: cannot insert '/lib/extra/bcm_enet.ko': Success
insmod: cannot insert '/lib/extra/wl.ko': Success
insmod: cannot insert '/lib/extra/p8021ag.ko': Success
insmod: cannot insert '/lib/extra/bcmvlan.ko': Success
insmod: cannot insert '/lib/extra/pwrmngtd.ko': Success
insmod: cannot insert '/lib/kernel/drivers/watchdog/bcmdog.ko': Success
insmod: cannot insert '/lib/kernel/drivers/usb/storage/usb-storage.ko': Success
RCS DONE
starting pid 936, tty '': '/bin/sh'

With our kernel booted, we arrive at the familiar (GPL'ed ;- ) BusyBox shell [5]

Version 1.9.1 of BusyBox, apparently:

Code: [Select]

BusyBox vv1.9.1 (2011-06-01 22:36:10 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cat /proc/version
Linux version 3.3.7 (asbo@home) (gcc version 4.5.3 (Buildroot 2012.05) ) #1 SMP Fri Aug 17 03:22:58 BST 2012

# cat /proc/cpuinfo
system type             : MIPS Malta
processor               : 0
cpu model               : MIPS 24Kc V0.0  FPU V0.0
BogoMIPS                : 847.05
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 1, address/irw mask: [0x0ff8]
ASEs implemented        : mips16
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

# ls -l

-rw-r--r--    1 0        0         1202746 vmlinux.lz
drwxrwx---   15 0        1102          340 var
dr-xr-xr-x    3 0        1101         1024 usr
drwxrwx---    2 0        1103           40 tmp
dr-xr-xr-x    2 0        1101         1024 sbin
dr-xr-xr-x   29 0        0               0 proc
drwxrwx---    2 0        1103           40 mnt
lrwxrwxrwx    1 0        1101           11 linuxrc -> bin/busybox
drwxrwxrwx    5 0        0            2048 lib
dr-xr-xr--    8 0        1102         1024 etc
drwxrwxrwt    2 0        0            1820 dev
drwxrwx---    2 0        1102         1024 config
-rw-r--r--    1 0        0          187416 cferam.000
drwxrwxrwx    3 0        0            1024 BTAgent
dr-xr-xr-x    2 0        1101         2048 bin

And here's the Broadcom xdslcmd tool, running in emulation on a PC:

Code: [Select]

# xdslcmd
Usage: xdslcmd start [--up] [--mod <a|d|l|t|2|p|e|m>] [--lpair <(i)nner|(o)uter>]
           [--trellis <on|off>] [--snr <snrQ4>] [--bitswap <on|off>] [--sesdrop <on|off>]
           [--sra <on|off>] [--CoMinMgn <on|off>] [--i24k <on|off>] [--phyReXmt <0xBitMap-UsDs>]
           [--TpsTc <0xBitMap-AvPvAaPa>] [--monitorTone <on|off>]
           [--forceJ43 <on|off>] [--toggleJ43B43 <on|off>]
       xdslcmd stop
       xdslcmd connection [--up] [--down] [--loopback] [--reverb]
           [--medley] [--noretrain] [--L3] [--diagmode] [--L0]
           [--tones] [--normal] [--freezeReverb] [--freezeMedley]
       xdslcmd configure [--mod <a|d|l|t|2|p|e|m>] [--lpair <(i)nner|(o)uter>]
           [--trellis <on|off>] [--snr <snrQ4>] [--bitswap <on|off>] [--sesdrop <on|off>]
           [--sra <on|off>] [--CoMinMgn <on|off>] [--i24k <on|off>] [--phyReXmt <0xBitMap-UsDs>]
           [--TpsTc <0xBitMap-AvPvAaPa>] [--monitorTone <on|off>]
           [--forceJ43 <on|off>] [--toggleJ43B43 <on|off>]
       xdslcmd bert [--start <#seconds>] [--stop] [--show]
       xdslcmd afelb [--time <sec>] [--tones] [--signal <1/2/8>]
       xdslcmd qlnmntr [--time <sec>] [--freq <msec>]
       xdslcmd inm [--start <BB_THRESH 10*dB> <INMIATO> <INMIATS>] [--stop] [--show]
       xdslcmd snrclamp [--shape <shapeId>] [--bpshape [bpIndex-bpLevel,]]
       xdslcmd nlnm [--show ] [--setThld <Thld_Num_Tones>]
       xdslcmd diag [--logstart <nBytes>] [--logpause] [--logstop] [--loguntilbufferfull <nBytes>]
           [--loguntilretrain <nBytes>]
       xdslcmd info [--state] [--show] [--stats] [--SNR] [--QLN] [--Hlog] [--Hlin] [--HlinS] [--Bits]
           [--linediag] [--reset] [--vendor] [--cfg]
       xdslcmd profile [--show] [--save] [--restore]
       xdslcmd --version
       xdslcmd --help
#


In summary: shown above, the file system of the BT Home Hub 3.0b is used as the rootfs for a MIPS32 Linux kernel running in emulation on a PC.

Any collaborators to get it running properly?!

cheers, a

[1] http://www.mips.com/products/development-kits/malta/
[2] http://www.qemu.org/
[3] http://docs.google.com/open?id=0B6wW18mYskvBaDBuSzhqZk13N3M
[4] http://buildroot.uclibc.org/about.html
[5] http://www.busybox.net/

[SecTSys]

If you can get this working and get the router performing to it's peak I am happy to follow instructions, once the whole thing is worked out 

I am Still learning this stuff... :p if i see something though that looks glaringly obvious i will point it out if it's been missed! - does that help in any way?

[Howlingwolf]

Sorry for the delay in replying asbokid.

I got sidetracked writing some tor control scripts in python for someone. Not being a pythonista it took me a few days to get the hang of the language.

It's got some nice high level features but I have to say I'm not a fan of the syntax. Get a space in amongst the indentation tabs and the damn thing chokes. Of course it won't actually tell you why you've got an indentation level error, just the fact that you have one

Maybe we could generate our own keypair and drop the public key into place in the firmware, overwriting the Beatie one 

Surely that would only work if we already have access?

The same BTAgent software is found in binary form in most CPE from BT. Those binaries/closed source libraries can be run in a MIPS emulator.

I'm not sure where you're heading with that but that's probably just a failure of imagination on my part.

 

I'm planning a slight different approach. Start off with a minimal emulation platform with just the processor, ram and flash memory - using the flash dump kindly supplied by your good self

Log all the I/O attempts and then start adding whatever emulated peripherals I can until I get it running. It'll probably take a while but you never know, We might get lucky and identify the update process trigger from the I/O log.

Good luck! You're on your own with that one!

 

Interestingly, the MIPS Malta platform you mention in a following post is one of the emulated platforms for the OVPSim I'm looking at.

I'm going to start looking at the examples over the weekend and perhaps try something more straightforward like u-boot on a 'bare-metal' platform before trying to setup a cfe environment.

One thing which did make me smile. I was reading through the OVP docs and it all seemed strangely familiar...

Then it suddenly struck me. The way their platform framework is put together is very similar to the methodology Peter Graham and I developed for emulating 8bit processors back in the early 80s 

Their's is rather more sophisticated of course... 

Aha.  If that was the Dr Peter Graham of umanitoba.edu, then he's a proper Unix beardie!  What was the development?

cheers, a

No, it's not the same PG. Peter and I did embedded systems design during the 80's using the Z80 for the most part. We even did a couple of 'personal computer' designs for a client as well but neither of them made it to market. Too much competition from the likes of Clive Sinclair

For us emulation was simply a way of eliminating the rather lengthy EPROM erase/re-program cycle during development and testing. We made it a generic 'framework' so we could re-use it without having to do a major re-write every time.

[zcutlip]

Hello,

I'm new here.  SecTSys got in touch with me via my company's website and asked if I'd be interested in joining in.  As enticement, he sent me a couple of HH3s (rev b) to play with, so here I am.

I'd like to help out where possible, if that would be welcome.  I think I'm mostly up to speed with the progress made so far (at least the broad strokes).  It looks like the main goal here is to get the HH3b to take a modded firmware so the device can be used with other ISPs, and also to disable some undesired BT "features". Does that sound about right?

My first step /was/ going to be do desolder the flash chip and dump the firmware, but I see that's been done already. Nice! :-)

Anyway, as time allows, I'll start poking at the device and the firmware and see what I can come up with.  If there are specific technical issues I should focus on directly, please let me know.

Unfortunately, this is a side project for me--I have to focus on paying client work first.

Cheers and looking forward to playing along.

Zach

[burakkucat]

Hello Zach and welcome to the Kitz forum.

Your understanding of the basic objectives is spot-on. Why should a piece of hardware be locked down to one particular ISP / CP (other than to maximise financial gain)?    (Rhetorical question!)

The maestro will be along in due course and, undoubtedly, will have some more words to post on this topic. 

[asbokid]

Hello Zack!

Welcome to the lunatic asylum!

The (buggy) f/w for the HH3.0b is dumped as you've already found.

The idea is to modify the embedded (JFFS2) flash file system in that dump, removing firewall rules as necessary and re-enabling telnetd and/or sshd, to allow shell access.  The plan then is to rebuild the firmware to include that modified file system. And finally to reprogram the flash with it.

In theory, simple enough.

Though it looks like the firmware is digitally signed. And it may be that the (closed-source) HH3.0b bootloader uses that signature to verify the integrity of the firmware (kernel + file system) before booting any further.

Next intermediate plan, as mentioned above, is to fit a NAND flash IC cradle onto the board of the HH3.0b.

The photo below shows a selection of boards for NAND flash prototyping.   Hopefully one of those black cradles shown at top-centre in the photo can be secured to the hole in the PCB where the NAND flash IC once lived!

This would allow for arbitrary firmware to be programmed into the NAND using a separate programmer.

(click for full size)

cheers, a

[SecTSys]

Hi there - I am Glad that Zach has made it here. - Didn't want to spoil the fun / surprise there. 

Getting a hold of HH3 (Rev b) is becoming difficult - BT are no longer sending them out - and switching back to the type a's for the moment. which kinda sucks but i have a friend who works for BT and has said that they will help me out bringing me HH3 B's that end up being replaced with type A's

I have one in stock shall we say! anyone need it?

[zcutlip]

Thank you for the warm welcome.  The progress everyone has made so far is impressive.

I think I'll start by investigating the integrity checking on firmware images.  Hopefully there will be a weakness there we can exploit.

Zach

[asbokid]

Getting a hold of HH3 (Rev b) is becoming difficult - BT are no longer sending them out - and switching back to the type a's for the moment. which kinda sucks but i have a friend who works for BT and has said that they will help me out bringing me HH3 B's that end up being replaced with type A's

It looks like the HH3.0b is being issued again to new Blighty Telco customers.  Here's one specimen, from the BT Care in the Community forums:

From: http://community.bt.com/t5/BB-Speed-Connection-Issues/New-to-BT/m-p/627436

New to BT   on 07-09-2012 10h59

Hi,
Been with BT for 3 days now and really disappointed on a number of fronts.
[...]

Information for Helpdesk agents:

Code: [Select]

1. Product name: BT Home Hub 3.0B
2. Serial number: +058721+1209309785
3. Firmware version: V100R001C01B031SP12_L_B. Last updated 04/09/12
4. Board version: VER.D
5. ADSL uptime: 0 day, 06:12:55
6. Bandwidth: 448/256
7. Data sent/received: 10361388/120208497
8. Broadband username: bthomehub@btbroadband.com
9. BT FON: Yes
9b. Shoe size: 8 (left)  8½ (right)
10. Wireless network/SSID: BTHub3-FRX2
11. Wireless connections: Enabled (b/g/n, 20M, WPS Disabled)
12. Wireless security: WPA and WPA2
13. Wireless channel: Automatic/1
14. Firewall: Default
15. MAC Address: 10:C6:1F:E8:49:88
16. VPI/VCI: 0/38
17. Line profile: Interleaved
18. Software variant: 12_L_B
19. Boot loader: 1.0.37-106.5
 

I have one in stock shall we say! anyone need it?

That's very generous of you, SecTSys, but I'm stuffed with routers at the moment.   Someone else, maybe?

cheers, a

[zcutlip]

This may be a silly question, but is there a way to disable PPoE on this device?  I'd like to assign an address either statically or with DHCP to the WAN port.

Thanks