this is my understanding as well.
I didn’t find any example in the community of someone able to directly communicate with io-homecontrol devices, therefore my deduction is the same as yours.
Please keep posting your findings, I’m very interested in your research. I also think that the community would really appreciate your help in controlling Velux devices via OpenHAB.
thanks
Having reviewed several communities like FHEM, openHAB, somfy (and some local German ones, like ELV, busware), I’m doubting that there is a working interface which is able to “speak” to io-homecontrol devices (including cryptographic setup, continous key exchange, a.s.o.) for the time being.
But, if you find a device, please let us know…
Hi, all
No news about SPI from leutholl ??
I think it is the best way, RF + uP/USB can make a dongle.
AES key is in RF chip, so SPI is free to find the protocol, is it not ?
Hi all,
It’s been a while since I reported to you last time.
I am still in the TaHoma approach and I have some feedback.
First of all, I still don’t have a protocol specification. Nevertheless, I have managed to root the box by reflashing the NAND memory. I did that because the static analysis is quite time consuming for little benefits.
An io-homecontrol installation uses AES-128 to assure protocol authentication. On the TaHoma, the installation key is stored along the node database (the list of the characteristics of all installed io-homecontrol devices) directly on the NAND Flash.
All the applications to manage protocols are ARM-compiled + Luajit (bytecode). I decompiled some with enough details to have a basic understanding of io-homecontrol’s principles. That said, this isn’t enough for me to fully describe an io-homecontrol frame. I am considering to use a SDR approach to sniff data on the network given the fact I know the encryption key.
The good news is that I can activate debugging on TaHoma’s applications. Moreover, they communicate using a dbus message broker I can also sniff. RPCs by this way are the basis of all communications on the box. So it seems to be possible to intercept a message at different levels (application to the SPI bus of the io-homecontrol chip).
BTW (speaking of SPI), I discovered this a long time ago when I began this project, but here is the device tree of the TaHoma that may be useful to understand the TaHoma platform: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/at91-kizbox.dts
At this time I have unfortunately no jailbreak without hardware attack. But I have some ways still to explore… It may be possible, even if the developers did a good job securing the OS. Moreover when you have the control over the system, it is possible to redirect the cloud link to an on premise server. Setting a full test environment with a private server is my next priority, it will make me able to fully control the command chain.
I’m still looking for help on this project. Contact me by PM for details.
Thank you for your efforts!
I wish I would have the necessary skills to help you!
I have a Somfy Tahoma Pad and a Somfy set&go device.
If I can help you with testing or somehow else please let me know.
Also thanks from me to everybody participating here! It’s a very interesting topic and I’ve been following it for quite some time now.
Hopefully not too far off-topic: If a Somfy Tahoma fails to boot, it tries to recover from a USB drive. Does by any chance somebody have such a drive?
Hey Aldohr,
I’m curious about the firmware dump, any chance you could send it to me? I have a bit of experience with ARM decompiling + general software security, so I can try to look for security holes in the box to hope for a hardwareless jailbreak.
The Somfy servers went down tonight for a few minutes, which only makes me want to have a home control server more.
I haven’t found the PM button on the community (perhaps I can’t due to my account being brand new), but I’d love to help out on this.
Cheers
Hi,
Is anyone still interested in the protocol used by Set&Go io? I reverse engineered the encryption. It is AES-128 encrypted with a custom block mode and padding scheme. The key for incoming and outgoing packages is the same, but the supposedly random iv used for the incoming messages seems to always be the same (a bug/poor “random” generator?). I can decrypt the messages from the logs in earlier threads and find strings such as the names and serial numbers and 16-byte keys that are likely the device/system keys. The decrypted packets also contain a CRC-16 with polynomial 8408. I wrote a small emulator to demonstrate it and uploaded it here: https://www.dropbox.com/s/laal9ylyj2n6lxe/set_go_emu.zip?dl=1
The sample data is from the packet logs posted long ago by leutholl and others. ( https://groups.google.com/forum/#!category-topic/openhab/AinJdyyDtG0 ) I was reading through their old topic on reverse engineering the protocol and felt like giving it a try. I am actually considering to buy screens and was looking for information on whether to get the RTS or io motor. I do not actually own any io devices nor the set&go mouse at the moment, so I cannot test it with actual hardware. Instead, I wrote an emulator that makes set&go io think a device is connected. To that end, I injected a .dll (VS2019) into the executable that bypasses the USB detection and reports that a device is connected on COM3. Then I wrote a Python (3.8) script to communicate on COM4 and used com0com to pipe one to the other. Now Set&Go thinks a device is connected. It finds 4 io devices from leutholl’s logs, and one made-up device that seems to show a bit more UI. I don’t get many settings to change (I thought that was the purpose of the set&go?) but maybe that is due to the devices that were used for the original logs.
I do not know much about the content of the messages, except that it seems to be organized in sessions and that most messages contain some kind of optional sub messages. Not all messages seem to follow this format however, this is specific to the message type.
I also had a look at the firmware. The firmware was embedded in the executable as a Qt resource. It is actually stored as 950 pre-generated and pre-encrypted protocol messages of 550 bytes, each encrypted with the same key as before. I decrypted the messages and concatenated them to get a raw firmware dump (950*512 bytes), but I do not know what instruction set is used. It looks like it is big-endian judging from a few address offsets in the beginning of the file, but that could be misleading. I can find the encryption key bytes, the firmware version, and a few text strings in the firmware image, so the dump itself looks good. From the message headers I deduced that the firmware is likely written at address 0x80008000. I’d be interested in hearing if someone knows what instruction set it is or can make any sense of it.
I did this mostly for fun, as the original topic was interesting to read and felt like a challenge. Even though quite a few years have passed, I hope it is useful to someone who wants to reverse it further. It should not be too hard to get it to a usable state if you have the corresponding hardware. 
Regards
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:
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 
Anyone, let me know if owning the TaHoma is still something of interest.
Regards,
Aldohr
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: https://github.com/Aldohrs/tahoma-jailbreak
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:
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:
So, if you want to get on the train you may want to check:
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!
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
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:
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:
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:
To do that, they are several approaches that can be used:
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
Hello again 
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 - 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
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
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.
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
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.