32C3: Dieselgate — Inside The VW’s ECU

December 31, 2015 by Elliot Williams 67 Comments

[Daniel Lange] and [Felix Domke] gave a great talk about the Volkswagen emissions scandal at this year’s Chaos Communication Congress (32C3). [Lange] previously worked as Chief architect of process chain electronics for BMW, so he certainly knows the car industry, and [Domke] did a superb job reverse-engineering his own VW car. Combining these two in one talk definitely helps clear some of the smog around the VW affair.

[Lange]’s portion of the talk basically concerns the competitive and regulatory environments that could have influenced the decisions behind the folks at VW who made the wrong choices. [Lange] demonstrates how “cheating” Europe’s lax testing regime is fairly widespread, mostly because the tests don’t mimic real driving conditions. But we’re not sure who’s to blame here. If the tests better reflected reality, gaming the tests would be the same as improving emissions in the real world.

As interesting as the politics is, we’re here for the technical details, and the reverse-engineering portion of the talk begins around 40 minutes in but you’ll definitely want to hear [Lange]’s summary of the engine control unit (ECU) starting around the 38 minute mark.

[Domke] starts off with a recurring theme in our lives, and the 32C3 talks: when you want to reverse-engineer some hardware, you don’t just pull the ECU out of your own car — you go buy another one for cheap online! [Domke] then plugged the ECU up to a 12V power supply on his bench, hooked it up, presumably to JTAG, and found a bug in the firmware that enabled him to dump the entire 2MB of flash ROM into a disassembler. Respect! His discussion of how the ECU works is a must. (Did you know that the ECU reports a constant 780 RPM on the tacho when the engine’s idling, regardless of the actual engine speed? [Domke] has proof in the reverse-engineered code!)

The ECU basically takes in data from all of the car’s sensors, and based on a number of fixed data parameters that physically model the engine, decides on outputs for all of the car’s controls. Different car manufacturers don’t have to re-write the ECU code, but simply change the engine model. So [Domke] took off digging through the engine model’s data.

Long story short, the driving parameters that trigger an emissions reduction exactly match those that result from the EU’s standardized driving schedule that they use during testing — they’re gaming the emissions tests something fierce. You’ve really got to watch the presentation, though. It’s great, and we just scratched the surface.

And if you’re interested in our other coverage of the Congress, we have quite a collection going already.

Must-Have Overkill Christmas Tree Lights

December 30, 2015 by Elliot Williams 9 Comments

The yuletide fire is out, so we’re starting to receive this year’s Christmas hacks. [Chris] sent us his awesome video-mapped tree lighting hack. His project made clever use of a bunch of cool tools, so even if you’re not thinking forward to next December, it’s worth a look. Still images don’t do it justice; check out the video below the break.

The end result is an addressable string of WS2812B LEDs connected up to a Raspberry Pi Zero that can display a video image even though it’s wrapped around a roughly cone-shaped (pine) object. But this is actually more impressive than you’d think at first; how would you map a flat image to a string of LEDs wrapped around a tree?

[Chris]’s solution was to write a routine that lit up the LEDs in a unique pattern and then detected them using OpenCV and a webcam, making the mapping directly. He then samples images from a video at exactly the points where the pixels are located on the tree, and sends this data out to the LEDs.

The basic framework here should transform fairly easily into a generic image-mapping procedure with randomly located LEDs, so we think it’s a hack that’ll outlast the season. And because it runs on the Pi Zero, everything is in Python so it’d be a good project for beginners to replicate. However, the code section on the project page still lists it as coming soon. We hope so!

Continue reading “Must-Have Overkill Christmas Tree Lights” →

32C3: Shopshifting — Breaking Credit Card Payment Systems

December 30, 2015 by Elliot Williams 19 Comments

Credit card payment systems touch all of our lives, and because of this there’s a lot riding on the security of that technology. The best security research looks into a widely deployed system and finds the problems before the bad guys do. The most entertaining security presentations end up finding face-palmingly bad practices and having a good laugh along the way. The only way to top that off is with live demos. [Karsten Nohl], [Fabian Bräunlein], and [dexter] gave a talk on the security of credit-card payment systems at the 32nd annual Chaos Communications Congress (32C3) that covers all the bases.

While credit card systems themselves have been quite well-scrutinized, the many vendor payment networks that connect the individual terminals haven’t. The end result of this research is that it is possible to steal credit card PINs and remotely refund credits to different cards — even for purchases that have never been made. Of course, the researchers demonstrate stealing money from themselves, but the proof of concept is solid. How they broke two separate payment systems is part hardware hacking, part looking-stuff-up-on-the-Internet, and part just being plain inquisitive.

Continue reading “32C3: Shopshifting — Breaking Credit Card Payment Systems” →

32C3: Beyond Your Cable Modem

December 29, 2015 by Elliot Williams 20 Comments

[Alexander Graf] gave an absolutely hilarious talk at 32C3 about the security flaws he found in cable modems from two large German ISPs. The vulnerability was very serious, resulting in remote root terminals on essentially any affected cable modem, and the causes were trivial: unencrypted passwords in files that are sent over TFTP or Telnet to the modems, for instance.

While [Alexander] was very careful to point out that he’d disclosed all of these vulnerabilities to the two German cable ISPs that were affected, he notably praised one of them for its speedy response in patching up the holes. As for the other? “They’d better hurry up.” He also mentions that, although he’s not sure, he suspects that similar vulnerabilities are present in other countries. Oh dear.

A very interesting point in the talk is the way that [Alexander] chose to go about informing the cable ISPs. Instead of going to them directly and potentially landing himself in jail, he instead went to the press, and let his contacts at the press talk to the ISPs. This both shielded him from the potential initial heat and puts a bit of additional pressure on the ISPs to fix the vulnerability — when the story hits the front page, they would really like to be ahead of the problem.

There’s even a bone for you die-hard hardware hackers out there who think that all of this software security stuff is silly. To get the modem’s firmware in the first place, at minute 42 of the talk, [Alexander] shows briefly how he pulled the flash chip off the device and read it into his computer using a BeagleBone Black. No JTAG, no nothing. Just pulling the chip off and reading it the old-fashioned way.

If you’ve got an hour, go watch [Alexander]’s talk. It’s a fun romp through some serious vulnerabilities.

32C3: A Free And Open Source Verilog-to-Bitstream Flow For ICE40 FPGAs

December 29, 2015 by Elliot Williams 10 Comments

[Clifford] presented a fully open-source toolchain for programming FPGAs. If you don’t think that this is an impressive piece of work, you don’t really understand FPGAs.

The toolchain, or “flow” as the FPGA kids like to call it, consists of three parts: Project IceStorm, a low-level tool that can build the bitstreams that flip individual bits inside the FPGA, Arachne-pnr, a place-and-route tool that turns a symbolic netlist into the physical stuff that IceStorm needs, and Yosys which synthesizes Verilog code into the netlists needed by Arachne. [Clifford] developed both IceStorm and Yosys, so he knows what he’s talking about.

What’s most impressive is that FPGAs aren’t the only target for this flow. Because it’s all open source and modifiable, it has also been used for designing custom ASICs, good to know when you’re in need of your own custom silicon. [Clifford]’s main focus in Yosys is on formal verification — making sure that the FPGA will behave as intended in the Verilog code. A fully open-source toolchain makes working on this task possible.

If you’ve been following along with [Al Williams]’s FPGA posts, either this introduction or his more recent intermediate series that are also based on the relatively cheap Lattice iCEStick development kit, this video is a must-watch. It’s a fantastic introduction to the cutting-edge in free FPGA tools.

What Can Happen When You Do Try This At Home

December 28, 2015 by Elliot Williams 25 Comments

In somewhat of a countdown format, [John McMaster] looked back over the last few years of projects and documented the incidents he’s suffered (and their causes) in the course of doing cool stuff.

[John] starts us off easy — mis-wiring and consequently blowing up a 400V power supply. He concludes “double-check wiring, especially with high power systems”. Other tips and hazards involve situations in which we seldom find ourselves: “always check CCTV” before entering the experiment chamber of a cyclotron to prevent getting irradiated. Sounds like good advice.

[John] also does a lot of IC decapping, which can involve both heat and nasty acids. His advice includes being ready for large spills with lots of baking soda on hand, and he points out the need to be much more careful with large batches of acid than with the usual smaller ones. Don’t store acid in unfamiliar bottles — all plastics aren’t created equal — and don’t store any of it in your bedroom.

The incidents are listed from least to most horrible, and second place goes to what was probably a dilute Hydrofluoric acid splash. Keyword: necrosis. First place is a DIY Hydrochloric acid fabrication that involves, naturally, combining pure hydrogen and chlorine gas. What could possibly go wrong?

Anyway, if you’re going to do “this” at home, and we know a bunch of you are: be careful, be protected, and be prepared.

Thanks [J. Peterson] for the tip!

V8 Javascript Fixes (Horrible!) Random Number Generator

December 28, 2015 by Elliot Williams 59 Comments

According to this post on the official V8 Javascript blog, the pseudo-random number generator (PRNG) that V8 Javascript uses in Math.random() is horribly flawed and getting replaced with something a lot better. V8 is Google’s fast Javascript engine that they developed for Chrome, and it’s used in Node.js and basically everywhere. The fact that nobody has noticed something like this for the last six years is a little bit worrisome, but it’s been caught and fixed and it’s all going to be better soon.

In this article, I’ll take you on a trip through the math of randomness, through to pseudo-randomness, and then loop back around and cover the history of the bad PRNG and its replacements. If you’ve been waiting for an excuse to get into PRNGs, you can use this bizarre fail and its fix as your excuse.

But first, some words of wisdom:

Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. For, as has been pointed out several times, there is no such thing as a random number — there are only methods to produce random numbers, and a strict arithmetic procedure of course is not such a method.
John von Neumann

John von Neumann was a very smart man — that goes without saying. But in two sentences, he conveys something tremendously deep and tremendously important about random variables and their mathematical definition. Indeed, when you really understand these two sentences, you’ll understand more about randomness than most everyone you’ll meet.

Continue reading “V8 Javascript Fixes (Horrible!) Random Number Generator” →