Blitzwolf BW-SHP6 connected but script does not continue

nightcat91 commented 5 years ago

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 commented 5 years ago

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?

IMG_20190404_175820 IMG_20190404_180115 IMG_20190404_175734

kueblc commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Read_Flash

kueblc commented 5 years ago

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

mclaudiopt commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

Following this as i have the same issue.

Stopped blinking and the dots are continuing but nothing happens

melyux commented 5 years ago

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 commented 5 years ago

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

joopy commented 5 years ago

Not working here either with a brand new BW-SHP6

kueblc commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Do you have any firmware backups to share?

melyux commented 5 years ago

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 notifications@github.com 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Niek commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Same error here.

I hope will be a fix because without tasmota quite useless

yabolek commented 5 years ago

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

probonopd commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Niek commented 5 years ago

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

sebastianklein96 commented 5 years ago

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

Niek commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

CervDotBe commented 5 years ago

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

kueblc commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

jensbri commented 5 years ago

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

ghost commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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)

ct-Open-Source / tuya-convert

Blitzwolf BW-SHP6 connected but script does not continue #166