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/SSLMitm.md at main · Aldohrs/tahoma-jailbreak · GitHub