Io-homecontrol / velux - something's in the bush

Add-ons Bindings
226

Dear all,

I just bought an io-homecontrol device (a water heater) that I would like to control. Unfortunately I don’t want an io-homecontrol bridge (“cozytouch” in my case) communicates to a remote server in order to configure and control my devices. I really would like to control them only from my local network.
Thus I’m looking for a solution to make a local link between domoticz or any other domotic solution and my devices through an official but hacked bridge or a personal io-homecontrol bridge.
It seems that you start cracking the io-homecontrol protocol. How far are you from creating an opensource io-homecontrol bridge or something like that? And does someone can make a summary of the current knowledge of this protocol?
To finish, how can I help?
Thanks for your work!

227

Hi,
Unfortunalety, i am in the same case. But i have no really Time to hack.

So i am following the work… The last News i have from aldorh is that the work is on github
https://github.com/Aldohrs/tahoma-jailbreak

228

Hi Teetoow, SamD,

Unfortunately, I didn’t do any work on Cozytouch as I focused mainly on the hardware I got: the TaHoma.

At this point I only have pieces of information about io-homecontrol and a bunch of untested hypothesizes. Here’s what I know:

  • The radio protocol works (at least for EU) on 3 bands of the 868MHz range. The bands are used to reduce collision risks between frames and to improve the communication capacity
  • Every frame is encrypted using AES-128 with a key common to the whole installation (1 controller, like the TaHoma, and x devices). This key may be sent in clear during the pairing process but it has to be confirmed.
  • There are several classes to differentiate device types: actuators, sensors, etc.
  • It is a multilayer protocol and it seems that the application layer can be arbitrary as the io-homecontrol application embedded on the TaHoma has dynamic parsing specific to each supported device.

Some folks here and elsewhere took other paths to reverse the protocol and also learned some things. You can check on the following links:

On the TaHoma, the protocol is handled, on the real time side, by an off-the-shelf STM32 and a SI4463 transceiver. Both are available on the market and the circuit may be recreated to get a standalone board usable with a Raspberry Pi or anything that have GPIOs and/or USART support. I don’t know the STM32 well but it may be possible to have a USB port for easier use.

Unfortunately, I’m not an expert in radio and electronics. Plus, to be sold, such a device must pass regulatory controls (e.g. by the FCC and/or other agencies for non-US countries).

So I’ll tell we are very far from an actual opensource transceiver for io-homecontrol.

The easiest way would be to jailbreak an existing gateway (check for the Velux Gateway for example) and use it as a bridge.

On the TaHoma side I did some progress since my last message. Here’s what I learned:

  • The embedded webserver is usable only when the device is in “pairing” mode (I’m not sure if this is the same mode as the mode activated to integrate a new device),
  • The embedded web application that comes along the API on older versions of the firmware references something called a “Rail DIN” (the app seems to be in french). I guess this is the industrial version of the TaHoma,
  • The HomeKit integration may open some attack surface because it opens ports,
  • I managed to get the TaHoma to communicate with a webserver I own on the local network. I’ll add a tutorial to the jailbreak repository to do that when I’ll have some time. At the moment, I did not have enough time to reverse the protocol used on the web side. As the TaHoma checks connectivity through an unknown UDP protocol on port 18888, I’m not sure if it is necessary to mimic a response from the server to have actual communication. I only observed the firmware and environment update process so far,
  • Not useful but the firmware leaks internal URLs of the CI infrastructure of Overkiz and also their test scripts, lol. The latter may be useful to debug some things.

So, how to get on the train? My main concern at the moment is the way we share knowledge. The discussion here is interesting but it does not organize information well. I created a private repo on Github with the latest progress but I didn’t really update it since last year and it is really focused on what I found on the TaHoma firmware.

To reverse the protocol on the software side, we have at least 3 major parts:

  • The lua daemons that are in charge of the top-level application management (device knowledge, device management, communication with Overkiz’s cloud, etc.)
  • The io-homecontrol native library (developed in C++) which is in charge of ensuring the communication through USART with the STM32
  • The STM32 firmware which is in charge of handling the real time operations with the SI4463 transceiver.

To do that, they are several approaches that can be used:

  • Static analysis of the luajit code (fairly easy because of the bytecode format that can be decompiled rather easily, though a comparison with actual bytecode stays necessary as I found no 100% reliable decompiler - maybe some improvement to the existing one could be something for a developer),
  • Static analysis of the native code (ARM for both the STM32 and the AT91 with Thumb for the STM32). Some scripts should be made to properly map IOMMU in IDA or Ghidra.
  • Dynamic analysis using directly Somfy’s hardware or, better (but needs some work to prepare the toolset), emulation on Qemu.

Another concern I have is the share of the firmware. First, it is likely to be illegal and, second, it may allow someone to identify my unit that has not been banned yet. Overkiz uses now a CDN that is not authenticated, but I have no means to ensure that the update URLs are nothing more than a commit number.

The best I can do is adding you to the project I have on Github I you ask me individually by DMs.

Regards,
Aldohr

EDIT: I added the instructions for MITM attacks on the TaHoma here: tahoma-jailbreak/SSLMitm.md at main · Aldohrs/tahoma-jailbreak · GitHub

229

Hello again :slight_smile:

Just a quick update as I’m still working on this.

First, I spoke before about the possibility of booting Linux on the TaHoma from a USB stick. Unfortunately, this is not possible if the box is not already jailbroken as the analysis of the initramfs showed that the Linux images on the USB stick must be signed by a certificate (unless if the signature verification program has a flaw, we’re blocked here).

I managed to make the box communicate with my webserver using DNS hijacking and certificate modification as described on Github. The update URL is the first one called by the box. It exposes several endpoints that allow the box to know if there is a new version, log information (quite verbose) and obviously it provides the box with firmware images. It also provide the box with a configuration file that allows it to know with servers to contact and with which protocols (there are several options) for normal operations.

Most of the internal communication from software to software is done using dbus. I plan to directly hook up here to have a close access to all commands. But some static reverse engineering is required before to understand the services exposed on the bus.

And here I am for now.

2 Likes
230

Hi Guys,

Just discovered this topic - if I can be any helpful - I jailbreaked the Cozytouch some months ago (I shared my process on my blog - www.lafois.com).

I then created a simple cozytouch to MQTT python daemon - and I can now monitor and control my water heater.

Cheers,

Ben

2 Likes
231

Hi @hairdresser,

Awesome work! Like I suspected, the Cozytouch architecture is really similar with the one of the TaHoma: same processor family, same firmware layout, same radio “daughterboard” (STM32F101 + SI4463). I think we have nearly the same firmware, with just some features different (for example the TaHoma has 2 “daughterboards”: one for io-homecontrol and the other for RTS).

If you follow the guide I wrote for the TaHoma, I would not be surprised if you had also an access through the USB port (but you don’t need to anymore :p). But if you want to get another way, here you go: GitHub - Aldohrs/tahoma-jailbreak: Instructions and scripts to jailbreak the Somfy TaHoma

SAM-BA can flash the NAND flash using the nandflash applet. At least, the process is straightforward through the USB or Serial connection (if the Serial you found is DBGU). It may be simpler than your approach if you’re able to jump into SAM-BA at will.

Regarding SSH: you can also just replace the authorized_keys file in /etc/security to use your own key (this is why the root account has no password); also be careful if you then connect your box to the Internet because the status of the SSH service is sent to Overkiz. And Overkiz can also remotely control the state of the SSH service, maybe that’s why your device closed itself (though an update can also do that because updates are images directly flashed to the UBI volumes).

I worked on the dbus approach but not quite as much as you. I wish I found out about your blog before. I also tried the lighttpd step without much success, but didn’t want to bother patching the lua part.

At the moment, I’m working on the CloudLink protocol (and I made some significant progress since my last post). Hopefully, that will allow me to have a simple access to the dbus because all data exchanged between the Overkiz cloud and the TaHoma is encoded in XML and JSON and thus is simple to reverse engineer. The only thing I had to overcome was the TLS mutual authentication and the fact that the TaHoma expects a sort of “server hello” from the server before sending any data (it is just a 0x03 byte sent by the server after the TLS handshake).

@ennergei is working on the firmware of the STM32F101 I dumped from my unit. You should be able to find yours under /apps/ (look for something named like stm32). We were able to pull some information on the io-homecontrol protocol itself mostly with the information that were pulled by Thomas Buck in this thread: Is io-homecontrol decodng feasible - #5 by tobu42

I’ll give you some more information in DM if you’re interested in taking part in the research.

Regards,
Aldohr

232

I also worked on the data exchanged with the cloud (after properly adding my certificate in the keystore) - but I realized that not all the data received from the device are transmitted to the cloud.
In my case - I was interested by all probes/sensors values (useless - but as I’m a geek… :-)) - reason why I went back to the DBUS; Same remark for REST api: not all the values of all sensors are present - while they transit on the DBUS.

233

Hello,

I tried to follow the guide from @Aldohr but didn’t get to the state where I could see the device listed in lsusb.
I just recently received the Tahoma and thought the first step with connecting “two points” couldn’t be too hard. Currently though my box is just having the green light on with a blue flash every 15s.
Any idea what this means? And do you have any tips for the first connection to get onto the device?

Regards
flobbie

234

Hi Guys, i am new to this, i also have velux integra
is there a possibility to read the rain sensor? can we get the state of it?

thnx in advance

235

Hello, I don’t know whether it is possible with the current binding, but the API of the KLF200 offers this information. (Page 61)

0x02 STATUS_RAIN The status is from a rain sensor activation.

236

The binding supports it as the rain sensors modifies the windows limitation settings.

237

i believe the rain sensor is onlu activated when the windows was open ? if its closed, it doenst get a state i think?

@gs4711 , what do you mean by “windows limitation settings” ? where is that described in the api ?

238

do you mean this one?

0eE3 LIMITATION_BY_RAIN

239

No, this is not stated within the API documentation. It’s an undocumented feature of the rain sensor which modifies the window limitation settings.

240

ah, can you give me some more info about it? atm i am using pyvlx with scripts
any idea how to retrieve it with that?

241

@Fabio_Pergola

unfortunatelly I don’t know the scripts but you can try to query the window limitations to determine whether it is raining (see also Velux - Bindings | openHAB).

242

aha, it is the same as this? @gs4711

image
image642×873 103 KB

1 Like
243

Hi Guenther as far as I know it, the Velux KLF binding does (of course) receive the limitation setting value in the data retrieved from the actuator, but it does not (yet) do anything to convert those values into an actual Channel state… :frowning:

But nevertheless I think this should be possible with very little work, so I will add it to my ‘to do’ list… :slight_smile:

244

andrew, with what command from that api document can i retrieve that info ?

245

Yes. You’ve got it.