io-homecontrol / Protokollanalyse

[plin]

Hi,

Ich habe soeben einen Beitrag in einem anderen Forum (https://community.openhab.org/t/io-homecontrol-velux-somethings-in-the-bush/11413/223) gefunden:

"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 5
The sample data is from the packet logs posted long ago by leutholl and others. ( https://groups.google.com/forum/#!category-topic/openhab/AinJdyyDtG0 5 ) 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. 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."

Da ich immer noch eine kostengünstigere Lösung als eine KLF200 suche: Lässt sich aus obigem Ansatz etwas machen, so dass ich meine Velux SSL aus FHEM heraus ansteuern kann?

VG plin