Follow-up: Hacking OnStar

Reader [regulatre] has provided us with his furthering of hacking the OnStar system in GM cars. Previously, we wrote about some initial attempts to gain access to the system that OnStar uses to monitor and control cars called GMLAN. [regulatre] has managed to create an adapter between the GMLAN connector and a standard OBD2 plug, which should allow a number of standard readers to be able to retrieve data.

This method details using a bluetooth OBD2 reader, and passing the data onto a linux machine. It looks as though the writer of this method is looking to integrate OnStar reading and writing into an Android App which currently is an OBD monitor.

We love seeing follow-ups like this, because it puts everyone one step closer to full control of closed devices. As always, let us know if you take any of this in a new direction.

Hacking the OnStar GPS v2

[Andy] has provided us with his new guide to hacking the OnStar GPS. Previously, we have covered a way to grab the GPS data from an unused OnStar system, however in recent years GM has added much more complex systems, which make it harder than swapping out a serial line. For the new version, [Andy] has figured out GM’s Controller Area Network (CAN), which they call GMLAN. He has also done most of the software snooping and sleuthing, and has mostly solved GMLAN’s method of announcing GPS data. There is sample code available to convert this information into generic latitude and longitude.

Unfortunately for the project, (and very fortunately for [Andy]), he has a child on the way and new job responsibilities, so he is offering up his results to the HaD community to finish up, double check, and provide a good how-to for everyone else. To anyone who decides to pick up this project and run with it, let us know!

gm onstar hacking

onstar serial hack

this site shows you how to jack in to the gps receiver inside any gm onstar system.  it’s as simple as soldering a up a serial cable.  you can then connect to it and either run some gps diagnostic software, or switch the device to nmea mode so that you can use it with your gps mapping software in your car pc.

if you’ve got an onstar system but aren’t paying for the service this might be just the hack for you.  thanks for the link leo!

Continue reading “gm onstar hacking”

Your Next Desktop… QNX?

QNX has a long checkered history as an embedded operating system. QNX was always famous for being a real time operating system with a microkernel architecture. That is, kernel functions run as a set of coordinated tasks instead of as a single piece of code. A recent release of QNX 7 (see video, below) allows it to run on 64-bit desktop computers and [elahav] decided to tackle turning this embedded RTOS into a desktop operating system.

That might sound far-fetched, but QNX is a POSIX-compliant system and has all the features you’d expect in a system like Linux or BSD. It just isn’t aimed at the desktop market and therefore doesn’t have a lot of tools for running the desktop. QNX isn’t the kind of RTOS you’ll find on an Arduino. It is more common in things like automobile systems (for example, it runs General Motor’s OnStar system).

He started with a mini ITX board and installed QNX. Usually, you develop for an embedded system on a workstation and then just ship the code over to the target system, but [elahav] took the time to get a build system working on the target. There was one problem. The built-in vi editor was primitive by modern standards. He is usually an emacs user, but even vim would be better than the “stock” vi. While an emacs port would be possible, it would also require porting over a lot of libraries, so his first project was to get the vim source code to compile.

Turned out not to be as easy as he had hoped. The build system expected certain GNU tools that didn’t exist yet (although standard versions of the tools, like grep, did exist). So he had to figure out how to cross compile vim. In retrospect, [elahav] decided he should have just ported the GNU tools first. He did have to remove some old code from vim that was aimed at an older version of QNX.

Continue reading “Your Next Desktop… QNX?”

Books You Should Read: The Car Hacker’s Handbook

I just had my car in for an inspection and an oil change. The garage I take my car to is generally okay, they’re more honest than a stealership, but they don’t cross all their t’s and dot all their lowercase j’s. A few days after I picked up my car, low and behold, I noticed the garage didn’t do a complete oil change. The oil life indicator wasn’t reset, which means every time I turn my car on, I’ll have to press a button to clear an ominous glowing warning on my dash.

For my car, resetting the oil life indicator is a simple fix – I just need to push the button on the dash until the oil life indicator starts to blink, release, then hold it again for ten seconds. I’m at least partially competent when it comes to tech and embedded systems, but even for me, resetting the oil life sensor in my car is a bit obtuse. For the majority of the population, I can easily see this being a reason to take a car back to the shop; the mechanic either didn’t know how to do it, or didn’t know how to use Google.

The two most technically complex things I own are my car and my computer, and there is much more information available on how to fix or modify any part of my computer. If I had a desire to modify my car so I could read the value of the tire pressure monitors, instead of only being notified when one of them is too low, there’s nowhere for me to turn.

2015 was the year of car hacks, ranging from hacking ECUs to pass California emissions control standards, Google and Tesla’s self-driving cars, to hacking infotainment systems to drive reporters off the road. The lessons learned from these hacks are a hodge-podge of forum threads, conference talks, and articles scattered around the web. While you’ll never find a single volume filled with how to exploit the computers in every make and model of automobile, there is space for a reference guide on how to go about this sort of car hacking.

I was given the opportunity to review The Car Hacker’s Handbook by Craig Smith (259p, No Starch Press). Is it a guide on how to plug a dongle into my car and clear the oil life monitor the hard way? No, but you wouldn’t want that anyway. Instead, it’s a much more informative tome on penetration testing and reverse engineering, using cars as the backdrop, not the focus.

Continue reading “Books You Should Read: The Car Hacker’s Handbook”

2015: As the Hardware World Turns

A few hours from now, the ball will drop in Times Square. 2015 is over, and the good news is you can easily turn a handwritten ‘5’ into a ‘6’. Keep that in mind for the next few weeks. It’s time for a retrospective of everything that happened in 2015. That’s rather boring, though, and it’s usually better to put the most outrageous items in the lede. Therefore, it’s time for predictions of what will happen over the next 366 days. They are, in order:

  • 2016 will be the year of the Linux desktop
  • Self-driving cars will be demonstrated
  • Graphene! Something to do with graphene!
  • Your company will receive a resume with ‘Bitcoin’ listed as a skill
  • Fusion power is only nine years away

With that said, a lot happened this year. Tiny Linux single board computers became incredibly cheap, Radio Shack died, and Arduino went crazy.

Continue reading “2015: As the Hardware World Turns”

The Year of the Car Hacks

With the summer’s big security conferences over, now is a good time to take a look back on automotive security. With talks about attacks on Chrysler, GM and Tesla, and a whole new Car Hacking village at DEF CON, it’s becoming clear that autosec is a theme that isn’t going away.

Up until this year, the main theme of autosec has been the in-vehicle network. This is the connection between the controllers that run your engine, pulse your anti-lock brakes, fire your airbags, and play your tunes. In most vehicles, they communicate over a protocol called Controller Area Network (CAN).

An early paper on this research [PDF] was published back in 2010 by The Center for Automotive Embedded Systems Security,a joint research effort between University of California San Diego and the University of Washington. They showed a number of vulnerabilities that could be exploited with physical access to a vehicle’s networks.

A number of talks were given on in-vehicle network security, which revealed a common theme: access to the internal network gives control of the vehicle. We even had a series about it here on Hackaday.

The response from the automotive industry was a collective “yeah, we already knew that.” These networks were never designed to be secure, but focused on providing reliable, real-time data transfer between controllers. With data transfer as the main design goal, it was inevitable there would be a few interesting exploits.

Continue reading “The Year of the Car Hacks”