I’ve had a smart home alarm system for close to a year now and have been mostly happy with it but for the lack of ability to manage it outside of their mobile applications and online systems. With the help of a Bus Pirate I’ve hopefully solved this problem.

I would like to use Node-Red to interact directly with my alarm unit not using the manufacturers online systems. I would also like options should they decide to turn their service off one day.

The hub device has a web interface on port 80 but you are not provided with a password for it. The service is basic looking and it’s clearly not intended for consumer use. Having a device on your local network with an admin interface you don’t have a password for really isn’t on.

I had previously come across an article that stated they obtained the web interface password from the firmware through the JTAG port but it also said that a firmware update had been released to fix some of the concerns. My device was purchased after that date and has had firmware updates so I wasn’t sure if it would work, but as I had a Bus Pirate already I might as well try.

I decided to open the piggy bank for a cable and a breakout board to connect the Bus Pirate to the on-board JTAG socket. The main chips data sheet can be found here. I used OpenOCD’s kx.cfg as the target via the Bus Pirate. I was however met with this text so it seems they did secure it as suggested in the linked article:

Warn : **** Your Kinetis MCU is in secured state, which means that, ****
 Warn : **** with exception for very basic communication, JTAG/SWD ****
 Warn : **** interface will NOT work. In order to restore its ****

I examined the headers on the bottom left of the board with a Jtagulator but couldn’t identify JTAG or UART on them so I assume they are for an expansion or something. There are unpopulated connectors on the board for USB sockets and other things.

There were three unpopulated holes next to the main chip with one being ground, these connected to pin 31 and 32 on the chip. On looking up the data sheet this pin pair can be configured as UART TX & RX:

I considered taking the board out and putting headers on but the probe clips go through and hold in place so just set up like this:

The data sheet suggested 115200 baud and on starting Minicom, output was immediately visible on the terminal.

The system is sending a lot of information to this interface, device status messages, configuration information, XML from the external XMPP communications and logins/passwords attempted on the web console.

This was interesting but the interface appeared to be for debug output only and I couldn’t find any way to get a response with input at all.

Talking about the nearly but not quite issues to a friend they suggested flash chips and referenced this great write up. So next up was the Winbond 25q32fv chip with SPI!

Now I had a choice here, I should really take the chip out as powering it up may power the board up, and I’m not going to be able to read it properly it if it’s being used. Being lazy I just gave it a go with flashrom but ended up with correctly sized files of garbage.

Guessing the failure to read data might be to do with SPI being used as the device was powered from the Bus Pirate, I removed the chip.

The chip came off cleanly with the heat gun:

I then spent the next ten minutes unable to get anything from it at all while convincing myself I had broken it somehow. I then soldered it back on and powered the device up to be met with it taunting me about my failure with this on the UART:

faile0-faile0-faile0-faile0-faile0-faile0-faile0-faile0-faile0

I removed and then re-soldered it once again in hope it was just my bad soldering to thankfully find the device working again. Now I wanted to remove the chip and try reading again outside of the device, but I’d had it off twice and after the near brick experience I wasn’t keen on doing it again.

When I’d tried reading the flash previously there were constant errors streaming by on the UART due to things being disconnected/powered off. In order to raise odds of getting something useful off the chip while the system was running I removed most of the error conditions to reduce potential use of the chip and tried again.

Binwalk still wasn’t giving any information about the structure of the file though. However on running strings on the output this time, the information I was after, the password, was sitting alongside the admin username. Most of the file was garbage but I had the one bit I needed and could now log in to the web interface.

The password is random alphanumeric so they may have followed the suggestions from the earlier referenced article but without another device I can’t confirm that they are all unique. I would not have been able to brute force this password so thankfully this worked as I might have tried that next.

This wouldn’t have been necessary had they just provided the web interface password. I don’t think it’s acceptable to provide equipment with listening network services while not providing a means to use them.

The device I used here has been updated by the manufacturer so the above may not be possible on the new units.