UART/Serial on Wyze cam v3

[C1ARKGABLE]

Hey gang,

I was wondering if anyone had looked into the hardware as a hack vector.

Judging by the FCC internal photos of the Wyze cam v3, it looks like there are three pins that might correspond to an exposed serial port. (Specifically on pdf page 3, the top photo, adjacent to the largest IC)

Having access to this, and being able to start telnetd, might allow us to bypass the need to do any DNS spoofing (like was being discussed here: #132 (comment)).

If no one else has, I might crack my Wyze open and try to establish a serial connection. I'll report back here with my findings.

[HclX]

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.

[C1ARKGABLE]

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

[satmandu]

Does WYom20200 work as the password for the newer firmware?

[GrumpyMeow]

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' ?

[HclX]

I haven't done this for a while, but last time I tried it no longer works with official firmware, so I won't be surprised if they changed it for rtsp firmware too.

…

On Sat, Jan 8, 2022, 04:42 Meow ***@***.***> wrote: 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' ? — Reply to this email directly, view it on GitHub <#134 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZNWD5MXNDCCYJJLFBVAELUVAWNBANCNFSM5A44HALQ> . 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 commented.Message ID: ***@***.***>

[GrumpyMeow]

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.

[iointerrupt]

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.

[XBravRevolutionz]

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.

[virmaior]

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.

[XBravRevolutionz]

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.

[gtxaspec]

@virmaior thanks! this is just what we needed.

[virmaior]

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

[XBravRevolutionz]

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.

[gtxaspec]

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.

[gtxaspec]

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.

[gtxaspec]

@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

[gtxaspec]

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

[themeadery]

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

[gtxaspec]

@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?

[themeadery]

@gtxaspec Thanks for all the help in Telegram.

[ghost]

Hello there, some time have passed and I wonder if someone was able to crack the password for the UART shell ? I see @themeadery is able to login trough the UART connection in Putty (cf his screenshot), so I guess is doable

[themeadery]

@Tihmz IIRC, the way I got into it was to short pins on power up to get into a special "mode" then blow everything out by overwriting it all with custom firmware from OpenIPC. I'm sorry I forget all the details and correct terminology, it has been a while. The OpenIPC devs really know how to hack this stuff. IIRC, you are overwriting two areas of memory and then you are home free on new firmware/software. I think it is somewhat a waste of time trying to use the stock firmware. And again, IIRC, nobody really cracked the password so far.

[ghost]

Ok, thanks for the quick answer !

[gtxaspec]

Check out thingino, specifically for these ingenic cameras. https://github.com/themactep/thingino-firmware