Vintage Gauges Turned Classy Weather Display

It’s always good to see old hardware saved from the junk pile, especially when the end result is as impressive as this analog gauge weather display put together by [Build Comics]. It ended up being a truly multidisciplinary project, combing not only restoration work and modern microcontroller trickery, but a dash of woodworking for good measure.

Naturally, the gauges themselves are the real stars of the show. They started out with rusted internals and broken glass, but parts from a sacrificial donor and some TLC from [Build Comics] got them back in working order. We especially like the effort that was put into making the scale markings look authentic, with scans of the originals modified in GIMP to indicate temperature and humidity while retaining the period appropriate details.

To drive the 1940s era indicators, [Build Comics] is using an Arduino Nano and a DHT22 sensor that can detect temperature and humidity. A couple of trimmer pots are included for fine tuning the gauges, and everything is mounted to a small scrap of perfboard hidden inside of the custom-made pine enclosure.

This is hardly the first time we’ve seen analog gauges hooked up to modern electronics, but most of the projects are just that: modern. While the end look might be somewhat polarizing, we think maintaining the hardware’s classic style was the right call.

Posted in analog gauge, Arduino Hacks, classic hacks, dht22, environmental monitoring, restoration, temperature sensor, weather display, woodworking | Leave a comment

A Shell? A Programming Language? Relax! It’s Both!

Every time we publish a Linux hack that uses a shell script, someone will chime in about how awful it is to program shell scripts. While we like the ubiquity and efficiency, we can’t disagree that the shell is a bit of a hack itself. [Axel Lijencrantz] wants to change your shell to be a full-blow programming language called Crush.

On the face of it, it looks like a shell. Want to see the contents of the current directory? Simple: ls.

The difference is underneath. In Crush, ls is a built-in and it returns data in rows like a database. You can manipulate that database with SQL-like commands: ls | where {type=="directory"}.

You can still treat I/O as binary streams. But Crush also knows about CSV files, JSON, line-oriented files, and several other formats. So if you were trying to feed the output of ls to a program and need it in JSON form, that’s simple: ls | json:to ./listing.json.

Crush can also do math without resorting to trickery like older shells or strange syntax like bash. The shell supports closures that you can assign to a variable to make what amounts to a function. Another welcome feature is that Crush understands the idea of namespaces.

There are a few oddities like using % as a wildcard instead of * because the * is for multiplication. However, we like a lot of the features, including simplified remote execution and the ability to create custom types.

Crush is similar to Nu, but has some different goals with respect to programming languages. If you are still writing programs in traditional shells like bash, be sure to run a linter.

Posted in bash, crush, linux, linux hacks, nushell, shell | Leave a comment


William English, one of the creators of the mouse back in the 60s, passed away last week. And that got me thinking of how amazing it would have been to be in the place that was inventing what would become modern computing interfaces. What a special time! Of course, they probably had no idea.

From here, it looks like the mouse changed everything, but you have to realize that they were working in a world with light-pens, where you could actually draw on the screen. In contrast, the mouse seems positively non-futuristic. They must have known they’d come up with an improvement over the status quo, but did they know they’d created a revolution?

So where has the revolutionary spirit in DIY human interface devices gone? I’d claim it’s still alive and kicking. Indeed our own Kristina Panos has a series called “Inputs of Interest” and we’ve seen a ton of DIY keyboards of late. Then there are many varieties of dial inputs. I used to have a dedicated scroll wheel made out of a hard-drive platter, and when I was reading lots of PDFs on-screen, I have to say it earned its desk-space. Heck, we’ve even seen people make their own mouse.

But what I love about the story of the development of the mouse is that they asked the question “what is the best way to locate a point on a screen” and tried to answer it. Half of their success is probably in simply asking the right question, and the other half in prototyping something half-workable. My gut says that we don’t have inputs figured out 100% on mobile yet. This sounds like a job for Hackaday. What’s the next big human-interface design need? And have you got any crazy ideas to solve it?

Hackaday Remoticon

And this week, we announced the Hackaday Remoticon, our shelter-in-place version of the Supercon. It’s going to take place in November as usual, but online instead of IRL.

The good news? It’s going to be chock full of workshops, all streamed online and recorded for posterity. And for that we need your proposals. If you’d like to teach a group of distributed hackers learning your favorite techniques and tricks, this is your chance!

The bad news is of course that we won’t get to see you all in person. That’s going to make the 2021 Hackaday Supercon seem even more super.

Posted in computer hacks, diy, Hackaday Columns, hid, input devices, mouse, newsletter, peripherals hacks, pointer, scroll wheel | Leave a comment

Why Buy The Newer Model, When You Can Just Replicate Its User Interface?

Every now and then, along comes an awesome hack from years past that we missed at the time. We kick ourselves for somehow missing such amazing work, and since it’s that good, we share it with you with apologies. Such is the case with [Andrei Anatska]’s faithful replication of the Pioneer CDJ-2000 user interface as an upgrade to the earlier CDJ-1000 DJ controller, a piece of work of such quality that you could almost mistake it for being a commercial product.

At its heart is the STM32F746G Discovery board, which for some reason it pleases us greatly in this context that he refers to as the Disco board. If you’re hazy on the details of the various STM dev boards, this is the all-singing all-dancing one with the fancy colour LCD display. Out comes the VFD on the CDJ-1000 and a set of wires are soldered to its main board, then the Disco board is hooked up with the project firmware installed. The piece de résistance is the case, for which he eschews 3D-printing and instead cuts out from black plastic. Full instructions can be found in this PDF, so should you happen to have a CDJ-1000 that’s seen better days, you can join in the fun. See it in action in the video below.

DJ controllers may be run-of-the-mill today, but to those of us whose DJing days were in the era of a pair of Technics SL1200s and a stack of vinyl to the sound of early ’90s house music they are still nothing short of miraculous. We’ve featured plenty of hacks involving them here but they don’t always involve professional kit. Even a game controller can be pressed into service.

Thanks [Niklas Fauth] for the tip.

Posted in DJ controller, musical hacks, Pioneer, STM discovery | Leave a comment

An Amiga Sampler 30 Years Later

There was a magic moment for a few years around the end of the 1980s, when home computers were better than professional ones. That’s a mighty grand pronouncement, but it refers to the crop of 16-bit home computers that genuinely were far better than nearly all PCs at the time for multimedia tasks. You could plug a sampler cartridge into your Amiga and be in the dance charts in no time, something which sparked a boom in electronic music creativity. As retrocomputing interest has soared so have the prices of old hardware, and for those still making Amiga music that cart can now be outrageously expensive. it’s something [echolevel] has addressed, with an open-source recreation of an Amiga sampler.

As anyone who peered inside one back int he day will tell you, an Amiga sampler was a very simple device consisting of a commonly-available 8-bit A to D converter, a CMOS switch for right and left samples, and maybe an op-amp preamplifier. This is exactly what he’s produced, save fpr the CMOS switch as he points out that Amiga musicians use mono samples anyway. At its heart is an ADC0820 half-flash ADC chip, and the whole thing is realised on a very retro-looking through-hole PCB.

For a Hackaday scribe with a Technosound Turbo still sitting in a box somewhere it’s a real trip down memory lane. It was a moment of magic to for the first time be able to edit and manipulate audio on a computer, and we’re glad to see that something of those days still lives on. See it in action in the video below the break.

Posted in amiga, retrocomputing, sound sampler | Leave a comment

HAWT Wind Turbine Is Mostly 3D Printed

Wind turbines are a great source of renewable energy, and a great DIY project, too. They can be built with all kinds of materials and the barrier for entry is low for the beginner. [Fab] has built just such a device, taking advantage of modern construction techniques, and dubbed it the WinDIY.

The WinDIY design is mostly 3D printed, with a familiar three-bladed design. The diameter of the rotor is 1.2 m, meaning that braking and regulating the turbine is required for safety in high winds. [Fab] is aiming to achieve this control with a combination of mechanical and electronic braking, as well as variable-pitch blades. The benefit of 3D printing the design is it allows iterations to be made quickly, particularly of parts with complex geometries that would be too time-consuming or expensive to machine otherwise.

[Fab]’s writeup goes into great detail on topics like the design of the pitch control systems and other minutae, which should serve as a great reference for anyone else working on a similar project. If you’re looking for something with more of a sci-fi future vibe, consider attempting a vertical-axis build instead.

Posted in 2020 Hackaday Prize, The Hackaday Prize, vertical axis wind turbine, Wind turbine | Leave a comment

Hands-On: AND!XOR Unofficial DC28 Badge Embraces the Acrylic Stackup

Still hot from the solder party, a new AND!XOR badge just landed on my desk courtesy of the hacking crew that has been living the #badgelife for the past five years. Originally based on the Futurama character Bender, the design has morphed to the point that it’s no longer recognizable as a descendant of that belligerent robot. Instead we have a skeletal midget whose face is half covered by a gear-themed mask.

At first glance, you might not even notice the character design because you’re too distracted by the beautiful composure of the hardware. This year’s badge includes a double stack-up of acrylic on top of a red circuit-board. Anyone who has used acrylic bezels in a badge design can tell you the cost for material and laser cutting time is significant. In this case the overall aesthetic of the badge is based upon the look of the mirrored gold with the art detail laser etched into the back. It’s a unique bling without even turning the power on.

When you do flip that hard switch next to three AAA batteries secured to the back of the badge, you’re greeted with RGB LEDs hidden under the etched parts of the faceplate, and both a 128×64 OLED screen and a 160×128 color LCD. The larger screen provides the menu system which is navigated via the Blackberry keyboard worn by the skeletal midget like a belt.

The Blackberry keyboard is a hot trend this year as we’ve seen the Blackberry PMOD KeyBoard that sells out every time it hits Tindie, and projects like the LoRa QWERTY Messenger sourcing them for delicious backlit user input. Why not? The original hardware was a homerun, so it makes sense the surplus replacement stock is now being embraced by hardware hackers.

If you don’t want to type everything with the edge of your thumb, the USB-C port on the bottom of the board provides terminal access. A really nice touch is that the badge also enumerates as USB mass storage, providing access to the readme file as well as a way to load new animations, images, and BASIC programs.

These things must have been a huge hassle to assemble. The keyboard is attached with some clear sticky mounting squares and two tiny screws that thread into holes on the faceplace. That’s not the hard part… the cable threads through a hole, loops somewhere under the stackup, and then snaps into a connector on the board. Four screw bosses hold the acrylic in place, and the two screens adhere to the spacer layer of acrylic. Taking it apart we get a nice look at the underside of the laser-etched acrylic.

An STM32F412RET6 is at the heart of the design. There are far fewer LED than in previous years so there is no dedicated LED driver. The choice there was to use APA-102 RGB LEDs which are driven with simple SPI signals. If you’re wondering about the cuttable traces seen in gold, [Zapp] says he uses them while prototyping the badges in case components need to be rerouted. Normally they’d be hidden, but since the board is covered by acrylic he left them in on the production board.

That beefy QR code? Yeah, it resolves to a sketchy URL:

Further investigation shows it leads to a 302 “moved temporarily” redirect which goes… and you’ve probably already guessed this… to a video of our friend Richard Paul Astley.

The Game, the Culture, the Goodies

The real fun of these badges are the puzzles and interactive activities wrapped inside the firmware. I haven’t had time to dive into those but they are as present as in all previous years, including a public Slack channel where friend exchanges can be done to unlock challenges within. A few guidelines for the capture the flag are mentioned on the project’s documentation page.

The AND!XOR badge is always one of the hottest unofficial DEF CON badges for collectors and this year is no different. Except of course it’s all extremely different since DC is actually cancelled and we’re all socially distancing. How do you distribute hundreds of badges when nobody is centrally located?

As always, they produced a few hundred of these badges. Some of them were sold, but most of the badges were given away for free, underwritten by the companies that sponsored this badge. The distribution scheme for the free badges was an awesome one, sending caches of badges to trusted hackers in locations all over North America which were then given to people who solved challenges or were “doing great hacker things”.

I can’t wrap up this review without mentioning how the badge was wrapped when it arrived. This stretchy sleeve provided a bit of padding around the anti-static bag and can be used as a pandemic mask. But look closely, you’ll see this is custom printed material that includes the silhouette of each of the AND!XOR badges that came before this. It’s unique, incredibly awesome, and a testament to the team’s devotion to making everything about their badges awesome because just because they can.

Posted in AND!XOR, badge, badgelife, cons, DEF CON, defcon 28, hardware | Leave a comment

Separation Between WiFi and Bluetooth Broken by the Spectra Co-Existence Attack

This year, at DEF CON 28 DEF CON Safe Mode, security researchers [Jiska Classen] and [Francesco Gringoli] gave a talk about inter-chip privilege escalation using wireless coexistence mechanisms. The title is catchy, sure, but what exactly is this about?

To understand this security flaw, or group of security flaws, we first need to know what wireless coexistence mechanisms are. Modern devices can support cellular and non-cellular wireless communications standards at the same time (LTE, WiFi, Bluetooth). Given the desired miniaturization of our devices, the different subsystems that support these communication technologies must reside in very close physical proximity within the device (in-device coexistence). The resulting high level of reciprocal leakage can at times cause considerable interference.

There are several scenarios where interference can occur, the main ones are:

  • Two radio systems occupy neighboring frequencies and carrier leakage occurs
  • The harmonics of one transmitter fall on frequencies used by another system
  • Two radio systems share the same frequencies

To tackle these kind of problems, manufacturers had to implement strategies so that the devices wireless chips can coexist (sometimes even sharing the same antenna) and reduce interference to a minimum. They are called coexistence mechanisms and enable high-performance communication on intersecting frequency bands and thus, they are essential to any modern mobile device. Despite open solutions exist, such as the Mobile Wireless Standards, the manufacturers usually implement proprietary solutions.


Spectra is a new attack class demonstrated in this DEF CON talk, which is focused on Broadcom and Cypress WiFi/Bluetooth combo chips. On a combo chip, WiFi and Bluetooth run on separate processing cores and coexistence information is directly exchanged between cores using the Serial Enhanced Coexistence Interface (SECI) and does not go through the underlying operating system.

Spectra class attacks exploit flaws in the interfaces between wireless cores in which one core can achieve denial of service (DoS), information disclosure and even code execution on another core. The reasoning here is, from an attacker perspective, to leverage a Bluetooth subsystem remote code execution (RCE) to perform WiFi RCE and maybe even LTE RCE. Keep in mind that this remote code execution is happening in these CPU core subsystems, and so can be completely invisible to the main device CPU and OS.

Join me below where the talk is embedded and where I will also dig into the denial of service, information disclosure, and code execution topics of the Spectra attack.

Denial of Service

This happens when one wireless core denies transmission to the other core. DoS attacks are possible if one core is able to claim spectrum resources of the other core. As this is the basic working principle of any coexistence interface, all of them are vulnerable by definition, as long as one core keeps constantly claiming the resource for himself. Other DoS opportunities arise from one wireless core being able to crash another via shared RAM abuse.

Information Disclosure

One wireless core can infer data or actions of the other core. One example is when connecting an HID device like a keyboard. Timings and contents of keypresses can be observed on the host that receives those keystrokes. However, an attacker who has only code execution on a WiFi chip should not be able to make such observations. While the content of the keypresses are missing, it is possible for code running on the WiFi chip to infer timing statistics about the keys pressed in the Bluetooth side. This becomes interesting for inferring passwords and password lengths.

Code Execution

One wireless core can execute code within the other core. The security researchers demonstrate that it is possible to execute an arbitrary WiFi address with controlled contents via Bluetooth. This happens because when both cores are running, they share a RAM region which contain, among other information, a large function table. By overwriting a specific address, it is possible to control the WiFi core program counter. This means that a Bluetooth subsystem exploit can turn into a WiFi exploit. In addition, writing to the WiFi buffer and executing addresses produces various kernel panics on Android and iOS, indicating that further escalations into the host are possible and probably it’s just a matter of time until someone pops calc.


Although the research was centered on Broadcom and Cypress combo chips (which cover, by the way, all iPhones, MacBooks, iMacs, older Apple Watches, Samsung S and Note series, some Google Nexus, Raspberry Pi and so forth…) advisories were sent to Intel, MediaTek, Qualcomm, Texas Instruments, Marvell, NXP and they all mention similar coexistence interfaces in their devices. So, mutatis mutandis, and because of its very nature, some Spectra class vulnerabilities probably exist in other vendors too.

And since [Jiska] has a history breaking wireless stuff, we can probably expect a follow-up on this research and this class of inter-chip privilege escalation vulnerabilities. Can’t wait!

Posted in bluetooth, DEF CON, defcon 28, defconsafemode, Featured, news, security hacks, spectra, vulnerability, wifi, wireless hacks | Leave a comment

Hackaday Podcast 079: Wobble Sphere, Pixelflut, Skeeter Traps, and Tracing Apps

Hackaday editors Mike Szczys and Elliot Williams gaze upon the most eye-popping projects from the past week. Who would have known that springy doorstops could be so artistic? Speaking of art, what happens if you give everyone on the network the chance to collectively paint using pixels? There as better way to catch a rat, and a dubious way to lure mosquitoes. We scratch our heads at sending code to the arctic, and Elliot takes a deep look at the contact tracing apps developed and in use throughout Europe.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (~65 MB)

Places to follow Hackaday podcasts:

Episode 079 Show Notes:

New This Week:

Interesting Hacks of the Week:

Quick Hacks:

  • Mike’s Picks:
  • Elliot’s Picks:

Can’t-Miss Articles:

Posted in artic, contact tracing, coronavirus, Covid-19, exercise bike, flywheel, github, Hackaday Columns, mosquitoes, multimeter, pixelflut, podcast, Podcasts, potentiostat, rat trap | Leave a comment

This Week in Security: Garmin Ransomware, KeePass , and Twitter Warnings

On July 23, multiple services related to Garmin were taken offline, including their call center and aviation related services. Thanks to information leaked by Garmin employees, we know that this multi-day outage was caused by the Wastedlocker ransomware campaign. After four days, Garmin was able to start the process of restoring the services.

It’s reported that the requested ransom was an eye-watering $10 million. It’s suspected that Garmin actually paid the ransom. A leaked decryptor program confirms that they received the decryption key. The attack was apparently very widespread through Garmin’s network, as it seems that both workstations and public facing servers were impacted. Let’s hope Garmin learned their lesson, and are shoring up their security practices.


KeePass released an update this week addressing a couple flaws in the KeePassRPC service. The update announcement is light on the details, but thankfully we have the full story directly from [Philipp Danzinger], the student that discovered the vulnerabilities. Both vulnerabilities are in the implementation of the SRP-6(a) key exchange protocol.

The vulnerable component is the RPC. KeyPass is essentially a simple database containing passwords. That database is encrypted using the user’s password, so the contained passwords cannot be retrieved without that master password. When a user launches KeePass, he or she is first prompted for this master password, and the database is decrypted using that password. The KeePassRPC service allows other processes, like a browser plugin, to access the now-decrypted database. The first time a new client attemps to access the RPC service, a keypair is generated, and the user is prompted whether to allow the new connection. The public key is stored and marked as trusted, allowing that client to request passwords again in the future, so long as the database had been unlocked.

The authentication protocol is similar to a DH key exchange. A shared value is raised to the power of the secret key resulting in a value called A. This is sent as part of the key exchange, and the formal specification states that it is never allowed to be 0. The problem is that KeePassRPC doesn’t properly check that A != 0. When A is set to 0, the entire key exchange breaks down, as all the values end up equaling 0, as 0^x is always 0. This means that any client can spoof an already authorized client.

The second vulnerability is a weak random number generator used on the server side to generate the secret key b. That key is based on the current date and time, run through a pseudo-random function. Because that function is known, if an attacker can guess the exact time value used, then the secret key is easily calculated. It’s not quite as simple as it seems, as the time value is measured in “ticks”, each tick being 100 nanoseconds. It would take a bit of guesswork and a few thousand guesses to land on the right value, but without any rate limiting, that process would just take a few seconds.

What makes this attack very serious is the fact that modern web browsers allow Javascript running on a webpage to attempt to connect to localhost. If your KeePass database is unlocked, and you load a page running malicious JS, it could access the RPC port and spoof the authorized KeePass browser plugin and download your entire KeePass database. Thankfully this bug was disclosed privately and KeePassRPC has been updated to 1.12.1, which closes both vulnerabilities. Additionally, 1.13 has since been released with additional safeguards against this and similar attacks.


Twitter has started displaying a security warning for some users. The details are extremely scarce, but lets see what details we can tease out. First, the warning specifies that the issue in question was a vulnerability in the Twitter Android app, but that it was related to an Android vulnerability, and then links to the October 2018 Android security update. Looking through the vulnerabilities disclosed, there doesn’t seem to be an obvious candidate for the related vulnerability.


We’ve seen a very simple technique show up in countless security stories: path transversal. It’s simple, you can include a “..” as part of a file path to move up a directory. Often times this can be included in unexpected places to bypass security restrictions, or do other unintended things. Archive files are no exception, and there is nothing preventing a zip archive from having such paths. Most archive programs catch this behavior and don’t allow the archive to extract as it’s written. The venerable unzip command complains like this:

# unzip Archive:
warning: skipped "../" path component(s) in tmp/../../moo extracting: tmp/moo

KDE Ark, until recently, didn’t treat those paths as special, and would happily extract files to whatever path it was instructed to. The update doesn’t seem to be officially released at the time of writing, so be wary of blindly extracting archives until that update is available. There is a useful repository of archives that can be used to test for various transversal issues, and I’ve confirmed that one in particular (harmless zip file containing tmp/../../moo) does demonstrate the issue in Ark.

And Finally…

Remember Boothole? Multiple vendors pushed fixes to this Linux secure boot vulnerability, and a handful of unbootable systems was the result. For the case of RHEL and CentOS, another round of updated packages have been released, fixing the problem and making for bootable systems again.

And what does a criminal do with a database breach? Apparently after selling them, they release them for free. If it wasn’t stolen data, I’d call it a win. Once a breach has made as much money as the seller thinks it’s likely to make, it’s not uncommon for the data to be released for free. These aren’t very popular sites or services, but it might be worth a check to see if your data was included in the release.

Posted in Hackaday Columns, keepass, news, security hacks, This Week in Security, twitter | Leave a comment