Wyze Forcing New Firmware

[bjs-pdx]

It looks like Wyze is forcing new firmware onto cameras. Just noticed a V2 that was changed.

What is the best way to stop this. It’s going to break things.

[ltoolio]

What FW ver did you get forced to?

[bjs-pdx]

V2 - 4.9.9.3006

[bjs-pdx]

Here is the information from the config page:

[endertable]

The actual setting we need is what you have in your /opt/wz_mini/wz_mini.conf file. Look for a setting:

DISABLE_FW_UPGRADE=

to see if it is true or false.

Fortunately, for the V2 cam, wz_mini still works with the latest FW, but you may want to check your V3 cams for this setting as a FW update could break things on those for wz_mini. So far, Wyze has only tried updates on my V2's not on my V3's. Although most of my V3's are on FW 4.36.10.3406 or higher. I think they are ok if you are on at least 4.36.9.139 or higher for the V3 and anything less they may try forced updates, possibly so they don't have to support so many different API calls and security purposes.

[bjs-pdx]

So Wyze is forcing updated firmware in order to use the cameras in the app:

[dudududodododedede]

I'm seeing this too when I'm trying to view the cameras in the app Has anyone tried rolling back to an older version of the app?

[bjs-pdx]

I'm seeing this too when I'm trying to view the cameras in the app Has anyone tried rolling back to an older version of the app?

You can’t rollback on iOS.

[tismofied]

So Wyze is forcing updated firmware in order to use the cameras in the app:

I am seeing the exact same thing 😭

[gtxaspec]

someone on the old firmware, try:

Please write the following in /system/bin/app.ver file and restart.

V2:

[VER]
appver=4.9.9.3006

V3:

[VER]
appver=4.36.13.0416

taken from https://github.com/mnakada/atomcam_tools/issues/115#issuecomment-2336583807

see if it works.

[endertable]

On iOS you can also switch to another app real quick and switch back, and the box will be gone for the rest of the session.

[bjs-pdx]

Had to give up and accept the inevitable upgrade. Every time I tried to view a camera in the app the forced upgrade window would pop up with no way to close it. I was able to sneak past it by powering off the camera and, when I powered it back on, quickly clicking the setup gear icon. I had to reformat the SD Cards then run the update. Of course after that, no more wyze_mini_hacks.

This really sucks.

[gtxaspec]

@bjs-pdx you could try and downgrade, and try the fix i posted above

[bjs-pdx]

Not sure a downgrade is going to do anything. Wyze app checks the firmware and forces the upgrade. How does your suggested fix change that?

[gtxaspec]

the fix physically changes the firmware version reported by the device. icamera reads from that file to tell the fw ver

[bjs-pdx]

Okay...I see. But still don't know what breaks in the Wyze app when running older firmware. They are forcing this for some hidden reason but can't tell what that may be. This also may be the future of constant breakage.

[bjs-pdx]

Just to be clear, I think this project is great. I’m just done with Wyze. Seems like every month or so they make a change and things break. Tired of fighting a losing battle. Going to switch to Amcrest for my camera needs. Much more reliable.

[gtxaspec]

You can convert the wyze devices to a standalone firmware we've been working on... www.thingino.com. just FYI.

[bjs-pdx]

Not really something I want to do. Liked the idea of added functionality without losing the native functions.

[cad1231]

someone on the old firmware, try:

Please write the following in /system/bin/app.ver file and restart.

V2:

[VER]
appver=4.9.9.3006

V3:

[VER]
appver=4.36.13.0416

taken from mnakada/atomcam_tools#115 (comment)

see if it works.

That file appears to be read-only. How can I write to it?

Thanks!

[endertable]

You can’t on the V3 camera, but you should be able to alter the file that is in the /configs directory. Supposedly, that is the file that I camera reads…

[cad1231]

I tried changing /configs/app.ver - it doesn't do anything, just reverts to the old app.ver (even in /configs) on reboot.

[cad1231]

@gtxaspec do you have any other ideas? The thread on atomcam-tools that you linked said that the person had to update the firmware for this trick to work. I upgraded wz-mini-hacks using the shell script, but changes to /configs/app.ver still don't stick after a reboot. I have the wyze cam v3. Thanks!

[gtxaspec]

i'll have to setup a wyze device ( i dont currently have any setup with stock firmware ) I'll try to restore one soon and test

[sideup66]

Note that we should try to find out WHY its updating. I asked in the discord and WyzeJason told me it was due to a bug? (what bug im not sure)? However, if it is a certificate change wyze did on their end and the newer apps potentially have newer certs where the old will expire soon, that may be the reason for the force. I did upgrade as well as I needed things functioning and now note that a change im noticing is that wyze seems to be trying to use a hardcoded dns server and trying to bypass dnsmasq. Im seeing strange behavior where the local app is pinging api.wyze every minute. My DNAT rule at my router is successfully dnating this to pihole, but it is strange behavior regardless. I took a look at wz_mini to see what can be done, and know I have a firewall present, which I tried to configure to simply dnat the traffic to the local dnsmasq instance, but NAT doesnt seem to be present in the kernel and isnt addable via lsmod by what I can see. Might be something to look into if we need to upgrade it.

[sideup66]

Figured out the dns issue. Seems like wyze took a page out of our book :) and now runs dnsmasq by default on the device. Ours fails because the address is bound by their instance, plus on the newest firmware the build of dnsmasq in firmware is newer than the one present on wz_mini. I was able to address the DNS noise issue by killing the watchdog process they run for it + dnsmasq, running the copy as in the init file for resolv.conf, then starting the Wyze copy of dnsmasq with our config file (using -C argument.) after work ill submit a PR tonight with the fix so it can be integrated into the tree. Can include an if statement easily enough to check the existence of the system dnsmasq and if not present, simply use the wyze_mini one.

[cad1231]

i'll have to setup a wyze device ( i dont currently have any setup with stock firmware ) I'll try to restore one soon and test

Thanks!

[sideup66]

See here for a updated dnsmasq script that is compatible with the newer firmware beyond 4.36.9.139. Also sent @gtxaspec a PR for upstream so its included here. https://github.com/gtxaspec/wz_mini_hacks/pull/789

[endertable]

@sideup66 hi, what FW version did you upgrade to that had all these changes? Does the newer firmware allow wz_mini functionality again?

[sideup66]

I am on 4.36.13.0416. Aside from dnsmasq, I am not sure if the way firmware is pushed may have changed. That should be investigated as well.

On the newer versions, you won't have RTSP still but wz_mini still has root shell on the device. I am simply updating the Dnsmasq script in my PR to utilize the built-in dnsmasq binary from wyze if it exists, it seems more up-to-date currently than the one present in wz_mini and I included logic for both, so the script should be able to detect one way or the other and effectively let you configure dnsmasq with our configuration file.

[qip]

To continue view my wyze V3 on the app, I've the following quick fix:

In /media/mmc/wz_mini/etc/rc.d/S10firmware, add:

echo -e "[VER]\nappver=4.36.13.0416" > /opt/wz_mini/tmp/patched_app.ver
mount --bind /opt/wz_mini/tmp/patched_app.ver /system/bin/app.ver

somewhere between if [[ "$DISABLE_FW_UPGRADE" == "true" ]]; then and else.

After that, restart the camera.

This fix is effective for immediate needs (I just want to check if my package is delivered on my phone right now), I guess it could be better to move this code to rc.local.d or somewhere more appropriate.

[cad1231]

@qip thank you, that worked!

[sideup66]

To continue view my wyze V3 on the app, I've the following quick fix:

In /media/mmc/wz_mini/etc/rc.d/S10firmware, add:

echo -e "[VER]\nappver=4.36.13.0416" > /opt/wz_mini/tmp/patched_app.ver
mount --bind /opt/wz_mini/tmp/patched_app.ver /system/bin/app.ver

somewhere between if [[ "$DISABLE_FW_UPGRADE" == "true" ]]; then and else.

After that, restart the camera.

This fix is effective for immediate needs (I just want to check if my package is delivered on my phone right now), I guess it could be better to move this code to rc.local.d or somewhere more appropriate.

Now heres another question, if one is full self-hosting this is a non-issue. However, if you are relying on wyze services for anything....there may be a good reason to force the firmware update (im going to take a stab and say they possibly moved to newer certificates in the new firmware that are about to expire in the old). Do we know what that is? My last talk with them was a vague "oh a bug was fixed". I worry that if they are forcing people off the old firmware, cloud level things may change that will break functionality of the older fw.

Also, we should test the scripts in newer fw to ensure things are working. Despite losing RTSP in newer, we still have full root shell on the device and those supporting scripts are still useful. I already fixed dnsmasq for newer above and sent a PR to @gtxaspec for it. We should confirm the firmware blocker still works as well. My fear is everyone will hack the old firmware to cling on, then wyze will break something at the cloud level and everyone will whine and be forced to upgrade. We should have the devices setup for all scenarios in either sense IMO.

[gtxaspec]

they could easily change the stuff at the cloud level to break this, for some reason they haven't, yet. I would take anything customer service or media reps say with a grain of salt, they simply aren't privy to real engineering information. Firmware blocker should still work as well, the method to upgrade fw has not changed. eventually, one day, it will break, but not yet.

[sideup66]

No problem, I am just considering both sides here. A certificate update could break the legacy firmware theoretically.

If one is interested in not using wyze at all, they should just move to their own firmware at this point. dafang is pretty mature and so is thingino with constant updates.

[gtxaspec]

If i recall correctly from analyzing the binary before, they have the ability to remotely update certificates, so hopefully this wouldn't be the case.

I'll add the fix mentioned above to the official release later today. Hopefully wz_mini still has a long life to live =D

[sideup66]

It definitely has a long time to go yet. Even if RTSP is gone in newer firmware, its still insanely valuable for giving root access to the camera shell.

Id be curious to see a comparison of the latest firmware to 4.36.139 to exactly see what has changed in the icamera binary and why. We know about rtsp, but what else? It may give clues to why they forced it.

[bjs-pdx]

I'm disheartened by what Wyze did. They forced the update with no easy way to avoid it and fix the problem. I had two cameras offline due to the update and was annoyed that the Wyze pop-up screen prevented any access to the camera or any ability to close that pop-up. The only way I found around it was to force close the app. Even then, every time I tried to access the live view of my V3 cameras the pop-up returned making them totally useless.

For now, I'm running the Wyze firmware without this software. I had to do manual firmware updates via sd card on two of the cameras. I finally got around the pop-up by turning the cameras off, then turning them back on and quickly pressing the settings icon. I then reformatted the sd cards in the cameras containing the wyze_mini_hacks software, rebooted and allowed the firmware to update.

Too much trouble for now. I'll watch for updates here and consider running this again if things seem stable.