New PSK format

[countcobolt]

Hi all

I am trying to flash a BSD34 smart socket. I have downloaded the latest tuya master built using git. Working on an RPI 3B. I can connect the socket using the normal smart life app. I did this after I absolutely could not manage to flash it at first (still cant). Decided to dive a bit deeper into it today and found this:

In smarthack-psk.log I have a ton of entries as following

new client on port 443 from 10.42.42.20:53000
ID: 0242416f68626d64366147393149465231509241f729c9f0af3aa41e355b7cbeb1ece63da6ff54b74f271af0ef044466e6
PSK: d9488a1b4524ae3e31acd0342e6d0b2eedbb5d55e957a9a51073b95e36ab1c5c
('could not establish sslpsk socket:', SSLError(1, u'[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:727)'))
new client on port 443 from 10.42.42.20:5371
ID: 0242416f68626d64366147393149465231509241f729c9f0af3aa41e355b7cbeb1ece63da6ff54b74f271af0ef044466e6
PSK: d9488a1b4524ae3e31acd0342e6d0b2eedbb5d55e957a9a51073b95e36ab1c5c
('could not establish sslpsk socket:', SSLError(1, u'[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:727)'))

My smartphone and device are actually connecting to the acces point. In smarthack-wifi.log you see

wlan0: AP-STA-DISCONNECTED ac:57:75:99:f2:9f
wlan0: AP-STA-CONNECTED ac:57:75:99:f2:9f
wlan0: AP-STA-CONNECTED c4:4f:33:bc:10:c6
wlan0: AP-STA-DISCONNECTED ac:57:75:99:f2:9f
wlan0: AP-STA-CONNECTED ac:57:75:99:f2:9f
wlan0: AP-STA-DISCONNECTED ac:57:75:99:f2:9f
wlan0: AP-STA-CONNECTED ac:57:75:99:f2:9f

The AC mac is my smartphone, while the C4 is the actual device I am trying to flash.

The mqtt log remains quite virgin

1578041479: mosquitto version 1.5.7 starting
1578041479: Using default config.
1578041479: Opening ipv4 listen socket on port 1883.
1578041479: Opening ipv6 listen socket on port 1883.

as does the UDP log

Listening for Tuya broadcast on UDP 6666
Listening for encrypted Tuya broadcast on UDP 6667

Smarthack-web.log does not give me more either Listening on 10.42.42.1:80

I have browsed and google for hours now and mostly I find that this might be due to not using the ESP8x chip. Yet funnily enough, when I simply configure them using the smart life app, I see them in my network as ESP_some_ref_number in it. And it does get an IP address.

The socket looks like this

Any clues on why the SSL error shows up? Using openssl 1.1.1d / Python 2.7.16 and 3.7.3

Kind regards Steve

[joshgarde]

I have a SB50 as well, running latest firmware from tuya. What do I need to get this flashed?

If you're okay with potentially ruining the hardware, a soldering iron and a USB serial adapter. If you're looking for a way to do it with tuya-convert, it's likely just a waiting game until someone comes up with a new way to fool the newer firmware into flashing custom fw

[cdk222]

Hi - has anybody be able to progress with this? Do you need any log's for troubleshooting assistance. Anything I can do to assist with this?

Just wondering whether to hold out for an update or return the Arlec LED Strips I was hoping to flash.

[thelefty]

I'm in the same boat with Treatlife and Moes Dimmers/Switches. What's the status and how can I help?

[kevinblo]

Double socket tuya. Board ESP8266 e469716.

smarthack-psk.log:

new client on port 443 from 10.42.42.10:49162                                                                                                                                    
ID: 01f4fd3c0a5dab15ca1e21d1827ca9ba5a0e37d2e7822871213ab7886d38e291245f4cd6aa96736fdb6927d792c5c93163c9                                                                         
Prefix: b'\xf4\xfd<\n]\xab\x15\xca\x1e!\xd1\x82|\xa9\xbaZ'                                                                                                                       
PSK: 5f246e521b7d348f6c8f389943c8458f4fc924160e14e429b56f222b3662d734    

smarthack-web.log:

payload C6CA7FC6A9C2B139530CB0F322AADE49                                                                                                                                         
WARNING: it appears this device does not use an ESP82xx and therefore cannot install ESP based firmware                                                                          
Answer tuya.device.dynamic.config.get                                                                                                                                            
reply {"result":"fn8oBaEAaJe3I+enO7OkYdd0LkD9WHnY6k8vmvctrJbHnfd5h135dVfGL+AxoA0w9F2VBmqNqTqJcWuiX4YubMwnS/rTtk0nNd0LydAf8zW7mevrGF2WUpAllBDW/Q5l","t":1590942752,"sign":"d1a6b65
53ce50b4b"}                                                                                                                                                                      
.[32m[I 200531 09:32:32 web:2246].[m. 200 POST /d.json?a=tuya.device.config.get&et=1&other={"token":"00000000","region":"US"}&t=28&uuid=75a83cd9dad0c419&v=4.1&sign=6e893904a55d3
e390acf838f831cc555 (10.42.42.1) 4.46ms                                                                                                                                          
.[32m[I 200531 09:33:36 web:2246].[m. 302 GET /gw/mtop.common.getTimestamp/* (10.42.42.30) 0.45ms                                                                                
.[32m[I 200531 09:33:36 web:2246].[m. 200 GET / (10.42.42.30) 0.81ms                       

smarthack-udp.log:

Listening for encrypted Tuya broadcast on UDP 6667                                                                                                                               
10.42.42.10 {"ip":"10.42.42.10","gwId":"bf53b793d217e8983azjw4","active":0,"ablilty":0,"encrypt":true,"productKey":"keyymwkvrcstea38","version":"3.3"}                           
WARNING: it appears this device does not use an ESP82xx and therefore cannot install ESP based firmware                                                                          

It is new PSK?

[kueblc]

@kevinblo no, it is not an ESP:

WARNING: it appears this device does not use an ESP82xx and therefore cannot install ESP based firmware                                                                          

[kevinblo]

it is not an ESP

No possible flash?

[kueblc]

@kevinblo no, at least not ESP firmware, like Tasmota, Espurna, etc.

[Fjuxx]

Is there a way to overcome the new PSK format? or does this mean someone very smart need to figure out the new format?

either way, I think I'm back to unscrewing my new tuya curtain switch to flash the firmware the old fashioned way.... too bad that now also the Chinese manufacturers are getting annoying with blocking alternative firmware.

Edit, i'm using a newly ordered SC400W-EU.

I thought i could quickly open it up and solder some wires. I was wrong.... So for now i'm going to use the official app.

there it states that it has the latest fimware and that the MCU and Wifi firmware are at: 1.0.7 if there are other test that i can run that could be usefull, please let me know!

[yardleydobon]

I believe I have a bulb with new firmware. I've got it wired up to a serial adapter. I'm willing to save the factory firmware and capture network traffic of pairing it to the cloud. Would you give me more specific instructions on what exactly you'd like, please? Do you have a link to a guide on how to capture the network traffic?

smarthack-psk.log

[tzwickl]

I ordered the latest Bakibo TP22Y Power Monitoring Plug from Amazon and I have the exact same issue when trying to flash Tasmota with Tuya-Convert:

new client on port 443 from 10.42.42.30:14086
ID: 0242416f68626d643661473931494652314626e61bab0d971476d8b39faab37114c33fa080ec8cfa32438e79c78fc007c6
PSK: f0a8641e94932c4720fcfbf1e3d6495f702d0fbb09c7db240bec9acca59ca8f8
could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1056)

I guess there is nothing else we can do for now? So I guess I will send them back and look out for alternatives :)

[strikernl]

I bought an AOFO Smart Power Strip (ZLD-44EU-W) with 4 sockets and 4 USB ports. Unfortunately it was shipped with a new firmware, smarthack-psk.log shows the DECRYPTION_FAILED_OR_BAD_RECORD_MAC errors. Would it help anyone to get a dump of the installed firmware? It's a hassle to flash it via USB because it has to be disassembled completly.

I have the exact same one. It failed via tuya-convert, so I flashed via serial. Here is the original firmware that I dumped.

If I get some time I'll reflash the original firmware and capture the original pairing process wifi stuff.

Is there anything else I could do to help?

AOFO_ZLD-44EU-W_20200604_image1M.bin.gz

[multicron]

I tried to flash an IR blaster using Tuya Convert, and got the same problem as everyone else. It has a beautiful spot to attach a header, and I've attached a copy of the stock firmware. I noticed a few interesting things in a "strings" of the firmware:

OS SDK ver: 2.0.0(29f7e05) compiled @ Sep 30 2019 11:19:12 [N]%s:%d metedata is without encryption, cover this partition with encrypted data [N]%s:%d var block [%d] last version is without encryption,now need to encrypt data and cover this partition [ERR]%s:%d flash_aes128_ecb_encrypt err [ERR]%s:%d !!!!!!CHIP_MAC:%s FLASH_MAC:%s!!!!!! aes-internal-dec.c aes-internal-enc.c lhttps://a3.tuyacn.com/gw.json https://a3.tuyaeu.com/gw.json https://a3-ueaz.tuyaus.com/gw.json https://a3.tuyaus.com/gw.json {"mac_addr":"500291e8f141","prod_idx":"26636676","auz_key":"wg7xdxUcsi7W0EmnPUlEtuwoyZwcF2W2","pskKey":"GUKgTWzsxGCn8UR5tIFFluuKD2qA8FYmaZwY2","prod_test":false} {"ap_ssid":"SmartLife","ap_pwd":null} {"CC":"CN"} vtrust-flash ESP_E8F141 vtrust-flash

The mac_addr shown does indeed match the MAC address of the chip onboard. I assume "vtrust-flash" is just a record of the last smartconfig SSID received.

Are there notes on how Tuya-Convert works, and what the last PSK update had to do to circumvent the last firmware upgrade? I might be able to help, but I don't want to slog through a bunch of things other people already understand.

firmware-backup.zip

[multicron]

For fun I tried to load the firmware backup onto a Node-MCU-like board, but I got this error:

SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000

V2
Mo
OS SDK ver: 2.0.0(29f7e05) compiled @ Sep 30 2019 11:19:12
rf_cal[0] !=0x05,is 0xFF

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 2592, room 16
tail 0
chksum 0xf3
load 0x3ffe8000, len 764, room 8
tail 4
chksum 0x92
load 0x3ffe82fc, len 676, room 4
tail 0
chksum 0x22
csum 0x22

on the serial port, over and over, at baud rate 74880 (my board has a 26 MHz crystal that screws up the default baud rate). I realize that this is because my 4MB board is looking for the RF Calibration data at the end of 4MB, not 1MB (I had done an "erase_flash" before uploading the firmware). I think the fix is to upload the appropriate esp_init_data_default.bin in the correct place, as detailed in this web page: https://nodemcu.readthedocs.io/en/master/flash/#sdk-init-data

[multicron]

Curious constant (in tuya_tls.c, perhaps?):

00070810: 0074 696d 656f 7574 0073 746f 7000 7475  .timeout.stop.tu
00070820: 7961 5f74 6c73 2e63 0042 416f 6862 6d64  ya_tls.c.BAohbmd
00070830: 3661 4739 3149 4652 3165 566a 6147 3576  6aG91IFR1eVjaG5v
00070840: 6247 3953 4255 7745 7759 4456 4c6e 526a  bG9SBUwEwYDVLnRj
00070850: 6269 356a 6232 3078 4654 4154 424d 4d44  bi5jb20xFTATBMMD
00070860: 436f 7564 4856 5856 4d47 4131 5545 4159  CoudHVXVMGA1UEAY
00070870: 576c 7662 5445 564d 424d 4741 3155 4541  WlvbTEVMBMGA1UEA
00070880: 3530 6458 6c68 5958 4d32 3951 4444 4177  50dXlhYXM29QDDAw
00070890: 714c 5a69 3578 4654 4154 4267 4e56 4241  qLZi5xFTATBgNVBA
000708a0: 4d4d 4456 3559 584e 684c 6d4e 5445 774c  MMDV5YXNhLmNTEwL
000708b0: 4b69 3533 5a62 3230 5242 674e 5642 414d  Ki53Zb20RBgNVBAM
000708c0: 4d43 696f 7564 356a 6232 3078 466a 4167  MCioud5jb20xFjAg
000708d0: 4e56 3559 5331 7062 4d49 494c 4d41 6b47  NV5YS1pbMIILMAkG
000708e0: 4131 5545 4268 4d43 5141 5042 674e 5642  A1UEBhMCQAPBgNVB
000708f0: 4167 4670 4577 4477 5944 5651 5535 5056  AgFpEwDwYDVQU5PV
00070900: 5445 704d 4363 4741 3155 4543 4675 5a33  TEpMCcGA1UECFuZ3
00070910: 706f 6233 5548 5639 7362 3264 3549 5645  pob3UHV9sb2d5IVE
00070920: 5154 4267 4e56 4241 4d4d 4443 6f75 644e  QTBgNVBAMMDCoudN
00070930: 754c 6d4e 7662 5445 424d 3530 6458 6c68  uLmNvbTEBM50dXlh
00070940: 644d 5255 4456 5151 4444 4177 714c 6e52  dMRUDVQQDDAwqLnR
00070950: 3165 356a 6232 3078 4654 4167 4e56 3559  1e5jb20xFTAgNV5Y
00070960: 5770 774c 644b 7272 5672 744c 4941 6d4f  WpwLdKrrVrtLIAmO
00070970: 4663 636c 576a 4d2b 356a 3053 6d53 4235  FcclWjM+5j0SmSB5
00070980: 4670 6e51 6739 6800 7479 5f77 735f 6d6f  FpnQg9h.ty_ws_mo
00070990: 6400 7479 5f77 735f 7061 7274 0074 7579  d.ty_ws_part.tuy

[iracigt]

@multicron I looked into this issue in depth back in February. From what I remember:

I assume "vtrust-flash" is just a record of the last smartconfig SSID received.

Yep! They store WiFi credentials in cleartext in flash. The password is there too, as are the credentials for the last three setup attempts. Good luck clearing your credentials when discarding.

Are there notes on how Tuya-Convert works, and what the last PSK update had to do to circumvent the last firmware upgrade?

I found reading the get_psk(identity) function in scripts/psk-frontend.py to be helpful. I don't know of any documentation other than that, but the last version was pretty simple. There was some fixed random (?) data that was the same for every device. The device did some cryptographic operations on unique data (e.g. MAC address) and sent a "hint" unique to the device to the server. Both the server and the client did some more operations on the hint data and arrived at the PSK (the key used to secure the HTTPS connection).

What changed was before the PSK was derived directly from the hint. Now it seems the key is preprogrammed at the factory, not computed on the device, and no information about it is ever sent to the server. The device sends its unique ID (basically MAC address) and the server figures out (presumably from a database) what the key should be. The device can request the server downgrade to the old authentication, but the server cannot ask the device to downgrade. Since we emulate the server, the downgrade path doesn't help us.

I tried to load the firmware backup onto a Node-MCU-like board, but I got this error

Yeah, they worked pretty hard on that. There a ton of checks and countermeasures to make running the firmware on anything other than the Tuya device very difficult. I'd assume the concern was counterfeit devices mooching off their cloud services. But as a result, getting this firmware running under a debugger is probably a real challenge. I relied on static analysis personally, so I didn't try it. They do many checks against the MAC address and hardware identifiers and each device is given a unique (?) API key, so if one was cloned, they could easily blacklist all of the cloned devices.

Curious constant (in tuya_tls.c, perhaps?)

Yes. It seems Tuya copied the xkcd getRandomNumber function (https://xkcd.com/221/). The "randomness" comes from a small fixed pool (the string you see there). There's a computation I don't fully understand at the beginning, but it effectively memcpys a substring of that pool to use as the random data for the TLS connection. Now I have no background in cryptography, but as far as I can tell, that is not actually exploitable for us because of the pre-shared key.

Rough sketch:

// 0x40274b10 in my firmware
static const char *pool = "BAohbmd...";

// 0x4024c67c in my firmware
int get_random_data(uint32_t unk, uint8_t *dest, uint32_t len)
{
  int iVar1 = ???; // Compute some offset

  uint32_t uVar3 = 0x15e - iVar1;
  if (len < 0x15e - iVar1) {
    uVar3 = len;
  }

  memcpy(dest, pool, uVar3);
  return 0;
}

[finnzz]

Got a pair of 7w RGB CW bulbs (Brand: KHSUIN, BtcLink name also appears on Box) from Amazon in the US. They have the new patch.

They failed to flash with the same PSK description error described in this thread.

[Fjuxx]

@iracigt if I read your reply properly, should we start investigating the Android app instead to figure out how it works? as if they use unique keys there is no way of finding it in the firmware itself.

[kueblc]

Happy to have so many smart people helping to reverse engineer this.

So that we do not spend time repeating efforts, make sure to post your findings here, and to read the entire thread. I have collected my original findings in this comment here. I can add important notes to this as we learn more.

Accordingly, it would be very helpful to refrain from "me too" comments to keep the thread focused on findings. Instead, consider using the :+1: reaction. Please do not take offense if I hide your non-finding related comment.

@Fjuxx we have reversed the app in its entirety, which does provide useful information related to the provision process and cloud communication, however the part we are interested in, the PSK, is between the IoT device and the cloud only. Therefore efforts will be best spent reversing the firmware samples, as we can only glean so much information from the cloud.

[eerorossi]

👍

su 7. kesäk. 2020 klo 18.58 Colin Kuebler notifications@github.com kirjoitti:

Happy to have so many smart people helping to reverse engineer this.

So that we do not spend time repeating efforts, make sure to post your findings here, and to read the entire thread. I have collected my original findings in this comment here https://github.com/ct-Open-Source/tuya-convert/issues/483#issuecomment-577938924. I can add important notes to this as we learn more.

Accordingly, it would be very helpful to refrain from "me too" comments to keep the thread focused on findings. Instead, consider using the 👍 reaction. Please do not take offense if I hide your non-finding related comment.

@Fjuxx https://github.com/Fjuxx we have reversed the app in its entirety, which does provide useful information related to the provision process and cloud communication, however the part we are interested in, the PSK, is between the IoT device and the cloud only. Therefore efforts will be best spent reversing the firmware samples, as we can only glean so much information from the cloud.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ct-Open-Source/tuya-convert/issues/483#issuecomment-640240036, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALA3JYKNC3WOKWKZKKCLHODRVO2LXANCNFSM4KCLJ2RA .

[Fjuxx]

@kueblc ah ok, that is too bad. I hoped that the auth worked without internet instead of with.

I'm planning to open up my curtain switch and flashing it directly. Are there certain tests you would like me to run before flashing tasmota?

And I'm guessing you would like the full backup of the original firmware of the unit?

[kueblc]

@Fjuxx yes, more data is very much appreciated!

You can create a capture of the registration process by connecting both your phone and the device to an AP running tcpdump or WireShark. You can share that here, along with the full backup of your firmware, which may help us to understand how the device derives the PSK.

[alibenpeng]

@kueblc Here are capture and backups for the gosund sp112 gosund_sp112_capture.zip BTW, 10.6.65.214 is the smart plug, in case you were wondering.

[fiservedpi]

Merkary Light Bulb has a new version as well 10.42.42.16 {"ip":"10.42.42.16","gwId":"22885450c44f33b5ed3e","active":2,"ability":0,"mode":0,"encrypt":true,"productKey":"key75ugrk53wuycc","version":"3.3"} as opposed to version 3.1, flashing works on 3.1 but NOT 3.3 Merkaryv3.3.zip

[multicron]

Worried that I might not be able to get more cheap Tasmotized plugs, I ordered a 4-pack of the Gosund WP-6 (a pretty boring 16A smart outlet without any extra features) from Amazon at this link: https://www.amazon.com/gp/product/B07Q2P77JL. I ordered them on 6/8/2020, received on 6/10/2020, and they all flashed fine with Tuya-Convert. So if you're looking to stock up on plugs with older firmware, this particular item seems like a good bet right now, but of course eventually the stock will be replaced with items with the newer firmware.

[cjd]

I'm seeing the same issue now on recent Arlec Grid devices (from Bunnings in Australia) Previously bought ones work without issue - but the last few have all had the PSK issue (only noting this so that others have a heads up for the Arlec devices)

[claymen]

I'm seeing the same issue now on recent Arlec Grid devices (from Bunnings in Australia) Previously bought ones work without issue - but the last few have all had the PSK issue (only noting this so that others have a heads up for the Arlec devices)

Looks like the revised versions are here for quite a few products. Picked up a 6930HA a week ago, no issues, ones stocked this week at the same Bunnings here in Perth need to be manually flashed. Oh well, at least we can still crack them open and directly flash them, seeing a few realtek based devices showing up around now which afaik you can't flash at all.

[madivad]

Confirming I have purchased a number of DETA Grid Connect GPS and light switches. A 4 gang light switch will not flash OTA. I pulled out a 2 gang light switch and it did flash OTA, however, another 2 gang light switch I just tried to do then also fails and it would appear to be the PSK issue. I figure the 2 gang GPO worked being old stock and these other guys have the newer firmware.

If there is anything I can attempt to record, capture, etc, I'd be more than happy to give it a go. Will be trying to manually flash them tonight. Fingers crossed.

OTA FAIL https://www.bunnings.com.au/deta-smart-touch-activated-quad-gang-light-switch-with-grid-connect_p0161015 OTA GOOD https://www.bunnings.com.au/deta-grid-connect-smart-double-touch-power-point_p0098813 OTA FAIL https://www.bunnings.com.au/deta-grid-connect-smart-double-gang-touch-light-switch_p0098812

[mafrosis]

Another small data point from Australia. Successfully flashed two Arlec brand "grid connect" smart plugs (PC190HA), and a 4-port Arlec "grid connect" power board (PB89HA).

Flash failed due to SSL error on two Arlec smart LED lightbulbs (GLD064HA/GLD112HA).

If I can figure out how to run an AP on my linux box so I can tcpdump the pairing process, then I will share.

[astro0302]

Another device that does not flash - bought on Amazon 06/15/2020 - Bakibo TP22Y. No way to open device without destroying.

Error ist also PSK-Key:

new client on port 443 from 10.42.42.36:9925 ID: 0242416f68626d64366147393149465231b03ad7f811ff2750cc16d15763b8add1c3fc9833a31bc52429a01e90dd5966c9 PSK: 7e7f47815c53b77f9c84eb43719f07243fe24f187cd32fc66c26e5afef6e60fd could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1056)

[ja22zz]

Adding another to the list the does not flash Latest version of the Verve Design Hana 36w CCT Ceiling Light (ACL04HA) - purchased from Bunnings Australia 18th June 2020. I haven't cracked it open yet - just watching this thread with anticipation :-)

new client on port 443 from 10.42.42.10:7848 ID: 0242416f68626d643661473931494652311a3fd62f589186485350d7eda90c3579a6f5db056eba1fcd4ff4a0c6c263f29f PSK: 7c7139e4931eb408fcb35eddbbf51ba1165d082a7eb32e779efb44a9fb74ccb1 could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:720)

[rbswift]

Hopefully Bunnings will get so many returns due to the lack of easy tasmota compatibility that they actually do something to fix it!

[meingraham]

@rbswift

Bunnings is selling a device that works as intended. Tuya has upgraded the firmware to plug the hole that Tuya-Convert was using to flash a custom firmware binary. There is nothing Bunnings can do. They have no control over this.

Hopefully the smart hackers contributing to this project can find a workaround for the third time.

[fonix232]

@meingraham I actually don't understand why Tuya blocked this option. They sell hardware, and running their cloud costs resources. Less devices connecting to the cloud means less resources being used, while they still have their main income from selling units. If there was a financial reason to block devices running custom software, I'd understand, but this just makes no sense.

Security-wise it's also a bit stupid - the window to hijack any device being set up is so short that unless someone specifically targets you, it's extremely unlikely that they can do anything. And I doubt many people leave their devices in configuration mode for long periods of time (especially since most devices do not enter into config mode on first boot out of the box).

[meingraham]

@fonix232

Nevertheless, they have patched their firmware twice to block Tuya-Convert. They don't want their firmware being replaced or they believe that having that vulnerability opens them up for poor PR or liability... or... they want you on their cloud even if it does use their resources. Mull on that one for a bit and see if you can come up with different reasons than protecting their company image. OK, that's speculation on my part. But, as you said, it's hard to understand otherwise.

[fonix232]

My guess would be that the actual manufacturers of the devices (Tuya only provides the cloud services, base firmware, and WiFi/BLE modules, apart from a few reference designs) want their products to be only used through the approved methods. Which is understandable.

As for the reverse engineering... I'm fairly certain that Tuya has a database, and the app can query it once the PSK identity is delivered to the phone. They store the required values in a database, allowing easy retrieval (and barely any chance to reverse engineer it, unless the hash algorithm is easy to brute force (and SHA256 is not one of those). Given this, I think our best bet is to RE how the app communicates with the Tuya servers, and copy that method, however that would make Tuya-Convert reliant on a "third party" service that could stop working at any moment.

Well, I guess this is the end of having nice IoT devices without cloud connections. I really hope this whole "cloud smart home" fad dies sooner than later, as these cloud connections are precisely what cause security issues.

[meingraham]

TBH, I'm not sure what happens once one goes through the Tuya device design creation wizard as far as the manufacturing step. Based on the similarity of a lot of the devices even with different brands, there's probably a third party manufacturer as well.

There is a TuyAPI and a server implementation which allows one to "mimic" the Tuya cloud on a local server (e.g., Raspberry Pi). This still relies on the Tuya protocols and doesn't give the ability for enhanced features or MQTT, etc. My preference has been to replace the firmware.

Tuya-Convert definitely made that very easy. And in some cases, it is the only method since some devices are sealed to the point that getting to the ESP chip is impossible without destroying the device. However, there are still several Tuya-based devices that one can open up and get to the serial flashing contacts. This then is an alternative method of getting custom firmware onto the device. So, the options are to find a device with an older version of the Tuya firmware to purchase, or purchase a device that can be disassembled "easily" and flash it via the serial interface (Tuya-based or otherwise). It is this latter category that Tuya cannot control (other than encasing the internals in Tungsten :wink:).

[strikernl]

Maybe it's an idea to move this meta discussion about the merits of Tuya attempting to prevent custom firmware elsewhere?

[meingraham]

I was thinking the same...

[joconcepts]

Another device that does not flash - bought on Amazon 06/15/2020 - Bakibo TP22Y. No way to open device without destroying.

Error ist also PSK-Key:

new client on port 443 from 10.42.42.36:9925 ID: 0242416f68626d64366147393149465231b03ad7f811ff2750cc16d15763b8add1c3fc9833a31bc52429a01e90dd5966c9 PSK: 7e7f47815c53b77f9c84eb43719f07243fe24f187cd32fc66c26e5afef6e60fd could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1056)

I have bought the same sockets and get this message:

ID: 0242416f68626d64366147393149465231d40c3ee10f67ee0e4a644b28856f1e48aea994d4380892ad0e18a5f5322c653b PSK: edf6fadce61393db971672f651a0c5107fd427f6ff43de86cfde18dd5c525dc2 could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1056)

[joshgarde]

Just as a quick aside: tuya-convert was partially created as a way to demonstrate how vulnerable Tuya's software was in the early days and to encourage them to do better. In a way, tuya-convert accomplished it's goal: to get Tuya to fix their security. It's just that tuya-convert has grown to become so much more than a security demo https://www.heise.de/ct/artikel/Tuya-Convert-Escaping-the-IoT-Cloud-no-solder-needed-4284830.html

[joconcepts]

Is there still a chance to get the tuya-convert again working with newer tuya firmware?

[towo]

Can also confirm an AOFO 4AC-4USB coming with the new PSK; I can provide PCAP dumps on request.

[Ercenk]

Potentially ran into the same issue with following bulbs I received today.

https://www.amazon.com/gp/product/B07HR8GT12/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

[Newms118]

Jumping in here, having the same issue trying to flash a teckin bulb:

new client on port 443 from 10.42.42.39:19554 ID: 0242416f68626d64366147393149465231d3506ef81084feccf0aa3702b04d51cfdee843daf13333b64f7$ PSK: 7bbe775075fb728edb29da9dd156dcd7c0f1600d8881ed1568b7ddbb32ee51df could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption $ new client on port 443 from 10.42.42.39:6132 ID: 0242416f68626d64366147393149465231d3506ef81084feccf0aa3702b04d51cfdee843daf13333b64f7$ PSK: 7bbe775075fb728edb29da9dd156dcd7c0f1600d8881ed1568b7ddbb32ee51df could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption $ new client on port 443 from 10.42.42.39:10834 ID: 0242416f68626d64366147393149465231d3506ef81084feccf0aa3702b04d51cfdee843daf13333b64f7$ PSK: 7bbe775075fb728edb29da9dd156dcd7c0f1600d8881ed1568b7ddbb32ee51df could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption $ new client on port 443 from 10.42.42.39:9248 ID: 0242416f68626d64366147393149465231d3506ef81084feccf0aa3702b04d51cfdee843daf13333b64f7$ PSK: 7bbe775075fb728edb29da9dd156dcd7c0f1600d8881ed1568b7ddbb32ee51df could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption $ new client on port 443 from 10.42.42.39:2054 ID: 0242416f68626d64366147393149465231d3506ef81084feccf0aa3702b04d51cfdee843daf13333b64f7$ PSK: 7bbe775075fb728edb29da9dd156dcd7c0f1600d8881ed1568b7ddbb32ee51df

Anyone have a clue how to get around this?

[H4R0]

Please stop posting other products that fail to flash, the problem is known and the community is working on it. You are not helping by posting logs. If you got network captures or firmware dumps thats another topic, but we have plenty to work with already.

Subscribe to get notified for updates instead, thanks.

[GeWado]

Gosund WB4 bulb, I got the firmware before and after installation. And I took the traffic during configuaration. I hope this ist helful. gosund-WB4.zip

[ptz0n]

I got the Deltaco Smart Plug SH-P01E and obviously running into the same issues.

Happy to help out! Is there any pointers for how to open the device without totally messing up the body?

[eerorossi]

There is a small oval shaped lid between the connectors. Remove it and you find two screws.

ma 29. kesäk. 2020 klo 11.45 Erik Eng notifications@github.com kirjoitti:

I got the Deltaco Smart Plug SH-P01E and obviously running into the same issues.

Happy to help out! Is there any pointers for how to open the device without totally messing up the body?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ct-Open-Source/tuya-convert/issues/483#issuecomment-651022074, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALA3JYIEMSIDKLFEM6VGM7LRZBIB5ANCNFSM4KCLJ2RA .

[ptz0n]

Well, this device was actually quite accessible. I used a sharp knife to slide out the oval plug and there was the screws. No prying needed once the screws was removed.

Serial adapter has been ordered and I will hopefully be able to snap that new firmware in a few days.

Thanks again for the guidance.

[andrewkriley]

Also seeing this for Deta Grid Connect Smart QUAD light switch https://www.bunnings.com.au/deta-grid-connect-smart-quad-gang-touch-light-switch_p0161015

new client on port 443 from 10.42.42.28:29365 ID: 0242416f68626d643661473931494652311e16bd7ee50c481d54998566b0a1fa565fa96856e6e3f97210c0d7993fc928f4 PSK: 20c8120f292b40e85a9f753224cb54c029a8e4837ca636e8594f7985eb5b2e84 could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1056)

I previously did the Double light switch successfully. Seems a change in firmware.