In the past few years, we’ve seen a growth in car hacking. Newer tools are being released, which makes it faster and cheaper to get into automotive tinkering. Today we’re taking a first look at the M2, a new device from the folks at Macchina.
The Macchina M1 was the first release of a hacker friendly automotive device from the company. This was an Arduino compatible board, which kept the Arduino form factor but added interface hardware for the protocols most commonly found in cars. This allowed for anyone familiar with Arduino to start tinkering with cars in a familiar fashion. The form factor was convenient for adding standard shields, but was a bit large for using as a device connected to the industry standard OBD-II connector under the dash.
The Macchina M2 is a redesign that crams the M1’s feature set into a smaller form factor, modularizes the design, and adds some new features. With their Kickstarter launching today, they sent us a developer kit to review. Here’s our first look at the device.
Two-Board Hardware Design
The M2 hardware consists of two main parts: the interface board and processor board.
On the interface board, you’ll find all the hardware needed to speak the most common automotive protocols. Here you’ll find two high speed CAN interfaces, one single wire interface, LIN, and the older OBD protocols (ISO 9141, J1850). This range of interfaces means that the hardware will be compatible with just about any car made after 1996. There’s also a header for providing other external connectivity to the MCU (GPIOs, ADCs, etc…).
The processor board is essentially an Arduino Due, with a USB port, LEDs, SD card slot, and EEPROM built in. The modular nature of the design allows for the processor board to be replaced or upgraded in the future. Finally, there’s an XBee compatible socket for adding Bluetooth, WiFi, or even cellular data.
There’s two form factors of the M2 available: under-the-hood and under-the-dash. The under-the-dash model is similar in form factor to any other OBD-II dongle. It fits right on the port, which provides power and connectivity. If you’re looking for a more permanent installation, the under-the-hood version has a connector for a custom wiring harness.
The Software
Fundamentally, this device is an Arduino. The getting started guide goes over installing the Arduino IDE, adding the custom board, and flashing a demo. If you’ve ever used an Arduino, this will be completely familiar. Dealing with these protocols requires libraries on the Arduino. Some of these are still works in progress, but the plan is to support all of them from within Arduino, so a simple sketch will be able to access any protocol.
If you’re planning on using a PC paired with the M2, there are some options. SavvyCAN is currently supported, and SocketCAN support is in the works, so it will work with Wireshark and other tools on Linux. The good news is that the open platform can be used to emulate just about any device, so with some work it could support many of the car hacking tools already out there.
Beyond supporting the aforementioned communication protocols, there’s not much software yet. Macchina is hoping to get developers on board with the hardware, and the first kits shipped will be to developers. While the software does not yet have a wide range of functionality, the open source nature of the project will hopefully expand the capabilities on the software.
Not an ELM327 Dongle
Every time we see an OBD-II dongle pop up, commenters are quick to point out that the ELM327 devices are readily available and very cheap. This is true, and I recommend that anyone with a car picks one up. They’re handy for checking basic codes, and clearing the “check engine” light (we call it the “Malfunction Indication Lamp” in automotive engineering speak).
The ELM327 is great for the price, but it has its shortcomings. Most communicate using ASCII over Bluetooth Serial Port Profile, which severely limits the data throughput and doesn’t work on iOS. The software cannot be customized. No on board storage is provided for logging. The Bluetooth pin is always 1234, so if you leave it plugged in, anyone walking by can do diagnostics on your car! The M2 does cost more than these devices, but it also addresses many of these problems.
Conclusions
The M2 is a nifty piece of new hardware for people that want to hack on cars. It’ll need some more work on the software side of things before it’s useable by the masses, but it’s basically ready for the hackers to start work with. The developer release is available for $99, and will get you early access to the beta hardware.
With this hardware, there’s many projects you could implement. It could act as a standalone, high speed vehicle data recorder. The under the dash model could be used to bridge a third party component onto a vehicle’s CAN bus — like this amazing custom head unit we saw yesterday — providing translation of the data needed for operation (steering wheel buttons, vehicle speed for volume adjust, etc.). Adding Bluetooth, you could have a custom immobilizer and remote control system for your car. Using cellular data, you could keep tabs on the whereabouts of a vehicle and even shut it down remotely.
We’re pretty careful about which crowdfunding campaigns we discuss here on Hackaday. Macchina does have a track record of delivering hardware, and has shipped us a beta unit that they will be providing to developers. The project is also open source, and we think it will help people get involved with car hacking. As such, we believe it’s a project worth sharing with our readers.
Great ad. Failed to explain why ELM327 has limited use. Overall, it looks like one of the cases where somebody thought “if we cram an arduino into it, it would make it a lot better, and people would buy it”. No it wont, and no, not for $99.
Hmm, bandwidth limitations, requires BT SPP support (eg, won’t work on iOS), unable to change the paring pin, cannot change firmware on the device, no SWCAN on LIN support, no onboard storage… I think those are some good reasons.
Furthermore, ISOTP (ISO 15765-2) transmissions are capped at 8 bits on the ELM327 which limits non-OBD-II diagnostics. The receive buffer is sufficiently small that a large ISOTP reception will cause an overrun, which is hard to get around since many ECUs do not properly support the ST_min and BS parameters of ISOTP. Oh, and the response pending NRC is not supported, which means any diagnostic functions using it will just fail.
Not working on iOS sounds like a feature to me
Well, that explains why i didn’t get any data out of that thing the other day.
Am i happy that that iphone is company paid.
My ELM adapter is a USB serial adapter … WTH would you want bluetooth with a fixed pin (and no pair button)?
Preach. Info should be added to OP.
Thanks for the honest feedback. Just a point of clarification though – the $99 level is for the “M2 Developer Edition” units that we have already manufactured and will ship right after the campaign is over. We’ll also send active developers the “Release” hardware for free, which would otherwise be $79.
Strangely that looks like a clone of the ancient, original ELM327 sold by suspect Chinese distributers. Rather than an actual ELM product.
I’m sure the differences are well documented elsewhere. https://en.m.wikipedia.org/wiki/ELM327
Most of the “ELM327” devices sold cost less than the ELM chip, so the knockoffs seem to have taken over the market.
Despite my best efforts, I haven’t been able to buy a device with a “genuine ELM327 chip.”
People claim to license the firmware, but I’ve spoken to Elm and they do not license firmware. The chip, which is a PIC18F with custom firmware, costs $15 in quantities of 1000. You can buy an entire dongle for less.
ELM has a pretty exhaustive list of people who sell their (and competing) products here: https://www.elmelectronics.com/help/obd/links/
I find it hard to believe they’re keeping folks who sell their product so close to the vest that you can’t buy a device using it.
And there’s always the same-protocol-capable STN1110 chip if you’re looking for a comparable competitor.
But yes. If you’d like you can buy an entire dongle from somewhere in the depths of Guandong with some sort of electronics in it. It may even work.
uh! free samples!
This is one of the better-known ones: http://www.carplugs.com/obd2iphone.html
Their iPhone app is also very good and is able to differentiate between Chinese clones and their product.
This is correct. The chip versions sold in China are actually clones of an old version of the ELM chip. Very old. The article is advocating buying stolen intellectual property.
This is true, and I recommend that anyone with a car picks one up. They’re handy for checking basic codes, and clearing the “check engine” light (we call it the “Malfunction Indication Lamp” in automotive engineering speak).
By recommending an old, stolen chip version, the author is also creating huge frustration for people with newer cars that have newer and faster protocols than the outdated chip version supported, thus lacking the capabilities of the newer chips.
Please everyone STOP buying and telling people to buy stolen IP from a very good US company.
ehhh actually ELM is based in Canada….
It is NOT stolen IP. ELM does not write open standards. ISO does!
“Using cellular data, you could keep tabs on the whereabouts of a vehicle and even shut it down remotely.”
Elaborate, please. I am not saying remote shutdown is not possible through just an OBD-II port but technically, it should not be part of the OBD-II interface as a standard feature on every vehicle unless I am missing something? Sure, you could add in such functionality in a host of different ways but through only an ODB-II port seems like a bit of a bold claim as a product feature.
This is neat hardware but I am currently struggling a bit to figure out exactly how it would be useful. Also, most OBD-II plugs are awkwardly placed such that having something continually plugged into them is really awkward and in the way.
I’m not advocating for this method, but crashing the HS bus on a GM vehicle (which is available on OBD-II) will at the least put the vehicle into a limp home mode. It will also prevent starting, and cause a bunch of fault codes.
Crashing the bus is as simple as: while(true) {send_frame_with_id_0();}
That’s due more to poor programming and isolation of systems (among other fundamental architectural actual flaws) rather than a specific intentional process though. “Officially”, the OBD-II port doesn’t support remote shutdown, right? I admit that my OBD-II work is somewhat limited and every manufacturer implements their own flavor of OBD-II anyway.
Officially, it supports the standard OBD-II modes and PIDs: https://en.wikipedia.org/wiki/OBD-II_PIDs
Practically, it provides connectivity to ECUs for diagnostic purposes, usually using Unified Diagnostic Services nowadays. This sometimes means direct access to the CAN bus used for engine control (like in the case of GM). So, there’s tons of possibilities if you’re willing to do some reverse engineering.
Yeah. Most vehicle manufacturers don’t isolate their main CAN bus.
Toyota and Subaru definitely don’t, and according to you, neither does GM.
That said, as far as the use case of putting a third-party component onto a vehicle’s CAN bus mentioned in the article, there are cheaper (but not ELM-clone-cheap) options like the CANTact and its clone, the CANable (wait, you’re the CANtact guy aren’t you?) that likely are also higher performance.
Considering that quote is taken from the end of a paragraph brainstorming potential projects, almost if not all, using additional components then there is your answer.
Also- I drive with an ELM-counterfeit plugged in all the time and never comes close to being in the way. Most OBD ports are mounted right below the dash- no way your legs should be that close.
So you are supposed to spend $100 on this and then add more components to it in order to do anything useful with it? Or does it have a wealth of functionality built in? When I spent time toying around with OBD-II hardware, the amount of things you actually could interface with was fairy limited. It’s neat that you can tell what the error codes your car is spitting out or do limited things like displaying audio tracks or maybe even accessing GPS info but the OBD-II interface is, theoretically, by design a fairly limited bus and to go much further starts to require some deeper levels of hardware hacking. Something that is beyond the scope of quick or easy.
The ELM327 Dongle is small though. This is more like sticking a DUE on the end of a ODB-II plug. It sticks out much further by design. Driving around with it in feels somewhat problematic is what I am getting at.
The location of OBD-II ports is absurdly varied. Most are in the general vicinity of the driver. Mostly. Maybe. I own several vehicles and the location of some of them would probably break a device like this just getting in and out of the vehicle due to location and size alone. The ELM327 dongle version would probably be ok but that’s not the form factor of this device.
Thinking about this as an OBD-II dongle is like thinking of a laptop as a VT100 emulator. Yeah, it can do that, but…
Speaking as an automotive electrical engineer, I was quick to dismiss this as yet another elm327 that can’t do anything interesting. But I clicked through, and found that it has multiple CAN channels, as well as GMLAN and LIN.
Get the “under-the-hood” version and you could wire it in between modules and do man-in-the-middle tricks like the CANBus Triple was designed to do. You can intercept, modify, translate, and whatever your heart desires. That’s incredibly more powerful than what’s come before.
When I was referring to this as a ODB-II dongle, I was more speaking to the form factor and not the capabilities of the unit as compared to a ELM327. Clearly, this can do considerably more. It just is quite bulky and given the location of most ODB-II ports, that could be a rather large issue that would prevent anyone from practically using this while driving.
Nate, great analogy. ELM327 is well known and we thought emulation would be a good way to take advantage of all those great apps out there (DashCommand, Torque, etc). It provides a good starting point, but we look forward to seeing a lot of other cool projects. I am personally interested in playing around with LIN more.
Wonder just how much mischief one could get into?
The bad thing about the usual elm327 dongle form-factor is, that there are cars where you’ll have a bad time getting that thing out of the bloody OBD2 port, e.g. Subarus. I had that issue with my now dead MY06 Impreza and my current MY00 Forester, because the port is recessed to a depth that _exactly_ matches the dongles height.
On one had, that’s quite nice as the dongle won’t ever be in my way. But on the other one has to remember that emissions testing (part of the inspection that has to be done every two years) is done via a special piece of hardware that gets its data via OBD2.
This one has an OBD port or “under the hood” option. Already backed.
My sample size does not consist of every passenger car ever made since 1996 here but unless I am incorrect, most every car lacks an “under the hood” means of EASILY plugging into OBD-II? I have never seen a SAE J1962 connector anywhere except inside the passenger compartment.
Generally speaking the newer the car, the more functions are exposed on a data bus that is on that port. On a large number of vehicles you’ll usually have a high speed bus for important stuff such as the engine, transmission, security/immobilizer, airbags, ABS, etc.. Then you have a lower speed ‘comfort bus’ for stuff such as HVAC, entertainment, interior lights, locks, windows. And depending on the vehicle occasionally a ‘gateway’ device or two that will communicate between networks and transfer data across. ie: vehicle speed from transmission to the entertainment system to facilitate speed adjusted volume.
Taking that into consideration, none of the major manufacturers have secured these buses. It is still ‘security by obscurity’ at this point. And it is completely read/write/execute. It is all down to reverse engineering for the most part. The most recent case with the proof of concept with Jeep/Chrysler vehicles and their Uconnect system and being able to shut down the vehicle remotely is a good example. The entertainment system is connected to the high speed bus in the vehicle and they were able to create a pinhole from the 3G connection and communicate to the high speed bus. Then it is as simple as sending a command to disable a portion of the vehicle. Usually these are commands that are normally reserved for diagnostic/testing purposes.
Also recall older GM On-star advertisements about being able to recover the vehicle from a theft including restricting engine speed and locking the 4-way flashers on to identify it from the exterior. All that is done remotely and just sending the appropriate commands to the vehicle buses that are easily available through that OBDII port.
It should also be noted that the cheap ELM327 clones are capable of doing all of this. To a point. As an anecdote I have a 2007 Ford Focus and one of these clone dongles. First model year that has CANbus tech. There’s software out there called ‘Forscan’ which has a lot of Ford specific diagnostic tools reverse engineered that only dealers usually have access to. One thing I had to do recently was program new spare keys to my car. This involves actually commanding the security module in the car itself to erase old keys and program new ones. All doable from a clone ELM327 dongle. Can also have various modules do self tests and on some newer vehicles, change certain hidden dealer only settings.
The main place the ELM327 dongles fall short is the bandwidth as mentioned. If you plan to do reverse engineering of any sort it is going to fall flat on its face. Most vehicles the low speed ‘comfort’ CANbus is around 250kbps, sometimes more. The ELM327 clones you are lucky to be able to push 25kbps or so. High speed CANbus speeds can go up to 1mbit or more. And there’s ton of data that flies across at all times even if the car is off.
As a last and final note: If you have watched Mr. Robot, recall the episode where they stole the minivan before heading off to Steel Mountain. The show is good about using real life tech and vulnerabilities. In this case after they were able to get inside the vehicle it was as simple as connecting to the OBDII port with the correct interface and essentially spoof the unsecured data going across and trick the car into believing a valid key was in range. And most modern cars that still have key based ignitions are no more than push button telling the PCM to start the engine. Again, a simple case of spoofing the correct data and telling it to start without a physical key present.
It depends on the manufacturer. For GM, I can definitely remotely shut down a car on demand.
OBD II is the diagnostics protocol which can run on top of the CAN bus, which exposes other things.
If you have an Etherne(tcp/ip) connection to use a web browser, it can also for example do SSH. CAN is the Ethernet(TCP/IP), OBD II is a web browser HTTP/S, so i could say crash your computer using the interface for SSH by attacking HTTP/S
Some CAN’s are isolated from non diagnostic, some aren’t however it doesn’t matter since most OEM’s do not correctly sanitise inputs so you can “make bad things happen”(tm) with some carefully crafted data, or just blast all over it like a script kiddo with LOIC.
Heck you can crash a lot of ECU’s just by making them think the RPM is higher than it is. They mostly work on a principle of if i got the data, its correct.
I’m not a big fan of the all the stuff on the OBDII plug style of interface for long term, but its a neat solution for some things. There are often alternative OBD II connectors.
And OBD II connectors are only mandated/defined partly, the OEM can choose to add or change interfaces on other pins,
Shutting it down remotely cleanly as in , turn off the engine is tougher, but it is doable.. One some cars I could just zero all your ignition fuel maps, or say partially so that when it goes below a certain RPM/speed the engine would just die.
Maybe with an ARM instead of a lame AVR, bad choice. But I will look into the ELM327, good tip.
Just like the Arduino Due, this appears to use a SAM3X8E ARM Cortex M3, not an AVR.
Almost retrotech as we will all be riding in electric self-driving vehicles any day now, no?
Jump into your self-driving
Johnny CabUber, crawl under the dash and plug this baby in. Boom… you’ve hacked your steering-wheel-less vehicle to be human driveable.I’m going to mark down the permalink to this comment and link back to it in 5 years when this hack actually happens.
Are you going to use another hack to interface your wireless steering wheel to it as well?
The thing’s got an expansion header on it. When Josh showed it to me a the OSH Park bring-a-hack he had an esp32 slotted in but take your pick (Bluetooth, 433 MHz, etc.
Don’t be silly, of course u would drive it with your VR unit
I like the reference to Hot-Rodding but that name is now virtually and forever entombed as it conjures up a V8 sometimes injected, usually carburetor absolutely minimal electronics type of engine. Now if they said Street Rodding or weekend track racer then there’s a place for messing with a vehicle’s engine management… As a Kickstarter I was all excited but then I couldn’t find if my car (European) is in the least compatible as candidate so that’s slowed me big time… oh and for some reason I keep reading Mac-China but in all this I wish the guys the best in their venture.
Pete, what sort of car do you have? I am willing to bet that M2 is compatible – we even have the old J1850 PWM/VPW circuitry built in. And yea, “Macchina” is sort of the Italian vernacular for “car” or more literally “machine”. Thanks for the well wishes – we really appreciate it!
Hello …i want make project to control bcm (body control module) like lock and unlock and turn flashing light and head light i can do that by macchina m2 ????but protocol is kwp2000 in obd2 to hyundai and kia 2012 models cars …
I feel this has potential but is uh…trying too hard?
I’ve done my fair share of “car hacking” which has turned into products sold in the automotive aftermarket. This device doesn’t even scratch the surface of being either hardware or software ready to support anything more than a shift light gadget.
I’m in the same boat with it. I think it definitely has a lot of capability, but anyone looking to make a commercial product will make their own product from the ground up. (e.g. cheaper in the long run) On the flip side, without have a large base of users that want to do the same thing with the product, it will be hard to get software support on the other end.
I think this will work well for one off solutions / prototyping; however, I don’t know if that market will be big enough to make this thing take off. (e.g. most people can do what they want with an ELM knock-off and existing software…)
HI? this looks great, i want to make my own version of it using only can transceiver and a sim868 for gsm and gps function, well, where can i find the schematic for this peace of art ? i want to see how it is done exactly,
thanks
Sounds like you want to make an autonomous GPS guided car bomb, Khalid Houssam. Might want to try a reword. No offense.
How the fuck is GPS supposed to work under the engine off a car anyway?
with an off board antenna. same way any car GPS works.
For the price.. I’d rather stick with a PiCAN (http://copperhilltech.com/pican-with-gps-can-bus-board-for-raspberry-pi/) over the Arduino. I’ve been playing the the can lines on a motorcycle for about a year now and the Pi is more flexible in what it can do over the Arduino.