Spooky Animated Eyes For Your Frightening Needs

October 31, 2018 by 9 Comments

Unless you have an incredibly well-stocked parts bin, it’s probably too late to build these spooky animated eyes to scare off the neighborhood kiddies this year. But next year…

It’s pretty clear that Halloween decorating has gone over the top recently. It may not be as extreme as some Christmas displays, but plenty of folks like to up the scare-factor, and [wermy] seems to number himself among those with the spirit of the season. Like Christmas lights, these eyes are deployed as a string, but rather than just blink lights, they blink creepy eyes from various kinds of creatures. The eyes are displayed on individual backlit TFT-LCD displays housed in 3D-printed enclosures. Two pairs of eyes can be driven by the SPI interface of one ItsyBitsy M0 Express; driving more displays works, but the frame rate drops to an unacceptable level if you stretch it too far. Strung together on scraps of black ethernet cable, the peepers can live in the shrubs next to the front door or lining the walk, and with surprisingly modest power needs, you’ll get a full night of frights from a USB battery bank.

We like the look of these, and maybe we’ll do something about it next year. If you’re still in the mood to scare and don’t have the time for animated eyes this year, try these simple Arduino blinky eyes for a quick hit.

Continue reading “Spooky Animated Eyes For Your Frightening Needs” →

When Good Software Goes Bad: Malware In Open Source

October 31, 2018 by 28 Comments

Open Source software is always trustworthy, right? [Bertus] broke a story about a malicious Python package called “Colourama”. When used, it secretly installs a VBscript that watches the system clipboard for a Bitcoin address, and replaces that address with a hardcoded one. Essentially this plugin attempts to redirects Bitcoin payments to whoever wrote the “colourama” library.

Why would anyone install this thing? There is a legitimate package named “Colorama” that takes ANSI color commands, and translates them to the Windows terminal. It’s a fairly popular library, but more importantly, the name contains a word with multiple spellings. If you ask a friend to recommend a color library and she says “coulourama” with a British accent, you might just spell it that way. So the attack is simple: copy the original project’s code into a new misspelled project, and add a nasty surprise.

Sneaking malicious software into existing codebases isn’t new, and this particular cheap and easy attack vector has a name: “typo-squatting”.  But how did this package get hosted on PyPi, the main source of community contributed goodness for Python? How many of you have downloaded packages from PyPi without looking through all of the source? pip install colorama? We’d guess that it’s nearly all of us who use Python.

It’s not just Python, either. A similar issue was found on the NPM javascript repository in 2017. A user submitted a handful of new packages, all typo-squatting on existing, popular packages. Each package contained malicious code that grabbed environment variables and uploaded them to the author. How many web devs installed these packages in a hurry?

Of course, this problem isn’t unique to open source. “Abstractism” was a game hosted on Steam, until it was discovered to be mining Monero while gamers were playing. There are plenty of other examples of malicious software masquerading as something else– a sizable chunk of my day job is cleaning up computers after someone tried to download Flash Player from a shady website.

Buyer Beware

In the open source world, we’ve become accustomed to simply downloading libraries that purport to do exactly the cool thing we’re looking for, and none of us have the time to pore through the code line by line. How can you trust them?

Repositories like PyPi do a good job of faithfully packaging the libraries and programs that are submitted to them. As the size of these repositories grow, it becomes less and less practical for every package to be manually reviewed. PyPi lists 156,750 projeccts. Automated scanning like [Bertus] was doing is a great step towards keeping malicious code out of our repositories. Indeed, [Bertus] has found eleven other malicious packages while testing the PyPi repository. But cleverer hackers will probably find their way around automated testing.

That the libraries are open source does add an extra layer of reliability, because the code can in principal be audited by anyone, anytime. As libraries are used, bugs are found, and features are added, more and more people are intentionally and unintentionally reviewing the code. In the “colourama” example, a long Base64 string was decoded and executed. It doesn’t take a professional researcher to realize something fishy is going on. At some point, enough people have reviewed a codebase that it can be reasonably trusted. “Colorama” has well over a thousand stars on Github, and 28 contributors. But did you check that before downloading it?

Typo-squatting abuses trust, taking advantage of a similar name and whoever isn’t paying quite close enough attention. It’s not practical for every user to check every package in their operating system. How, then, do we have any trust in any install? Cryptography solves some of these problems, but it cannot overcome the human element. A typo in a url, trusting a brand new project, or even obfuscated C code can fool the best of us from time to time.

What’s the solution? How do we have any confidence in any of our software? When downloading from the web, there are some good habits that go a long way to protect against attacks. Cross check that the project’s website and source code actually point to each other. Check for typos in URLs. Don’t trust a download just because it’s located on a popular repository.

But most importantly, check the project’s reputation, the number of contributors to the project, and maybe even their reputation. You wouldn’t order something on eBay without checking the seller’s feedback, would you? Do the same for software libraries.

A further layer of security can be found in using libraries supported by popular distributions. In quality distributions, each package has a maintainer that is familiar with the project being maintained. While they aren’t checking each line of code of every project, they are ensuring that “colorama” gets packaged instead of “colourama”. In contrast to PyPi’s 156,750 Python modules, Fedora packages only around 4,000. This selection is a good thing.

Repositories like PyPi and NPM are simply not the carefully curated sources of trustworthy software that we sometimes think them to be– and we should act accordingly. Look carefully into the project’s reputation. If the library is packaged by your distribution of choice, you can probably pass this job off to the distribution’s maintainers.

At the end of the day, short of going through the code line by line, some trust anchor is necessary. If you’re blindly installing random libraries, even from a “trustworthy” repository, you’re letting your guard down.

Helium Can Stop Your IPhone — Maybe Other MEMS, Too

October 31, 2018 by 115 Comments

Sometimes hacking isn’t as much about building something, it’s about getting to the root of a particularly difficult problem. [Erik Wooldrige] was facing a problem like that. He’s a system specialist at a hospital near Chicago. Suddenly a bunch of iPhones and Apple watches were failing or glitching. The only thing anyone could think of was the recent install of an MRI machine.

Sure, an MRI machine can put out some serious electromagnetic pulses, but why would that only affect Apple products? Everything else in the hospital, including Android phones, seemed to be OK. But about 40 Apple devices were either dead or misbehaving.

Continue reading “Helium Can Stop Your IPhone — Maybe Other MEMS, Too” →

LED Stick Person Costume Lights Up The Night

October 31, 2018 by 16 Comments

Sometimes a simple idea can yield fantastic results. A few runs of LED strips fastened to a black hoody and sweatpants and just like that…a LED stick person costume for Halloween. The creator of the “Glowy Zoey” [Royce] originally put together some glow in the dark stick person suits to stand out when hitting the slopes at night. Now he’s taken that simple idea for a costume and made a small business out of it.


“I had a lot of extra parts laying around. I gathered everything up and got to work soldering.”  – Royce Hutain

The suits themselves consist of button snaps and ribbon loops sewn into a pattern that routes the LED strips around the jacket’s hood and down each arm. To make the lighting effect pop, an all black plastic mask is used to cover the wearer’s face. It wouldn’t be that much a stretch to substitute EL wire in place of the LED strips if one were so inclined. We’d wager a number of you could pull this off straight out of the junkbox.

The Glowy Zoey stick figure suits even received some mainstream television press a few years ago when they were featured on Jimmy Fallon’s Late Night show. Note that visiting the Glowy Zoey website may take you back a bit since it features one of those autoplay jingles that were so prevalent in the Web 1.0 days. In fact the same jingle is used in the video below from their YouTube channel:

Continue reading “LED Stick Person Costume Lights Up The Night” →

Learn To Optimize Code In Assembly… For Android

October 30, 2018 by 11 Comments

When programming a microcontroller, there are some physical limitations that you’ll come across much earlier than programming a modern computer, whether that’s program size or even processor speed. To make the most use of a small chip, we can easily dig into the assembly language to optimize our code. On the other hand, modern processors in everyday computers and smartphones are so fast and have so much memory compared to microcontrollers that this is rarely necessary, but on the off-chance that you really want to dig into the assembly language for ARM, [Uri Shaked] has a tutorial to get you started.

The tutorial starts with a “hello, world” program for Android written entirely in assembly. [Uri] goes into detail on every line of the program, since it looks a little confusing if you’ve never dealt with assembly before. The second half of the program is a walkthrough on how to actually execute this program on your device by using the Android Native Deveolpment Kit (NDK) and using ADB to communicate with the phone. This might be second nature for some of us already, but for those who have never programmed on a handheld device before, it’s worthwhile to notice that there are a lot more steps to go through than you might have on a regular computer.

If you want to skip the assembly language part of all of this and just get started writing programs for Android, you can download an IDE and get started pretty easily, but there’s a huge advantage to knowing assembly once you get deep in the weeds especially if you want to start reverse engineering software or bitbanging communications protocols. And if you don’t have an Android device handy to learn on, you can still learn assembly just by playing a game.

A Bluetooth Upgrade For An Unusual Set Of Headphones

October 30, 2018 by 11 Comments

We will have all picked up something from a junk pile or swap meet in our time that caught our eye not because we needed it but because it looked cool. [Quinn Dunki] did just that with an irresistible set of 1980s air traffic control headphones. What did she do with them? Turn them into a set of Bluetooth headphones of course!

The ‘phones in question are particularly interesting, as they turned out upon inspection to be a two-way radio in disguise. Cracking them open revealed a radio board and a logic board, and what makes them particularly interesting to this Hackaday scribe’s eye is their choice of frequency. She finds a crystal with a VHF airband frequency multiplier and concludes that they must operate there, but a look at the photos reveals all the ingredients of a classic AM or low HF receiver. There is a ferrite rod antenna and a variable capacitor, if we didn’t know that these were very high-end professional ‘phones we’d almost suspect they were a novelty AM radio from Radio Shack. If any readers can shed any light on the frequency and purpose of this device, we’re all ears.

The conversion involved a Sparkfun Bluetooth module breakout board paired with a little audio power amplifier. The original drivers were high-impedance and one of them had died, so she replaced them with a modern pair of identical size. The control buttons were mounted in the headphone’s external housing, after a wrong turn into attempting to create a custom enclosure. The result is a rather novel but high-quality set of ‘phones, and one we rather wish we’d found ourselves.

Kepler Closes Eyes After A Decade Of Discovery

October 30, 2018 by 16 Comments

Since its launch in March 2009, the Kepler Space Telescope has provided us with an incredible amount of data about exoplanets within our galaxy, proving these worlds are more varied and numerous than we could ever have imagined. Before its launch we simply didn’t know how common planets such as ours were, but today we know the Milky Way contains billions of them. Some of these worlds are so hot they have seas of molten rock, others experience two sunsets a day as they orbit a pair of stars. Perhaps most importantly, thousands of the planets found by Kepler are much like our own: potentially playing host to life as we know it.

Kepler lived a fruitful life by any metric, but it hasn’t been an easy one. Too far into deep space for us to repair it as we did Hubble, hardware failures aboard the observatory nearly brought the program to a halt in 2013. When NASA announced the spacecraft was beyond hope of repair, most assumed the mission would end. Even by that point, Kepler was an unqualified success and had provided us with enough data to keep astronomers busy for years. But an ingenious fix was devised, allowing it to continue collecting data even in its reduced capacity.

Leaning into the solar wind, Kepler was able to use the pressure of sunlight striking its solar panels to steady itself. Kepler’s “eyesight” was never quite the same after the failure of its reaction wheels, and it consumed more propellant than originally intended to maintain this careful balancing act, but the science continued. The mission that had already answered many of our questions about our place in the galaxy would push ahead in spite of a failure which should have left it dead in space.

As Kepler rapidly burned through its supply of propellant, it became clear the mission was on borrowed time. It was a necessary evil, as the alternative was leaving the craft tumbling through space, but mission planners understood that the fix they implemented had put an expiration date on Kepler. Revised calculations could provide an estimate as to when the vehicle would finally run its tanks dry and lose attitude control, but not a definitive date.

For the last several months NASA has known the day was approaching, but they decided to keep collecting data until the vehicle’s thrusters sputtered and failed. So today’s announcement that Kepler has at long last lost the ability to orient itself came as no surprise. Kepler has observed its last alien sunset, but the search for planets, and indeed life, in our corner of the galaxy doesn’t end today.

Continue reading “Kepler Closes Eyes After A Decade Of Discovery” →