A putter with an Arduino attached to its shaft

This Golf Club Uses Machine Learning To Perfect Your Swing

Golf can be a frustrating game to learn: it takes countless hours of practice to get anywhere near the perfect swing. While some might be lucky enough to have a pro handy every time they’re on the driving range or putting green, most of us will have to get by with watching the ball’s motion and using that to figure out what we’re doing wrong.

Luckily, technology is here to help: [Nick Bild]’s Golf Ace is a putter that uses machine learning to analyze your swing. An accelerometer mounted on the shaft senses the exact motion of the club and uses a machine learning algorithm to see how closely it matches a professional’s swing. An LED mounted on the club’s head turns green if your stroke was good, and red if it wasn’t. All of this is driven by an Arduino Nano 33 IoT and powered by a lithium-ion battery.

The Golf Ace doesn’t tell you what part of your swing to improve, so you’d still need some external instruction to help you get closer to the ideal form; [Nick]’s suggestion is to bundle an instructor’s swing data with a book or video that explains the important points. That certainly looks like a reasonable approach to us, and we can also imagine a similar setup to be used on woods and irons, although that would require a more robust mounting system.

In any case, the Golf Ace could very well be a useful addition to the many gadgets that try to improve your game. But in case you still end up frustrated, you might want to try this automated robotic golf club.

Continue reading “This Golf Club Uses Machine Learning To Perfect Your Swing”

This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat

DNS spoofing/poisoning is the attack discovered by [Dan Kaminski] back in 2008 that simply refuses to go away. This week a vulnerability was announced in the uClibc and uClibc-ng standard libraries, making a DNS poisoning attack practical once again.

So for a quick refresher, DNS lookups generally happen over unencrypted UDP connections, and UDP is a stateless connection, making it easier to spoof. DNS originally just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that wasn’t sufficient when combined with a technique that generated massive amounts of DNS traffic. That attack could poison the DNS records cached by public DNS servers, greatly amplifying the effect. The solution was to randomize the UDP source port used when sending UDP requests, making it much harder to “win the lottery” with a spoofed packet, because both the TXID and source port would have to match for the spoof to work.

uClibc and uClibc-ng are miniature implementations of the C standard library, intended for embedded systems. One of the things this standard library provides is a DNS lookup function, and this function has some odd behavior. When generating DNS requests, the TXID is incremental — it’s predictable and not randomized. Additionally, the TXID will periodically reset back to it’s initial value, so not even the entire 16-bit key space is exercised. Not great. Continue reading “This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat”

Automate The Freight: Autonomous Buses To Start Operation In UK

The UK will get its first full-size autonomous bus service this summer, if final road testing that begins in the next two weeks goes according to plan.

Known as Project CAVForth for the UK government’s Center for Connected and Autonomous Vehicles (CCAV) and the Forth bridge, over which the buses will travel, it is said to be the most complex test of autonomous on-road mass transit yet undertaken in Europe. The full-size single-deck motorcoaches, five in total, will ply a 22-km (14-mile) route into Edinburgh from Fife, crossing the famous Firth of Forth on the Forth Road suspension bridge. The buses will carry about 36 passengers each and run at SAE Level 4 autonomy, meaning that a safety driver is optional under good driving conditions. Continue reading “Automate The Freight: Autonomous Buses To Start Operation In UK”

A square PCB with a Raspberry Pi Pico mounted in the middle

Identify Radioactive Samples With This DIY Gamma-Ray Spectrometer

If you’re a radiation enthusiast, chances are you’ve got a Geiger counter lying around somewhere. While Geiger counters are useful to detect the amount of radiation present, and with a few tricks can also distinguish between the three types of radiation (alpha, beta and gamma), they are of limited use in identifying radioactive materials. For that you need a different instrument called a gamma-ray spectrometer.

Spectrometers are usually expensive and complex instruments aimed at radiation professionals. But it doesn’t have to be that way: physics enthusiast [NuclearPhoenix] has designed a hand-held gamma spectrometer that’s easy to assemble and should fit in a hobbyist budget. It outputs spectral plots that you can compare with reference data to identify specific elements.

A PCB with a sensor wrapped in black tape
The scintillator and sensor are wrapped in black tape to block out ambient light.

The heart of the device is a scintillation crystal such as thallium-doped sodium iodide which converts incoming gamma rays into visible light. The resulting flashes are detected by a silicon photomultiplier whose output is amplified and processed before being digitized by a Raspberry Pi Pico’s ADC. The Pico calculates the pulses’ spectrum and generates a plot that can be stored on its on-board flash or downloaded to a computer.

[NuclearPhoenix] wrote a convenient program to help analyze the output data and made all design files open-source. The hardest part to find will be the scintillation crystal, but they do pop up on auction sites like eBay now and then. We’ve featured an Arduino-based gamma spectrometer before; if you’ve always wanted to roll your own scintillators, you can do that too. Continue reading “Identify Radioactive Samples With This DIY Gamma-Ray Spectrometer”

For Once, The Long Arm Of John Deere Presses The Right Button

Over many years now we’ve covered right-to-repair stories, and among them has been a constant bête noire. The American farm machinery manufacturer John Deere whose instantly recognisable green and yellow tractors have reliably tilled the soil for over a century, have become the poster child for inappropriate use of DRM. It’s enough to make any farmer see red, but there’s a story from CNN which shows another side to manufacturer control. A Deere dealership in Melitopol, Ukraine, was looted by invading Russian forces, who took away an estimated $5m worth of farm machinery. The perfect crime perhaps, save for the Deere computer system being used to remotely disable them leaving the crooks with combine harvesters they can’t even start.

It makes for a good news story showing the Ukranians getting one over on the looters, and since on-farm thefts are a hot topic anywhere in the world it’s not entirely unexpected that Deere would have incorporated a kill-switch in their products. Recently we covered a look at how the relationship between motor vehicle owner and manufacturer is changing from one of product ownership to software licence, and this is evidently an example of the same thing in the world of machinery. It’s reported that the looters are seeking the help of tractor hackers, which may be unfortunate for them since the world’s go-to source for hacked Deere software is Ukraine. Perhaps they would be better remembering that Russia has legendary tractors of its own.

Thanks [Robert Piston] for the tip.

DIY Metal Detector Gives You The Mettle To Find Some Medals

Hurricane season is rapidly approaching those of us who live in the northern hemisphere. While that does come with a good deal of stress for any homeowners who live in the potential paths of storms it also comes with some opportunities for treasure hunting. Storms tend to wash up all kinds of things from the sea, and if you are equipped with this DIY metal detector you could be unearthing all kinds of interesting tchotchkes from the depths this year.

The metal detector comes to us from [mircemk] who is known for building simple yet effective metal detectors. Unlike his previous builds, this one uses only a single integrated circuit, the TL804 operational amplifier. It also works on the principle of beat-balance which is an amalgamation of two unique methods of detecting metal.  When the wire coils detect a piece of metal in the ground, the information is fed to an earpiece through an audio jack which rounds out this straightforward build.

[mircemk] reports that this metal detector can detect small objects like coins up to 15 cm deep, and larger metal objects up to 50 cm. Of course, to build this you will also need the support components, wire, and time to tune the circuit. All things considered, though it’s a great entryway into the hobby.

Want to learn more about metal detecting? Check out this similar-looking build which works on the induction balance principle.

Continue reading “DIY Metal Detector Gives You The Mettle To Find Some Medals”

This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures

To start our week of vulnerabilities in everything, there’s a potentially big vulnerability in Android handsets, but it’s Apple’s fault. OK, maybe that’s a little harsh — Apple released the code to their Apple Lossless Audio Codec (ALAC) back in 2011 under the Apache License. This code was picked up and shipped as part of the driver stack for multiple devices by various vendors, including Qualcomm and MediaTek. The problem is that the Apple code was terrible, one researcher calling it a “walking colander” of security problems.

Apple has fixed their code internally over the years, but never pushed those updates to the public code-base. It’s a fire-and-forget source release, and that can cause problems like this. The fact that ALAC was released under a permissive license may contribute to the problem. Someone (in addition to Apple) likely found and fixed the security problems, but the permissive license doesn’t require sharing those fixes with a broader community. It’s worth pondering whether a Copyleft license like the GPL would have gotten a fix distributed years ago.

Regardless, CVE-2021-0674 and CVE-2021-0675 were fixed in both Qualcomm and MediaTek’s December 2021 security updates. These vulnerabilities are triggered by malicious audio files, and can result in RCE. An app could use this trick to escape the sandbox and escalate privileges. This sort of flaw has been used by actors like the NSO group to compromise devices via messaging apps. Continue reading “This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures”