UART/Serial on Wyze cam v3 about wyzehacks HOT 20 OPEN

You can do it and that's how I develop and debug wyzehacks. Unfortunately a recent beta firmware shows they changed the root password so you won't be able to login on that serial console unless you crack the password.

Also, the USB cable on v3 is actually not only for power. If you have a USB OTG cable you can power the camera and extend the data pins to another UART port. That UART port does a bunch of functionalities mostly for factory testing, but I think it's also how it talks to the light accessory.

from wyzehacks.

it looks like someone put together a well-featured alternate firmware for the atomcam and atomcam2. Would it be able to run on wyze cams?

https://honeylab.hatenablog.jp/entry/2021/09/24/002107

I can read/write Japanese but my wife will be livid if I brick one of the cameras observing our flying squirrel.

from wyzehacks.

So a few updates here...

From left to right (last pin is closest to the SoC and is wide), it's RXD, TXD, and ground. My scope suggested it was 3.3V. I have it running at 115200 baud right through the U-Boot.

Unfortunately, there's not great news on the new password. With 4.36.8.32 (The latest I grabbed), the password has been changed to a SHA512 with a salt of "wyzecamv3". Needless to say, it isn't going to be easy.

I'm fairly junior when it comes to working with squashfs images, but there is some good news... You can boot certain T31 images using the boot header factory_t31_ZMC6tiIDQN, which seems to be used in some devices that are nearly identical to the Wyze gear (who's the chicken, and who's the egg?).

https://www.atomtech.co.jp/products/atomcam
https://www.atomtech.co.jp/products/atomcam2

Unfortunately, it appears as though the issue with my V3 does seem to be hardware related to the wifi Realtek 8189, or at least communication with it. My boot fails with all firmwares (including a modified Atom firmware) with the below error:

mmc1: error -145 whilst initialising SDIO card

I'm not thinking it's a bus issue, as the SD card registers properly at mmc0, so I'm at a stalling point for now on chasing that. I'm more than happy to try getting information through the serial console. However, I need to get the new shell password first. I can confirm that 'root' is still the only account on the new images.

from wyzehacks.

Gotcha, I looked at the salted passwords you posted in the other thread… they look like they would take forever to break.

Side note, I keep getting half garbled output from the serial connection… broken chars and then a few lines of actual stuff… then broken chars. I might just have to get a real FTDI and USB OTG cable instead of playing with the raspberry pi. 😂

from wyzehacks.

Does WYom20200 work as the password for the newer firmware?

from wyzehacks.

Does WYom20200 work as the password for the newer firmware?

Can anybody confirm if this password works on the recent firmware like 'demo_v3_RTSP_4.61.0.1' ?

from wyzehacks.

from wyzehacks.

Ok thank you for this information.
I did manage to connect the UART via the three pins. The middle pin was what allowed me to see the terminal output of the camera. Unfortunately I guessed wrong connecting the other pins and have damaged my camera. (Doh)
The camera continuously reboots and does not show any terminal output any more. Grrr.

from wyzehacks.

Has anyone been able to figure out which pin does what? Based on your previous post, I gather the middle pin is TX but not 100% sure.

from wyzehacks.

I did try booting the modded SD card firmware, but there is some work due to the different EEPROM structure of our cameras.

However, it gives me a kernel option now to boot and read data otherwise locked away, and potentially at least find a workaround for the password on a per-camera basis. Unfortunately, I'll need to set up a linux environment to start messing with the squashfs.

from wyzehacks.

@virmaior thanks! this is just what we needed.

from wyzehacks.

@gtxaspec if you need me to liase in any way, I can try to get in contact with the developer!

from wyzehacks.

Just a small progress update on my side tests...

I've managed to slap together a stripped down version of https://github.com/bakueikozo/atomcam_tools, but swapped out the secret file from Wyze's older firmware. I can then boot to the shell and use the WYom20200 root password to sign in.

The cool thing is that the factory boot image will autoboot if in the SD slot without pressing buttons, there may be a way to run a completely RAM-only based hack with no flashing of the camera.

Here's the annoying caveat: The atomcam kernel seems to use less GPIO currently, so we need to find a way to boot the Wyze one. However, booting the Wyze image from the tempFS causes some fun issues as it tries to automount the SD card causing a kernel panic.

That being said... I may be able to use the SD boot solely to reflash the MTD partition for the core OS to update the password file to the old password and reset. I'm still in the process of figuring out the exact flow (and risks), but here's what I have right now:

1. Autoboot custom rootfs from SD card without operator intervention
2. Successfully modded init.d to run without user entry on the console (sadly haven't figured out the exact mapping for the speaker to play custom files for progress)
3. Mounted MTD partitions from the 128mbit flash chip on the camera as read-only
4. Confirmed the fs_flash script is functioning with the atomcam image and busybox version.

Procedurally, I need to make a script that does the following:

1. Mount the MTD partition hosting the rootfs.
2. Copy all the contents of the image to a temp directory (SDCard or even RAM disk)
3. Replace the /etc/shadow file with the old password schema file. We could also inject the WyzeHacks mods at this stage too... but all in due time.
4. Rebuild the squashfs image with the correct sector sizing
5. Reflash the partition to the 128mbit chip without affecting other locations. We have the MTD layouts from the boot messages, so that's cool.
6. Play a jingle to remove the SD card (I'm really hoping I just need to enable the GPIO pin for speaker power for aplay to work)
7. Reboot and enjoy your current Wyze firmware, but with the old password login and WyzeHacks without disassembly.

I'm hoping I can make more progress this weekend. I'm spinning up a github page to log my learnings. I'll post it once it's available.

from wyzehacks.

check out https://github.com/gtxaspec/wz_mini_hacks
its NOT as masterful as wyze_hacks, but its basic. I have an update soon automating installation using SD card only.

The toolchain and kernel sources are out there, @XBravRevolutionz, there was a guy who was compiling a custom U-boot for this too, @BiatuAutMiahn, not sure how far he got, #106

Haven't figured out how play sound through the speaker, the GPIO (63) doesn't exit under /sys.

from wyzehacks.

speaker:

interrupt app_init.sh using Test.tar
rmmod audio
insmod /system/driver/audio.ko spk_gpio=63 alc_mode=0 mic_gain=0

then audio play should work...audio is distored...sadly i can't get it to work when the full iCamera stuff loads.

from wyzehacks.

@XBravRevolutionz have you been able to compile a kernel image?

If you have you can boot it by placing it on the microsd card with the file name factory_t31_ZMC6tiIDQN and booting while holding the setup button will allow you to load the kernel... without flashing it.
edit- nevermind i see you already knew this =D

from wyzehacks.

https://github.com/mnakada/atomcam_tools

boots all the way to login, this fork is using a custom kernel and ext rootfs. on the pan v2 that i have it reboots after a while, probably watchdog.

edit: the toolchain in the docker image and kernel produce a kernel that boots fine on the v3/panv2

from wyzehacks.

You guys seem to be the best people to ask about hacking into the cam v3 because you seem to be doing similar things as to what I am doing.

I'm trying to access the bootloader of my v3 using the method found here: https://github.com/themactep/device-wyze-v3/blob/master/installation.md

I either can't get the timing down right or I am doing something wrong. If I short the flash pins before applying power it won't power on. If I short the pins as fast as I can after power on it throws tons of squashfs read errors, but either still shows a regular login prompt or locks up. Interestingly, in the boot messages it says to interrupt autoboot press any key, but I've tried 100 times and it doesn't seem to respond to input no matter how fast I am.

I don't know if this would actually help how you guys are hacking or would know how to actually get in the bootloader, but I figured it's worth a shot crossing paths here.

Logged into normal console

"Hit any key to stop autoboot"
Could this allow bootloader access?

BTW, I'm using a Raspberry Pi Pico, soldered wires to the UART pins on the cam, and this excellent UART-USB bridge firmware for the Pico: https://github.com/Noltari/pico-uart-bridge

from wyzehacks.

@themeadery the stock bootloader does not allow you to access the command prompt unless the rootfs is corrupted. You need to short the pins after uboot is loaded but before it tries to load the rootfs.

you have options:

if you have ssh access to the camera, you can intentionally corrupt the rootfs partition to allow uboot access.
if you have ssh access you can install the openipc u-boot to have greater access.

both involve some risk, as you should have a backup of your flashrom if you ever need to restore in case of corruption or mistake.

what is your end goal?

from wyzehacks.

@gtxaspec Thanks for all the help in Telegram.

from wyzehacks.