Accessing "Spy" Cam video stream?

garmcqui · Nov 21, 2017

Hi all,

I posted this in the Blue Iris section, but in reality I don't think it's a BI problem, it's hardware/network related.

I spent an eye-watering £19 :lol:

on this cheap "Spy Cam" to allow me to keep an eye on the dogs whilst I am
at work:

It is an AOBO HC001.

https://www.amazon.co.uk/dp/B072J7TCQ3/
PC Software is downloaded from http://www.scc21.net
For what it is, it works great, out of the box it creates its own WiFi network, which you connect to via phone app, into that you put your own router's WiFi details and you can then use the app to connect to the device.

So it is definitely sending a video stream across my WiFi network, I just can't seem to access it.

Using nmap, I scanned the ports on the device, and came up with this:

Starting Nmap 7.60 ( Nmap: the Network Mapper - Free Security Scanner ) at 2017-11-21 16:39 GMT Standard Time
NSE: Loaded 146 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 16:39
Completed NSE at 16:39, 0.00s elapsed
Initiating NSE at 16:39
Completed NSE at 16:39, 0.00s elapsed
Initiating ARP Ping Scan at 16:39
Scanning 192.168.0.1 [1 port]
Completed ARP Ping Scan at 16:39, 0.38s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 16:39
Completed Parallel DNS resolution of 1 host. at 16:40, 16.52s elapsed
Initiating SYN Stealth Scan at 16:40
Scanning 192.168.0.1 [1000 ports]
Discovered open port 21/tcp on 192.168.0.1
Discovered open port 23/tcp on 192.168.0.1
Discovered open port 6789/tcp on 192.168.0.1
Completed SYN Stealth Scan at 16:40, 0.85s elapsed (1000 total ports)
Initiating Service scan at 16:40
Scanning 3 services on 192.168.0.1
Completed Service scan at 16:42, 146.21s elapsed (3 services on 1 host)
Initiating OS detection (try #1) against 192.168.0.1
NSE: Script scanning 192.168.0.1.
Initiating NSE at 16:42
NSE: [ftp-bounce] Couldn't resolve scanme.nmap.org, scanning 10.0.0.1 instead.
Completed NSE at 16:42, 12.53s elapsed
Initiating NSE at 16:42
Completed NSE at 16:42, 1.02s elapsed
Nmap scan report for 192.168.0.1
Host is up (0.014s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp BusyBox ftpd (D-Link DCS-932L IP-Cam camera)
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| total 0
| drwxr-xr-x 2 root root 1029 Apr 28 2017 bin
| drwxr-xr-x 4 root root 0 Nov 22 00:37 dev
| drwxr-xr-x 5 root root 325 Apr 28 2017 etc
| lrwxrwxrwx 1 root root 11 Jun 19 03:00 init -> bin/busybox
| drwxr-xr-x 3 root root 1038 Apr 28 2017 lib
| drwxr-xr-x 4 root root 37 Mar 5 2013 mnt
| dr-xr-xr-x 53 root root 0 Jan 1 1970 proc
| drwxr-xr-x 2 root root 736 May 8 2017 sbin
| dr-xr-xr-x 13 root root 0 Nov 22 00:37 sys
| drwxr-xr-x 2 root root 0 Nov 22 00:37 tmp
| drwxr-xr-x 8 root root 102 Apr 28 2017 usr
|_drwxr-xr-x 6 root root 0 Nov 22 00:37 var
| ftp-syst:
| STAT:
| Server status:
| TYPE: BINARY
|_Ok
23/tcp open telnet BusyBox telnetd
6789/tcp open ibm-db2-admin?
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at Nmap Fingerprint Submitter 2.0 :
SF-Port6789-TCP:V=7.60%I=7%D=11/21%Time=5A1456F7%P=i686-pc-windows-windows
SF:%r(JavaRMI,B,"\x0b\0\x02\x01\0\0\x01\x0004\0");
MAC Address: 02:E0:4C:B0:5C:00 (Unknown)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.10
Uptime guess: 0.001 days (since Tue Nov 21 16:41:55 2017)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=258 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Host: anyka; Device: webcam; CPE: cpe:/h:dlink:dcs-932l

TRACEROUTE
HOP RTT ADDRESS
1 13.50 ms 192.168.0.1

So as you can see, three ports open (21, 23, and 6789?).

Any advice appreciated!

Thanks,

Gareth

quality muffins · Nov 4, 2018

i bought a similar camera from ali express and i'm stuck on the same problem. there is no RTSP support enabled.

what i've found so far is that 2 config files have the line "rtsp_support = 0". you can access them via ftp and the paths are:
/usr/local/factory_cfg.ini <--- this one can't be edited, the ftp server denies uploading anything here
/etc/jffs2/anyka_cfg.ini <-- this one can be edited, but doesn't do anything

my camera appears to be based on the anyka chipset, there are some intresting bits to read in the /var/log/messages file

catcamstar · Nov 4, 2018

What happens if you let ONVIF manager discover this device? Although I don't think that would find anything valuable. If you open the video stream with the app, can you look with wireshark at the headers? You might find anything related to the video stream (whether or not it is rstp or something else).

acollao · Mar 21, 2020

Anyone Found the Solution ??? I have the same camera with Port 21, 23 and 6789

ant_thomas · Sep 2, 2020

Anyone managed anything with this one?

I've got open ports on
21
23
999
6789
6790

None are ONVIF or RTSP as far as I can tell. I've edited various files in /etc/jffs2/ to change the onvif setting to 1 rather than 0 and added "rtsp_support".
Still nothing.

Geraldo V · Mar 30, 2021

No solution?!?! I bought the same camera and only ports tcp 21 and 6789 are available ....

catcamstar · Mar 30, 2021

So much attention in this thread

Did ANYONE try ONVIF manager lol? Wireshark the traffic? Anyone?

Bye!
CC

Marzino · Jul 12, 2021

catcamstar said:
So much attention in this thread Did ANYONE try ONVIF manager lol? Wireshark the traffic? Anyone?

Bye!
CC

Hope this thread is still active.

I have a similar cam and nmap shows this:

Code:

21/tcp   open  ftp            BusyBox ftpd (D-Link DCS-932L IP-Cam camera)
23/tcp   open  telnet         BusyBox telnetd
6789/tcp open  ibm-db2-admin?
8000/tcp open  http-alt?

My cam has a desktop app and so I did do a wireshark capture looking for some indication of how to use the stream with my own NVR and not use the Chinese apps. From what I could tell the packets all look the same. For example the packets from the cam to the desktop app are always 60 bytes and in the other direction always 46 bytes. Also the outbound from the camera port did not show up on my nmap scan, but that could be the type of scan I used (Intense plus UDP). I did try ONVIF manager but it doesn't discover it.

Anyway, here are the Wireshark Packets if it helps. Any help is appreciated.

This is from the camera to the desktop app

Code:

Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{D830D682-B718-47CF-9A9F-02F4246838BF}, id 0
    Interface id: 0 (\Device\NPF_{D830D682-B718-47CF-9A9F-02F4246838BF})
    Encapsulation type: Ethernet (1)
    Arrival Time: Jul 12, 2021 11:18:21.644797000
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1626106701.644797000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 60 bytes (480 bits)
    Capture Length: 60 bytes (480 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:data]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Shenzhen_61:dd:b2 (14:b2:e5:61:dd:b2), Dst: Clevo_55:97:31 (80:fa:5b:55:97:31)
    Destination: Clevo_55:97:31 (80:fa:5b:55:97:31)
        Address: Clevo_55:97:31 (80:fa:5b:55:97:31)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Shenzhen_61:dd:b2 (14:b2:e5:61:dd:b2)
        Address: Shenzhen_61:dd:b2 (14:b2:e5:61:dd:b2)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
    Padding: 0000000000000000000000000000
Internet Protocol Version 4, Src: 192.168.40.60, Dst: 192.168.40.11
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 32
    Identification: 0x0000 (0)
    Flags: 0x40, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x6935 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.40.60
    Destination Address: 192.168.40.11
User Datagram Protocol, Src Port: 27772, Dst Port: 28467
    Source Port: 27772
    Destination Port: 28467
    Length: 12
    Checksum: 0x60ad [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (4 bytes)
Data (4 bytes)
    Data: f1e00000
    [Length: 4]

And this is back to Camera

Code:

Frame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) on interface \Device\NPF_{D830D682-B718-47CF-9A9F-02F4246838BF}, id 0
    Interface id: 0 (\Device\NPF_{D830D682-B718-47CF-9A9F-02F4246838BF})
    Encapsulation type: Ethernet (1)
    Arrival Time: Jul 12, 2021 11:18:21.645016000
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1626106701.645016000 seconds
    [Time delta from previous captured frame: 0.000219000 seconds]
    [Time delta from previous displayed frame: 0.000219000 seconds]
    [Time since reference or first frame: 0.000219000 seconds]
    Frame Number: 2
    Frame Length: 46 bytes (368 bits)
    Capture Length: 46 bytes (368 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:data]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Clevo_55:97:31 (80:fa:5b:55:97:31), Dst: Shenzhen_61:dd:b2 (14:b2:e5:61:dd:b2)
    Destination: Shenzhen_61:dd:b2 (14:b2:e5:61:dd:b2)
        Address: Shenzhen_61:dd:b2 (14:b2:e5:61:dd:b2)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Clevo_55:97:31 (80:fa:5b:55:97:31)
        Address: Clevo_55:97:31 (80:fa:5b:55:97:31)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.40.11, Dst: 192.168.40.60
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 32
    Identification: 0x4164 (16740)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment Offset: 0
    Time to Live: 128
    Protocol: UDP (17)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.40.11
    Destination Address: 192.168.40.60
User Datagram Protocol, Src Port: 28467, Dst Port: 27772
    Source Port: 28467
    Destination Port: 27772
    Length: 12
    Checksum: 0xd1b5 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
        [Time since first frame: 0.000219000 seconds]
        [Time since previous frame: 0.000219000 seconds]
    UDP payload (4 bytes)
Data (4 bytes)
    Data: f1e10000
    [Length: 4]

catcamstar · Aug 1, 2021

Hi!

Probably what you are exchanging with the cam is some "p2p" handshaking, all the other chattering is from the cam to the "cloud" and when you watch the video feeds, that will be "cloud" to your pc/mobile. For that, you need some kind of port mirrorring (or through a "plain" switch wireshark sniffing.

Good luck!
CC

Marzino · Aug 2, 2021

catcamstar said:
Hi!

Probably what you are exchanging with the cam is some "p2p" handshaking, all the other chattering is from the cam to the "cloud" and when you watch the video feeds, that will be "cloud" to your pc/mobile. For that, you need some kind of port mirrorring (or through a "plain" switch wireshark sniffing.

Good luck!
CC

How about this to get more useful data from the capture:

If I hardline my laptop into my modem, and do the port mirroring that way, then run the capture would that get me more useful packets?

I found an FTP port and a telnet port open but the authentication is not tied to the camera configuration. I have run some brute force attacks (Hydra) against both ports but no joy. I'd rather not take it apart to determine the underlying chipset, but that would at least lead me to the firmware which could be useful. I just really want to avoid having to use the remote server to access the cam. So I was hoping there was a stream they were trying to hide that I could intercept, maybe spoof the intended target and then I wouldn't have to let this thing send every capture to some server in china. The cam interface has the recordings as discrete files, so I was thinking the FTP credentials could be useful. I could setup an automatic poll and fetch and pull them into my NVR.

Right now all I can do if I don't want captures going to china is to not setup the access to my local network, but keep it in local hotspot mode where I connect to it is as the client and download via the camera interface but it is manual and a PIA.

Thoughts?

rleyden · Feb 15, 2023

I purchased 2 Aliexpress IP cams in January 2023 trying to find one with a SOC supported by Openipc . Both are probably similar the the camera(s) in this thread or at least have ANYKA SOC. The nmap open ports are as described above. I did open one of them up;
apparent SOC ANYKA AK3918FN080 , V200** CDSJ22P22
Here's a photo. I plan to attach a USB to serial connector to the handy UART points. I'm debating whether to solder or try to find a good pogo pin header.

samueljh1 · Jun 4, 2023

Sorry for the bump, but for anyone interested, I have just written a paper exposing significant security flaws in these specific modules. You can see the post here: [Paper] Spying on the Spy: Security Analysis of Hidden Cameras

Sam

fallenangel3k · Sep 16, 2023

samueljh1 said:
Sorry for the bump, but for anyone interested, I have just written a paper exposing significant security flaws in these specific modules. You can see the post here: [Paper] Spying on the Spy: Security Analysis of Hidden Cameras

Sam

hi! thx for bumping this up again. would love to share my experience with this kind of cams with you... i am "pround" owner of one since yesterday, $17 from temu ^^ i certainly would like to put it under my own control and sure of knowing china is not watching me continously.... nothing to hide but it was obvisiously why this cams are that cheap despite the awesome ir/nightmode quality and sound-level of microphone, etc...

I did a zenmap portscan with udp enabled, too. these udp-ports looks very suspicious.. :

PORT STATE SERVICE VERSION
21/tcp open ftp BusyBox ftpd (D-Link DCS-932L IP-Cam camera)
6789/tcp open ibm-db2-admin?
1040/udp open|filtered netarx
1051/udp open|filtered optima-vnet
1060/udp open|filtered polestar
16919/udp open|filtered unknown
17219/udp open|filtered chipper
22846/udp open|filtered unknown
31337/udp open|filtered BackOrifice <----- ??? not a coincidence port ??
40708/udp open|filtered unknown
41058/udp open|filtered unknown
48255/udp open|filtered unknown
49162/udp open|filtered unknown
49172/udp open|filtered unknown

i am doing a nmap -sS -sU -p 1-65535 -T4 -A -v 192.168.178.15 on it now, maybe more open ports...

will have a look into your work, THANK YOU for sharing openly <3

Marcus

Search

Accessing "Spy" Cam video stream?

garmcqui

Young grasshopper

quality muffins

n3wb

catcamstar

Known around here

acollao

n3wb

ant_thomas

n3wb

Geraldo V

n3wb

catcamstar

Known around here

Marzino

n3wb

catcamstar

Known around here

Marzino

n3wb

rleyden

n3wb

Attachments

samueljh1

Getting the hang of it

fallenangel3k

n3wb