Tuya 2.0 Firmware

[tsightler]

Describe the bug
I have about 18 generic tuya wall switches/plugs that have always worked just fine with tuyapi, however, a couple of those switches recently received update to 2.0.0 firmware (all others are on 1.0.4 to 1.0.5). After this I can no longer seem to use tuyapi to communicate with these devices, I just get socket error.

I can still use tuya-cli with list-app to get device ID/key, but any attempt to communicate with the devices using this new firmware with the discovered id/key simply fails with "Error from socket" message.

Any chance this is a known compatibility issue or is there any data I can provide that might help isolate the issue further? I'm thinking I may need to try to block these things from Tuya so that they won't get future firmware updates. Either that, or just suck it up and switch them to custom firmware.

[kueblc]

Thanks for the report, I've been aware that an update was coming but the extent of the damage is unknown. This is very helpful for evaluating what has changed.

Was the update elective or did it occur silently?

Are you able to get a copy of the firmware bin? And/or a network capture of an update?

You can block Tuya from pushing further updates if you intercept DNS requests for a.gw.tuyaus.com a.tuyaus.com and a3.tuyaus.com (replace us with eu or cn if you're in EU or China). You can use dnsmasq on your router or home server and configuring your router to use this DNS first. Note this effectively removes any cloud capability.

[tsightler]

I'll admit in this case the update was elective. I was actually working with support to resolve an issue with these two devices due to the fact they were running firmware 1.0.0. However, I was anticipating them pushing 1.0.5, like all of my other devices, not 2.0.0, although the update did resolve my issue, so that's good, but broke my local control, so that's bad. That being said, I have received silent updates previously, from 1.0.2 to 1.0.5, on a few of the devices I've had a while.

I've been hesitant to block connection to Tuya due to the fact that I do make use of the cloud integration with Google Assistant/Alexa, so I'd have to plan an alternative. Not that I can't do that but everything works just fine now so it's becoming motivated enough to want to change all of that automation.

How do you get the firmware bin? I'm assuming there is a tool. Point me there and I'll be happy to grab it. I'll probe at this think over the weekend and see if I can figure out what it's doing.

[kueblc]

Out of curiosity, what was the original issue that 2.0.0 resolved for you?

If you want to keep cloud integration but block firmware updates, it's a little trickier but still possible. You might be able to set up nqinx to proxy requests and filter out via a regex matching upgrade strings in the URL. I also have a utility I wrote for testing that does something like this, I'll work on preparing this for release.

For retrieving the firmware bin, if you have physical access to the ESP microcontroller inside the device, you can connect over serial and use esptool.py to backup the firmware directly. There's plenty of guides to do this, such as on the Espurna and Sonoff-Tasmota wikis.

If you don't want to open your device, you can try capturing the network activity with tcpdump or Wireshark. You'll want to be capturing from somewhere inbetween Tuya and your device, ie your access point or with your network card in monitor mode.

It might be enough to remove the device and re-add it while recording. This should provide us with enough data to simulate an upgrade request without actually performing it. Or if you are planning/willing to actually upgrade another device, that capture would tell us where to find the firmware bin.

[tsightler]

The original issue was pretty minor, I'm regretting it now! With the old firmware the wifi indicator would go out any time the switch was turn on. It was completely inconsistent with the other 16 devices I have, where the wifi light stayed on regardless. There was also a weird presentation of these devices in the Smart Life app. Both issues are now corrected, but losing local control is a bummer for sure.

I'm not sure if I'll be able to grab the firmware if it requires physical access. I'm not unwilling to dig into the hardware, but these are installed home devices that are used on a daily basis.

Getting tcpdump would be more likely, but none of my other devices are showing the firmware upgrade as available. These two devices were "unique" in that they had different virtual IDs. Actually, I have 4 different sets of virtual ID numbering among the 18 devices I have, but these 2 were somehow weird from the start, with the old firmware. I think it was just old stock that I happened to receive from Amazon.

I can play with add/remove and see what I can capture, or maybe I'll order replacements for these two devices and be more willing to play with these two, that's probably the easiest thing to do.

[kueblc]

When you say virtual ID, are you referring to the gwIds?

I understand the difficultly in grabbing firmware from in use devices. Anything you manage to get is certainly appreciated.

[tsightler]

Yeah, just the ID I guess. It's called "Virtual ID" in the Device Information in the Smart Life app.

[tsightler]

So here's a little bit of data I've been able to dig up so far, I know it's not much, but I didn't have a ton of time today. All of the switches with the 1.0.x firmware show connections to Tuya Inc servers on port 1883, which is standard MQTT port. The switches with the 2.0.0 firmware show connections on 8886, which appears to be MQTT over TLS.

[tsightler]

Managed to do just a little more probing. The 2.0 firmware is sending out data on UDP 6667 instead of 6666. Also, it seems the data is encrypted vs the easily visible plaintext. Same seems to be true for the initial handshake on TCP 6668.

I had never really looked at the protocol but it seems to consist of some headers and then some json data portion, which is clear text in the 1.x firmware, but obviously encrypted in the 2.0 firmware, in both the UDP broadcast packets and the TCP handshake. Overall, just comparing the packets sent, and their sizes and headers, the handshake looks about the same so my hope is that maybe it's just encrypting the handshake data with the same cipher method previously used for command data, which should, at least in theory, be easy for me to hack up (it may be beyond my somewhat limited javascript skills, but I think I'm starting to make pretty good sense of the code).

[tsightler]

I've attached a couple of tcpdumps of the Smart Life app talking directly to port 6668 (offline mode) showing the exact same toggle of a switch, one with 1.0.5 firmware and the other with 2.0.0 firmware.

You can clearly see the difference. I tried to use tuyadump to look at the captures but it obviously only works with the 1.0.5 firmware dump. With the dump from the newer device it thinks some commands are clear text, but obviously they are not, but there is a 3.3 in the same place where 3.1 exist so I'm assuming it's a bump in protocol version. Hopefully somebody with more knowledge might be able to make better sense of it.

captures.zip

[kueblc]

Thank you so much for doing some digging on this and providing a capture. This is very helpful! I'll take a look and see what else I can find out.

[kueblc]

This is good data. Now just need to get our hands on a copy of the firmware. Were you able to capture the pairing process?

[tsightler]

Would a capture from my gateway be good enough?

[kueblc]

Yes, that should do it

[tsightler]

OK, I had some challenges capturing on my gateway, but here's a capture from my APs. My phone that I was running the pairing from was on a different AP so it ended up with two separate captures, one for the app and another for the switch. Really didn't see much interesting as it seemed to me that everything was encrypted or HTTPS. I'm wondering if I'll need mitmproxy to see what's going on.
pairing_captures.zip