New PSK format
countcobolt opened this issue · comments
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
Runs on fw 1.1.4 in smarlife app
Have the same issue.ssl 1.1.1d and python 2 and 3 .have to flash with soldering. Esp chip is mounted.
For to open the smart plug you have to eat first Southtirolean Speckknödl
Just wondering did you just pull really hard on it or what is the trick to open it? Turn? Worried to break them
moved a screwdriver into one hole and then leveraged.nothing breaks
A few more stupid questions :
1: did you solder on the bottom or on the dots?
2: did you connect the gnd to reset?
3: which tasmota did you put on it?
Thanks a lot in advance :)
2 screws in total.hav no usb serial programmer here.its on the way ... only ioo to ground .the rest on grenn pcb .from right to left.....3.3 gnd......
Hi @countcobolt and @rsbob, it looks like you may have discovered a new version of the Tuya firmware. The PSK identity in your psk log does not have the expected prefix, which explains why the calculation is failing.
If you are flashing by wire, could you please make a backup of the stock firmware? We can use this to further debug and possibly develop a new workaround.
@kueblc
Ok I have it open and will try tomorrow morning. A few stupid questions (I am on Linux or Mac) do you have some tutorials on how to download the existing firmware?
Kind regards
Once you have it installed you can use something like:
esptool.py read_flash 0 0x100000 firmware-backup.bin
flashed now ...
esptool.py --port /dev/ttyS0 flash_id
esptool.py --port /dev/ttyS0 read_flash 0x00000 0x100000 image1M.bin
esptool.py --port /dev/ttyS0 erase_flash
esptool.py --port /dev/ttyS0 write_flash -fs 1MB -fm dout 0x0 tasmota-DE.bin
#
@kueblc
Here the orig.FW
BSD34--image1M.zip
@rsbob which. pin did you connect the GPIO0 on? I have CW, R and then 00 in one line (or similar (can't really read it properly on them)) Thanks
Steve
gpi0 (esp pcb side soldered to ground ,then give voltage and run commans )Green pcb . 3,3 volt Gnd rx tx on the main platine side . yellow cable to the the blue ones.see foto.
i think its printed IO
@rsbob hey, I know I need to connect GPIO0 to the ground, but that is the problem: which one is GPIO0 on the PCB? The printing on my PCB is really bad, so cannot read it (literally :) )
😂You se IO on blue board near 3,3 volt and grount lines?but if you can wait wait a hour i add a foto.
the left from Rx .the one without trace market OO
just one thing: using the template on https://github.com/blakadder/templates/blob/master/_templates/BSD34 the led is not working, toggle etc is working as expected
secondly , wondering how to enable the power metering ==> Sorry noticed it doesn't have that feature... Stupid me
I get the same sslpsk errors in smarthack-psk.log though slightliy different ID:
ID: 0242416f68626d643661473931494652315ee70ad6ee67338a4f486a0750cfc89d52ee6a3be1727dcaa5eef3054e2165f5
PSK: 2b25c3013c2186c23697c1cc752161c039d1672c36b3d7e6df51c4f43b87586a
('could not establish sslpsk socket:', SSLError(1, u'[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:727)'))
The device is a Deltaco SH-P01E socket with power monitoring.
smarthack-wifi.log with my Huawei phone and smart plug connected:
...
wlx90f652e46df6: AP-ENABLED
wlx90f652e46df6: AP-STA-CONNECTED 30:45:96:1d:86:56
wlx90f652e46df6: AP-STA-CONNECTED d8:f1:5b:8b:34:59
Would be nice to be able to use tuya-convert since I don't know how to take the plug apart without damaging it.
any backup of old smartlife fw for me😂bsd34
If anyone is interested, here's the firmware from my Deltaco SH-P01E plug.
Deltaco_SH-P01E_20200110_image1M.zip
The firmware is the latest up until Jan 10th 2020.
Took some time on this today. Unfortunately these latest firmware builds seem to have changed a number of things making this a non-trivial fix.
- firmware OS SDK version did not change, but the hash and build time did
OS SDK ver: 2.0.0(e8c5810) compiled @ Jan 25 2019 14:26:04
OS SDK ver: 2.0.0(29f7e05) compiled @ Sep 30 2019 11:19:12
- interesting that this build date corresponds with the release of tuya-convert 2.0, coincidence?
- psk begins with
02
rather than01
- guessing this will tell us the psk algorithm version
- disabled most of the serial debugging output
- unfortunate as this was a useful reverse engineering resource
- did not respond to our
smartconfig
procedure- it may use a new mechanism or additional restrictions have been imposed
- MAC address in flash appears to be compared with actual device MAC
- likely to foil reverse engineering attempts by running firmware on a dev board
- new factory written key found in flash,
"pskKey"
- this may mean the encryption key will no longer be derived deterministically, big bummer
- only found in @rsbob's backup, looks like @Farfar's was updated to this firmware and thus lacks this factory written key
- this may mean there is still hope for devices that came with a lower firmware, since updating to this firmware would require fetching the key
- this is a very interesting new endpoint:
tuya.device.uuid.pskkey.get
Thus the cat and mouse game with Tuya continues.
If anyone is able to capture network traffic from one of these devices pairing with the cloud, along with the corresponding firmware backup, this would be instrumental in reverse engineering efforts
If anyone finds a US variant of this I would be happy to get a couple sacrificial units and give it a go.
@kueblc If you are interested to analyse the traffic, you could probably use the bulb sold in a big online store as "bakibo smart wlan led". I have the same issue with it. It shows could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:720)
.
@AlexBV mine is a Bakibo TB95 with the same problem.
@AIexBV It would be great for anyone wishing to contribute, who has the ability to disassemble/backup the original FW before doing anything and then another backup after trying TC.
Logs are good too!! We're going to need to sacrifice (anyone in the community who is willing/able) to sacrifice some modules to play this game of Cat & Mouse
Tollbringer
@Tollbringer I already tried to open the bulb. But I do not have access to good tools, so unfortunately I damaged the chips. But maybe the log entries will help. I got many lines like this:
new client on port 443 from 10.42.42.11:63510 ID: 0242416f68626d643661473931494652318f1af4a8c59aa2df416796cf6c3509959021a9fc70c1265ab969a0c21765060a PSK: cae5783da388990f138996dc22b9b50e3c155cc50fdd80401e8e27db0a2d58c5 could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:720)
@kueblc please find attached a tcpdump of the communication: bakibo_bulp_pcap.zip
Hey guys, I think I'm in an even worse situation, when trying tuya-convert
from within docker I get a wall of these:
new client on port 443 from 10.42.42.31:37666
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37670
could not establish sslpsk socket: [SSL: WRONG_SSL_VERSION] wrong ssl version (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37674
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37676
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37680
could not establish sslpsk socket: [SSL: WRONG_SSL_VERSION] wrong ssl version (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37686
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37694
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37730
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37738
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37748
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37756
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37760
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37772
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37784
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37796
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37806
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37810
could not establish sslpsk socket: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:852)
don't panic this is probably just your phone!
new client on port 443 from 10.42.42.31:37820
could not establish sslpsk socket: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:852)
don't panic this is probably just your phone!
The device is a Nooie Led Smart Bulb, the FW is at version 1.0.5, so it should be old enough, but it talks protocol version 3.3 (I think) and I had some trouble fetching its key.
I say it talks a 3.3 version protocol because looking at the traffic with it's official app, I see a lot of 3.3
in each packet (see attach) and the already known 0000 0000 55aa
sequence (maybe I'm wrong, it's just a little bit more of 24h that I'm studying this topic :)
If you need some reverse engineering help, let me know, I'm ready to mostly everything except cracking open the device.
I've tried both with my phone and my tablet, given the problems I had with the bulb I bet it's the bulb.
@aviogit I'm not saying your bulb does not have problems, but that specific error you are reading is unrelated. You can check which device is assigned that IP address.
Mmm, running everything outside of docker, I get this:
new client on port 443 from 10.42.42.10:36974
argument 2 must be str, not bytes
new client on port 443 from 10.42.42.10:36975
argument 2 must be str, not bytes
And you're right, 10.42.42.10 is my tablet:
#> arp -n
Address HWtype HWaddress Flags Mask Iface
10.42.42.10 ether 10:7b:44:bd:f2:b7 C wlan1
I confess I'm not understanding the pairing procedure and why another device is needed, so if you have any advice on how to solve this, I'm all ears.
argument 2 must be str, not bytes
You must run install_prereq.sh
again after updating tuya-convert
I don't know, the device completes the pairing procedure, but the message is always the same:
Device did not appear with the intermediate firmware
Check the *.log files in the scripts folder
I've re-run install_prereq.sh
, now I get again the NO_SHARED_CIPHER messages, as it was inside docker. I'll try again.
Using interface wlan1 with hwaddr 00:02:6f:8d:e7:e3 and ssid "vtrust-flash"
wlan1: interface state UNINITIALIZED->ENABLED
wlan1: AP-ENABLED
wlan1: AP-STA-CONNECTED 68:57:2d:6d:f1:d7
wlan1: AP-STA-CONNECTED 10:7b:44:bd:f2:b7
wlan1: AP-STA-CONNECTED 68:57:2d:6d:f1:d7
#> arp -n
Address HWtype HWaddress Flags Mask Iface
10.42.42.27 ether 68:57:2d:6d:f1:d7 C wlan1
10.42.42.10 ether 10:7b:44:bd:f2:b7 C wlan1
I don't know, the device completes the pairing procedure, but the message is always the same:
Device did not appear with the intermediate firmware
Check the *.log files in the scripts folder
Yes, the message is always the same on failure. You'll need to check your log files. Since your issue is not related to this one, if you would like further assistance, please open your own issue with your log files attached and I would be happy to continue the discussion with you there.
@AlexBV mine is a Bakibo TB95 with the same problem.
Bakibo TP22Y the same problem
Version:
WI-FI Modul: 1.1.4
MCU-Modul 1.1.4
@kueblc Colin, is there anything else I can contribute to support for the new PSK format beyond a network recording before returning the smart bulbs? Or should I better keep them because it is foreseeable that they can be converted soon?
After spending some time digging through the firmware, it's pretty clear Tuya has upped their game here. It appears a unique preshared key is programmed into each device at the factory. Unlike before where the key could be derived from the TLS identity, now the identity is a hash of the device's id and MAC address. For those following along, the new identity derivation is:
'\x02' + 'BAohbmd6aG91IFR1' + sha256(prod_idx + mac_addr)
where prod_idx is the ASCII of the 8 digit product ID, and mac_addr is the MAC address of the device in hex, all lowercase, no punctuation. These parameters are all stored in the flash in a JSON blob at 0xfb000.
Here's the firmware dump from a Moeshouse Smart Downlight with the same issue. New right out of the box, never paired with the tuya app.
Think I'm seeing the same issue with a BSD29 - getting the following error in the smarthack-psk log:
('could not establish sslpsk socket:', SSLError(1, u'[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:727)'))
Anyone worked through a solution yet?
Here's the original firmware for BSD29 smart plug.
Hope it helps.
How did you manage to open the devices up to flash them? They look pretty impenetrable!
How did you manage to open the devices up to flash them? They look pretty impenetrable!
Pushed a screwdriver into the grounding pin hole and pushed until the weld gave in, nothing broke, i only had to use a tiny bit of superglue to make sure the cover didn't come off when pulling the plug out of the socket.
I also had to desolder the L N terminals to access the bottom of the pcb for programing the esp8285.
I can post pictures if needed.
Pictures would be great if you could post some. Been a while since I've done any fine soldering, so slightly apprehensive about opening it up..
Wow, buying tuya gear now is really hit and miss. Received four MALITAI Smart WiFi 9W RGBCCT E27 bulbs today. Three of them worked perfectly with tuya convert. The fourth one would not enter fast flashing mode, until I finally toggled the bulb on and off around 10 times... and then, it turned out to be blocked! I'll bet they pulled four bulbs off the shelf, helpfully tested one by pairing it, at which point it got updated.
I solved that one with a soldering iron -- not the easiest tasmota conversion ever, but... yeah. you know.
now the identity is a hash of the device's id and MAC address
@iracigt I'm not certain yet but it looks like you can use the Smart Life app to pair the device and get the prod_idx. I found it under "Device Information" as the first 8 characters of the "Virtual ID" string and it seems to match the prod_idx I found in the json blob. Can anyone else confirm this?
Also it looks like the prod_idx happens to be identical for the particular set of 6 BSD29s that I bought. I'll take a closer look when I have some more time but is that all we need to flash the firmware?
@CHAZICLE I have checked my BSD34, the Virtual ID is 83203175d8f15bd49015. Version of WI-FI module is 1.1.4. But I have no idea how to check the prod_idx "in the json blob" :(
I'll take a closer look when I have some more time but is that all we need to flash the firmware?
No, it's a bit more complicated than that. The missing part is how to compute the PSK from the PSK identity, if that is possible with the information we have.
As @iracigt has said, the prod_idx
is used to compute the PSK identity. This is handed to the server by the client during the handshake, so it is not secret information.
prod_idx
is not secret information either, it is the first part of the gwId
as you have noticed, @CHAZICLE. In fact the gwId
is what is being hashed here, which is prod_idx
+ mac
.
The point is that the previous implementation did leak secret information through the PSK identity, which we could use to compute the PSK. Now that it does not, our job is harder.
In order to solve this, we will need samples of actual communications between the client (smart device) and the server (Tuya cloud), along with a copy of that device's firmware. If anyone is able to provide both we may be able to crack this.
One possible procedure to accomplish this would be:
- Start with a new device
- Create a bridged hotspot using
create_ap
- Start recording the network interface with
tcpdump
or WireShark - Connect smart phone
- Use the vendor app to connect the smart device to the hotspot
- Disconnect and stop recording
- Open the device and read the firmware over serial using
esptool.py
🙋🏻♂️I just received two of the smart plugs described in the start post (the eu version) bsd34.
After trying and googling for 4 days I just came across this post after discovering the DECRYPTION_FAILED_OR_BAD_RECORD_MAC
error in the smarthack-psk.log file.
This is a hard to find gh issue.
I'd love to help if someone can take me through the steps.
I'm a (ruby) developer, have the tools (pi's, macbook, kali linux, soldering iron, arduino flash thingy), but not the know how to take the steps mentioned above.
I have one that's already linked with the smart life app and one that is still virging (except for the tuya-convert attempts). Just don't know which is which anymore.
So long story short. What do I do.
edit:
secondly , wondering how to enable the power metering ==> Sorry noticed it doesn't have that feature... Stupid me
The app does provide these features with the bsd34...
@kueblc, there are yet several tuya devices heading here by mail. I'm sure at least one of them will be blocked, and if so I will attempt to capture the traffic and the binary as you described above. I don't actually know when I'll get a blocked device next (I beat all previous ones into submission with my soldering iron) so if someone beats me to it, that works too.
- Install
create_ap
git clone https://github.com/oblique/create_ap
cd create_ap
sudo make install
cd ..
- Setup a pass through AP (assuming your interface is
wlan0
)
sudo create_ap wlan0 wlan0 MyAccessPoint MyPassPhrase
- Start recording
tcpdump -i wlan0 -w capture.pcap
- Connect your phone to
MyAccessPoint
(or whatever you decide to call it) - Use the app (SmartLife or vendor branded app) to pair the device
- Wait for registration to complete
- Disconnect the device
- Go back to
tcpdump
and pressCtrl
+C
- Disassemble the device and connect to the serial port of the ESP
- Download the firmware using
esptool
esptool.py read_flash 0 0x100000 firmware.bin
- Upload both
capture.pcap
andfirmware.bin
@leifclaesson great to hear, thank you for your contributions
The missing part is how to compute the PSK from the PSK identity, if that is possible with the information we have.
Oh damn. so THAT changed? Well here's my pcap and firmware:
module1.zip
I'll have another one ready soon. Happy decrypting!
🙋🏻♂️I just received two of the smart plugs described in the start post (the eu version) bsd34.
After trying and googling for 4 days I just came across this post after discovering theDECRYPTION_FAILED_OR_BAD_RECORD_MAC
error in the smarthack-psk.log file.
This is a hard to find gh issue.I'd love to help if someone can take me through the steps.
I'm a (ruby) developer, have the tools (pi's, macbook, kali linux, soldering iron, arduino flash thingy), but not the know how to take the steps mentioned above.I have one that's already linked with the smart life app and one that is still virging (except for the tuya-convert attempts). Just don't know which is which anymore.
So long story short. What do I do.
edit:
secondly , wondering how to enable the power metering ==> Sorry noticed it doesn't have that feature... Stupid me
The app does provide these features with the bsd34...
There is a new BSD34 device on the market with power metering.
I called it "BSD34-1 16A Modul" in the tasmota database, but it seems, that my entry isn't still visible there.
You can use the power metering with the following template.
{"NAME":"BSD34-1 16A","GPIO":[0,53,0,131,134,132,0,0,21,17,52,0,0],"FLAG":0,"BASE":18}
The new device has a 16A fuse instead of 10A and power metering. At the socket you won't find a difference. I opened the device to flash it und figured out, that there are two LEDs (red/blue).
With the original firmware it is possible to have red, blue and a purple combination of them.
My template uses this purple color. You will find the LEDs at GPIO1 (LED2) and GPIO14 (LED1).
You can use the normal or the inverted variant (LED1 vs. LED1i). I didn't spend so much time to figure out the correct color combination as it is in the original firmware.
@masterflai Thanks for sharing! Working great!
I might have bricked them with tuya-convert.
They won't connect with the SmartLife app anymore 😧
They just stop (fast) blinking after a second or two and don't respond.
@delneet it is unlikely to be bricked, please open a new issue if you need help resolving.
I'd like to ask us to keep off topic discussion to a minimum to make collaboration and information sharing about this particular issue easier. The purpose of this issue will be collecting our findings and data until we hopefully find a workaround for the new PSK format.
I got three identical downlights today -- all blocked! Will try to dump them tomorrow.
Okay, severe case of cranial rectitis here. Good thing I had three devices, because I paired the first two into my main network, not the one I was capturing packets on! I thought I was smart to leave my phone on the main network so only the communication to/from the bulb would be logged, and then completely overlooked the fact that it didn't ask for my (previously saved, obviously) wifi password but just went ahead and paired it... Durrrr....
Anyway, at least i realized it before the third one. Real shame about the other two though. @kueblc , is it helpful to have more captures? I did actually save the pre-tuya-integration firmware for all three devices separately, so if it's useful I could re-flash the original firmware and attempt this again.
Here's before/after binaries and the capture (of the third device).
tuya_pairing.zip
Okay, I hate to leave stones unturned, and I was bored, so I did it. Here are the before/after and captures of three identical devices. It's the 3.5" RGBCW downlight with the recessed diffuser and orange arms -- different from for example the Zemismart downlights which has a flush diffuser and black arms.
Let me know if I can help any other way. Thanks for the great work with Tuya Convert, @kueblc and everyone else in the community.
- Install
create_ap
git clone https://github.com/oblique/create_ap cd create_ap sudo make install cd ..
- Setup a pass through AP (assuming your interface is
wlan0
)sudo create_ap wlan0 wlan0 MyAccessPoint MyPassPhrase
- Start recording
tcpdump -i wlan0 -w capture.pcap
- Connect your phone to
MyAccessPoint
(or whatever you decide to call it)- Use the app (SmartLife or vendor branded app) to pair the device
- Wait for registration to complete
- Disconnect the device
- Go back to
tcpdump
and pressCtrl
+C
- Disassemble the device and connect to the serial port of the ESP
- Download the firmware using
esptool
esptool.py read_flash 0 0x100000 firmware.bin
- Upload both
capture.pcap
andfirmware.bin
@leifclaesson great to hear, thank you for your contributions
@kueblc I have new Tuya IR which could not OTA because of this issue. If you need the information above to debug, I will make for you.
Thank you.
Same Problem here with TB95 bulb.
new client on port 443 from 10.42.42.17:34775
ID: 023f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3ff34d434ebeb1d22b0a8a672b34f45e8d1d6da8d7d7087ae47e82c7e4010e0d28
Prefix: b'????????????????'
PSK: 42b1cbd08045d6d93a41749c666df553c6738c9b8b977265b2d90631e9d10ca0
could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1056)
I have the same problem with a bunch of E12 RGB bulbs. I've opened one of them up and it unfortunately appears nearly impossible to solder a wire to GPIO0 to facilitate an offline flash. I'll fiddle with it though.
Let me know if you want me to test with what i've got, I've got 14 bulbs I can get captures and bins for.
same here with a loratap sc500w curtain switch
new client on port 443 from 10.42.42.24:26773
ID: 0242416f68626d64366147393149465231293a51d5543cb4717d4d645a9ef23f3f2d71437225 3b0bed72c16a89f4b06db9
PSK: 42df0b16a88c3f4ea40087c8f31cf95406b7dc9eece251f1c880cfe44a3b88d4
could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] de cryption failed or bad record mac (_ssl.c:1056)
wlan0: AP-STA-DISCONNECTED d8:bf:c0:e6:e4:58
wlan0: AP-STA-CONNECTED d8:bf:c0:e6:e4:58
same here with a loratap sc500w curtain switch
I join this. The SC500W-v2 shutter switch resists flashing for me and other people as well (FHEM forum).
Procedure:
- Set SC500W pairing mode by pressing button. LED blinks rapidly.
- Follow instructions from tuya-convert up to and beyond the "Press ENTER" message.
- LED turns to steady on.
- tuya-convert times out after some time
Same on deltaco SH-P01E (other manufacture of Gosund SP1)
Can someone please help me on manual flashing? I was able to solder 3.3, tx, rx, gnd.
If I'm correct they are in the order 3.3; _ ; RX ; TX; GND; _ on the 'upper' row.
I watch all the attached photoes, and didn't see how you managed to solder gpio0, and noone mentioned the 'en' pin. As far as I know, gpio0 should be pulled low (gnd) and 'en' should be pulled to high for a successfull flash.
I use an usb->serial converter, and HA's esphome plugin to flash.
On @countcobolt comment at Jan 4, I see 3.3; ?? ; RX ; TX soldered (black;white;grey;purple), but no gnd.
Edit:
Offtopic, but wanted to correct my error to prevent someone making the same mistake. I determined the pins by measuring the resistance between the circles on the panel and the soldered 'leggs'. My mistake was that I thought the G marked circle is the ground, but not. It is at the upper left corner, and indeed it is the ?? marked leg. So to make a manual flash, you need to solder the first four legg (from top left). 3.3; GND ; RX ; TX
The gpio0 is the oo marked circle next to 'RX' and below 'R'. I didn't even try to solder it, but I was able to hold a pin to it while powering the ESP, so it entered flashing mode.
Good luck for converting.
Same with Gosund 800l bulbs :/
Is it possible that we get in near future a solution for this problem?
What can i do?
Could not flash Merkury MI-EW003-999W LED Light strip. Ended up using Tasmotizer. The logs show some sort of decryption error? I made a backup of the firmware if you would like me to send it to you.
Logs:
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
smarthack-mqtt.log
I also have a magic home backup if you'd like that too. I cant remember if I even tried tuya-convert on it or not, I just soldered to it.
Hi @kueblc , I think will be a good idea to change this post title to:
"new psk format. Device did not appear with the intermediate firmware"
That way may be more people could find it and not open new isues (like me and others)
Hello, I have the same problem with LoraTap SC511WSC Curtain Switch.
The flashing stuck at "Resending SmartConfig Packets" and no intermediate firmware at all....
have the same problem with a DETA Quad Smart Switch (6904HA). Have successfully flashed single and dual gang switches, but the quad gang, has same failure as above (resending packets...). now having a hard time flashing via serial as well. Not my night!
smarthack-udp.log
smarthack-web.log
smarthack-psk.log
smarthack-wifi.log
smarthack-mqtt.log
have the same problem with a DETA Quad Smart Switch (6904HA). Have successfully flashed single and dual gang switches, but the quad gang, has same failure as above (resending packets...). now having a hard time flashing via serial as well. Not my night!
smarthack-udp.log
smarthack-web.log
smarthack-psk.log
smarthack-wifi.log
smarthack-mqtt.log
I have the same issue with the DETA Triple Smart Switch
(this is my first attempt at tuya convert)
Hi!!
The same issue with tuya smart plug (brazilian version). If any log are required, please let me know.
no help to provide, but one more device that fails : Etersky [aka Maxcio] curtain switch (WS-CS01) in smart life 1.0.6
new client on port 443 from 10.42.42.26:34096
('could not establish sslpsk socket:', SSLError(1, u'[SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:727)'))
I used development branch on github to collect this log
I seem to be having the same problem with Arlec GLD060HA lamp/bulb in Australia (Bunnings)
I have cracked open the Teckin SB50 bulb, but can someone guide me on how to backup the firmware in a way that will help here? As soon as I figure out the connection pads to use for programming, I will pull the currently problematic firmware.
As in the utility or format of the firmware backup?
Hi, I have bought lately (Amazon Germany) sp112 plug. It seems to be the same issue as described over. I flashed sp1 successfully yesterday, and I am surprised, that it does not work with sp112 (bot bought at the same time).
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
As @rbswift mentioned, I would also flash them in old way maybe and backup firmware. Where can I find instructions how to back up the firmware - connections to the main board and tools I found already in some other article to know, how to flash.
Thanks in advance.
@tomrar1290
Making a backup is simple, if you soldered, and can flash a new image.
It was mentioned earlyer in this thread:
Get:
https://github.com/espressif/esptool
Issue command:
esptool.py read_flash 0 0x100000 firmware-backup.bin
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.
have the same problem with a DETA Quad Smart Switch (6904HA). Have successfully flashed single and dual gang switches, but the quad gang, has same failure as above (resending packets...). now having a hard time flashing via serial as well. Not my night!
smarthack-udp.log
smarthack-web.log
smarthack-psk.log
smarthack-wifi.log
smarthack-mqtt.log
Same here. The switch drops out of pairing mode with Tuya. Tried a serial flash but couldn't get it into flash mode. Did you have any luck getting it flashed?
Hi, Adding another one to the list, Arlec PC399HA, Australia, Bunnings.
have the same problem with a DETA Quad Smart Switch (6904HA). Have successfully flashed single and dual gang switches, but the quad gang, has same failure as above (resending packets...). now having a hard time flashing via serial as well. Not my night!
smarthack-udp.log
smarthack-web.log
smarthack-psk.log
smarthack-wifi.log
smarthack-mqtt.logSame here. The switch drops out of pairing mode with Tuya. Tried a serial flash but couldn't get it into flash mode. Did you have any luck getting it flashed?
OK, I got it going. I had forgotten to pull up the enable pin. Once I did that the ESP programmed as usual. Some further experimenting got the 4 way set up as follows:
{"NAME":"DETA 4G Switch","GPIO":[0,0,0,20,18,21,0,0,24,19,22,23,17],"FLAG":0,"BASE":18}
A bit of a pita, but I'll see if it behaves over the next few days.
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 bought the exact same model. Is it enough to loosen the 6 screws on the back? Or do I have to disassemble it even further?
@LaurentCoignot I think that's related to the "slow pairing" mode. This tool exploits the "fast pairing" mode where joining the device's AP is not required
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 bought the exact same model. Is it enough to loosen the 6 screws on the back? Or do I have to disassemble it even further?
No, you have to disassemble it completly.
I have cracked open the Teckin SB50 bulb, but can someone guide me on how to backup the firmware in a way that will help here? As soon as I figure out the connection pads to use for programming, I will pull the currently problematic firmware.
I have a SB50 as well, running latest firmware from tuya.
What do I need to get this flashed?