Wyze Cam OG not working

[mr-bobdobalina]

Not seeing the Wyze Cam OG showing up on the bridge. Running docker compose up (without the -d) I don't even see it listed in the initial "Connecting to..." section.

I also did FRESH_DATA=true on my yml.

[jhansche]

I have some HTTP proxy logs, and limited wireshark logs, with the ability to capture additional traffic between the Wyze app and the OG cam. How can I help with researching or adding support?

I'm willing to contribute changes, if someone can point me in the right direction for building and testing changes.

[mrlt8]

The OG is most likely using a different "IoTVideoSdk" platform. The SDK seems to be from Gwell/Tencent like the doorbell pro which @carTloyal123 was looking into.

Unfortunately, there isn't much information or any documentation in English: https://github.com/GWTimes/IoTVideo-PC https://github.com/GWTimes/GWP2PSDK https://cloud.tencent.com/document/product/1131/42244

[jhansche]

Isn't it this? https://www.tencentcloud.com/document/product/494/7244

All we need the tencent API for is to obtain the access key (enr) and get the local IP and UDP port, is that right? The wyze API response shows only a "placeholder" for the OG camera enr, and no ip.

Once we have the IP, port, and enr (is this the same as tencent's access key?), then there's a small handshake negotiation that happens between device and app, and after that the video starts to stream over UDP. This is presumably where the GWP2P or the iotvideo SDK comes in.

https://github.com/GWTimes/IoTVideo-Android looks a bit more informative.

So, high level, how would you describe what needs to happen in order to make progress towards support?

• How much of it is shared between GW and other wyze cams? E.g. it seems you already have "IOTC" in the stack somewhere, so that's not new.. we can get the thumbnails, so that's not new, etc. Where exactly is the separation between them?
• once we have the access key for the camera, is that all that's missing? Or do we still need a way to communicate with the camera P2P (the UDP handshake and streaming mentioned above)?

I just want to make sure I'm working in the right things, and not chasing something that's irrelevant or already in place.

@cartloyal123 anything new to share, or roadblocks you've hit that I can help get past?

[spartandrew18]

Any progress on getting the Wyze OG to work?

[sdalbert]

I also was happy to see progress for the OG recently and would like to see more. I understand that it is not promising so far, but I'm invested in one of these now and would rather not send it along to the obsolete hardware box yet.

[iamdagy]

This is a very useful and needed project. Thanks a lot. Hope OG cameras are Supported soon (I've got a bunch of them) your bridge solution can finally free the feed from a specific webui/app. Let us know how we can help in getting Support for OG cameras

[neo8]

Just FYI, I upgraded to 223 and partially connected. I see a still image with "The media could not be loaded, either because the server or network failed because the format is not supported. X" My other V3's and V2's work fine.

[iamdagy]

Is there anyway we can help moving forward the support for the new OG camera ?

[carTloyal123]

Hi everyone, sorry for the radio silence. I have not looked much further into the new cameras since I posted a while ago. The python Tencent library looks very promising and I had not come across that. If someone wants to give that a shot that would be awesome but I will not be able to give this much time for the next several weeks/months sadly. I was working on this to get a stream from the video doorbell pro and basically was stuck at trying to reverse engineer the mechanism to even enable the camera video stream to start. I hope to have time to look at these at some point but for now I will just be in the background/checking this thread.

[jhansche]

I have time sporadically (hard to know when), but I'm still not confident in my understanding of the various components of this project (see my questions above). Being new to the project, I just haven't wrapped my head around all the moving parts, and how each piece of the logs and/or network captures corresponds to equivalent pieces of the python code here.

What I've seen so far in my wire dumps is that the wyze api does not send the actual encryption key or the local ip address for these cameras, like it does for the other cameras, so I haven't been able to determine how the app discovers those. Once we have those, it seems like we should be able to proceed with getting the video stream. It appears to be over MQTT, but I haven't confirmed that yet. I also lost my logs of this, so I'll have to recreate my dev environment to get back to that.

[nbetcher]

I also was happy to see progress for the OG recently and would like to see more. Just FYI, I upgraded to 223 and partially connected. I see a still image with "The media could not be loaded, either because the server or network failed because the format is not supported. X" Is there anyway we can help moving forward the support for the new OG camera ?

Where is it that people are saying this, "support" and "progress"? I'll be honest, I don't follow this project's commits closely, but from what I could tell, there is no progress. And that would follow what I understand about the original problem. Which leads to my response to these replies to:

I was working on this to get a stream from the video doorbell pro and basically was stuck at trying to reverse engineer the mechanism to even enable the camera video stream to start. What I've seen so far in my wire dumps is that the wyze api does not send the actual encryption key or the local ip address for these cameras, like it does for the other cameras

My understanding is that @mrlt8 is not interested in reverse engineering or implementing an implementation of a reversed-engineered solution (totally speculation). I say this only because the currently-supported cameras are implemented by Python library derived directly from a leaked copy of the library from the ThroughTek (Tutk) IoT SDK [1].

These new cameras do not use the Tutk IoT SDK and instead use Gwell Times. Most of you know this already, but going back to what I originally said...

It makes me think that, unless someone comes up with the library from the original Gwell Times SDK (which I believe is floating around on Github, maybe?), AND an SDK key, AND @mrlt8 is willing to spend all of that time implementing another SDK (take a look at the amazing work he's done already in https://github.com/mrlt8/docker-wyze-bridge/tree/25a2bdfa2ad7f992de4db5cac55923fbb68779a6/app/wyzecam and that's despite the massive, massive amounts of heavy-lifting that the Tutk SDK's native library already handles), reverse engineering the packet dumps won't be of any help for an actual implementation.

I don't know how easily getting an SDK key will be though. That might be the tougher of the two things to accomplish.

Nothing I've said here about @mrlt8 represents any degree of accuracy. I'm not a developer or contributor on this project. I am a software developer, but I don't have the time or A/V / mathematical knowledge to accomplish the end result. These are just my impressions and interpretation since @mrlt8 has been a bit quiet on the topic.

[1] See https://github.com/mrlt8/docker-wyze-bridge/blob/25a2bdfa2ad7f992de4db5cac55923fbb68779a6/app/wyzecam/iotc.py#L55

[mrlt8]

While I was a huge fan of the original v2 and v3 cams (and still own more cams than I actually need), I have little interest/need for any of the gwell cameras. These newer models are very cloud dependent and have a higher chance of becoming ewaste if wyze drops support and/or goes under.

However, I am still working on an alternate way to add support for the newer cameras - the floodlight pro and the unreleased doorbell/outdoor cam also seem to be from yet another manufacturer so I'd like to find a solution that could potentially work across multiple platforms.

As for the gwell related credentials, has anyone looked into https://wyze-mars-service.wyzecam.com/plugin/mars/v2/regist_gw_user/? I can provide the signature keys for the relevant app-ids if needed.

[gibsonMatt]

my Micro Center is selling these for $15..picked up a few. How are things looking for eventual support of gwell cameras?

[gtxaspec]

@mrlt8 i think the common platform with the new cameras even between the different mfg's is the Realtek Ameba Pro 2 IOT Platform:
https://www.amebaiot.com/en/amebapro2
https://github.com/ambiot/ambz2_sdk
https://github.com/aws-samples/amazon-kinesis-video-streams-producer-embedded-c

Also looks like the tiny cam pro developer has figured out support too. may be worthwhile decompiling that app.

[mrlt8]

Thanks! Will try to take a look when I get a chance!

[nbetcher]

Thanks! Will try to take a look when I get a chance!

I've done some very preliminary inspection of how TInycam is accomplishing this and I believe the developer applied for, and received, the Tencent SDK to interface with the Gwell cameras. The Tencent SDK is definitely inside of Tinycam, along with some heavy mathematical obfuscation methods, likely to mask the developer's SDK key.

Some interesting strings:

https://wyze-mars-service.wyzecam.com/ wyze-mars-asrv.wyzecam.com wyze-test-list.cloudlinks.cn

The rest of the class is very, very, VERY heavily obfuscated, and even AI-based decompilation would struggle given the degree of nesting.

Either way, it appears the developer went the legitimate route and just obtained an SDK and a key for it.

[a9s2w5]

It should also be noted that even TinyCam's implementation only runs/supports the new OG/Doorbell Pro on ARM devices. There is no x86 support. And the TinyCam DEV had been hired to actually do work for Wyze, not sure what or the end result of that. This is me asking as much as suggesting, it seems like support for the Gwell/Tencent products, such as the OG and Doorbell Pro, are highly unlikely to be supported due to the complications/limitations?

[talormanda]

It should also be noted that even TinyCam's implementation only runs/supports the new OG/Doorbell Pro on ARM devices. There is no x86 support. And the TinyCam DEV had been hired to actually do work for Wyze, not sure what or the end result of that. This is me asking as much as suggesting, it seems like support for the Gwell/Tencent products, such as the OG and Doorbell Pro, are highly unlikely to be supported due to the complications/limitations?

He got hired by wyze? where did you read that?

[a9s2w5]

He got hired by wyze? where did you read that?

https://www.linkedin.com/in/avasilyev/

[ramboton]

I am not so sure about the no x86 support either. I am viewing my doorbell cam with TinyCam pro, I am on a chromebook, but it does work and my chromebook is not ARM, it is an Intel I5-8350U

[a9s2w5]

I am not so sure about the no x86 support either. I am viewing my doorbell cam with TinyCam pro, I am on a chromebook, but it does work and my chromebook is not ARM, it is an Intel I5-8350U

Merely am quoting the developer of Tinycam. https://www.reddit.com/r/tinycam/comments/159x0gg/comment/juuy0di/?utm_source=share&utm_medium=web2x&context=3

[iamdagy]

have we got any news ? how can we help to move this forward? Thanks

[carTloyal123]

It sounds like to me there are two ways to actually push this forward. The first would be for someone to reach out to Wyze/Alexey and see if we can cooperate and be on the same team here. The second would be for someone to spend a decent amount of time trying to implement the Realtek SDK and/or the Tencent SDK into the bridge which will seemingly be quite difficult given many unknowns about the credentials and auth management needed. I am happy to do the first and see if we can get anywhere by gaining knowledge from Alexey and Tinycam. If that does not go anywhere then people can speak up on what they know or how much they can contribute to getting anywhere with adding the new SDKs and figuring out the auth steps that will be needed. @mrlt8 how does this sound to you?

[nbetcher]

Or a third option: just ask Alexey how the authentication and credentialing is to see if the second option is more practical.

[carTloyal123]

@nbetcher Sure, but this is still basically the first option.

I have reached out to Alexey on LinkedIn to see what insight he is willing to provide.

[carTloyal123]

An update: I have successfully backed out the wyze information needed to get the p2p accessId and accessToken and this is working in python. With these two pieces of information along with a deviceId, p2purl (known) and the aformentioned iotvideo SDKs we might get somewhere.

At the moment, I am trying to load up the iotvideo sdk in python similar to the tutk library that is already implemented. This is where I could use some help probably from @mrlt8 since my knowledge is being stretched. I have the .so files for the libraries but I can not call any functions by name after loading them with ctypes CDLL. I am curious if you could offer some insight or if you would be interested in taking a stab at it yourself.

Regardless, half of the equation is pretty much done which is getting the credentials from Wyze so that is progress. I will keep pushing on getting these libraries to play nice in python but until then happy coding!

[jhansche]

@carTloyal123 that's awesome 😎

• Do you have your WIP committed somewhere to peruse or experiment with?
• Where did the .so file come from? (i.e., extracted from an android APK, iOS app, some other backchannel, etc? More directly: what platform was it intended for?
• If the .so file was not actually written for Python's C API you'll need to do some wrapping, in order to act as a bridge between the Python runtime and the C library, so that the Python runtime can call the wrapper, which will import this C library and call the target code in that library. Have you already done this? See https://docs.python.org/3/extending/extending.html

[carTloyal123]

Not committed anywhere yet, I will put it in a PR for this repo soon. Libraries are currently from the wyze app apk on android and since they only support ARM platforms it seems like they do not like to be loaded. I have been trying using an aarch64 machine but still no luck. The issue is not being able to wrap them, that is trivial, the issue is working out how to even execute the binaries on a platform other than android. There is a windows dll which might be useful but I have not tried it. Since Tutk has an x86_64 version it works fine but that is not the case here for the iotvideo sdk.

I do have some more ideas to test to get these binaries working but we will see. I think it might be an issue with my setup since I can't even load the Tutk library from this repo🙃

[jhansche]

Yes for sure, an arm or other .so file will not load on an x86 or other architecture. But Android re-bundles APKs based on the device that is installing the app. So if you installed it from an arm device, you would only get the arm libraries.

Best case would be to install it on an x86 or x86_64 device, and extract the so files from there. Then it should be able to load on a target system assuming the arch matches (or is compatible).

On my device for example, I have:

/data/app/~~UaTVuHj6tdXhp4vEFFTVCQ==/com.hualai-pN8RQUbB4pQPzWA8Lyj66w==/:
-rw-r--r-- 1 system system 105254430 2023-08-18 05:10 split_config.arm64_v8a.apk

But installing on another arch should provide other arch splits.

[carTloyal123]

As far as I can tell that actually is not the case. Each apk comes with all the needed binaries for every architecture. At runtime the developer has to check the current platform ABI and load the desired library if available. You can see this quite clearly by decompiling any apk. There are folders for each architecture type and browsing the decompiled code shows system calls to check ABI and selectively load binaries.

Now this brings me to the really interesting finding that someone on this thread is running tinycam on their x86 Chromebook and viewing their doorbell. @ramboton would you be able to do some digging by chance on this? I'm not super familiar with what android does to install apps but there has to be a place to store all the libraries somewhere and if you wanted to see if you can find that that would be awesome. You're looking for a folder called 'x86' or 'x86_64' and the file will be called 'libiotvideo.so'. I am guessing that the Chromebook has an emulation layer but hopefully I am wrong and we can magically find the x86 files we need.

[ramboton]

Unfortunately I have 2 issues, #1 is that I am not technical enough to do that I know nothing about programming or anything like that. #2 for some reason the OG is no longer working in Tinycam on my x86 chromebook, some update must have broken that feature.

On Thu, Sep 14, 2023 at 6:07 AM carTloyal123 @.***> wrote:

As far as I can tell that actually is not the case. Each apk comes with all the needed binaries for every architecture. At runtime the developer has to check the current platform ABI and load the desired library if available. You can see this quite clearly by decompiling any apk. There are folders for each architecture type and browsing the decompiled code shows system calls to check ABI and selectively load binaries.

Now this brings me to the really interesting finding that someone on this thread is running tinycam on their x86 Chromebook and viewing their doorbell. @ramboton https://github.com/ramboton would you be able to do some digging by chance on this? I'm not super familiar with what android does to install apps but there has to be a place to store all the libraries somewhere and if you wanted to see if you can find that that would be awesome. You're looking for a folder called 'x86' or 'x86_64' and the file will be called 'libiotvideo.so'. I am guessing that the Chromebook has an emulation layer but hopefully I am wrong and we can magically find the x86 files we need.

— Reply to this email directly, view it on GitHub https://github.com/mrlt8/docker-wyze-bridge/issues/677#issuecomment-1719418442, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS22IZRBGDPII5DCY52DT6LX2L6QBANCNFSM6AAAAAAT7SO4VI . You are receiving this because you were mentioned.Message ID: @.***>

[jhansche]

I've been an android developer for over 10 years. The file I showed listed above is named "split" because it is from an "APK split", which works exactly as I described, and it is very well documented. If the app was published as an APK initially by the developer, then yes it must include all architectures it will support, but that hasn't been the best or most common practice for many years. If the developer publishes the app to the play console as an AAB (Android app bundle), then the play store will automatically deconstruct it and create all the splits needed and will deliver only what is relevant to your device when you install it.

That said, the AAB that was uploaded must have the architecture support to begin with, so if they never intended to support an architecture, play store won't magically create it for you. If it can be installed on an x86 device (i.e. an emulator would be my first suggestion), then the split will be present there.

[jhansche]

According to apkmirror, they only publish 2 variants, arm64-v8a + armeabi-v7a: https://www.apkmirror.com/apk/wyze-labs-inc/wyze/wyze-2-44-5-330-release/ And trying to open Google Play store on an x86 emulator to install it, gives this:

So they simply don't support the x86 ABI.

If it was working previously on an x86 Chromebook, that would have been using the Chrome OS android apps support, which works by using ARM translation (like an emulator): https://developer.android.com/topic/arc/device-support#arm-translation

[carTloyal123]

This is all fine. Either way the issue still remains that we need a way to load the libiotvideo.so library that comes with Wyze or TimyCam. I assume this is possible since @mrlt8 has been able to do the same thing for the TUTK binary. It also looks like @mrlt8 has combined the tutk and iotcapi binaries into one so I would definitely like to know more about that if possible. So far the iotvideo sdk requires at least 5 binaries so it would be great to only end up with one. @mrlt8 did you have to do anything special to get elf headers corrected from the tutk binary?

[jhansche]

It was my understanding that @mrlt8 obtained the C library from some other undisclosed source, I do not believe it came from the mobile apps, but from some other private or internal source. 🤔 but now I can't find the reference to that information to backup that notion.

The amd.lib and arm.lib files in the docker app dir are described as:

amd.lib: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8dc56493821b4c11df52c05f77bedd7d12339ef5, not stripped
arm.lib: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=0fa09d0d94da421c35c658683d7a3d7807e422af, not stripped

So this being the case, it's possible that your ARM lib might work on a raspberry pi, or other ARM based host? But for it to work on an intel or AMD based architecture, we'll need to find another source for x86, x86_64, or amd64 libs.

It doesn't appear that iOS apps would contain an x86 binary either, unless the app is intended to run on the Simulator. Otherwise it's all ARM based. If there were a macOS app, that would surely support x86, but I do not see one.

[mrlt8]

The tutk library that we use comes from the SDK which is compiled for linux:

Library files (.\Lib) To provide the greatest portability, TUTK IOTC platform supports many popular platforms and corresponding development environment. The corresponding libraries are listed as following for use when linking executable files.

Platform	Directory
Android	.\Lib\Android
Google Native Client	.\Lib\NaCl
iOS	.\Lib\iOS
Linux (Embedded Linux)	.\Lib\Linux\
MAC OS	.\Lib\MAC
Windows	.\Lib\Windows
WinRT	.\Lib\WniRT

https://www.sunipcam.com/sdk/Readme.htm

I don't believe it's possible to use the andorid (bionic) library directly in linux and we'd need to run some kind of emulation or convert it to glibc with something like https://github.com/Cloudef/android2gnulinux

The iOS libraries may have potential to run natively on MacOS with the ma1/m2, but not sure if it could be done in a docker container?

[carTloyal123]

Thanks @mrlt8 for the update. That is most helpful since I think I was assuming the binary had come from an android/ios app.

Looks like android2gnulinux might be an option. At the moment I am pretty fascinated by https://github.com/libhybris/libhybris/tree/master/hybris so I am going to see if I can get a basic example of this working. From what I can tell this should be a decent way to generate C bindings, then wrap in Python when needed. It will be a long process but does at least offer some hope that this is possible. Let me know if anything else comes up or other comments!

[carTloyal123]

So, I have been looking into running android libs on normal linux systems and there is some possibility that that is possible but I have hit a number of dead ends. I am going to explore my second thought which is create a basic android app that acts as a proxy for the iot video lib. I think this has much more potential since the android app can be packaged up nicely and emulated on any platform with qemu or other tool. The idea is the create an android app and expose the iotvideo library through a websocket/REST api to the outside world, implementing features as needed. Will come back with more once I have spent some more time with this second idea.

[nbetcher]

Apologies for falling behind in the conversation — and although I did skim through all replies since my last, I was unable to answer this question — I'm confused though, why are we bothering with the TutK SDK (which is already fully implemented and in this project) when the it's the Tenscent SDK that is used for the Wyzecam OG/etc?

[carTloyal123]

Tutk SDK is of course done. We are only talking about the iotvideo.so library found in the GWell repos and in the wyze/tinycam apks

[ju5t3nc4s3]

the SOC in the OG is the same as this dev board (AMB82-MINI) doc is here https://device.report/m/f97fabeccb918a1d2e6c4183aeca88e7ba92ae3eff1dec7f4bbc47ef76dba633_optim.pdf

[gtxaspec]

I'm not an expert in audio-video processing, but I assume that both the audio and video have timestamps. Is it possible to buffer them individually and, once we have a buffer built up, compare these timestamps when combining them into one stream? Can we adjust the buffered content to compensate for a delay in either the video or audio?

[mrlt8]

The raw h264 bytes don't contain any PTS/DTS/timestamps. The tutk AV module does include the timestamp to the micro second with each frame, but I don't believe it's possible to pass that to ffmpeg?

I believe the current sync issue seems to come from the mismatch in the number of video/audio frames if/when the camera drops a frame or is slow. When that happens, the muxer seems to pause the audio till it receives the next video frame causing the audio to lag behind or, if using the wallclock to set the timestamps, the audio will continue while the video slowly drifts behind as the camera starts producing frames and muxer doesn't seem to realize the video is behind since it's using the wallclock to set the timestamp as they arrive..

[revans23]

Just chiming in to voice support for an OG solution. I have both a M2 Mac and PC that I am happy to test on if it is helpful.

[mrlt8]

Sorry for the delay, hope to have something up for testing soon.

[carTloyal123]

Amazing, is this something to test for the doorbell pro and cam og?

[carTloyal123]

@mrlt8 anything others can help with?

[dinan5]

I'm happy to test with OG Cam as well. Thanks!

[mrlt8]

Will need to look into it, but I believe the doorbell pro/pro 2 require a wake command so I don't think they'll be supported.

[carTloyal123]

@mrlt8 that makes sense. Are you using the iotvideo sdk for the og cam or some other approach to interface with it?