Epilogue
A few days ago I had to replace the old IP camera I use to watch over my dogs and cats, and found out that IP cam technology changed a lot since I bought that old camera. IP cameras are now low-price and ubiquitous. I bought one of those generic models and installed it at my home, expecting to use the same software and network configuration I used before. However, these new cameras do not work the same way. They didn't gave me the same control I had over the old model.
This is the "wonderful" world of P2P camera. My old camera worked by providing an internet webserver where I should connect to receive the images. Simple, but a pain in the ass when you want to access your camera from outside your home LAN. P2P camera are different: Instead of you connecting to the camera, the camera itself connects to a server, and, to see the images, you need to connect your phone to the same server. No matter where you are in the world, if you have an internet connection, you can still receive your camera images. Buuuuut... Despite being easier to configure, this simplicity seemed to also bring some security concerns, and I gave up installing this thing at my home. However, that presented a good opportunity for reverse engineering a third party hardware, and maybe I could even get into the guts of the camera and change the things I didn't like in it.
This series of posts will document this analysis. This is a work in progress. I will add new posts whenever I advance in this study
Discovering the camera
Here is the little thing:
This first difficulty was to find information about the camera. Despite having a company logo printed on its front, I could not find any information about this company on Google. I found several identical cameras being sold online, but under different brands, all of them seem to be Chinese names. The camera box and manual didn't gave any useful information either, on regarding identifying the manufacturer website. It seems there's no easy way to get in touch with them e receive technical support
According to the manual, the only way to configure and operate the camera is by installing an app in your phone. The configuration sequence is:
- Power up the camera. Since it is not yet configured, it will create an internet WiFi network, used only for configuration
- Launch the app on your phone. It will find the WiFi network created by the camera and connect to it
- The app will ask your WiFi (home) network name and password. It will send this data to the camera
- The camera connects to Internet using your WiFi and notifies the manufacturer server that it is alive
- The app connects also to the server and now you can control your camera
Ok. But now I don't want to rely on an external server, so let's dig on how the camera work and try to change that
The fist thing is to find if the camera operating system provides a terminal connection, like SSH, so I could control the camera. Using nmap to see if there's any port open:
nmap founds 2 open TCP ports (554 and 5000), neither related to SSH. 554, however, is related to RTSP, a streaming protocol. That could be an option for receiving the camera images. I'll check this later, since I still would need to discover authentication information for this protocol.
nmap also helps by identifying the operating system (Linux 3.X). That's also a good information, because now we know it uses an opensource OS, not any closed proprietary software that would make things way more complicated.
Analyzing the network traffic
Since the camera takes my WiFi password to send video and audio from my home to an external server, I believe I should understand exactly what if being done with this data. So I fired up Wireshark to analyze the data transferred during the whole camera setting up procedures
A lot to dislike here. The camera is connecting to a lot of servers that I don't think it should. I have no idea why my camera would need to connect to Google, Alibaba or Facebook, but it is, at least, trying to resolve those addresses via DNS.
One interesting thing: The app informs that there's an update available for the camera firmware. So, probably, the camera figured out this by connecting to its manufacturer server, and the app is asking me if I'll allow the installation. By monitoring the traffic, I see the camera is checking this address: http://upg.cloudlinks.cn/api/device/checkupgrade.ashx?ApiVersion=1&DeviceVersion=419430406&KeyID=73dd8ec6718551f970cdcefd8ec77826&CustomerNO=0
Which returns the following json data:
So that's the URL for the new firmware version. I can easily download it. However, the manufactures doesn't want anybody spying on its software, so the firmware file is encoded. I'll try to find out how to decode this later. Let's go back to the video stream.
The server receiving my video is easy to identify on Wireshark. Once the camera connects, a lot of data is sent to this IP. However, every time the camera is restarted, a different server is used. The camera probably has a list of several servers it can use, and selects one from this list from time to time. One of them is this:
Maybe I should be concerned of my video and audio being sent to China, maybe not. I don't know, but I'd rather it not being sent to any other country, since I'm right next to the camera, it could send directly to me. So, let's continue
After configuration, data is initially sent via to a server listening on UDP port 8000. This seems to be an initial connection, maybe the camera and the server use it for some initial handshake. Actual video seems to be sent to UDP port 51892, since the biggest packages go to this port. One interesting thing is that it seems to send a lot of empty data. I would expect a good data compression here, since we're transmitting video to the other side of the world, but this protocol doesn't seem to be very efficient in terms of saving network traffic:
So, I would like to understand more about this protocol, but now I'll be focusing on accessing this Linux system, which I'll try on part 2 of this a study