Tuya Smart type switches - com protocol analysis

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}}

Check this post https://www.letscontrolit.com/forum/viewtopic.php?t=3245

Might be on to something here. The hex codes match the ones sent in the packet for that status message in plain text… so that’s serial over IP. I wonder if i could send a plain text command, i’ll give it a try although the coding for those switches looks different somewhat. Thanks for the pointer Lapatoc

I bought an inexpensive Tuya switch knowing that it didn’t have support in home-assistant because I wanted it for a specific purpose. It costs about half the price of a TP-Link and WeMo switch, so started looking to see if anyone out there was working on integrating it with HA and found the following two repos.


I’m wondering if folks here might be able to take this work and move it forward into a completed HA component.