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.
Agree. Absolutely awesome article except for this one little line:
> Ensure the patches to the calibration values are safe before using.
How would you do that? I've worked on both ends of steering on VW Bugs and Golfs (steering column fixes and tie rod replacements). You don't want to mess either of these up either, but the repairs are (a) well documented and (b) relatively easy to verify you did them correctly.
By contrast, I've seen software break catastrophically in the past from "harmless" updates like changing the number of commas in a version string. In this case it's not the kinda doesn't work problem but hitting an unexpected corner case on the freeway that would worry me.
The calibration values were discovered through static analysis, so the code referencing those values can be followed to determine if unexpected side effects may be present. Obviously this process is imperfect, but it's not like blindly throwing bytes in and hoping something comes out.
I'm not a big advocate for comma/OpenPilot or EPS patching stuff in general, but I thought the patch in this example was fairly benign and reasonable as these things go - it was a data patch to the calibration area rather than a code patch, and the altered calibration contained relatively straightforward values with clear references and obvious effects.
> 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.
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.
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.
> 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.
> 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.
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.
> 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.
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.
> 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.
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.
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.
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.
> 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.
So if I'm understanding BATCO correctly, there's an average key reuse by a single sender after 13 messages because of the how the traffic key rotation selects a row? That, combined with the sense I'm getting that the cipher sheets were distributed widely (auth tables imply multiple senders using the same cipher sheet at the same time) seems to imply broad reuse of key rows, making it a pad, but not a one time pad. Do my assumptions filing in the blanks line up?
I'll give it that's it's definitely way better than DRYAD, which is pretty universally not considered a OTP because of the much greater key reuse (like how auth uses the same cipher tables as encrypt, leaking tables). So it boils down to the practical use case on whether it falls into OTP.
Yes entire radio net is moving through the shared pad together - so you when you send you consume a bit of the pad, and when someone sends to you they use the next bit of the pad, then you use the next, etc.
A new row per message means you don't re-use between messages (message is something like a sentence).
Each message should be short enough that you don't re-use (a 22-symbol message is already crazy), and you are not allowed to re-use if that means re-using a target symbol, but yes you might slightly re-use within messages if you're being sloppy.
In reality you don't get through the pad very quickly due to the 'compression' of a dictionary for typical parts of messages.
(This is all public info, not disclosing anything here.)
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.
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".
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_300399/30039207/...
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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"
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.
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?
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.
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.
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...
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
You havent seen Border Control: Europe by Discovery network. Border Control: Spain in particular often shows them stopping whole lorries loaded to the gills with stolen chopped up cars trying to cross to Morocco.
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.
> 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.
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.
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!
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.
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.
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.
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>
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.”
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.
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.
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...
GDPR is not enforced enough and it's very hard to get it enforced. Data protection authorities are completely useless at handling complaints from my experience.
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.
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.
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.
>> 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.
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.
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!
Holy cow, that's a crazy failure. Many cars have a zone between idle, and some greater RPM that is essentially a no charge condition. But what a consequence! Having dimmed lights, or an erratic instrumement display is the worst I've seen.
My older Honda has a fairly wide zone, 600 to about 1200 RPM. Annoying on high load days, and I've often wondered why this isn't designed out. Maybe it's wider due to car age and component wear / variation. I've installed a pretty great battery and see a little light dim, and that's about it.
One day I had an alternator failure and some distance to drive to get a new one basically. Made it, but right near the end, the instrument panel would go into reset and the car into some limp mode. Not the end of the world, particularly given I was expecting some failure as battery voltage dropped below 11 volts.
It was close enough to lose instruments entirely, but the engine ran anyway. All in all, it was a pretty graceful failure.
That rando full torque action seems crazy! And at 10! That's definitely a scenario, as you have found out, that can happen enough to seemingly be a problem.
So, what happened! Suddenly, your car is off the road, or what?
Seems like your sore thumb is the least of the potential bad things going on right then.
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.
> 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.
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.
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.
One system I know of had to have software to reduce torque at the end stops or it could destroy FETs and shut down. If this system needed such protection, we might wonder if its included when taking external torque commands. I would if I wrote the code, but you never know when operating outside their expected use cases.
It's also much more benign to destroy components than to have actual bugs. And he's not changing software at the source level.
> are all protections still in place when taking an external command
Diagnostic-specific commands are often restricted when the vehicle is in motion. On VW I remember that any "write" command such as an actuator test being declined even for "innocent" stuff such as lights or power windows on the body control module.
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.
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.
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.
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.
> 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.
> 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.
and there is no way to obtain the original ROM? and flash it and everything is ok again?
> and there is no way to obtain the original ROM? and flash it and everything is ok again?
If it was permanently bricked, then no. The device would be in a state that it could not restart the flash process.
If reflashing were possible with the original ROM, it would not be considered permanently bricked.
It would be possible that an OEM or advanced specialist may have the ability to salvage a permanently bricked device, through special equipment, and/or repair/replace components. However for all practical purposes, if a (update/patch/hacking) process can leave a device "permanently bricked", an end-user cannot recover from that state.
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.
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?
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.
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.
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.
>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.
Oh take your hand wringing and shove it.
How many man hours per capita per year are spent operating sketchy modified vehicles?
How many man hours per capita per year are spent driving distracted, intoxicated etc?
While they are not mutually exclusive the former is clearly a rounding error compared to the latter because the slice of the population that is even in a position to engage in it is minuscule compared to the broad mass market appeal of the latter. These people are no more of a concern to society than shark bites.
Before taking any anatomically adverse actions, I would need a better argument than whataboutism. The fact that something is statistically less likely than other bad things does not make it good.
> 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).
> 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.
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.
I've got to agree with this. While I am a fan of some of the assistances that come with vehicles, I am not a fan of the level of assistance some vehicles build in. I've lost power steering and powered brake assistance before (separate occasions), on different vehicles and while technically you still have steering or brakes (not drive by wire) , the loss of mechanical advantage is enough to mean you are effectively a passenger. While modern reliability has reduced the occurrence, the impact when that failure occurrs has only gotten worse.
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.
> 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?
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.
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.
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.)
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.
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.
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.
"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. :-)
This is timely! I just made the decision to buy a car (either a 2021 or 2022 Subaru WRX, most likely), and have been curious about hacking the ECU, CAN bus, etc.
I’m aware that tuning is a thing, but it’s generally not my scene. What I really want is to do the work myself instead of going to a tuner or buying one of those Cobb kits.
Can HN recommend any resources and/or other technically-oriented communities?
As far as I'm aware for Subarus, Taxtrix Openport 2.0[1] is popular with modders and seems to have good software/workflow.
Through this article though I discovered the Panda[2]. It reportedly does J2534 and I wonder if this means it can use the same workflow. The price of the white Panda is attractive.
I'm not sure if Openport is still actively developed. Oh, and stay away from the cheap clones. They're reportedly not good[3][4].
Does anyone have experience with the Pandas for remapping and use as a diagnostic tool?
Is there a place where one can download ECU mappings for various car models? Maybe this is silly, but it seems like there ought to be some kind of community-maintained repo, no?
I haven't had much luck. Sometimes you can find stuff with a search engine or PM someone on a forum with a similar setup and ask them nicely to share their tune. But it should be said, it can be dangerous to flash configs from random sources to your ECU.
I recently also rediscovered this (https://www.totalcardiagnostics.com/toad), which ostensibly "Contains 14,000+ optimized car ECU map files" and software to reflash. No idea on the quality or utility though.
Great write up! I am the author of the TP2.0 page you linked to. I went through a very similar process to you, ended up disassembling the code for a Siemens PPD ECU (PowerPC architecture from memory, it was about 10 years ago) so I could turn of the DPF regeneration functionality.
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.
I think the 6 minute timeout it could be a fallback mode in case the component sending the commands malfunctions and keeps spamming the same command in a loop over and over again.
Granted, if this happens while driving you're likely to have an accident anyway, but if you don't, then waiting 6 minutes would allow you to reclaim your steering for the rest of the journey.
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).
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.
> 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.
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?
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%.
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.