Free As In Beer, Or The Story Of Windows Viruses

July 5, 2017 by Elliot Williams 211 Comments

Whenever there’s a new Windows virus out there wreaking global havoc, the Linux types get smug. “That’ll never happen in our open operating system,” they say. “There are many eyes looking over the source code.” But then there’s a Heartbleed vulnerability that keeps them humble for a little while. Anyway, at least patches are propagated faster in the Linux world, right?

While the Linuxers are holier-than-thou, the Windows folks get defensive. They say that the problem isn’t with Windows, it’s just that it’s the number one target because it’s the most popular OS. Wrong, that’d be Android for the last few years, or Linux since forever in the server space. Then they say it’s a failure to apply patches and upgrade their systems, because their users are just less savvy, but that some new update system will solve the problem.

There’s some truth to the viruses and the patching, but when WannaCry is taking over hospitals’ IT systems or the radiation monitoring network at Chernobyl, it’s not likely to be the fault of the stereotypical naive users, and any automatic patch system is only likely to help around the margins.

So why is WannaCry, and variants, hitting unpatched XP machines, managed by professionals, all over the world? Why are there still XP machines in professional environments anyway? And what does any of this have to do with free software? The answer to all of these questions can be found in the ancient root of all evil, the want of money. Linux is more secure, ironically, at least partly because it’s free as in beer, and upgrading to a newer version is simply cheaper.

Continue reading “Free As In Beer, Or The Story Of Windows Viruses” →

[Daito Manabe] Interview: Shocking!

July 5, 2017 by Elliot Williams 2 Comments

We’ve loved [Daito Manabe]’s work for a while now. Don’t know [Daito]? Read this recent interview with him and catch up. Is he a hacker’s artist, or an artist’s hacker?

My personal favorite hack of his is laser painting apparatus from 2011. The gimmick is that he uses the way the phosphors fade out to create a greyscale image. Saying that is one thing, but watching it all come together in time is just beautiful.

Maybe you’ve seen his facial-electrocution sequencer (words we never thought we’d write! YouTube link). He’s taken that concept and pushed it to the limit — setting up the same sequences on multiple people make them look eerily like the sacks of meat that they are, until everyone laughs at the end of the experiment and they’re all back to being human.

Anyway, if you didn’t know [Daito], check out the rest of his work. Have any other favorite tech artists that we’re missing? Drop us a line.

Hacking An Inspection Microscope

June 26, 2017 by Elliot Williams 74 Comments

Sometimes I need to be able to take photographs of very small things, and the so-called macro mode on my point-and-shoot camera just won’t cut it. And it never hurts to have an inspection scope on hand for tiny soldering jobs, either, though I prefer a simple jeweler’s loupe in one eye for most tasks. So I sent just over $40 off to my close friend Alibaba, and a few weeks later was the proud owner of a halfway usable inspection scope that records stills or video to an SD card.

Unfortunately, it’s only halfway useable because of chintzy interface design and a wobbly mount. So I spent an afternoon, took the microscope apart, and got it under microcontroller control, complete with WiFi and a scripting language. Much better! Now I can make microscope time-lapses, but much more importantly I can take blur-free photos without touching the wiggly rig. It was a fun hack, so I thought I’d share. Read on!

Continue reading “Hacking An Inspection Microscope” →

The Arduino Foundation: What’s Up?

June 19, 2017 by Elliot Williams 65 Comments

The Arduino Wars officially ended last October, and the new Arduino-manufacturing company was registered in January 2017. At the time, we were promised an Arduino Foundation that would care for the open-source IDE and code infrastructure in an open and community-serving manner, but we don’t have one yet. Is it conspiracy? Or foul play? Our advice: don’t fret. These things take time.

But on the other hand, the Arduino community wants to know what’s going on, and there’s apparently some real confusion out there about the state of play in Arduino-land, so we interviewed the principals, Massimo Banzi and Federico Musto, and asked them for a progress report.

The short version is that there are still two “Arduinos”: Arduino AG, a for-profit corporation, and the soon-to-be Arduino Foundation, a non-profit in charge of guiding and funding software and IDE development. The former was incorporated in January 2017, and the latter is still in progress but looks likely to incorporate before the summer is over.

Banzi, who is a shareholder of Arduino AG, is going to be the president of the Foundation, and Musto, AG’s CEO, is going to be on the executive board and both principals told us similar visions of incredible transparency and community-driven development. Banzi is, in fact, looking to get a draft version of the Foundation’s charter early, for comment by the community, before it gets chiseled in stone.

It’s far too early to tell just how independent the Foundation is going to be, or should be, of the company that sells the boards under the same name. Setting up the Foundation correctly is extremely important for the future of Arduino, and Banzi said to us in an interview that he wouldn’t take on the job of president unless it is done right. What the Arduino community doesn’t need right now is a Foundation fork. Instead, they need our help, encouragement, and participation once the Foundation is established. Things look like they’re on track.

Continue reading “The Arduino Foundation: What’s Up?” →

Hackaday Prize Entry: ESP32 Monster And Getting Started Quickly

May 28, 2017 by Elliot Williams 19 Comments

Prolific hacker [kodera2t] is working on his own “ESP32 monster board” dev board for the still-newish ESP32 WiFi module. His board has everything: Ethernet, OLED, LiPo, and even CAN-bus. But all that peripheral connectivity is worth nothing if you can’t program the microcontroller to use it.

The Arduino environment for the ESP32 is coming along quite nicely, but it’s not yet fully featured enough to run all of [kodera2t]’s hardware. To take advantage of all that, he needs to use Espressif’s SDK — called the “IoT Development Framework” or IDF for short. In his latest project log, [kodera2t] goes through everything necessary to get the IDF up and compiling on OSX. (It’s strangely similar to the Linux procedure.) Read through the official instructions here, if you want more, but we think [kodera2t] hits all the high points.

While we’re tooting [kodera2t]’s horn, check out his old project — an Arduino shoehorned into an SD card — or watch his alter-ego [Toshiro Kodera] give a serious talk about his day job, engineering radio-frequency meta-materials.

Embed With Elliot: LIN Is For Hackers

May 26, 2017 by Elliot Williams 18 Comments

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” →

NIST Helps You With Cryptography

May 25, 2017 by Elliot Williams 33 Comments

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!