|
Some of you mighta seen this in the monthly chat -- I bought a red 2014 SRT that was supposed to have the Grand Touring package, which has the dual mode electronic suspension and the GTS hood. There were 3 failures in the chain: - somehow, the factory didn't build it that way, and no amended window sticker ever made it to the dealer. Maybe a fixed sticker never left the factory. - the "Viper-trained" sales guy didn't spot the hood difference and didn't know how to activate the dual mode suspension. If he had, he'd have seen right away that the buttons were missing off the console - I was irresponsible about knowing all of the details of the car I was buying and assumed that if it was on the sticker, it was on the car. FCA gave me 2 options: - check for the missing options, which I could use on a few aftermarket suspension options - full buyback, which is what I went for Today, their 3rd party finalized their proposal, which is 100% of what I paid, including taxes and financing. So $0 deduction for any mileage I put on it, which is nice. I bring it in into any Chrysler dealer, they look it over for damage, with reasonable leeway for scuffs, chips, etc., and if they ok it, they hand me the check from FCA. Unlike DV, because my car didn't experience a failure covered under warranty, I wasn't eligible for exchanging my car for MSRP-valued credit. If I were, I think I would have custom-ordered one, because MSRP is way more money than what I paid. Instead I'm gonna take the check and probably deal with ViperExchange to get their new replacement dual mode suspension package, which is derived from their racing program. I just need to sit until the right base Viper comes along. Since I've had the car, I've concluded that: - red is an awesome color, though the attention is a bit much. Very few people noticed the black Z06. - everything about the Viper needs to be vulgar, so 6-vent SRT hood is way cooler than the 2-vent GTS hood. My friends are trying to convince me to do a farewell burnout before turning the car in, but I'm a little scared to.
|
#
?
Jul 22, 2015 19:44
|
|
|
|
| # ? Apr 28, 2024 11:33 |
|
|
Wow, thanks for that, that completely disproves what the alleged FCA engineer I was talking to said. He may have been talking about a different vehicle, I guess... I'm going to go with trusting the article for now. LIN bus is another fun one. It is significantly simpler and smaller, all transactions (read and write from anything to the master) are arbitrated by the master node, there is only one master node and up to (iirc) 15 or 31 slave nodes. It's more used for things like wiper motor controllers, seat position controllers, etc that don't need much in the way of smarts. Actually, a perfect example is the wiper motors in a new-gen Focus. There are two of them for the front instead of just one, with none of the traditional linkages. The left wiper motor has a LIN bus interface and the two wiper motors are slaved together via a synch wire that they use to communicate and synchronize their motion. The motors are each smart enough to stop if they see an overload condition, return to home automatically, and wipe speeds and swept angle can be configured at production time. I looked into using them but they're too heavy for our application. Here's the press release: http://www.bosch-presse.de/presseforum/details.htm?txtID=4979&locale=en And the datasheet, which includes the LIN bus commands needed to run the motor, with a tantalizingly large number of empty/reserved data fields that I suspect contain the configuration commands: http://www.bosch-motorsport.com/media/catalog_resources/Wiper_Direct_Actuator_WDA_Datasheet_51_en_2785939211pdf.pdf I'm really quite tempted to swap a set onto the 5 ton because the vacuum powered wipers SUCK.
|
|
#
?
Jul 22, 2015 19:46
|
|
|
IOwnCalculus posted:So both have a CAN C and a CAN IHS, and it seems like most of the stuff that you'd be majorly worried about is on CAN C. In the Cherokee, the radio is connected to both C and IHS. In the Viper, it's connected to just IHS and the BCM is the only thing connected to both. (Both vehicles also have a 'LIN' that seems to be fully separated from everything else). So to do this attack on a Viper, you'd need to hack the radio, then use it to hack the BCM, and then you'd have full control. Whereas in the Cherokee, if you hack the radio, you can send commands directly to both busses. There's another layer of problems here, though, too - if the radio trusts an external source (like the update server, or remote customer service, dealership techs, etc), and fails to appropriately validate the identity of that external source, you can simply MITM those connections and access everything hrough the default administrative pathways. From there, it's a matter of attacking the configurations on the individual busses - but those busses were probably created with the expectations that the administrative pathways are trusted, so there's unlikely to be any controls preventing someone manually spoofing a command that tells the car it's actually moving at 3MPH and all wheels are locked up and it needs to fully engage the ABS systems now, meaning the driver has lost all braking force. Basically, if each component isn't individually responsible for validating input and output, and has no way of defending itself/failing securely or notifying anyone if something is happening, then eventually someone's gonna figure out how to wreck everything, due to the number of holes in the platform code, without even addressing the code that is custom to each vehicle. Without some form of logging and monitoring that someone can evaluate, you have no way of detecting attacks, and it's been well validated that any security controls or system is breakable given enough analysis, expertise, and time. Failing secure can also have really nasty consequences in a car platform as well - if the fly by wire is getting spoofed, is it acceptable to simply disable the throttle to prevent malicious inputs? What about if the computer can no longer detect if the wheels are sliding, is it better to disable the ABS system or let it engage? What if the computer doesn't even know it's not detecting actual wheelspeed anymore? It's a nasty, complex problem. The other issue is that doing all of that stuff also has a heavy influence on the development cycle without significant work - if your code is broken, is it because your code sucks or the security controls are preventing you from doing it? If the security controls are preventing you from doing it, are you violating the security guidelines or is it just that the security was implemented incorrectly? And then someone turns off the security controls for testing and development, the feature works, timelines get crunched, and turning the controls back on or testing them drops off the bottom of the task queue to meet the deadlines. And that's the story of literally everything developed ever, with a handful of exceptions that essentially prove the rule. Z3n fucked around with this message at 20:29 on Jul 22, 2015 |
|
#
?
Jul 22, 2015 20:27
|
|
|
Z3n posted:While you can absolutely design secondary networks, firewall, segment, etc, all of these things are still subject to the same core problem that we build these systems with stacks of code on code on code that no individual has evaluated or understands as a comprehensive whole. There are only a tiny minority of folks who could be reasonably trusted to write secure code, fewer who can securely architect systems in a way that meets business goals, and the number of those people who are not currently employed by the tech or gov sectors is basically zero - baseline salary for these people is in the hundreds of thousands of dollars plus likely millions in stock, and I don't think the auto industry is at the point where they're ready to pay that kind of money, nor would they see the value in it. Some of these things are simple to implement if someone bothers to rub a few brain cells together. One-way data links for example. Almost any type of network connection that supports broadcast traffic (or is always effectively broadcast as is the case in a lot of bus-type networks) can be made one-way by simply not hooking up the transmitter on the insecure end (or the receiver on the secure end, depending on which is easier). Ethernet, K-Bus, CAN, the principle works the same on all of them. You don't need rocket scientists, just an awareness of the problems and a bit of caution. For situations where two-way communication is required it gets a bit harder, but it's still not that big of a deal. In whatever addressing format your network of choice uses, make sure everything the insecure devices need to talk to are within a certain range that can be masked. Put a hardware device in the path that filters any traffic not matching that mask. All "secure" endpoints for example could be put in the top end of the address range, so any traffic from the insecure side with the first bit of the address set to 1 gets dropped. Basically the people designing these systems should really just have a meeting with their corporate overlords' network security team. A one-way link is almost the same as a passive network tap (commonly used for intrusion detection systems or network troubleshooting), and bitmask-based address filtering is one of the simplest tasks a hardware firewall does. No one needs to be an expert in security, they just need to think about it in the slightest. Putting an internet connected computer directly on the chassis bus as shown in the images IOC posted is not even trying.
|
|
#
?
Jul 22, 2015 20:28
|
|
|
wolrah posted:Some of these things are simple to implement if someone bothers to rub a few brain cells together. One-way data links for example. Almost any type of network connection that supports broadcast traffic (or is always effectively broadcast as is the case in a lot of bus-type networks) can be made one-way by simply not hooking up the transmitter on the insecure end (or the receiver on the secure end, depending on which is easier). Ethernet, K-Bus, CAN, the principle works the same on all of them. You don't need rocket scientists, just an awareness of the problems and a bit of caution. This is really simple in concept but really difficult in execution. For example: How do you handle an attacker spoofing excessive legitimate traffic? 3mph is just as valid an input as 75mph, but in one situation it's going to kill you and in another it's completely harmless. Same with wheelspeed sensors. How do you fail when you detect malicious values? What is a malicious value, when, and how do you independently validate that when you can't establish trust in the system? What stops someone who has access on the bus from simply spoofing the address range? Basically, half the controls you talk about just involve knowledge of the design of the system to defeat, and the other half are vulnerable to basic attacks such as spoofing or flooding which lead to an attacker being able to introduce enough noise into the system to render good data lost in the noise, achieving their goals anyways. Part of the reason we're in this situation is because people think that the problems are "simple" without considering the massive stack of edge cases and problematic behaviors that are trivial for an attacker to perform and very difficult to defend against, because you have to have some form of validation that the traffic you're getting is actually legitimate, which involves not trusting your sensors without independent validation. The reference here is to aviation software design redundancy principals of multiple independently developed systems that require validation of error states from independent subsystems before they report errors. But that's incredibly expensive and totally unrealistic to expect in generic car design #901238. Here's the thing, if you're putting an internet connected radio and supporting computer in a car, it's going to be possible to own you through that thing, full stop, regardless of the design you have in place. The best you can hope for is to make it somewhat more difficult, and if I'm being completely honest, IMO, it's an acceptable level of risk for it to require 2 dedicated researchers 3+ months of time on this individual platform to develop functional exploits for it, especially considering they've been working on these problems for years. The number of platforms they can develop for is relatively limited and time consuming - this is far better than many industrial control systems we have currently connected to the internet right now. Most of that is due to relative obscurity of the platform design, requiring a bunch of reverse engineering work, but that's enough of a high bar to entry to keep it out of the realm of kids swatting someone, which is the current bar for people killing someone on the internet. Z3n fucked around with this message at 20:52 on Jul 22, 2015 |
|
#
?
Jul 22, 2015 20:42
|
|
|
wolrah posted:Some of these things are simple to implement if someone bothers to rub a few brain cells together. One-way data links for example. Almost any type of network connection that supports broadcast traffic (or is always effectively broadcast as is the case in a lot of bus-type networks) can be made one-way by simply not hooking up the transmitter on the insecure end (or the receiver on the secure end, depending on which is easier). Ethernet, K-Bus, CAN, the principle works the same on all of them. You don't need rocket scientists, just an awareness of the problems and a bit of caution. A lot of good ideas in here... the address partitioning is interesting but probably easier said than done, BTW. Especially since companies like to keep their messageIDs/addresses the same as long as possible so their codebase can mature and not get hosed up by someone changing everything willy nilly, and there are also a lot of third party / contracted-out control units involved. For example Bosch, KSS, ATe, and Teves do probably 95% of the ABS/ETC/ESC hydraulic systems on the planet between them, and companies like OpenSynergy are known for doing infotainment unit OSes - including some really nifty hypervisor based setups I've looked into using. A lot of those are going to be using a semi standardized set of messageIDs that the company already chose. Gluing it all together is enough of a mess without trying to change every messageID to make them fit your partitioning scheme, especially when if you build your bridge unit intelligently and make the firmware read-only and fairly easily validated, it's really not too hard to keep high priority/safety critical commands from going one way while allowing everything the other way. Shouldn't even really need that powerful of a microcontroller, quite honestly. It's just that as Z3n (and I) have said a few times in the 3-4 threads this is being discussed in (at last count  ) - this is all thrown together far quicker than we can catch up security wise. It's a Hydra of security holes, for every one that someone manages to find and patch, another ten or 100 are introduced.
|
|
#
?
Jul 22, 2015 22:35
|
|
|
wolrah posted:No you can't. For ABS to be able to do its job it has to be able to release brake pressure being applied by the driver. Any functional ABS can theoretically disable the brakes as far as the driver's concerned. You can. Older ABS has error loops you can exploit depending on the ABS supplier- there's nothing particularly smart nor complete always overriding about older separate ABS controllers - And I'm not just talking about pulling the ABS fuse either. The issue is with the newer ones that interconnect with traction control and stability systems or more. quote:It's just that as Z3n (and I) have said a few times in the 3-4 threads this is being discussed in (at last count ) - this is all thrown together far quicker than we can catch up security wise. It's a Hydra of security holes, for every one that someone manages to find and patch, another ten or 100 are introduced. Dont put the access in there in the first place. There, done. And if you want a system that has wireless, air gap it from the other car subsystems. Frankly all the subsystems need is a power signal to come on and the main system can do that quite well without resorting to ridiculous levels of network interconnect. Obvious, easy, cheap, secure.
|
|
#
?
Jul 23, 2015 02:55
|
|
|
YOSPOSter Heresiarch wrote this in one of the Security Fuckups threads and it's relevant to this conversation: https://docs.google.com/document/d/12xsw81HZnGRpbrrWtVksHi2gbwyVWyeQm0edsZvt_k0/edit?usp=sharing
|
|
#
?
Jul 23, 2015 03:20
|
|
|
^^^ yeah this is quite relevant. CAT INTERCEPTOR posted:You can. Older ABS has error loops you can exploit depending on the ABS supplier- there's nothing particularly smart nor complete always overriding about older separate ABS controllers - And I'm not just talking about pulling the ABS fuse either. The issue is with the newer ones that interconnect with traction control and stability systems or more. You're looking at this from the wrong perspective. The attackers are doing exactly what you're talking about here - they're overriding the ABS controller to essentially engage it at full "antilock" capability, robbing the driver of the ability to use the brakes maliciously, rather than doing what ABS normally does which is stops the driver from using the brakes when they overdo it. They're just moving the needle on "overdoing it" to a place where the brakes stop working entirely. The system can't be separated because they're tied into the core of the car itself - proper antilock activation, speed dependent lockup prevention, safety checks, etc, is essential to the car meeting government standards for safety, and adding more systems to replicate that sort of functionality is adding significant additional complexity, reducing reliability and increasing the chances of a failure. Do you really want to have to maintain 3 individual but identical wheelspeed sensors, for your gauges, your ABS, and your traction control system because you're trying to isolate individual systems? Oh, and you're also going to need 2 pumps now too, because your ABS pump and your TC brake application pumps can't be shared. Down this pathway lies madness. quote:Dont put the access in there in the first place. There, done. And if you want a system that has wireless, air gap it from the other car subsystems. Frankly all the subsystems need is a power signal to come on and the main system can do that quite well without resorting to ridiculous levels of network interconnect. Obvious, easy, cheap, secure. This is an exceptionally simplistic view that doesn't hold up to any sort of reasonable scrutiny or real world application, such as testing for failed subsystems, maintaining a reasonable number of sensors, meeting automotive standards for design, etc. etc. etc. And a system that is wireless that is airgapped from all other car subsystems is pointless - the whole reason is to allow legitimate remote access to help drivers with emergency services, monitor car trouble, update firmware, etc. The attitude of "disable functionality until it's secure" is one that the security community has harped on about for years unsuccessfully, because it's standing in the way of progress rather than figuring out how to progress with a reasonable approach to the risks. The reality is that perfect security is impossible, attempting to achieve perfect security gets you useless software and hardware, and you need to balance the risks against the rewards. In this case, exploitation is difficult, requires a high degree of technical skill, and is not broadly applicable across individual platforms without specialized work, and that means the risks are relatively minimal. It's something automakers should fix or make more difficult, but it's also something that's will kill fewer people than have died from normal auto accidents in the amount of time it takes us to write these posts over the next 10 years. This is really not a big deal overall, it's just a symptom of a continued, worrying trend, that's likely to get a bunch of hamfisted regulations slammed down our throats that are going to damage legitimate security work far more than help us fix these issues. The field of offensive vs. defensive security at the moment is essentially laser guided missiles against forts with wooden walls. If you're willing to expend enough resources, you can build a fort that will stand up to a lot of missiles, but ultimately, the defenders operate at a huge handicap by default. Part of the problem is people thinking that less functionality is a realistic fix in a world that demands more functionality. Z3n fucked around with this message at 03:53 on Jul 23, 2015 |
|
#
?
Jul 23, 2015 03:47
|
|
|
One potential solution, as I see it, is cryptographic. Give every device on the intra-car network a unique public/private keypair, and install the public keys for each device on every other device in the car from the factory. Each vehicle becomes its own web of trust. Pro: You can't replace the radio firmware to send commands to the ABS unit. Con: You have to remove and install keys on every networked device in the car every time you swap a networked device, which would necessitate a trip to an authorized service center. Edit: or, you could pop the EEPROM where the keys are stored out of the old unit and into the new unit. drat that would be easy. "But couldn't you read the private key for, say, the BCM and use that to spoof BCM messages?" Well yeah, but only on that one car! Safety Dance fucked around with this message at 18:56 on Jul 23, 2015 |
|
#
?
Jul 23, 2015 17:36
|
|
|
That's not what crypto is for and doesn't even stop the attack.
|
|
#
?
Jul 23, 2015 19:39
|
|
|
SperginMcBadposter posted:That's not what crypto is for and doesn't even stop the attack. Yes it is and yes it does. Let's say, for example, the BCM sends a message to the wipers, telling them to activate. The BCM cryptographically signs the message using its private key. The wipers have the BCM's public key installed, and can verify that the message came from the BCM. Now, let's say the infotainment system received a malicious OTA update that causes it to try to spoof messages from the BCM, telling the wipers to activate. The infotainment system does not have the BCM's private key, so it cannot sign the message.
|
|
#
?
Jul 23, 2015 19:56
|
|
|
The bcm isn't between the radio and the can bus on the jeep though, so no it doesn't stop the attack.
|
|
#
?
Jul 23, 2015 20:01
|
|
|
Safety Dance posted:Yes it is and yes it does. Do you want $1,500 wiper motors? because this is how you get $1,500 wiper motors.
|
|
#
?
Jul 23, 2015 20:02
|
|
|
I don't necessarily mean to continue the hijack here, I quite enjoy the Laguna Seca videos. I've been meaning to effort post here about the UI stuff but (funnily enough) I've been running around lately dealing with the hack you guys are talking about. Obviously I have to use a lot of discretion when talking about this kind of thing, but the short and skinny of what happened here is a complete breakdown of defense in depth. There were a few small vulnerabilities (and one BIG one) that allowed them to do what they did. I'll wait until official reports come out to talk more specifically, but essentially there was a version of the VP3/4 firmware that was released that listened for incoming connections on a non-standard port. The radio would allow bindings for a certain application protocol that allowed external access to the unit. This was the big security vulnerability that enabled the whole thing. Again, waiting for the official statements, but the affected port(s) have been blocked on the network side of things, and for now they would not be able to exercise this vulnerability from the network again. I have no idea how they gained access to the CAN microcontroller on the radio, though. That, in my opinion, is the hardest part of this and I'm glad they're not going to publish how they did that. I have no idea how that version of firmware passed quality control. I'm guessing somebody is getting fired over this one. The good news is that none of the stuff that my team built was a part of the break we're smarter than that, we get our stuff pen tested! We're actually drafting a statement right now basically saying "it's not our fault" with FCA's concurrence. But this is all pretty bad. It just sucks that it happened to the solution I'm involved with.There are actually proposals for CAN security, but it's tough to get automakers to change something like CAN that's been around forever. I read and reported on a proposal from an academic journal a few years ago proposing the use of CBC-MAC (cipher block chaining with message authentication code) with CAN messages. It would certainly make this type of exploit much more difficult at the vehicle network, but it'd also have pretty major implications for aftermarket device manufacturers. Here's a nice write-up illustrating some of the considerations: https://kabru.eecs.umich.edu/papers/publications/2013/manuscript_ICCPS_rev1.pdf. On pretty much every FCA vehicle I've worked with, the radio sits on both the CAN-I (interior) and CAN-C (powertrain) busses. On the UI front, at the very beginning of the generation of radios (VP3/4), sometime in 2012, the radio manufacturer integrated a proprietary Java virtual machine as the application framework. That version of the JVM was essentially a beta version from the supplier who wrote it. The supplier was never able to get the radio manufacturer to integrate a production-ready build into the overall firmware build. The entire UI framework is built on top of LWUIT, but the version that eventually made it to production didn't properly integrate UI transformations. This really isn't a big deal for most of the Uconnect apps (Storefront, via mobile, Assist) - they're all relatively static pages with very well-defined page transitions. But the Performance Pages app is a completely different story. When the application renders a page, there are generally multiple gauges associated with that page - it's even worse now if you go drive a Hellcat Challenger or Charger since they have boost gauges. So whenever any of the CAN datapoints changes, it has to repaint the entire gauge rather than transforming existing assets. As you could imagine, this taxes both the built-in GPU and CPU pretty heavily. And it's super slow since it's constantly dipping into RAM (and sometimes even flash storage) instead of caches. This is sort of a high-level look at the problem - I'm actually not a Java developer by trade, I just work with them every day. There might even be some creative ways to work around the problem. I'm leaving the company shortly so I've sorta checked out from all of it anyway v  v
torb main fucked around with this message at 20:19 on Jul 23, 2015 |
|
#
?
Jul 23, 2015 20:15
|
|
|
SperginMcBadposter posted:The bcm isn't between the radio and the can bus on the jeep though, so no it doesn't stop the attack. Well yeah, dingus, I'm not saying "re-jigger the Jeep", I'm saying "replace CANbus with a different protocol that works".
|
|
#
?
Jul 23, 2015 20:17
|
|
|
Safety Dance posted:Yes it is and yes it does. Powershift is right. This is using a nuke to solve a problem that a hammer will do perfectly fine for. There's no reason to make poo poo so you have to install crypto keys and "learn" each device to the network you're putting them on here. Hell, we all (rightly so) mock companies who do that, like Cat Interceptor's mate's commo fuel pump adventure and LR/BMW's obscenely complicated "must install and use factory scantool to learn each device to the network" nonsense. That's how you end up with a vehicle that throws a fit the second one network wire corrodes or one bit gets corrupted and nothing matches anymore and it goes into what LR aficionados term "gently caress You mode". Unless you enjoy paying four figures for stuff that works perfectly fine without spending that much, and in fact we complain about spending 3 figures on as it is. We're talking about 8 bit micros with (in my case, on some of the control modules I design) as little as 16k of code storage and 1k of RAM, not something you can drop an SSL library on and laugh. e: it might be time to make a "car electrical engineer nerd blather thread" instead of derailing this one and the terrible car poo poo thread, I guess. I have been meaning to do a big effortpost about how to do a quality job wiring a vehicle, too, but haven't gotten around to it yet. kastein fucked around with this message at 20:27 on Jul 23, 2015 |
|
#
?
Jul 23, 2015 20:24
|
|
|
kastein posted:e: it might be time to make a "car electrical engineer nerd blather thread" instead of derailing this one and the terrible car poo poo thread, I guess. I have been meaning to do a big effortpost about how to do a quality job wiring a vehicle, too, but haven't gotten around to it yet. I would really enjoy reading this - both the nerd blather and the effortpost about proper wiring, as it's relevant to a lot of the bike work I do. And then Das Volk can have his thread about lucky #13 back. Alman posted:*a good post* Interesting, thanks for sharing 
Z3n fucked around with this message at 23:39 on Jul 23, 2015 |
|
#
?
Jul 23, 2015 23:33
|
|
|
kastein posted:e: it might be time to make a "car electrical engineer nerd blather thread" instead of derailing this one and the terrible car poo poo thread, I guess. I have been meaning to do a big effortpost about how to do a quality job wiring a vehicle, too, but haven't gotten around to it yet. Please do, I'd love to read that. As it is, I use this for my wiring reference how-to-do-it-right-guide these days: https://www.rbracing-rsr.com/wiring_ecu.html
|
|
#
?
Jul 24, 2015 00:16
|
|
|
CAT INTERCEPTOR posted:I do have a slight clue about how many holes in software there are and how hard they are to protect - but the issue is the attack vector should never of loving happened in the first place and the ability to override steering and brakes likewise should not have existed. And actually it's very easy to defend against attack if you just simply don't have that ability in the first place First rule of network security. Packets can't cross a proper air gap. Anything that can potentially cause the car to crash remotely needs to be completely physically separate from any remotely accessible electronics. That's just common sense security.
|
|
#
?
Jul 24, 2015 00:47
|
|
|
Liquid Communism posted:First rule of network security. Packets can't cross a proper air gap. Anything that can potentially cause the car to crash remotely needs to be completely physically separate from any remotely accessible electronics. That's just common sense security. As Mencken said, for every complex problem there is an answer that is clear, simple, and wrong, and security is sadly a lot of people failing to consider the complexity of development and functionality requirements and reducing things to the simple and wrong answer. These vulnerabilities will always be present, the trick is to not leave the front door open and aggressively validate the design requirements against the security risks in a way that is meaningful to those who make the decisions: Management. If you come to them with "We need to airgap ABS systems", then you better also have an answer about how the ABS system is going to communicate to the gauges, how that's not equally insecure, how this is going to fit into the manufacturing processes, and how you're going to address the automotive regulations that apply to that system, etc, etc. And if you do manage to convince them, you better also be able to justify why you're choosing to airgap ABS in relationship to the self parking motors, and the fly by wire throttle, or someone smart is going to look at what you've said and take you to the table on not mitigating those other "significant risks", based on the security concerns you had brought to the table. In terms of actually fixing the problems? Well, step one is getting to the point where there are meaningful security guidelines for all developers, and step two is validating that you're meeting those standards in development, testing, production, and final delivery. At the very least, for every car released there should be network testing checklist along with engine testing and everything else that validates that the network connections are properly specced, listening on the appropriate ports, and validating certificates for updates/etc as required. At the very least, a late stage check like that would have caught the initial vuln that made this so compelling. Without the wow factor of "scan for car, hack it remotely", this aligns right on back down to someone hacking your car by plugging a bunch of bullshit into it, which is basically on par with someone jamming some cheap explosives in it or creatively disabling some component that causes an accident, and is an acceptable risk to folks that drive cars already implicitly.
|
|
#
?
Jul 24, 2015 04:37
|
|
|
Remote attacks are always a million times scarier; it's axiomatic that anyone who has physical access to a device can do pretty much anything.
|
|
#
?
Jul 24, 2015 05:02
|
|
|
Z3n posted:I would really enjoy reading this - both the nerd blather and the effortpost about proper wiring, as it's relevant to a lot of the bike work I do. There isn't much to tell until the Hillclimb in 5 weeks (we have a McLaren P1 registered!!!), and by the way, kimbo you should buy a car at VX and bring it I'm enjoying the update uconnect put out because It needs much more care and attention than my M3s did. Much more frequent oil changes for one, the DOT4 in it is probably not up to the task, and it even needs better dealerships. When I took it to the strip, the clutch got stiff, and the TPMS started freaking out when I drove it below sea level. I took it to a local dealer, only to find out they weren't Viper Certified, then another, same thing. The third dealership was but the tech lied repeatedly about what was wrong - claiming the clutch was gone, that the CAGS was defeated (I wish) that I'd raced and modified the car and a bunch of other bullshit. I took the service manager out to show what a liar the tech was: the CAGS was still functional; he was so loving lazy he hadn't driven the car even the requisite 5 minute warm-up to enable it. The clutch wasn't worn at all, but needed a fluid change (later verified independently,) and the TPMS issue was a broken sensor no amount of relearning would fix. While I have a written letter of apology and admittance of wrongdoing from that dealership, it won't change the fact that I should have listened to the VOA guys in the first place and taken it to the only dealer in the bay area that's known to be good - the one that did my exchange. They fixed the car in a day and a half, and washed it too! This dealership experience reminds me a lot of what I learned with GM. If you really want to run a new car into the ground and have legitimate means for a lemon law, take it to a lovely dealership that doesn't know their rear end from a hole in the ground. The first car I had, I worried that because the car was 2 quarts low on oil, I had contributed to its failure. I recently found out that the engineers looked at the dead motor, and its failure was due to a mis-machined #8 rod bearing, which apparently had happened on dozens of motors built around the time of my black car. I suppose that's what happens when you have to chase raccoons out of your factory before resuming building the great American supercar after a 3 year hiatus. I absolutely adore the car and I'm happy that I have had better luck with this one. Now that I have a reliable dealer to work with (and no mis-manufactured bearings), I think I can keep this car working for a long time.
|
|
#
?
Jul 24, 2015 05:21
|
|
|
That last half sentence had better not become the new thread title any time soon. Interesting to hear you had a tech that was allegedly certified who doesn't seem to know anything about the car you'd think they'd all be dying to learn about. When is the hillclimb? Can't wait to see video etc, especially of that P1 - I'm definitely hoping to see a in-depth comparison on the ease of placement/just how close you can get that Viper's rear right corner from that coursemarker like you did in the M3. What's the record, 1.3 mm?
|
|
#
?
Jul 24, 2015 06:14
|
|
|
you vastly overestimate the enthusiasm of a career mechanic
|
|
#
?
Jul 24, 2015 06:16
|
|
|
Das Volk posted:that the CAGS was defeated (I wish) that I'd raced and modified the car and a bunch of other bullshit. I took the service manager out to show what a liar the tech was: the CAGS was still functional; he was so loving lazy he hadn't driven the car even the requisite 5 minute warm-up to enable it. In his defense, it's almost impossible to not hit the CAGS required conditions in the Gen 5 vipers. I mean, look at this: Viper manual posted:Skip Shift is enabled when vehicle speed is greater than 16 MPH (26 km/h) but less than 18 MPH (29 km/h) and the accelerator is at 20% or less. 17mph at <20% throttle. You monster.
|
|
#
?
Jul 24, 2015 07:02
|
|
|
Das Volk posted:I'm enjoying the update uconnect put out because quote:The first car I had, I worried that because the car was 2 quarts low on oil, I had contributed to its failure. I recently found out that the engineers looked at the dead motor, and its failure was due to a mis-machined #8 rod bearing, which apparently had happened on dozens of motors built around the time of my black car. That was a big reason that I didn't take the check for just the suspension and keep the car. I didn't want to deal with the unknown state of the motor hanging over me all the time. DV's old car and mine are 50 VIN units apart.
|
|
#
?
Jul 24, 2015 07:17
|
|
|
Sounds about right  For reference: https://www.youtube.com/watch?v=muLTnZ9nwgI I simply pushed too hard into that turn. I had two options: let the car slide into the mountain, or let the mechanical LSD save my rear end. I chose the latter, and there's a video explaining it: https://www.youtube.com/watch?v=z3BKLn9yK-o The Viper has a similar setup, so we'll see 
|
|
#
?
Jul 24, 2015 07:45
|
|
|
How was your M3 in terms of maintenance and running costs (besides gas obv)? Hopefully I'll be able to consider an E92 soon enough, though it'd have to be serious decision and not a toy purchase so things like that would need to be at least somewhat reasonable. Really jello about the Viper too but there's no way I'd be able to get it here in the EU anytime soon.
|
|
#
?
Jul 24, 2015 15:11
|
|
|
Das Volk posted:I think I can keep this car working for a long time. "You Guys, I Think I'm Out Of The Woods, Part II: The Das Volk Story"
|
|
#
?
Jul 24, 2015 15:14
|
|
|
Das Volk posted:I simply pushed too hard into that turn. I had two options: let the car slide into the mountain, or let the mechanical LSD save my rear end. I chose the latter, and there's a video explaining it: https://www.youtube.com/watch?v=z3BKLn9yK-o Someone translate the video tia.
|
|
#
?
Jul 24, 2015 15:25
|
|
|
Adiabatic posted:"You Guys, I Think I'm Out Of The Woods, Part II: The Das Volk Story" That was the right comment from the right poster.
|
|
#
?
Jul 24, 2015 17:12
|
|
|
mobby_6kl posted:How was your M3 in terms of maintenance and running costs (besides gas obv)? Hopefully I'll be able to consider an E92 soon enough, though it'd have to be serious decision and not a toy purchase so things like that would need to be at least somewhat reasonable. The E92 was nigh on indestructible and only really needed oil every 7500 and diff/trans every 30k. Adiabatic posted:"You Guys, I Think I'm Out Of The Woods, Part II: The Das Volk Story" 
|
|
#
?
Jul 24, 2015 17:38
|
|
|
Das Volk posted:Not as high a price as the BMW Castrol TWS for M cars, but there's an "SRT formula" called Pennzoil Ultra. I'm not sure how it differs from other oils but there's some certification level it has that others don't. I'm taking the "early and often" option for oil changes, it's getting one at 500 miles tomorrow before we set off. Not being an oil scientist I have no idea, But if its really just "Penzzoil Ultra", its not that fancy of oil. So thats awesome actually. Its not really any more expensive than the other brands and the parts stores have 5 qts of that poo poo all the time super cheap. So getting a change wont be insane hard when you're out and about either. poo poo still makes me jealous everytime I open this thread. EbolaIvory fucked around with this message at 17:49 on Jul 24, 2015 |
|
#
?
Jul 24, 2015 17:47
|
|
|
mobby_6kl posted:How was your M3 in terms of maintenance and running costs (besides gas obv)? Hopefully I'll be able to consider an E92 soon enough, though it'd have to be serious decision and not a toy purchase so things like that would need to be at least somewhat reasonable. I bought my 16k mile E92 in January, so far I've had to shell out for: 1 $220 oil change, 1 $250 battery, a couple hours of labor for installing/coding the battery & giving it a general checkup a month after purchase, and 1 set of angel eye bulbs (battery and bulb were both original equipment for an '08 car). The real expenses (other than gas, which was a bargain for the first 3 months of ownership) so far have been detailing products and the effort of cleaning it myself. And $20's for the valet to let me park it myself. It's pretty reasonably acting like "A regular car" thus far considering what a highly-strung & focused machine it actually is when it wants to be and I semi-daily drive it to work to the tune of about 80-100 miles a week in addition to weekend fun drives. I've put about 4000 miles on it and it'll be due another oil change in September or so, I don't anticipate any further 'scheduled' maintenance this year, with tires ($1200) possibly being needed a bit after the 1 year ownership mark.
|
|
#
?
Jul 24, 2015 19:32
|
|
|
Ether Frenzy posted:1 $250 battery, a couple hours of labor for installing/coding the battery Walmart carries the batteries for half that and BMWhat/Carly can do the battery registration for fairly cheap - or you can use Tool 32 / NCS Expert for even less. BlackMK4 fucked around with this message at 22:28 on Jul 24, 2015 |
|
#
?
Jul 24, 2015 22:17
|
|
|
Yeah, not so much on getting the battery for half that in my zip code but I looked back at my records and it was actually closer to $220 in total. I bought the battery from Sears after shopping around online, it was $190 with a sale going on + core charge + tax + delivery to my independent mechanic's shop (the car was already there and part of the labor time was him confirming the battery actually needed replacement before I just randomly purchased one) so I just had him go ahead and install/code it since he was already doing the 'New to me' first service anyway.
|
|
#
?
Jul 24, 2015 22:49
|
|
|
Ether Frenzy posted:I bought my 16k mile E92 in January, so far I've had to shell out for: 1 $220 oil change, 1 $250 battery, a couple hours of labor for installing/coding the battery & giving it a general checkup a month after purchase, and 1 set of angel eye bulbs (battery and bulb were both original equipment for an '08 car). I think I got spoiled by the M3 and its reliability, given how much power they wring out of the motor. I have no idea how they made that thing so good, but once I pay the Viper off in a few months I might start looking for another M3.
|
|
#
?
Jul 25, 2015 02:45
|
|
|
IOC indicated some discussion on the hacking / remote-access stuff was happening here -- I think I've posted about the stuff before, but I used to work on the HW/SW for anti-theft / ABS / other ECMs for a few of the major Tier 2s -- we're lucky that someone happily blew this poo poo up in public. Our security precautions were all dependent on obscurity -- all sorts of backdoors and lazy system design to enable cost savings were the priority of the day. Now with OTA updates (and silent ones at that, looking at you Tesla), it's terrifying to think about potentially faulty software getting pushed out to your vehicle. Tesla engages with some of the conventional / traditional suppliers back in MI, and a few of those companies have resident engineers at Tesla to support their development efforts. They were pretty aghast at the cavalier attitude where you have managers used to consumer software pushing out brake SW updates to the test fleet that sometimes rendered them entirely inoperable. Complete strangers to safety-critical SW development. At least there's some separation of CAN busses based on function, but we mostly ended up cutting those apart because of bus utilization issues where we didn't have the bandwidth to keep all the modules talking at once. movax fucked around with this message at 04:04 on Jul 25, 2015 |
|
#
?
Jul 25, 2015 04:01
|
|
|
|
| # ? Apr 28, 2024 11:33 |
|
|
kastein posted:LIN bus is another fun one. It is significantly simpler and smaller, all transactions (read and write from anything to the master) are arbitrated by the master node, there is only one master node and up to (iirc) 15 or 31 slave nodes. It's more used for things like wiper motor controllers, seat position controllers, etc that don't need much in the way of smarts. Actually, a perfect example is the wiper motors in a new-gen Focus. There are two of them for the front instead of just one, with none of the traditional linkages. The left wiper motor has a LIN bus interface and the two wiper motors are slaved together via a synch wire that they use to communicate and synchronize their motion. The motors are each smart enough to stop if they see an overload condition, return to home automatically, and wipe speeds and swept angle can be configured at production time. I looked into using them but they're too heavy for our application. LIN and CAN in the traditional German fashion are designed to go together -- take your driver door, the idea is to throw in one CAN module (pricier, more complex) that has local LIN links to other functions in the door (window motors, switches, mirror control, etc.). It looks really pretty in a system level diagram -- you have complex nodes, and then simpler nodes scattered around the vehicle for the low-bandwidth, sensor/actuator stuff that the complex node controls / filters/ processes and sends out to the rest of the bus. LIN's also attractive because with the right transceivers, you can piggy-back on the existing power wiring and have a simple +12V/GND going to a motor, and enjoy LIN communication on that link as well.
|
|
#
?
Jul 25, 2015 04:07
|
|