A car is a rolling pile of hundreds of microcontrollers these days — just ask any greybeard mechanic and he’ll start his “carburetor” rant. All of these systems and sub-systems need to talk to each other in an electrically hostile environment, and it’s not an exaggeration to say that miscommunication, or even delayed communication, can have serious consequences. In-car networking is serious business. Mass production of cars makes many of the relevant transceiver ICs cheap for the non-automotive hardware hacker. So why don’t we see more hacker projects that leverage this tremendous resource base?
The backbone of a car’s network is the Controller Area Network (CAN). Hackaday’s own [Eric Evenchick] is a car-hacker extraordinaire, and wrote up most everything you’d want to know about the CAN bus in a multipart series that you’ll definitely want to bookmark for reading later. The engine, brakes, doors, and all instrumentation data goes over (differential) CAN. It’s fast and high reliability. It’s also complicated and a bit expensive to implement.
In the late 1990, many manufacturers had their own proprietary bus protocols running alongside CAN for the non-critical parts of the automotive network: how a door-mounted console speaks to the door-lock driver and window motors, for instance. It isn’t worth cluttering up the main CAN bus with non-critical and local communications like that, so sub-networks were spun off the main CAN. These didn’t need the speed or reliability guarantees of the main network, and for cost reasons they had to be simple to implement. The smallest microcontroller should suffice to roll a window up and down, right?
In the early 2000s, the Local Interconnect Network (LIN) specification standardized one approach to these sub-networks, focusing on low cost of implementation, medium speed, reconfigurability, and predictable behavior for communication between one master microcontroller and a small number of slaves in a cluster. Cheap, simple, implementable on small microcontrollers, and just right for medium-scale projects? A hacker’s dream! Why are you not using LIN in your multiple-micro projects? Let’s dig in and you can see if any of this is useful for you. Continue reading “Embed With Elliot: LIN is for Hackers”
Getting cryptography right isn’t easy, and it’s a lot worse on constrained devices like microcontrollers. RAM is usually the bottleneck — you will smash your stack computing a SHA-2 hash on an AVR — but other resources like computing power and flash code storage space are also at a premium. Trimming down a standard algorithm to work within these constraints opens up the Pandora’s box of implementation-specific flaws.
NIST stepped up to the plate, starting a lightweight cryptography project in 2013 which has now come out with a first report, and here it is as a PDF. The project is ongoing, so don’t expect a how-to guide. Indeed, most of the report is a description of the problems with crypto on small devices. Given the state of IoT security, just defining the problem is a huge contribution.
Still, there are some concrete recommendations. Here are some spoilers. For encryption, they recommend a trimmed-down version of AES-128, which is a well-tested block cipher on the big machines. For message authentication, they’re happy with Galois/Counter Mode and AES-128.
I was most interested in hashing, and came away disappointed; the conclusion is that the SHA-2 and SHA-3 families simply require too much state (and RAM) and they make no recommendation, leaving you to pick among less-known functions: check out PHOTON or SPONGENT, and they’re still being actively researched.
If you think small-device security is easy, read through the 22-question checklist that starts on page twelve. And if you’re looking for a good starting point to read up on the state of the art, the bibliography is extensive.
Your tax dollars at work. Thanks, NIST!
And thanks [acs] for the tip!
We have a love-hate relationship with biometric ID. After all, it looks so cool when the hero in a sci-fi movie enters the restricted-access area after having his hand and iris scanned. But that’s about the best you can say about biometric security. It’s conceptually flawed in a bunch of ways, and nearly every implementation we’ve seen gets broken sooner or later.
Case in point: prolific anti-biometry hacker [starbug] and a group of friends at the Berlin CCC are able to authenticate to the “Samsung Pay” payment system through the iris scanner. The video, embedded below, shows you how: take a picture of the target’s eye, print it out, and hold it up to the phone. That was hard!
Sarcasm aside, the iris sensor uses IR to recognize patterns in your eye, so [starbug] and Co. had to use a camera with night vision mode. A contact lens placed over the photo completes the illusion — we’re guessing it gets the reflections from room lighting right. No etching fingerprint patterns into copper, no conductive gel — just a printout and a contact lens.
Continue reading “Fooling Samsung Galaxy S8 Iris Recognition”
[Alberto Piganti], aka [pighixxx] has been making circuit diagram art for a few years now, and has just come out with a book that’s available on Kickstarter. He sent us a copy to review, and we spent an hour or so with a refreshing beverage and a binder full of beautiful circuit diagrams. It doesn’t get better than that!
[pighixxx] started out making very pretty and functional pinout diagrams for a number of microcontrollers, and then branched out to modules and development boards like the Arduino and ESP8266. They’re great, and we’ll admit to having a printout of his SMD ATMega328 and the ESP-12 on our wall. His graphical style has been widely copied, which truly is the sincerest form of flattery.
But after pinouts, what’s next? Fully elaborated circuit diagrams, done in the same style, of course. “ABC: Basic Connections” started out life as a compendium of frequently used sub-circuits in Arduino projects. But you can take “Arduino” with a grain of salt — these are all useful for generic microcontroller-based projects. So whether you want to drive a 12 V solenoid from a low-voltage microcontroller, drive many LEDs with shift registers, or decode a rotary encoder, there is a circuit snippet here for you. Continue reading “First Look at ABC: Basic Connections”
Raindrops on roses, and whiskers on kittens? They’re alright, I suppose. But when it comes down to it, I’d probably rather have a bunch of 4051, 4052, and 4053 analog multiplexers on the component shelf. Why? Because the ability to switch analog signals around, routing them at will, under control of a microcontroller is tremendously powerful.
Whether you want to read a capacitive-sensing keyboard or just switch among audio signals, nothing beats a mux! Read on and see if you agree.
Continue reading “A Few of Our Favorite Chips: 4051 Analog Mux”
These are the Golden Years of electronics hacking. The home DIY hacker can get their hands on virtually any part that he or she could desire, and for not much money. Two economic factors underlie this Garden of Electronic Eden that we’re living in. Economies of scale make the parts cheap: when a factory turns out the same MEMS accelerometer chip for hundreds of millions of cell phones, their setup and other fixed costs are spread across all of these chips, and a $40 million factory ends up only costing $0.50 per unit sold.
But the unsung hero of the present DIY paradise is how so many different parts are available, and from so many different suppliers, many of them on the other side of the globe. “The Internet” you say, as if that explains it. Well, that’s not wrong, but it’s deeper than that. The reason that we have so much to choose from is that the marginal cost of variety has fallen, and with that many niche products and firms have become profitable where before they weren’t.
So let’s take a few minutes to sing the praises of the most important, and sometimes overlooked, facet of the DIY economy over the last twenty years: the falling marginal cost of variety.
Continue reading “The Long Tail of DIY Electronics”
[Alexander Reben] makes tech art, and now he’s encouraging you to do the same — within a URL. The gimmick? Making the code small enough to fit the data portion of a link. And to help with that, he has set up a webpage that uncompresses and wraps code from the URL and inserts it into the HTML on the fly. His site essentially applies or un-applies all the tricks of JS minification in the URL, and turns that into content.
So, for instance,
Something strikes us as fishy about passing JS code opaquely in links, but since the URL decodes on [Alexander]’s server, we don’t see the XSS attack just yet. If you can find the security problem with this setup, or better yet if you write up a nice animation, let us know in the comments.