Minimalist Magnetic Minute Minder Mesmerizes

April 3, 2020 by Kristina Panos 26 Comments

Timepieces are cool no matter how simplistic or granular they are. Sometimes its nice not to know exactly what time it is down to the second, and most of the really beautiful clocks are simple as can be. If you didn’t know this was a clock, it would still be fascinating to watch the bearings race around the face.

This clock takes design cues from the Story clock, a visual revolution in counting down time which uses magnetic levitation to move a single bearing around the face exactly once over a duration of any length as set by the user. As a clock, it’s not very useful, so there’s a digital readout that still doesn’t justify the $800 price tag.

[tomatoskins] designed a DIY version that’s far more elegant. It has two ball bearings that move around the surface against hidden magnets — an hour ball and a minute ball. Inside there’s a pair of 3D-printed ring gears that are each driven by a stepper motor and controlled with an Arduino Nano and a real-time clock module. The body is made of plywood reclaimed from a bed frame, and [tomatoskins] added a walnut veneer for timeless class.

In addition to the code, STLs, and CAD files that birthed the STLs, [tomatoskins] has a juicy 3D-printing tip to offer. The gears had to be printed in interlocked pieces, but these seams can be sealed with a solution of acetone and plastic from supports and failed prints.

If you dig minimalism but think this clock is a bit too vague to read, here’s a huge digital clock made from small analog clocks.

This Week In Security: OpenWrt, ZOOM, And Systemd

April 3, 2020 by Jonathan Bennett 21 Comments

OpenWrt announced a problem in opkg, their super-lightweight package manager. OpenWrt’s target hardware, routers, make for an interesting security challenge. A Linux install that fits in just 4 MB of flash memory is a minor miracle in itself, and many compromises had to be made. In this case, we’re interested in the lack of SSL: a 4 MB install just can’t include SSL support. As a result, the package manager can’t rely on HTTPS for secure downloads. Instead, opkg first downloads a pair of files: A list of packages, which contains a SHA256 of each package, and then a second file containing an Ed25519 signature. When an individual package is installed, the SHA256 hash of the downloaded package can be compared with the hash provided in the list of packages.

It’s a valid approach, but there was a bug, discovered by [Guido Vranken], in how opkg reads the hash values from the package list. The leading space triggers some questionable pointer arithmetic, and as a result, opkg believes the SHA256 hash is simply blank. Rather than fail the install, the hash verification is simply skipped. The result? Opkg is vulnerable to a rather simple man in the middle attack.

OpenWrt doesn’t do any automatic installs or automatic updates, so this vulnerability will likely not be widely abused, but it could be used for a targeted attack. An attacker would need to be in a position to MitM the router’s internet connection while software was being installed. Regardless, make sure you’re running the latest OpenWrt release to mitigate this issue. Via Ars Technica.

Wireguard V1.0

With the Linux Kernel version 5.6 being finally released, Wireguard has finally been christened as a stable release. An interesting aside, Google has enabled Wireguard in their Generic Kernel Image (GKI), which may signal more official support for Wireguard VPNs in Android. I’ve also heard reports that one of the larger Android ROM development communities is looking into better system-level Wireguard support as well.

Javascript in Disguise

Javascript makes the web work — and has been a constant thorn in the side of good security. For just an example, remember Samy, the worm that took over Myspace in ’05. That cross-site scripting (XSS) attack used a series of techniques to embed Javascript code in a user’s profile. Whenever that profile page was viewed, the embedded JS code would run, and then replicate itself on the page of whoever had the misfortune of falling into the trap.

Today we have much better protections against XSS attacks, and something like that could never happen again, right? Here’s the thing, for every mitigation like Content-Security-Policy, there is a guy like [theMiddle] who’s coming up with new ways to break it. In this case, he realized that a less-than-perfect CSP could be defeated by encoding Javascript inside a .png, and decoding it to deliver the payload.

Systemd

Ah, systemd. Nothing seems to bring passionate opinions out of the woodwork like a story about it. In this case, it’s a vulnerability found by [Tavis Ormandy] from Google Project Zero. The bug is a race condition, where a cached data structure can be called after it’s already been freed. It’s interesting, because this vulnerability is accessible using DBus, and could potentially be used to get root level access. It was fixed with systemd v220.

Mac Firmware

For those of you running MacOS on Apple hardware, you might want to check your firmware version. Not because there’s a particularly nasty vulnerability in there, but because firmware updates fail silently during OS updates. What’s worse, Apple isn’t publishing release notes, or even acknowledging the most recent firmware version. A crowd-sourced list of the latest firmware versions is available, and you can try to convince your machine to try again, and hope the firmware update works this time.

Anti-Rubber-Ducky

Google recently announced a new security tool, USB Keystroke Injection Protection. I assume the nickname, UKIP, isn’t an intentional reference to British politics. Regardless, this project is intended to help protect against the infamous USB Rubber Ducky attack, by trying to differentiate a real user’s typing cadence, as opposed to a malicious device that types implausibly quickly.

While the project is interesting, there are already examples of how to defeat it that amount to simply running the scripts with slight pauses between keystrokes. Time will tell if UKIP turns into a useful mitigation tool. (Get it?)

SMBGhost

Remember SMBGhost, the new wormable SMB flaw? Well, there is already a detailed explanation and PoC. This particular PoC is a local-only privilege escalation, but a remote code execution attack is like inevitable, so go make sure you’re patched!

Full-Colour, Full-Motion Video – On An Audio Cassette!

April 3, 2020 by Jenny List 29 Comments

A lot of projects we feature use video in some form or other, but that video is invariably digital, it exists as a stream of numbers in a computer memory or storage, and is often compressed. For some of us who grew up working with composite video there is a slight regret that we rarely get up-close and personal with an analogue stream, so [Kris Slyka]’s project putting video on a conventional audio cassette is a rare opportunity.

It's fair to say this isn't the highest quality video. — It’s fair to say this isn’t the highest quality video.

Readers with long memories may recall the Fisher-Price PixelVision toy from the late 1980s which recorded black-and-white video on a conventional cassette running at many times normal speed. This system does not take that tack, instead it decreases resolution and frame rate to a point at which it can be recorded at conventional cassette speeds. The result is not particularly high quality, but with luminance on one side of a stereo recording and chrominance on the other it does work.

The video below the break is a run through the system, with an explanation of how video signals work. Meanwhile the code for both encoder and decoder are available through the magic of GitHub. If you’re interested further, take a look at our examination of a video waveform.

Continue reading “Full-Colour, Full-Motion Video – On An Audio Cassette!” →

ESP8266 And Sensors Make For A Brainy NERF Ball

April 3, 2020 by Tom Nardi 4 Comments

For his final project in UCLA’s Physics 4AL program, [Timothy Kanarsky] used a NodeMCU to smarten up a carefully dissected NERF football. With the addition to dual MPU6050 digital accelerometers and some math, the ball can calculate things like the distance traveled and angular velocity. With a 9 V alkaline battery and a voltage regulator board along for the ride it seems like a lot of weight to toss around; but of course nobody on the Hackaday payroll has thrown a ball in quite some time, so we’re probably not the best judge of such things.

Even if you’re not particularly interested in refining your throw, there’s a lot of fascinating science going on in this project; complete with fancy-looking equations to make you remember just how poorly you did back in math class.

As [Timothy] explains in the write-up, the math used to find velocity and distance traveled with just two accelerometers is not unlike the sort of dead-reckoning used in intercontinental ballistic missiles (ICBMs). Since we’ve already seen model rockets with their own silos, seems all the pieces are falling into place.

The NodeMCU polls the accelerometers every 5 milliseconds, and displays the data on web page complete with scrolling graphs of acceleration and angular velocity. When the button on the rear of the ball is pressed, the data is instead saved to basic Comma Separated Values (CSV) file that’s served up to clients with a minimal FTP server. We might not know much about sportsball, but we definitely like the idea of a file server we can throw at people.

Interestingly, this isn’t the first time we’ve seen an instrumented football. Back in 2011 it took some pretty elaborate hardware to pull this sort of thing off, and it’s fascinating to see how far the state-of-the-art has progressed.