Estimated reading time: 5 minutes

One day you wake up, you look at an old device that has been sitting in a drawer for many years – in my case an IP camera with a glorious but stubborn HiSilicon chip hi3510 – and decide that the time has come to do things right. You tell yourself: “No more proprietary clouds, no more shady apps on your smartphone. Today I set up saving videos via FTP directly on my local computer.”. A bit of choice’ obligatory, also because support for these devices often ceases “cloud” within a few months of their launch on the market.

In my case instead of using my Linux PC I will use my Linux server. Open Media Vault (OMV) is a Debian-based distribution that allows me to manage my files and shares as easily as I would with a NAS. I also have the ability to start docker and any service it supports… and then it's Linux: I have all the tools I'm familiar with at my disposal.

There's only one little one, huge problem: in the settings of this camera there is no entry relating to FTP. A voice in my head suggests to me: “Hey, one moment… I hadn't found my voice FTP in the configuration files?” In fact it is like this, but in the cam interface you cannot enter a destination server, you cannot change username, password o porte.

“Ok, this cam has the address of an FTP server in one of its configuration files, an FTP port and a pair of credentials, but nothing can be seen in the interface. So this cam uses FTP or not? And he uses it… what it conveys? Where it broadcasts? How it transmits?”

The device is a black box and the FTP is probably programmed by the Chinese manufacturer to package the videos and send them straight and only to their remote servers through a proprietary application.

Wonderful! Thus begins one of those classic nocturnal adventures made of open terminals, network packets captured on the fly and hours spent making reverse engineering on a firmware that didn't want to collaborate. If you too are trapped in the limbo of Chinese cam error codes, that's how I got out alive.

---

First obstacle: The great DNS deception (The mistake -2)

The first thing you do when a device won't connect is check the configuration files. By downloading the file config_action.ini of the camera, the first ridiculous detail emerged: the firmware completely ignored the local IP of the NAS that I had entered on the screen. It was written in his code, stiff as marble, that to do any tests the cam had to first contact the parent company's server: www.myidoorbell.com. Needless to say, that site no longer exists… but the cam doesn't know that.

Until the cam received a response from that web address, the FTP test didn't even start, spitting out a generic Error -2 (host unreachable), or at least that's what I thought.

How to solve? I used AdGuard Home (a local DNS like others) to create a custom DNS rewrite rule. I told my router: “Senti, when the camera searches www.myidoorbell.com, Don't send it on the internet. Give her the IP of my OMV (192.168.5.10)”.

At that point the cam took the bait. But the mistake became another.

---

Second obstacle: Dirty syntax and silent logs (The mistake -3)

Fixed DNS, the cam error code has passed by -2 a -3. One step forward, some, but there was a frustrating problem: the OpenMediaVault FTP server (ProFTPD) it didn't show absolutely nothing here log. The total desert.

Searching the depths of HiSilicon firmware, it turns out that these chips send FTP commands with a syntax “dirty”, adding random whitespace to the end of strings. To digest this stuff, I had to create a custom configuration file for ProFTPD (/etc/proftpd/conf.d/cam_fix.conf) inserting some tolerance directives, among which:

MultilineRFC2228 on
ServerIdent on "Ready"

This cleaned up the messages, but the test kept failing with error -3 e ProFTPD rimaneva ostinatamente muto. Why?

---

The “Boss Finale”: Interception with tcpdump

When software logs lie to you or keep quiet, there is only one thing to do: listen directly to the network cables. I opened the OMV terminal and launched the final diagnostic command to intercept the cam traffic:

sudo tcpdump -ni any host 192.168.5.125

I re-ran the test and the crime scene appeared in real time. The cam was knocking on the door 21 (FTP), the server responded saying it was ready, the cam sent the username and at that point the server slammed the door in her face with this message:

FTP: 550 Richiesto SSL/TLS sul canale di controllo

Mystery revealed! By default, recent versions of OpenMediaVault are (rightly) configured to expect encrypted and secure FTP connections (FTPS). But the old camera chip, being rudimentary, it didn't support encryption at all and only spoke classic plaintext FTP. Feeling the connection rejected due to lack of TLS, the cam closed the session instantly, even preventing the login from being recorded in the system logs.

All it took was going to the OMV dashboard, disable the TLS/SSL requirement in the FTP service settings (allowing unencrypted traffic in the local network) and restart the daemon.

In the end, one last touch: from the package dump I noticed that the cam truncated the password to soli 8 characters, ignoring the subsequent spaces generated by the bug of its own web panel. I aligned the Linux user password on OMV to those 8 exact characters with sudo chpasswd and…

HTTP/1.1 200 OK -> result="0"

Vittoria! The cam is logged in, wrote his test file into the shared folder and closed the session. Control was finally mine.

---

A necessary reflection: Who owns our data?

This nocturnal fiddling, as well as the satisfaction of having bent the hardware to my will, it left me with a deep feeling of uneasiness.

You remember the three initial questions? They were “What it conveys?”, “Where it broadcasts?” and “How it transmits?”.

Think about it carefully. We buy shiny electronics, often attracted by rock-bottom prices and cleanly designed boxes. We discard them, we connect them to the power outlet and install an app that asks us to create yet another cloud account. At that precise moment, we're sneaking into our homes, in our rooms, in front of our family intimacy, an electronic eye operated by the “Mr. Nobody”.

During this analysis we discovered two chilling things about this device of dubious origin:

1. Zero consensus, zero transparency: Even if you configure the cam to work locally, the firmware is programmed to bypass your choices and send data to a remote server (www.myidoorbell.com) located who knows where, without the user ever having signed or understood real consent for the management of that traffic.
2. The total lack of security: The camera claimed to send video streams and login credentials over an FTP connection completely clear, not encrypted. It means anyone, along the chain of internet nodes between our house and the Chinese server, could have intercepted, watch and save our videos without any effort.

Data sovereignty is not an abstract concept for web philosophers; it is the conscious decision to take back the keys to your own house. Spend an hour setting up a local server, forcing a wayward piece of silicon to work under our rules and isolating it from the internet amused me, but it's not just a nerd pastime. It is the only way left to draw an insurmountable boundary between our private lives and the opacity of a technological market that wants us to be constantly transparent, tracked and vulnerable.

When you buy your next piece of technology, think carefully about what might be behind it, because today there are not only surveillance cameras, but smart peepholes, cameras integrated into the light bulbs under the porch, cameras on cars, cameras on robot vacuum cleaners. We really trust all these manufacturers?