One of the great things about the Hackaday community is how quickly you find out what you don’t know. That’s not a bad thing, of course; after all, everyone is here to get smarter, right? So let’s work together to get our heads around this paper (PDF) by [Zerina Kapetanovic], [Miguel Morales], and [Joshua R. Smith] from the University of Washington, which purports to construct a low-throughput RF transmitter from little more than a resistor.

This witchcraft is made possible thanks to Johnson noise, also known as Johnson-Nyquist noise, which is the white noise generated by charge carriers in a conductor. In effect, the movement of electrons in a material thanks to thermal energy produces noise across the spectrum. Reducing interference from Johnson noise is why telescopes often have their sensors cooled to cryogenic temperatures. Rather than trying to eliminate Johnson noise, these experiments use it to build an RF transmitter, and with easily available and relatively cheap equipment.

On the transmitter side, we have little more than an antenna connected to the common side of a digital RF switch, an Analog Devices ADG901 eval board. The switch toggles the antenna between a 50-Ohm dummy load or ground; this allows data to be modulated with on-off keying, with the Johnson noise generated by the dummy load representing a logical 1. The antenna is a pyramidal horn antenna made from foil-covered foamboard, offering 13.6 dBi of gain. The receiver is a pair of high-gain LNAs, a bandpass filter, and an SDR dongle with a Raspberry Pi, all attached to an identical antenna.

After running a number of control experiments to make sure they weren’t measuring general RF noise or feedthrough from the RF switch control signal, the authors did several demonstrations of what can be done with this. They were able to show throughput in the 20 bps range at 1.42-GHz, over distances of up to 7 meters, and offered a couple of practical uses, such as a battery-free remote temperature sensor.

It’s important to note that this isn’t using backscatter of ambient RF signals from local radio stations; we’ve seen those before and were suitably impressed with what they can do. This is just relying on thermal noise to generate a carrier, and that’s pretty cool too. We’d love to see someone replicate this — if you do, make sure you drop us a tip so we can write it up.

Thanks to [Reed] for the tip!

The condition PLA evaluates microcode conditionals.
As simple as a processor’s instruction set may seem, especially in a 1978-era one like the Intel 8086, there is quite a bit going on to go from something like a conditional jump instruction to a set of operations that the processor can perform. For the CISC 8086 CPU this is detailed in a recent article by [Ken Shirriff], which covers exactly how the instructions with their parameters are broken down into micro-instructions using microcode, which allows the appropriate registers and flags to be updated.

Where the 8086 is interesting compared to modern x86 CPUs is how the microcode is implemented, using gate logic to reduce the complexity of the microcode by for example generic parameter testing when processing a jump instruction. Considering the limitations of 1970s VLSI manufacturing, this was very much a necessary step, and an acceptable trade-off.

Each jump instruction is broken down into a number of micro-instructions that test a range of flags and updates (temporary) registers as well as the program counter as needed. All in all a fascinating look at the efforts put in by Intel engineers over forty years ago on what would become one of the cornerstones of modern day computing.

You can buy gears off the shelf, of course, and get accurately machined parts exactly to your chosen specification. However, there’s something rugged and individualist about producing your own rotating components. [Maciej Nowak] demonstrates just how to produce your own gears with a homemade cutting tool.

The cutting tool for the job is an M16 machine tap, chosen for the smaller flutes compared to a hand tap. This makes it more suitable for cutting gears. It’s turned by a belt driven pulley, run by a small motor. The workpiece to be cut into a gear is then fed into the cutting tool by sliding on a linear bearing, with its position controlled by a threaded rod. The rod can be slowly turned by hand to adjust the workpiece position, to allow the gear teeth to be cut to an appropriate depth.

The method of action is simple. As the tap turns it not only cuts into the workpiece, but rotates it on a bearing as well. By this method, it cuts regular teeth into the full circumference, creating a gear. Obviously, this method doesn’t create highly-complex tooth shapes for ultimate performance, but it’s more than capable of creating usable brass and steel gears for various purposes. The same tool can be used to cut many different sizes of gear to produce a whole geartrain. As a bonus, the resulting gears can be used with M16 threads serving as worm gears, thanks to the pitch of the tap.

If you find yourself needing to produce tough metal gears on the regular, you might find such a tool very useful. Alternatively, we’ve explored methods of producing your own sprockets too, both in a tidy manner, and in a more haphazard fashion. Video after the break.

https://www.youtube.com/embed/vP3EHZ-S0sY?version=3&rel=1&showsearch=0&showinfo=1&iv_load_policy=1&fs=1&hl=en-US&autohide=2&wmode=transparent

Anyone in the JDM scene can tell you, round air vents are prime real estate for round analog gauges. If you want a gauge but don’t want to block your vent, you could consider building these LED vent gauges from [ktanner] instead.
Tasteful, no?
The design is simple. It relies on 3D printing a replacement bezel for the Mazda Miata’s stock round air vents. This bezel is designed to hold a NeoPixel ring from Adafruit. When built with the optional laser-cut diffuser, the parts have a near-stock look when the LEDs are turned off. It’s a classy, stealthy mod – exactly the sort of thing Miata owners need but never seem to have! (Author Note: don’t be mad, I was once one of you!)

With 24 addressable RGB LEDs, it’s possible to display all kinds of data by turning the LEDs on and off and varying the colors. For example, you could readily build a boost gauge that turns on more LEDs at higher boost pressure. It could then be set up to flash red in the event that you surpass safe thresholds. [ktanner] hasn’t specified any particular microcontroller for the setup — but just about any part you like can be used to drive NeoPixels, after all.

If you’re new to NeoPixels, you might find a simulator useful for developing your projects. Meanwhile, if you’re doing similar work on other cars, be sure to hit us up on the tipsline!

This week, Editor-in-Chief Elliot Williams and Managing Editor Tom Nardi meet up virtually to talk about all the hacks that are fit to print. This week’s episode starts off with a discussion about the recently unveiled 2023 Hackaday.io Low-Power Challenge, and how hackers more often than not thrive when forced to work within these sort of narrow parameters. Discussion then continues to adding a virtual core to the RP2040, crowd-sourced device reliability information, and mechanical Soviet space computers. We’ll wrap things up by wondering what could have been had Mattel’s ill-fated ThingMaker 3D printer actually hit the market, and then engage in some wild speculation about the issues plaguing NASA’s latest Moon mission.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

https://html5-player.libsyn.com/embed/episode/id/25748694/height/90/theme/custom/thumbnail/yes/direction/backward/render-playlist/no/custom-color/000000/

Available in the cloud, or as download!

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• Google Podcasts
• iTunes
• Spotify
• Stitcher
• RSS

Episode 203 Show Notes:

News:

• Hackaday.io Low-Power Challenge Begins Today

What’s that Sound?

• Congrats to [TheElectricCanuck] for getting the sound of musical cards in bike spokes.

Interesting Hacks of the Week:

• RP2040 DMA Hack Makes Another ‘CPU Core’
• You Can Help Build A Resin Printer Review Database
• DIY Capacitor Leakage Tester With A Professional Finish
• Inside Globus, A Soviet-Era Analog Space Computer
• Designing A Simpler Prosthetic Finger
• Secure LoRa Mesh Communication Network

Quick Hacks:

• Elliot’s Picks:
  • Knitting Clock Makes You A Scarf For Next Year
  • Minimalist Homebrew Hardware Recreates Arcade Classics
  • Floppy Photog: Making An IR Filter From A 3.5″ Disk
• Tom’s Picks:
  • Bend It Like A Carpenter
  • Cassette Player Cupholder Is A Useful But Risky Idea
  • Wii Turned Expansion Card For Broadcast Monitor

Can’t-Miss Articles:

• Ask Hackaday: Do Kids Need 3D Printers?
• NASA Lunar Probe Finds Out It’s Not Easy Being Green

Looking for the perfect winter desk accessory? [Wq] has created a beautiful coaster made out of PCBs that can keep your drink warm with an internal heater. (Chinese).

An ESP8266 sits as the main controller, with an additional MQTT control option, where the whole unit is powered over a USB-C connection. On board PCB traces, in the shape of a Hilbert curve, create the heating element used to heat beverages placed on the coaster, where [Wq] reports a measured resistance of the PCB trace network at 1.2 ohms. [Wq] writes that an AON6324 MOSFET replaces the D4184 that was previously being used, but might need some testing to get working properly. There are two capacitive touch sensors which has a TTP223E capacitive touch controller attached to detect input, with a multi-colored FM-3528 RGB LED for user feedback.

We love the artistry that went into building the coaster. For adventurous hackers wanting to build their own, the bill of materials (BOM), source code and board files are all available. We’ve seen everything from coasters and to PCB reflow boards, so it’s nice to see experimentation with a combination of these ideas.

When we first saw tweets about a security issue in Grand Theft Auto V, it sounded a bit like a troll. “Press ‘alt and f4’ to unlock a cheat mode”, or the hacker that claims to be able to delete your character. [Tez2]’s warning tweet that you shouldn’t play GTA Online without a firewall sounds like another of these online urban legends. But this one actually seems legit. NIST is even in on the fun, assigning CVE-2023-24059 for the exploit.

When playing an online game, other users send a “join request” to join the active session. This packets can contain malformed data which has been observed to crash the game client remotely. It’s believed, though not publicly confirmed, that it’s also a Remote Code Execution (RCE) vulnerability. It seems likely that this aspect will be added to some of the various cheat panels that are already widely used for this 10-year-old game. So now, rather than just giving your own character infinite ammo and health, you can inflict some havoc on other players, possibly up to corrupting their character files and getting them banned.

But why stop there? If we have code execution inside the game, what stops another player from launching a real attack? A video game isn’t sandboxed like a browser, and there’s nothing preventing a disk wiper attack or even a worm from compromising a bunch of players. The worst part is that it’s an old game, and even though there’s a large playerbase, it’s not guaranteed to get a fix. There’s at least one project aiming to be a firewall to prevent the issue.

XNU’s 19 and 20 year old Bugs

[Adam Doupé] seems to have a knack for finding old bugs in Apple’s code, and this time it’s a pair of really old flaws in Apple’s kernel, XNU. The first is an issue in dlil.c, the network interface handler. This issue is a type casting error, where an int is cast to a uint_16. If that cast overflows, the value becomes a large negative number, and the subsequent data write underflows the buffer and writes out-of-bounds. The method to trigger this one is a bit tricky, as it requires creating 65536 network interfaces.

There are two approaches to triggering that condition. The first is the simplest, a tiny script running as root, that calls ifconfig repeatedly to create the interfaces. While that could be interesting as part of an exploit chain, the more interesting idea is to make a malicious USB dongle that presents itself as multiple network interfaces. The rest of the post is [Adam]’s attempt to turn the underflow into an exploit. He didn’t quite pull it off, but it looks like it’s possible.

The second bug is even older, a 20 year old flaw in XNU’s ndrv.c, the raw socket handler. It’s an edge case where a linked list with two members get improperly walked, one of the list members is freed, but the parent item still contains a pointer to the now-freed memory. Both bugs have now been fixed in the latest iOS and macOS releases.

Android (ARM) Too

Android isn’t one to be left out, with a great writeup from [Man Yue Mo] of Github Security Lab, about a problem in the Arm Mali GPU shipped as part of Pixel 6 devices. With great irony, we are told of how the one non-Google element in the all-Google phone led to kernel-space exploitation from within an app. Specifically, it’s the driver for that GPU, and how it handles JIT memory, which is memory segments that are managed by the kernel, and accessed by userspace and directly by the GPU. And as you might expect, having three different components accessing memory at once can cause problems.

In this case, the problem is how eviction is handled. Those chunks of memory get processed, and then can be returned to the free store. A performance optimization by the driver is to keep memory buffers “warm”, not actually asking the kernel to free them, and skipping the allocation process when the next request is needed. The problem is that memory in this limbo state is considered “evictable”, and the kernel can free those regions without doing so through the GPU driver. This leave the system in an odd state where the GPU driver and userspace still have valid pointers to a memory location, but the kernel has marked it free. The real fun begins when the freed memory location is claimed by an attacking process, and a fake JIT object put in its place. By some clever memory manipulation, this can be leveraged to produce a userspace mapping of kernel code, which can then be read and written. And the simplest step from there is to just modify the userspace application, making it run as root.

It’s a clever find, but what really stands out is the problem with getting it fixed. This was reported to Android engineers in July of 2022, and a few weeks later the report was closed as a “Won’t fix” issue. There is a legitimate point here, that it’s not Android code that contains the problem, and this needed to be fixed in the ARM driver. ARM issued an update that fixed the issue less than three months later, in August of 2022. A coordinated disclosure was scheduled with ARM for November, but it seems the Android engineers completely dropped the bug, and waited til the January update to finally ship the patch to Android users. And when it finally came, it was tracked as a different bug altogether, meaning the original report was closed and forgotten about. It’s a bit disheartening to see Google show such a flippant attitude toward a vulnerability of this severity, on their own product.

KSMBD Again

It’s beginning to look like a bad idea to put the Server Message Block Daemon driver in the Linux kernel, as we have another pre-auth integer underflow leading to denial of service. Researchers at Sysdig found the flaw this time, researching based on the previous ZDI-22-1690, which was a more serious RCE in the same kernel module. This one is a bit different from other integer underflows we’ve looked at. The wrap-around nature of integers instead saves this vulnerability from being a more serious one.

The real problem is that during SMB authentication, the data structure from the remote user contains a pair of length values, which are used to parse the incoming authentication data. It’s obvious that these values aren’t implicitly trusted, and some good error checking is done to prevent a trivial buffer overflow. The case that trips us up is when nt_len is less than CIFS_ENCPWD_SIZE, and the resulting value is negative. When this negative integer is cast to the unsigned size_t in a memcpy() call, the negative integer is “unwrapped” to a nearly max-value size_t. The memory copy function will attempt the instruction, but this is a rather uncontrolled operation, and eventually reaches inaccessible memory, and panics the kernel. So far there doesn’t seem to be a way to turn this particular flaw into a true RCE. And besides, after this many years, surely everyone knows not to expose an SMB service to untrusted users, right?

Insecure Boot

While Secure Boot hasn’t quite proven to be the dystopian PC lock-in that some of us feared, it’s still occasionally a pain to deal with while trying to fix something on a broken machine. Need a custom boot disk to run a tool? Yep, time to disable secure boot. But there’s a few cases where it’s helpful, like preventing boot malware from getting a toe-hold in an encrypted system. There’s maybe something to be said for a known quantity like secure boot.

Which is why it’s a bit odd to find that MSI decided to compromise it en masse on their desktop motherboards in a firmware update pushed out last January. And do note, MSI didn’t turn off secure boot. Check the firmware settings, or run mokutil --sb-state, and these machines would happily inform you that Secure Boot was still enabled. But an obscure firmware setting, “Image Execution Policy” is set to “Always Execute” — so Secure Boot would still check the signature on the boot stack, and then boot it regardless of what was found. I’ll just quote the discoverer, [Dawid Potocki]’s conclusion: “Don’t trust that whatever security features you enabled are working, TEST THEM!”

QT’s RCE Vulnerability Bug

The QT suite has an issue, where Javascript embedded in QML (Qt Modeling Language) code could trigger one of two memory handling issues, and achieve RCE. There’s a bit of disagreement between Cisco Talos and QT, as to whether this is a simple bug, or security vulnerability. QML code is explicitly intended to be user interface code for applications, and should never execute untrusted code. In fact, according to QT, the security vulnerability would be any “application that is passing untrusted input to QtQml”.