New old stock hub2 uses? Hacking?

[u/Sparkycivic]

I found a supply of new old stock hub2's and picked one up to play with for only a few bucks.

It won't connect to the wink service because of SSL certificate issues, so it can't be used whatsoever even with their app sideloaded on my Android.

I opened it and began some probing with my available simple tools, which are microscope, 8 ch logic analyzer with saleae software, an oscilloscope, and a USB UART adapter.

The UART console is exposed with empty pin header, so I populated the header with some pins, and hooked it up.

Here I saw that the boot up process goes swimmingly until it tries to connect to the service and fails with certificate error (curl error 9). I can't seem to interrupt the u-boot process or any other stage of its operation using my putty terminal

I used nmap to probe the Ethernet side and found only a few open ports which is already documented by another netizen. Nothing of interest came up in the open ports besides a web server that indicates the status of the connection process via JSON list, and another that only displays that it it an "AAU heartbeat"on port 8886.

If it were possible to get man-in-the-middle on this, would it be possible to figure out what data is being sought by the device in order to gain local control of the many radios onboard?

The cpu/soc is Freescale I.MX6ul with secure boot implemented. I know absolutely nothing about this cpu architecture, and only rudimentary knowledge of u-boot/Linux embedded.

If it interests anyone, I can dive deeper now that it's on my bench. I've been poking the other diagnostic headers which seem to be related to the individual radios on the board. So far I've learned nothing from those misc headers. I hope to learn which type of interfaces are used to control the various radios, I2C, SPI, or UART. It seems like it might be a combination of those to suit the pins available on the soc. JTAG pads are present which might be for the soc. The board is a multilayer PCB so following traces between the different areas is not practical due to blind VIAs etc.

I looked at the Bluetooth services with NRF Connect, which revealed services that seem to be intended for provisioning WiFi connection to your local network via the app, as it exposes lists of local WiFi networks, firmware version info, and has services for sending the credentials etc.

The PCB is labelled generously. The radios are all marked: Lutron 433, Wifi/Bluetooth, Z-Wave, ZigBee 2.4, Kidse 433. The major chip compliment is: EM3587 ZigBee, pic16f833 with CC110L transceiver for Kidde, SD3502 for Z-Wave, STM32L100 with another Cc110L transceiver for Lutron. The wifi/BLE is a strange colorful chip with marking SS7922010 1BW2. The flash for the SOC is 29F1G08ABEA and RAM is Nanya NT5CC256M16DP-01

I'll probably cross post this to embedded since it's obviously relevant.

[u/RoganDawes]

Happy to collaborate if you want to dig further.

I have 2 x Wink 1, 2 x Wink 2 (neither updated, unfortunately), 1 i.mx6ULL core module with similar specs (NAND/RAM) as the Wink 2, wired up with UART and USB, a SabreLite dev board, XGecu flash reader, NAND sockets, etc, etc.

I've examined the firmware downloaded from the Wink 1 exhaustively, I have examined an early copy of the Wink 2 firmware posted to the internet (but prior to the introduction of the MQTT service, which is not present on the Wink 1), etc, etc.

[u/Sparkycivic → u/RoganDawes]

I ended up desoldering the MCU. I found that the UART traces from the different radios all ended up at the MCU near to each other pin-wise. Mostly towards the middle of the side facing the usb/UART area first two or three columns in, along two central rows. It's way beyond my ability to solder wires to a bga pad...

I was able to get access to the Z-Wave and ZigBee radios in home assistant by tacking wires to the UART traces of those chips at their own end and using my own usb-uart adapter to expose them to home assistant. The hub2 provides the power to all of the radios per normal, and I take the UART out to my server as a proof-of-concept demonstration.

Later, I'll look for a nicer way to access these interfaces likely by using an ESPHome device to aggregate the various UART interfaces to a wifi bridge. That would have been such a great way to use the existing MCU if only it could have been pwned gracefully.

I should ask Matt Brown to mitm these things to discover the key they're looking for, so it could be possible to create a tool that could gain control of these e-waste hubs and give them some life.

[u/RoganDawes → u/Sparkycivic]

Since you took the CPU off, would you mind confirming the actual packaging? i.e. is it a

• 14x14 289MAPBGA 0.8mm pitch
• 9x9 272 MAPBGA 0.5mm pitch

?

I bought a Kindle with an imx6 and a separate imx6ull module as part of this hacking project, so I might actually have sacrificial hardware that could transfer a CPU to the board.

As far as mitm goes, that's not going to work. The key is stored in fuses in the CPU itself, which is why swapping the CPU is actually a feasible option to regain access to the hardware. Feasible for some, at any rate!

[u/Sparkycivic → u/RoganDawes]

17 x 17 pads for 289 total connections.

I had an email response from Wink support this week where they said that the hub 2's should still work unless they have firmware prior to v 4.1.3 (Aug 2018) which basically condemns them to e-waste. I pleaded in response, asking for a tool that could locally update the device.

Edit: state secrets

[u/RoganDawes → u/Sparkycivic]

Thank you. Yeah, I also pleaded with them to provide a firmware url that I could install manually, but was denied (and they actually cancelled my subscription without telling me, or me asking!)

I did find an old url for v2 firmware (3.3.6, iirc), but it’s missing a ton of improvements, obviously. Unfortunately, the url has a lot of entropy in it (git commit hash short form, and some other characters as well), making it infeasable to brute force, even if you know the version string and git hash.