jonrob.net

Hacking the OpenReach Eci modem b-focus v-2fub/r rev b

Using the router I configured in https://jonrob.net/2017/02/05/openbsd-6-0-home-router/ I found the connection to be stable until I moved house where I've been getting frequent disconnects, whenever this happens /var/log/messages on the router shows:

Jun  3 22:42:27 Xavier /bsd: pppoe0: LCP keepalive timeout
Jun  3 22:48:16 Xavier /bsd: pppoe0: LCP keepalive timeout
Jun  3 22:54:04 Xavier /bsd: pppoe0: LCP keepalive timeout
Jun  3 22:59:52 Xavier /bsd: pppoe0: LCP keepalive timeout

Swapping this out for a different modem resolves the issue so it's clearly an issue with the OpenReach modem, now lets see if we can fix it.

Connecting my laptop to Lan1 on the modem and restarting the network interface with

doas sh /etc/netstart em0

shows that it is not running dhcp, and

arp -a

shows nothing in the arp table so it doesn't look like this has an IP address meaning we can't telnet/ssh in or access any web interface. Apart from maybe looking into the BTAgent I don't see any attack vectors here.

The case can be opened without causing any damage by removing the two foam feet and unscrewing with a 00# phillips screwdriver, then shimming the clips using a loyalty card and the screwdriver, it's best to start at the side opposite the lights and work around as that side has three clips.

The tx, rx, and ground pins are labelled below as 2,3,4 respectively (between the firmware chip with the sticker and the capacitors) and we will need to solder some breakout pins onto the board to get a connection.

Once this is connected it's time to find the baud rate, my plan was just to go through a list of common baud rates but luck would have it I found it on the first guess, it's 115200.


So in OpenBSD we can cross the wires over with a UART and connect with the command:

cu -l /dev/cuaU0 -s 115200

Now we are greeted with:

IFX CPE login:

and trying all common passwords I don't have any luck(admin:admin, root:admin, root:root, user:user) so it looks like we will have to dig deeper.

Rebooting the modem it tells us we have 8Mb of flash and we can press any key to interrupt the bootloader, typing help gives us the available commands. Unfortunately there isn't a command to upload the flash to a file server but we can view sections of the flash with md, as we know we have 8Mb of flash we can use this to dump the entirety of it with.

md.b 0xb0000000 0x800000

It's no good in STDOUT though, so we need to close our session, enable logging, reopen cu and print the flash:

>$ script log
>$ cu -l /dev/cuaU0 -s 115200
VR9 # md.b 0xb0000000 0x800000
b0000000: 10 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0000010: 68 8c 68 8c 00 00 00 00 31 2e 31 2e 30 00 00 00 h.h.....1.1.0...
b0000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0000030: 40 80 90 00 40 80 98 00 40 80 68 00 40 1b 78 00 @...@...@.h.@.x.
b0000040: 3c 08 00 ff 35 08 ff 00 03 68 d8 24 3c 08 00 01 <...5....h.$<...
....
b07fffd0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b07fffe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b07ffff0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
VR9 # ~.
[EOT]
>$exit

This log file needs cleaning up a bit, so opening it in vim we can remove all the lines that aren't the dump, then write a macro to remove ^M from the end of every line(exact keys I pressed for the macro: ggq1$xjq550000@1).

To turn this dump into something usable we will need to perform a reverse hexdump with:

>$ xxd -r log >> flash.bin

This bin file is something we can work with, using binwalk we can see what partitions we have:

>$ binwalk -vt flash.bin

Scan Time: 2017-06-04 23:01:45
Signatures: 212
Target File: modem/flash.bin
MD5 Checksum: 703fb68b03b1cc55585204dd834645bf

DECIMAL HEX DESCRIPTION
--------------------------------------------------------------------------------------
19132 0x4ABC uImage header, header size: 64 bytes, header CRC:
 0x2C94DEF7, created: Fri May 25 05:44:51 2012, image
 size: 51504 bytes, Data Address: 0xA0400000, Entry
 Point: 0xA0400000, data CRC: 0xEE3E562A, OS: Linux,
 CPU: MIPS, image type: Firmware Image, compression
 type: lzma, image name: "u-boot image"
19164 0x4ADC U-Boot boot loader reference
19196 0x4AFC LZMA compressed data, properties: 0x5D, dictionary
 size: 8388608 bytes, uncompressed size: 140248 bytes
73728 0x12000 uImage header, header size: 64 bytes, header CRC:
 0x1172B473, created: Wed Sep 7 05:37:02 2011, image
 size: 56332 bytes, Data Address: 0x0, Entry Point:
 0x0, data CRC: 0x943FCF00, OS: Linux, CPU: MIPS,
 image type: Multi-File Image, compression type:
 lzma, image name: "GPHY Firmware"
73800 0x12048 LZMA compressed data, properties: 0x5D, dictionary
 size: 8388608 bytes, uncompressed size: 262400 bytes
135168 0x21000 uImage header, header size: 64 bytes, header CRC:
 0x43809A6F, created: Thu Jun 14 08:07:15 2012, image
 size: 942624 bytes, Data Address: 0x80002000, Entry
 Point: 0x802C4000, data CRC: 0x47732E02, OS: Linux,
 CPU: MIPS, image type: OS Kernel Image, compression
 type: lzma, image name: "MIPS IFXCPE Linux-2.6.20.19"
135232 0x21040 LZMA compressed data, properties: 0x5D, dictionary
 size: 8388608 bytes, uncompressed size: 3051672 bytes
1179648 0x120000 Squashfs filesystem, big endian, lzma signature,
 version 3.0, size: 2072326 bytes, 769 inodes,
 blocksize: 65536 bytes, created: Thu Jun 14 08:07:17
 2012
3870096 0x3B0D90 uImage header, header size: 64 bytes, header CRC:
 0xD5EF58F6, created: Fri Aug 1 03:18:35 2014, image
 size: 1096816 bytes, Data Address: 0x80002000, Entry
 Point: 0x800061B0, data CRC: 0xC19DACFE, OS: Linux,
 CPU: MIPS, image type: OS Kernel Image, compression
 type: lzma, image name: "MIPS LTQCPE Linux-2.6.32.42"
3870160 0x3B0DD0 LZMA compressed data, properties: 0x5D, dictionary
 size: 8388608 bytes, uncompressed size: 3420552 bytes
4980112 0x4BFD90 Squashfs filesystem, little endian, version 4.0,
 compression:lzma, size: 2536581 bytes, 1115 inodes,
 blocksize: 131072 bytes, created: Fri Aug 1
 03:18:41 2014
7601552 0x73FD90 JFFS2 filesystem, big endian
8256920 0x7DFD98 gzip compressed data, from Unix, last modified: Sat
 Jan 1 00:00:20 2000, max compression
8323442 0x7F0172 U-Boot boot loader reference

I'm not interested in the firmware or the bootloader sections as all I want are passwords, OpenBSD has no support for squashfs so the only thing I can check here is the gzipped partition(count is (8256920-7601552):

>$ dd if=flash.bin of=gzippedpart.gz bs=1 count=655368 skip=8256920
>$ gunzip gzippedpart.gz

This is a long configuration file with some plaintext passwords, mostly things like root:admin, admin:admin user:user, unfortunately none of these work so we will have to crack open the rest of the filesystem. I scp'd flash.bin to a machine I've got running Centos 6 and I managed to extract the filesystem with:

>$ git clone https://github.com/lattera/dd-wrt
>$ cd dd-wr/trunk
>$ sudo ./extract-ng.sh flash.bin

After installing the dependencies by trial and error it eventually ran and dumped the root filesystem into ./fmk/rootfs/

etc/passwd is a broken symlink to ramdisk/passwd but it's in ramdisk_copy/passwd, which is shadowed meaning we can run john the ripper on it

>$john --show passwd
root:amazon

This doesn't work either so after grepping the filesystem I also found etc/init.d/passwd.sh which is a script with some encrypted password it places into etc/passwd, john tells us these are the same password we've already seen:

root:admin:0:0:root:/root:/bin/sh
admin:admin:0:0:root:/root:/bin/sh

and it also alludes to a support_user account

At this point I reset the modem by holding down the reset button, unplugging it, plugging it back whilst still holding the reset button, it then told me it was wiping the flash and after that, admin:admin works!

I'm not sure what was stopping me from logging in before but now I'm in and I can try to get some more information on these disconnects, looking in /var/log/messages I get the following whenever it disconnects:

Jun 5 21:03:17 cpe local0.debug udhcpc[3932]: Sending DHCP DISCOVER, xid 0x112ca75a, secs 7882, uptime 7882 ...
Jun 5 21:03:19 cpe local0.debug udhcpc[3932]: Sending DHCP DISCOVER, xid 0x112ca75a, secs 7884, uptime 7884 ...
Jun 5 21:03:21 cpe local0.debug udhcpc[3932]: Sending DHCP DISCOVER, xid 0x112ca75a, secs 7886, uptime 7886 ...
Jun 5 21:03:25 cpe local0.debug udhcpc[3932]: Run dhcpc script : /usr/share/udhcpc/default.script leasefail
Jun 5 21:03:25 cpe local0.debug udhcpc[3932]: Waiting script finish (pid 5027)

Which isn't very helpful to me, from here I think my only options are either watch the network traffic using tcpdump to troubleshoot further, or to install OpenWrt to see how it performs. I'll try these when I get some time but if anyone has any ideas on what might be causing these frequent drop-outs I would love to hear from you.

2020-07-06 Update
Further troubleshooting suggests this is an issue with OpenBSDs PPPoe interface with BT, solutions outside of digging into the PPPoe code are to terminate the connection with a non OpenBSD device or change service provider.
I did get a lot of help from: http://forum.kitz.co.uk/index.php?topic=11818.180

and the reset instructions came from: http://www.kitz.co.uk/routers/hg612hacking.htm

and unsquashfs is from: https://github.com/lattera/dd-wrt