Chameleon IHD6: Reverse-engineering first look

This post looks at the internals and operation of the Chameleon IHD6. My motivation is getting access to my own consumption data.

Accessing energy consumption data

For some reason, the UK smart meter infrastructure makes it hard for an individual to get access to their own consumption data. Many households are given an In-Home Display (IHD) by their energy supplier which allows them to see the energy consumption, but not feed it into their own data collection or home automation systems.

The Chameleon IHD6 is a very popular IHD at the moment. Getting data off of that device is not possible unless your energy provider provides a means (e.g. Bulb can connect to Smart Things). For everyone else… bad luck.

This may appear to be a strange set of circumstances, given that the stated purpose of the IHD is to provide information to help energy consumers manage their energy consumption. Contractually, the device is owned by the energy consumer. It has the consumer’s wifi password, and uses the energy consumer’s internet connection. It handles the energy consumer’s personal data (without their express agreement?).

Welcome to the 21st century: You are not the customer, you are the product.

Network

The IHD connects to a wireless network called the Home Area Network (HAN) which is managed by the energy industry. The energy consumer is locked out of that network, although some energy providers will allow them to connect their own approved CAD devices.

Chameleon IHDs which are supplied with the CAD option also have a connection to the consumer’s wifi to allow upload of consumption data, and to allow the provider to manage firmware and settings. The uploaded data is not available to the energy consumer unless Chameleon and the energy provider offer this as a service. One assumes that this is due to commercial decisions: Chameleon can get the energy provider to pay for an ‘upgraded feature’ for consumers.

The device

Documentation

There is very little technical documentation publicly available. The technical overview says that the CAD version of the device supports:

MQTT messages with a TLS 1.2 encrypted, JSON encoded, payload

The documentation also mentions a feature:

Engineering menu to aid triage

I don’t believe I have located the engineering menu.

Externals

The device doesn’t have much going on. There is a touch-screen display on the front, and a power button and micro-USB connector on the back to charge. The USB connector appears to be for charging only — it doesn’t appear to have an active USB device on the end.

Network

Before taking it apart, I’ll connect the device up to a wifi hot spot which is not routed to the internet and see what happens:

• The device performs a DNS lookup for 0.cham.pool.ntp.org and 0.time.chameleoncloud.co.uk and uses these hosts for network time using NTP. If the DNS lookup fails, or the hosts on these addresses do not supply network time, the device considers the wifi connection failed. I created a DNS service using dnsmasq and pointed these addresses at a local NTP timeserver to get beyond this step.
• The device then performs a DNS lookup for r55np2.messaging.chameleoncloud.org.uk and performs a TCP TLS connection to port 8883 on that host. Judging from the port number, this is an MQTT connection.

I can’t get beyond the TLS connection step by creating a TLS certificate. On connection to a spoofed TLS service, the device closes the connection. I have tried setting up a service with a certificate signed by my own self-signed CA, and also with a properly signed CA (but the wrong hostname). It appears that the device is doing TLS trust properly i.e. it has one or more trusted CA certificates which it uses to verify the server’s identity.

In the real world, the provider’s MQTT service uses an RSA 2048-bit certificate with web server and web client key usage. The certificate is provided for hostnames *.messaging.chameleoncloud.org.uk and messaging.chameleoncloud.org.uk and is issued by GoDaddy.

I’m reluctant to let this device connect to the real internet over my wifi, so haven’t taken this further at the moment.

Internals

If you have one of these devices: don’t take it apart unless you are happy with the device not working. There is a tamper-detection switch inside, and your energy provider may be unhappy with you breaking the device. In my case, I’m working with a device which has been decommissioned.

The bigger IC you can see here is an FT800Q which is a graphics offload device for the TFT screen, it handles display and touch-screen.

There is a momentary switch top right in this picture, which is for tamper-detection. When the board is enclosed in the case, the switch is pressed. To try to subvert the switch, I drained the device battery before opening it up — not sure if this would have been successful or not. The device, when configured by the energy provider, has secret keys for the ZigBee HAN on-board, and one guess would be that tamper detection would result in the deletion of these keys.

The USB connector power lines are connected to power circuitry. The data lines are routed to an area of the board bottom right in the above photo, and don’t appear to be connected to anything. The USB lines connect to R12 and R13 which aren’t installed on this board, along with MV2 and MV3. Perhaps if the correct components were installed, the device would be accessible as a USB device.

The battery is soldered to the battery leads. The interesting components are hidden behind two EMI shields. With the EMI shields removed:

Two MCU components can be found: a Qualcomm QCA4010 and a ERF32. Both devices have an RF function, judging from the antenna traces which they are connected to.

The QCA4010 is the larger of the two devices, it supports wifi 802.11b/n/g and judging from its size (800kB memory) is the master device. The ERF32 is an MCU with 2.4GHz RF capabilities, and supports a number of protocols including ZigBee.

There are many test points on the board which are connected to both MCUs. There appears to be a set of pads for programming the QCA4010 in the centre of the board, these pads are also connected to test points. It may be possible to extract and modify the QCA4010 firmware using these pads. The device is also designed to be upgraded over wifi (by the energy industry, not by the consumer).

The tamper-detection switch connects to pin 25 on EFR32 device (PA0) pin, which indicates that it causes an interaction with ZigBee functionality. Also, it indicates that tamper-detection is not functional unless the EFR32 is running.

Conclusion

Further areas for study would be:

• Can the firmware be modified for a new CA certificate?
• Can the engineering menu be accessed, and can it be used to configure the network communications?
• Has the device been assured, and is it secure to connect to a consumer’s wifi network?
• Is the service compliant with GDPR and does the consumer have control over what their data is used for?