Estimated reading time: 2 minutes

Posted on 21 January 2026

You know those IoT devices (video intercoms, cameras, sensors) which suddenly become useless because the official app disappears from the stores or the cloud servers in China are turned off, transforming the device into a useless and expensive paperweight? It happened to me with an IP Cam Unotec based on chipset HiSilicon Hi3510. No accessible web interface, just stubborn hardware trying to contact now non-existent remote servers.

In this article I will explain how I regained total control of the device, turning a paperweight into a local sentinel that saves images to a Debian server “in house”, without going through external servers.

The Strategy: DNS Hijacking e FTP Mirroring

Analyzing network traffic, it turned out that the camera was trying to resolve the domain www.myidoorbell.com to upload content via FTP. The idea was as simple as it was effective: implement a Man-in-the-Middle amichevole.

1. DNS redirection with Pi-hole

To intercept the camera, I used Pi-hole. I created a local DNS record so that every request to the cloud domain would be resolved with the IP of my internal Debian server (192.168.5.110).

FTP Server Configuration (vsftpd)

The camera is “old school” and uses the FTP protocol in passive mode. Many modern configurations of vsftpd they fail because they map connections in IPv6 or do not correctly communicate the local IP for data transfer.

After various tests, the winning configuration in the file /etc/vsftpd.conf was:

listen=YES
listen_ipv6=NO
pasv_address=192.168.5.110
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100

Without the directive pasv_address, the server responded with a null address (0.0.0.0), preventing the cam from transmitting the image bytes, even though the login was successful.

The “Remote control” CGI: Activate the Sensors

Once the DNS and FTP bridge is in place, the camera connected but sent blank files. The reason? The motion sensor (Motion Detection) it was disabled by default in the internal parameters.

Not being able to repackage the firmware due to integrity checks (checksum), I took advantage of the API CGI exposed by the Hi3510 chip. Using the credentials found in the configuration files (admin:admin), I sent the commands via HTTP:

# Forza uno scatto immediato e l'invio via FTP
curl -u admin:admin "http://192.168.5.123/cgi-bin/hi3510/param.cgi?cmd=testftp"

# Attiva il rilevamento movimento nell'area principale
curl -u admin:admin "http://192.168.5.123/cgi-bin/hi3510/param.cgi?cmd=setmdattr&-m1_enable=1"

Final Result

When launching the command testftp, the Debian server successfully logged the upload: a sharp JPG file, captured directly by the cam sensor and saved locally.

Conclusions

• DNS and Power: If you check name resolution in your network, you control the behavior of your IoT devices.
• Reverse Engineering “Light”: Often there is no need to rewrite the firmware; you just need to understand how the device communicates with the outside.
• Privacy Guaranteed: Now the Cam is isolated from the web, it does not send data to unknown servers and continues to carry out its work on-premise.
• To do: I still have to find a paperweight.