Reverse Engineering di una IP Cam (Parte 2): Liberare una vecchia cam dal Cloud Cinese
Postato il 21 Gennaio 2026
Avete presente quei dispositivi IoT (videocitofoni, telecamere, sensori) che diventano improvvisamente inutili perché l’app ufficiale sparisce dagli store o i server cloud in Cina vengono spenti trasformando il dispositivo in un inutile e costoso fermacarte? Mi è successo con una IP Cam Unotec basata su chipset HiSilicon Hi3510. Niente interfaccia web accessibile, solo un hardware ostinato che cercava di contattare server remoti ormai inesistenti.
In questo articolo vi spiego come ho ripreso il controllo totale del dispositivo, trasformando un fermacarte in una sentinella locale che salva immagini su un server Debian “in house”, senza passare per server esterni.
La Strategia: DNS Hijacking e FTP Mirroring
Analizzando il traffico di rete, è emerso che la telecamera cercava di risolvere il dominio www.myidoorbell.com per caricare contenuti via FTP. L’idea è stata semplice quanto efficace: attuare un Man-in-the-Middle amichevole.
1. Reindirizzamento DNS con Pi-hole
Per intercettare la telecamera, ho utilizzato Pi-hole. Ho creato un record DNS locale in modo che ogni richiesta verso il dominio cloud venisse risolta con l’IP del mio server Debian interno (192.168.5.110).
Configurazione del Server FTP (vsftpd)
La telecamera è “vecchia scuola” e utilizza il protocollo FTP in modalità passiva. Molte configurazioni moderne di vsftpd falliscono perché mappano le connessioni in IPv6 o non comunicano correttamente l’IP locale per il trasferimento dati.
Dopo vari test, la configurazione vincente nel file /etc/vsftpd.conf è stata:
listen=YES
listen_ipv6=NO
pasv_address=192.168.5.110
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100Senza la direttiva pasv_address, il server rispondeva con un indirizzo nullo (0.0.0.0), impedendo alla cam di trasmettere i byte dell’immagine, nonostante il login avvenisse correttamente.
Il “Telecomando” CGI: Attivare i Sensori
Una volta sistemato il ponte DNS e FTP, la telecamera si connetteva ma inviava file vuoti. Il motivo? Il sensore di movimento (Motion Detection) era disabilitato di default nei parametri interni.
Non potendo ricompattare il firmware per via dei controlli di integrità (checksum), ho sfruttato le API CGI esposte dal chip Hi3510. Usando le credenziali scovate nei file di configurazione (admin:admin), ho inviato i comandi 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"Risultato Finale
Al lancio del comando testftp, il server Debian ha loggato correttamente l’upload: un file JPG nitido, catturato direttamente dal sensore della cam e salvato localmente.
Conclusioni
- DNS è Potere: Se controlli la risoluzione dei nomi nella tua rete, controlli il comportamento dei tuoi dispositivi IoT.
- Reverse Engineering “Leggero”: Spesso non serve riscrivere il firmware; basta capire come il dispositivo comunica con l’esterno.
- Privacy Garantita: Ora la Cam è isolata dal web, non invia dati a server sconosciuti e continua a svolgere il suo lavoro on-premise.
- To do: Devo ancora trovarmi un fermacarte.
0 commenti