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

Fail Of The Week: GitLab Goes Down

February 2, 2017 by 57 Comments

Has work been a little stressful this week, are things getting you down? Spare a thought for an unnamed sysadmin at the GitHub-alike startup GitLab, who early yesterday performed a deletion task on a PostgreSQL database in response to some problems they were having in the wake of an attack by spammers. Unfortunately due to a command line error he ran the deletion on one of the databases behind the company’s main service, forcing it to be taken down. By the time the deletion was stopped, only 4.5 Gb of the 300 Gb trove of data remained.

Reading their log of the incident the scale of the disaster unfolds, and we can’t help wincing at the phrase “out of 5 backup/replication techniques deployed none are working reliably or set up in the first place“. In the end they were able to restore most of the data from a staging server, but at the cost of a lost six hours of issues and merge requests. Fortunately for them their git repositories were not affected.

For 707 GitLab users then there has been a small amount of lost data, the entire web service was down for a while, and the incident has gained them more publicity in a day than their marketing department could have achieved in a year. The post-mortem document makes for a fascinating read, and will probably leave more than one reader nervously thinking about the integrity of whichever services they are responsible for. We have to hand it to them for being so open about it all and for admitting a failure of their whole company for its backup failures rather than heaping blame on one employee. In many companies it would all have been swept under the carpet. We suspect that GitLab’s data will be shepherded with much more care henceforth.

We trust an increasing amount of our assets to online providers these days, and this tale highlights some of the hazards inherent in placing absolute trust in them. GitLab had moved from a cloud provider to their own data centre, though whether or not this incident would have been any less harmful wherever it was hosted is up for debate. Perhaps it’s a timely reminder to us all: keep your own backups, and most importantly: test them to ensure they work.

Thanks [Jack Laidlaw] for the tip.

Rack server image: Trique303 [CC BY-SA 4.0], via Wikimedia Commons.

33C3: Hunz Deconstructs The Amazon Dash Button

February 2, 2017 by 22 Comments

The Amazon Dash button is now in its second hardware revision, and in a talk at the 33rd Chaos Communications Congress, [Hunz] not only tears it apart and illuminates the differences with the first version, but he also manages to reverse engineer it enough to get his own code running. This opens up a whole raft of possibilities that go beyond the simple “intercept the IP traffic” style hacks that we’ve seen.

dash_block_diagramJust getting into the Dash is a bit of work, so buy two: one to cut apart and locate the parts that you have to avoid next time. Once you get in, everything is tiny! There are a lot of 0201 SMD parts. Hidden underneath a plastic blob (acetone!) is an Atmel ATSAMG55, a 120 MHz ARM Cortex-M4 with FPU, and a beefy CPU all around. There is also a 2.4 GHz radio with a built-in IP stack that handles all the WiFi, with built-in TLS support. Other parts include a boost voltage converter, a BTLE chipset, an LED, a microphone, and some SPI flash.

The strangest part of the device is the sleep mode. The voltage regulator is turned on by user button press and held on using a GPIO pin on the CPU. Once the microcontroller lets go of the power supply, all power is off until the button is pressed again. It’s hard to use any less power when sleeping. Even so, the microcontroller monitors the battery voltage and presumably phones home when it gets low.
Continue reading “33C3: Hunz Deconstructs The Amazon Dash Button” →