Open Semag opened 2 years ago
Most likely the case. Wyze will likely disable the ability to view a camera that doesn't meet minimum firmware requirements in their app, leaving us to decide on either choosing the RTSP route (with NFS) and removing the camera from the Wyze ecosystem and using third party applications or staying within the locked-down Wyze ecosystem.
That super bums me out because I have a whole home brew person detection built on the motion capture images the Wyze cams captures.
I would feasibly move to Dafang or RTSP but I don’t think either maintains the on camera motion detection, which saves the ever present wireless bandwidth of rtsp monitoring.
unless someone else is aware of a way to offload the motion detection to the cameras and bring in extra processing only on demand when something is happening?
If your Wyze cams have already been jailbroken with Wyze hacks, do the hacks survive the update to recent firmwares? I don’t remember exactly but I had some old firmware (v3) installed and jailbroken and updated to 4.36.2.5 and the hack survived but I haven’t updated since as the setup is very stable
I believe the newer ones that change the root password definitely kill the Wyze hacks.
Most likely the case. Wyze will likely disable the ability to view a camera that doesn't meet minimum firmware requirements in their app, leaving us to decide on either choosing the RTSP route (with NFS) and removing the camera from the Wyze ecosystem and using third party applications or staying within the locked-down Wyze ecosystem.
Could we just spoof the firmware version on the camera?
For compatibility, we may need to be on a 4.x.6.241+ firmware that uses the Connect_ByUIDEx method for DTLS/authkey support if they decide to deprecate Connect_ByUID_Parallel.
I believe the newer ones that change the root password definitely kill the Wyze hacks.
Is it possible to apply a patched updated firmware manually (via telnet) while we are still jail broken
I'm also trying to modify the firmware file. I suspect that on recent firmwares Wyze implemented some additional verification. I suspect a sign/hash is appended to the firmware file (64 bytes). At this moment i don't see which technique is used. This is probably also the reason that Wyze is pushing the new firmwares.
@nijhawank you can do an in-app upgrade on V3 cams from your current 4.36.2.5 to 4.36.3.18 and the hack will survive. I was running on 2.5 for a long time like you and decided to try this week. 3.18 is that intermediate version Wyze requires before going to latest. Upgrading from 3.18 to latest will kill the hack. If you want to test you can always downgrade using SD card and apply the hack again. I've been doing it by downgrading to 4.36.0.280 -> apply hack -> upgrade in app to 4.36.3.18.
Has anyone been able to get the hacks version 1 to apply to v3 cams? I'm having a hard time getting the bootloader unlock image to install on the camera. wyze_updater.py shows unauthorized operation. SD card install logs show bootloader checksum mismatch.
I had an experience where one of my recently purchased V3s could not be hacked regardless of firmware version, but a V3 purchased back from initial release was. The more recent V3 had a MAC starting with "D0:xx:xx" and the initial release has a MAC of "2C:xx:xx"
Interesting, I've been trying on a newer v3 with MAC "7c". I will try with my older v3 with MAC "2c"
Same issue
Traceback (most recent call last):
File "./wyze_updater.py", line 433, in
I followed the post https://github.com/HclX/WyzeHacks/issues/138#issuecomment-1002436875 to get Wyzehacks on the V3 last week. It required spoofing the DNS addresses for specific URLs based on device type and using the "WyzeUpdater.py"
Yeah I can confirm for @jk111 that my v3 has a max starting with 7C:73:B2 so the DNS spoof will work there. It does need to be on version 4.36.2.5 or earlier though.
@nijhawank you can do an in-app upgrade on V3 cams from your current 4.36.2.5 to 4.36.3.18 and the hack will survive. I was running on 2.5 for a long time like you and decided to try this week. 3.18 is that intermediate version Wyze requires before going to latest. Upgrading from 3.18 to latest will kill the hack. If you want to test you can always downgrade using SD card and apply the hack again. I've been doing it by downgrading to 4.36.0.280 -> apply hack -> upgrade in app to 4.36.3.18.
So what you are saying is that we can always downgrade from any latest version and reapply the hack? Doesn’t the new version block downgrades?
Up until 4.36.3.18 or so (not sure about the newest versions) you can still downgrade via the SD Card method. I'm not sure if they're going to block that moving forward.
The real big question is: is there a way to block them from updating the cam firmware? Is updating the VER.txt file enough or does it do other checks?
Don’t you think if we put in the amazon s3 bucket dns redirect they won’t be able to remotely update? Unless they change the software location
The real big question is: is there a way to block them from updating the cam firmware? Is updating the VER.txt file enough or does it do other checks?
You mean app.ver? I don't think it does other checks, but they changed the connection method to use DTLS a couple of versions ago due to the tutk vulnerability and the KVS stuff for WebRTC streaming, so those could break if on an older build?
Don’t you think if we put in the amazon s3 bucket dns redirect they won’t be able to remotely update? Unless they change the software location
Don't the cameras go into a reboot loop if they can't phone home? I wonder if they'd do the same if unable to download the firmware..?
perhaps if we can block new updates, flash the new firmware manually, so the camera doesn't reboot automatically, then re flash the modified wyzehacks firmware, then wyzehacks will only require old firmware to initially install... hmm...
The real big question is: is there a way to block them from updating the cam firmware? Is updating the VER.txt file enough or does it do other checks?
You mean app.ver? I don't think it does other checks, but they changed the connection method to use DTLS a couple of versions ago due to the tutk vulnerability and the KVS stuff for WebRTC streaming, so those could break if on an older build?
Don’t you think if we put in the amazon s3 bucket dns redirect they won’t be able to remotely update? Unless they change the software location
Don't the cameras go into a reboot loop if they can't phone home? I wonder if they'd do the same if unable to download the firmware..?
So does anyone know how we can update the app.ver file, especially on v3 because I believe that is a read only mount.
I like this flash/apply new firmware manually idea. Any idea how to do this?
Yesterday I tried these experiments: Experiment 1:
Experiment 2:
@endertable app.ver inside rootfs could be changed by changing rootfs. It should anyways be possible to apply such patched rootfs by downgrading to 4.36.2.5 using SDcard recovery and then using a modified wyzehacks that also uses modified rootfs with patched app.ver
@endertable app.ver inside rootfs could be changed by changing rootfs. It should anyways be possible to apply such patched rootfs by downgrading to 4.36.2.5 using SDcard recovery and then using a modified wyzehacks that also uses modified rootfs with patched app.ver
Thanks, the only issue I see is when Wyze starts forcing the updates, I imagine that as soon as the Cam boots and sees it is not using the latest update, it will automatically update and at that point not allow Wyze hacks to work anymore, so even if you downgrade with SD card, it will automatically update upon the reboot to a new minimum version.
I liked @gtxaspec idea of us manually updating to newminimum version, but that would mean Us dissecting the firmware and running all the flash_erase and flashcp commands ourselves, probably through a script. Question is, does anyone know how to dissect the wise firmware bundles?
does it really fail if it can't phone home? no one can operate (as in leave it recording to the SD card) these without them connected to the internet? If so, could we spoof the phone home and block access to AWS?
I think a couple of my cameras auto updated to the latest firmware...
What models? What firmware did it update to? Estimate as to when it happened?
Feb 15, 02:15 EST, autoupdated to 4.9.8.501, update was pushed thru s3.us-west-2.amazonaws.com
Does anyone know the good camera brand\model that can write to nfs on stock firmware without a shaman dance? It turns out like wyze is going to a trash bin very soon.
4.9.6.241
> 4.9.8.501
FYI, I'm running the beta app to test compatibility with my wyze bridge, and noticed some of the cams had DTLS turned on.
Some of my cams remained on 4.9.6.241
, while the one on the latest firmware also remained on 4.9.8.860
V2 updated to 4.9.8.501 about a week ago.
It’s in a remote location and went dead in mid January around the time wyze was emailing me telling me to update my app and firmware. Came back to life about a week ago with a newer firmware.
On Feb 15, 2022, at 6:32 PM, virmaior @.***> wrote:
What models? What firmware did it update to? Estimate as to when it happened?
— Reply to this email directly, view it on GitHub https://github.com/HclX/WyzeHacks/issues/145#issuecomment-1040999594, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMWYVN2K7FOIH7YJQP3U3L5BFANCNFSM5LNUTXGA. 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&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.
I have 5 V3s. It looks like it just forcibly updated 4 of them which were on 4.36.0.252 to 4.36.3.18. The one on 4.36.2.5 has not been updated yet.
4.36.3.18 still has the same password, functioning telnet, and functioning boa... Rather unhappy about this. Will probably switch to RTSP firmware and use stream capturing.
10 minute later it forcibly updated them 4.36.3.19. I've now removed their subnet completely from the internet to avoid further updates.
2022-02-19 was able to do a manual downgrade to 4.36.2.5 and reapply the hack for 4 cameras that autoupgraded. Steps involved:
How can we block the update?
If I block this domain in my OpenDNS and in my router would that work?
s3.us-west-2.amazonaws.com
@Vendo232 that wasn't the domain they used at least for V3 updates. My V3s were on a subnet where I left that domain spoofed and they were still able to "upgrade" them remotely.
Looks like we're dead in the water for now?
was able to reinstall Wyzehack and install HTTP stream hack for my use on Frigate. All 3 my Wyze V3 work now great.
here is the guide
@Vendo232, that is awesome. Thank you so much for doing this and documenting it.
Did we ever get a fix for this?
If you can downgrade to 4.36.0.280, I have a method to modify the firmware and flash the latest stable release with telnet enabled, you need to have an SD card in the unit...it's not wyzehacks...yet, but you can run commands in telnet or a script on boot.
If you can downgrade to 4.36.0.280, I have a method to modify the firmware and flash the latest stable release with telnet enabled, you need to have an SD card in the unit...it's not wyzehacks...yet, but you can run commands in telnet or a script on boot.
This sounds awesome, then I can upgrade to latest and get back online. 😀
@endertable, if you are experienced try:
@gtxaspec what an update ! so no compilation is required now? I hope @FiveLeavesLeft will find time to update the stream hack for wz_mini_hacks!
will try today the new update on RTSP and LAN cable
trying to revert my pan cam v1. but cannot find older firmware anywhere. anyone got a copy or download link? thanks
Did anyone see the email today about enforced firmware updates? I’m wondering if we black hole the s3 amazon address if it will prevent the upgrade? Also do you think the new app version will drop support for the older firmware?