Un utilizator și-a „reparat” aspiratorul robot, dezactivat de la distanță de producător după blocarea transmiterii datelor către servere

Un inginer a descoperit că aspiratorul său inteligent iLife A11 a fost dezactivat de la distanță de producător, după ce a blocat colectarea de date. Povestea a devenit un caz emblematic al tensiunii dintre controlul utilizatorilor și apetitul companiilor pentru telemetrie.

Scris de | 3 noiembrie, 2025
Un utilizator și-a „reparat” aspiratorul robot, dezactivat de la distanță de producător după blocarea transmiterii datelor către servere

Cazul unui inginer care și-a „resuscitat” aspiratorul robot iLife A11 a stârnit discuții aprinse despre cât de mult control au producătorii asupra dispozitivelor smart cumpărate de utilizatori. Povestea, relatată de chiar de către Harishankar, un inginer pasionat de securitate, spune că acesta a observat că aspiratorul său trimite constant date și loguri către serverele companiei, fără niciun consimțământ explicit. Pentru a verifica exact ce transmite dispozitivul, acesta a monitorizat traficul de rețea și a identificat IP-urile serverelor responsabile cu colectarea telemetriei. A decis să blocheze accesul către acestea, lăsând totuși deschise serverele de actualizări de firmware. Timp de câteva zile, aspiratorul a funcționat normal, până când, brusc, nu a mai pornit deloc.

După o analiză amănunțită, Harishankar a descoperit că producătorul i-a trimis un „remote kill command”, o instrucțiune care dezactivează complet dispozitivul de la distanță. În service, tehnicienii nu găseau nicio problemă: produsul pornea și funcționa normal, însă imediat ce era reconectat acasă în spatele firewall-ului, acesta revenea la starea de dezactivare, întrucât nu mai comunica cu serverele. În consecință aspiratorul nu mai funcționa deloc în mod offline. După mai multe drumuri și un refuz final din partea centrului de reparații, invocând ieșirea din garanție, inginerul a decis să ia lucrurile în propriile mâini.

„Cineva, sau ceva, a trimis un „kill command”. […] Hai să numim asta exact ce este: retaliere. Fie că a fost o pedeapsă intenționată sau o aplicare automată a politicilor, rezultatul a fost același: dispozitivul s-a întors împotriva proprietarului.”, scrie Harishankar pe blogul său.

A deschis carcasa, a analizat plăcile de bază și a descoperit că sistemul de operare al aspiratorului se bloca în timpul inițializării din cauza lipsei conexiunii cu serverele originale. Folosind componente suplimentare precum un Raspberry Pi și câteva scripturi Python scrise de el, acesta a reușit să modifice firmware-ul, să dezactiveze verificările online și să pornească dispozitivul în mod complet offline.

Cazul său ridică întrebări serioase despre practicile producătorilor de gadgeturi conectate. În esență, un produs cumpărat și plătit integral a fost dezactivat pentru că utilizatorul a refuzat să trimită date de utilizare. Situația readuce în atenție dilema tot mai frecventă din zona Internet of Things: cui aparține, de fapt, un dispozitiv smart: cumpărătorului sau companiei care îl controlează prin software?

Harishankar spune că intenționează să își mențină aspiratorul în modul offline permanent și să publice detaliile tehnice ale reparației, pentru ca și alți utilizatori să poată face același lucru. Cazul său nu este izolat: mai multe exemple similare au fost semnalate în ultimii ani, în special la produse care depind de servere cloud pentru funcționare.

Acesta are și un sfat pentru cei care folosesc dispozitive „Internet of Things” acasă: „niciodată să nu le folosești pe rețeaua WiFi principală” și să „le tratezi ca pe niște străini”.

Etichete: , , , , , , , ,

Sursa: Github