Maybe helpful for people wanting to interface to ODB CANBUS

dmaxben

Member
The opposite side of the "it can't go wrong" coin are those who have demonstrated being able to take over system control via CANBUS in ways that could be catastrophic if done in a moving vehicle.

While this was done in terms of how someone could maliciously affect a system to which not having access would be a primary safeguard, once you facilitate access you open the door to malicious action both deliberately caused and unintentionally. Many things said to not be possible proved indeed to be possible.

The issue of 'fuzzing' is particularly relevant to damage a PICAXE or similar system could inflict; simply throwing inorrect packets on the bus causes some ptentially dangerous events to occur.


Full paper at http://www.autosec.org/pubs/cars-oakland2010.pdf, snippets below -

Reflashing ECUs While Driving. The standard also states that ECUs should reject reflashing events if they deem them unsafe. In fact, it states: “The engine control module should reject a request to initiate a programming event if the engine were running.” However, we experimentally verified that we could place the Engine Control Module (ECM) and Transmission Control Module (TCM) into reflashing mode when our car was at speed on jack stands. When the ECM enters this mode, the engine stops running. We also verified that we could place the ECM into reflashing mode while driving on the closed course.

Fuzzing. Much to our surprise, significant attacks do not require a complete understanding or reverse-engineering of even a single component of the car. In fact, because the range of valid CAN packets is rather small, significant damage can be done by simple fuzzing of packets (i.e., iterative testing of random or partially random packets). Indeed, for attackers seeking indiscriminate disruption, fuzzing is an effective attack by itself.

Brakes. Our fuzzing of the Electronic Brake Control Module allowed us to discover how to lock individual brakes and sets of brakes, notably without needing to unlock the EBCM with its DeviceControl key. In one case, we sent a random packet which not only engaged the front left brake, but locked it resistant to manual override even through a power cycle and battery removal. To remedy this, we had to resort to continued fuzzing to find a packet that would reverse this effect. Surprisingly, also without needing to unlock the EBCM, we were also able to release the brakes and prevent them from being enabled, even with car’s wheels spinning at 40 MPH while on jack stands.

Lights Out. Our analysis uncovered packets that can disable certain interior and exterior lights on the car. We combined these packets to disable all of the car’s lights when the car is traveling at speeds of 40 MPH or more, which is particularly dangerous when driving in the dark. This includes the headlights, the brake lights, the auxiliary lights, the interior dome light, and the illumination of the instrument panel cluster and other display lights inside the car.

Critical components, like the EBCM brake controller, are connected to the separate highspeed bus, with the Body Control Module (BCM) regulating access between the two buses. One might therefore assume that the devices attached to the low-speed bus, including aftermarket devices, will not be able to adversely impact critical components on the high-speed bus. Our experiments and analyses found this assumption to be false.
Honestly, that was written from a bit of a "doomsday"/paranoia/tin-foil-hat perspective. Those guys are completely exaggerating /blowing it out of proportion when they say "any idiot can randomly throw numbers at the bus and make the car spontaniously combust". They obviously have a LOT of background in GMLAN, and have done a TON of reverse engineering. Either that or their brother is a GM software engineer. Because GM guards all of the specs/white-papers/databus info on both GMLAN and Class 2 databusses with the utmost secrecy. I have an ELM322 and I once spent a whole weekend throwing random commands at my truck and I couldnt get it to do anything more than lock the doors, put the windows up and down, and chime. All of the "wrong" commands I sent were simply ignored and worst case scenario, the door locks would stop working and I would have to cycle the ignition.

"jam the door locks by repeatedly sending a lock command". Give me a break. Even a 6-year old has enough strength to force the door lock open and overpower the door lock motor.

Basically, that whole article needs to be taken with a HUGE HUGE grain of salt.
 

hippy

Technical Support
Staff member
Basically, that whole article needs to be taken with a HUGE HUGE grain of salt.
I guess it really comes down to whether they were lying or did actually achieve the effects they claim. And if one believes they achieved it then whether one believes the same could be achieved using a PICAXE or other micro.
 

dmaxben

Member
I can only point to the link in an earlier post and what the researchers demonstrated there ...



It's not so much that a vehicle bus system isn't sound or resilient in itself, it's more what can happen when a controller, PICAXE or other, is introduced into that system.

The researchers were deliberately injecting 'dodgy packets' into the system to achieve their results but it's no different to a PICAXE unintentionally injecting the same with the same results. If their controller can instruct one wheel to lock at speed or completely disable braking then there's a definite risk that a PICAXE or any other micro could do the same.

I'm sure no one deliberately designs any system to put themselves in danger but the issue is what happens when someone does by accident or error or even through issues they have no direct control of ?
True, but They stated (in a roundabout way, reading between the lines) that they had to completely dump all of the code out of the EBCM, break it down, UNLOCK it, do the hokey-pokey, reflash it back in, then unlock it again before they could get it to apply the brakes when NOT on jack stands. And even then....cars have parking brakes/emergency brakes....

and the whole thing about stability control systems "correcting the steering" is another thing that they are twisting around to make it sound worse "scarier" than it is. ESC systems "steer" (and I use that term lightly, any action the driver makes with the steering wheel can overpower a stability control's attempt to "STEER") using differential braking.

Basically, these guys are genius computer crackers who had to work on this project for a long time, ascertain outside help (whether it was some advice from someone at GM who knows GMLAN or what) to garner the results they were after....They even stated that it took days to crack the EBCM seed/key. Days of actively working at a project with a significant background in GMLAN protocol and thousands of dollars of CAN hardware and sniffer software is probably not something that can be duplicated with a hobbyist and his PICAXE "just by accident".

So basically...Id be willing to bet a PICAXE interfaced with an ELM chip doesnt even have enough memory/physical capability to do anything more than maybe send some ASCII text to the driver info center or maybe lock the doors... As I said, ive used an ELM interface with my laptop to try to send some commands...for starters the ELM has its own filtering built in, and everything else that I tried to send to the vehicle, was just ignored.

US Military/pentagon security could also be cracked with enough time on someones hands...and other things....such as with the new ADS-B standards for aircraft guidance and transponders that are going to be mandated by 2020 I think, its "THEORETICALLY" possible to "hack" into the fly-by-wire/FADEC system on an aircraft and make it crash.....but is it likely? Of course not. Not in the real world. :)

At the risk of overstepping, I dont want to get into too heated an argument here, but I just wanted to add some input from a more "car-based" point of view/opinion. Granted, Im not saying I would ever try something like this (PICAXE to car), simply because I dont posses the knowledge to even know where to begin..

Ben
 
Last edited:

Michael V

Senior Member
I know i'm a bit late on this but i would dearly like to make usse of a CAN "highway" that is already in place in a large piece of earthmoving equipment. This is mainly to save cabling, and ease of instalation. Surely there is a safe way to do ths? If i can connect say a temperature or pressure sensor to a picaxe, then a MCP2551 CAN bus driver chip, then a physical connection to the bus, and get the data "off "elsewhere on the bus also with a driver chip and picaxe, or a Can to computer dongle, then that saves a lot of really expensive automotive quality cable and cable ties and time and inconvenience. It would allow me to do what was otherwise impractical to do. Is there not a safe way to do this?

Or what about just making your own bus? The MCP2551 CAN driver chips are cheap enough at about $2 each.

There are also these things:
http://gridconnect.com/rs232-can-converter.html
http://www.canautomotion.com.au/pages/IXXAT/IXXAT CANlink II.html
http://www.can232.com/


They don't seem particularly worried about what goes on the bus - maybe all the safety aspects are all managed in the device? But these things start at about $150.

If a picaxe can just use the MCP2551 and connect to a whole bunch of other picaxes operating indempendently on the same wire, and the $2 chip manages the potential data conflicts, then that could be a very useful tool. Has anyone done anything like this? I've searched for any info on this and haven't been successful.
 

B4Lamb

Member
Jeremy Harris' posts make perfect sense to me as a designer of military safety critical systems and on Canbus systems used on military marine
Craft engine control systems.
 

B4Lamb

Member
It would seem to me to be advantageous to use one of the cheap OBDll to Bluetooth scanners and interface to a PICAXE with a Blue tooth receiver tranceiver rather than start from scratch with the ELM 327 chip and MCP2551 interface chip. Mainly to reduce cabling from the OBDll socket which is normally tucked near the foot well on the drivers side. Either that or use a low profile 90 degree OBDll plug to socket extension lead available for about 3 quid on ebay. Maybe hacking into one of these OBDll scanner modules to gain access to the ELM 327 pins is also a low cost option as a starting point? I'd be interested to know if anyone has successfully used the ELM 327 and a picaxe to monitor and display sensor data.
 
Top