Analyzing Video Communication Devices for the Deaf

By Jordan Duffy –


Video Communication Devices are prevalent, and they are widely used around the world. However, there are some unique, and proprietary, devices that are to be used by Deaf people. Some examples include the Sorenson ntouch VP, Purple’s SmartVP, and ZVRS’ Z70. The devices mentioned are internet-connected “black-box” devices that enable communication between deaf people, and provides a way for deaf people to communicate with others via the use of an interpreter.

In this case, the author has a Sorenson ntouch VP on hand, and this is the ‘black box’ device I will be analyzing.

Research Tasks:

Basic reconnaissance:

The simplest way to start off analysis of a black box device is to do a port scan. Tools like nmap will be able to achieve this.

The default NMAP scan manages to find only two open ports:

SIP-TLS (port 5061)
SIP (nonstandard port 50060)

Although there are known exploits for SIP, rudimentary testing with nmap’s SIP scripts such as sip-brute, sip-call-spoof, and sip-enum was not effective against this black-box device.

We were able to gather some SIP information from this device however.


This information did not tell us much, but it did tell us what this phone supported, via the use of SIP Allow messages (INVITE, ACK, CANCEL, BYE, MESSAGE, INFO, REFER, NOTIFY)

With nmap, we also could attempt OS detection of this black box device. Nmap is very confident that this device runs on Linux versions 2.6.9 – 2.6.33

The results of nmap scans were not conclusive, as it did not tell us much, other than the fact that this device has two ports open (5061 and 50060)

The next step is to monitor the traffic that goes in and out of this device. This proved to be a bit difficult as I did not have a dedicated network tap. I made use of Windows bridging feature to bridge two Ethernet ports, so traffic would pass through the computer. This proved to be an effective monitoring solution for the time being.

A basic topology diagram:


After getting the topology set up, the next step is to start monitoring all the traffic that passes through this device.

By default, this device uses DHCP to obtain addressing information. This can be changed in the settings, but we’ll be sticking with the defaults for now.

After rebooting this device, and after this device boots up completely, we can see that it goes through the DORA discovery process like any other DHCP-enabled device.


After this process completes, we see several DNS queries being made.


The most notable ones being requests for the following addresses:

Immediately after the first few DNS queries have been made, we see several TCP sessions being established.

The first session establishes a HTTPS session, where most of the communication is encrypted using TLS v1.0 with RSA key exchange.

However, we see some HTTP sessions being established as well. This session will make occasional plaintext HTTP XML requests. Responses are also plaintext.

The first POST request is for the following address:*REDACTED*&i=516375

The ‘u=’ string appears to be the unique ID, and is redacted as it uses the MAC address of the device.

The XML response is as follows:


The XML section just locates the primary and backup service addresses of each “Service Contact”

(where X is a placeholder for 1, or 2 – primary/secondary)

This is interesting information, but doesn’t tell us much. It doesn’t tell us that there is a definite vulnerability within this system. We can try to gather more information to see if this information might become relevant later on.

Let’s try making some calls on this device and see if we can find any interesting SIP stuff going on.

I placed a call to the sorenson’s internal call-back number. This is a number that will initiate and connect a video call with your phone, hang up, and then call back. It’s a great way to see if the data differs when I initiate the call, versus when someone else initiates a call with me.

Recall that most of the communication is encrypted using TLSv1. This was disappointing as I was not able to see the initial call being established. However, I did see UDP packets being sent using the STUN protocol.

STUN stands for Session Traversal Utilities for NAT, and is a way to initiate and maintain UDP connections while behind firewalls/NATs. SIP and RTP traffic will piggyback this STUN traffic.


ChannelData TURN Messages represent the piggy-backed RTP messages, even though it uses the STUN protocol.

The UDP packets themselves once again do not carry any information that could help us exploit a certain vulnerability within this system, but there was something interesting hidden inside the Channel-Bind Success Response STUN message.


The “SOFTWARE” attribute has a value of “Coturn- ‘dan Eider’”. After some research, we see that this is a TURN server software called ‘coturn’ available here and we find that this is an older version of TURN server (August 2016).

Going through the past revisions of this code in github, we see that version fixed a SQL injection vulnerability. It’s possible, but unlikely, that the current version may have unpatched vulnerabilities. This is definitely something to keep in mind for future analysis.

We have analyzed live calls and discovered that Sorenson uses an older TURN server. This is one potential vector of attack, but it will prove to be a challenging one. Let’s try using some other functions within the phone.

Going through the settings menu, we see that there is an option to check for updates. Knowing that ‘update-checkers’ have been popular attack vectors in the past, we can see if this function is vulnerable to attack.

Before checking for updates, I take note that the Application version is, and the bootloader version is Pressing the ‘check for updates’ button results in unencrypted HTTP XML traffic being sent!


We see that this device sends out the version the device is currently running on. After this is sent, we see more HTTP traffic happening



Most notably, we see a HTTP GET request to get what seems to be a firmware update. I copied this URL and could download the firmware image on my computer without any authentication.

I was very curious to see what this file was – if there was a known structure. Luckily, I use a handy linux ‘file’ tool to do that for me!


So this is a Linux kernel image. Recall how nmap identified this device to be a Linux version 2.6.9 – 2.6.33? The ‘file’ command and ‘mkimage’ command tells us that this image is actually Linux version 2.6.30 – which is pretty close!

We can actually extract this image using binwalk available at

“binwalk -Me” will recursively extract all identified images in this Linux u-boot image.


In fact, this utility was able to extract nearly everything inside. I was able to view the root directory after extraction:


This concludes our journey into the sorenson nTouch VP device.


Overall, the ‘black-box’ seems to be well insulated, and did not give out much data when scanning with nmap. However, with continuous network monitoring, we were able to find small pieces of data that might be of some use in the future. The biggest discovery was unencrypted, and unverified firmware updates being done on this device.

Although I was not able to find a publicly available exploit that would work on this device, I believe the discovery of unencrypted and unverified firmware will pave the road to potential exploits in the future, especially when I’m able to extract the firmware image and view the root directory. In theory, it would be possible to create my own, patched firmware image, and fool the device into downloading this image via a proxy. If everything is done correctly, it might be possible to have this device install a modified firmware image. Creating homebrew firmware images is harder said than done, but the potential is still there. This, in my eyes, is a huge flaw.

Ideally, if I had a more experienced hand, I would attempt the following in the future:

  • Analyze STUN messages and see if it’s possible to extract raw RTP packets from it. Right now, the built-in wireshark analyzer does not do a very good job of deciphering it.
  • Attempt SSL downgrade attacks in order to make SSL traffic plaintext if possible.
  • Thoroughly audit the binwalk dump I generated, to find any potential vulnerabilities within this device.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s