YooSee SD-M5 doorbell: 1080p, PoE, RTSP, Onvif, only $66

[Bazzle]

Now I just wish I could reliably record the video stream.

I have an Dahua NVR recording 12 normal Dahua cams.
Cam no13 is the doorbell cam.
In that I set the feed to : see pic
Colour not quite right as I used my iphone on the 50hz tv screen (security can be seen on hdmi feeds around house)

 

[Jay Roman]

Has anyone compared the YooSee to the Dahua VTO2202F-P ?

Is the Dahua VTO2202F-P , the go to recommended doorbell ?

 

[Florissilfhout]

@mrxyz, @sp00025, @SecuritySeeker Thank you all for your efforts so far! I have been following this topic for quite some time now and I am very intrigued with what you have come up with.
I would very much like to patch my SD-M5 YooSee doorbell with at least the FPS-fix, but also to not let it phone home anymore (or rebooting because it can't). Does anyone have the mentioned firmware with Telnet installed where I could play around with the npc binary without soldering? I have used Ghidra before so if there currently isn't an "all-in" fix, just the Telnet patched firmware would really help me.

Cheers,
Florissilfhout

 

[mrxyz]

I didn't solder... I just pressed with some force and it stayed connected (as long as you don't move the device it will be fine).

 

[petervk]

I've followed the path described beautifully by @mrxyz (thanks!!), and have managed to patch my npc binary so it doesn't drop the frame rate. I've also managed put this together and build a new firmware image which my device happily accepted and upgraded itself to (I'd rather not have a microSD card inserted eventually). This should work without opening up the unit and adding a console connection...
I've got a better/fuller version of busybox working so can run pgrep and reredirect, next steps are to send a MQTT message on doorbell press...
Anyway, happy to share this modified image when I'm done.

 

[Florissilfhout]

I've followed the path described beautifully by @mrxyz (thanks!!), and have managed to patch my npc binary so it doesn't drop the frame rate. I've also managed put this together and build a new firmware image which my device happily accepted and upgraded itself to (I'd rather not have a microSD card inserted eventually).

If you could share the patched firmware you created, that would be great! I could hit the ground running that way.

 

[brommetje]

I've followed the path described beautifully by @mrxyz (thanks!!), and have managed to patch my npc binary so it doesn't drop the frame rate. I've also managed put this together and build a new firmware image which my device happily accepted and upgraded itself to (I'd rather not have a microSD card inserted eventually). This should work without opening up the unit and adding a console connection...
I've got a better/fuller version of busybox working so can run pgrep and reredirect, next steps are to send a MQTT message on doorbell press...
Anyway, happy to share this modified image when I'm done.

Hi @petervk can please create some kind of howto step by step how to do it and which software (like busybox) I need to setup MQTT, I do need have an SD card in my doorsafe?
thanks brommetje

 

[petervk]

Well I've successfully managed to corrupt my filesystem, and now npc wont run, either from SD or Flash . I should be able to recover by reflashing from uboot, will report back when I've got something useful to share.

 

[petervk]

Deleted.

 

[Florissilfhout]

Thanks @petervk!
I've had the opportunity to look at your files and you patched the FPS at the same place I would have
Now I am looking at the code that is responsible for the daily reboots (because I don't like it to be connected to the Interwebz) and I think I found the point of interest:


Seems there is more than one reason for the device to do a scheduled reboot so this will definitely need another look.

Sorry for the Noob question: For activating Telnet, is it sufficient to uncomment telnetd in your "npc"?

Cheers,
Florissilfhout

 

[mrxyz]

Just had a quick look. FUN_0028bc8c in my case (I guess your case it will be FUN_00294240, is basically something like system(): it executes the supplied argument. Changing the contents of the various "reboot" strings, should be enough to prevent the program from rebooting.

However, one thing to keep in mind is that some services could have been halted before the call FUN_0028bc8c, which might cause some problems when you just change reboot into reb00t or something.

 

[petervk]

Sorry for the Noob question: For activating Telnet, is it sufficient to uncomment telnetd in your "npc"?

Yup exactly, do you need an image built with this or do you have access already?

I'm almost there on the MQTT side of things, I've got mosquitto_pub running fine on the camera, just having trouble with the named pipe and acting on the "222..". It often takes seconds for the script to pickup the button press and fire off the MQTT message. mrxyz's notify program was in C but I can't believe an implementation in ash would result in performance this terrible, there's some else going on.

while true; do
  cat /tmp/npc.log | /mnt/disc1/busybox grep -m 1 '222222222222'
  LD_LIBRARY_PATH=/npc /npc/mosquitto_pub -h $MQTT_SERVER -u $MQTT_USER -P $MQTT_PASSWD -t $MQTT_TOPIC -m "DINGDONG" &
done

 

[petervk]

Alright, worked it out. I'm blocking the camera from WAN access, and it seems sometimes when I press the button there's a blocking function already trying to hit an external IP. So this happens:

** PRESS DOORBELL HERE **

sHiRegCmd.dwBaseAddr = 0x20650000 0x2004

** SEVERAL SECONDS LATER **

on_timeout_query_listsrv_resend_v2: http_req already request
http_list_request_done_v2...
http_list_request_done_v2: pkt->data_len=0
http_list_request_done_v2...
http_list_request_done_v2: pkt->data_len=0
init_v2_frm_listsrv 111opt_encrypt=1
init_v2_frm_listsrv 222opt_encrypt=1
init_v2_frm_listsrv 333opt_encrypt=1
p2pu_v2_send_list_request opt=1
on_timeout_query_listsrv_resend_v2: send UDP ListFrmRequest to 123.206.9.74:51701, list_req_cnt = 16, ms_timeout = 15000.
init_v2_frm_listsrv 111opt_encrypt=1
init_v2_frm_listsrv 222opt_encrypt=1
init_v2_frm_listsrv 333opt_encrypt=1
p2pu_v2_send_list_request opt=1
on_timeout_query_listsrv_resend_v2: send UDP ListFrmRequest to 121.43.181.184:51701, list_req_cnt = 16, ms_timeout = 15000.
keyup =  2
222222222222

The sHiRegCmd... string is coming from a kernel driver as it gets printed to the console irrespective of where npc's output is going, and it's printed immediately upon button press. So my script now looks like this:

while read line; do
  if echo $line | /mnt/disc1/busybox grep "sHiRegCmd.dwBaseAddr = 0x20650000 0x2004" ; then
    LD_LIBRARY_PATH=/npc /npc/mosquitto_pub -h $MQTT_SERVER -u $MQTT_USER -P $MQTT_PASSWD -t $MQTT_TOPIC -m "DINGDONG" &
  fi
done < /proc/kmsg

@Florissilfhout - what decompiler is that? I dont recognise the view...

 

[Florissilfhout]

Great progress @petervk!
At the moment I am struggling to get the gmwf tool to work (something about No module Crypto.Cipher). So I haven't actually installed anything new on the doorbell yet. Also, I am new to MQTT but it seems to be something I want to implement

The decompiler I'm comfortable with is Ghidra. Here is where I am thinking to patch the reboot issue (stop the increment of the DayCounter by setting it to 0x0):


Other than the challenges mentioned, how would I be able to use the doorbell with two-way audio in conjunction with my Synology NAS?

 

[Florissilfhout]

At the moment I am struggling to get the gmwf tool to work (something about No module Crypto.Cipher).

Nevermind, messed up the pip/python versions

 

[mrxyz]

Other than the challenges mentioned, how would I be able to use the doorbell with two-way audio in conjunction with my Synology NAS?

Iirc audio is available via the onvif stream. To play audio on the device I'd write some code to do that, but perhaps there are easier ways (pipe some data over a socket via e.g. netcat, and play that using some audio player e.g. mpg123 or whatever).

 

[petervk]

I run Home Assistant, hence wanting to get MQTT working from the camera so I can trigger automations when the button's pressed. I'm also running Blue Iris and the camera works great with that.

Look forward to hearing how you go with the reboot stuff, I think thats the last thing I'd like to change from stock behaviour.

 

[Florissilfhout]

I could use some assistance.
I have packed and signed the patched binary (with the npc file containing "telnetd & /npc/npc_fps_noReboot &") as version 13.01.01.31.
I placed this npcupg_13.01.01.31.bin in the root of the SD card and inserted it. Unblocking the camera from WAN gives YooSee app control back and says current firmware is the latest (13.1.1.36).
1. How do I force install this update on the SD card (without anything connected to UART)?
2. Shouldn't the .bin also contain telnet somewhere (other than the command to start the service)?

 

[petervk]

I believe the file on the SD card needs to be named npcupg.bin (not sure I've ever seen this work, can't remember). However - I use a windows utility to do the upgrade :


telnetd was always on the original rootfs, it's just not started by default..which we change on our updated /npc/npc script.

I have packed and signed the patched binary (with the npc file containing "telnetd & /npc/npc_fps_noReboot &") as version 13.01.01.31.

Is this verbatim or a indicative? If they're on the same line like this you'll need a semicolon in between.

 

[Florissilfhout]

Thanks for the Tool. I couldn't get it to find the camera (maybe a VM issue) but renaming the file seems to have worked! The app mentioned a new firmware was available, it's installing as we speak.

About the telnetd command, in the npc file they are not on the same line Thanks for checking