Hacking Zosi DVR - goal: to access a standard vid stream

[panic916 0]

I have a Zosi ZR08ZM10 DVR that I got from Amazon cheap for black friday. I was hoping to replace my previous cheap Floureon DVR but I have an issue I'm trying to resolve. Both the Zosi and Floureon seem to be running that same software that it seems all cheap Chinese DVRs run, but the Zosi is much faster and less buggy (and clearly a newer version). The Zosi, however, will not provide any standard video streaming mechanisms (RTSP, MJPG/HTTP, etc) despite there being port settings in the configuration. Zosi support has confirmed that this model doesn't support that.

 

A port scan of the entire TCP range, returns ZERO open ports!

 

Yet they have a Windows app that does offer streaming video. But this won't work for me since I would like to use various clients directly, including GStreamer and VLC.

 

So my thoughts (hopes) are this:

• Possibly the unit has a firewall in place but the firmware actually does support RTSP / HTTP (like my Floureon one did)?
  
  • Perhaps I can gain root on the unit via a serial cable?

  [*]The stream to my PC via their proprietary software is using UDP and may have some non-standard handshake, but I would be surprised if the final stream wasn't a standard one (not sure how I could tap into that)

 

I've downloaded their Windows app (called AVSS) Aand began dissecting it to see how the stream is established (via Windows Message Analyzer, Wireshark, disassembling / debugging it with x64dbg, and strings.exe). It seems to be using some "p2p" libraries to communicate via UDP. It's hitting several external servers, to do so. I have a feeling that once the connection has been established, it may be a standard stream and perhaps I could tap into it.

 

The libraries include these files:

 

• AVAPIs.dll
  
• IOTCAPIs.dll
  
• P2PTunnelAPIs.dll

 

IPs it's hitting include:

• 120.24.59.150
  
• 114.215.137.159
  
• 50.7.98.242
  
• 52.79.197.188
  
• 139.162.174.232

 

The mainboard seems to have this printed on it (which i haven't found any datasheet for): TP2833C_DHI3520DV300_081E

 

(tl;dr;) So my questions are:

 

• Does anyone have experience hacking and getting into one of these Zosi ZR08ZM10 units?
  
• Has anyone played with this p2p API (the DLLs and whatnot)?
  
• Does anyone know if this mainboard has a terminal which is accessible via serial connection?

 

Thanks! - photos below

[wymangr 0]

@panic916 I know this is a really old post, but were you ever able to figure this out? 

[panic916 0]

@wymangr No I haven't.  I sorta gave up.  I'm in the process of moving into a new house, and I'm going to be setting this up again in the next week or two there.  As a result, I foresee a renewed interest in hacking this coming up on the horizon lol.

[wymangr 0]

@panic916 Let me know if you have any luck. I'll be banging my head against it trying to figure it out... lol

[Kaetemi 0]

I did this for a different Zosi revision that still had the port 5000 open. (This is the port that the iVSS tool connects to.)

https://github.com/kaetemi/sdk_for_zr04rn

Newer boxes seem to have all the ports closed, even though it still lists the port 5000 service in the configuration.

My bet is that they just closed the ports, and now establish an outgoing connection to their cloud services, to create a tunnel, which just connects to the same port 5000 service that way. EDIT: Seems not.

[Kaetemi 0]

On my new box, port 30100 is open, though. No idea what it's for.

EDIT: Interesting. It does seem to create local LAN UDP traffic to port 33484 on the box. Large amounts while playing video. A 32 byte packet every second while idle.

EDIT2: The UDP traffic seems to be initiated by the box.

Also, I'm seeing UDP broadcast traffic from the cameras that are connected to the box's ethernet ports leaking into the LAN. I wonder if the box will route the traffic somehow. This after the box broadcasts 51a80000000000000000000000000000 from port 18153 to 18152. The camera message comes from port 18152 to port 18153.

EDIT3: If you add routing to 192.168.138.0/24 to the IP address of the CCTV box, it also responds at address 192.168.138.99. No difference in which ports are open, though. It does not seem to route the cameras.

EDIT4: Set your own IP address in the 138 range (below 99), the cameras appear to be reachable directly. The CCTV box acts like a regular switch between the LAN and PoE ports. Camera has open ports 23, 554, 8000, and 8080.

Port 554 on the camera:

RTSP/1.0 400 Bad Request
Cache-Control: no-cache
Server: Hisilicon Ipcam

Port 23 on the camera:

(none) login:
Password:
Login incorrect

 

[Kaetemi 0]

It seems the cameras can be accessed directly through RTSP. There's zero security, the box acts like a switch with its own DHCP server on the PoE side.

Check your CCTV box settings to see which network the box assigns to the cameras. This should be 192.168.138.0/24.

Add an IP address to your system within the same subnet. The CCTV box can be pinged at 192.168.138.99.

The cameras will have IP addresses 192.168.138.100 to 199.

Connect using this URL format to access the HD stream: rtsp://192.168.138.105:554/11, and the SD stream: rtsp://192.168.138.105:554/12

[Echo108 0]

Hi, I am new on this forum and I know this is an old post but I would like to resurrect it for the sake of those who have to deal with zosi support (if you call it that) anyway I too hit all the brick walls and I was able to ascertain that the avss program can be run in linux as I do not use windows anything, zosi support said it could never be done, so if I can achieve that I am sure we can get into this box. I was interested in a serial connection, I built a server on a pogoplug using this same technique and since I am now retired I find more time to dink around with this stuff when the spirit moves me. The connection for that device is pretty straight forward and I may have to open up the the unit to see if I can dissect it further. If I can find the serial connector on the board I can use the usb to serial adapter I have and run picocom on my linux terminal and hopefully I see something, I will get back on here later with results even if they fail, just putting stuff down so I remember to try them. If anyone here found a way to save some time regarding the zosi backdoor I would really appreciate it:) Anyway my reason for access is because they tell me my IP cam is digital and will not connect to the dvr because it cannot run wifi, well I installed the wifi and it is connected but the ddns refuses to connect to my NOIP account no matter what I try and I am stumped and the best way to achieve this is to look at the inside of the programming. Any thoughts? Thanks in advance! Echo

[Carbon_Digital_Solutions 0]

I'd certainly like to Hear about this, I just got hired to Extract data from the System, Zosi tells me I have to use a fat32 thumb drive no larger than 64gb.... can you imagine moving 2tb of data 64gb at a time?

I'm making a byte-to-byte copy of the drive using a Ubuntu computer with the dd command.

I found a bunch of UDP Ports open using NMAP and tried some packet captures on Wireshark. 

The two devices are on a direct connect network. 

Does anyone know how to use the "device CMD" in the ZOSI "AVSS" pc application? I tried some commands like "ls -a, pwd, cd /" but none of them show any responses. 

I can only assume the system is running Linux of some type, but the HDD seems to have its own filesystem because even my Linux machine can't recognize the filesystem format, and its got support for almost any filesystem you can imagine. 

Open ports

PORT      STATE         SERVICE        VERSION

774/udp   open|filtered acmaint_dbd

1031/udp  open|filtered iad2

1058/udp  open|filtered nim

8001/udp  open|filtered vcom-tunnel

20249/udp open|filtered unknown

20465/udp open|filtered unknown

21358/udp open|filtered unknown

22846/udp open|filtered unknown

33717/udp open|filtered unknown

37843/udp open|filtered unknown

47624/udp open|filtered directplaysrvr

49189/udp open|filtered unknown

-------------------------------------------------SCAN OUTPUT-------------------------------------------------------------------------------

Starting Nmap 7.92 ( https://nmap.org ) at 2022-12-31 23:03 Mountain Standard Time

NSE: Loaded 296 scripts for scanning.

NSE: Script Pre-scanning.

Initiating NSE at 23:03

NSE: [shodan-api] Error: Please specify your ShodanAPI key with the shodan-api.apikey argument

NSE: [mtrace] A source IP must be provided through fromip argument.

Completed NSE at 23:04, 10.72s elapsed

Initiating NSE at 23:04

Completed NSE at 23:04, 0.00s elapsed

Initiating NSE at 23:04

Completed NSE at 23:04, 0.00s elapsed

Pre-scan script results:

|_hostmap-robtex: *TEMPORARILY DISABLED* due to changes in Robtex's API. See https://www.robtex.com/api/

| targets-asn: 

|_  targets-asn.asn is a mandatory parameter

|_http-robtex-shared-ns: *TEMPORARILY DISABLED* due to changes in Robtex's API. See https://www.robtex.com/api/

| broadcast-igmp-discovery: 

Scanning 192.168.1.10 [1 port]

Completed ARP Ping Scan at 23:04, 0.03s elapsed (1 total hosts)

Initiating Parallel DNS resolution of 1 host. at 23:04

Completed Parallel DNS resolution of 1 host. at 23:04, 13.04s elapsed

Initiating SYN Stealth Scan at 23:04

Scanning 192.168.1.10 [1000 ports]

Completed SYN Stealth Scan at 23:04, 0.17s elapsed (1000 total ports)

Initiating UDP Scan at 23:04

Scanning 192.168.1.10 [1000 ports]

Increasing send delay for 192.168.1.10 from 0 to 50 due to max_successful_tryno increase to 5

Increasing send delay for 192.168.1.10 from 50 to 100 due to max_successful_tryno increase to 6

Warning: 192.168.1.10 giving up on port because retransmission cap hit (6).

Increasing send delay for 192.168.1.10 from 100 to 200 due to 11 out of 11 dropped probes since last increase.

Increasing send delay for 192.168.1.10 from 200 to 400 due to 11 out of 11 dropped probes since last increase.

UDP Scan Timing: About 6.19% done; ETC: 23:12 (0:07:50 remaining)

Increasing send delay for 192.168.1.10 from 400 to 800 due to 11 out of 11 dropped probes since last increase.

UDP Scan Timing: About 92.06% done; ETC: 23:20 (0:01:16 remaining)

Completed UDP Scan at 23:20, 989.67s elapsed (1000 total ports)

Initiating Service scan at 23:20

Scanning 12 services on 192.168.1.10

Service scan Timing: About 8.33% done; ETC: 23:40 (0:17:58 remaining)

Completed Service scan at 23:22, 97.67s elapsed (12 services on 1 host)

Initiating OS detection (try #1) against 192.168.1.10

Retrying OS detection (try #2) against 192.168.1.10

NSE: Script scanning 192.168.1.10.

Initiating NSE at 23:22

Completed NSE at 23:25, 168.63s elapsed

Initiating NSE at 23:25

Completed NSE at 23:25, 1.03s elapsed

Initiating NSE at 23:25

Completed NSE at 23:25, 0.00s elapsed

Nmap scan report for 192.168.1.10

Host is up (0.0016s latency).

Not shown: 1000 closed tcp ports (reset), 988 closed udp ports (port-unreach)

PORT      STATE         SERVICE        VERSION

774/udp   open|filtered acmaint_dbd

1031/udp  open|filtered iad2

1058/udp  open|filtered nim

8001/udp  open|filtered vcom-tunnel

20249/udp open|filtered unknown

20465/udp open|filtered unknown

21358/udp open|filtered unknown

22846/udp open|filtered unknown

33717/udp open|filtered unknown

37843/udp open|filtered unknown

47624/udp open|filtered directplaysrvr

49189/udp open|filtered unknown

MAC Address: REDACTED (Ieee Registration Authority)

Too many fingerprints match this host to give specific OS details

Network Distance: 1 hop

Host script results:

|_ipidseq: ERROR: Script execution failed (use -d to debug)

|_fcrdns: FAIL (No PTR record)

|_path-mtu: ERROR: Script execution failed (use -d to debug)

| traceroute-geolocation: 

|   HOP  RTT   ADDRESS       GEOLOCATION

|_  1    1.62  192.168.1.10  - ,- 

|_firewalk: ERROR: Script execution failed (use -d to debug)

TRACEROUTE

HOP RTT     ADDRESS

1   1.62 ms 192.168.1.10

NSE: Script Post-scanning.

Initiating NSE at 23:25

Completed NSE at 23:25, 0.00s elapsed

Initiating NSE at 23:25

Completed NSE at 23:25, 0.00s elapsed

Initiating NSE at 23:25

Completed NSE at 23:25, 0.00s elapsed

Read data files from: F:\Network Programs\Nmap

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 1286.28 seconds

           Raw packets sent: 2448 (111.782KB) | Rcvd: 2008 (114.969KB)

[tomcctv 190]

49 minutes ago, Carbon_Digital_Solutions said:

I can only assume the system is running Linux of some type, but the HDD seems to have its own filesystem because even my Linux machine can't recognize the filesystem format, and its got support for almost any filesystem you can imagine. 

Hi you are right ….. do you not have access to the recorder ?

you will have a problem if this footage is to be used for court ……only native files can be used in court not altered files …. Signature and watermark must be available 

why do you need 2tb of footage

[ahmouse 0]

Hello everyone,

I just ordered a ZOSI 8 channel BNC Analog DVR (Model name: ZR08VM) for my 8 analog cameras, and managed to find the RTSP streams!

The RTSP stream is located at rtsp://192.168.x.x/video9 of course replacing the IP address with your DVR's IP. (May appear as Ansjer Electronics on your router's device list or an nmap scan)
For some reason the channel numbers start at 9, so for me channel 1 was found at URL ending with video9, channel 2 at URL ending with video10 and so on. It also seems there's no security, so even if you setup a password on the box, the rtsp stream can be accessed without it. For that reason, I would recommend using a server to act as a firewall between the box and the internet, so that the streams are never directly exposed to the network without authentication.

On this model only port 554 (RTSP) was open, and after many hours of toying with nmap I started just trying common RTSP URLs suggested online. I noticed that most of the time the connection would close immediately, but when I tried rtsp://192.168.x.x/video1 it simply got stuck trying to connect, but didn't close instantly. I figured this was a good sign, and tried different changing that last number until I found the correct range (9-16) which may be different for you depending on the model.

Since BNC PCIe cards are expensive (and for security reasons), I wanted to just use this DVR solely for its BNC ports to feed the streams to my home server where I'll actually manage the cameras. Thankfully, I can now do that easily with RTSP while bypassing the crappy firmware on the box!