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

Turning Television Into A Simple Tapestry

February 1, 2017 by 6 Comments

Teleknitting, the brainchild of Moscow artist [vtol], is an interesting project. On one hand, it doesn’t knit anything that is useful in a traditional sense, but on the other, it attempts the complex task of deconstructing broadcasted media into a simpler form of information transmission.

Teleknitting’s three main components are the processing and display block — made up of the antenna, Android tablet, and speaker — the dyeing machine with its ink, sponges, actuators, and Arduino Uno, and the rotating platform for the sacrificial object. A program running on the tablet analyzes the received signal and — as displayed on its screen — gradually halves the number of pixels in the image until there is only one left with a basic representation of the picture’s colour. From there, thread passes over five sponges which dye it the appropriate colour, with an armature that responds to the broadcast’s volume directing where the thread will bind the object.

Continue reading “Turning Television Into A Simple Tapestry” →

A Very MIDI Christmas Lightshow

February 1, 2017 by 22 Comments

Christmas light displays winking and flashing in sync to music are a surefire way to rack up views on YouTube and annoy your neighbours. Inspired by one such video, [Akshay James] set up his own display and catalogued the process in this handy tutorial to get you started on your own for the next holiday season.

[James], using the digital audio workstation Studio One, took the MIDI data for the song ‘Carol of the Bells’ and used that as the light controller data for the project’s Arduino brain. Studio One sends out the song’s MIDI data, handled via the Hairless MIDI to serial bridge, to the Arduino which in turn sets the corresponding bit to on or off. That gets passed along to three 74HC595 shift registers — and their three respective relay boards — which finally trigger the relay for the string of lights.

From there, it’s a matter of wiring up the Arduino shift register boards, relays, and connecting the lights. Oh, and be sure to mount a speaker outdoors so passers-by can enjoy the music:

Continue reading “A Very MIDI Christmas Lightshow” →