Hackers take control of a moving car

Page may contain affiliate links. Please see terms for details.

markmifsud

MB Enthusiast
SUPPORTER
Joined
Nov 17, 2008
Messages
2,380
Location
North Weald, Essex
Car
Insignia VXR 2.8t (2017) SuperSport, AWD, eLSD / Gone :( CLK320 CAB (A208) 02
I work in IT so I see ethical hacking as a good thing and often do it myself. Sometimes the only way to know your secure it to try and break in. But, what these hackers achieved is quite worrying. Unsure how Chrysler got away with not doing a recall.


Hackers Show They Can Take Control of Moving Jeep Cherokee - WSJ
 
Just one more reason why self driving cars will not become a reality...thankfully.
 
Just one more reason why self driving cars will not become a reality...thankfully.

I think they're inevitable.

But I think perhaps 20 years for them to become prevalent. And some time after that to become mandatory in designated urban areas/routes and on motorways.

Consider that the population density of areas such as the SE England is increasing quite rapidly (say 50% in 25 years) - if self-driving cars allow higher traffic density without loss of speed/safety then they are an obvious solution.
 
All systems that are connected to the internet are potentially hackable. I don't know why anyone would be more worried about cars being hackable than, say, power plants or defence systems.
 
Just one more reason why self driving cars will not become a reality...thankfully.

Hi,
They are effectively here already - just take a look at the Distronic+ system with the automated steering that is available on current Mercedes models and the extra enhancements coming on the new E class.
You set the speed - car accelerates and brakes itself according to vehicles in front, either keeps between white lines or follows line of car in front, uses GPS and speed limit signs to check whether within limit.
Thus is all now!!
Cheers
Steve
 
All systems that are connected to the internet are potentially hackable. I don't know why anyone would be more worried about cars being hackable than, say, power plants or defence systems.

Cars are consumer grade cr*p.

That said it's astonishing if they have not isolated the operational systems of the car from the externally accessible systems.

The biggest risk to defence and critical infrastructure - which use isolated networks - is more likely to be insiders who have authorisation to access the inner isolated networks and either use that access to introduce malware (deliberatelt or inadvertently) or to extract sensitive information.
 
The software for cars tends to be far and beyond the complexity than credit is given for it - It's been researched that high-end cars have 100 million lines of code and beyond (not sure what "high-end" is defined as but I'm guessing it means more MB/BMW than Dacia) - Granted this includes everything beyond the non-critical systems, including the entertainment system, but still, it does highlight the complexity involved. See graph below.

If an industry-average consumer-grade vehicle hits 15-50 bugs per 1,000 lines of code, then that is 1,500,000 to 5,000,000 bugs of various degrees across your car electronics. Scary biscuits, eh? Let's just pretend they achieved a clean-room level of bugs and only hit 3 defects per 1,000 lines, then that's still 300,000 bugs.

On the upside, most of these will probably be "dark corners" and weird edge cases that get hit with an very small probability - The most crucial systems are likely VERY well tested with many many layers of fail-safe and self-check diagnostics (think "limp mode" and you're not far off it).

But yes, the more lines of code, the more likely bugs are present - Bugs equal attack vectors that hackers, ethical or otherwise, can exploit. Although given the likelihood, you're more likely to experience glitches and gremlins than have someone maliciously disabling (or controlling) your car, for now anyway.

Still, the next time you have a gremlin in your car ... Spare a thought for the programmers and testers of those systems. They're probably getting it in the neck as you read this for high severity bugs that are deliciously difficult to find and fix. ;)

Que not-so-random and illuminating graph:

1276_Codebases.png


Source: Million Lines of Code | Information Is Beautiful
 
Last edited:
The software for cars tends to be far and beyond the complexity than credit is given for it -

There's signficantly different types of software.

As regards bugs - it's not really lines of code that are significant but the number of paths and the amount of state that his held. (Over the years there have been different ways of trying to define this complexity - most have focused on measuring the code rather than the state - because the code is static and easier to analyse).

The critical embedded stuff tends to be more constrained and conservative than the GUI based entertainment and nav stuff.

A figure of 15 to 50 bugs per 1000 lines of code isn't meaningful or realistic.

Typically the low level critical systems will have fewer issues. They're simpler in terms of amount of I/O, code and state, more containable, more critically designed and tested, and more conservative.

OTOH at the other end of the spectrum the entertainment system - interfaces with a human vai some sort of UI, loads of garnish, and needs to talk to third party media and comms systems, and handle the interface to other options - cameras, additional entertainment (TV, rear screens, connected services + internet).

Still, the next time you have a gremlin in your car ... Spare a thought for the programmers and testers of those systems.
The usual issue isn't bugs but the complexity of the systems making the underlying problems very obscure.

In the old days somebody could fix a fridge by playing with the compressor and a thermostat and temperature probe. These days there may be multiple probes and fans - and multiple control states. The poor technician has a lot more to figure out unless they get useful (and truthful) diagnostic help from the control system.

Same goes for cars. A simple electrical starter motor problem may be diagnosed as a sensor or ECU problem and consume many technician hours before somebody twigs what might have been obvious from the outset a couple of decades ago.
 
I don't disagree with any of that Dryce and that more or less aligns with how I think about software - Much of what I stated was a simplification and was meant to be more tongue-in-cheek (most of this is only interesting to those in industry already afterall), but I think I did state similar points about critical versus non-critical systems, conditional/branching coverage (edge cases), and the accessibility issues of embedded systems. What I might have failed on was adequately describing it, but then I did always fall short at English in school. ;)
 

Users who are viewing this thread

Back
Top Bottom