Dash With Arduino

February 2, 2017 by 5 Comments

Amazon Dash is a handy service, and when Amazon released their AWS IoT platform, [Brian Carbonette] felt that it left out all the hardware hackers from the tinkering fun. Seeking justice, he put together a guide for an Arduino Dash button aimed at hardware hackers and those who are still easing into the world.

For his build, [Carbonette] used an Arduino MKR1000, laying out a few different configuration options for building your button. He has also gone to great lengths to help all comers tackle the Arduino-Dash API communication process by building an AmazonDRS Arduino Library, which handles all the “boring details,” so you can focus on the hardware. With the warning that the software-side setup is tedious the first time around, [Carbonette] has included a detailed manual for setting up the aforementioned AmazonDRS library, some example code, and a breakdown thereof. He also suggests implementing other features — such as a notification if the item is out of stock on Amazon — to tie the project together.

Continue reading “Dash With Arduino” →

Sharing Virtual And Holographic Realities Via Vive And Hololens

February 2, 2017 by 13 Comments

An experimental project to mix reality and virtual reality by [Drew Gottlieb] uses the Microsoft Hololens and the HTC Vive to show two users successfully sharing a single workspace as well as controllers. While the VR user draws cubes in midair with a simple app, the Hololens user can see the same cubes being created and mapped to a real-world location, and the two headsets can even interact in the same shared space. You really need to check ou the video, below, to fully grasp how crazy-cool this is.

Two or more VR or AR users sharing the same virtual environment isn’t new, but anchoring that virtual environment into the real world in a way that two very different headsets share is interesting to see. [Drew] says that the real challenge wasn’t just getting the different hardware to talk to each other, it was how to give them both a shared understanding of a common space. [Drew] needed a way to make that work, and you can see the results in the video embedded below.

Continue reading “Sharing Virtual And Holographic Realities Via Vive And Hololens” →

LiftLocker Keeps Your Lift Safe From Attacking Garage Doors

February 2, 2017 by 54 Comments

Car lifts used to be a tool reserved for professional mechanics. Times are a-changing though. With the advent of reasonably priced four-post hydraulic lifts, more and more shade tree mechanics are joining the five-foot high club. Installing a lift in a home garage creates a few hazards, though. What happens when a family remotely opens the garage door while there is a car up on the lift? Garage door and lifted vehicle will meet – with expensive and/or dangerous results. [Joe Auman] saw this problem coming a mile away. He built the LiftLocker to make sure it never happens to him.

At its core, LiftLocker is a set of switched extension cords. Two cast-aluminum boxes hide the electronics. One box plugs in-line with the lift. The other box plugs in-line with the garage door opener. Each box includes a Sparkfun Redboard Arduino compatible, an RFM22 433 MHz Radio, and a relay. Input comes from a security system magnetic reed-switch. Both boxes are identical in hardware and code.

Operation is simple. One box and reed switch goes on the lift, the other on the garage door. If the lift is going up, its reed switch will open. The lift’s Arduino detects this and commands its RFM22 to send a signal to the other box on the garage door. Upon receiving this signal, the garage door controller will open its relay, disconnecting power to the garage door opener. Communication is two-way, so if the Lift controller doesn’t hear an ACK message from the garage door controller, everything will shut down. Click past the break to see the system in action.

Continue reading “LiftLocker Keeps Your Lift Safe From Attacking Garage Doors” →

Yes/No Neural Interface Partly Works

February 2, 2017 by 19 Comments

It sounds like something out of a sci-fi or horror movie: people suffering from complete locked-in state (CLIS) have lost all motor control, but their brains are otherwise functioning normally. This can result from spinal cord injuries or anyotrophic lateral sclerosis (ALS). Patients who are only partially locked in can often blink to signal yes or no. CLIS patients don’t even have this option. So researchers are trying to literally read their minds.

Neuroelectrical technologies, like the EEG, haven’t been successful so far, so the scientists took another tack: using near-infrared light to detect the oxygenation of blood in the forehead. The results are promising, but we’re not there yet. The system detected answers correctly during training sessions about 70% of the time, where the upper bound for random chance is around 65% — varying from trial to trial. This may not seem overwhelmingly significant, but repeating the question many times can help improve confidence in the answer, and these are people with no means of communicating with the outside world. Anything is better than nothing?

journal-pbio-1002593-g001It’s noteworthy that the blood oxygen curves over time vary significantly from patient to patient, but seem roughly consistent within a single patient. Some people simply have patterns that are easier to read. You can see all the data in the paper.

They go into the methodology as well, which is not straightforward either. How would you design a test for a person who you can’t even tell if they are awake, for instance? They ask complementary questions (“Paris is the capital of France”, “Berlin is the capital of Germany”, “Paris is the capital of Germany”, and “Berlin is the capital of France”) to be absolutely sure they’re getting the classifications right.

It’s interesting science, and for a good cause: improving the quality of life for people who have lost all contact with their bodies. (Most of whom answered “yes” to the statement “I am happy.” Food for thought.)

Via Science-Based Medicine, and thanks to [gippgig] for the unintentional tip! Photo from the Wyss Center, one of the research institutes involved in the study.

Ask Hackaday: Are Unlockable Features Good For The User?

February 2, 2017 by 136 Comments

There are numerous examples of hardware which has latent features waiting to be unlocked by software. Most recently, we saw a Casio calculator which has the same features as its bigger sibling hidden within the firmware, only to be exposed by a buffer overflow bug (or the lead from a pencil if you prefer a hardware hack).

More famously, oscilloscopes have been notorious for having crippled features. The Rigol DS1052E was hugely popular on hacker benches because of it’s very approachable price tag. The model shipped with 50 MHz bandwidth but it was discovered that a simple hack turned it into the DS1102E 100 MHz scope. Tektronix has gotten in on this action as well, shipping modules like I2C, CAN, and LIN analyzation on the scope but requiring a hardware key to unlock (these were discovered to have a horribly insecure unlock method). Similar feature barriers are found on Rigol’s new reigning entry-level scope, the DS1054Z, which ships with protocol analyzation modules (among others) that are enabled only for the first 70 hours of scope operation, requiring an additional payment to unlock them. Most scope manufacturers are in on the game, and of course this is not limited to our tools. WiFi routers are another great example of hardware hosting firmware-unlockable features.

So, the question on my mind which I’d like to ask all of the Hackaday community is this: are unlockable features good for us, the people who use these tools? Let’s take a look at some of the background of these practices and then jump into a discussion in the comments.

Continue reading “Ask Hackaday: Are Unlockable Features Good For The User?” →

No-Etch: The Proof In The Bluetooth Pudding

February 2, 2017 by 40 Comments

In a previous episode of Hackaday, [Rich Olson] came up with a new no-etch circuit board fabrication method. And now, he’s put it to the test: building an nRF52 Bluetooth reference design, complete with video, embedded below.

The quick overview of [Rich]’s method: print out the circuit with a laser printer, bake a silver-containing glue onto the surface, repeat a few times to get thick traces, glue the paper to a substrate, and use low-temperature solder to put parts together. A potential drawback is the non-negligible resistance for the traces, but a lot of the time that doesn’t matter and the nRF52 reference design proves it.

The one problem here may be the trace antenna. [Rich] reports that it sends out a weaker-than-expected signal. Any RF design folks want to speculate wildly about the cause?

Continue reading “No-Etch: The Proof In The Bluetooth Pudding” →

Hacking The Aether: How Data Crosses The Air-Gap

February 2, 2017 by 35 Comments

It is incredibly interesting how many parts of a computer system are capable of leaking data in ways that is hard to imagine. Part of securing highly sensitive locations involves securing the computers and networks used in those facilities in order to prevent this. These IT security policies and practices have been evolving and tightening through the years, as malicious actors increasingly target vital infrastructure.

Sometimes, when implementing strong security measures on a vital computer system, a technique called air-gapping is used. Air-gapping is a measure or set of measures to ensure a secure computer is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network. Sometimes it’s just ensuring the computer is off the Internet. But it may mean completely isolating for the computer: removing WiFi cards, cameras, microphones, speakers, CD-ROM drives, USB ports, or whatever can be used to exchange data. In this article I will dive into air-gapped computers, air-gap covert channels, and how attackers might be able to exfiltrate information from such isolated systems.

Continue reading “Hacking The Aether: How Data Crosses The Air-Gap” →