I have been trying to reverse the com protocol for the Tuya based switches. They are unexpectedly secured for most part but with a packet capture app with MiTM i was able to capture quite a few bits of data. The devices support both HTTPS and MQTT. There is an open API doc and demo on github, although the English (written by non-native speaker) of it is confusing and some examples don’t use actual data which can lead to a lot of wasted time.
If anyone is actively looking into this and has some experience in patter and crypto analysis we might just be able to reverse what i call the skinny-MQTT that device and app use when offline. The traffic is mostly non-SSL, except when the app grabs device info (local key) from the server , which i also got. With that i was able to produce same sign hash for the MQTT message according to API docs, but i am unable to decrypt the AES data payload.
The more interesting are the offline packets. The app will query the switch in plain text with this message
{“devId”:“002006615ccf7fe01925”,“gwId”:“002006615ccf7fe01925”}
to which the switch replies with
{“devId”:“002006615ccf7fe01925”,“dps”:{“1”:true,“11”:0}
I was been able to reproduce this by sending the original packet including the non-printable parts of it
The part that comes after it is a bit tricky - for instance here is a turn off payload
3.130decb2c55f32c88s/eLH9AuBByvayZpQ+vfk7vvfMnv8UqZatTcbjwnjP8Jm50eAmN6uajpiewwYQ0Vk/Id7QpPLe5GIM7N+RtGvm+43f6eX9gbCZBgxkvRS63bx7WQLkSZpvVdrVzQYcvb
From what i can gather the 3.1 is protocol designation, next 16 is the signature (most likley middle 16 bits from and MD5, this is something that is used with MQTT as well) and the starting with “s/e…” encrypted payload. What is interesting here is the pattern that emerges compared to the another off message
3.1e12a10804e056426s/eLH9AuBByvayZpQ+vfk7vvfMnv8UqZatTcbjwnjP8Jm50eAmN6uajpiewwYQ0VE6qSmVXrm1fxcY2ywnGanW+43f6eX9gbCZBgxkvRS63bx7WQLkSZpvVdrVzQYcvb
Most of the payload is identical, and the difference most likely account for the timestamp that looking at API has to be there (epoch time). However if the encryption was uniform for the full command string, it would produce widely different results. The replies from device contain similar pattern (in fact all messages have the first 64 characters after hash sign, and on and off messages also have respectively identical endings
This looked like base64 but alas it did not turn out to be so. My knowledge with encryption is limited and i have hit a dead end so if anyone has any ideas. I am almost certain that the message looks something like this
{“devId”:“002006615ccf7fe01925”,“t”:"1506367627,“dps”:{“1”:true}}