Breaking changes to Wyze API

[elahd]

It looks like Wyze killed WyzeUpdater's approach to loading third party firmware. See elahd/esp2ino#16 (comment). Thoughts?

[mandusm]

I was able to work around this with some DHCP / DNS and a slight edit of LINE 257 in wyze_updater.py.
What I can confirm is 1: The device does check for Valid SSL Certs so using SSL does not work, 2: It doesn't care if you don't use SSL so simply passing HTTP as the update URL passes the Wyze API check.

LINE 257:

            url = "http://s3-us-west-2.amazonaws.com/wuv2/upgrade/WLPP1/firmware/1.2.0.80a.bin"

---

Full Log of Update

Device type:      Camera (WYZE_CAKP2JFUS)
Device name:      Living Room Cam
Firmware version: 4.36.2.5
IP Address:       192.168.88.154

Pushing firmware to this device? [y/N]:y
INFO:root:Serving firmware file '../installer/firmware.bin' as 'http://s3-us-west-2.amazonaws.com/wuv2/upgrade/WLPP1/firmware/1.2.0.80a.bin', md5=e1b30c480e83eb374ff781ac58149076
DEBUG:root:{'provider_key': 'WYZE_CAKP2JFUS', 'action_key': 'upgrade', 'instance_id': '<redacted>', 'custom_string': '', 'action_params': {'url': 'http://s3-us-west-2.amazonaws.com/wuv2/upgrade/WLPP1/firmware/1.2.0.80a.bin', 'md5': 'e1b30c480e83eb374ff781ac58149076', 'model': 'WYZE_CAKP2JFUS'}}
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.wyzecam.com:443
send: b'POST /app/v2/auto/run_action HTTP/1.1\r\nHost: api.wyzecam.com\r\nUser-Agent: okhttp/3.8.1\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nContent-Length: 781\r\nContent-Type: application/json\r\n\r\n'
send: b'{"access_token": "<redacted>", "app_name": "com.hualai", "app_version": "2.11.40", "phone_system_type": "2", "app_ver": "com.hualai___2.11.40", "phone_id": "<redacted>", "sc": "<redacted>", "sv": "011a6b42d80a4f32b4cc24bb721c9c96", "ts": 1626475178000, "provider_key": "WYZE_CAKP2JFUS", "action_key": "upgrade", "instance_id": "<redacted>", "custom_string": "", "action_params": {"url": "http://s3-us-west-2.amazonaws.com/wuv2/upgrade/WLPP1/firmware/1.2.0.80a.bin", "md5": "e1b30c480e83eb374ff781ac58149076", "model": "WYZE_CAKP2JFUS"}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Cache-Control, Accept, authorization, content-type
header: Access-Control-Allow-Methods: POST,GET,OPTIONS
header: Access-Control-Allow-Origin: *
header: Cache-Control: no-cache
header: Content-Type: application/json; charset=utf-8
header: Date: Fri, 16 Jul 2021 22:39:00 GMT
header: Expires: -1
header: Pragma: no-cache
header: Server: Microsoft-IIS/8.5
header: X-AspNet-Version: 4.0.30319
header: X-Powered-By: ASP.NET
header: Content-Length: 171
header: Connection: keep-alive
DEBUG:urllib3.connectionpool:https://api.wyzecam.com:443 "POST /app/v2/auto/run_action HTTP/1.1" 200 171
DEBUG:root:{'ts': 1626475140865, 'code': '1', 'msg': '', 'data': {'session_id': '<redacted>', 'action_session_id': '<redacted>', 'custom_string': ''}}
DEBUG:root:request received, path=/wuv2/upgrade/WLPP1/firmware/1.2.0.80a.bin
192.168.88.154 - - [16/Jul/2021 15:39:40] "GET /wuv2/upgrade/WLPP1/firmware/1.2.0.80a.bin HTTP/1.1" 200 -

[HclX]

@mandusm Are you redirecting s3-us-west-2.amazonaws.com to your local IP address using DNS/DHCP spoofing or similiar? It's also interesting that they now support http. I remember it wasn't working before which is why you needed to do https.

[gtxaspec]

@mandusm Are you redirecting s3-us-west-2.amazonaws.com to your local IP address using DNS/DHCP spoofing or similiar? It's also interesting that they now support http. I remember it wasn't working before which is why you needed to do https.

can confirm, working, I used dnsmasq on my local openwrt router and was able to update the WYZEDB3. You must also use port 80.

[elahd]

Thanks, all, for putting the time into this. I'm going to work on packaging this into something more universal / distributable.

[HclX]

@elahd If you make a PR of this I can test it out and merge it into the master repo.

[HclX]

I guess for people with blubs/sockets they should convert theirs into tasmota compatible and forget this mess forever.

[mandusm]

@mandusm Are you redirecting s3-us-west-2.amazonaws.com to your local IP address using DNS/DHCP spoofing or similiar? It's also interesting that they now support http. I remember it wasn't working before which is why you needed to do https.

Hi, apologies for the slow response.
Yes, I used DNSMASQ to do DNS Spoofing on my local network.

I've been thinking about how we could build an integrated solution for WyzeHacks and the best way would be like they do in tuya-convert. Having the user use a USB Wifi Adapter, and then broadcasting a custom AP with hostapd that the camera connects to and using DNSMASQ to capture the DNS requests from the camera.

It's about 3 hours worth of work for me to do this, but I am weary of building it, since I have no doubt Wyze is tracking this repo, and for them to fix this, they quite simply just need to add http to their exclude list in the API this will no longer work. We will never be able to sign S3 https requests.

[krayj]

Does anyone know if the workaround is still viable? I'm thinking of trying this but if wyze has already excluded http then there is no point. Also, the referenced lines in wyze_updater.py are no longer valid, it looks like that file has undergone some revisions since the workaround was described.

[HclX]

The OTA method is pretty much dead now. I think this project finally gain their attention. Even if we manage to find a new security hole, fixing it is just a matter of time. As owner of this project I feel bad, but as a general user Im glad they started looking into security issues. So it might not be a bad thing.

…

On Fri, Aug 20, 2021, 12:07 Kevin Jones ***@***.***> wrote: Does anyone know if the workaround is still viable? I'm thinking of trying this but if wyze has already excluded http then there is no point. Also, the referenced lines in wyze_updater.py are no longer valid, it looks like that file has undergone some revisions since the workaround was described. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZNWD3LLSD3RTOL7BMGBGDT52RYNANCNFSM5AKLOBCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[fmdev1]

Such a bummer. I just tried the process also, and getting the same
RuntimeError: Request failed, error 3005:UnauthorizedOperation
Hoping some workaround for this pops up. Any alterative methods of flashing via arduino or other hardware flashing method?

[gtxaspec]

Looks like dns spooing works with the V3 up to firmware 4.36.3.18, after that it breaks. Looking at the contents of the firmware upgrade .tar's , would there be a way to intercept and stop the upgraderun.sh file? And flash the partitions manually, after modification... effectively blocking OTA updates, something like replacing flashcp and flash_eraseall binaries with dummies holding up the script execution... @HclX I know you must be super busy, would you have any info, notes or comments on this?

this won't help the newer cameras that force https and the locked bootloader, but will continue the viability for existing models.

[HclX]

@gtxaspec Yes, this year is quite busy for me so I haven't spent too much on wyzehack. Here is what I have regarding the current situation:

1. Apparently Wyze is working on blocking this hack from both server side and device side. So we need to accept the fact that whatever new loopholes we discover, they will be blocked again by Wyze. OTA installation is pretty much dead.
2. Still, there is one big loophole I think Wyze might not be able to block which is the SD card recovery method. So we can still flash the Wyze camera with modified firmware using this method.
3. I made some changes in "v2" branch for installing wyzehack using SD card recovery method, but it's far from working state. You also need to "unlock" your v3's bootloader so you can flash custom firmware -- which can be done by downgrading the camera firmware first, and then dns spoofing to run custom command.
4. OTA update can be blocked with modified firmware as well.

[crossan007]

I just tried the DNS redirect method (changing line 257 to url = "http://s3-us-west-2.amazonaws.com/wuv2/upgrade/WLPP1/firmware/1.2.0.80a.bin") and it seems that my V3 camera received the command to download new firmware; however, it gets stuck with a blinking purple light.

Rebooting the camera seems to return to old RTSP firmware (4.61.0.3)

Am I doing something wrong, or is this method now also likely dead?

[crossan007]

SUCCESS!!

I was able to OTA-update from the Wyze-Official RTSP firmware (4.61.0.3) to this firmware using the DNS method and the python uploader with a rather large caveat: the HTTP server built into the python script didn't seem to be responding to the URL request with the firmware file. I, instead, set up a separate HTTP server on my device with the directory structure of the "authorized" url (wuv2/upgrade/WLPP1/firmware/1.2.0.80a.bin), and the V3 camera seems to have downloaded the file, and I now have root telnet access!

EDIT:.

It seems like the latest build of the updater script correctly listens on the HTTP port, so you can use this command ./wyze_updater.py --token ~/.wyze_token update -d <camera_mac> -f directory/to/hacked/firmware.bin --url-host 's3-us-west-2.amazonaws.com' --url-path 'wuv2/upgrade/WYZE_CAKP2JFUS/firmware/4.36.3.19.tar' -p 18080 (Courtesy of HclX/WyzeHacks#138 (comment))

Then, the default login should be: HclX/WyzeHacks#112 (comment)

[virmaior]

Either you left out that you modified WyzeHacks or what you're saying doesn't make sense. v3 RTSP firmware versions are not supported under the current script (https://github.com/HclX/WyzeHacks/blob/master/wyze_hack/main.sh). It should show have an error in the installlog saying "WyzeHack: Wyze version not found!!!"

[RayMarDesign]

Thanks for all this! Without it I wouldn't have managed to switch my two Wyze plugs over. Both were original WLPP1 running 1.2.0.80 firmware.

I had initially DNS-spoofed s3-us-west-2.amazonaws.com to the computer I was running the updates from but was not seeing requests reaching it. Ended up getting frustrated and directing it over to a local network httpd after hardcoding url and commenting out server from the next line (only because my laptop wasn't letting me run the script otherwise because it couldn't start the server).

Afterwards I looked at the logs of my DNS (AdGuard Home) and realized why it wasn't working initially; the plugs were requesting the DNS with the port included! s3-us-west-2.amazonaws.com:18080 was shown multiple times (and not flagged as redirected).

Not sure if running with --ssl would have worked, but it appears custom ports are a not an option.

[sorphin]

Just for reference.. I had/have some old pre 2021 plugs (that were running 1.2.0.56).. tried it, got the plugs to accept the firmware using --ssl, dns spoofing, etc... and.... they worked... with V0.4... (I thought they had bricked, but then when I hooked up after cracking them open, I saw the esp2ino AP)..