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

Hello !

Nice work @ennergei! io-homecontrol frames are in fact encrypted in AES-128, so this may be the key you have here.

On my side, I’ve been dark for a long time. Sorry about that, I had so much things to do that the io-homecontrol project has a bit gone under the pile.

I have good news though. I found a vulnerability in the TaHoma box. It still requires hardware access but it is way much simpler that the method I used before to dump the NAND.

It may be patchable by software but I doubt that Somfy and Overkiz will ever do it because:

  1. They would have a non-negligible chance to brick the box
  2. It would require some design changes

I’m keeping a bit under an embargo here, just the time to check some details. Hopefully, I’ll go full disclosure by Friday. I’ve managed to gain full root access on the latest version and to prevent the update utility to brick the TaHoma at the first reboot.

Another thing interesting is that the TaHoma is capable of rebooting to an attached USB mass storage if root access has already been obtained. I have some research to do on this but it would really accelerate the test process and if a vulnerability allowing to write to arbitrary files is found we could have a tethered exploit not requiring any dodgy hardware manipulation.

I wrote a detailed post explaining the whole process and the trails that I find interesting so far. As I said, it should be available by the end of the week. I you have a spare TaHoma you don’t mind to brick (and I suspect that other Somfy io boxes are affected too), just get yourselves a USB-A to USB-A cable and a piece of wire :stuck_out_tongue:

Anyone, let me know if owning the TaHoma is still something of interest.


Hi again,

If you look for the instructions to read/write the NAND flash memory of the TaHoma without having to desolder it, look here:

Here’s a bit more context.

With the help of several persons, I was able to dump the firmware of the TaHoma box more than 3 years ago. It may be valid for other Somfy boxes (like the Conexoon) as the Linux Kernel source code contains several Device Trees following the same architecture for all Somfy’s boxes (search for Overkiz in the Linux Kernel).

Dumping the firmware required to desolder the NAND flash memory, read it, apply a specific and custom ECC, and backdoor the firmware with specific manipulations to prevent it from bricking itself at the next reboot.

As this was only reserved to advanced users with no practical way to get fast modifications on the firmware for analysis, I did only disclose the process to a few people.

A more practical (more like less difficult in reality) way to jailbreak TaHoma’s firmware consists in exploiting a flaw in the boot process of the ATSAMA5D31, as it is configured, that runs the board.

The ATSAMA5D31 boot process is as follow:

  • Internal ROM (burnt into the SoC) is ran at address 0x0
  • It lists all memory devices attached to the SoC (in our case, the NAND flash memory)
  • It calls the second stage bootloader from the boot memory device if it finds a valid pattern at the beginning of it
  • If it does not find that pattern, it boots into a recovery/program mode called SAM-BA

By default, the SAM-BA monitor mode is not secured. Details for securing it are under NDA but I don’t think Overkiz followed that specification.

During my tests, I noticed that when a blank NAND flash memory is connected to the SoC, it boots to SAM-BA mode. It then gets accessible via USB (A-to-A cable) to a host. The host is then able to send commands and data through the USB port.

As described on the Github link at the top of this post, the trick consists in blocking the normal operation of the NAND flash memory. As per the specification of the memory, the CE# pin should be pulled low to enable it.Thus to bypass this, feeding 3.3V to the CE# pin deactivates the NAND chip. As a matter of fact, the SoC doesn’t detect the NAND flash and boots the SAM-BA monitor.

Using a utility from Atmel, I was able to dump and to write data from and to the NAND flash memory directly through the SoC. That solves several problems, like the ECC and the need for a NAND Flash memory programmer.

It is unlikely that this vulnerability will ever be corrected, though not impossible.

I still have at the moment other means to retrieve the firmware that are less practical.

Several things should be determined at the moment but here is my master plan:

  • Get the TaHoma to work with unofficial servers
  • Get a reverse-engineered specification of io-homecontrol to work with a device inspired from the STM32/transceiver in use in the TaHoma

So, if you want to get on the train you may want to check:

  • There is a web server embedded. On older versions, it was monkey with a static website calling cgi-bin endpoints. Most recent versions use lighthttpd with only the API. It is authenticated and I didn’t find yet where the credentials are stored. The API calls are made to a socket owned by the “local” application. My main hypothesis is that this web server can be used to manage the domotic functionalities, but it is disabled by default.
  • Most high-level applications are developed in lua and compiled with luajit.That can be decompiled quite easily.
  • The /apps/overkiz/share/ folder contains specifications for each product supported by each protocol in SQLite databases
  • The /apps folder contains also the node database for each protocol. The io-homecontrol database contains the AES-128 key for the io-homecontrol network
  • The /sys/next file allows to choose to boot from a USB stick (but a proper root filesystem and Linux is necessary)

And that’s all for today. Enjoy owning (or bricking) your device.


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!

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

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.


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

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.


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 -

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




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.


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.


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?


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

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.

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

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 ?

do you mean this one?


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

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?


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).

aha, it is the same as this? @gs4711

1 Like

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: