Hello @woodster
according to the symbols on the remote it’s a one-way remote. I have no other remote for the rollershutters than this one (and the Somfy Tahoma Box).
Seems I’m not gonna have luck with this. I’ve spent hours now trying all different buttons and also put the rollershutters into pairing mode (4.6. Hinzufügen/Löschen eines Smoove 1) and no lock 
That’s frustrating after it took me such a long time to get a KLF200. Still thanks for your help here guys.
Hi,
If it is IO Homecontrol compatible then it must work.
I think the motor must be in config mode for doing the pair from a oneway remote.
Have you tried to do the 7.3 step?
I have only put it in pairing mode as described in 4.6 - I haven’t yet been able to try 7.3 as I have no direct access to the motor wires and will have to disassemble the rollershutter stuff above the window (hopefully tomorrow). That’s my last hope as the “normal” pairing hasn’t worked (at least if I did the right thing on KLF200).
When trying to do the pair I select “Search for Products” in KLF and then press the Somfy switch up (or some other position). Correct? If I reset the rollershutter as explained in 7.3 does it mean the KLF pairs with it? I understand the KLF needs a paired switch and not an unpaired actor?
No, the remote is not used for pairing when using the KLF.
I think you accidently re pair to the remote when pressing on the buttons.
Try to reset as mentioned. Then DONT press the remote. Mind there might be a time slot where the motor is open for pairing.
I will try it. Thanks for your help. Will report back.
If you can reset the motor completely you should be able to do the ‘search for new product’ only.
Good luck
Hi guys,
I somehow managed to pull the firmware from the Somfy TaHoma box. I am currently reverse engineering it. As the io-homecontrol daemon is binary, this will take some time. If by any chance someone here has some knowledge and experience with ARM reverse engineering, I will be happy to discuss it.
I’m also looking for a TaHoma rooting procedure which does not involve hardware approach. The idea is to change the destination of the cloud requests to allow the use of a self-hosted sink server.
I’m at the beginning of the analysis and I don’t know if I will be successful or not but I will keep you up to date if someone is still interested in having a protocol specification.
If someone wants to help, I’m open to discuss the details privately.
I’d be interested even in the hardware approach. Could you give me some hints how you got access to the box?
Honestly, the avalaibility of the Somfy servers sucks very very much. I even thought about DNS poisoning on my router so I could override the API endpoint addresses 
The only part which I am not really sure about is whether they use proper certificate pinning (which they should do to ensure real secrecy).
I’d be interested even in the hardware approach. Could you give me some hints how you got access to the box?
Quite a tiedous journey. The hardware attack consists in desoldering the flash memory and directly reading it. As it is not encrypted, it is possible to dump the entire firmware. But this is far too complicated to be used in casual jailbreak, hence the research of an access to the system console via the network.
I tried DNS poisoning 
The fact is that Overkiz (the Somfy subsidy designing the TaHoma) did a really neat job: they are using an embedded custom CA (with their own trust store) to authenticate the server as well as a client certificate unique to each TaHoma box to authenticate the boxes against the update and the cloud servers.
I’m still making progress in the reverse engineering and I’m starting to have some hints of the protocol specification. It will take at least some months to achieve though.
Hi there!
I’m currently researching solutions on how to use openhab with the io-homecontrol protocol. The finished system should be able to control io-homecontrol blinds and read from an io-homecontrol anemometer and sunmeter.
So far I’ve found these and I’d love if someone could confirm them:
For 1) internet connection seems to be mandatory, since the somfy tahoma binding just logs into the web service of somfy to send commands to the blinds.
For 2) there seems to be no mandatory internet connection, which I is a big plus.
Are there ways to directly communicate with io-homecontrol devices via openhab? I figure not, because transmitting commands to the devices are sent on radio-frequencies. Therefore needing something like the KLF 200.
Are there any other ways to control io-homecontrol devices via openhab?
Cheers
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