Status of WyzeCamLiveStream hack on V3.

[FiveLeavesLeft]

I know some people were interested in getting my hack running again on V3.

The hack relies on changing LD_LIBRARY_PATH and intercepting calls to IMP_Encoder_GetStream which lives in /system/lib/libimp.so. This sort of worked on V3 under WyzeHacks but it was tenuous. I remember being convinced at one time that iCamera relied on C "undefined behavior".

I can't currently get it to work reliably on V3. If I create a libimp.so that contains only this...

    #define LIB "/system/lib/libimp.so"

    static void *sym = 0;

    void  __attribute__((constructor)) foo(void) {
            printf("CRBMIN constructor");
            if(sym) return;
            sym = dlopen(LIB, RTLD_GLOBAL|RTLD_NOW);
            printf("CRBMIN sym = %p", sym);
    }

    void _init(void) {
            printf("CRBMIN _init");
            foo();
    }

.. the camera runs for awhile but eventually gets errors and reboots.
What could account for this? I have some ideas:

    1. My toolchain is not exactly compatible with the toolchain iCamera was compiled with.
    2. Bug in the dynamic loader that ships with the camera. ( Doubtful. )
    3. iCamera relying on undefined behavior.

I don't think it's failing because of anything Wyze the company is doing intentionally. I can look at the stdout of iCamera with and without the hack above and see minor differences in error reporting. So this hack that shouldn't change any behavior is causing iCamera to fail. A long time ago, on V3 under WyazHacks I think I observed the dynamic loader stepping on the memory of static strings.

The loader that ships with the camera doesn't have the usual LD_DEBUG stuff compiled in. That would have been nice.

That's the status, I don't know if anyone out there is interested enough and/or has the expertise to take this to the next level. I am open to suggestions. I will continue to think about it.

Thanks,

Charlie ( FiveLeavesLeft )

ps: Thanks for the great work.

[gtxaspec]

Charlie,

I wasn't too familiar with your project before but I've had many folks contact me regarding the functionality with wz_mini, so maybe we can figure out a way to make it work.

You for sure need the right toolchain. What I would start with is heading to https://github.com/mnakada/atomcam_tools/ and git cloning his repo. Follow Build.md (with google translate) to setup a docker environment with the toolchain and a bunch of other stuff. I was able to sucessfully compile everything for wz_mini using this, and more. It should also be possible to replace the built-in loader as well.

Have you looked at the libcallback sources at https://github.com/mnakada/atomcam_tools/blob/main/libcallback/video_callback.c and audio_callback.c? Maybe you could integrate this method into your livestream hack as well?

[FiveLeavesLeft]

Thanks for the links. I did a make.sh on atomcam_tools last night and it completed. Wow. A lot to unpack here. Thanks.

[FiveLeavesLeft]

@gtxaspec In the old version of wz_mini_hacks I had modified setup.sh to modify /etc/rcS to change PATH and LD_LIBRARY_PATH. In looking at the new version of wz_mini_hacks, I don't see a way to do this. Could I get a copy of the old setup.sh ? ( I lost mine. ) Or maybe you could change wz_mini_hacks to put /configs/bin and /configs/lib on the front of PATH and LD_LIBRARY_PATH as this may be generally useful for future hacks. Thanks.

[gtxaspec]

try https://github.com/gtxaspec/wz_mini_hacks/tree/fe9e712c3894d8e3fc49be86c3b2f2bfb484c6be

[gtxaspec]

check out the latest release, I bind over rcS when using RTSP, maybe you can hook into this, you can also place stuff into wz_mini/bin and wz_mini/lib

[gtxaspec]

another new version, more hooks in different places, you can change fstab, rcS, and some other stuff too.. check it out if you like.

[FiveLeavesLeft]

Thanks, build.md is very helpful too. You are making great progress at blinding speed.

[gtxaspec]

any luck? Also have you checked out libcallback, and seen how he hooked in to iCamera to get the streams? It seems to work but break the live view and microsd recording when enabled

[FiveLeavesLeft]

I've been really busy with other things and in the process of moving. Not sure when I will be able to get back to this. You can close this if you like. Thanks.

[gtxaspec]

@FiveLeavesLeft thanks for the info. I have a few questions if you have time, I am trying to get the wyzecamlivestream compiled and loaded to test.

I compiled the code, my questions are:

1.do you replace the libimp.so in /system/lib ? is iCamera supposed to use this instead?

2. or do you leave that alone and LD_PRELOAD it?
3. once the library is loaded, how do you trigger the stream? or is it automatic once loaded

[FiveLeavesLeft]

I’ve never used LD_PRELOAD but I was going to try that option sometime soon.

I changed LD_LIBRARY_PATH to look in /configs/stream_hack before /system/lib so iCamera would load libimp.so from there. Then I dlopen’ed /system/lib/libimp.so inside my code which is in /configs/stream_hack/libimp.so . This worked on V2 but had some strange side effects on V3 that I don’t understand.

Using LD_PRELOAD is an interesting approach that I never tried.

I would like to get back to this, and I feel sort of bad that you are using your precious time on this, but I won’t be able to look at it for at least a week.

As an aside, in my recent effort I also changed PATH and I created a fake “dmon” that looked like this:

!/bin/sh

if [ $6 = "/system/bin/iCamera" ] then

    /system/bin/iCamera >& /media/mmc/icam.log &

else

    /system/bin/dmon $@

fi

That let me look iCamera’s stdout and stderr. Maybe you have a better way to do that.

On Apr 25, 2022, at 9:18 PM, gtxaspec @.***> wrote:

@FiveLeavesLeft https://github.com/FiveLeavesLeft thanks for the info. I have a few questions if you have time, I am trying to get the wyzecamlivestream compiled and loaded to test.

I compiled the code, my questions are:

1.do you replace the libimp.so in /system/lib ? is iCamera supposed to use this instead?

or do you leave that alone and LD_PRELOAD it? — Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1109312619, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMT6MM4J7BBQG6GZF5LVG5VCJANCNFSM5TS4WOTA. You are receiving this because you were mentioned.

[gtxaspec]

thank you for the detailed explenation, i have some extra time so no worries.

also, once the library is loaded, how do you trigger the stream? or is it automatic once loaded

[gtxaspec]

got it partially working with wz_mini, I change the LD_LIBRARY path as you mentioned, and it works briefly but then iCamera reboots the camera...

[init.c:1432][sdk_major_error_handle] errCode:1

there is hope!

[gtxaspec]

i updated wz_mini, in wz_mini/etc/init.d/v3_init.sh, i added:

#Custom PATH hooks
#sed -i '/^# Run init script.*/i#Hook Library PATH here\nexport LD_LIBRARY_PATH=/opt/wz_mini/lib:$LD_LIBRARY_PATH\nexport' /opt/wz_mini/tmp/.storage/rcS
#sed -i '/^# Run init script.*/i#Hook system PATH here\nexport PATH=/tmp/test/bin:$PATH\nexport' /opt/wz_mini/tmp/.storage/rcS

where you can change the LD_LIBRARY_PATH, as you see i changed it to the wz_mini/lib directory, and then iCamera successfully loads the library.

[FiveLeavesLeft]

That’s what I was seeing. Are you saying it’s working now and you can stream video from it?

On Apr 25, 2022, at 10:26 PM, gtxaspec @.***> wrote:

got it partially working with wz_mini, I change the LD_LIBRARY path as you mentioned, and it works briefly but then iCamera reboots the camera...

there is hope!

— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1109358832, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMQRGIDVJGZ7J46WGB3VG55APANCNFSM5TS4WOTA. You are receiving this because you were mentioned.

[gtxaspec]

@FiveLeavesLeft not quite working yet,I was just too excited when I got a few seconds of video before the camera rebooted. will continue investigate further.

[gtxaspec]

for reference, here is an updated SDK targeted to the T31 https://github.com/BiatuAutMiahn/IVSP-T31-1.1.1-20200508/tree/main/software/sdk/Ingenic-SDK-T31-1.1.1-20200508/samples/libimp-samples

[gtxaspec]

I have compiled a new version of uClibc with LD_DEBUG enabled for development. it can be enabled in etc/init.d/v3_post.sh and the icamera executable script is in usr/bin/iCamera-dbg

[FiveLeavesLeft]

I’m finally getting around to looking at this again. Downloaded the latest version, copied the files over to the SDCARD. When it powered up I heard it say something about “creating swap”. I can ping it, but I can’t ssh into it.

My wz_mini/etc/ssh/authorized_keys looks like:

PLACE AUTHORIZED KEYS BELOW

ssh-rsa AAAAB3NzaC1yc2EAA ….. +P9b30= @.***

I tried ssh , ssh -l root and ssh -l crb . All say "Connection closed by 192.168.8.143 port 22”.

Any ideas? Thanks.

On Apr 30, 2022, at 4:57 AM, gtxaspec @.***> wrote:

I have compiled a new version of ld-uClibc.so.0 and libuClibc-1.0.40.so with LD_DEBUG enabled for development

— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1113975862, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMWVEOJDPRQ5TXXDCU3VHUNZ7ANCNFSM5TS4WOTA. You are receiving this because you were mentioned.

[gtxaspec]

try ssh -v root@ip, this will enable verbose mode, see if it's trying the key at all.

[FiveLeavesLeft]

Thanks for the quick reply! Here’s what it says. I am on an MacBook air.

air:wz_mini_hacks-master crb$ ssh -v @. OpenSSH_8.6p1, LibreSSL 2.8.3 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/ matched no files debug1: /etc/ssh/ssh_config line 54: Applying options for debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug1: Connecting to 192.168.8.143 [192.168.8.143] port 22. debug1: Connection established. debug1: identity file /Users/crb/.ssh/id_rsa type 0 debug1: identity file /Users/crb/.ssh/id_rsa-cert type -1 debug1: identity file /Users/crb/.ssh/id_dsa type -1 debug1: identity file /Users/crb/.ssh/id_dsa-cert type -1 debug1: identity file /Users/crb/.ssh/id_ecdsa type -1 debug1: identity file /Users/crb/.ssh/id_ecdsa-cert type -1 debug1: identity file /Users/crb/.ssh/id_ecdsa_sk type -1 debug1: identity file /Users/crb/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /Users/crb/.ssh/id_ed25519 type -1 debug1: identity file /Users/crb/.ssh/id_ed25519-cert type -1 debug1: identity file /Users/crb/.ssh/id_ed25519_sk type -1 debug1: identity file /Users/crb/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /Users/crb/.ssh/id_xmss type -1 debug1: identity file /Users/crb/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.6 debug1: Remote protocol version 2.0, remote software version dropbear_2022.82 debug1: compat_banner: no match: dropbear_2022.82 debug1: Authenticating to 192.168.8.143:22 as 'root' debug1: load_hostkeys: fopen /Users/crb/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: @. MAC: compression: none debug1: kex: client->server cipher: @.*** MAC: compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY Connection closed by 192.168.8.143 port 22 air:wz_mini_hacks-master crb$

On May 8, 2022, at 5:59 PM, gtxaspec @.***> wrote:

try ssh -v @.***, this will enable verbose mode, see if it's trying the key at all.

— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1120527825, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMXCT64HLDTYRFTUL63VJBPPHANCNFSM5TS4WOTA. You are receiving this because you were mentioned.

[gtxaspec]

i think your mac ssh client doesn't like dropbear ssh. you can disable the ssh only keys requirement, edit /opt/wz_mini/init.d/v3_init.sh and delete the -s -g from the dropbear command (line 115) and then save and reboot.

[raelbsd]

Hi, thanks for hard work! I have 4 wyze cams, I made it work in one, but in the three left had no luck. I'm trying to ssh and I have this, the first time a kex_exchange_identification error and then "Connection refused" all the times. I've already tried to delete the -s -g, and it's the same. In the v3_init.log I don't see any errors or warnings related.

Maybe I should open a new issue but looks it's related to the latest error in thread. What else could I try? Thanks!

root@calisto:~# ssh -v 192.168.1.30
OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.1.30 [192.168.1.30] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4
kex_exchange_identification: read: Connection reset by peer
root@calisto:~# ssh -v 192.168.1.30
OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.1.30 [192.168.1.30] port 22.
debug1: connect to address 192.168.1.30 port 22: Connection refused
ssh: connect to host 192.168.1.30 port 22: Connection refused

[gtxaspec]

@raelbsd this could mean that the memory card is corrupted, or the authorized_keys file is corrupted. Have you tried reformatting your cards and copying everything fresh?

also, based off your log, it shows that no identity key file was found locally on your system. do you always run as root?

[raelbsd]

Hi, I'll try with a brand new card, I've formatted all the 4 cards and I did a fresh install several times. Also I've tried with a normal user with the keys generated, and when I've tried as root, I've change the dropbear parameters to allow password logins. I'll try with a new card to see if I got luck. Thanks!

[FiveLeavesLeft]

I finally did get the WyzeCamLiveStream to work under wz_mini_hacks. A minor code change and use of LD_PRELOAD and LD_LIBRARY_PATH. Do you want to incorporate it into wz_mini_hacks or shall I maintain a separate GitHub repo for it? It’s a couple of C files and a Makefile.

Thanks.

On May 8, 2022, at 6:15 PM, gtxaspec @.***> wrote:

i think your mac ssh client doesn't like dropbear ssh. you can disable the ssh only keys requirement, edit /opt/wz_mini/init.d/v3_init.sh and delete the -s -g from the dropbear command and then save and reboot.

— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1120533277, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMXLFGQ7UNGJNHAKC43VJBRK7ANCNFSM5TS4WOTA. You are receiving this because you were mentioned.

[gtxaspec]

I would love to include it in the project!

@FiveLeavesLeft question, what video stream does it tap into? the current solution In the project uses the same stream displayed in the app I believe, and users complain the bitrate is too low compared to the stock rtsp fw.

[gtxaspec]

also, I wonder if it would be possible to direct the video stream to a /dev/video loopback device so v4l2rtspserver can handle the audio as well, or does your code do audio as well?

[FiveLeavesLeft]

The code interposes a function in libimp.so that gets called for each frame of h264 video. I don’t know what the bitrate is, my code is very naive and just writes a frame each time the function is called. I never tried to throttle anything.

The code just writes to file descriptor so maybe I could write to /dev/video or something similar. A named piped maybe?

No audio at all.

Wyze runs iCamera with LD_PRELOAD=libsetunbuf.so, does wz_mini_hacks do that also?

Thanks.

On May 12, 2022, at 3:46 PM, gtxaspec @.***> wrote:

also, I wonder if it would be possible to direct the video stream to a /dev/video loopback device so v4l2rtspserver can handle the audio as well, or does your code do audio as well?

— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1125485203, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMVIIO5Y5TQ64GU34MLVJWC2ZANCNFSM5TS4WOTA. You are receiving this because you were mentioned.

[gtxaspec]

the libsetunbuf is only needed for the wyze dmon logging, though wz mini only runs without it when running the rtsp server, as libcallback has it built in I believe.

if you have time to look at the video_callback.c, I think it is getting sent to a file descriptor.

[FiveLeavesLeft]

If you want to try the new live stream version, ssh into the camera and:

cd /configs wget www.sonic.net/~crb/dev/get source ./get reboot

For this to work. you must modify LD_LIBRARY_PATH to have /configs/lib_hack in front of everything else eg

export LD_LIBRARY_PATH=/configs/lib_hack:$LD_LIBRARY_PATH

How you do that is up to you.

This version depends on LD_PRELOAD=libsetunbuf.so ( as is the case in app_init.sh ).

To stream try ( where $(IP) is the ip address of the camera ). vlc http://$(IP):12345 —demux h264 or mpv http://$(IP):12345

If this works for you, we can discuss how best to integrate it into wz_mini_hacks and I can get you the Makefile and source code.

Thanks.

On May 13, 2022, at 1:33 PM, gtxaspec @.***> wrote:

the libsetunbuf is only needed for the wyze dmon logging, though wz mini only runs without it when running the rtsp server, as libcallback has it built in I believe.

— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1126459932, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMWJOYLICP6NJW5OTULVJ24AJANCNFSM5TS4WOTA. You are receiving this because you were mentioned.

[gtxaspec]

tested, it works!

[gtxaspec]

if you want to update your repo I can get the source from there, if that's easiest for you

[endertable]

Was this actually integrated in to wz_mini already, I didnt’t notice the update. Or is it integrated into the rtsp server?

[FiveLeavesLeft]

It wasn't integrated. Do you think there is reason to do so? Is there something that this adds that isn't covered by everything else running so well?

The files I mentioned below are no longer up to date. If there's a reason to integrate I will need to update them. Otherwise we should close this issue. Thanks.

[gtxaspec]

@FiveLeavesLeft maybe we could keep your solution in mind as a back up just in case, if you agree. It's always good to have more than one way to achieve something, especially on such a popular feature.

[FiveLeavesLeft]

Sounds good to me.

[gtxaspec]

great to hear, and thank you very much!

closing for now.

[gtxaspec]

@FiveLeavesLeft Hello! I wanted to include your h264 solution in an upcoming release of wz_mini as an alternative to v4l2rtspserver for users, would you mind sharing the source to integrate it?

thanks!

[FiveLeavesLeft]

I override a routine, IMP_Encoder_GetStream that gets called for each frame. I call the original version of the routine and if someone has opened a connection to my little server I send the frame over that connection.

So I have some C code that waits for a connection. That runs in it’s own little thread.

On Apr 25, 2022, at 9:39 PM, gtxaspec @.***> wrote:

thank you for the detailed explenation, i have some extra time so no worries.

also, once the library is loaded, how do you trigger the stream? or is it automatic once loaded

— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1109324547, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMVXJQVSOZ53XBUFXRTVG5XPXANCNFSM5TS4WOTA. You are receiving this because you were mentioned.

[FiveLeavesLeft]

Great. The Makefile and source code and toolchain are in www.sonic.net/~crb/dev/src.tgz . I forget where exactly I got this toolchain, but it’s probably the same one you are using.

Integrate this into wz_mini_hacks however you want. I chose /configs because it’s writable and persistent on V2 and V3. ( I haven’t made this version work with V2 yet. )

The code compiles into libcrb.so which is copied into /configs/lib_hack/libsetunbuf.so .

How it works:

The routine IMP_Encoder_GetStream is called for each h264 frame. It it used internally by iCamera and lives in /system/lib/libimp.so . My code intercepts the calls to IMP_Encoder_GetStream, calls the version in libimp.so and also writes the h264 frame to a client ( file descriptor ) if there is one.

Changing it to write to some other file descriptor would be trivial. I’ve never done anything with /dev/video and I don’t know anything about it.

Let me know if you have any questions. Thanks.

ps: Thinking about this, this hack is persistent and will live on even without a sdcard.

On May 13, 2022, at 9:19 PM, gtxaspec @.***> wrote:

tested, it works!

— Reply to this email directly, view it on GitHub https://github.com/gtxaspec/wz_mini_hacks/issues/10#issuecomment-1126635269, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATVGDMTCAOMQFNUJXE7BH23VJ4SU5ANCNFSM5TS4WOTA. You are receiving this because you were mentioned.