Custom Alexa Skill In A Few Minutes Using Glitch

January 17, 2018 by Al Williams 18 Comments

As hackers, we like to think of ourselves as a logical bunch. But the truth is, we are as subject to fads as the general public. There was a time when the cool projects swapped green LEDs out for blue ones or added WiFi connectivity where nobody else had it. Now all the rage is to connect your project to a personal assistant. The problem is, this requires software. Software that lives on a publicly accessible network somewhere, and who wants to deal with that when you’re just playing with custom Alexa skills for the first time?

If you have a computer that faces the Internet, that’s fine. If you don’t, you can borrow one of Amazon’s, but then you need to understand their infrastructure which is a job all by itself. However, there is a very simple way to jump start an Alexa skill. I got one up and running in virtually no time using a website called Glitch. Glitch is a little bit of everything. It is a web hosting service, a programming IDE for Node.js, a code repository, and a few other things. The site is from the company that brought us Trello and helped to start Stack Overflow.

Glitch isn’t about making Alexa skills. It is about creating web applications and services easily. However, that’s about 90% of the work involved in making an Alexa skill. You’ll need an account on Glitch and an Amazon developer’s account. Both are free, at least for what we want to accomplish. Glitch has some templates for Google Home, as well. I have both but decided to focus on Alexa, for no particular reason.

Continue reading “Custom Alexa Skill In A Few Minutes Using Glitch” →

Miss Beatrice Shilling Saves The Spitfire

January 16, 2018 by Dan Maloney 54 Comments

On a bright spring morning in 1940, the Royal Air Force pilot was in the fight of his life. Strapped into his brand new Supermarine Spitfire, he was locked in mortal combat with a Luftwaffe pilot over the English Channel in the opening days of the Battle of Britain. The Spitfire was behind the Messerschmitt and almost within range to unleash a deadly barrage of rounds from the ~~four~~ eight Browning machine guns in the leading edges of the elliptical wings. With the German plane just below the centerline of the gunsight’s crosshairs, the British pilot pushed the Spit’s lollipop stick forward to dive slightly and rake his rounds across the Bf-109. He felt the tug of the harness on his shoulders keeping him in his seat as the nimble fighter pulled a negative-g dive, and he lined up the fatal shot.

But the powerful V-12 Merlin engine sputtered, black smoke trailing along the fuselage as the engine cut out. Without power, the young pilot watched in horror as the three-bladed propeller wound to a stop. With the cold Channel waters looming in his windscreen, there was no time to restart the engine. The pilot bailed out in the nick of time, watching his beautiful plane cartwheel into the water as he floated down to join it, wondering what had just happened.

Continue reading “Miss Beatrice Shilling Saves The Spitfire” →

Spectre And Meltdown: How Cache Works

January 15, 2018 by Adam Fabio 15 Comments

The year so far has been filled with news of Spectre and Meltdown. These exploits take advantage of features like speculative execution, and memory access timing. What they have in common is the fact that all modern processors use cache to access memory faster. We’ve all heard of cache, but what exactly is it, and how does it allow our computers to run faster?

In the simplest terms, cache is a fast memory. Computers have two storage systems: primary storage (RAM) and secondary storage (Hard Disk, SSD). From the processor’s point of view, loading data or instructions from RAM is slow — the CPU has to wait and do nothing for 100 cycles or more while the data is loaded. Loading from disk is even slower; millions of cycles are wasted. Cache is a small amount of very fast memory which is used to hold commonly accessed data and instructions. This means the processor only has to wait for the cache to be loaded once. After that, the data is accessible with no waiting.

A common (though aging) analogy for cache uses books to represent data: If you needed a specific book to look up an important piece of information, you would first check the books on your desk (cache memory). If your book isn’t there, you’d then go to the books on your shelves (RAM). If that search turned up empty, you’d head over to the local library (Hard Drive) and check out the book. Once back home, you would keep the book on your desk for quick reference — not immediately return it to the library shelves. This is how cache reading works.

Continue reading “Spectre And Meltdown: How Cache Works” →

They’re Putting Soy In Your Wires, Man

January 15, 2018 by Tom Nardi 111 Comments

I’ve got a friend who tells me at every opportunity that soy is the downfall of humanity. Whatever ails us as a society, it’s the soy beans that did it. They increase violent tendencies, they make us fat and lazy, they run farmers out of business, and so on. He laments at how hard it is to find food that doesn’t include soy in some capacity, and for a while was resigned to eating nothing but chicken hot dogs and bags of frozen peas; anything else had unacceptable levels of the “Devil’s Bean”. Overall he’s a really great guy, kind of person who could fix anything with a roll of duct tape and a trip to the scrap pile, but you might think twice if he invites you over for dinner.

A column of soy soldiers stand at the ready.

So when he recently told me about all the trouble people are having with soy-based electrical wiring, I thought it was just the latest conspiracy theory to join his usual stories. I told him it didn’t make any sense, there’s no way somebody managed to develop a reliable soy-derived conductor. “No, no,” he says, “not the conductor. They are making the insulation out of soy, and animals are chewing through it.”

Now that’s a bit different. I was already well aware of the growing popularity of bioplastics: the PLA used in desktop 3D printers is one such example, generally derived from corn. It certainly wasn’t unreasonable to think somebody had tried to make “green” electrical wiring by using a bioplastic insulation. While I wasn’t about to sit down to a hot bag of peas for dinner, I had to admit that maybe in this case his claims deserved a look.

Continue reading “They’re Putting Soy In Your Wires, Man” →

Software Design Patterns For Real Hardware

January 12, 2018 by Sonya Vasquez 21 Comments

Here on Hackaday, we’re generally designers of hacks that live in the real world. Nevertheless, I’m convinced that some of the most interesting feats are at the mercy of what’s possible in software, not hardware. Without the right software, no 3D printer could print and no quadcopter could fly. The source code that drives these machines may take months of refinement to flesh out their structure. In a nutshell, these software packages are complicated, and they don’t happen overnight.

So how do they happen; better yet: how could we make that happen? How do we write software that’s flexible enough to coexist peacefully on all sorts of hardware variations?

What separates the big open-source software projects like ROS, LinuxCNC, and Multiwii from the occastional hackathon code are the underlying principles that govern how they’re written. In object-oriented programming, these principles are called design patterns. In the next couple posts, I’m going to crack the lid on a few of these. What’s more, I’ll package them into real-world examples so that we can see these patterns interact with real hardware. The next time you pop open the source code for a big open source hardware project, I hope you can tease out some of these patterns in the code. Better yet, I hope you carry these patterns into your next robot and machine project. Let’s get started.

For readability, all of the examples run in Python3. The snippets below are truncated for brevity, but the real examples in the repository will work if you’ve got a similar hardware setup.

Continue reading “Software Design Patterns For Real Hardware” →

Local Infrastructure: The Devil Is In The Details

January 11, 2018 by Bryan Cockfield 107 Comments

About two months ago I rode my bike to work like any other day, but on the way home a construction project seemed to have spontaneously started at one of the bridges that I pass over. Three lanes had merged into one which, for a federal highway, seemed like a poorly planned traffic pattern for a such a major construction project. As it happens, about an hour after I biked across this bridge that morning both outside sections of the bridge fell into the water. There was no other physical damage that seemed to explain why parts of a bridge on U.S. 1 would suddenly collapse.

The intriguing thing about this bridge collapse was that the outer retaining wall and about half of the sidewalk on both the northbound side and the southbound side had fallen into the water at the same time. This likely wasn’t caused by something like a boat impact, car accident, or an overweight truck. Indeed, Florida Department of Transportation (FDOT) investigated the incident and found that two post tension wires that held these sections of the bridge together had failed, making it unsafe for pedestrians and bicyclists but also for any boaters below. Continue reading “Local Infrastructure: The Devil Is In The Details” →

Spectre And Meltdown: Attackers Always Have The Advantage

January 10, 2018 by Roger Cheng 45 Comments

While the whole industry is scrambling on Spectre, Meltdown focused most of the spotlight on Intel and there is no shortage of outrage in Internet comments. Like many great discoveries, this one is obvious with the power of hindsight. So much so that the spectrum of reactions have spanned an extreme range. From “It’s so obvious, Intel engineers must be idiots” to “It’s so obvious, Intel engineers must have known! They kept it from us in a conspiracy with the NSA!”

We won’t try to sway those who choose to believe in a conspiracy that’s simultaneously secret and obvious to everyone. However, as evidence of non-obviousness, some very smart people got remarkably close to the Meltdown effect last summer, without getting it all the way. [Trammel Hudson] did some digging and found a paper from the early 1990s (PDF) that warns of the dangers of fetching info into the cache that might cross priviledge boundaries, but it wasn’t weaponized until recently. In short, these are old vulnerabilities, but exploiting them was hard enough that it took twenty years to do it.

Building a new CPU is the work of a large team over several years. But they weren’t all working on the same thing for all that time. Any single feature would have been the work of a small team of engineers over a period of months. During development they fixed many problems we’ll never see. But at the end of the day, they are only human. They can be 99.9% perfect and that won’t be good enough, because once hardware is released into the world: it is open season on that 0.1% the team missed.

The odds are stacked in the attacker’s favor. The team on defense has a handful of people working a few months to protect against all known and yet-to-be discovered attacks. It is a tough match against the attackers coming afterwards: there are a lot more of them, they’re continually refining the state of the art, they have twenty years to work on a problem if they need to, and they only need to find a single flaw to win. In that light, exploits like Spectre and Meltdown will probably always be with us.

Let’s look at some factors that paved the way to Intel’s current embarrassing situation.

Continue reading “Spectre And Meltdown: Attackers Always Have The Advantage” →