Automatically aquire needed parameters about tuyapi

[codetheweb]

@pfeiffee
I added some instructions here. Let me know if things work out.

[codetheweb]

Sorry about that, I should make the docs more clear. All the parameters can be sniffed in plaintext (at least, plaintext once the HTTPS traffic is decrypted) during the initial setup of the device. Try removing the device from your app then adding it again while sniffing. If you set up Charles’ certificate correctly on your phone, it should decrypt HTTPS traffic automagically. Note: uid and key are called uuid and localKey respectively in the official API.

…

On Oct 28, 2017, at 5:56 PM, pfeiffee ***@***.***> wrote: I am able to get all the info I outlined in this post: python-tuya/python-tuya#1 (comment) Yet still have no idea where to find the UID and KEY values. I tried to use the Charles app and had my phone send all traffic through a socks 5 proxy to Charles and I'm still not seeing the local key or uid values. Maybe the first json string is unencrypted getStatus. I want to say that my ssl cert reversing things just arn't working on this. How did you go about de-ssl-ing the packets? Here is a sample of a turn on and off on the port 6668: ..U..............WA=...U..U..................Q.....U..U........ ...F{"devId":"002009262c3ae817e19a","gwId":"002009262c3ae817e19a"}.%.}...U..U........ ...Y....{"devId":"002009262c3ae817e19a","dps":{"1":false,"2":0,"4":0,"5":0,"6":1231}}m..u...U..U.............3.137ed7a48ff271e52PZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrH+Cke6uc2p1Ffl2AYvLF2rJ/ngc/EJeIXiGOrY9vFbniEA7LmOkCK66N6cb80iql2E6CfiCza+ivc2mlfUf/R6#..+...U..U.................x.p....U..U.................3.18cc58581a5d5a855PZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrExYLyT9xR3tTqTGAN2CNEnUVALV5jheBKxuaLpNTjRUjLaZ1j+jBoZrAxZ3zcs680=.w.....U..U.............3.13e5530644a4a031bPZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrHZfccCsWIkuo2QNShDjqQTc3M4KsH/I2MnjRbt/S9QjCEA7LmOkCK66N6cb80iql2E6CfiCza+ivc2mlfUf/R6..V....U..U.................x.p....U..U.................3.193b1f16eed69c377PZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrGWjcMctZYp4nF91mDoV1IAimI/NF3StveQCtVjcSl9SrP68joOZ7crLpwap1yx6Yg=%..c...U..U.............3.1dc00201b701beaebPZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrH1KeS3CuQ4u4P1rw/XcyzgLp2Aku7lI6waA1S7B9BFOpQwKyaho9oabVmurTqLWf0eXxemklZskZ2kBFPM0jP0-......U..U.................x.p....U..U.................3.1fc9bdc270429fa20PZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrH1KeS3CuQ4u4P1rw/XcyzgiI7p9y6Lbv2lzwUJxWzM96kcavlH4f0O206Ug9wDxr0=.an....U..U..............WA=...U..U..................Q.....U..U.................3.1f7999523619c1b0fPZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrEMvogScDF7HlUxg8PL+6kEFSeJWX5zoexl2+xqyc4q+52ImmB+2QokNliV3Z0xKcS2+FDD7CoX+maVSU6uu+SX..F....U..U.............3.18daa6bfa06b70c03PZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrH+Cke6uc2p1Ffl2AYvLF2r7ngm4iiyI4XOoMcDODAPoiEA7LmOkCK66N6cb80iql2E6CfiCza+ivc2mlfUf/R6.......U..U.................x.p....U..U.................3.1827be0aa4d4fe1c1PZq9YjgtkdqtS8Iw4vKCwi7AJ2Vr3dvbNaio1F9WYrExYLyT9xR3tTqTGAN2CNEnnDaemapmVsqahVhvk7lmTcDtRNjY/DkG+XjLCooic0k=.&r....U — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pfeiffee]

Those instructions were excellent! Interestingly - my issue was Android N no longer supports universal app proxying and I haven't been able to find a single rooted solution yet. I followed your instructions with my old iPhone and I was able to get the uuid and localKey.

For anyone else reading this post:
More research needs to be done but it turns out if you do a cURL request to this url:

https://a1.tuyaus.com/api.json?timeZoneId=America/New_York&sdkVersion=1.15.0&a=s.m.dev.list.group.list&time=1509672781&appRnVersion=2.9&platform=iPhone5(GSM)&os=IOS&osSystem=9.0.2&appVersion=2.7.1&clientId=9af5
sjusduysghbseukpn&lang=en-US&ttid=sdk_appstore@7ysfe7eh7sdf7hsdfh7sdf&sid=az15074sd7sd7hs7dfg339947530bf83920c17ab341ab0c9&deviceId=72AMSNSNSN5-FF10-4SSS-B5F3-FB4FC483B&sign=8006SNSHSDSDJ20c56f009d&v=2.0&

[some characters swapped out for security]

You can get a real-time update of all your devices and their keys - no Charles or sniffing app required. I'm already working on a PHP webpage that can display my device info.

However, I have no idea how to get those values without doing an initial sniff. (there's gotta be a way!) We need to find out how to make this easy so more people can do this.

[codetheweb]

Right.

Honestly, I feel like accessing the API directly is probably going to be out of our reach, as you need a API key and all sorts of other messy stuff. I was also looking at somehow starting mitmproxy from a setup script and filtering the output to display the needed params.

[pfeiffee]

Update: Just had my first successful light on/off toggle with your library!

Now we need a way to automatically harvest the IPs of the devices on the network and match them up to the UIDs. Since the auth codes are not needed to get device status which has the UID, maybe doing a dirty -loop through all 255 sub IPs- and probe everyone with a getStatus?

Confusion avoidence question/suggestion:
var tuya = new TuyaDevice({
type : 'outlet',
ip : '192.168.1.180',
id : 'XXXX', // will this always = uid?
uid : 'XXXX', // do we need to keep id if uid=id?
key : 'ZZZZ'
});

[codetheweb]

Congratulations!

Yeah, I didn't realize until now that the uid is redundant. However, we can't just straight-up remove it because it appears the device expects a TCP request of a certain length. @blackrozes was working on this, I'm not sure where they're at.

Honestly, looping through all IPs feels pretty hacky (but I don't have a better suggestion at the moment).

[AALMA]

@pfeiffee Is this a problem with iOS as well?

I first didn't realize I had to enable SSL Proxying in Charles so the first time time I tried it I was only getting CONNECT requests logged, no POST request for Tuya.

Then I enabled ssl proxying in Charles and installed the Charles certificate in iOS following the directions on their site and now the Tuya app seems unable to connect to their server. If I disable proxy on iOS it works again though.

Do you know if iOS 11 is unable to use installed certificates for App traffic? If so, any idea what I can do for a work around? I think all the devices I have are on iOS 11.

Edit:
Found a solution here:
https://www.neglectedpotential.com/2017/04/trusting-custom-root-certificates-on-ios-10-3/

You have to go to Settings > General > About > Certificate Trust Testings and enable the certificate there as well.

[codetheweb]

@AALMA glad you got it figured out :).

[WRH2000]

Sorry for the newbie question, but I have one of these devices and would like to block it from communicating with the Tuya servers/cloud and just control it on my local lan...Does this project do that? Can I just run the script on a local webserver and still control the device? One of the other things that would be useful is to set rules, ie 15 minutes before sunset turn device on

[codetheweb]

@WRH2000
If you want to completely block the device from phoning home, you'd have to create firewall rules at the router level. But this project does enable local control of devices, without any server in between.

To use rules as triggers, you'd have to write a custom script. Specifically, if you want to turn on a device before sunset, check this module out.

[WRH2000]

@codetheweb Awesome, thanks! I tried to block the 6668 port via the firewall/router and see if I could still use them but they go offline...I'm guessing this is similar to a MQTT broker/node setup and they are communicating back to the Tuya servers for instructions vs. getting the info directly from your phone app? Look forward to trying your api to see if I can keep everything local.

Has anyone done a tear down on one of these plugs? What chipset does it use? Esp8266? Possible to reflash the firmware?

[codetheweb]

@WRH2000 I believe they only communicate over TCP 6668 locally, when calling home I think they use HTTP/HTTPS (80/443), which would have to be blocked on a device-by-device basis (a blanket block of 80/443 for all devices in your house would be bad).

It is based on a ESP8266 (or maybe a ESP32). It's possible to reflash the firmware, and many others have done it on similar outlets.

[joshskidmore]

@pfeiffee - Your comment about working with the API led me to some researching. The Tuya API is generously documented and you can even create a developer account for free.

The problem that would prevent this library from directly connecting to the API (instead of MITM/Charles) is the need for the hardware company-specific devId which is required to sign API requests. I'm not even sure that these devIds are directly passed over the wire. Based on who manufactured the hardware, each would be different. (The Tuya concept is to provide hardware manufacturers an easy, white-labeled API.)

If the devIds are being passed somewhere over the wire (either using the API/HTTPS or MQTT protocol), we might be able to maintain a list of known company devIds here, but I'm unsure of the legalities?

I'm going to purchase a couple more devices and mess around some more tonight. It would be great to add some utility helpers to allow a user of this library to just pass login credentials (of their device manufacturers app) and receive a list of devices and their parameters. Their API also allows for other, remote calls and historical data which could also be useful for someone trying to create something with this library. My personal use is to use this library to create a nodejs utility to capture the plug's energy usage data, but still use the device manufacturer's app to actually control the socket.

[fusionedv]

I have 3 devices (bulbs) and I think the logic behind the devIds in my case is: The last 12 characters are the MAC-adress. And one or to bevore are the device-type. I got 2 white bulbs and one rgbw bulb. The rgb has the number 6 and the two white one have a 3

0120000[dev-type][mac]
0120000[3][1c1c1c1c1c1c]
012000031c1c1c1c1c1c

I am not sure but I think a secretKey, given by Tuya, also is necessary to sign and encrypt the request from local to toya cloud. see https://docs.tuya.com/en/cloudapi/cloud_access.html#http-https-connection-method
As I understand this, tuya provides this key to the manufacturers.

[codetheweb]

@joshskidmore you're correct on almost all accounts. However, Tuya also gives developers an app key, which does not look easy for hobbyists to obtain (right @blackrozes). For anyone else wanting to look into this, the official docs can be found here.

@blackrozes that's really interesting, good catch. Mine seems to be in the format 00200465[mac], so I'm not sure what to make of that. Maybe 00200465 is the device's type?

If anyone else has already found their device's devId, please add it here. Let's try to gather some data and see if there's a pattern.

[joshskidmore]

Question (kind of related to this): If you have a generically branded plug that uses Tuya, but has their own app (eg Greeni, Jinvoo Smart), are you able to just use the Tuya Smart app instead?

I'm looking to buy a few more of these off Amazon and from shared screenshots of the generic apps, it looks like an identical app template provided by Tuya.

I'm hesistent to buy one that requires a generic app just in case that company goes out of business and doesn't maintain the app.

If you can register generic devices with the Tuya app, I would then be curious as to if we were able to somehow (legally) aquire a developer key from Tuya, if we could then just register Greenli, Voion, [CHEAP AMAZON RIPOFF] plugs to an account with proper API access. I'm not hopeful for this because I imagine that the generic hardware vendor pays Tuya licensing fees to use the service.

Apologies in advance if this was an inappropriate place to ask. I just assume that the watch was of this are probably intimately technically familiar with Tuya, haha!

[codetheweb]

It looks like you can. In fact, since branded apps require you to make an account with Tuya, you should be able to go from several branded apps to using just the Tuya Smart app as long as you use the same login on everything.

[AthruC]

New here with some questions and hoping to offer some additional thoughts.

I picked one of these smart plugs up recently (re-branded) with similar hopes and was sent to this thread. Ideally I'd want to be able to control these devices with a command sent from a web browser.
Also as an FYI, I have been going back/forth with the manufacturer and allegedly there is a Zigbee antenna built in that is currently disabled, for whatever that is worth.

I added my uuid scheme to the list. The leading numbers vary slightly so I noted the manufacturer and market that I purchased these plugs from/for. I suspect that there may be a difference based on those criteria. To mention, they are the small round plugs as well. I notice that there are a number of different plug styles available for different markets and maybe that info should be added to the spreadsheet as well?

Also to note, their API ties directly to Alexa and Google so there may be an alternate back door that's not being considered?

[codetheweb]

@pfeiffee @AALMA @WRH2000 @joshskidmore @blackrozes:

After a (very) deep dive into the internals of NodeJS' net module, this now reuses the client object between connections. Try it out and let me know if it seems more stable.

[fusionedv]

I found out after some deep testing with the stability, that it is important to send keep alive pings to the device. In my case eath 15 secounds is working very well. Since I found out this, my bulbs working 100% stable for at least 2 weeks. The keep alive command is just the "getStatus" command.
Perhaps someone could test this. e.g.

var checkTuya = setInterval(function(){ 
    tuya.getStatus(function(error, status) {
      if (error) { return console.log(error); }
      console.log('New status: ' + status);
    });
}, 15000);

[codetheweb]

I turned on Node's built-in keepAlive functionality in the underlying socket that this uses. @blackrozes if you have time, please try it out and see if it provides similar stability to calling getStatus.

[clach04]

@codetheweb I've added 2 devices to the spreadsheet. I've not yet had chance to try tuyapi with it. So far I'm using the jinvoo app (https://play.google.com/store/apps/details?id=com.xenon.jinvoo) to register and lookup the device id (and Amazon Alexa to actually control it).

The name on the network for my devices is ESP_last_three_bytes_of_mac. Looking at the FCC internal photos confirms its an ESP8266MOD device (see
https://apps.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=Y&application_id=6pPi3ddGo42B1Wg9IxSXTw%3D%3D&fcc_id=2AJ5F-SM-PW701U and then click on "Internal Photos"). I'd prefer to use the builtin firmware than flash it to take control so I'm pleased to see progress with this project.

[codetheweb]

Moving conversation to #5.

[nishanthhegde]

Update: Just had my first successful light on/off toggle with your library!

Now we need a way to automatically harvest the IPs of the devices on the network and match them up to the UIDs. Since the auth codes are not needed to get device status which has the UID, maybe doing a dirty -loop through all 255 sub IPs- and probe everyone with a getStatus?

Confusion avoidence question/suggestion:
var tuya = new TuyaDevice({
type : 'outlet',
ip : '192.168.1.180',
id : 'XXXX', // will this always = uid?
uid : 'XXXX', // do we need to keep id if uid=id?
key : 'ZZZZ'
});

how did u get the key & id pair?

[kueblc]

@nishanthhegde Take a second to look, step by step instructions have already been provided.