[Aggiornata] Tre milioni di spazzolini elettrici smart utilizzati come rete botnet per un attacco DDoS

per la lavanda gastrica non c'è nulla di smart?
chiedo per un amico che si ingolfa di cibo

COMUNQUE LA DISCUSSIONE SI E' FATTA INTERESSANTE

Io spero negli esiti ragionevolmente IT

Cosa che, infatti, ho fatto. Ora modifico il messaggio sopra con asterischi in grassetto per marcare il mio argomento, prova a rileggere.



Oh, l'hai scritto eccome.
Hai elencato una serie di premesse e hai tirato queste conclusioni:



Finché ti limiti a dubitare l'onere della prova rimane a me, ma l'onere di provare i controargomenti è tuo, e solo tuo.



E io ti ho mostrato che questa lista non è un buon argomento per affermarlo; ora se vuoi continuare a sostenerlo, devi portare argomenti più convincenti.



OK; in quale modo le specifiche di progetto possono fare in modo che, per esempio, Java sia più efficiente?



OK, a questo punto ne stai facendo una questione di questione di giudizio di valore, certamente insindacabile. La mia risposta, sempre un giudizio di valore e altrettanto insindacabile, è che è demenziale accontentarsi del sufficiente e avere costi maggiori se è possibile avere una soluzione decisamente migliore a costi minori. Sei libero di non essere d'accordo.



Ma "quello che fa piu' comodo" a chi?
Non è chiaro che avere una soluzione che usa meno risorse e costa meno dovrebbe fare comodo al produttore dello spazzolino?



Dovresti spiegare cosa vuol dire "nel suo complesso rispetta meglio le specifiche di progetto", perché sinceramente faccio fatica a capirlo.



Casi specifici come quello di un microcontrollore che deve finire in uno spazzolino?



Non è irrilevante ma che non lo sia non vuol dire che non sia lo strumento migliore per lo scopo, è sempre questione di soppesare i pro e i contro.



"come anche no"



Perdona anche tu la sincerità, ma io invece mi sono fatto l'idea che sia invece tu che non hai la competenza necessaria per dare giudizi, da "a me Java , per quel poco che l'ho visto, non piace e non lo uso" a quell'elenco di punti che fanno pensare che esperienza di sviluppo su microcontrollori, a differenza di me*, tu non ne abbia proprio.
Mi sbaglio?

* Giusto per mostrare che non mi invento niente, da una veloce ricerca sul forum: https://www.hwupgrade.it/forum/showpost.php?p=43762034&postcount=3"][U]1[/U][/URL], https://www.hwupgrade.it/forum/showpost.php?p=46350473&postcount=12"][U]2[/U][/URL], https://www.hwupgrade.it/forum/showpost.php?p=46350966&postcount=17"][U]3[/U][/URL].





A me sembra che tu stia continuamente cercando di spostare i paletti, stiamo ancora parlando di quei [supposti] "Tre milioni di spazzolini elettrici smart utilizzati come rete botnet per un attacco DDoS", oppure di robe professionali che costano chissà cosa, e che dubito fortemente possano essere così diffusi?



Il paragrafo sopra...?

Veramente stai mettendo in dubbio che una VM sia più lenta del codice nativo?



Ah, quindi ora Java non sarebbe semplicemente sufficiente, ma necessario?



E questo, come già detto, dovrebbe essere il tuo dentista a dirtelo.



Ma molto più probabilmente semplicemente perché, nella stragrande maggioranza dei casi, non è necessario.



Su questo siamo perfettamente d'accordo, è la retorica che non mi è piaciuta.



Uhm, quindi la maggior parte della gente ha un supercomputer in tasca, ma che sia meglio sfruttare quello che sia al posto di usarne un altro è "una supposizione".
OK



Altri esempi altrettanto stupidi: se uno non ha Internet, oppure lo spazzolino è scarico.

Assolutamente no. Su un sistema di cui non conosci:
[LIST]
[*]Funzionalita'
[*]Prestazioni
[*]Consumi
[*]Memoria
[*]Algoritmi
[*]Pacchetti software disponibili
[/LIST]

(quindi in pratica di cui non conosci niente)

hai stabilito che la metrica fondamentale sia la bruta velocita' d'esecuzione. E da qui hai detto che C/C++ e' il linguaggio migliore (perche' non assembly hand-tuned mi chiedo allora..).

Quindi sei partito da un'assunzione arbitraria per arrivare alla tua conclusione. Questa per me non e' una dimostrazione (che non puoi fornire per mancanza di informazioni).

Tra le altre cose questa delle prestazioni cade malamente se si fa una minima ricerchina. IMHO non hai molto ben presente cosa sia possibile fare oggi con qualche centinaio di mW.

Qua ad esempio vengono dichiarati 8-12 W di [U]consumo durante l'uso di un generico spazzolino elettrico.[/U] Per confronto, qui il consumo di un https://www.jeffgeerling.com/blog/2021/look-inside-raspberry-pi-zero-2-w-and-rp3a0-au"]Rpi Zero sotto stress e' dichiarato essere [B][U]0.83 W[/U][/B][/URL].

Un Rpi zero e' equipaggiato con un [U]SoC ARM da 1 GHz e 512 MB di RAM[/U]. Quindi una bestiolina del genere impatterebbe di appena il 6-10% il consumo dello spazzolino. Limare molto di piu' i consumi del processore non aumenterebbe particolarmente l'autonomia.

Avere un SoC con potenza simile o anche decisamente inferiore al Rpi [U]potrebbe[/U] non rendere necessario l'utilizzo esclusivo del C++ per la programmazione del sistema di controllo dello spazzolino. E a quel punto, con il parametro delle prestazioni piu' rilassato, altre considerazioni, tra cui quelle che ho fatto io, [U]potrebbero[/U] avere un peso maggiore. Tipo che se trovi quello che ti vende le librerie in Java per il tuo prodotto eviti lo sviluppo in-house delle stesse e risparmi un sacco di tempo e soldi. O magari ti permette di usare un linguaggio memory safe su un dispositivo che sta 24h/24 esposto alla rete.

Ma se anche un Soc piu' potente impattasse di una percentuale maggiore sui consumi, si sta parlando comunque di un dispositivo che viene usato per 5-10 min a sessione prima di essere riposto sulla sua base. Ovvero consumi dell'ordine del Wh prima di ritornare attaccato alla rete. Io tutto questo terribile problema di autonomia non ce lo vedo



"Ha senso" per ribattere alla tua stroncatura senza se ne ma. Se vuoi potevo dire (come ho gia' fatto intendere in diverse maniere):

- Allo stato attuale delle nostre conoscenze riguardo al progetto in questione non ci sono elementi per affermare che il linguaggio di programmazione "Java" sia necessariamente inadatto all'applicazione che e' oggetto di discussione.

Meglio?



Non hai dimostrato proprio niente. Come sopra. Sei partito, senza avere gli elementi di valutazione necessari, da assunzioni arbitrarie per arrivare a conclusioni arbitrarie.



Se ti stai riferendo ai consumi vedi sopra. Senno' specifica meglio.



Come sopra. Non hai gli elementi per dire che il C++ diminuisca i costi. Perche' se da una parte [U]potresti[/U] avere un costo minore dell'hardware, dall'altra [U]potresti[/U] avere maggiori costi di sviluppo e integrazione. Ne tu ne io abbiamo gli elementi per valutarlo.



Come sopra. E' un modo di affrontare i problemi di sviluppo monodimensionale. E' sbagliato prendere una singola metrica (con assunzioni arbitrarie) per valutare le decisioni ingegneristiche su un determinato prodotto.



https://it.wikipedia.org/wiki/Specifica_tecnica



A S S U N Z I O N I A R B I T R A R I E



Vedi che almeno una volta ogni venti quote siamo d'accordo?



Sai, a costo di essere ripetitivo, voglio rimarcare che su questo progetto non conosciamo nulla e che quindi non e' possibile affermare che Java sia una cattiva scelta.



Questa e' una fallacia. Che tu abbia esperienza o meno non ti permette di giudicare un [U]progetto di cui non sai nulla.[/U]

Aggiungo inoltre che il fatto che tu sviluppi su microcontroller (di bassa potenza da quello che vedo) non sia assolutamente indice che tu sia capace di fare un corretto design di un prodotto. Anzi, il tuo modo superficiale di affrontare questo aspetto suggerisce il contrario. Ho la sensazione che parte del problema sia che tu pensi che tutti i problemi riguardanti il mondo embedded o quasi si possano risolvere con un microcontroller da una manciata di MHz o KB e programmazione bare-metal.

Io questo problema lo vedo periodicamente.

Es. dove sto io chi fa lo sviluppo hardware, software e firmware e' separato da chi fa ingegneria dei sistemi (Io nel tempo invece sono andato a rompere le p@lle quasi a tutti ). I colleghi che fanno solo sviluppo per il 100% del loro tempo sono estremamente competenti nel loro settore ma spesso mancano di visione d'insieme sui problemi da affrontare. E alla fine, nelle discussioni capita che la loro propongano design come quelli riprodotti nell'immagine sotto a seconda del loro ambito:

Link ad immagine (click per visualizzarla)

Ovviamente l'input e i feedback di chiunque sono ben accolti. Pero' parte del lavoro e' far capire agli specialisti come mai certe decisioni tecniche che riguardano un determinato sistema sono state prese. E sopra di me ci sono persone con visione d'insieme ancora piu' larga che coordinano lo sviluppo a piu' alto livello.

EDIT

E no. Anche solo il fatto di usare librerie standardizzate gia' incluse, [U]se le caratteristiche del progetto te lo permettono[/U], e' un grosso vantaggio anche in ambito embedded.
Anche solo avere sempre la stessa interfaccia per il networking, indipendentemente dalla piattaforma in cui sei, e' utilissimo da un punto di vista di debugging (posso far girare sul mio computer il codice senza tool appositi), velocita' di sviluppo(non mi devo imparare una nuova libreria ogni volta), portabilita' (se cambio vendor non devo rifare tutto da 0), sicurezza (visto che il codice non deve essere cambiato ad ogni nuova piattaforma, il rischio di introdurre nuovi bug e' ridotto), manutenzione (non devo avere N versioni del codice dove N e' il numero delle API che devono essere supportate).

E scusa se e' poco.

Non a caso anche in ambito embedded esistono OS e soluzioni, anche per C++, che forniscono una singola API su una moltitudine di diverse piattaforme per le motivazioni di cui sopra. Ovviamente il layer di astrazione("l'inutile fardello" costa qualcosa in termini di memoria e prestazioni. Ma e' un costo che in molti casi e' sensato pagare.

Che tu rigetti l'argomento in toto dimostra una visione estremamente limitata dell'informatica da parte tua. Divertente come tu mi lanci accuse da questo punto di vista.

Poi il resto delle argomentazioni del tipo "Java non e' semplice perche' forse potrebbe essere difficile installarlo" oppure "dei vendor che hanno gli IC come core business possono dare lo stesso supporto allo sviluppo software di una realta' come Oracle" non vale neanche la pena commentarle. Evidentemente in ambito embedded sviluppi solo progetti molto semplici se queste sono le tue "argomentazioni".



Non sto spostando proprio niente (?).

EDIT

Comunque 3 milioni di spazzolini di fascia alta medio-alta venduti non e' un numero inverosimile. Solo contando il mercato USA ci sono 331 milioni di abitanti. 3 mln sono lo 0.9% della popolazione. E ci metto la mano sul fuoco che il numero di persone che puo' permettersi uno spazzolino da qualche centinaio di dollari sia ben maggiore.

Ti invito quindi a fare almeno una ricerchina la prossima volta prima di fare insinuazioni o congetture. Che qui nessuno, te compreso, ha la scienza infusa.



No, il mio commento era riferito al fatto che, per l'ennesima volta, tu dichiarassi come le prestazioni siano la parte piu' importante di uno spazzolino smart (ora ho grassettato la parte).



Scusa ma che stai a di' . Dove leggeresti questo? Per te si programma in C/C++ solo in bare metal?



E come fa a dirmelo? Mi appare in sogno dicendo che il giorno prima non ho insistito abbastanza sulla parte interna del secondo molare sinistro?



[U]Scusa ma non e' proprio compito tuo fare questo tipo di valutazioni [/U]



Invece a me non piace che mi si mettano in bocca cose che non dico. Lo trovo poco corretto.



la potenza è nulla senza controllo


Per fare un esempio: a lavoro su un nostro sistema di controllo devo sviluppare un sistema di feedback su CPU. Il crate ha due processori:

[LIST]
[*]Un vetusto PowerPC 440 da 889 DMIPS che stiamo cercando di resuscitare
[*]Un Intel-i7 con due core fisici 9000 DMIPS/core e 4 GB di ram
[/LIST]

Solo con queste informazioni si direbbe che l'i7 sia meglio. Ma:

[LIST]
[*]Dovrei trasferire avanti e indietro i dati da un bus PCIe che e' usato per muovere anche altra roba.
[*]Sull'i7 c'e' linux non realtime. Di conseguenza si ha un naturale jitter nella risposta
[*]Sull'i7 ci sono altre applicazioni pesanti che possono bloccare il mio task di feedback a lungo
[/LIST]

Di contro il PowerPC eseguirebbe solo il mio task di feedback. Inoltre le informazioni verrebbero direttamente caricate su registri dello stesso. Ergo minore latenza e meno jitter.

Il PowerPC e' meno potente dell'I7? Si! Ma questo non significa che usare la CPU piu' potente nelle vicinanze sia sempre la soluzione migliore.

Il caso dello spazzolino e' simile ma peggio. Il sistema dovrebbe appoggiarsi alla rete wireless per scambiare informazioni con il cellulare. Cellulare che non e' assolutamente pensato per task di feedback e che potrebbe inserire ritardi notevoli se sovraccarico, peggiorando l'uso dello spazzolino e quindi la soddisfazione del cliente.

Scusa ma penso che inserire una dipendenza non necessaria da un dispositivo esterno (cellulare), con caratteristiche ignote (Il produttore non ha idea delle prestazioni del cellulare di ogni suo acquirente) e che puo' essere disponibile oppure no per le piu' svariate ragioni, sia cattiva progettazione della peggior specie. Soprattutto visto che con qualche spicciolo puoi mettere un SoC di tutto rispetto. SoC che ti permette di avere lo spazzolino indipendente dal cellulare, che puoi caratterizzare completamente in fase di sviluppo e su cui hai il controllo totale.



Immagino che se uno non ha Internet non si orienti su prodotti IoT? (temporaneamente o permanentemente?) Comunque non vedo il motivo per cui, se va via internet temporaneamente, lo spazzolino non possa essere utilizzato.
Da quello che ho capito leggendo in giro la parte IoT serve principalmente a comunicare al dentista da remoto i risultati dello scan dentale dello spazzolino giorno per giorno. Se per un giorno manca internet non credo sia un grosso problema.

Per la carica vedi sopra.

hmmm.
quasi certamente si collega come quando e dove vuole....


banale.
Fa le statistiche con tutti gli utenti del mondo e tu ovviamente sei nella top ten o sul podio... Sempre che tu compri sempre l'ultimo modello, altrimenti vieni classificato come schiappa moscia e i tuoi dati sono pubblicati su tutti i social ed additati al pubblico ludibrio...


ma per favore, sembra lo spot di una casa produttrice.
dai, dillo che sei del marketing e sei pagato per suggerire qua e là l'utilità di una emerita ciofeca che dirà sempre che sei bravissimo perchè usi il prodotto xy...
poi lo lasci lì per 1 mese e quando lo riprendi sarà programmato per dirti che stai per perdere tutti i denti... salvo che se usi il nuovo modello yx 4° gen che ti salverà la dentatura, e tutti vissero felici e contenti

ho già letto altri tuoi post "entusiasti" per fesserie... dai, su... NON hai passato il test di Turing...

Credo di aver sentito una mosca ronzare.

non cerco ipotesi ma non sono così ingenuo da pensare che sia tutto "lindo",
non mi sorprenderebbe l'interesse nelle abitudini degli utenti-consumatori,
avevo già letto anni fa del pericolo intrusione,
ho anche probabilmente esagerato chiamare la mia come Smart Tv, del 2014 comunque, non 2017 (è una UE40JU6400) ed è UHD 4k... ha sì... uno Smart hub ma non ha una videocamera... o almeno non risulta tra le caratteristiche,
qualora sia celata all'utente, bè, comunque non so che "profilazione" debbano fare, e cosa se ne vorrebero fare... / ma non mi sorprenderebbe...

- per il resto... la discussione, a visione di uno sconoscitore, e non penso ci sia necessità di retorica... ritengo che sia proseguita con contributo che fa emergere delle competenze aderenti all'ambito

cercando in giro ci sono ricerche in merito all'uso che le tv fanno della connessione internet.

di solito i dispositivi iot sono piene di backdoor da banali connessioni di test a bootloader standard che permettono l'upload di firmware non firmato come il classico uboot fino a pagine web che danno accesso a cli con privilegi di root.
il perchè? per velocizzare il processo di sviluppo di sw alla Mickey Rourke in ironman 2.



di solito non si usano linguaggi ad alto livello su sistemi mcu e di solito non ci si usa java la scelta di usare un linguaggio del genere significa che hanno usato personale non qualificato probabilmente riclicato da altri ambiti (tipo il bancario dove java era molto utilizzato e che sta andando in phase out) in quanto qualsiasi firmware developer conosce linguaggi di basso livello e di solito si specializza su un architettura di mcu.

tutto il resto dei presunti vantaggi di java e netbeans che hai scritto significa che non conosci nulla dell'ambiente di sviluppo a mcu? perchè pensi che per sviluppare su micro bisogna utilizzare mille tool esoterici che rallentano il lavoro ? ora è tutto impostato se usi un ide serio si fa tutto con quello dalla scrittura del codice al debug al deploy alla gestione delle diverse toolchain di svilupppo fino alla gestione dell'ota
poi parlare di oracle e supporto significa che non hai mai provato ad usare oracle senza avere dietro una società da billion con un supporto paid da nmila euri all'anno. mentre su mcu anche se sei piccolo il reseller fa da tramite con i field engineer anche per pochi pezzi annui.


tornando a bomba che tool utilizzare per creare uno spazzolino smart? ci sono diverse opzioni

opzione barbone style con un minimo di esperienza in mcu che è probabilmente quella utilizzata,

prendo un hw ultra scrauso che costa pochi centesimi e che ha uno sputo di capacità di calcolo ma con wifi e bt (esp32) che è probabilmente la scelta che farei io nel progettare una scheda per un sistema che costa pochi euro all inclusive

a questo punto o uso la toolchain del produttore (che è una cli ) e il codice me lo scrivo bare to metal utilizzando qualsiasi editor che mi piaccia anche notepad++


opzione barone style senza il minimo di esperienza in mcu installo vscode che ha un plugin apposta per la gestione di queste mcu scrause (platform.io) scrivo il codice partendo da esempi dal forum di arduino e tiro su un codice del genere in meno di un giorno anche con esperienza minima (ci sono librerie che fanno tutto dalle api rest alla comunicazione ble con letteralmente 10 righe di codice

opzione sono uno sviluppatore fw serio: uso un tool professionale in grado di creare codice ottimizzato e programmo mediante jtag il micro ottenendo di piallare il bootloader (libero memoria ) sfruttando al massimo tutto l'hw disponibile cosa che è inutile su un applicazione del genere


tutte le opzioni ti danno la possibilità di fare debug e deploy in letteralmente 1 click e qualche secondo (decina di secondi utilizzando le prime due opzioni con il bootloader pochi secondi la terza)

riguardo al fatto che secondo te lo sviluppo in java è facilitato
giusto per farti capire lo sforzo di implementazione: la cosa più complicata in un sistema del genere è sicuramente l'invio dei dati verso una piattaforma cloud preferibilmente sicura.

ora effettuare una http post verso un server remoto aws gestendo pure la sicurezza mediante https e api key con un sistema del genere si fa con queste righe di codice (a meno della gestione errori)
[CODE]
const char *server = "https://[server address]"; // Server URL
void SendInformationToHttps(String sTemp)
{
HTTPClient http;
http.begin(server))
http.addHeader("x-api-key", "[api key]";
http.addHeader("Content-Type", "application/json";
http.addHeader("Host", "[host]";
String payload = "[json string]";
int httpCode = http.POST(payload);
http.end();
}
[/CODE]
come vedi è praticamente identico che usare un linguaggio ad alto livello

tl:dr my 2 cents

Eh vabbe' guarda. Che ti devo dire. Hai ragione tu e quelli che hanno sviluppato lo spazzolino sono sicuramente dei c*glioni che si sabotano da soli e hanno scelto Java per farsi male.

Per me la discussione finisce qua. Mi sembra che si facciano troppe assunzioni su un oggetto di cui non si sa praticamente niente.

Oh. Poi se qualcuno mi posta qui tutte le caratteristiche del progetto riguardante questo spazzolino (o spazzolini? Anche questo non mi e' al 100% chiaro) e mi dimostra da queste che Java sia stata una scelta scema sono disposto a dargli ragione (again, non mi frega difendere Java). Mi da fastidio pero' che si critichi il lavoro altrui senza cognizione di causa.

oltre 15 anni di esperienza nella progettazione di device e nello sviluppo di firmware bastano come cognizione di causa?