Un gruppo di ricercatori di due università diverse, hanno testato le loro abilità di hacking su due automobili.
Essi potevano, in remoto, bloccare i freni, il motore, azionare i finestrini, accendere la radio, il condizionatore ed i tergicristalli, suonare il clacson ed inserirsi nel display del tachimetro con messaggi o quant'altro.
Sono stati in grado di fare tutto questo su due macchine diverse (senza fare il nome della marca e del modello) collegando un computer portatile al sistema di controllo elettronico e controllando il computer in modalità wireless utilizzando un secondo PC in una macchina separata.
E' bastato semplicemente intercettare il CAN-BUS
Avevamo già parlato, in passato, della sicurezza dei protocolli wireless nel settore automotive Hacking RKE ma ora la cosa si è sviluppata, intercettando il can-bus è possibile fare praticamente DI-TUTTO!!
Speriamo solo che i costruttori siano al passo con i tempi... dei ladri. Ma per quanto riguarda le vecchie auto? e per vecchie intendo solo di 2 o 3 anni.
Nel prossimo futuro, dovremmo essere più preoccupati per un attacco hacker alla nostra auto, piuttosto che al nostro PC.
PDF |freehacking.net|
Ho letto questa pubblicazione qualche mese fa, e non so ancora decidere se questa è una cosa fighissima o se dovrebbe farmi paura…
Io l’ho seguita dall’inizio… parliamo del 2007 ma a quanto pare è un argomento ancora attuale!
La pubblicazione dei documenti creò una certa agitazione negli ambienti 🙂
addirittura ci fu una risposta ufficiale da Microchip Technology (infatti il rolling code in questione era appunto il Keeloq)
Ecco la risposta ufficiale Microchip
Il problema fu che poi in rete iniziarono ad apparire decine di siti con spiegazioni più o meno plausibili sulla poca affidabilità del rolling code….
Comunque io penso che nel momento in cui gli hacker arrivano al risultato, questo significa che ci arrivano anche i malintenzionati, se già non ci sono arrivati prima.
Se non ci fossero loro (gli Hacker) probabilmente le aziende dormirebbero sonni tranquilli, troppo tranquilli, a discapito della sicurezza del consumatore!
Se vuoi approfondire, ecco dove tutto ebbe inizio:
http://digg.com/news/technology/Keeloq_cracked
si, in microchip si sono messi paura ahahah
c’e stato un periodo sembrava tutto il mercato automotive dovesse saltare
Il Keeloq credo sia uno dei Rolling code più diffusi, soprattuto nel settore automotive…
Non è proprio così semplice, la linea can è formata da 2 cavi per l’invio di segnali digitali tramite specifici protocolli,è come se l’auto fosse un computer,solo che nel computer la connessione tra scheda audio e scheda madre è in slot mentre sull’auto visto le specifiche distanze avviene tramite questa linea,le velocità sono diverse si và dai 125kbs per la gestione confort al massimo di 500kbs per la gestione centralina,abs,cambio e freni..la differenza tra le altre linee è che le reti Can utilizzano strutture Multi-master ovvero ogni ceppo di controllo è indipendente ma allo stesso tempo in funzione della centralina e altri sensori,al contrario delle reti LIN che adoperano strutture master,esempio: centralina master e le altre logiche slave.il vantaggio delle linee Can è che essendo tutte logiche master è impossibile intercettare un solo ceppo di cavi e controllare tutto e in caso di guasto a una parte logica della centralina non vengono bloccate le altre logiche in slave,quindi non credo molto a questo articolo con tutto il rispetto per il sito.Si può fare di tutto collegandosi direttamente alla centralina tramite un cavo Eobd-2-1 ma controllare completamente un veicolo tramite 2 cavi e in wireless e far in modo che i comandi(molti sono meccanici) del guidatore vengano ignorati dal veicolo è chiedere troppo…magari dipenderà anche dal tipo di veicolo in quanto per risparmiare non tutti i costruttori adottano le solite tecnologie..ma vi assicuro che comandare remotamente un veicolo tramite un protocollo è inverosimile
Ecco i documenti in pdf, presentazione e documento tecnico del “lavoro” fatto da uqesti 2 ragazzi per decriptare il rolling code. Lo hanno presentato anche in varie conferenze…
http://www.cosic.esat.kuleuven.be/keeloq/
L’ho letto,non metto in dubbio che mandare in tilt un microprocessore sia facile.però come ripeto non è che i cablaggi della centralina a sensori e altri componenti di gestione avviene solo tramite le linee Can e Full Can.Parliamo sempre di un codice binario con segnali digitali..la macchina ha delle logiche particolari,non lavora solo in funzione di questo tipo di protocollo ma adopera i veri e propri cabalggi.Io sono dell’idea che le probabilità di questo attacco alle auto sia possibiile al 5% come descritto da loro,al 50% se si usano altri metodi più realistici..poi nel sito parla di auto che non investono sulla sicurezza..ricordo che la linea CAN è stata progettata dalla Bosch già la Fiat adopera magneti marelli le altre non saprei..infatti la bmw non la vedo menzionata.
Da una rapida lettura della presentazione sembra che i ragazzi abbiano pensato più all’immagine che alla sostanza, non è percaso che siccome il 99% dell’uditorio non è in grado di comprendere a fondo la parte matematica abbiano sfoggiato una decorata ed abbellita enorme bolla d’acqua calda???
chi ha verificato quanto illustrato risalendo alla mfk?
Emanuele, tu che hai il prototipo, perchè non ci provi?
http://it.emcelettronica.com/decodifica-codici-telecomandi-radiocomandi-rolling-code-microchip-keeloq-motorola-e-national
ma quello che hai copiato il link è quello per le codifiche delle radiofrequenze dei telecomandi apri e chiudi macchina,ma la apri e basta perchè di + non fai…inoltre il blocchetto della chiave ha un sistema a trasponder tipo RFID se nel suo raggio di azione non c’è il tag passivo(immerso nel copro della chiave) la centralina blocca tutto….questo articolo dice che con un sistema wirelless si può completamente pilotare un veicolo..pensa che c’è chi fà i prototipi di veicoli che vanno da soli e questi con una linea di 2 cavi hanno fatto la solita cosa!!!ahahah mi vien da sorridere.Io studio elettronica,specializzazione elettrauto.;)
Si ma il passo determinante a mio avviso è il “keeloq revelated” ed il prototipo nel link parla proprio di questo, solo che necessità la manufacture key (leggi i commenti), appunto dicevo.
Per pilotare un auto “con una linea di 2 cavi” , come sai, quella linea è il physical layer del canbus, protocollo che, se hackerato permette di controllare la centralina e, se nella centralina è prevista la gestione della guida (questo non lo sò), allora è fattibile. Comunque entrare nel can-bus non è poi così difficile, il protocollo che ho visto io (non mi ricordo però che versione) era abbastanza semplice.
ma la linea can come detto prima è un protocollo!! il suo compito è quello di dare un occhio vigile e veloce alla centralina e in caso di guasto isolare solo quel ceppo,ritornando alla pratica se io mi collego a una linea can e inizio a inviare pacchetti tramite codice binario destinati alla centralina per prima cosa si rischia di mandare in tilt il sistema,in quanto essendo multi master quel pacchetto potrebbe arrivare a ceppi non destinati..seconda cosa se la centralina non manda segnali l’invio di pacchetti viene considerato come un disturbo perciò cerca di azzerarlo..poi la centralina non vive in funzione della linea can ci sono componenti di maggiore priorità,come un sensore motore o un movimento elettromeccanico eseguito dal guidatore..se invece entravano tramite cavo eobd allora li hai le porte aperte,in quanto sei direttamente collegato con la centralina e il computer è come se fosse un programmatore..e anche così non hai le porte spalancate come quà dice..per esempio cambiare il messaggio di testo del display bisognerebbe aprire il cruscotto,prendere il chip e riprogrammarlo con i valori logici e assegnare il messaggio destinato a un determinato ordine d’ingresso..l’abs e esp sono deboli come logiche proprio perchè devono sempre essere campionati i dati di ricezione con pocco è possibile mandarli in tilt.
Non ricordo bene i dettagli della cosa, ma se non sbaglio in qualche modo si era riusciti ad avere accesso ai registri di memoria della CPU “principale”. Se stiamo trattando una topologia a stella, e si riesce a controllare il centro della rete, probabilmente si riesce ad avere accesso più o meno a tutte le periferiche che accettano comandi.
Scusate se mi permetto, ma vorrei chiarire alcuni punti, non è per insegnare nulla a nessuno ma mi sembra si stia facendo un po’ di confusione. Chiedo perdono se non ho letto l’articolo originale, per cui non entrerò in quel merito , vorrei solo chiarire alcuni aspetti generali che possono indurre in confusione i meno introdotti sull’argomento. Il CAN, ovvero il CAN-BUS è una rete di trasmissione dati multipunto su due linee elettriche (il BUS appunto), come accade di solito in questi casi sia il mezzo fisico che la parte di “basso livello” del protocollo di trasmissione, come lunghezza dei frame, indirizzamento ecc, sono definiti da apposita norma, per garantire funzionamenti standard. La rete è a bus, ergo due fili, poi questa si può estendere e articolare con gateway di ridirezione dei messaggi su sottoreti, ma tutti i nodi sono collegati da due fili in parallelo ai “morsetti” del tranceiver anche il nodo dell’eventuale gateway, questo distingue l’indirizzamento fisico, gestito dal controller hardware, da quello logico implementato dal protocollo che gestisce la rete e i suoi servizi. Quindi se sulla presa oebd ho i due estremi CANH e CANL io mi collego e sono in rete, posso inviare messaggi ma questi avranno senso solo se il mio indirizzo logico è previsto dal protocollo della rete del motore. Se mando messaggi a caso posso fare dei danni, come portare in blocco il sistema, ma per assumerne il controllo devo conoscere e inserirmi nel protocollo di rete. Su una rete can è possibile utilizzare qualunque protocollo adatto, proprietario o meno, io stesso per lavoro ho utilizzato protocolli inventati dal cliente e altri standard, come il SAE J1939, di origine statunitense. Quest’ultimo nato per definire le reti su veicoli a motore definisce ogni nodo come elemento della rete del veicolo dal motore (il master logico) al FAP, al cambio, al controllo della coppia ecc. Ogni dispositivo è quindi mappato e ha proprietà differenti sugli altri elementi ma il vero master rimane la centralina, ovvero il nodo, del motore, il quale può assegnarmi un indirizzo o accettare il mio se non sono in grado di cambiarlo, altrimenti vengo escluso, in ogni caso per far questo devo possedere un codice di identificazione del produttore che mi identifica come produttore di controller elettronici SAE J1939, questo se il protocollo è implementato in maniera stretta, se clono il codice il rischio di conflitto e quindi esclusione dalla rete è alto. Alcuni costruttori si “basano” sui protocolli standard ma poi li differenziano personalizzandoli, questo li rende di fatto “open” perchè il sistema dell’assegnamento degli indirizzi salta, ma toglie anche il controllo sugli accessori che possono essere compatibili ma non certificati, dal punto di vista degli sniffer rende le cose difficili perché di solito il protocollo non standard contiene modifiche sui pacchetti dati conosciuti solo al produttore del veicolo e questo rende difficile interpretare i comandi. Concludo, sperando di essere stato chiaro ma consapevole di non aver per niente esaurito l’argomento, facendo osservare che i produttori di autovetture utilizzano diversi tipi di reti e protocolli di trasmissione dati tra le ECU del veicolo, LIN è un esempio, seriale su un filo usata per accessori ma non nel controllo del motore. J1850, GM ecc, mentre la rete can spesso è utilizzata come rete servizi, per diagnostica e manutenzione, mentre il controllo motore e accessori come gli antifurti, è oramai affidato al protocollo FlexRay di lunga più robusto del CAN-BUS, ognuno dei protocolli citati richiede un hardware di interfaccia specifico, e anche se esistono analizzatori can professionali che implementano tutti questi protocolli in un unico software a PC, siamo ben lontani da una seriale e una scheda ARDUINO o PIC amatoriale
volendo ci si può stare 1 mese a parlarne,comunque sono d’accordo con te voglio solo precisare 2 punti.
-tu già parli di eobd,mentre nell’articolo dicono di riuscirci in wireless..
-la linea Can e full Can sono tutti protocolli in multi master è stato progettato appositamente,in caso di guasto di un ceppo non si compromette tutta la linea.
-la linea Can è disattiva e inaccessibile(a 0 logico) fin quando non arriva l’ok dalla centralina allarme,cioè fin quando non si apre la macchina.
-la centralina è un sistema intelligente,quando si cambia un pezzo anche se non è identico parte la funzione di campionamento della centralina e lo ingloba nel suo sistema,purtroppo questo non vale per gli iniettori che devono essere identici.
per il resto sono d’accordo con te 😉
Ciao Chadreed,
con un microcontroller (con can a bordo) e relativi driver di potenza esterni, puoi interfacciarti con il tuo apparato (webasto) a livello hardware.
Poi, ovviamente, serve il protocollo, e quindi quali comandi inviare per inserirsi nella rete e attivare e/o inibire il dispositivo.
Forse sarebbe opportuna una interfaccia CAN-RS232 (o USB) da collegare al PC.