General STS thread

[kevm14]

They dont sell software because only 3 people would buy it. Not because you can't modify the PCM.

I was operating on the assumption that if someone had in fact "hacked" my ECM, it seems like it would be someone who could actually profit from it, rather than someone hacking for fun or whatever.

You take over the radio (IPM) and have it do whatever you want. Better yet, take over the OnStar module remotely so you don't even need to be near the car.

Like that FCA thing. They did exactly what I'm talking about and took over multiple modules and disabled that Jeep remotely.

I'd like to see it done. I want to see how much effort it would take. I am not sure where the STS falls on the vulnerable scale. Look at my Roadmaster. It's got early GM LAN for practically nothing at all. You couldn't do anything with it. You can flash through the DLC but you know how long that takes. Not practical.

And then the FCA thing - I'm going to say, without any evidence, that that vehicle has a generation or two newer architecture that looks much more like modern computers and networks. I feel like that significantly increases the chances of starting with a massive off the shelf advantage in terms of tools, known entry points and stuff like that.

So where would my STS fall? If we focus on the attack vector in question, nav head firmware, you'd have to know some things about that to say how vulnerable it actually is. How big is the firmware? It's not like it is a general purpose computer with a lot of compute resources. Rather you are probably flashing a specific firmware on a specific controller. It is the firmware inside of a nav unit, and I don't think all of it is even flashable. I'd like to see if it would even be possible to flash a firmware in there, have it go successfully and otherwise not indicate that anything suspicious has happened, and then "take over" the IPM so that you could potentially control the high speed network. The car probably wasn't built for cyber resiliency (nor am I sure it needed to be), but how possible or easy is it? The car already has some level of detection/failsafe when modules don't communicate properly.

What is also possibly an important detail is that the nav firmware is updated via disk. Unlike ALL other modules in the car, I suspect the firmware itself is pretty isolated from the actual GM LAN. In fact I would be surprised if you could actually get from a hacked nav firmware to the low speed LAN at all and if not, that is a 100% firewall. Even if the firmware had a path to the IPM, it would have to actively launch an attack on it and "take it over" by means of modifying its executed code (via low speed network side). Is that even possible on my IPM? It is not a general purpose computer or network device with an IP address.

If we were talking about a module flashed via DLC with firmware from a questionable source, I guess that would be more interesting since those bits are by definition already touching the network. The nav firmware update has nothing to do with the network. In theory, you should probably be more concerned about plugging in a scan tool from China to the DLC (no I'm not concerned about my Tech 2 clone). I do not think it is at all equivalent to plugging an unknown USB device into a protected network.

Now we could talk about GPS spoofing firmware and stuff but for car applications, and since my car has no self driving or anything like that, also a non-starter in my opinion, at least as far as my actual care factor. Even if you compromised the IPM, I'm not sure it has the ability to actively simulate network traffic from another module. Best you could probably do is cause the equivalent of a high speed network storm and render the car undrivable. Also, the OnStar module has its own GPS receiver anyway, at least 99% sure. I do not think the OnStar module receives GPS and makes that available on the network. The STS is just too old for that kind of stuff (at least based on car network sophistication). My point there being that the nav system firmware and the OnStar module have nothing at all to do with each other, other than they use different GPS sources to accomplish different things.

My STS may be "fancy" but modern stuff is FAR more integrated and vulnerable imo. Like Bill's Camaro even. Someone should research Global A and see what that architecture looks like.

[kevm14]

https://vehicle-reverse-engineering.fan ... GM_GlobalA

[kevm14]

Haven't read
http://www.autosec.org/pubs/cars-usenixsec2011.pdf

Skimmed and skimmed the report.
https://www.wired.com/2014/08/car-hacking-chart/

The summary gets to my point, at least about my STS.

[kevm14]

This guy sounds like me.

Gerry • 5 years ago • edited
I have worked for PAG-Group Automotive OEMs for 13 years now (Ford, Jaguar, Land Rover, Aston Martin), in diagnostics, electronic integration and vehicle engineering. You can not simply hack into a car wirelessly by accessing Bluetooth or Wi Fi. All of the Electronic Control Units (ECUs) have signals that they share and listen to on the network and safety critical ones are protected by checksum bytes, update counters (algorithmically encrypted), Quality Factor quantifiers and hard coded logic to ignore and weed out erroneous messages. Infotainment is on its own fibre optic network and the signal definition netfiles mean the source address of the signal has to be correct as well as the content of the message or it will be ignored. Messages to request torque or braking may be recieved but they can also be rejected if inappropriate. All diagnostic functions are locked out without a security unlock seed/key and even so actuation of practically every single powertrain and braking function is rejected if vehicle reference speed is anything other than zero.

In-car networks don't operate using TCP/IP (yet- that I know of) and an ECU is not a server that you can crash and get root access- these concepts do not apply to an ECU using its own proprietary operating system. You can't reprogram them, you can't force them to change their behaviour. You might be able to try and spoof them but not without a physical presence on the vehicle and even then, for all of the reasons I state above, you would be ignored anyway. You can't access the source code and alter it. ECUs do not work like regular computers.

So in my experience with all of those brands, this 'hackers may take over your car wirelessly' is utter nonsense scaremongering. If you were connected to the DLC socket (OBD2 port) the worst you could be able to do is crash the network which will simply result in limp-home mode (locked in one gear, maximum torque limited so you won't be able to exceed a certain speed) until you cycle the ignition state and the network reinitialises.

There's a lot of crap spoken about hacking cars and I'm sick of it.
/rant over.

Hey, even if he's wrong (he doesn't have any FCA credentials so there's that), I'm perfectly fine with sounding like an experienced automotive engineer.

[Adam]

The system wasn't designed to be remotely exploitable.

No shit. FCA didn't didn't plan on people remoting into their vehicles and killing the engine. There was a series of bugs in some specialized electronics talking a communications protocol that was designed before security was a concern. Some very talented people leveraged those to do the stuff the article talks about.

The Jeep exploit duo has been doing this sort of thing for years, so an exact start to finish number isn't really possible to come up with. With sufficient prior knowledge, a qualified research team should be able to pull something like this off in 6-24 months. You see this sort of thing every year at PWN-2-OWN, CCC, and Black Hat. And those are usually the good guys who responsibly disclose their findings.

I'm not arguing that the STS is more or less exploitable than anything else, you said you were getting head unit firmware from the internet, what could possibly go wrong? So I answered that question.

There probably isn't a general market for exploiting the GMLAN system in your STS, unless what you find also carries over to other vehicles or you are explicitly targeting that platform for some reason.

Has this thread been sufficiently derailed?

[Adam]

I have worked for PAG-Group Automotive OEMs for 13 years now (Ford, Jaguar, Land Rover, Aston Martin), in diagnostics, electronic integration and vehicle engineering. You can not simply hack into a car wirelessly by accessing Bluetooth or Wi Fi.

The article you linked talked about making a Ford Escape's brakes not work. Granted it was from in the car, but that's just an exploit chain away from being triggered remotely.

All of the Electronic Control Units (ECUs) have signals that they share and listen to on the network and safety critical ones are protected by checksum bytes, update counters (algorithmically encrypted), Quality Factor quantifiers and hard coded logic to ignore and weed out erroneous messages.

Yes, all the checksum computation and counter verification is guaranteed to be implemented 100% correctly and in a way that can't be spoofed. It is definitely tested against every possible combination of inputs so it is a completely deterministic system. There's no way someone could compute their own checksum on a malicious command.

Infotainment is on its own fibre optic network and the signal definition netfiles mean the source address of the signal has to be correct as well as the content of the message or it will be ignored.

Either "no it isn't" or "yes it is, but that network is connected to another network". There's no way someone could put the wrong source address on a message.

Messages to request torque or braking may be recieved but they can also be rejected if inappropriate. All diagnostic functions are locked out without a security unlock seed/key and even so actuation of practically every single powertrain and braking function is rejected if vehicle reference speed is anything other than zero.

We've definitely classified every inappropriate message for every situation. There's no way our unlock seed/key has escaped our control. There's no way any of the sensor inputs could be wrong or provided by something else.

In-car networks don't operate using TCP/IP (yet- that I know of) and an ECU is not a server that you can crash and get root access- these concepts do not apply to an ECU using its own proprietary operating system.

Because TCP/IP is the only network protocol. There's no way a proprietary operating system can be exploited. The fact that is listening for command messages on a network, decoding them, and executing functions in response makes it nothing like a server. Servers definitely don't do that.

You can't reprogram them, you can't force them to change their behaviour.

They definitely don't apply module firmware updates at the dealer every time you bring your car in. Those updates definitely don't write new firmware to the modules. This act definitely doesn't change it's behavior, like adding Android Auto to cars that already support Car Play (a thing Toyota is literally doing to almost all their cars right now).

You might be able to try and spoof them but not without a physical presence on the vehicle and even then, for all of the reasons I state above, you would be ignored anyway.

Because the presence of messages on a network indicates you have physical access to the network.

You can't access the source code and alter it. ECUs do not work like regular computers.

There's no way to decompile the binary firmware blob and get assembly language out of it. Or C. No one knows how to determine the function of software from that. There's no way you could look at the PCB in one of these things and figure out what type of processor it contains. There is definitely not documentation for those processors freely available from the vendor websites fully documenting the processor architecture and ISA complete with sample code.

So in my experience with all of those brands, this 'hackers may take over your car wirelessly' is utter nonsense scaremongering.

Charlie Miller did it several years ago.

If you were connected to the DLC socket (OBD2 port) the worst you could be able to do is crash the network which will simply result in limp-home mode (locked in one gear, maximum torque limited so you won't be able to exceed a certain speed) until you cycle the ignition state and the network reinitialises

Or make the brakes stop working.

Is my sarcasm density sufficiently high?

[kevm14]

Yeah it does seem like some of the stuff he says is impossible was exploited at least on that Jeep. On the other hand, he posted that like 5 years ago and was likely speaking from experience from perhaps the late 90s through the 2000s. With that as context, a lot of what he says is likely true, for that time period, but doesn't present a credible argument against the Jeep thing.

I think my personal conclusion is more or less valid. My STS is technically more vulnerable than a 90s vehicle but considerably less than stuff in the 2015 range (the later STSs did have some cyber-physical systems, though the only true item may be the active steering - lane keeping I think was all passive at that time, and ACC was available back to 05). I'm guessing that going forward security will improve. GM certainly indicated that considerable time and care was given to cybersecurity for their new architecture with OTA updates. I wonder how secure Teslas stuff is. You'd think being Silicon Valley based it would be good but I don't think that guarantees anything.

Analysis of Automotive Networks 2.PNG (19.82 KiB) Viewed 788 times

Defending against remote attacks.PNG (41.35 KiB) Viewed 788 times

Analysis of Automotive Networks conclusion.PNG (15.2 KiB) Viewed 788 times

Some have questioned the fact that the article concludes with a device you could buy but I think that's an overly cynical interpretation. I don't think anything is for sale. What they are suggesting is just an example of how you could monitor for bad traffic and is not out of line with anything I understand to be good practice, or at least part of the solution.

[Adam]

I agree with you.

Remember, though, you asked what could possibly go wrong.

[kevm14]

Yes. I think that meant "what's likely to happen."

[kevm14]

So I switched to Rain-X windshield washer fluid because I was at Walmart and realized I can get premium fluid for the cost of regular fluid everywhere else.

As expected its use provides some Rain-X type water beading on my windshield. What was unexpected is its impact on automatic wiper operation.

I guess because of the way the water beads and flows around the windshield, it has an effect of making the auto wipers seem more sensitive. Previously I found I had to either increase the sensitivity one notch in heavier rain, or just give up on auto and flick it to low speed. With the Rain-X, the wipers much more effectively controlled themselves on my way into work today, spending a surprising amount of time in low speed (which was extremely rare before).

So I don't know exactly why this is but the bigger water droplets and/or the water flowing up the windshield while driving seems to make the sensor see more rain and run the wipers on higher settings than before. This is good. I'm guessing that with Rain-X applied, the water beads closer to how it might have on a brand new windshield, which is how the system would be calibrated.

I guess for those of you who have auto wipers...try Rain-X windshield washer fluid, or just Rain-X your windshield I guess.