Home Home

Fixing RTSP in a Vivotek camera

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
146
articles
June 1, 2020
Tags hardware 7

I own a Vivotek camera. It appears that I haven't been to serious updating the firmware—but neither is the manufacturer—since the camera was bought in 2015, but didn't have the latest firmware released in... 2014.

Although the description of the “new” firmware featured no bugfixes, I still decided to install it. I'm not sure if it made something better, but what's for sure is that it broke RTSP. It just went down, port 554 unreachable.

Although I contacted Vivotek's support, I thought that figuring out the problem myself could probably be a faster alternative. Without much surprise, I found that a popular vulnerability affected my model of the camera as well, and knowing the password of an administrator—that is my own password—I got myself telnet access to the device. This was easy:

  1. Go to the web interface and walk through the pages until an HTTP call is made to a CGI script.
  2. From the network panel, copy the network request as a CURL command.
  3. Modify it accordingly by changing the URI to /cgi-bin/admin/mod_inetd.cgi?telnet=on. It looks like this is the only change I had to do.

Indeed, nmap happily displayed that telnet's port 23 was now open, and I was able to connect with my administrator credentials. The next thing was to figure out what happened.

My first thought was that the firmware hardened the iptables rules, but it appeared that it wasn't the case. The files inside /var/log weren't particularly interesting. After a bit of searching and thanks to netstat -tulpn, I found that nothing was listening on port 554.

Running /etc/init.d/rtsps start was showing a bunch of errors, but not what I wanted. It took a few minutes to understand that, under the hood, it was running the following script:

/usr/sbin/rtsps \
    -a 10.0.0.92 \
    -c /etc/conf.d/config_streamserver.xml \
    -q \
    /etc/conf.d/config_qos.xml \
    -d

Running the script manually and removing the -q (standing for quiet) and -d (standing for daemon), I got the following output:

[StreamingServer_Initial]ChannelNumber 1, PerChannelStreamNumber 2
Addon Caching 0x40137100
Addon Caching 0x40137100
Addon Caching fail!
Addon Caching fail!
Addon Caching 0x4120f080
Addon Caching fail!
Addon Caching fail!
Parse video media info failed for config file /etc/conf.d/config_streamserver.xml!
config file /etc/conf.d/config_streamserver.xml parse failed
initial rtsp server fail

Inspecting the XML file, there was a suspicious thing. There is a block /root/network/rtsp with a lot of options (including the port and the authentication), and among others, it contains four blocks: <s0>, <s1>, <s2>, and <s3>. The first two specify the streams live.sdp and live2.sdp like this:

<s0>
    <enable>1</enable>
    <accessname>live.sdp</accessname>
    <videotrack>0</videotrack>
    <audiotrack>-1</audiotrack>
    <metadatatrack>0</metadatatrack>
    <multicast>
        <alwaysmulticast>0</alwaysmulticast>
        <videoport>5560</videoport>
        <audioport>5562</audioport>
        <ipaddress>239.128.1.99</ipaddress>
        <metadataport>6560</metadataport>
        <audioextraipaddress>239.128.1.99</audioextraipaddress>
        <ttl>15</ttl>
        <vvtkextension>1</vvtkextension>
    </multicast>
</s0>

but the next two blocks look like this:

<s2>
    <enable>1</enable>
    <accessname></accessname>
    <videotrack>2</videotrack>
    <audiotrack></audiotrack>
</s2>

Wait? An enabled stream with absolutely no information inside? That's weird!

Setting <enable> to zero didn't help: /usr/sbin/rtsps continued to claim that it cannot parse the file. However, adding dummy content to the empty nodes helped:

<s2>
    <enable>0</enable>
    <accessname>abc</accessname>
    <videotrack>2</videotrack>
    <audiotrack>abc</audiotrack>
</s2>

Essentially, the parser is unable to parse an XML block which doesn't have any content. That's sad. Anyway, I got rid of <s2> and <s3>, and it seems to be working now.


Vivotek's support appeared to be as great as one would expect. I contacted them on the 1st of June, case number 00078251. A month later, there is still no response. Good job, guys.

On 24th of June, I sent them the following message:

Hi,
Is this expected that you don't even bother answering your customers' questions? I thought the support was just needing some time to answer, but three weeks with absolutely no updates is plainly impolite.

Let's see if mentioning the fact that someone is impolite makes this person less impolite.