Tuya-convert: Blitzwolf BW-SHP6 connected but script does not continue

[nightcat91]

Hi,

a few days ago I got my two Blitzwolf BW-SHP6 in the mail from banggood. They were preordered on banggood and took a bit of time (roughly 1 month) to be send out by banggood.

I connected my rasp 3b+ again but it doesnt work. (I did about 5-6 converts of other devices before, all sucessful and all the same steps).
Searching through the issues I think my problem is related to two other issues:
https://github.com/ct-Open-Source/tuya-convert/issues/160 and https://github.com/ct-Open-Source/tuya-convert/issues/130 and I think I might have gotten devices with the new firmware.

EDIT: just to complete the info:
The devices where plugged in blinking fast and when I pressed Enter on the flash script (after connecting my phone to the wifi) after about 10 sek. the tuya device stopped flashing its led. I think thats the point where it connects to the wifi AP but the script never continues, just those dots all the way....
Using my phone to browse tuya.com while beeing connected to the wifi of the RASP I get a Hello World webpage back, so I think the DNS on the rasp is working correctly...

Now, what I found in the logs is that the device connected to the wifi:
From smarthack-wifi.log:

Backing up /etc/dnsmasq.conf...
Writing dnsmasq config file...
Creating new /etc/dnsmasq.conf...
Writing hostapd config file...
Configuring AP interface...
Applying iptables rules...
Starting DNSMASQ server...
RTNETLINK answers: File exists
Starting AP on wlan0 in screen terminal...
Configuration file: /etc/hostapd/hostapd.conf
Failed to create interface mon.wlan0: -95 (Operation not supported)
wlan0: Could not connect to kernel driver
Using interface wlan0 with hwaddr b8:27:eb:76:bc:4b and ssid "vtrust-flash"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
wlan0: STA f0:0f:ec:1c:0e:4f IEEE 802.11: associated
wlan0: AP-STA-CONNECTED f0:0f:ec:1c:0e:4f
wlan0: STA f0:0f:ec:1c:0e:4f RADIUS: starting accounting session DA8127634B891298
wlan0: STA f0:0f:ec:1c:0e:4f WPA: pairwise key handshake completed (RSN)
wlan0: STA ec:fa:bc:34:29:0e IEEE 802.11: associated
wlan0: AP-STA-CONNECTED ec:fa:bc:34:29:0e
wlan0: STA ec:fa:bc:34:29:0e RADIUS: starting accounting session 116BE9ADC3B44FA2
wlan0: STA ec:fa:bc:34:29:0e WPA: pairwise key handshake completed (RSN)

MAC f0:0f:ec:1c:0e:4f is my mobile phone, and I am guessing that ec:fa:bc:34:29:0e is the tuya device.

I have never used the official tuya app, all my tuya devices (5-6) have gone straight through tuya convert to tasmota, so I have no knowledge of the official app. Is there another way to find out the firmware version number of my new devices?

This is from smarthack-web.log:

Listening on port 80
^CTraceback (most recent call last):
File "./fake-registration-server.py", line 132, in
main()
File "./fake-registration-server.py", line 128, in main
tornado.ioloop.IOLoop.current().start()
File "/usr/local/lib/python3.5/dist-packages/tornado/platform/asyncio.py", line 148, in start
self.asyncio_loop.run_forever()
File "/usr/lib/python3.5/asyncio/base_events.py", line 421, in run_forever
self._run_once()
File "/usr/lib/python3.5/asyncio/base_events.py", line 1388, in _run_once
event_list = self._selector.select(timeout)
File "/usr/lib/python3.5/selectors.py", line 445, in select
fd_event_list = self._epoll.poll(timeout, max_ev)
KeyboardInterrupt
Listening on port 80
^[[32m[I 190404 16:08:07 web:2246]^[[m^O 200 GET / (10.42.42.20) 10.21ms
^[[33m[W 190404 16:08:07 web:2246]^[[m^O 404 GET /favicon.ico (10.42.42.20) 14.28ms

If you need any other logs please let me know.
Like I said the devices have never been in contact with the tuya cloud or the original tuya app, but I dont know the firmware version.
If this help to get any capture logs from them I would be happy to help (but I have never used wireshark before).

Also, if this is still needed I might be able to crack one of them open and if anyone can help or tell me how to make a dump of the firmware, I might be able to do that

[nightcat91]

I was able to open one of them and I will try to get to the ESP chip with the solder points...

What do I need to have and know to be able to make a dump of the firmware thats on it right now?

[kueblc]

Hi @nightcat91,

It's difficult to say what the firmware might be, without adding to the app or before backing up the firmware via serial connection. You could try using tcpdump or Wireshark during the flashing attempt to capture network traffic. We can then see what/who the device is trying to communicate with.

I recommend reading through the Sonoff-Tasmota wiki on the subject of directly connecting, backing up, and flashing firmware. You'll need some sort of USB to serial adapter like an FTDI or CH340, with 3.3V not 5V power and logic. You'll also need the esptool.py to make backups and flash new firmware.

If you manage to get a backup of the firmware, that would be tremendously helpful in reverse engineering the new changes that are blocking tuya-convert on newer firmware.

Let us know how it goes!

[nightcat91]

Hi,

I am familiar with getting an FTDI on an ESP8266. But I just dont really know how to use the esptool.py or tcpdump...

Will have a read about those and I hope I can get everything that is needed.
My guess would be to first try and get the firmware as it is right now and then try to capture the setup process with the original app??

[kueblc]

Great! As far as backing up using the esptool, do

esptool.py read_flash 0x00000 0x100000 firmware-backup.bin

Yes, try to get the firmware first, then if you can capture the provisioning process that would be phenomenal. You might try setting up a proxy so that the SSL traffic can be captured as it passes through.

[nightcat91]

Can you maybe explain a little bit more (or guide me with some links) about how I would set up a proxy to capture the SSL traffic aswell? Can this all be done on the rasp that is runnig the tuya convert script?

Can I use the rasp with its tuya convert script to do the capture with tcpdump so that I dont have to expose my real wifi network when doing the pairing process with the original app?

I will try to get a dump of the firmware tomorrow or saturday...

[jj-0]

Here's a firmware dump.

I tried to fool it by using stunnel to accept an SSL connection but that was unsuccesful (no shared cipher).

blitz_shp-6-default_firmware.zip

[fredericvl]

I have exactly the same problem with my 4 new Blitzwolf SHP-6 devices.
A couple of months ago I already had one of those and then flashing with tuya-convert was no problem at all.
I did a tcpdump and it looks like the device is now trying to communicate with Tuya over SSL instead of plain HTTP on port 80...

See tcpdump below:

16:15:40.007552 IP (tos 0xc0, ttl 64, id 40667, offset 0, flags [none], proto UDP (17), length 328)
    10.42.42.1.bootps > 10.42.42.13.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xfe09d846, Flags [none] (0x0000)
      Your-IP 10.42.42.13
      Server-IP 10.42.42.1
      Client-Ethernet-Address ec:fa:bc:34:2a:a1 (oui Unknown)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 10.42.42.1
        Lease-Time Option 51, length 4: 43200
        RN Option 58, length 4: 21600
        RB Option 59, length 4: 37800
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 10.42.42.255
        Default-Gateway Option 3, length 4: 10.42.42.1
        Domain-Name-Server Option 6, length 4: 10.42.42.1
16:15:41.699064 IP (tos 0xc0, ttl 64, id 40827, offset 0, flags [none], proto UDP (17), length 328)
    10.42.42.1.bootps > 10.42.42.13.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xfe09d846, Flags [none] (0x0000)
      Your-IP 10.42.42.13
      Server-IP 10.42.42.1
      Client-Ethernet-Address ec:fa:bc:34:2a:a1 (oui Unknown)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 10.42.42.1
        Lease-Time Option 51, length 4: 43200
        RN Option 58, length 4: 21600
        RB Option 59, length 4: 37800
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 10.42.42.255
        Default-Gateway Option 3, length 4: 10.42.42.1
        Domain-Name-Server Option 6, length 4: 10.42.42.1
16:15:44.320227 IP (tos 0xc0, ttl 64, id 41066, offset 0, flags [none], proto UDP (17), length 328)
    10.42.42.1.bootps > 10.42.42.13.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xa7018a9e, Flags [none] (0x0000)
      Your-IP 10.42.42.13
      Server-IP 10.42.42.1
      Client-Ethernet-Address ec:fa:bc:34:2a:a1 (oui Unknown)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 10.42.42.1
        Lease-Time Option 51, length 4: 43200
        RN Option 58, length 4: 21600
        RB Option 59, length 4: 37800
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 10.42.42.255
        Default-Gateway Option 3, length 4: 10.42.42.1
        Domain-Name-Server Option 6, length 4: 10.42.42.1
16:15:44.402046 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.42.42.13 tell 0.0.0.0, length 28
16:15:44.691028 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.42.42.13 tell 0.0.0.0, length 28
16:15:45.196467 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.42.42.13 tell 10.42.42.13, length 28
16:15:46.074282 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.42.42.1 tell 10.42.42.13, length 28
16:15:46.074359 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.42.42.1 is-at b8:27:eb:76:7e:88 (oui Unknown), length 28
16:15:46.080931 IP (tos 0x0, ttl 255, id 4, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 59750+ A? a3.tuyaus.com. (31)
16:15:46.196466 IP (tos 0x0, ttl 255, id 5, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 59750+ A? a3.tuyaus.com. (31)
16:15:47.199912 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.42.42.13 tell 10.42.42.13, length 28
16:15:47.200073 IP (tos 0x0, ttl 255, id 6, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 59750+ A? a3.tuyaus.com. (31)
16:15:47.865307 IP (tos 0xc0, ttl 64, id 41249, offset 0, flags [none], proto UDP (17), length 328)
    10.42.42.1.bootps > 10.42.42.13.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xa7018a9e, Flags [none] (0x0000)
      Your-IP 10.42.42.13
      Server-IP 10.42.42.1
      Client-Ethernet-Address ec:fa:bc:34:2a:a1 (oui Unknown)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 10.42.42.1
        Lease-Time Option 51, length 4: 43200
        RN Option 58, length 4: 21600
        RB Option 59, length 4: 37800
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 10.42.42.255
        Default-Gateway Option 3, length 4: 10.42.42.1
        Domain-Name-Server Option 6, length 4: 10.42.42.1
16:15:47.865622 IP (tos 0x0, ttl 64, id 41250, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 59750* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:15:47.865743 IP (tos 0x0, ttl 64, id 41251, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 59750* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:15:47.865859 IP (tos 0x0, ttl 64, id 41252, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 59750* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:15:47.889658 IP (tos 0x0, ttl 255, id 7, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.10089 > 10.42.42.1.https: Flags [S], cksum 0xdc17 (correct), seq 6509, win 4380, options [mss 1460], length 0
16:15:47.889788 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.10089: Flags [R.], cksum 0x04dd (correct), seq 0, ack 6510, win 0, length 0
16:15:51.016899 IP (tos 0x0, ttl 255, id 8, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 38820+ A? a3.tuyaus.com. (31)
16:15:51.017434 IP (tos 0x0, ttl 64, id 41394, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 38820* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:15:51.033615 IP (tos 0x0, ttl 255, id 9, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.9219 > 10.42.42.1.https: Flags [S], cksum 0xdf7b (correct), seq 6511, win 4380, options [mss 1460], length 0
16:15:51.033747 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.9219: Flags [R.], cksum 0x0841 (correct), seq 0, ack 6512, win 0, length 0
16:15:52.879634 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.42.42.13 tell 10.42.42.1, length 28
16:15:53.015083 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.42.42.13 is-at ec:fa:bc:34:2a:a1 (oui Unknown), length 28
16:15:54.163852 IP (tos 0x0, ttl 255, id 10, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 24983+ A? a3.tuyaus.com. (31)
16:15:54.164362 IP (tos 0x0, ttl 64, id 41441, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 24983* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:15:54.177550 IP (tos 0x0, ttl 255, id 11, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.7265 > 10.42.42.1.https: Flags [S], cksum 0xe71b (correct), seq 6513, win 4380, options [mss 1460], length 0
16:15:54.177685 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.7265: Flags [R.], cksum 0x0fe1 (correct), seq 0, ack 6514, win 0, length 0
16:15:57.196330 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.42.42.13 tell 10.42.42.13, length 28
16:15:57.304376 IP (tos 0x0, ttl 255, id 12, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 15170+ A? a3.tuyaus.com. (31)
16:15:57.304688 IP (tos 0x0, ttl 64, id 41682, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 15170* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:15:57.316133 IP (tos 0x0, ttl 255, id 13, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.358 > 10.42.42.1.https: Flags [S], cksum 0x0213 (correct), seq 6517, win 4380, options [mss 1460], length 0
16:15:57.316245 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.358: Flags [R.], cksum 0x2ad8 (correct), seq 0, ack 6518, win 0, length 0
16:16:00.456024 IP (tos 0x0, ttl 255, id 14, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 15892+ A? a3.tuyaus.com. (31)
16:16:00.456495 IP (tos 0x0, ttl 64, id 41882, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 15892* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:16:00.465065 IP (tos 0x0, ttl 255, id 15, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.3494 > 10.42.42.1.https: Flags [S], cksum 0xf5ce (correct), seq 6521, win 4380, options [mss 1460], length 0
16:16:00.465193 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.3494: Flags [R.], cksum 0x1e94 (correct), seq 0, ack 6522, win 0, length 0
16:16:03.596041 IP (tos 0x0, ttl 255, id 16, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 58320+ A? a3.tuyaus.com. (31)
16:16:03.596525 IP (tos 0x0, ttl 64, id 41952, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 58320* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:16:03.677499 IP (tos 0x0, ttl 255, id 17, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.4335 > 10.42.42.1.https: Flags [S], cksum 0xf27f (correct), seq 6527, win 4380, options [mss 1460], length 0
16:16:03.677710 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.4335: Flags [R.], cksum 0x1b45 (correct), seq 0, ack 6528, win 0, length 0
16:16:06.822480 IP (tos 0x0, ttl 255, id 18, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 49375+ A? a3.tuyaus.com. (31)
16:16:06.822989 IP (tos 0x0, ttl 64, id 42160, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 49375* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:16:06.829950 IP (tos 0x0, ttl 255, id 19, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.dicom > 10.42.42.1.https: Flags [S], cksum 0xd800 (correct), seq 6533, win 4380, options [mss 1460], length 0
16:16:06.830069 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.dicom: Flags [R.], cksum 0x00c6 (correct), seq 0, ack 6534, win 0, length 0
16:16:07.196332 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.42.42.13 tell 10.42.42.13, length 28
16:16:09.952460 IP (tos 0x0, ttl 255, id 20, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 45158+ A? a3.tuyaus.com. (31)
16:16:09.952777 IP (tos 0x0, ttl 64, id 42451, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 45158* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:16:09.960370 IP (tos 0x0, ttl 255, id 21, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.36419 > 10.42.42.1.https: Flags [S], cksum 0x751d (correct), seq 6541, win 4380, options [mss 1460], length 0
16:16:09.960491 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.36419: Flags [R.], cksum 0x9de2 (correct), seq 0, ack 6542, win 0, length 0
16:16:13.097052 IP (tos 0x0, ttl 255, id 22, offset 0, flags [none], proto UDP (17), length 59)
    10.42.42.13.49153 > 10.42.42.1.domain: [udp sum ok] 26826+ A? a3.tuyaus.com. (31)
16:16:13.097527 IP (tos 0x0, ttl 64, id 42665, offset 0, flags [DF], proto UDP (17), length 75)
    10.42.42.1.domain > 10.42.42.13.49153: [udp sum ok] 26826* q: A? a3.tuyaus.com. 1/0/0 a3.tuyaus.com. A 10.42.42.1 (47)
16:16:13.107203 IP (tos 0x0, ttl 255, id 23, offset 0, flags [none], proto TCP (6), length 44)
    10.42.42.13.5367 > 10.42.42.1.https: Flags [S], cksum 0xee61 (correct), seq 6549, win 4380, options [mss 1460], length 0
16:16:13.107319 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.42.42.1.https > 10.42.42.13.5367: Flags [R.], cksum 0x1727 (correct), seq 0, ack 6550, win 0, length 0

[nightcat91]

Hi,

here is my firmware dump that I was able to get with read flash with the esptool from my BW-SHP6.
I will try to get a tcpdump of the connection with the official app.

firmware-backup_bw-shp6.zip

[kueblc]

@jj-0 @fredericvl @nightcat91 Thank you all for the valuable data! This has been very helpful in understanding the update.

[mclaudiopt]

hi there. i flashed several SHP2 without problem...now bought SHP6 and it does not flash...it just gives me the endeless ...... (points).
is there any news regarding the update of the script that allows flashing this plug? thanks

[ohiaia]

Hi everybody...
another here is getting endless pointed line response...

here you are my smarthack-web.log

Listening on port 80


URI:/gw.json?a=s.gw.token.get&gwId=28478004840d8e604987&other={"token":"00000000","region":"US","tlinkStat":{"configure":"smartconfig","time":2,"source":"ap","path":"broadcast"}}&t=24&v=3.0&sign=380fd99bd977d014f896c527f0521459
Answer s.gw.token.get
[I 190411 14:11:17 web:2246] 200 POST /gw.json?a=s.gw.token.get&gwId=28478004840d8e604987&other={"token":"00000000","region":"US","tlinkStat":{"configure":"smartconfig","time":2,"source":"ap","path":"broadcast"}}&t=24&v=3.0&sign=380fd99bd977d014f896c527f0521459 (10.42.42.26) 6.43ms


URI:/gw.json?a=s.gw.dev.fk.active&gwId=28478004840d8e604987&other={"token":"00000000"}&t=7&v=3.0&sign=3920b9ff12a38098ee7871966ea14dce
Answer s.gw.dev.pk.active
READ GW ID 28478004840d8e604987
TRIGGER UPGRADE IN 10 SECONDS
Trigger upgrade in 10 seconds
[I 190411 14:11:17 web:2246] 200 POST /gw.json?a=s.gw.dev.fk.active&gwId=28478004840d8e604987&other={"token":"00000000"}&t=7&v=3.0&sign=3920b9ff12a38098ee7871966ea14dce (10.42.42.26) 37.90ms


URI:/gw.json?a=tuya.device.upgrade.silent.get&gwId=28478004840d8e604987&t=12&v=4.1&sign=2ceed6773de77f86fead15368b24f6e1
Answer s.gw.upgrade
b'{"result":{"auto":3,"fileSize":"506587","etag":"0000000000","version":"9.0.0","url":"http://10.42.42.1/files/upgrade.bin","md5":"dc92883ebc44f64253bfb004433fc929"},"t":100,"e":false,"success":true}'
[I 190411 14:11:23 web:2246] 200 POST /gw.json?a=tuya.device.upgrade.silent.get&gwId=28478004840d8e604987&t=12&v=4.1&sign=2ceed6773de77f86fead15368b24f6e1 (10.42.42.26) 13.29ms
a4cfb0890d40283545fcc9c046d5d2b2
b'2.10d40283545fcc9c0t5inCMDHpcJKQpxfOe2RbWJiWxbpLqgHXkHWJtAOJm0K1+a3FEGfff0Qa6bY4ZppJsm5uMafEvnzLLz/1MQ4v+fUbKRx+LOrUEbXCIlyiKbdg4SXZL9kLEC9aqKXAOwI'
Traceback (most recent call last):
  File "mq_pub_15.py", line 110, in <module>
    sys.exit(main())
  File "mq_pub_15.py", line 105, in main
    client.connect(broker)
  File "/usr/local/lib/python3.5/dist-packages/paho/mqtt/client.py", line 839, in connect
    return self.reconnect()
  File "/usr/local/lib/python3.5/dist-packages/paho/mqtt/client.py", line 962, in reconnect
    sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
  File "/usr/lib/python3.5/socket.py", line 712, in create_connection
    raise err
  File "/usr/lib/python3.5/socket.py", line 703, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused


URI:/gw.json?a=tuya.device.log.report&gwId=28478004840d8e604987&t=669&v=1.0&sign=7c59bb93f895d029b5bf760b15c3c8d6
WARN: unknown request: tuya.device.log.report (/gw.json?a=tuya.device.log.report&gwId=28478004840d8e604987&t=669&v=1.0&sign=7c59bb93f895d029b5bf760b15c3c8d6)
[I 190411 14:20:53 web:2246] 200 POST /gw.json?a=tuya.device.log.report&gwId=28478004840d8e604987&t=669&v=1.0&sign=7c59bb93f895d029b5bf760b15c3c8d6 (10.42.42.26) 23.00ms


URI:/gw.json?a=tuya.device.log.report&gwId=28478004840d8e604987&t=1269&v=1.0&sign=83977540640c77ded5b7b4884dec535a
WARN: unknown request: tuya.device.log.report (/gw.json?a=tuya.device.log.report&gwId=28478004840d8e604987&t=1269&v=1.0&sign=83977540640c77ded5b7b4884dec535a)
[I 190411 14:30:53 web:2246] 200 POST /gw.json?a=tuya.device.log.report&gwId=28478004840d8e604987&t=1269&v=1.0&sign=83977540640c77ded5b7b4884dec535a (10.42.42.26) 9.17ms
Listening on port 80
[I 190411 14:42:53 web:2246] 200 GET / (10.42.42.25) 6.56ms
[W 190411 14:42:55 web:2246] 404 GET /favicon.ico (10.42.42.25) 17.33ms
[I 190411 14:43:52 web:2246] 304 GET / (10.42.42.25) 3.95ms
[I 190411 14:43:56 web:2246] 304 GET / (10.42.42.25) 3.70ms
[I 190411 14:44:00 web:2246] 304 GET / (10.42.42.25) 3.66ms
[I 190411 14:44:29 web:2246] 304 GET / (10.42.42.25) 3.95ms
[I 190411 14:44:50 web:2246] 304 GET / (10.42.42.25) 5.29ms
[I 190411 14:45:15 web:2246] 304 GET / (10.42.42.25) 3.85ms

As you can see it fails here:

[I 190411 14:11:23 web:2246] 200 POST /gw.json?a=tuya.device.upgrade.silent.get&gwId=28478004840d8e604987&t=12&v=4.1&sign=2ceed6773de77f86fead15368b24f6e1 (10.42.42.26) 13.29ms
a4cfb0890d40283545fcc9c046d5d2b2
b'2.10d40283545fcc9c0t5inCMDHpcJKQpxfOe2RbWJiWxbpLqgHXkHWJtAOJm0K1+a3FEGfff0Qa6bY4ZppJsm5uMafEvnzLLz/1MQ4v+fUbKRx+LOrUEbXCIlyiKbdg4SXZL9kLEC9aqKXAOwI'
Traceback (most recent call last):
File "mq_pub_15.py", line 110, in
sys.exit(main())
File "mq_pub_15.py", line 105, in main
client.connect(broker)
File "/usr/local/lib/python3.5/dist-packages/paho/mqtt/client.py", line 839, in connect
return self.reconnect()
File "/usr/local/lib/python3.5/dist-packages/paho/mqtt/client.py", line 962, in reconnect
sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
File "/usr/lib/python3.5/socket.py", line 712, in create_connection
raise err
File "/usr/lib/python3.5/socket.py", line 703, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

I'll try to tap into the code ASAP but if you have any suggestion feel free to share it!!!

[kueblc]

@ohiaia Is this a BW-SHP6? It looks very different from the experience others are having. I think this belongs in a separate issue. The s.gw.token.get shouldn't be called if you had the same issue as the others in this thread.

The MQTT error is irrelevant, since the device made a call to tuya.device.upgrade.silent.get. It doesn't look like it requested upgrade.bin after that, so the issue lies with the fact the response was not what this particular device expected. So it will be very helpful to open another issue with device details.

[tifrei]

Following this as i have the same issue.

Stopped blinking and the dots are continuing but nothing happens

[melyux]

Same here. Identical device flashed two weeks ago, no problem. Today, the new one, all dots and nothing in the logs after the device does "group key handshake completed (RSN)".

[soloam]

Same problem with me! Not able to flash! Some time ago I flashed without any problems! Now only dots!

[joopy]

Not working here either with a brand new BW-SHP6

[kueblc]

It has been established that the BW-SHP6 is shipping with patched firmware, please note it may take us some time to work out a solution. In the meantime, if you need to flash these devices you will need to do it directly via serial.

[melyux]

Sorry, forgot to specify @kueblc: mine was a Martin Jerry switch. So it's not just Blitzwolf. I flashed it directly via serial. tuya-convert worked on an identical one a month ago though.

[kueblc]

Do you have any firmware backups to share?

[melyux]

Unfortunately flashed over it :/ I will be getting another Martin Jerry soon, so I will try to make a backup then.

Melik

On Apr 14, 2019, at 2:37 PM, Colin Kuebler [e-mail] wrote:

Do you have any firmware backups to share?

—
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/166#issuecomment-483048045, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ0a9f9UBTRWHREcCEQUE7Wj1Mr8WDgnks5vg4NfgaJpZM4cdHnB.

[DenielTorres]

Hi team! Thanks so much for working on this at all! I just wanted to check in how are you progressing with the new firmware issues? Thanks again!

[Niek]

Same issue here, the patched firmware tries to connect to a3.tuyaus.com:443 - no luck yet in trying to work around with a self-signed certificate of *.tuyaus.com - when I run a HAProxy instance in between I see a SSL Handshake failure (40) error in Wireshark.

[Niek]

Some further info: it seems that a3.tuyaus.com:443 requires a PSK-AES128-CBC-SHA256 cipher connection. The server provides the PSK hint 1dHRsc2NjbHltbGx3eWh, which is also present when running a strings on the firmware dump of @nightcat91 above. I assume the PSK is derived from this hint with some fixed string, but I haven't been able to find more info.

Command to check the connection:

echo "GET /gw.json" | openssl s_client -connect a3.tuyaus.com:443 -cipher PSK-AES128-CBC-SHA256 -ign_eof -psk $(xxd -p -u -c100 <<< "PSK_GOES_HERE")

(SSL alert number 20 means the PSK is incorrect)

[CervDotBe]

Is this also applicable on the BW-SHP2? Or those these still work with the OTA flashing? I was just thinking of buying some SHP2/SHP6 units.

[michamichamicha]

Do you have any firmware backups to share?

For what it's worth, I have the firmware for a Blitzwolf BW-SHP2 here:

blitz_shp-2-default_firmware.bin.zip

[m-kozlowski]

http://kotlet.empeka.pl/tmp/backup.shp6.201905102255.bin
from SHP6 HYS-01-033-WIFI_V1.4 bought last month

[Niek]

Both the images above contain the PSK hint 1dHRsc2NjbHltbGx3eWh5 as well as the magic string BAohbmd6aG91IFR1eVjaG5vbG9SBUwEwYDVLnRjbi5jb20xFTATBMMDCoudHVXVMGA1UEAYWlvbTEVMBMGA1UEA50dXlhYXM29QDDAwqLZi5xFTATBgNVBAMMDV5YXNhLmNTEwLKi53Zb20RBgNVBAMMCioud5jb20xFjAgNV5YS1pbMIILMAkGA1UEBhMCQAPBgNVBAgFpEwDwYDVQU5PVTEpMCcGA1UECFuZ3pob3UHV9sb2d5IVEQTBgNVBAMMDCoudNuLmNvbTEBM50dXlhdMRUDVQQDDAwqLnR1e5jb20xFTAgNV5YWpwLdKrrVrtLIAmOFcclWjM+5j0SmSB5FpnQg9h - anybody yet who managed to decompile the code to calculate the PSK?

[michamichamicha]

One 'interesting' thing I found was that: taking the first 20 characters of the long string (BAohbmd6aG91IFR1eVja), base64 decode it, it reads:
!ngzhou TuyXڀ
And Tuya has an office in HangZhou, China. Could be nothing...

Edit: And I found this in the string with base64 decode:
QÕåchnoloRLÁ€Õ.tcn.com1

[StevenReitsma]

Gosund SP1 (https://www.amazon.de/dp/B07B911Y6V) doesn't seem to be flashable anymore. I'm getting the same error as above. I can see in tcpdump that the devices are doing https requests. Any chance we will figure this out soon or should I just try flashing using serial? Let me know if I can do anything to help fix this issue.

[jokerigno]

Same error here.

I hope will be a fix because without tasmota quite useless

[yabolek]

Same here with SHP-6, unfortunately :( Watching this issue closely

[probonopd]

I think it is clear by now that devices cannot be flashed anymore after they have updated themselves. So please, if you encounter issues, mention whether your device was out-of-the-box, factory new, never connected to the app or the internet, or not. Thanks.

[yabolek]

Mine are out of the box factory new. Never connected to the internet etc. First thing I did, was trying to convert it. I had successes with previous plugs on the same setup.

[probonopd]

Damnit, does this mean they now come with a "too new" firmware from the factory? That would be a pity

[Niek]

@probonopd that's exactly the case since every device manufactured since around January this year it seems.

[sebastianklein96]

@Niek is there any way to verify the production date of a particular device?

[Niek]

@sebastianklein96 not sure about manufacturing date, but you can check the SDK version. Dump the firmware, then run strings firmware.bin | grep "OS SDK ver" - the ones posted in this thread (and mine) are all on OS SDK ver: 2.0.0(e8c5810) compiled @ Jan 25 2019 14:26:04

[jokerigno]

Same here: "Mine are out of the box factory new. Never connected to the internet etc. First thing I did, was trying to convert it".

[yabolek]

Small update from my side: Tried to enroll one of my sockets in tuya iOS and it worked fine. I remember someone saying that it should also fail in tuya. I have another socket still in box so I can test further

[ministryofsillywalks]

Another +1 for a brand new blitzwolf shp6 that already came with the new firmware.

[CervDotBe]

I guess there is no solution in the pipeline yet? :<

[kueblc]

Small update from my side: Tried to enroll one of my sockets in tuya iOS and it worked fine. I remember someone saying that it should also fail in tuya.

This is not correct, and connecting to the app will allow the device to update it's firmware if it isn't already, so I don't recommend this.

I guess there is no solution in the pipeline yet? :<

We'll keep you updated when we can release the workaround. We're all eager to open this door!

[sockd]

Today I got a Package with 4x SP111 ...
The first one worked (OS SDK ver: 1.4.2(78f3caf) compiled @ Oct 23 2017 13:45:35), the other 3 aren´t working with tuya-convert ...
Tomorrow I try to backup the firmware over FTDI and supply to you...

[Wiki591]

Just fyi: Blitzwolf BW-SHP5, brand new devices, are not flashable using tuya-convert either.

[jensbri]

Same goes for the Blitzwolf BW-LT11 (LED lights).

[ghost]

Some things I've been looking at with this if it helps-

• The encrypted partition @ 7b000-7fff0 uses AES128 ECB based on the encrypted blocks and strings in the ROM.
• The flash encryption key is unique per device based on the uploaded ROMs and my own. We can tell this because the of known plaintext weakness in ECB when encrypting the overwritten FFFF freespace. The MAC/Flash ID isn't long enough to be the key, but it may be derived from it.
• To be unique after an OTA update, the ROM must be encrypted after the download, by the server beforehand, or using a known key and re-encrypted. Has anyone attempted a manual flash back to an old version and a man-in-the-middle to see if the new ROM is delivered unencrypted?

[maschere]

Same problem seems to occur with the Gosund 8W wifi LED bulb. I bought a 2-pack - I could flash the first one flawlessly (though with the fork at https://github.com/kueblc/tuya-convert ), the second one stops blinking a few seconds after I start the OTA flashing, but nothing further happens.

[ghost]

An update if it helps. If not or if there is a more appropriate place to discuss, or if I should hush, please let me know.

• It appears that the flash is encrypted by the device if it is found to be unencrypted in the new firmware.
• The key remains the same between flash erases on the same device. It is confirmed different between devices.
• The device doesn't appear to arbitrarily encrypt the content of the user partition, but instead regenerates much of the content then encrypts it. The old firmware does this as well in an unencrypted fashion.

[tx992]

An update if it helps. If not or if there is a more appropriate place to discuss, or if I should hush, please let me know.

• It appears that the flash is encrypted by the device if it is found to be unencrypted in the new firmware.
• The key remains the same between flash erases on the same device. It is confirmed different between devices.
• The device doesn't appear to arbitrarily encrypt the content of the user partition, but instead regenerates much of the content then encrypts it. The old firmware does this as well in an unencrypted fashion.

Any update on this? I recently picked up a few dimmer switches with updated firmware. Was curious to dig in a bit and see if it was possible to identify the PSK somewhere in the image.

[Wiki591]

I'm not shure where to post my experience with the Server enhancements, probably I am wrong here, but:

Tried to flash Blitzwolf BW-SHP5, brand new device with the PR Server enhancements API additions - no success either.

What did I do:

sudo git clone -b enhance-api https://github.com/kueblc/tuya-convert.git
cd tuya-convert/
./start_flash.sh

Smartphone connected to AP
Device put into learn mode

The SHP5 starts in learn mode, connects (seen in log as mac 4f:22:9c:58:72), gets an ip address, looks like it gets the smartconfig, leaves learn mode (led stops flashing) and nothing more happens.

Logs:
smarthack-mqtt

1558626466: mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000) starting
1558626466: Using default config.
1558626466: Opening ipv4 listen socket on port 1883.
1558626466: Opening ipv6 listen socket on port 1883.

smarthack-smartconfig

Put Device in Learn Mode! Sending SmartConfig Packets now
Sending SSID vtrust-flash
Sending wifiPassword flashmeifyoucan
SmartConfig in progress
..........
SmartConfig complete.

smarthack-web

Listening on port 80

smarthack-wifi

Backing up /etc/dnsmasq.conf...
Writing dnsmasq config file...
Creating new /etc/dnsmasq.conf...
Writing hostapd config file...
Configuring AP interface...
Applying iptables rules...
Starting DNSMASQ server...
RTNETLINK answers: File exists
Starting AP on wlan0 in screen terminal...
Configuration file: /etc/hostapd/hostapd.conf
wlan0: Could not connect to kernel driver
Using interface wlan0 with hwaddr b8:27:eb:5e:bd:41 and ssid "vtrust-flash"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
wlan0: STA 54:ef:92:70:5a:b1 IEEE 802.11: associated
wlan0: AP-STA-CONNECTED 54:ef:92:70:5a:b1
wlan0: STA 54:ef:92:70:5a:b1 RADIUS: starting accounting session FC30DFC294BCDBAC
wlan0: STA 54:ef:92:70:5a:b1 WPA: pairwise key handshake completed (RSN)
wlan0: STA dc:4f:22:9c:58:72 IEEE 802.11: associated
wlan0: AP-STA-CONNECTED dc:4f:22:9c:58:72
wlan0: STA dc:4f:22:9c:58:72 RADIUS: starting accounting session 576B6A7361623F14
wlan0: STA dc:4f:22:9c:58:72 WPA: pairwise key handshake completed (RSN)
wlan0: STA 54:ef:92:70:5a:b1 WPA: group key handshake completed (RSN)
wlan0: STA dc:4f:22:9c:58:72 WPA: group key handshake completed (RSN)

[guergen1]

Has anybody flashed the new SP1?
I took the same, nothing works...

[tesarm]

Same for SP4

[EverythingSmartHome]

Had a look at this yesterday, again stuck with the PSK.

One silly question, would the PSK not need to be 16 bytes since we are working with AES128? I found 16 byte string in multiple firmwares: heeU2AWVxpxfqP6D

Although I'm not sure if this is a correct assumption to make? Although I do think they key and string need to be multiples of 16 at least?

[Niek]

@EverythingSmartHome where do you find that string? I can't find it in any of the firmware dumps above (when running strings). The string 1dHRsc2NjbHltbGx3eWh5 is in there though, which is part of the server PSK Identity hint 1dHRsc2NjbHltbGx3eWh50000000000000000 sent by the server (so 16 bytes of 0 appended).

[EverythingSmartHome]

@Niek Your right, my apologies, it was in one of my firmwares but not the other. My mistake!

I tried every combination I could think of yesterday but no dice. Frustrating as I think it is do-able!

[EverythingSmartHome]

@Niek I can't figure out how you get 16 bytes from string 1dHRsc2NjbHltbGx3eWh50000000000000000 - even running through xxd I get 38 bytes from this, or 22 bytes without the 0. Where am I going wrong?

[Niek]

@EverythingSmartHome sorry - I meant 16 0-characters postfixed after the string.

[EverythingSmartHome]

@Niek I follow you! So we still need to look for a 16 byte string for the PSK?

[forfuncsake]

I've got a different device that seems to come with the same firmware (https://blakadder.github.io/templates/brilliant_plug.html). Hooked up some wires today and backed up the flash - it contains the hint and the magic string identified by @Niek above.

I then took the TLS connection one step further by writing a tiny server that just responds with the same Server Hello/Hint/Hello Done packet every time; and discovered:

• The Client Hello -> Random always contains the start of the magic string (BAohbmd6aG) and sometimes contains more of the subsequent character in the following bytes.
• The Client Random doesn't always start with the magic string bytes, sometimes they're shifted in a few bytes with anything before them.
• After a valid server response, the client sends a Change Cipher Spec and Encrypted Handshake Message
• The Encrypted Handshake Message is 80 bytes and the first 16 bytes of which are always BAohbmd6aG91IFR1

[forfuncsake]

I ran a few more connections hoping to seem some repetition in the encrypted data when starting over, but it seems that the encrypted payload is always unique across my sample of 26 connections over 3 clean boots, while the Client Key Exchange PSK identity remains consistent on every attempt.

It seems OpenSSL 1.1.1c can act as the server, would be interested to know if the PSK client identity is the same for each device or unique per device.

To reproduce:

• follow the tuya-convert process but also start an open ssl server on port 443 of the OTA host with: openssl s_server -cipher PSK-AES128-CBC-SHA256 -tls1_2 -psk_hint 1dHRsc2NjbHltbGx3eWh50000000000000000 -psk 42416f68626d64366147393149465231 -nocert
• capture traffic on port 443 of the host

That PSK is seemingly not correct, it's just the 16 bytes mentioned in my earlier comment for initial testing.

My device is reporting the following in the Identity field:

0000   01 42 41 6f 68 62 6d 64 36 61 47 39 31 49 46 52   .BAohbmd6aG91IFR
0010   31 7e 41 df 6e 85 0d 5f ad e7 b7 da d1 5b f1 78   1~A.n.._.....[.x
0020   88 5f fa f4 2f ee 16 49 b9 1f 25 0d de e3 69 31   ._../..I..%...i1
0030   d6 da                                             ..

[Zn4rK]

I encountered the same problem with Neo CoolCam 16A EU version. I bought 10+ of these hoping that they were still flashable with tuya-convert.

I built myself a little programmer with pogo pins and my 3d printer, so I don't have to solder on the actual unit. So I can pretty easily dump a few more from the same vendor.

neo-coolcam-16A-eu-1MB-backup.bin.zip
neo-coolcam-16A-eu-1MB-backup-second-device.zip

Even though this issue is about the Blitzwolf, I figured that it might be interesting to have more dumps available.

[Niek]

For everyone that missed it, there is a solution in https://github.com/ct-Open-Source/tuya-convert/issues/273 - fork @ https://github.com/M4dmartig4n/tuya-convert

[kueblc]

Work from #273 is being considered for merge with PR #279