Roll A Black Box For Your Wheels

Telemetric devices for vehicles, better known as black boxes, cracked the consumer scene 25 years ago with the premiere of OnStar. These days, you can get one for free from your insurance company if you want to try your luck at the discounts for safe driving game. But what if you wanted a black box just to mess around with that doesn’t share your driving data with the world? Just make one.

[TheForeignMan]’s DIY telematics box was designed to pull reports of the car’s RPM, speed, and throttle depression angle through the ODBII port. An ODBII-to-Bluetooth module sends the data to an Arduino Mega and logs it on an SD card along with latitude and longitude from a NEO-6M GPS module. Everything is powered by the car’s battery through a cigarette lighter-USB adapter.

He’s got everything tightly wrapped up inside a 3D printed box, which makes it pretty hard to retrieve the SD card. In the future, he’d like to send the data to a server instead to avoid accidentally dislodging a jumper wire.

If this one isn’t DIY enough for you to emulate, start by building your own CAN bus reader.

Know Thy LED

The invention of the LED is one of the most important discoveries of our times. They are everywhere, from our flashlights to household lighting and television sets. We don’t need to tell you that a project with more blinkies is better than a project with fewer blinkies. But an LED is not simply an LED; the sheer variety of LEDs is amazing, and so in this write-up, we’ll take a closer look at how to choose the right LED for your next masterpiece. Continue reading “Know Thy LED”

A Live ECU Simulator For OBD2 Projects

If you are working with OBD2 hardware or software, it’s easy enough to access test data, simply plug into a motor vehicle with an OBD2 socket. If, however, you wish to test OBD2 software under all possible fault conditions likely to be experienced by an engine, you are faced with a problem in that it becomes difficult to simulate all faults on a running engine without breaking it. This led [Fixkick] to create an OBD2 simulator using a secondhand Ford ECU supplied with fake sensor data from an Arduino to persuade it that a real engine was connected.

The write-up is quite a dense block of text to wade through, but if you are new to the world of ECU hacking it offers up some interesting nuggets of information. In it there is described how the crankshaft and camshaft sensors were simulated, as well as the mass airflow sensor, throttle position, and speedometer sensors. Some ECU inputs require a zero-crossing signal, something achieved with the use of small isolating transformers. The result is a boxed up unit containing ECU and Arduino, with potentiometers on its front panel to vary the respective sensor inputs.

We’ve brought you quite a few OBD2 projects over the years, for example, there was this LED tachometer, and a way into GM’s OnStar.

Thanks [darkspr1te] for the tip.

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”