[HN Gopher] Hacking a VW Golf Power Steering ECU
___________________________________________________________________
Hacking a VW Golf Power Steering ECU
Author : ingve
Score : 287 points
Date : 2022-01-03 14:22 UTC (8 hours ago)
(HTM) web link (blog.willemmelching.nl)
(TXT) w3m dump (blog.willemmelching.nl)
| phkahler wrote:
| >> Only try this on an actual car if you know what you're doing.
| Even though only two very small patches are made to the model
| specific calibration values, making changes to your EPS might
| have unintended consequences.
|
| The author has no idea what he's doing, or more specifically what
| hazards might be lurking right under his nose. I worked in EPS
| for 6 years and it's all really cool stuff right up until you
| download code and it promptly turns left all the way to the stop
| the first time you touch the wheel. That was a bug ;-) I can't
| tell you how hazardous it may be to tweak tuning parameters -
| that depends on a lot of things. Tuning aside, just commanding it
| over CAN might allow you to do things that wouldn't normally
| happen and might damage something - i.e. are all protections
| still in place when taking an external command? I didn't work on
| this model, or at this company, I'm just saying I've seen a lot
| of stuff and wouldn't recommend messing around with safety-
| critical ECUs like this.
| londons_explore wrote:
| I have a totally stock EPS that will just apply random full
| torque left or right if the battery voltage drops below ~10
| volts. One would imagine that's a scenario they tested for, but
| apparently not! It happens very easily on my car when all the
| electrics are turned on for a few hours while driving with low
| revs, like driving on a cold dark day on a 40mph road.
|
| The first time I did it, my thumb was dislocated because it was
| inside the wheel! Didn't realise quite how powerful power
| steering systems are!
|
| Now I have tape over the heated seats button with a warning to
| only use them _or_ the rear defroster, not both.
|
| Fun fact: The power steering uses 170 Amps when turning the
| wheel fast! Of course the voltage drops!
| Infernal wrote:
| Mind sharing year/make/model of car? That's crazy.
| evdoks wrote:
| I think you are a little bit too harsh here. The author is one
| of the leading developers at Comma.ai - the company behind
| OpenPilot. I am closely following the project and regardless of
| what is your attitude towards OpenPilot, the author is
| definitely not someone, who jumps into EPS hacking without
| being aware of implications of his actions.
| [deleted]
| [deleted]
| pd0wm wrote:
| In this case the EPS already came stock with the functionality
| to request torque over CAN, that part of the code or the amount
| of torque was not touched. I agree it would not be a good idea
| to patch that functionality into an EPS that doesn't come with
| that from the factory.
| userbinator wrote:
| _and it promptly turns left all the way to the stop the first
| time you touch the wheel._
|
| I bet many have had nearly the same experience with rebuilding
| a power steering gear... yet that's no justification for taking
| away control from the things you own.
|
| "Life is risk, risk is life."
| oneplane wrote:
| As long as it's only your own life you risk and not that of
| others on the road, dependants in your household or something
| like that that need you to be around, sure.
| OnlineGladiator wrote:
| > yet that's no justification for taking away control from
| the things you own
|
| I'm a big believer in owning what you buy, but if what you're
| buying requires a license to operate and you intend to use it
| publicly, not to mention the various safety regulations and
| certifications required just for the product to be legal in
| the first place (which are likely ignored if not violated
| while modifying the product), then the justification is "not
| killing someone else accidentally."
|
| This doesn't mean you can never hack anything, but you should
| be aware of the risks and potential consequences of your
| actions.
| bri3d wrote:
| This is probably one of the best write-ups I've seen around the
| basics of automotive control unit reverse engineering.
|
| More modern VW control units are the same in broad strokes - they
| use UDS on ISO-TP instead of KWP on TP2.0, but this is just
| evolution of the same fundamentals. And instead of the wacky SGO
| format inside of FRF update files, they use the ASAM MCD-2 D-ODX
| format to define flashing layers. Most European automakers are
| similar.
|
| One interesting difference and trend in automotive control
| modules (also mentioned in Willem's fantastic write-up) is that
| many EU modules started adding signature checking and encrypted
| updates in the late 2000s, while most US and Japanese automakers
| have only done so in the last 2-3 years.
|
| These encrypted and signature checked updates are by and large
| still fairly vulnerable - often due to logic errors in the
| complex upgrade processes and occasionally due to a strange
| insistence on using RSA using PKCS#1.5 with e=3 and inadequate
| padding validation.
| ptsneves wrote:
| > One interesting difference and trend in automotive control
| modules (also mentioned in Willem's fantastic write-up) is that
| many EU modules started adding signature checking and encrypted
| updates in the late 2000s
|
| Do you mean the XOR encryption used? As someone working on the
| embedded linux(!= than embedded MCU) side i was very surprised
| to find such a crude "encryption" scheme employed. On the other
| hand i reckon there is only so much encryption an 8bit MCU can
| do. Also tolerance for complex encryption designs must be very
| low when you are trying to limit the scope of a life critical
| component.
|
| The anti brute force measure was a bit more refined and almost
| got the job done.
|
| Regardless, i agree. An great write-up. The binwalk and narrow
| down of possible CPUs used due to the ASIL-D constraint were
| really illuminating.
| pd0wm wrote:
| The XOR encryption was just for the update container. Newer
| update files usually employ some stronger forms of
| compression/encryption. However, it's usually some strange
| in-house crypto, so eventually people figure it out.
|
| bri3d refers to using RSA signatures on the firmware once
| it's written to the flash. By ensuring the firmware is signed
| using the manufacturers private key it should (in theory)
| prevent messing with the firmware, even if all
| encryption/flashing steps have been reverse engineered.
|
| Some interesting reading:
| https://github.com/bri3d/VW_Flash/blob/master/docs/docs.md
| https://github.com/jglim/UnsignedFlash
| chrisseaton wrote:
| > Do you mean the XOR encryption used? As someone working on
| the embedded linux(!= than embedded MCU) side i was very
| surprised to find such a crude "encryption" scheme employed.
|
| I'm not a cryptographer - but I don't think there's anything
| wrong with XOR encryption, and I'm not sure why you're
| putting it in scare-quotes - XOR with a sufficiently large
| key is absolutely fine, and with a one-time pad is
| unbreakable. XOR with very large keys is how critical
| military encryption systems such as radios work.
| j4hdufd8 wrote:
| > XOR with very large keys is how critical military
| encryption systems such as radios work.
|
| Cool! Do you have any references?
| chrisseaton wrote:
| For example the TETRA standard for trunked radio, "The
| key stream bits shall be modules 2 added (XORed) with
| plain text bits in data, speech and control channels".
| fanf2 wrote:
| In the TETRA specification they use the term "key stream"
| to mean the output of a stream cipher, which they call a
| "key stream generator". They aren't XORing directly with
| a large key - the TETRA key size is 80 bits. See section
| 6.3.2.2 of https://www.etsi.org/deliver/etsi_en/300300_30
| 0399/30039207/...
| chrisseaton wrote:
| Yes you can programatically generate a key.
| marcan_42 wrote:
| And we call that a stream cipher, not "XOR encryption",
| even though it uses a XOR operation. You're
| programmatically generating a _keystream_ , which is not
| the same thing as a key.
| ncmncm wrote:
| See, this is why we can't have secure things.
| heavenlyblue wrote:
| > XOR with a sufficiently large key is absolutely fine, and
| with a one-time pad is unbreakable
|
| Excuse me, how do you envision the use of one-time pads in
| the real world?
|
| And with sufficiently large block keys - how do you deal
| with data full of zeros? Because XOR of 0 will give you the
| exact key you have encrypted the data with.
|
| You are not a cryptographer, and indeed, I don't think
| you've spent enough time thinking about it.
| chrisseaton wrote:
| > Excuse me, how do you envision the use of one-time pads
| in the real world?
|
| You load up as much one-time pad as you will have data to
| transmit - sometimes hundreds of MB of key if required.
| Storage is cheap.
| danachow wrote:
| Hundreds of Megabytes? That's a big number to you? Did
| you step out of a time warp from 1990?
|
| Also you are surprisingly quite clueless about basic
| crypto if you think storage is the biggest issue with
| practically using one time pads (though it is indeed
| one). I'm pretty sure even the Wikipedia article can
| explain this so no reason to spoon feed it here.
| chrisseaton wrote:
| > Hundreds of Megabytes? That's a big number to you?
|
| If you only have a hundred MB of data to send... a
| hundred MB of key is sufficient to use as a one-time pad.
|
| Until digitisation the military literally did encryption
| over radios using physical pads - everyone carried a big
| one-time-pad (just a few tens of KB though). It was done
| as a lookup table rather than an XOR though.
| monocasa wrote:
| The pad system used by the military predigitisation[0]
| was a set of keys to input into a keystream generator
| rather than a strict one time pad style system, except
| for very specific and limited espionage use cases. And it
| wouldn't be one time, it'd be on the order of a daily key
| rotation with key reuse (with maybe a few chosen per day
| depending on classification level).
|
| [0] I'm assuming we mean computerized here. Old school
| cipher machines of the type of the ENIGMA and M-209 were
| arguably digital machines, just base ~26.
| chrisseaton wrote:
| > I'm assuming we mean computerized here
|
| No, pre common man-pack digital radios, so as recently as
| just prior to this century. They used paper one-time
| pads, with a big list of table indices for substitution.
| You still get them for use when you have no digital
| crypto for whatever reason.
| monocasa wrote:
| That's not quite what I'm seeing, instead that what I
| believe you're talking about (Morse code over open air
| with a Diana cipher backed by one time pads) were pretty
| much exclusively used by special forces in Vietnam. The
| issues with key distribution inherent in one time pads
| otherwise got in the way of cross team cooperation too
| much since each pad would only exist in two places (the
| spec ops team, and a major base close by, but not a FOB
| in case it was overrun).
|
| They might have taught that use case to radio operator
| MOSs, but it wasn't actually deployed in the general case
| it seems.
| chrisseaton wrote:
| > That's not quite what I'm seeing ... it wasn't actually
| deployed in the general case
|
| I'm was literally trained in the British variant of
| technique I'm describing. There's a wikipedia article
| about it, and it's referenced from this cryptography
| wiki's one-time-pad page. Other countries used similar
| systems.
|
| https://en.wikipedia.org/wiki/BATCO
|
| https://cryptography.fandom.com/wiki/One-time_pad
| [deleted]
| marcan_42 wrote:
| > I'm not a cryptographer - but I don't think there's
| anything wrong with XOR encryption
|
| When cryptographers and security professionals talk about
| XORing the keystream output of a pseudorandom function with
| plaintext to encrypt it, we don't call it "XOR encryption",
| we call it a stream cipher.
|
| When we talk about XORing with a random pad of equal length
| to the plaintext, we don't call it "XOR encryption", we
| call it a one-time pad.
|
| When we say "XOR encryption" we invariably mean "silly
| insecure thing with a repeating keystream no longer than a
| few bytes".
|
| > XOR with a sufficiently large key is absolutely fine
|
| It isn't. XOR with any key ever used more than once or
| looped around isn't not just "not unbreakable", it's
| demonstrably insecure. There is no "sufficiently large key"
| other than "same size as the plaintext and used only once
| for that plaintext" (a one time pad). To use smaller keys
| you need real cryptography, not XOR. Military radios
| absolutely do not work like this. They use stream ciphers,
| which can produce ~arbitrary length keystreams without
| repetition from a small seed key.
| formerly_proven wrote:
| I'm assuming they meant XOR-ECB with a block size of 1/2/4
| bytes.
| ptsneves wrote:
| The article's XOR key was 0xFF :) Definitely out of the
| sufficiently large key range.
| monocasa wrote:
| I think they mean using XOR with a repeated fixed tiny key
| _as_ the stream cipher, rather than just using XOR to mix
| the keystream and the plaintext.
|
| These ECUs aren't using one time pads with key lengths the
| same size as the firmware. I doubt they're using one time
| pads at all, which would necessitate each version of
| firmware using a different key.
| markus_zhang wrote:
| > XOR with very large keys is how critical military
| encryption systems such as radios work.
|
| Is it that large keys are factors of very large prime
| numbers so that to know the keys you will need a very
| powerful computer?
| ncmncm wrote:
| There are only two factors of any prime number, large or
| otherwise: 1 and the number.
|
| But even correcting to what you must have meant to
| suggest doesn't make sense.
| markus_zhang wrote:
| Sorry I meant something else, can't wrap my head around
| to recall the name...
| chrisseaton wrote:
| XOR with a one-time pad doesn't work off factors of large
| numbers - you're thinking of asymmetric encryption there.
| You literally just XOR each plain text byte with a key
| byte.
| markus_zhang wrote:
| Thanks! I don't know much about cryptography and will
| check this out.
| [deleted]
| bri3d wrote:
| No, this EPS control module is remarkably primitive even by
| late 2000s standards and several generations behind today's
| state of the art.
|
| More modern control modules with a bit more resource
| available to them will use AES as the symmetric encryption
| (although there are also fixed-key XOR schemes and custom
| stuff used like this: https://github.com/bri3d/VW_Flash/blob/
| master/lib/decryptdsg... ).
|
| The keys and even IV are usually fixed across a "model line"
| of ECUs, so once a decrypted flash memory can be extracted,
| this isn't much of a protection measure, but it's a lot
| better than XOR.
|
| Then, in more modern control units, flash areas are also
| usually protected by both a checksum (usually some CRC
| permutation, although cute tweaks and random nonsense are
| common here too) and some form of digital signature.
| tyingq wrote:
| >many EU modules started adding signature checking and
| encrypted updates in the late 2000s
|
| Ah, yeah, and this is irritating if you're a used car owner,
| particularly an owner of a car that's now lower value. I can't,
| for example, pick up a cheap used throttle body for my older
| Volvo because the main ECU will reject it until someone from
| the stealership charges me a LOT of money to "program" it.
| bri3d wrote:
| This is unlikely to be related to encryption but just
| protectionism on an older vehicle. Generally speaking, until
| very recently (like 1-2 years ago), non-immobilizer related
| adaptation processes are just a matter of finding the correct
| UDS remoteRoutine to invoke, and aren't cryptographically
| protected at all. It's likely that the thing you're missing
| is the diagnostic documentation for the correct routine
| invocations to send, rather than keys or certificates.
|
| Although, unfortunately this too is changing, starting in the
| 2021 model year VW AG have introduced a rather evil
| technology called SFD which requires server-signed tokens to
| perform these kinds of basic adaptations. This is all being
| done in the name of anti-theft security.
|
| We really need better right-to-repair rules for vehicles.
| tyingq wrote:
| This is possible, though it's essentially the same because
| the tools require an active "VIDA" subscription. So the ECU
| gatekeeps normal stuff with a high level blocker type
| thing. And, perhaps there are ways around it, but enough
| hassle to kill right-to-repair.
| carlhjerpe wrote:
| Seeing the amount of part theft in Stockholm I understand
| why they do it. Particularly steering wheels, they steal
| them and send them to the baltics where they put them in
| vehicles where the airbag has fired.
| ugjka wrote:
| Then you solve the problem in the baltics, not use it as
| excuse to turn your cars into "iphones"
| natch wrote:
| You really think that is a realistic goal, for the car
| companies to solve crime in other countries?
|
| Just as Apple can't prevent abusive people from having
| the desire to track, stalk, and creep on their own family
| members, I don't think you have a practical outlook or
| plan here.
|
| The manufacturers do what they can, and they deserve all
| our respect for that, not derision.
| ugjka wrote:
| Yet these big corporations spend billions of dollars
| lobbying the governments to their advantage every year.
| But when there is a practical problem, people like you
| come in here and throw their hands up "There is nothing
| we can do, but to lock our cars down"
| tonyedgecombe wrote:
| What are you proposing, that Sweden invades in order to
| stop car part theft?
| ugjka wrote:
| You know they are in the EU? Surely there are political
| tools to solve why there is a demand for stolen car parts
| in the Baltics
| kalnins wrote:
| There isn't a demand for stolen car parts. There is a
| demand for cheeper/used car parts. This is in part due to
| lower salaries combined with people wanting to buy "cool"
| cars that are way over their budget hence they aren't
| able to afford new car parts for them.
| ugjka wrote:
| And the only solution is lock our cars down and have no
| right to repair? And there is no question why something
| like this is happening within the EU? The union which is
| supposed to solve inequalities like this within its
| borders?
| mantas wrote:
| Lithuanian here.
|
| It's not inequality when instead of a cheap hatchback you
| NEED to buy BMW 5-Series or Porsche Macan. But you import
| a damaged one from US. And then you need a bunch of
| ,,used" parts to repair it.
| carlhjerpe wrote:
| I mean it is inequality since the people they steal parts
| from can afford them, but it's not the kind of inequality
| we'd shed tears over.
| mantas wrote:
| Or different priorities. Why pick between a nice house
| and Porsche if you can repair a crashed Porsche with
| stolen parts and build a house paying workers under table
| and skipping few regulations here and there.
| carlhjerpe wrote:
| True Robin Hood, steal from the rich and give to the
| poor. Too bad it destroys so much capital every time.
| the_mitsuhiko wrote:
| Just look at how many tailgates and catalysts are stolen
| from trucks in the US. That problem is not solvable by
| more law enforcement.
| carlhjerpe wrote:
| Not our jurisdiction, and what could car manufacturers
| do?
| ugjka wrote:
| Address the problem at the EU level because both Sweden
| and the Baltics are in it. This what the EU is for. But
| obviously it is much convenient to solve this the "Apple"
| way and claim that there was no other way...
| mantas wrote:
| Reintroducing border control would be a good 1st step.
| But gods forbid movement of ,,goods" is endangered :)
| carlhjerpe wrote:
| I know of no state that controls their outbound goods, so
| it'd be on the countries benefiting from this to get more
| strict, not gonna happen.
| mantas wrote:
| Here in Lithuania we're still checking cars leaving to
| Belarus to make sure they ain't stolen. Random car papers
| checks on Poland/Lithuania border is still a thing too.
| Both to make sure Porsche stolen in Berlin last night
| don't end up in Moscow 24 hours later.
|
| Unfortunately it's hard to check every boot for stolen
| headlights and steering wheels without border control
| kalnins wrote:
| I don't think they actually send them to baltics, as
| those are stolen from cars here also and they probably
| catch a better price in Stockholm anyway. Or sent a lot
| further than that.
|
| The running "joke" is that insurers pay to put your
| original stuff back into car, as insurers somehow find
| "used" parts for mechanics.
| carlhjerpe wrote:
| The running joke is a joke indeed, we have accountability
| and traceability in our marvelous high-tax socialist
| haven, if you pay someone a significant amount it's VAT
| has to be tracked, parts can't just magically appear out
| of thin air, well maybe every now and then, but not
| systematically.
|
| Edit: Especially airbags, they require special
| certifications to be installed and managed in Sweden,
| second hand airbags is NOT a thing here. Though other
| parts very well might be.
| michaelt wrote:
| In my country, if your car is missing (say) a wingmirror,
| you can go to a 'scrap dealer' who has a yard full of
| written off cars, and they'll sell you a wingmirror taken
| off a scrapped car.
|
| There isn't any greater authority, keeping track of every
| car part or ensuring the number of wingmirrors leaving
| stock matches the number legitimately entering stock.
| carlhjerpe wrote:
| We're not talking wingmirrors, we're talking interior.
| And it's different for cheap stuff one could pay cash,
| but cars are registered when they come in to the junkyard
| and parts sold are declared.
|
| I'm not saying it can't happen every now and then, but it
| wouldn't work systematically.
| formerly_proven wrote:
| > The electronics seemed to be fabricated using bare dies
| attached to some substrate, probably to lower cost and improve
| reliability at higher temperatures. The board is made up of two
| parts, a low-power part with the CPU and CAN transceivers, and
| some high-power part with 6 MOSFETs forming a three phase
| H-Bridge.
|
| > https://blog.willemmelching.nl/images/vw/IMG_3181.jpg
|
| It doesn't really look cheap to me (large machined surfaces on
| the cast aluminium casing, two ceramic PCBs, everything connected
| with wire bonding, even the motor windings and the external
| connector, which means that at least those bonds are carried out
| on an almost completely assembled product; also look at the sheer
| size of the motor bonds) but it does look very reliable -
| everything is bonded or welded, zero connectors, no fasteners,
| all solid state.
| stephen_g wrote:
| Yeah, it looks like it's extremely optimised for reliability.
| The construction reminds me of some of the space stuff I'd seen
| made by a company I worked for (it was all done before my time
| though).
|
| It probably wouldn't be incredibly expensive in this case
| (automotive) because all the wire bonding and tab welding can
| be automated, but clearly cost isn't the main concern behind
| the design!
| t0mas88 wrote:
| Automotive has quite broad temperature and vibration
| requirements and is supposed to work for 15 years+ so it
| makes sense to pick something like this.
| unbanned wrote:
| Ferrari used this method for their ECUs in the 360 to reduce
| risk of damage from vibration and heat.
| terr-dav wrote:
| Ah, so they're _designed_ to be on fire.
| numpad0 wrote:
| This also makes the component prone to lights. All in all, very
| exotic and interesting.
|
| Recently I opened up a Mitsubishi Electric power steering unit,
| and while mine looked a bit like a parallel world Enterprise,
| this one looks like Enterprise with a suffix couple alphabets
| later than the one in the intro. Mine was just a two PCB build
| of a logic board with Fujitsu microcontroller and a power board
| with an H bridge and input/output emergency isolation MOSFETs.
| mrtksn wrote:
| I agree but if that was in the world of consumer electronic it
| would have been frowned for repairability.
| garaetjjte wrote:
| Yeah, if some power transistor fails these things are
| nightmare to repair, eg.
| https://www.youtube.com/watch?v=133qU9sMatA
| captainmuon wrote:
| I'm really surprized this is reliable (of course they know what
| they are doing). Maybe because all the wirebonds to the dies
| are encased in epoxy (?) and the other bonds are so thick. Even
| then I would be worried they would snap off or lift their pads.
|
| I wasn't directly involved but I still have nightmares about
| wirebonding. For a large partice physics experiment, we bonded
| electronics to silicon (wafer) sensors. Those small bonds would
| start oscillating and break as soon as there was any noise with
| their resonance frequency. It took cooling and heating cycles
| also pretty badly. In the end they sorted out all problems
| somehow, but the association "wirebond = delicate" stuck with
| me.
| garaetjjte wrote:
| This isn't epoxy, it's some sort of sticky soft coating.
| Wirebonds looks fragile to me too, but after all every
| packaged chip have wirebonded pins, so at least it shouldn't
| be worse.
| blincoln wrote:
| This may go without saying, but a word of caution for anyone who
| wants to try this themselves: doing any sort of automated
| scanning of ECU hardware (e.g. the equivalent of trying to find
| undocumented opcodes in a CPU) stands a good chance of bricking
| the hardware (permanently), so plan to buy several of them if you
| want/need to go that route.
| j4hdufd8 wrote:
| What does it mean to permanently brick the hardware?
| balls187 wrote:
| > What does it mean to permanently brick the hardware?
|
| Colloquially means rendering a device in useless state which
| cannot be recovered.
|
| "Bricking" typically occurs when performing some sort of
| software update that goes awry, such as during powerfailure,
| using unofficial updates, etc.
|
| More and more systems have ways to recover from a bad update,
| especially when the manufacturer offers OTA updates, but in
| the case like article where an the ECU is not designed to be
| updated by end-consumers, a bad flash/update can lead to the
| device being left useless.
| froh wrote:
| Is a colloquialism for breaking it beyond repair. The origin
| is that you turn the fancy expensive electronic device into a
| heavy paperweight like block, just like a brick.
|
| For the "how" of what happens inside so it can't be repaired
| please see the sibling comments.
| [deleted]
| emidln wrote:
| Most ECUs have diagnostic messages that can read/write
| memory. This is often intended to be controlled by what
| "mode" the ECU is in
| (manufacturing/engineering/production/dealer-service), but
| these aren't always well tested or properly implemented
| controls. Fuzzing these leads to weird behavior and state
| machines with not-well-tested transitions. Whether you can
| reset these to a known state is ECU specific, and often will
| involve knowledge that isn't publicly known.
| jacquesm wrote:
| And sometimes it will require gear that isn't publicly
| available.
| PaulHoule wrote:
| Being willing to buy a second copy of the system you are hacking
| on is one of those things that separates the men from the boys or
| those who succeed from those who fail.
| ewagsjr wrote:
| As cool as this is, I will never EVER hack/jailbreak car
| steering. I can't put my faith in unsupported (non-OEM may be a
| better term for it) software keeping me safe. I watch the tesla
| autopilot videos of them totally messing up and that is fully
| supported but still failing too much.
|
| But cool POC for sure.
| joshenders wrote:
| What did you get your elevator operator for Christmas?
| therealcamino wrote:
| Well, presumably you're not letting your neighbor down the
| hall flash your elevator's firmware. He/she said non-OEM.
| marcodiego wrote:
| Power Steering ECU... this things determines how the driving
| wheel makes the car turn. Safety issues must be considered.
| bob1029 wrote:
| I will never purchase a vehicle for my own purposes that does
| not use hydraulics for brakes and steering.
|
| Putting a computer between my foot/hands and the physics
| unfolding in front of me is a total non-starter.
| userbinator wrote:
| I am reminded of the Boeing MCAS debacle, except instead of
| runaway trim, you now have "runaway steering wheel", and far
| less time to react...
| kyazawa wrote:
| With EPAS your steering wheel still physically steers the
| wheel via the rack and pinion gears.
|
| With ABS and ESC, most cars on the road today have a computer
| involved in the braking system. It seems pretty safe.
| [deleted]
| bob1029 wrote:
| > With ABS and ESC, most cars on the road today have a
| computer involved in the braking system. It seems pretty
| safe.
|
| Absolutely. These systems have very simple feedback loops
| and controller algorithms. Determining that you lost
| traction is a simple problem to solve. Determining that a
| dangerous obstruction is in front of your vehicle is not.
|
| ABS/ESC also tend to have a more limited impact on the
| vehicle, even if they do malfunction. You can typically
| disable these pretty easily (pull fuse/drive system
| configure).
| outworlder wrote:
| But you did say this:
|
| > Putting a computer between my foot/hands and the
| physics unfolding in front of me is a total non-starter.
|
| Which ABS does, there's literally a computer in between
| your inputs and the 'physics'. So which is it? There was
| a time when ABS was not considered a simple problem. They
| had to invent it for the Concorde.
|
| > You can typically disable these pretty easily (pull
| fuse/drive system configure).
|
| If they did catastrophically malfunction, you wouldn't
| have time to pull fuses.
| bob1029 wrote:
| Allow me to be more precise:
|
| I do not want to operate a vehicle wherein the
| _exclusive_ means of conveying my control inputs to the
| final destinations is via a computer. Some limited
| augmentations to existing direct inputs are acceptable in
| my view.
| mcguire wrote:
| Is the phrase you are looking for "drive by wire"?
| [deleted]
| Veritio wrote:
| Do you consider an automatic emergency break as less reliable
| than it helps?
|
| Because we do have a lot of numbers on cars were there is a
| computer in-between. Which should indicate to me that it is
| safer to drive with one instead of without one.
|
| Like just yesterday (I'm driving a new car) I thought about
| emergency breaking automatic vs. manual and I actually feel
| safer knowing that the car can potentially break faster.
|
| In the brochure of my mother's potentially future car, it
| actually advertise emergency breaking with emergency steering
| to drive left or right. I also found that quite good to have
| as it should be able to determine much faster if it can evade
| and where to evade.
|
| Or do you mean this different?
| bob1029 wrote:
| > I thought about emergency breaking automatic vs. manual
| and I actually feel safer knowing that the car can
| potentially break faster.
|
| For me, the knowledge that some other engineer designed a
| system that is a complete black box (from my perspective),
| which can arbitrarily stop my car with incredible braking
| force is terrifying.
|
| What happens if the emergency braking system decides to
| have a bug while you are exiting the freeway at 75mph?
| martin8412 wrote:
| My concern is if the engineers were qualified and allowed
| to follow proper protocol for designing safety critical
| systems.
| bob1029 wrote:
| Also consider the budgets these engineers have to work
| with now. If cars had an average unit cost measured in
| 7-9 figures (i.e. like a Boeing 777), I would have
| substantially more trust in everything involved.
| userbinator wrote:
| All that cost, and they still screwed up with the
| 737MAX...
| therealcamino wrote:
| There's not a simple relationship between cost of the end
| product and the budget for developing safety-critical
| systems. There are only ~1600 777s ever built. The
| development costs for automotive systems are amortized
| over millions of units.
|
| I have no idea what the budgets actually are, and it's
| fine if you don't trust certain kinds of automation in
| cars. In fact my 2020 Toyota with lane-keeping assistance
| tried to drive me off the freeway at 80mph three times
| last week. (I probably should have stopped trying it
| after the second time, but I was kind of morbidly
| fascinated at that point. As it steered me firmly towards
| the grassy median, it also started beeping urgently to
| tell me that it wasn't a good idea.)
| seized wrote:
| Yeah, Boeing is a solid example of that whole large
| budget == safe mentality.... Maybe in 2022 exclusively.
| l33tman wrote:
| I do share your concern... but somehow I (perhaps
| naively) feel there is a big difference between
| regulatory mandates like emergency braking, that all
| manufacturers in the EU has known and planned for since
| more than 15 years, and stuff like Teslas FSD-beta which
| is a disaster to happen running on our streets.
| jacquesm wrote:
| I've written about this before on HN, I had a late model
| C class Mercedes that decided to emergency brake on the
| surface of a small bridge sending the car into a spin,
| the same thing happened in a turn when there was a large
| sign present.
|
| In both cases the error seems to have been related to the
| radar picking up a return and interpreting that as an
| imminent frontal collision when there was absolutely no
| reason for that. I had the vehicle checked out, they said
| it was performing to spec so I sold it. No more Mercedes
| for me.
| jhallenworld wrote:
| Maybe it's safer than hydraulic power steering. With
| electronics, there could be all kinds of self tests, for
| example that one of the H-bridge MOSFETs is shorted or open,
| akin to a valve being stuck.
| userbinator wrote:
| In my experience, traditional "analog" systems degrade far
| more gracefully and this applies to automotive too; there's
| usually a long period where you notice things getting worse
| slowly due to wear, before ultimate failure.
| throwaway0a5e wrote:
| The guy actually doing the modding and putting his butt in the
| seat has far more skin in the game than anyone who's second
| guessing him here.
| progbits wrote:
| Well, except you know... every pedestrian (and possibly
| driver) in his neighborhood.
|
| I'm being half serious - this seems harmless enough, but
| where do you draw the line? I'm all for the fun of reverse
| engineering but maybe keep that shit off public roads.
| throwaway0a5e wrote:
| I couldn't care less. People hacking up things are a
| rounding error compared to the rest of the motoring public.
| If your vehicle is capable of meeting the performance
| expectations of everyone else I don't care what you drive.
| If your horse and buggy, ebike conversion, etc. can do
| highway speed and get there within the distance of the
| merge lane then feel free to ride that crap on the
| interstate. Likewise I don't see why anyone should be
| disallowed from driving heavy equipment on slow city and
| residential streets where it can keep up.
| wkearney99 wrote:
| ah yes, the casual arrogance of treating other people's
| lives as just 'rounding errors'.
|
| The only fortunate part, I suppose, is the kind of
| personality disorder that thinks/acts that way is
| likewise a rounding error.
| wkearney99 wrote:
| shame the people he might hit and kill as a result of "the
| game" don't get a choice.
| torquemodwanted wrote:
| I'd love to do a torque mod on a modern Honda EPS, but there's
| simply no easy way for a "normal" person do it. The amount of
| time and effort is extreme with no background knowledge of the
| problem. (Yes, I understand there's liability, etc.).
|
| It's completely taboo in openpilot discussions (e.g., the Discord
| channel), so I'm curious if there's an alternative community open
| to talking about it (distributing pre-patched or providing a
| patcher).
|
| For Honda cars at least, openpilot is absolutely hindered by the
| low torque allowed by the stock firmware.
| MuffinFlavored wrote:
| Very few ECUs have CCP/XCP writing wide open. A lot of magic is
| in the area of defeating the cryptographic signature check on the
| device (hash of flashed contents).
| olivermarks wrote:
| Great write up which also illustrates how deep DRM/closed systems
| are in cars built this century.
|
| Until around mid 90's cars still had lots of relays and barely
| comprehensible wiring looms if you could get your hands on
| workshop manuals.
|
| The sooner we go back to a BEV with the simplicity of a 1960's VW
| Beetle the better imo, not least so that the third world can get
| a look in.
| Beached wrote:
| pretty sure this won't happen. regulations require computerized
| standards to be used for various parts of a cars functions.
| this would require some insane lobbying to pull off.
| t0mas88 wrote:
| So far electric vehicles are getting worse not better, because
| they're less regulated on things like OBD access.
|
| And manufactures see them as a chance to make an always
| connected car that phones home. Tesla was first but everyone
| else is copying them now.
| grishka wrote:
| It's not like you can't disable these network interfaces one
| way or another. And of course it'll still work without this
| connectivity.
| trulyme wrote:
| For now. Like web pages used to work if you disabled
| JavaScript.
| grishka wrote:
| This is different. Cars could potentially be driven far
| away from civilization, so their reliability is sometimes
| critical for their occupants' survival. A car can't
| disable itself and leave people stranded in the middle of
| nowhere just because it doesn't have a cellular signal to
| phone home.
|
| And btw, many web pages do still work if you disable js.
| I'm saying that as someone who routinely disables js for
| websites that abuse it.
| userbinator wrote:
| Unfortunately, that situation has already happened:
| https://news.ycombinator.com/item?id=20873234
| grishka wrote:
| That was at least a carsharing car. It's a well-known
| fact that these need connectivity (your only means of
| unlocking them is the app, after all) and have a severely
| limited area where you could drive them. Though that one
| time when I took a carsharing car 70 km away from the
| city where it apparently couldn't communicate (but my
| phone had LTE) it didn't disable itself, it just didn't
| lock when the app thought it did. So it does depend on
| the particular way the particular company implemented its
| remote control unit I guess?
|
| I'm talking more about the situation where it's your own
| car.
| olivermarks wrote:
| My concern is that all vehicles are becoming more and more
| surveilled, transmitting hugely personal data. Once level 4
| centralized control is possible I predict pre permissioned
| requested travel will quickly follow.
|
| We urgently need a new generation of very basic
| transportation devices. The 3rd world relies on Toyo HiLuxes
| etc which are still easy to keep running. LandRover used to
| be all over the third world because they were rugged, basic
| and easy to work on. You'd think Tata who now own them would
| be continuing the tradition but they are building luxury
| vehicles with no clear purpose except signaling pretensions
| to offroad abilities. Embroidered with ECM controlled chips,
| wiring and sensors...</rant>
| syshum wrote:
| >> I predict pre permissioned requested travel will quickly
| follow.
|
| Excuse me sir, Did you upload your drive path to NHTSA
| today? No that will be a $300 fine...
| olivermarks wrote:
| It's not too hard to imagine requesting permission to
| travel, a robotaxi showing up and taking you to your
| location and funds deducted per mile and for damage to
| the planet compensation, assuming you got the necessary
| permissions granted in the first place...
| syshum wrote:
| Sounds like what is happening in parts of Australia
| today, only under the context of COVID...
| C19is20 wrote:
| Gdpr could be your friend.
| trulyme wrote:
| No technical solution will work against political problems.
| Any non-conforming vehicle will simply be forbidden. If you
| want to change anything, make it known how new cars phone
| home, what the dangers are, why this should be forbidden -
| only as a society can we prevent surveillance state.
| blamazon wrote:
| Individuals are not powerless in this fight. We can use
| democracy to try to maintain our freedom. The people of the
| Commonwealth of Massachusetts recently voted to enact the
| following:
|
| > "Question 1 (2020) required manufacturers that sell motor
| vehicles equipped with telematics systems to install a
| standardized open data platform beginning with model year
| 2022. The initiative defined telematics systems as a system
| in a motor vehicle that collects information generated by
| the operation of the vehicle that is then transmitted
| through wireless communications to a remote receiving point
| where it is stored. The measure allowed vehicle owners to
| access telematics system data through a mobile device
| application and to give consent for independent repair
| facilities to access that data and send commands to the
| system for repair, maintenance, and diagnostic testing."
|
| https://ballotpedia.org/Massachusetts_Question_1,_%22Right_
| t...
| userbinator wrote:
| Now you know why mid-century and slightly newer vehicles
| are so common in the world of custom cars and performance
| tuning. Simple and relatively comfortable to work on, with
| a large aftermarket of parts.
| mcguire wrote:
| " _After convincing the dongle to connect (even though most of
| the car was not present on the CAN bus) it was able to show some
| diagnostics information about the ECU._ "
|
| I am picturing this as a scene out of a '50s sci-fi horror movie.
| The mad scientist with a power steering controller on a tray in
| his lab. :-)
| Txoko wrote:
| Any Mercedes hacks?
| Veritio wrote:
| While I find this quite interesting, a street is not a lab.
|
| He should not do this on any public road and potentially he broke
| already some law.
| birken wrote:
| The driver is always responsible for what their vehicle does.
| As long as the driver can override the steering (which they
| can), then there is really nothing to be concerned about. This
| is the same for cars using openpilot, or Tesla's self driving
| systems or any other steering assistance features.
| l33tman wrote:
| This seems like a bit of an over-simplification.. A car needs
| to be type approved to run on our streets and the insurance
| companies need to accept whatever you did to the car in case
| of a crash. You don't really want to end up paying 100%
| yourself when you crash into that school bus with your mod.
|
| However it would be interesting to learn how type approvals
| handle the self-driving things. Maybe they really do allow
| all kinds of computer-assisted things? I don't know. If you
| change some structural beams in the car you surely lose
| approval. But can you mod steering and braking? What about
| openpilot users that crash?
| oceanplexian wrote:
| You can do a thought experiment where some esoteric
| firmware modification results in an accident, but it's
| 1000x more likely that Joe Sixpack spaces out while
| driving, runs a red light, and crashes into a busload of
| kids. Once we've solved that problem, drunk driving,
| distracted driving, poor driver education, and thus
| eliminated 99.9% of accidents, then it might make sense to
| have a debate about those pesky car modders or edge-case
| Tesla autopilot failures that are responsible for the last
| 0.01%.
| the_pwner224 wrote:
| > As long as the driver can override the steering (which they
| can)
|
| EPS is much more powerful than humans. It can apply huge
| torque and cause incredibly fast acceleration of the steering
| wheel (from full lock on one side to the other in a split
| second). Messing with the firmware definitely could cause a
| situation where the car just does whatever it wants to and
| the driver can do nothing about it.
| rzzzt wrote:
| The steering rack is probably toast in this video, but the
| "unloaded" maximum speed is still impressive:
| https://youtu.be/L6-nJSCmo1c
| markus_zhang wrote:
| One question: in part 2 it shows that Ghidra is able to produce
| disassembly from machine code, does that mean Ghidra knows the
| instruction set V850 uses?
| pd0wm wrote:
| Ghidra uses an intermediate language called p-code. When
| defining the CPU opcodes (and how to parse them), you also
| write a small snippet of p-code that represent that
| instruction. This makes the decompiler architecture agnostic.
|
| Example:
| https://github.com/NationalSecurityAgency/ghidra/blob/master...
| markus_zhang wrote:
| Thanks, I see. So it means anyone can add any architecture to
| Ghidra.
| [deleted]
___________________________________________________________________
(page generated 2022-01-03 23:00 UTC)