Thanks for the link to the researchers report. I read through it in detail and most of what they are saying relates to getting a CD into the car, and accessing the OBD-II port to make code changes. Later in the article they mention bluetooth cellular and RDS as attack vectors but it's not entirely clear (to me) whether these attack vectors only become available after the previous physical access. If the physical access is not necessary then the car they chose is difnitely hackable in the fashion I didn't believe possible, where as if the physical access is necessary then it is essentially as I had suspected. and I put this in the "brake line" category.
The thought of corrupting an OBD-II pass thru or even compromising the PC used in the workshop are certainly realistic and not precursors I had entertained as part of "hacking", but if we add that to the mix then short of not allowing dealers reprogramming access, I don't see the hacking problem going away. And that I believe will never happen without a government directive because it is too convenient and represents too much of a cost savings to them (dealer and vehicle manufacturer).
Hi Bert, in fact fails safe modes for all sensors are part of the design criteria for intelligent car modules. That sad fact of the matter is that more and more car design is being done in countries where most engineers don't drive a car :-) I worked for this unnamed automotive electronics manufacturer that moved design of an OEM program to Singapore where car ownership is at maybe 12% according to Wikipedia and when I was there only 1/2 the engineers had cars and none tinkered with them, essential to fully understanding things (I believe). In any case the issues that arose from that program were many. On my car the throttle position sensor had an intermittent fault and the only thing that was noticable was the car's inability to accelerate fast from a standstill. This was obiously missed on the ABS system mentioned resulting in the recall. I read the article that Junko referred to, and they put a lot less effort into it than professional crime gangs do into Windows exploits, but a hacker having OBD-II access to a car in my opinion is the same as giving your computer to the hacker to do as he sees fit, and is therefore indefensible. I.e as you say the same as cutting brake lines.
Hi Krisi, having an inside ticket to this I can say that some of the push is cost savings for the vehicle manufacturer in the build of the vehicle, part is warranty cost reduction by making the vehicle's systems easier to debug and part is to make it cheaper to add luxury features for next to no cost but still be able to charge for them. Then there's the majority of buyer that want the extra functionality I could write a thesis on this as to where all of cost benefits come but suffice to say here it's worth it for them and we're along for the ride (like it or not). These comments are explicitly related to vehicle networks, not the actual electronification of cars. I could do a thesis on that as well. :-) Some are common to the above and some additional. Purely on electronics in cars, this actually saves the buyer money for real benefit.
Yes the original article weighed heavily on getting the OBD-II port accessed. I read the article too, and it was very unclear as to wheather the OBD-II attack was necessary in addition to the Bluetooth/cellular attacks. I agree with your mention of the normal CAN messaging only allowing certain things to be transported, but would like to add that if you have access to the CAN bus itself via an OBD-II pass thru then reprogramming of every module on that bus becomes a possibility unless the module manufacturer disables it explicitly.
Assuming for the moment that this hasn't been done then in my mind far easier than the methods proposed in the original article would be to design a module that you can attach to the CAN bus in a few minutes that can at your leasure give you access to module reprogramming when you chose. Because the CAN HW layer won't let you crash the bus (something a simple wire link could of course do) you would need to do things like invoke special test modes that do allow control and are there for service puposes, and it would just be so much easier to develop and debug with the same level of mischief as the interfaces are specified in the OBD-II standards and manufacturer documentation.
But nothing a remote brake line sever couldn't achieve :-(
I doubt very much that an OBD2 connection is connected directly to the engine bus. Instead the connection is likely to a gatweay which provides the OBD2 standard messages.
This is easy to test: short out the CAN wires on the OBD2 connector and see if the engine runs. There is no way any sane car designer is going to have that connector connected so it can tamper directly with the main CAN bus.
By the way, CAN is really easy to DOS. Just dshort the wires, or continually send priority 0 packets. These have a higher priority and will prevent any other trafic on the bus.
At the end of the day, anyone with physical access can do anything they want: mess with the fuel, cut fuel lines, .... The only bene fit of doing an electronic attach is that you **might** be able to do damage without leaving any trace that you were being naughty.
These days, however, many vehicle manufacturers are doing a whole lot of run-time verification to reduce the possibility of tampering and are logging strangeness for diagnosis as well as for evidence during court cases.
This was largely my understanding (gateway) but the article desribed a less complicated structure. A Diesel truck I was working on a while back had 2 buses, an internal TCM to ECM path and an instrument cluster path and given that dealers can reflash the ECU as part of recall processing the OBD-II port would need programming access to that bus. I'll grab a few manuals and have a further think about this.
Hi, Etmax. I believe you are right. For attack scenarios using bluetooth cellular does require the previous physical access, if I understood it correctly.
Aside from the debate over how easy or difficult it is to gain the previous physical access to a car that is to be attacked (and I agree, it would be difficult), it still boggles my mind how easy bluetooth pairing was done in that attack test scenario.
I agree thaqt accessing the OBD-II is an age-old problem, which is hard to solve.
Car entertainment and car infotainment are two very important technology related to the improvements in car infosystems. Several, new technologies are also being implemented in car industry also. Car sensors and car electronic dashboards are quite helpful for the car traffic control and proper route detection also. Auto parts repair and service also very necessary for the safety of the vehicle or car users. It will help in safe driving by the vehicle operator.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.