Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking changes to Wyze API #9

Open
elahd opened this issue Jul 14, 2021 · 17 comments
Open

Breaking changes to Wyze API #9

elahd opened this issue Jul 14, 2021 · 17 comments

Comments

@elahd
Copy link

elahd commented Jul 14, 2021

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

@mandusm
Copy link

mandusm commented Jul 16, 2021

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
Copy link
Owner

HclX commented Jul 17, 2021

@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
Copy link

@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
Copy link
Author

elahd commented Jul 22, 2021

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

@HclX
Copy link
Owner

HclX commented Jul 22, 2021

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

@HclX
Copy link
Owner

HclX commented Jul 22, 2021

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

@mandusm
Copy link

mandusm commented Jul 27, 2021

@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
Copy link

krayj commented Aug 20, 2021

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
Copy link
Owner

HclX commented Aug 20, 2021 via email

@fmdev1
Copy link

fmdev1 commented Aug 22, 2021

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
Copy link

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
Copy link
Owner

HclX commented Oct 31, 2021

@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
Copy link

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
Copy link

crossan007 commented Feb 11, 2022

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
Copy link

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
Copy link

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
Copy link

sorphin commented Feb 19, 2024

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)..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants