Hallo Forum, dies ist mein erster Beitrag. Ich habe schon reichlich zu dem Thema recherchiert aber ich stoße immer nur auf Herausforderungen statt Lösungen. Kurz und knapp zu meinem Projekt: Ich habe zahlreiche Videos bei Youtube gesehen wie Autos gehackt werden und per Remote alle Befehle auf dem CAN Bus durchgeführt werden können. Jetzt möchte ich dies ebenfalls durchführen und prüfen ob es wirklich machbar ist. Schritt 1: Ich möchte eine Linux Maschine an den CAN Bus bringen und zunächst Sniffen welche Pakete darüber gehen. Welche Pakete kann ich über die OBDII Schnittstelle abgreifen? Ist das schon die Verbindung zum direkten CAN-Bus oder muss ich zunächst noch an einem Gateway vorbei? Welcher Adapter ist günstig und funktioniert für Linux? Schritt 2: Wenn ich es schaffe Pakete zu sniffen, möchte ich diese auch spezifizieren und kategorisieren können. Hier will ich die Kommunikation nachvollziehen und Schritt 3 einleiten. Gibt es hierzu Erfahrungen und ggf. Tools, die mir dabei helfen könnte? Nach einigen Standards und Spezifikationen sollten zumindest Header idendifizierbar sein. Somit auch einzelne Idendifier und Pakete. Schritt 3: Aus Schritt 2 sollen hier nun manipulierte Pakete gesendet werden, um das System auf Angreifbarkeit zu testen. Schritt 4: Überführung der gemachten Erfahrungen in ein Embedded System (hier Beaglebone Black), um dies auch per Remote zu versuchen. Ich möchte hier darauf hinweisen, dass dies keinen illegalen Zwecken, sondern rein der Forschung dient. Hat hier jemand solche Systeme schonmal aufgesetzt? Die anderen Threads zu dem Thema beschrieben Teilpropbleme aber keine Gesamtlösung. Schritt 1 schätze ich weniger problematisch als alle folgenden ein. Vielen Dank schonmal. Gruß Stanislav
Stanislav L. schrieb: > Ist das schon die Verbindung zum direkten CAN-Bus Zu welchem der CAN Busse? Da gibt es je nach Fahrzeug mehrere davon... Du wirst zum Manipulieren den Bus auftrennen und den gewünschten Teilnehmer mit gefakten Nachrichten versorgen müssen..
:
Bearbeitet durch Moderator
Ich arbeite in der Automobil Branche (CAN-bus) und kann dir nur ganz ganz dringend empfehlen das sein zu lassen. Gründe: Die Sicherheit andere Straßenteilnehmer Totalschaden am Auto (ECU irreparabel defekt) Deine Sicherheit Und so weiter.... Im Ernst, lass es sein. Spiel an anderen can Bussen rum aber nicht an dem in einem zugelassenen Fahrzeug
Am OBD-Interface kommen verschiedene CAN-Bussysteme zusammen. In der Regel gibt es min. einen Lobspeed-Bus mit einer Baudrate zwischen 33.33kBaud bis 125kBaud und einen Highspeed-Bus zwischen 125kBaud und 1MBaud. Gängig sind oft 500kBaud. Auf dem Highspeed-Bus liegen sicherheitsrelevante Signale, unter anderem vom Motorsteuergerät oder dem EBCM. Auf dem Lobspeed werden eher Komfort-Funktionen übertragen. Um CAN-Botschaften zu simulieren, musst du natürlich den Netzknoten eines Steuergerätes unterbrechen, damit Botschaften nicht doppelt auf dem Bus liegen. An die Bedeutung der Can-Ids und der Datenfelder kommst du ohne weiteres nicht ran. Es gibt hierfür spezielle Datenbanken wie bsp. das Vector DBC, für das zum Interpretieren eine spezielle Software benötigt wird. Was du allerdings machen kannst, ist zu gucken, ob eine Nachricht auf dem Bus zu sehen ist, wenn du beispielsweise einen Knopf oder Schalter betätigst. Dies gilt nur für spontane Messages. Zyklische Nachrichten liegen immer mit einer speziellen Zykluszeit auf dem Fahrzeugbus. Ich habe in einem privaten Projekt eine Radiosteuerung per Smartphone entwickelt. Ich habe dazu einen kleinen OBD-Dongle mit STM32F4-Mikrocontroller und einem BLE112-Bluetooth-Modul ausgestattet. Das Bluetooth-Modul baut zum Smartphone (mit spezieller App) über BLE eine Verbindung auf. Mit einem Button in der Smartphone-GUI kann ich dem STM einen Befehl zum Senden der CAN-Botschaft "Steering-Wheel-Control" schicken, mit der ich die Betätigung der Lautstärke-Taste auf den Lenkrad simuliere. Dies ist ein gutes Beispiel zur Analyse, da die Botschaft nur erscheint, wenn ein Button betätigt wird. Als Hardware empfehle ich dir auf ruhig auf einen Mikrocontroller umzusteigen (benötigt wird außerdem noch ein CAN-Transceiver). Die Spannungsversorgung kannst du ebenfalls vom OBD abgreifen (12V). Zum Thema Sicherheit würde ich sagen, dass es nicht kritisch ist, solange du deine zusätzliche Hardware wieder entfernst nach deiner Forschung und das Ganze nicht im Strassenverkehr einsetzt.
Moderne ECUs sind durch Seed-Key Verfahren (bei der Diagnose oder dem reprogrammieren) geschützt. Schickst du ihm ein paar mal (zufällig oder gewollt) den falschen Key ist es dauerhaft gelockt.
Danke für eure raschen Antworten. Nik schrieb: > Ich arbeite in der Automobil Branche (CAN-bus) und kann dir nur ganz > ganz dringend empfehlen das sein zu lassen. > Gründe: > Die Sicherheit andere Straßenteilnehmer > Totalschaden am Auto (ECU irreparabel defekt) > Deine Sicherheit > > Und so weiter.... Im Ernst, lass es sein. > Spiel an anderen can Bussen rum aber nicht an dem in einem zugelassenen > Fahrzeug Ich kann deine bedenken verstehen und sehe das absolut genauso. Ich werde keinesfalls Pakete auf den CAN Bus eines benutzten Fahrzeuges jagen - um Himmelswillen! Geplant ist erstmal Schritt 1 und 2 passiv durchzuführen. Schritte 3 und 4 würden, wenn überhaupt, mit einem Testfahrzeug durchgeführt werden. Ich arbeite im Security und Safety-Bereich und würde niemals solch ein Risiko eingehen. Ich danke für den Beitrag und hoffe somit, dass andere User sensibel bleiben. Dennoch sehe ich es als absolut notwendig sicherheitskritische Systeme auf Angreifbarkeit zu testen. Hier möchte ich meine Expertise aufbessern. jd schrieb: > Ich habe in einem privaten Projekt eine Radiosteuerung per Smartphone > entwickelt. Danke für deinen Beitrag. Ich finde dieses Projekt sehr spannend. Können wir uns darüber per PN austauschen, um den Thread nicht zu sprengen? jd schrieb: > Als Hardware empfehle ich dir auf ruhig auf einen Mikrocontroller > umzusteigen (benötigt wird außerdem noch ein CAN-Transceiver). Hier habe ich an einen Beaglebone Black mit CAN Cape gedacht. Außerdem soll der Beaglebone Black von Haus aus 2 CAN Anschlüsse haben. Hast du damit schon Erfahrungen gemacht? Gedacht hatte ich an sowas: https://de.wikipedia.org/wiki/Can4linux - In Kombination mit einem BeagleBoneBlack oder http://elinux.org/Beagleboard:TT3201_CAN_Cape - Ebenfalls mit einem BBB. Ich habe auch gelesen, dass ein Tranceiver von TexasInstruments funktionieren soll. Ist damit sowas gemeint = http://de.farnell.com/texas-instruments/sn65hvd231d/can-transceiver-sleep-65hvd231/dp/1106059 ?
Nik schrieb: > Ich arbeite in der Automobil Branche (CAN-bus) und kann dir nur ganz > ganz dringend empfehlen das sein zu lassen. > Gründe: > Die Sicherheit andere Straßenteilnehmer > Totalschaden am Auto (ECU irreparabel defekt) So ein Blödsinn habe ich schon lange nicht mehr gehört. Du wirst je nach CAN Bus 5-10 sich immer wiederholende Nachrichten erkennen. Die Pakete sind relativ groß und zumeist kannst du nur Alive-Counter der verschiedenen Steuergeräte erkennen. Einfache Bedienungen wie Tastendruck, etc. kann man sehen, aber bei komplexeren Messwerten sind die Daten schwer zu sehen. Es gibt für manche Fahrzeuge Nachrichtenkataloge die kursieren, aber da ist schwer ran zu kommen.
Nik schrieb: > Moderne ECUs sind durch Seed-Key Verfahren (bei der Diagnose oder > dem > reprogrammieren) geschützt. Schickst du ihm ein paar mal (zufällig oder > gewollt) den falschen Key ist es dauerhaft gelockt. "Diagnose oder dem reprogrammieren" Korrigiere mich wenn ich falsch liege, aber ich dachte immer, dass das Programmieren über Diagnose erfolgt. Einen Schaden zufällig per Diagnose anzurichten, halte ich für sehr unwahrscheinlich, da man ja eine ganz bestimmte Botschaft und Id versenden müsste (Eine die regulär nicht auf dem Bus liegt). Gleichzeitig muss ein Tester-Present periodisch gesendet werden, damit das Steuergerät im Diagnose-Modus bleibt.
:) Macht was ihr wollt. Aber sobald du dich an den CAN ran hängst greifst du in das Netzwerk ein. Der Transceiver schickt ein ACK, verhindert eventuell im NM das Standby der ECUs, und die Terminierung des Busses wird verändert. Dein Verhalten finde ich leichtsinnig aber bitte. Und ja, du siehst Nachrichten am OBD (Diagnose CAN) da es hier einheitliche Standards gibt (UDS oder ähnliches).
Nik schrieb: > Moderne ECUs sind durch Seed-Key Verfahren (bei der Diagnose oder dem > reprogrammieren) geschützt. Schickst du ihm ein paar mal (zufällig oder > gewollt) den falschen Key ist es dauerhaft gelockt. Gelockt ja, aber nicht dauerhaft und vor allem nicht irreparabel defekt. > Und ja, du siehst Nachrichten am OBD (Diagnose CAN) da es hier > einheitliche Standards gibt (UDS oder ähnliches). OBD sieht nur bestimmte Nachrichten.
Marc V. schrieb: > OBD sieht nur bestimmte Nachrichten. kannst du spezifizieren was man sieht und warum man es sieht? ich frage mich warum du sagst, dass nur "bestimmte" Nachrichten zu sehen sind.
Stanislav L. schrieb: > Marc V. schrieb: >> OBD sieht nur bestimmte Nachrichten. > > kannst du spezifizieren was man sieht und warum man es sieht? ich frage > mich warum du sagst, dass nur "bestimmte" Nachrichten zu sehen sind. Ich versuchs mal: OBD ist ein Synonym für den genormten Diagnose-Zugang zum Fahrzeug. In der Norm ist sowohl beschrieben wie der Stecker physikalisch (Form, Belegung) auszusehen hat, als auch welche Daten über den Zugang ereichbar sein müssen. Das Betrifft größtenteils alle Abgasrelevanten Fahrzeugdaten. Entstanden ist die Norm um einen einheitlichen Zugang zu allen Fahrzeugen zu schaffen (Sprich nur ein "Diagnose Gerät" in den Werkstätten). Der Zugang kann über CAN oder aber K-Line erfolgen (Neuerdings auch Ethernet - DoIp). Der am OBD angeschlossenen Bus ist meistens auf das ZG (Zentrale Gateway) im Fahrzeug geführt. Dort wird, anhand von Routing-Tabellen, entschieden welche Diagnosenachrichten von den anderen Subbussystemen auf den Diagnosezugang geroutet werden. Die Daten auf dem Bus sind heutzutage meistens im UDS-Standard kodiert. Grüße
:
Bearbeitet durch User
Stanislav L. schrieb: > kannst du spezifizieren was man sieht und warum man es sieht? ich frage > mich warum du sagst, dass nur "bestimmte" Nachrichten zu sehen sind. Schon lange her, dass ich mit OBD2 experimentiert habe, heute ist es bestimmt anders. Ausserdem habe ich die Hälfte davon vergessen, so dass auf meine Informationen kein Verlass ist... Auf jeden Fall gibt es mehrere Busse, OBD2 ist auch nur durch einen Gateway verbunden, was da durchkommt oder nicht, weiss ich nicht genau, aber es kommt bestimmt nicht alles durch. Auf der anderen Seite ist es den Herstellern sicher kein Problem, ein Gateway versteckt einzubauen, der über irgendeine Adresse und Passwort angessprochen werden kann und dann absolute Kontrolle über dein Fahrzeug übernimmt. VW ist mit Abgasen nur aufgeflogen weil da jemand während der Fahrt die Werte nachgemessen hat. Mal ehrlich, wer von uns weiss überhaupt, wie z.B. der Entertainment Bus genau angeschlossen ist und was da alles möglich und machbar ist ? Was mich aber heutzutage wirklich erschreckt, ist das automatische Einparken. Wenn das auf Knopfdruck geht, ist es auch möglich jedes Auto fernzusteuern. Ein Frontalzusammenstoss über WiFi und Bluetooth ? Ich glaube, ich suche mir wieder ein Auto vor Baujahr 2006.
:
Bearbeitet durch User
Nik schrieb: > :) > Macht was ihr wollt. Aber sobald du dich an den CAN ran hängst greifst > du in das Netzwerk ein. Der Transceiver schickt ein ACK, verhindert > eventuell im NM das Standby der ECUs, und die Terminierung des Busses > wird verändert. Käse. Bus-Sniffen am CAN geht völlig non-intrusiv. Und so leicht schiesst man sich die ECU nicht ab. Und wenn schon: Solange die Automotive-Industrie noch mit JTAG arbeitet (und das wird sie noch eine Weile), sind die Geräte immer recht leicht wieder neu zu programmieren und nicht nur das. > Dein Verhalten finde ich leichtsinnig aber bitte. Leichtsinnig finde ich, was uns die Automotive-Industrie teils heute andreht. Sowas sollte eigentlich keine Zertifizierung mehr überstehen. Und es ist das gute Recht eines jeden Anwenders, zu sehen, was sein Besitz unter der Haube so alles macht, auch gegen jeden Bestrebung der Hersteller, die Funktion zu verschleiern. Allerdings würde ich auch keine moderne Karre mehr kaufen. Das hat auch den Grund, dass ich nicht für einen Haufen überflüssiges Elektronikspielzeug, was zudem noch eine Menge obskurer Daten loggt und oft schon nach 10 Jahren aussteigt, bezahlen will.
Die ECUs im Fahrzeug werden per CAN-Bootloader (oder teilweise Ethernet) programmiert. Du findest in (fast) keiner ECU einen JTAG Zugang.
hackfin schrieb: > Allerdings würde ich auch keine moderne Karre mehr kaufen. Richtig, die telefonieren viel zu viel. Habe gerade einen youngtimer eingelagert.
Marc V. schrieb: > Was mich aber heutzutage wirklich erschreckt, ist das automatische > Einparken. Wenn das auf Knopfdruck geht, ist es auch möglich jedes > Auto fernzusteuern. Vor- und Rückwärts Fahren musst Du noch selber, die Automatik lenkt nur.
Chris F. schrieb: > Marc V. schrieb: >> Was mich aber heutzutage wirklich erschreckt, ist das automatische >> Einparken. Wenn das auf Knopfdruck geht, ist es auch möglich jedes >> Auto fernzusteuern. > Vor- und Rückwärts Fahren musst Du noch selber, die Automatik lenkt nur. ABS ist in jedem Auto drin, Zentralverriegelung, Tiptronic, GPS, jetzt auch die Lenkung, was glaubst du wie schwer es für entsprechend programmierte ECU ist, Kontrolle über dein Auto zu übernehmen und dich an jeden beliebigen Ort zu fahren?
:
Bearbeitet durch User
Nik schrieb: > Die ECUs im Fahrzeug werden per CAN-Bootloader (oder teilweise Ethernet) > programmiert. Du findest in (fast) keiner ECU einen JTAG Zugang. Nun, ich finde einen. Es gibt Leute, die trauen sich sogar, Gehäuse zu öffnen. Allerdings gebe ich zu, habe ich einen gewissen Heimvorteil und weiss, wo ich bei H.B./VDO Geräten kratzen muss. Und wer jetzt mit Gschmarri a la Lockbox ankommt: Leider wirkungslos. Nur Freescale kriegt das einigermassen gut hin.
Nik schrieb: > Ich arbeite in der Automobil Branche (CAN-bus) und kann dir nur ganz > ganz dringend empfehlen das sein zu lassen. > Gründe: > Die Sicherheit andere Straßenteilnehmer > Totalschaden am Auto (ECU irreparabel defekt) > Deine Sicherheit Found the German! Im Ernst: Jemand, der in der "Automobil Branche (CAN-bus)" tätig ist, sollte eigentlich wissen, dass CAN zunächst per se ohnehin nicht deterministisch ist, sprich auf Grund des Sicherheitskonzepts darf durch eine CAN-Busstörung schon gar keine Gefährdung ausgehen (wohlgemerkt spreche ich nicht von höherlagigen Protokollen). Für solche Anwendungsfälle gibt es andere Bussysteme, die auch eingesetzt werden, hier aber nicht Thema sind. Nik schrieb: > Macht was ihr wollt. Aber sobald du dich an den CAN ran hängst greifst > du in das Netzwerk ein. Der Transceiver schickt ein ACK, verhindert > eventuell im NM das Standby der ECUs, und die Terminierung des Busses > wird verändert. Nope. OBD geht ja nicht nur zwecks Zusammenfassung der Busse über ein Gateway, sondern auch zum Zwecke der elektrischen Trennung der Busse. Wenn der TO am OBD rumspielt, beeinflusst das die elektrischen Eigenschaften der eigentlichen CAN-Busse nicht. Abgesehen davon, dass man CAN-Busse auch 100% passiv mitlesen kann (d. h. ohne ACK durch den Sniffer), ist das am OBD wiederum relativ wumpe, da kein Eingriff in die eigentliche CAN-Kommunikation des Fahrzeugs erfolgt. Nik schrieb: > Die ECUs im Fahrzeug werden per CAN-Bootloader (oder teilweise Ethernet) > programmiert. You don't say! Dummerweise muss der Bootloader zuvor aber auch irgendwie auf die ECU - ich kenne keinen µC/DSP, der schon ab µC-Hersteller einen CAN-Bootloader drauf hat, welcher UDS spricht und die OEM-spezifischen Diagnose-Anforderungen (OEM-spezifische Werksnormen etc.) erfüllt (dann müsste es nämlich auch sinnvollerweise pro OEM eine eigene µC-Variante geben, da sich die einzelnen Normen doch u. U. extrem stark unterscheiden und der Software-Overhead und somit der zusätzlich für den benötigte Flash im µC in keinem Verhältnis steht). Alternativ ist bei entsprechenden Stückzahlen natürlich das Szenario denkbar, dass der µC vorprogrammiert bei Leiterplattenbestücker angeliefert wird, aber meiner Erfahrung nach ist immer noch das gängigste Szenario das Programmieren der fertig bestückten ECU(-Platine) mit Bootloader und Applikation während des Endtests beim Leiterplattenmenschen (alternativ nur Bootloader beim Leiti, Applikation dann über CAN sonstwo, beispielsweise in Zimbabwe oder am Kap Hoorn). Daher ist i. d. R. immer noch ein Programmierzugang gegeben, wenn auch nur über Testpunkte. > Du findest in (fast) keiner ECU einen JTAG Zugang. JTAG ist in in Serie gefertigten ECUs typischerweise nicht mehr drauf, richtig - warum auch? Es sei denn natürlich, der Layouter war zu faul, das aus dem Serienlayout herauszuschmeißen - der Steckverbinder wird in jedem Fall eingespart.
Danke für die zahlreichen Beiträge! Aber Stopp! Als Eröffner des Threads möchte ich darauf hinweisen, dass dies hier keine Streiterei werden soll wie die Kommunikation der Netzwerke funktioniert, sondern, darauf will ich ausdrücklich hinweisen, wie ich praktisch die Daten Sniffen kann. Ich bitte mir bei Schritt 1 zu helfen und Lösungen vorzuschlagen, die erprobt worden sind. Theoretisch kann ich mir einfach irgendeinen CAN-USB Adapter für 20,00€ kaufen und hoffen, dass es funktioniert. Aber wie gesagt: Der Plan ist es die Datenpakete über Linux zu sniffen. Ich bitte nun folgend darum Lösungen und Vorschläge zu unterbreiten.
Stanislav L. schrieb: > Theoretisch kann ich mir einfach irgendeinen > CAN-USB Adapter für 20,00€ kaufen und hoffen, dass es funktioniert. Auch praktisch wirst du dir einen CAN-Adapter kaufen müssen. > Der Plan ist es die Datenpakete über Linux zu sniffen. Ich > bitte nun folgend darum Lösungen und Vorschläge zu unterbreiten. Sich erstmal mit CAN auseinandersetzen und anschliessend verstehen, dass es mehrere verschiedene Busse in einem Auto gibt. Diese laufen weder alle über CAN, noch sind bei allen die Geschwindigkeiten gleich. Also, muss das alles irgendwo zusammenkommen und auf einen nenner gebracht werden. Und das ist bestimmt nicht die OBD Buchse.
Stanislav L. schrieb: > Als Eröffner des Threads möchte ich darauf hinweisen, dass dies hier > keine Streiterei werden soll wie die Kommunikation der Netzwerke > funktioniert, sondern, darauf will ich ausdrücklich hinweisen, wie ich > praktisch die Daten Sniffen kann. Und wie willst du etwas "sniffen", wenn du nichtmal weißt, wie die Kommunikation funktioniert? Einen CAN-Bus mitzutracen ist nun wahrlich keine Raketenwissenschaft. Entweder du baust dir selbst ein Interface oder greifst auf was zurück, was bereits erfolgreich seit Jahren erfolgreich in der Entwicklung eingesetzt wird (Stichwort CANalyzer, CANoe...) Als kostenlose Alternative wäre der BUSMASTER zu nennen. Wohl gemerkt, alles für Windows, bei Linux, keine Ahnung was es da gibt. @ Toni Tester: Dem kann ich nur uneingeschränkt zustimmen. @TO: Einen CAN Bus zu "hacken" ist meiner Meinung nach ziemlich witzlos..zumindest so wie du es vor hast. Dein "Konzept" benötigt physikalischen Zugriff auf den Bus, sei es mit einem externen Dongle oder sonst wie. Und selbst dann, bekommst du über die OBD Buchse höchstwahrscheinlich KEINEN Zugriff auf den Powertrain-CAN, da der OBD-Anschluss über ein Gateway geroutet wird. Du könntest lediglich Diagnose-Kommandos weiter routen lassen und selbst da ist dann bei den "interessanten" Services (Stellgliedtest, Reprogrammierung, etc) Schluss, da über Seed&Key Verfahren abgesichert. Und wenn ich mich physikalisch auf einen Bus klemmen muss, um was zu manipulieren...dann kann ich auch gleich die Kneifzange nehmen und ein paar Bremsleitungen durch zwicken. Die eigentliche Gefahr besteht darin, dass jemand das Auto highjacken kann OHNE von außen physikalischen Zugriff auf den internen Bus zu haben. Das wiederrum geht nur, wenn du es schaffst, einen Busteilnehmer per GSM (oder sonst was) zu übernehmen, eine korrupte Firmware zu flashen und mit dieser dann Schabernack zu treiben. Am anfälligsten dafür sind momentan Infotainment-Einheiten, die diese sowohl GSM Anbindung haben, andererseits aber ich direkt an den "sensiblen" Bussen wie PT-CAN etc hängen. Das ist dann aber schon die "hohe Kunst" und nicht mit einem physikalischen Angriff auf den CAN zu vergleichen. Da könntest du einfach ein Interface dran hängen und eine DoS Attacke starten, indem du zyklische Messages mit der ID 0 schickst und damit den Bus komplett dicht machst.
Der BBB kann CAN im Kernel bereits. Du besuchst also noch nen Transceiver (Sn65 oder ähnliches) und kannst dann mit candump deine CAN RAW data sehen.
Hallo, abgesehen davon, dass ich Modifikationen am CAN auch ziemlich dumm finde (zuhören meinetwegen noch, ein CAN-Bus-Ausfall darf nicht sicherheitskritisch sein) und ich stark bezweifele, dass der TO in der Lage ist, sich "in das Fahrzeug zu hacken" - so schwirrt hier doch viel Halbwissen herum: Toni Tester schrieb: > Dummerweise muss der Bootloader zuvor aber auch irgendwie auf die ECU - > ich kenne keinen µC/DSP, der schon ab µC-Hersteller einen CAN-Bootloader > drauf hat, welcher UDS spricht und die OEM-spezifischen > Diagnose-Anforderungen (OEM-spezifische Werksnormen etc.) erfüllt Braucht er auch nicht. Dafür gibt es einen Secondary Boot Loader, der als erstes von dem ECU-Hersteller geflasht wird und dann die Kommunikation im Fahrzeug-Netzwerk ermöglicht. Der SBL wird dann in der Regel geschützt bzw. ist nicht frei verfügbar, ggf. wird zusätzlich JTAG abgeschaltet (wenn man überhaupt Zugang hätte - z.B. bei Steuergeräten mit Bare Dies auf Keramik). Andererseits ist die Fahr-Software ohne SBL nicht lauffähig. Einfach 'mal retten durch selber neu flashen ist damit in der Regel nicht möglich, da der SBL natürlich per Seed&Key abgesichert ist. Sollte also der Zugang wegen falschem Seed&Key permanent gesperrt werden (was mir bisher nicht unter gekommen ist), wäre das Steuergerät damit tot. Ach ja, als Randbemerkung: Wenn man weiß wie, kann man erheblichen Unsinn über CAN anstellen und durchaus auch Unfälle auslösen - das braucht man als Privatperson nicht noch einmal zu testen ;-). Security wird in Zukunft mindestens einen ebenso hohen Stellenwert einnehmen wie jetzt schon die Safety, wobei der CAN hier nur begrenzt unterstützt. Schöne Grüße, Martin
> > JTAG ist in in Serie gefertigten ECUs typischerweise nicht mehr drauf, > richtig - warum auch? Es sei denn natürlich, der Layouter war zu faul, > das aus dem Serienlayout herauszuschmeißen - der Steckverbinder wird in > jedem Fall eingespart. Die mir bekannten massenproduzierten Platinen haben die Testpunkte noch drauf, der Grund dafür sind die Funktionstests (Bscan). Das Zeug muss in der Taktstrasse alle möglichen Tests bestehen, bevor der Bootloader draufkommt. Jetzt aber zurück zum Thema: Zum CAN-Sniffen eignet sich z.B. ein ADI-BF537 oder gerade der für Automotive entwickelte BF539, der kann auch noch MOST. Zu letzerem muss man allerdings ein bisschen graben. Da es dafür einen uClinux-Port gibt, kann man sich mit Wireshark und passenden Plugins seinen CAN-Debugger selber bauen. Ist halt etwas Einsatz nötig, und die Teile in Europa zu kriegen ist etwas mühsam geworden. Gibt diesbezüglich möglicherweise elegantere Lösungen auf ARM-Basis. Bei verschlüsselter Com mit nonces oder den doch eher einfachen symmetrischen Verfahren muss man halt an die Keys rankommen, das ist aber durchaus bei den meisten Automotive-Produkten, die billig sein müssen, ohne Ionenstrahl-Hackereien möglich.
Ich hab mal so ein Bluetooth OBD Dongle an unseren Toyota angeschlossen und wollte per App einfach mal bisschen Fahrt aufnehmen. Nach drei Minuten gingen nach und nach alle erdenklichen Warnlampen an und die Servolenkung lies unter anderem nach. - Also irgendwie kann man über den OBD schon was anrichten. Ich vermute es war weil das Teil immerzu Diagnoserequests gesendet hat und den Bus leicht überlastet. Weiss da jemand mehr? Unabhängig davon: Ist es nicht ziemlich langweilig sowas zu probieren, was schon soviele andere gemacht haben? Wieso versuchst du sowas nichtmal am FlexRay in sehr modernen Autos? Und zu den verschiedenen CANs: Mit einem gewissen Request an das Gateway spiegelt es dir einen anderen CAN an den Diagnose CAN (OBD). Das zu hacken wird aber wohl auch 2 Jahre dauern, solange du von niemand Informationen bekommst. Ansonsten wie schon gesagt wurde: Am effektivsten ist es direkt die CAN Leitung abzugreifen welche du beeinflussen willst. Da sollte schon was möglich sein. Viele Grüße und viel Erfolg!
Nik schrieb: > Der BBB kann CAN im Kernel bereits. Du besuchst also noch nen > Transceiver (Sn65 oder ähnliches) und kannst dann mit candump deine CAN > RAW data sehen. Ich habe auch gelesen, dass mit dem BBB und dem Transceiver schon geloggt werden kann. Hast du damit Erfahrungen? Ich habe dazu Anleitungen gefunden, welche aber sehr alt sind und Treiber muss man sich selbst schreiben. Da sehe ich noch eine Herausforderung. Martin L. schrieb: > Wenn man weiß wie, kann man erheblichen > Unsinn über CAN anstellen und durchaus auch Unfälle auslösen Das ist genau das, woran ich forsche. hackfin schrieb: > Jetzt aber zurück zum Thema: Zum CAN-Sniffen eignet sich z.B. ein > ADI-BF537 oder gerade der für Automotive entwickelte BF539, der kann > auch noch MOST. Zu letzerem muss man allerdings ein bisschen graben. > Da es dafür einen uClinux-Port gibt, kann man sich mit Wireshark und > passenden Plugins seinen CAN-Debugger selber bauen. Danke für den Hinweis. Ich werde nach dem Wochenende da mal recherchieren und mich schlau machen. Bei verschlüsselter Com mit nonces oder den doch eher einfachen symmetrischen Verfahren muss man halt an die Keys rankommen, das ist aber durchaus bei den meisten Automotive-Produkten, die billig sein müssen, ohne Ionenstrahl-Hackereien möglich. Ich höre gerade zum ersten Mal, dass ein Verschlüsselungsverfahren genutzt wird. Berichte aus der Industrie sprechen oft von Chiffren, Versetzungen der Bytes, Bit-Shift usw. aber mir wurde berichtet, dass noch nicht verschlüsselt wird, da dazu zu viel Bandbreite nötig ist. Niine schrieb: > Ist es nicht ziemlich langweilig sowas zu probieren, > was schon soviele andere gemacht haben? Wieso versuchst du sowas > nichtmal am FlexRay in sehr modernen Autos? Erstmal möchte ich den CAN hacken. Ob FlexRay dazu kommt, entscheide ich später. Für langweilig halte ich dies nicht, da es offentsichtlich eher nicht viele Leute gibt, die sich damit auskennen. Niine schrieb: > Ansonsten wie schon gesagt wurde: Am effektivsten ist es direkt die CAN > Leitung abzugreifen welche du beeinflussen willst. Da sollte schon was > möglich sein. Das ist der Plan. Falls es sich danach anhört, dass ich "nur" die OBSII Schnittstelle verwenden wollte, so möchte ich dies hier aufklären. Es werden natürlich alle Schnittstellen idendifiziert und ausgenutzt. OBDII, CAN (Schalthebel, Radio, ggf schlecht versteckt Kabel etc...) Ich habe mir gerade Literatur geschnappt und arbeite diese durch. Bei Erfolg berichte ich natürlich ;)
Stanislav L. schrieb: > Bei Erfolg berichte ich natürlich ;) Oh ja, bitte. Von allen die in den letzten Jahren hier vorbei gekommen sind und ähnliches vorhatten gab es m.W. nie eine Erfolgsmeldung. Stanislav L. schrieb > Ich habe zahlreiche Videos bei Youtube gesehen wie Autos gehackt werden > und per Remote alle Befehle auf dem CAN Bus durchgeführt werden können. Wie habe ich (und andere hier) es nur geschafft mich mit CAN auszukennen ohne ein einziges Youtube-Video gesehen zu haben? Gibt es keine anderen Informationsquellen mehr? > Ich habe mir gerade Literatur geschnappt.. Dann weißt du demnächst evtl. auch was Remote beim CAN-Bus bedeutet...
> Ich höre gerade zum ersten Mal, dass ein Verschlüsselungsverfahren > genutzt wird. Berichte aus der Industrie sprechen oft von Chiffren, > Versetzungen der Bytes, Bit-Shift usw. aber mir wurde berichtet, dass > noch nicht verschlüsselt wird, da dazu zu viel Bandbreite nötig ist. > Das braucht keine Bandbreite, da reicht eine einfache XOR-Operation. Die Kommunikation bei CAN lässt sich nicht sonderlich gut verschlüsseln, das gibt einfach der Standard nicht her. Aber Security Nonces (wie bei einem TAN-Verfahren) kommen öfters vor, damit Replay-Attacken nicht so einfach möglich sind. Wo die Verschlüsselung zum Zug kommt, sind die Bootloader, dass man nicht einfach neue Firmware einspielen kann. Nutzt aber alles nichts, wenn sich a) JTAG nicht 100% deaktivieren lässt oder b) schlicht die Keys bekannt werden (wie bei HDCP). Da kannst du durchaus in einem halben Jahr Erfolg haben. Aber fang erst mal mit dem Sniffer an. Du wirst schon etwas Zeit brauchen, um schon nur die CAN-Register zu erraten. Dann macht es auch frühzeitig Sinn, herauszubekommen, was für eine ECU du überhaupt hast, und was für SoCs eingesetzt werden. > Von allen die in den letzten Jahren hier vorbei gekommen sind und > ähnliches vorhatten gab es m.W. nie eine Erfolgsmeldung. Das dürfte daran liegen, dass nach Veröffentlichung solcher Reverse-Engineering-Vorhaben sich eine gewisse Anzahl von Interessenten bei dir melden könnte und dir in der einen oder anderen Richtung auf der Nase rumtanzt, bis die NDAs unterschrieben sind oder du den Prozess wegen Veröffentlichung von Geschäftsgeheimnissen oder Umgehen von Schutzmassnahmen verloren hast (zu letzerem sind mir allerdings bei dem Thema keine Fälle bekannt) Auch wenn du feststellen solltest, dass sich damit ein gewisses Geschäftsmodell verbinden könnte (wie z.B. in der Handy-Branche mit dem Aendern türkischer IMEIs), würdest du den Ruhm, den du in der RE-Community damit erwerben könntest, eher ablehnen. Oder nicht? Ich würde einfach raten, das Ganze unter einen möglichst akademischen Schutzmantel zu verfrachten und "Hacken" in "Sicherheitsforschung" umzubenennen.
https://www.youtube.com/watch?v=EDsHSwTfASo Zusammenfassung: mit dem Gerät, was er in der Hand hat, kann er jedes Auto starten, er meint buchstäblich "alles was sich auf der Straßen bewegt". Das teil hat ihm ca. 150 000€ gekostet und aus Russland geholt. bei MINI cooper, er hat das Auto (Steuergerät) umprogrammiert, dass es jetzt nur mit seinem eigenen Karte starten lässt. wie kann dies sein?!!
Hallo zusammen, nachdem ich nun eine Weile mit dem Ganzen gearbeitet habe, sind einige Erkenntnisse gewonnen worden. Die Kommunikation auf dem CAN-Bus läuft bis heute absolut unverschlüsselt ab. Es gibt keine Implementierungen, die sowas verhindern. In der Vergangenheit hatten viele Menschen Erfolg beim Angriff auf sicherheitskritische Funktionen. Teilweise ist es einigen gelungen über den CD Player und einer gebrannten Musik-CD Angriffe auf die Motorsteuerung zu starten, indem Pakete geschickt verpackt worden sind und die Gateways ausgetrickst haben. Eine Verschlüsselung lässt sich mit dem aktuellen Standard auf Grund der Spezifikation allein nicht implementieren. Im Protokoll sind 8 Byte für Daten vorgesehen. Damit konkurieren stets Laufzeit und Verschlüsselung gegeneinander. Wenn ich ein Datenpaket für den Airbag verschlüsseln möchte, dann löst er erst aus wenn der Fahrer die Baumrinde schmeckt (ich entschuldige mich für meine zugespitzte Art). Fitzebutze schrieb: >> Von allen die in den letzten Jahren hier vorbei gekommen sind und >> ähnliches vorhatten gab es m.W. nie eine Erfolgsmeldung. Y. M. schrieb: > Das teil hat ihm ca. 150 000€ gekostet und aus Russland geholt. Ich bezweifle die Relevanz dieser Aussage auf mehreren Ebenen. Geld hat hier nichts zu entscheiden. Zurzeit habe ich eine große Herausforderung. Ich habe mir CAN-Capes aus China geholt und in Betrieb genommen. Bedauerlicherweise werden keine Daten empfangen. Ich ärgere mich an der Stelle kein Oszilloskop zu besitzen :( Gekauft habe ich folgendes: http://www.waveshare.com/wiki/RS485_CAN_CAPE Ich habe zwei Beaglebone Black mit dem CAN-Cape aufgesetzt und das OS der Seite genutzt. Die Klemmen CAN-H(high) und CAN-L (low) wurden mit den jeweiligen Klemmen des anderen verbunden. Die Differenzspannung beider ist nun 0 V (so sollte es auch laut Spezifikation sein). Nur wenn ich mit dem einen sende, empfängt der andere nichts. Hat jemand eine Idee was hier schief gelaufen ist? Folgende Befehle wurden verwendet: BBB1>beaglebone:~#canconfig can0 bitrate 115200 ctrlmode triple-sampling on BBB1>canconfig can0 start # ab hier ist das Interface can0 up und wird unter ifconfig angezeigt BBB1>candump can0 # Snifft Daten auf dem Bus BBB2>beaglebone:~#canconfig can0 bitrate 115200 ctrlmode triple-sampling on BBB2>canconfig can0 start # ab hier ist das Interface can0 up und wird BBB2>cansend can0 123#11.22.33 # Der Befehl der Doku hat die falsche Syntax Nun sollten auf BBB1 Daten zu sehen sein, doch ich erhalte nichts. Ferner habe ich eine Frage. In der Beschreibung steht "Set jumper to enable UART1(RXD1, TXD1)": Mit dieser Angabe kann ich nichts anfangen. Hat hier wer eine Idee? Gruß Stanislav
Stanislav L. schrieb: > Ich habe zwei Beaglebone Black mit dem CAN-Cape aufgesetzt und das OS > der Seite genutzt. Die Klemmen CAN-H(high) und CAN-L (low) wurden mit > den jeweiligen Klemmen des anderen verbunden. Die Differenzspannung > beider ist nun 0 V (so sollte es auch laut Spezifikation sein). Nur wenn > ich mit dem einen sende, empfängt der andere nichts. Hat jemand eine > Idee was hier schief gelaufen ist? 2 x 120 Ohm Terminierung vergessen? Adern nicht verdrillt bzw. falscher Wellenwiderstand?
Stanislav L. schrieb: > Ferner habe ich eine Frage. In der Beschreibung steht "Set jumper to > enable UART1(RXD1, TXD1)": Mit dieser Angabe kann ich nichts anfangen. > Hat hier wer eine Idee? Es gibt RXD0, RXD1, RXD2, RXD4, RXD5 und dementsprechend auch TXD0, TXD1, TXD2, TXD4, TXD5. An "RXD JMP" jumper von RXD1 nach RXD. An "TXD JMP" jumper von TXD1 nach TXD. Was ist daran so schwer ? EDIT: Vielleicht trotzdem RS485 Enable jumper rausziehen.
:
Bearbeitet durch User
Stanislav L. schrieb: > Teilweise ist es > einigen gelungen über den CD Player und einer gebrannten Musik-CD > Angriffe auf die Motorsteuerung zu starten, indem Pakete geschickt > verpackt worden sind und die Gateways ausgetrickst haben. Sorry, aber das ist Bullsh...
Richard B. schrieb: > Stanislav L. schrieb: >> Teilweise ist es >> einigen gelungen über den CD Player und einer gebrannten Musik-CD >> Angriffe auf die Motorsteuerung zu starten, indem Pakete geschickt >> verpackt worden sind und die Gateways ausgetrickst haben. > > Sorry, aber das ist Bullsh... LOL, habe ich gar nicht gesehen. Wo sollen welche Pakete geschickt worden sein ? Falls es sich um Audio CDs handelt, ist es ein absoluter Blodsinn, da werden nur binäre Daten in Töne umgewandelt - jede mögliche Kombination von Daten ergibt eine valide Tonfolge - ob daraus Musik oder Kreischen wird, ist eine andere Frage. Wenn es MP3 ist, da wird es zwar encoded aber es wird nichts aus- geführt. Wenn es kein MP3 ist sondern etwas anderes, wird es gar nicht erst abgespielt, weil es nicht als valides MP3 erkannt wird. In jedem Fall wird da nichts ausgeführt - entweder es wird als MP3 erkannt oder nicht. Und ein CD Player im Auto ist nicht gleichzusetzen mit Windows Media Player oder ähnlichen Programmen die durch falsche Headerdaten schon mal verrückt spielen können - und da setzen diese Viruse an. Falls du wirklich so ein Blödsinn glaubst, würde ich mich an deiner Stelle nicht weiter mit diesem Thema quälen - bei deinem Kenntnisstand ist es mit an Sicherheit grenzender Wahrscheinlichkeit zum Scheitern verurteilt.
:
Bearbeitet durch User
Stanislav L. schrieb: > Teilweise ist es > einigen gelungen über den CD Player und einer gebrannten Musik-CD > Angriffe auf die Motorsteuerung zu starten, indem Pakete geschickt > verpackt worden sind und die Gateways ausgetrickst haben. Wo hast du denn diese Urban Legend gefunden? Falls du damit dies hier meinst: http://illmatics.com/Remote%20Car%20Hacking.pdf Wenn man das bis zum Ende durchliest (ich habs gelesen) wird man feststellen soo einfach ist das ganze gar nicht. Ein Experten-Team hat ja nur drei Jahre hierfür gebraucht.
Hallo, naja, ich wäre sehr vorsichtig mit der Häme - schon 2010 wurde ein solcher Hack von Mitarbeitern der University of Washington auf einem IEEEE-Symposium vorgestellt. Grund ist, dass immer häufiger Geräte verbaut werden, die ersten wesentlich mehr können als nur CDs abspielen und zweitens auch noch vom Benutzer updatebar sind. Eine schöne Zusammenfassung von verschiedenen Car-Hacks findet sich unter: http://venturebeat.com/2016/06/27/the-5-scariest-car-hacks-including-some-that-could-make-you-crash/ Wie gesagt, wenn man einmal Zugriff auf den CAN hat und weiß was man tut, lässt sich aktuell viel Unsinn mit den Fahrzeugen anstellen - selbst ein "beweisloser Mord" ist durchaus möglich: Angriff über eine Lücke des Telematik-Systems, Einschleusen einer Schad-Software die bei einer bestimmten Fahrsituation einen Unfall erzeugt (z.B. durch Blockieren der Räder in einer Kurve bei hohen Geschwindigkeiten) und sich nach Auslösen des Airbags selber löscht. Bei manchen Fahrzeugen ist dies tatsächlich zur Zeit möglich (es hat schon einige Rückrufe wegen Sicherheitslücken in Telematiksystemen gegeben - z.B. 1.4 Mio Fahrzeuge von Fiat-Chrysler). Und bei (geschätzt) >15.000 Mitarbeitern bei OEMs und Zulieferern, die das notwendige Wissen besitzten, ist es nur eine Frage der Zeit, bis aus einem 3-Jahres-Angriff ein Tool für Script-Kiddies wird... Schöne Grüße, Martin
Marc V. schrieb: > Wenn es MP3 ist, da wird es zwar encoded aber es wird nichts aus- > geführt. Wenn es kein MP3 ist sondern etwas anderes, wird es gar nicht > erst abgespielt, weil es nicht als valides MP3 erkannt wird. In > jedem Fall wird da nichts ausgeführt - entweder es wird als MP3 > erkannt oder nicht. Und ein CD Player im Auto ist nicht gleichzusetzen > mit Windows Media Player oder ähnlichen Programmen die durch falsche > Headerdaten schon mal verrückt spielen können - und da setzen diese > Viruse an. Grundsätzlich richtig. Aber dann auch wieder nicht. Zumindest die ersten COMANDs im Mercedes (bevor USB-Sticks und SD-Karten gängig waren) bekamen ihre (damals reichlich oft notwendigen) Updates über eine Service-CD/DVD. Ob und wie gut diese Updatemöglichkeit Schabernack ausschließt, weiß aber nur der Programmierer. Zumindest in den Anfängen der Digitaltechnik im Auto ist man damit jedenfalls reichlich naiv umgegangen.
Thomas F. schrieb: > Stanislav L. schrieb: >> Teilweise ist es >> einigen gelungen über den CD Player und einer gebrannten Musik-CD >> Angriffe auf die Motorsteuerung zu starten, indem Pakete geschickt >> verpackt worden sind und die Gateways ausgetrickst haben. > > Wo hast du denn diese Urban Legend gefunden? Keine Urban legend. > > Falls du damit dies hier meinst: > > http://illmatics.com/Remote%20Car%20Hacking.pdf > > Wenn man das bis zum Ende durchliest (ich habs gelesen) wird man > feststellen soo einfach ist das ganze gar nicht. Ein Experten-Team hat > ja nur drei Jahre hierfür gebraucht. Das kann definitiv schneller gehen. Er meint vermutlich das System von SVDO was in einigen BMW-Modellen (die mit dem tollen Joystick) verbaut wurde. Ich kann nur sagen: Manche Update-Konzepte sind einfach keine gute Idee. Wie schon oben erwähnt ist es nur noch etwas Fleissarbeit, die Systeme zu untersuchen, wenn man sich erst mal den JTAG-Zugang verschafft hat und den Reset-Watchdog 'stimuliert'. Bei neueren Systemen mit FPGA-Obskuritäten könnte es allerdings länger dauern.
Fitzebutze schrieb: > Wie schon oben erwähnt ist es nur noch etwas Fleissarbeit, die Systeme > zu untersuchen, wenn man sich erst mal den JTAG-Zugang verschafft hat > und den Reset-Watchdog 'stimuliert'. JTAG per Musik-CD oder über eine Internet-App? Oder muss man vorher das halbe Auto auseinander nehmen um an den JTAG dran zu kommen?
Hallo, auseinander nehmen zum lernen/implementieren, Update-CD oder Internet-App zum anwenden. Ist halt so im Informationszeitalter: Es braucht nur einer sich die Arbeit zu machen, damit hunderte leicht das Gleiche erreichen können. Glaubt es einfach, es gibt aktuell einige Autos, die zwar extrem auf Funktionssicherheit abgeprüft wurden, die aber ganze Scheunentore bezüglich IT-Sicherheit aufweisen. Das einzige, was aktuell den Super-GAU verhindert, ist die geringe Motivation der potentiellen Angreifer, das zu versuchen (warum sollte ich ein Auto "fernsteuern", wenn es mir das gleiche Wissen erlaubt, es zu klauen?). Gilt aber genauso für viele andere klassische Bereiche, die in den letzten Jahren "intelligent" wurden. So gibt (bzw. gab vor 15 Jahren, seitdem nicht mehr nachgesehen) es auch ganz einfache Methoden, einen ICE zur Vollbremsung zu zwingen... Schöne Grüße, Martin
Thomas F. schrieb: > Fitzebutze schrieb: >> Wie schon oben erwähnt ist es nur noch etwas Fleissarbeit, die Systeme >> zu untersuchen, wenn man sich erst mal den JTAG-Zugang verschafft hat >> und den Reset-Watchdog 'stimuliert'. > > JTAG per Musik-CD oder über eine Internet-App? Oder muss man vorher das > halbe Auto auseinander nehmen um an den JTAG dran zu kommen? Habe mich vielleicht zu knapp gefasst: Die Sicherheitslücken per Update-CD findet man typischerweise, wenn man die Firmware per JTAG ausliest. Dazu muss man in der Tat an die Platine herankommen, aber nicht zwingend sein Auto auseinandernehmen. Martin L. schrieb: > Das einzige, was aktuell den Super-GAU verhindert, ist die geringe > Motivation der potentiellen Angreifer, das zu versuchen (warum sollte > ich ein Auto "fernsteuern", wenn es mir das gleiche Wissen erlaubt, es > zu klauen?). Gilt aber genauso für viele andere klassische Bereiche, die Ich denke, damit triffst Du es gut. Das Bestreben zum Reverse Engineering ist typischerweise: a) Schauen wie die Konkurrenz es macht b) Überprüfen, ob die Konkurrenz eigene Patente verletzt Allerdings kann ich nicht beurteilen, wieweit gut organisierte IT-Kriminelle in Zukunft solche Lücken nutzen werden. Aber sagen wir mal: c) Auto drahtlos öffnen, CD einlegen (neue Seriennummer, Tracking aus), wegfahren Verschwörungstheorie: d) Miessliebigen Personen die Car-Firmware manipulieren e) Konkurrenz mit induzierten Unfällen gezielt schädigen Wenn's so einfach für eine breite Klientel wird, wird's eben zum Thema.
Der langen Rede kurzer Sinn: Ein Hack ist nur dann möglich, wenn der Hersteller Sicherheitslücken in der Software hat, mit Software in BOLD. Ein Hochsicherheits CAN im Auto und fertig ist die Laube. Zutritt nur durch entsprechende Stecker oder direkt am Bus möglich - da muss man aber erst mal drankommen. Was haben Bluetooth und WiFi normalerweise mit irgendeiner ECU zu tun ? Der ganze Blödsinn mit CD Player, MP3, Bluetooth, WiFi und ähnlichem ist nur möglich, weil bei den Firmen die so etwas herstellen bzw. in ihre Fahrzeuge einbauen, Idioten arbeiten. Flugzeughersteller können auch ihre Fly By Wire Systeme über einen gemeinsamen Bus mit Entertainment Bus für Passagiere realisieren. Spart Kosten. Auf jeden Fall: Marc V. schrieb: > Ich glaube, ich suche mir wieder ein Auto vor Baujahr 2006.
> Marc V. schrieb: > Der ganze Blödsinn mit CD Player, MP3, Bluetooth, WiFi und ähnlichem > ist nur möglich, weil bei den Firmen die so etwas herstellen bzw. > in ihre Fahrzeuge einbauen, Idioten arbeiten. > Ich glaube, ich suche mir wieder ein Auto vor Baujahr 2006. Mein Auto ist von 2007. Da hängt der CD-Wechsler am MOST, nicht am CAN-Bus. Damit bin ich ja dann sicher;-)
Marc V. schrieb: > Ein Hochsicherheits CAN im Auto und fertig ist die Laube. > Zutritt nur durch entsprechende Stecker oder direkt am Bus möglich > - da muss man aber erst mal drankommen. Moderne Autos haben teilweise mehr als 100 MByte Binärcode in über 60 Steuergeräten. Bis auf triviale Anwendungen (z.B. "Türsteuergerät", welches nur den Zustand des Fensterheber-Schalters auf den CAN-Bus legt) müssen diese update-fähig sein, denn alle nicht-triviale Programme enthalten Fehler. Diese Update-Fähigkeit muss über das Fahrzeugnetzwerk (in neueren Autos gibt es auch gerne einmal 6 oder 8 getrennte CAN-Busse und/oder Flex-Ray und/oder Automotive-Ethernet) möglich sein, wenn man nicht jedes Mal das Steuergerät tauschen oder zumindest ausbauen (und auf dem Weg dahin das halbe Auto zerlegen) möchte. Damit reicht aber im Prinzip ein von außen kompromitierbares Steuergerät aus, um sich nach und nach das ganze Netzwerk erobern zu können, wenn nicht entsprechende Gegenmaßnahmen getroffen wurden (Firewalls in den Gateways, redundante Busüberwachung,...). Mit einem "entsprechenden Stecker" ist es also nicht getan (abgesehen davon, dass dieser erstens leicht nachzubauen wäre und zweitens auch im Ersatzteilhandel abrufbar sein müsste). "Hochsicherheits-CAN" ist theoretisch möglich, allerdings aktuell - wenn überhaupt - nur rudimentär implementiert und in der Detail-Implementation nicht trivial (was dann wieder andere Angriffsvektoren öffnet...). > Was haben Bluetooth und WiFi normalerweise mit irgendeiner ECU zu tun ? Neue Autos haben in der Regel zentrale HMI (Human-Machine-Interfaces), die die verschiedenen Fahrzeugssysteme wie Klima, Radio, Freisprecheinrichtung, Navigation,... ansteuern können. Auch ist es tatsächlich der Wunsch des durchschnittlichen Kunden, möglichst viel Konnektivität zu haben, also per Bluetooth sein Handy zu koppeln oder sogar einen WiFi-Hotspot (mit eigener SIM oder mit Handy-Tethern) zu bekommen. Die Kommunikations-Stacks sind allerdings auch nicht trivial und damit fehleranfällig. Damit besteht eine gute Chance, das Steuergerät zu kompromitieren, auf welchem der Stack läuft. Dieses wiederum ist sicher im Fahrzeugnetzwerk integriert und damit kann über diesen Weg jede beliebige ECU kompromitiert werden (siehe oben). > Der ganze Blödsinn mit CD Player, MP3, Bluetooth, WiFi und ähnlichem > ist nur möglich, weil bei den Firmen die so etwas herstellen bzw. > in ihre Fahrzeuge einbauen, Idioten arbeiten. Genau, alles Idioten: Die Leute, die entscheiden, dass immer mehr "Intelligenz" in das Auto eingebaut werden soll, weil der idiotische Kunde danach verlangt, die Systemarchitekten, die zu idiotisch sind, alle Nebenwirkungen in einem hochkomplexen Netzwerk mit mehr als 60 Knoten zu überblicken, die Idioten, die die Spezifikationen der einzelnen Steuergeräte aufstellen und es nicht schaffen, dies vollständig unter Ausschluss von Lücken durchzuführen, die Heerscharen von idiotischen Programmieren, die zu blöd sind die perfekten Spezifikationen zu implementieren und die ganzen Tester, die mit ein bisschen Nachdenken doch auf den Testfall hätten kommen müssen, der die Lücke aufdeckt. Kleiner Tipp: wenn man glaubt, die ganze Welt sei idiotisch und man der einzige Normale, sollte man ganz dringend überprüfen, ob es nicht genau anders herum ist... > Flugzeughersteller können auch ihre Fly By Wire Systeme über einen > gemeinsamen Bus mit Entertainment Bus für Passagiere realisieren. > Spart Kosten. Ich bin da vermutlich nicht auf der Höhe der Zeit, aber zumindest die mir bekannten Bus-Systeme (hauptsächlich durch ARINC standardisiert) haben getrennte Multimedia- und Control-Netzwerke (wobei es natürlich, ähnlich wie im Auto, Gateways gibt und somit prinzipiell ähnliche Szenarios denkbar wären). Hauptunterschied zum Auto ist allerdings, dass die Update-Fähigkeit über Netz nicht so essenziell ist und deswegen in der Regel nicht gegeben ist, und dass jede Zeile sicherheitsrelevanten Quellcodes Kosten von bis zu 30.000 Euro verursacht, weswegen nur sehr wenig wirklich sicherheitsrelevantes von Computern gesteuert wird. Und trotzdem sind schon mehrere Vorfälle mit externer elektronischer Beeinflussung (in der Regel ungewollt) in Verbindung gebracht worden. Die Entwickler sind wohl auch alles Idioten gewesen... Schöne Grüße, Martin
Martin L. schrieb: > Diese Update-Fähigkeit muss über das Fahrzeugnetzwerk (in neueren Autos > gibt es auch gerne einmal 6 oder 8 getrennte CAN-Busse und/oder Flex-Ray > und/oder Automotive-Ethernet) möglich sein, wenn man nicht jedes Mal das > Gateways, redundante Busüberwachung,...). Mit einem "entsprechenden > Stecker" ist es also nicht getan (abgesehen davon, dass dieser erstens > leicht nachzubauen wäre und zweitens auch im Ersatzteilhandel abrufbar > sein müsste). Es soll nicht ein Hochsicherheits-Stecker sein, ein ganz normaler Stecker reicht auch. Nur soll es eben einen Hochsicherheits-CAN und vielleicht noch einen Update-CAN geben. Bluetooth, WiFi können ihre Daten (wohlbemerkt Daten) auf irgendeinem Bus bereitstellen, austauschen oder abholen, was auch immer, diese Daten können dann von interessierten ECUs über Gateway abgeholt oder neue zurückgesendet werden. Im schlimmsten Fall könnten damit falsche Daten wie etwa Regen oder Schneefall vorgetäuscht werden. Und CD hat da überhaupt nichts zu suchen. Nach der Logik könnte man mit Fernbedienug für CD-Wechsler ABS-ECU ausser Betrieb setzen. > Genau, alles Idioten: Die Leute, die entscheiden, dass immer mehr > "Intelligenz" in das Auto eingebaut werden soll, weil der idiotische Wenn man Geld, alle PINs, Passwörter, Kreditkarten, womöglich noch die Schlüssel vom Haus und Banksafe zusammen in der Geldbörse aufbewahrt, dann ist dieser jemand kurzgesagt, ein Idiot. Genau das machen aber die Autohersteller - alles schön zusammen in eine Geldbörse reinpacken und damit zugänglich machen. Martin L. schrieb: > Kleiner Tipp: wenn man glaubt, die ganze Welt sei idiotisch und man der > einzige Normale, sollte man ganz dringend überprüfen, ob es nicht genau > anders herum ist... Auch für dich ein Tip: Erst lesen, dann posten - nicht alle, nur die Verantwortlichen. > die Systemarchitekten, die zu idiotisch sind, > alle Nebenwirkungen in einem hochkomplexen Netzwerk mit mehr als 60 > Knoten zu überblicken, Das ist keine Nebenwirkung, das ist eine ernste Sicherheitslücke und ja, das sind Idioten. > die Idioten, die die Spezifikationen der > einzelnen Steuergeräte aufstellen und es nicht schaffen, dies > vollständig unter Ausschluss von Lücken durchzuführen, Es ist selbstverständlich nicht ihr Job zu prüfen, ob noch andere Geräte wie z.B. ein unbedingt für die Fahrsicherheit notwendiges CD oder Bluetooth bzw. WiFi am selben Bus hängen. > die Heerscharen > von idiotischen Programmieren, die zu blöd sind die perfekten > Spezifikationen zu implementieren Es ist selbstverständlich nicht ihr Job zu prüfen, ob noch andere Geräte wie z.B. ein unbedingt für die Fahrsicherheit notwendiges CD oder Bluetooth bzw. WiFi am selben Bus hängen. > und die ganzen Tester, die mit ein > bisschen Nachdenken doch auf den Testfall hätten kommen müssen, der die > Lücke aufdeckt. Ja, falls es solche überhaupt gegeben hat. > wenig wirklich sicherheitsrelevantes von Computern gesteuert wird. Und > trotzdem sind schon mehrere Vorfälle mit externer elektronischer > Beeinflussung (in der Regel ungewollt) in Verbindung gebracht worden. Nur mit Daten die von ausserhalb kommen, nicht die internen Daten. > Die Entwickler sind wohl auch alles Idioten gewesen... Nein, nur haben die Idioten die in Flugzeugen damit rumgespielt haben, den Vorteil der Zeit und der technologischen Entwicklung.
:
Bearbeitet durch User
Fitzebutze schrieb: > Ich denke, damit triffst Du es gut. Das Bestreben zum Reverse > Engineering ist typischerweise: > a) Schauen wie die Konkurrenz es macht > b) Überprüfen, ob die Konkurrenz eigene Patente verletzt > > Allerdings kann ich nicht beurteilen, wieweit gut organisierte > IT-Kriminelle in Zukunft solche Lücken nutzen werden. > Aber sagen wir mal: > > c) Auto drahtlos öffnen, CD einlegen (neue Seriennummer, Tracking aus), > wegfahren > > Verschwörungstheorie: > > d) Miessliebigen Personen die Car-Firmware manipulieren > e) Konkurrenz mit induzierten Unfällen gezielt schädigen > > Wenn's so einfach für eine breite Klientel wird, wird's eben zum Thema. Klingt gut. Lasst uns da einen BSC Studiengang draus machen. /regards P.S: Sorry, just kidding :-D
> >> Der ganze Blödsinn mit CD Player, MP3, Bluetooth, WiFi und ähnlichem >> ist nur möglich, weil bei den Firmen die so etwas herstellen bzw. >> in ihre Fahrzeuge einbauen, Idioten arbeiten. > Vielleicht wars von Gernhardt: Blöde gibt es viele, am Rhein und auch am Nile. Das Wort "Idioten" finde ich ziemlich vermessen. Es sind schlussendlich grosse Firmen, die mit Wasser kochen. Und es darf nicht 2 Jahre dauern, bis der Security-Bootloader endlich fertig ist, mit dem man sich in der Entwicklung nicht aussperrt oder dem Standard verschliesst. Da geht bei der marktgetriebenen Feauturitis im Management der Rotstift schnell über Security-Aspekte. Das ist ok, solange die Safety eben nicht betroffen ist, und an letzterer Ecke wird sicher geschludert und viele Systeme sind ihre Zertifizierung schlicht nicht wert. Es arbeiten aber auch einfach sehr viele Leute an der gleichen Baustelle und nicht alle davon sind paranoide Hacker. >> Ich glaube, ich suche mir wieder ein Auto vor Baujahr 2006. > > Mein Auto ist von 2007. Da hängt der CD-Wechsler am MOST, nicht am > CAN-Bus. Damit bin ich ja dann sicher;-) Auch für die MXVR der einschlägigen SoCs wären im Prinzip Attacken möglich. Wenn der SoC keine echte Memory-Protection hat (wie z.B. der so um diese Zeit gerne verbaute ADSP-BF539) kannst du auch da Code in sicherheitsrelevante Bereiche (also CAN I/O) injizieren. Aber ist gar nicht nötig, wenn die Update-Funktion schon vorgesehen ist. Schlussendlich muss bei einer gut verkauften Automarke auch ein weltweit brauchbarer Service her. D.h. auch Programmiergeräte oder einfache Möglichkeit eines Update durch Servicetechniker. Pragmatische Ansätze, die ich ev. genauso machen würde. Die Programmer werden geklont, und die Chips getunt. Manche Automarken verkaufen sich gerade deswegen besonders gut, und das sind uU die Aspekte, die zählen. Muss ich mich deswegen als Idioten bezeichnen lassen? Um mal wieder zum Thema zurückzukommen: Ich begrüsse es, dass öffentliches Reverse-Engineering im Automotive-Bereich betrieben wird. Ein Oszi lohnt sich da allerdings, dafür kann man sogar das Chinateil "minidso" verwenden. Mit alternativer Firmware macht das nen guten CANalyzer.
Fitzebutze schrieb: > Vielleicht wars von Gernhardt: Blöde gibt es viele, am Rhein und auch am > Nile. Das Wort "Idioten" finde ich ziemlich vermessen. Natürlich ist "Idioten" übertrieben aber wir schreiben 2016 und nicht mehr 1986. Man kann nicht HiTech einbauen und erwarten, dass niemand auf die Idee kommen wird, dies zu hacken, schlimmer noch, es wird extrem erleichtert durch irgendwelche Devices die absolut unnötig am CAN Bus hängen oder Zutritt zum CAN Bus haben. > Da geht bei der marktgetriebenen Feauturitis im Management > der Rotstift schnell über Security-Aspekte. Das ist ok, solange die Kosten sind wichtig, aber Sicherheit der Kunden sollte wichtiger sein. Was sind 50-100 Euro (und das ist schon übertrieben) Mehrkosten im Vergleich zum Endpreis für Käufer ? > Die Programmer werden geklont, und die Chips getunt. Manche Automarken > verkaufen sich gerade deswegen besonders gut, und das sind uU die > Aspekte, die zählen. > Muss ich mich deswegen als Idioten bezeichnen lassen? Das ist etwas ganz anderes. Wenn ich Chip Tuning mache, geschieht das direkt oder über entsprechende Schnittstelle. Dasselbe gilt für Programmer bzw. Diagnose. Ich rede von Attacken während der Fahrt oder noch schlimmer, über CD der unnötigerweise am selben CAN Bus hängt wie lebenswichtige ECUs oder Zutritt darauf über einen Gateway hat. Das ist, um mich vorsichtig auszudrücken, zumindest leichtsinnig.
Hat die Forschung mittlerweile Früchte getragen oder hat sich das ganze im Sand verlaufen ?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.