[ZEUS News - www.zeusnews.it - 03-11-2025]

Harishankar Narayanan è un ingegnere del software con una passione per l'hardware fai-da-te che ha acquistato un aspirapolvere robot iLife A11 (per circa 300 dollari), attratto dalle sue funzioni smart come la mappatura LIDAR e la navigazione autonoma. Dopo alcuni mesi di utilizzo, ha deciso di monitorare il traffico di rete del dispositivo, scoprendo che inviava continuamente log e dati di telemetria ai server del produttore in Cina, senza aver ricevuto un consenso esplicito da parte sua.
Tra i dati trasmessi figuravano mappe 3D della casa generate tramite Google Cartographer, un software open-source che il SoC AllWinner A33 del robot non riusciva a processare localmente per limiti di potenza computazionale. Narayanan ha reagito bloccando gli IP dei server di telemetria sulla sua rete domestica, lasciando aperti quelli per aggiornamenti firmware e OTA, con l'intento di preservare la privacy senza interrompere le funzioni essenziali.
Inizialmente l'aspirapolvere ha continuato a funzionare normalmente per alcuni giorni, ma a un certo punto ha smesso di accendersi. Narayanan lo ha portato più volte in un centro assistenza, dove i tecnici non rilevavano anomalie hardware e lo restituivano operativo, per vederlo fermarsi di nuovo completamente una volta ricollegato alla rete protetta. Il ciclo si è ripetuto fino a quando il servizio ha rifiutato ulteriori riparazioni, citando la scadenza della garanzia. Non avendo più nulla da perdere, a quel punto Narayanan ha disassemblato il dispositivo, rivelando un sistema basato su TinaLinux e un microcontroller per i sensori, con un errore di configurazione potenzialmente molto serio: l'Android Debug Bridge (ADB) era esposto e non protetto da password, consentendo accesso di root.
Ha bypassato facilmente una misura di sicurezza improvvisata del produttore che consisteva nell'omissione di un file essenziale; ha analizzato i log, scoprendo un comando di kill remoto emesso esattamente nel momento in cui il robot si era fermato. Identificato come un script inviato dai server del produttore, il comando disabilitava permanentemente il dispositivo non appena rilevava l'impossibilità di comunicare con i server di telemetria, interpretando il blocco come una «violazione di conformità».
«Qualcuno - o qualcosa - aveva emesso un comando di kill remoto. Che fosse una punizione intenzionale o un'applicazione automatica di "conformità", il risultato era lo stesso: un dispositivo consumer si era rivoltato contro il suo proprietario» ha raccontato Narayanan. Al centro assistenza, il reset del firmware rimuoveva temporaneamente il kill switch e la connessione a una rete aperta permetteva la comunicazione: così si ottenevano i "miracolosi" recuperi temporanei.
Lo storia però non finisce qui. Per contrastare il problema Narayanan ha invertito il comando di kill, riportando il robot in vita istantaneamente. Non soddisfatto, ha proseguito con un reverse engineering approfondito: ha creato connettori PCB personalizzati e scritto script in Python per controllare i componenti dal computer, testando sensori, motori e LIDAR individualmente. Ha persino assemblato un joystick con Raspberry Pi per guidare manualmente l'aspirapolvere, confermando l'assenza di guasti hardware. Il risultato è stato una configurazione completamente offline: il robot ora opera localmente senza dipendere da server remoti, gestendo la mappatura e la navigazione con un'elaborazione onboard potenziata da script personalizzati.
Questo approccio non solo ha salvato il dispositivo da un destino di e-waste, ma ha anche eliminato la dipendenza dall'elaborazione nel cloud, riducendo le latenze e i rischi di privacy. Molti aspirapolvere smart, inclusi modelli di brand cinesi meno noti, usano hardware simile con "backdoor" come per la gestione remota, permettendo al produttore di inviare comandi arbitrari o ottenere dati. Aras Nazarovas, ricercatore di Cybernews, ha sottolineato: «Trovare software del genere su un dispositivo smart è preoccupante e merita indagini su come sia stato usato: quali comandi sono stati inviati, se è servito per ottenere dati?».
Narayanan consiglia di isolare i dispositivi IoT su reti dedicate, trattandoli come «sconosciuti in casa» e di evitare di usare il Wi-Fi principale per prevenire accessi non autorizzati ad altri dispositivi connessi. Senza arrivare a possedere le competenze di Narayanan, è evidente che molti acquirenti di questo tipo di prodotti non sono in grado di operare nemmeno questo genere di configurazione: quanti sanno che pressoché tutti i router oggigiorno consentono di creare più di una rete Wi-Fi?
Per Narayanan l'esperienza è stata una lezione: «Non è solo un aspirapolvere; è un monito su ciò che compriamo e come lo controlliamo». Il suo blog offre guide dettagliate per repliche, invitando a un approccio proattivo alla sicurezza domestica in un'era di connettività pervasiva.
| 
Se questo articolo ti è piaciuto e vuoi rimanere sempre informato con Zeus News
ti consigliamo di iscriverti alla Newsletter gratuita.
Inoltre puoi consigliare l'articolo utilizzando uno dei pulsanti qui 
sotto, inserire un commento
(anche anonimo)
o segnalare un refuso.
 © RIPRODUZIONE RISERVATA  | 
  | 
| 
             | 
    ||
 
      
  | 
  
