Even when the boss is away, the show must go on, so Dan slid back behind the guest mic and teamed up with Tom to hunt down the freshest of this week’s hacks. It was a bit of a chore, with a couple of computer crashes and some side-quests down a few weird rabbit holes, but we managed to get things together in the end.
Tune in and you’ll hear us bemoan HOAs and celebrate one ham’s endless battle to outwit them, no matter what the golf cart people say about his antennas. Are you ready to say goodbye to the magnetic stripe on your credit card? We sure are, but we’re not holding our breath yet. Would you 3D print a 55-gallon drum? Probably not, but you almost can with a unique Cartesian-polar hybrid printer. And, if you think running MS-DOS on a modern laptop is hard, guess again — or, maybe you just have to get really lucky.
We also took a look at a digital watch with a beautiful display, a hacked multimeter, modern wardriving tools, switchable magnets, and debate the eternal question of v-slot wheels versus linear bearings. And finally, you won’t want to miss our look at what’s new with 3D scanning, and the first installment of Kristina’s new “Boss Byproducts” series, which delves into the beauty of Fordite.
The Hackaday comments section is generally a lively place. At its best, it’s an endless wellspring of the combined engineering wisdom of millions of readers which serves to advance the state of the art in hardware hacking for all. At its worst — well, let’s just say that at least it’s not the YouTube comments section.
Unfortunately, there’s also a space between the best and the worst where things can be a bit confusing. A case in point is [Bryan Cockfield]’s recent article on a stealth antenna designed to skirt restrictions placed upon an amateur radio operator by the homeowners’ association (HOA) governing his neighborhood.
Hiding an antenna in plain sight.
Putting aside the general griping about the legal and moral hazards of living under an HOA, as well as the weirdly irrelevant side-quest into the relative combustibility of EVs and ICE cars, there appeared to be a persistent misapprehension about the reality of the US Federal Communications Commission’s “Over-the-Air Reception Devices” rules. Reader [Gamma Raymond] beseeched us to clarify the rules, lest misinformation lead any of our readers into the unforgiving clutches of the “golf cart people” who seem to run many HOAs.
According to the FCC’s own OTARD explainer, the rules of 47 CFR § 1.400 are intended only to prevent “governmental and nongovernmental restrictions on viewers’ ability to receive video programming signals” (emphasis added) from three distinct classes of service: direct satellite broadcasters, broadband radio service providers, and television broadcast services.
Specifically, OTARD prevents restrictions on the installation, maintenance, or use of antennas for these services within limits, such as dish antennas having to be less than a meter in diameter (except in Alaska, where dishes can be any size, because it’s Alaska) and restrictions on where antennas can be placed, for example common areas (such as condominium roofs) versus patios and balconies which are designated as for the exclusive use of a tenant or owner. But importantly, that’s it. There are no carve-outs, either explicit or implied, for any other kind of antennas — amateur radio, scanners, CB, WiFi, Meshtastic, whatever. If it’s not about getting TV into your house in some way, shape, or form, it’s not covered by OTARD.
It goes without saying that we are not lawyers, and this is not to be construed as legal advice. If you want to put a 40′ tower with a giant beam antenna on your condo balcony and take on your HOA by stretching the rules and claiming that slow-scan TV is a “video service,” you’re on your own. But a plain reading of OTARD makes it clear to us what is and is not allowed, and we’re sorry to say there’s no quarter for radio hobbyists in the rules. This just means you’re going to need to be clever about your antennas. Or, you know — move.
Blink and you could have missed it, but a viral sensation for a few weeks this summer was One Million Checkboxes, a web page with as you might expect, a million checkboxes. The cool thing about it was that it was interactive, so if you checked a box on your web browser, everyone else seeing that box also saw it being checked. You could do pixel art with it, and have some fun. While maintaining it, its author [eieio] noticed something weird, a URL was appearing in the raw pixel data. Had he been hacked? Investigation revealed something rather more awesome.
The display of checkboxes was responsive rather than fixed-width, on purpose to stop people leaving objectionable content. Any pixel arrangement would only appear as you made it to someone viewing with exactly the same width of checkboxes. But still, the boxes represented a binary bitfield, so of course people saw it and had fun hacking. The URLs appeared because they were ASCII encoded in the binary, and were left on purpose as a message to the developer inviting him to a forum.
On it he found a disparate group of teen hackers who’d formed a community having fun turning the game into their own version of a Pixelflut. If you’ve not seen the game previously, imagine a screen on which all pixels are individually addressable over the internet. Place it in a hackerspace or in the bar at a hacker camp, and of course the coders present indulge in a bit of competitive pixel-spamming to create a colorful and anarchic collaborative artwork. In this case as well as artwork they’d encoded the forum link in several ways, and had grown a thriving underground community of younger hackers honing their craft. As [eieio] did, we think this is excellent, and if any of the checkbox pixelflutters are reading this, we salute you!
Before he eventually took the site down he removed the rate limit for a while to let them really go to town, and predictably, they never gave up on the opportunity, and didn’t let him down.
Some people would call the activity discussed here antisocial, but in particular we agree with the final point in the piece. Young hackers like this don’t need admonishment, they need encouragement, and he’s done exactly the right thing. If you want to read more about Pixelflut meanwhile, we’ve been there before.
We finally have some answers about the Windows IPv6 vulnerability — and a Proof of Concept! The patch was a single change in the Windows TCP/IP driver’s Ipv6pProcessOptions(), now calling IppSendError() instead of IppSendErrorList(). That’s not very helpful on its own, which is why [Marcus Hutchins]’s analysis is so helpful here. And it’s not an easy task, since decompiling source code like this doesn’t give us variable names.
The first question that needs answered is what is the list in question? This code is handling the option field in incoming IPv6 packets. The object being manipulated is a linked list of packet structs. And that linked list is almost always a single member list. When calling IppSendErrorList() on a list with a single member, it’s functionally equivalent to the IppSendError() in the fixed code. The flaw must be in the handling of this list with multiple members. The only way to achieve that criteria is to send a lot of traffic at the machine in question, so it can’t quite keep up with processing packets one at a time. To handle the high throughput, Windows will assemble incoming packets into a linked list and process them in batch.
So what’s next? IppSendErrorList(), takes a boolean and passes it on to each call of IppSendError(). We don’t know what Microsoft’s variable name is, but [Marcus] is calling it always_send_icmp, because setting it to true means that each packet processed will generate an ICMP packet. The important detail is that IppSendError() can have side effects. There is a codepath where the packet gets reverted, and the processing pointer is set back to the beginning of the packet. That’s fine for the first packet in the list, but because the function processes errors on the entire list of packets, the state of the rest of those packets is now much different from what is expected.
This unexpected but of weirdness can be further abused through IPv6 packet fragmentation. With a bit of careful setup, the reversion can cause a length counter to underflow, resulting in data structure corruption, and finally jumping code execution into the packet data. That’s the Remote Code Execution (RCE). And the good news, beyond the IPv6-only nature of the flaw, is that so far it’s been difficult to actually pull the attack off, as it relies on this somewhat non-deterministic “packet coalescing” technique to trigger the flaw.
Recently Raspberry Pi released the 2GB version of the Raspberry Pi 5 with a new BCM2712 SoC featuring the D0 stepping. As expected, [Jeff Geerling] got his mitts on one of these boards and ran it through its paces, with positive results. Well, mostly positive results — as the Geekbench test took offence to the mere 2 GB of RAM on the board and consistently ran out of memory by the multi-core Photo Filter test, as feared when we originally reported on this new SBC. Although using swap is an option, this would not have made for a very realistic SoC benchmark, ergo [Jeff] resorted to using sysbenchinstead.
Naturally some overclocking was also performed, to truly push the SoC to its limits. This boosted the clock speed from 2.4 GHz all the way up to 3.5 GHz with the sysbench score increasing from 4155 to 6068. At 3.6 GHz the system wouldn’t boot any more, but [Jeff] figured that delidding the SoC could enable even faster speeds. This procedure also enabled taking a look at the bare D0 stepping die, revealing it to be 32.5% smaller than the previous C1 stepping on presumably the same 16 nm process.
Although 3.5 GHz turns out to be a hard limit for now, the power usage was interesting with idle power being 0.9 watts lower (at 2.4 W) for the D0 stepping and the power and temperatures under load also looked better than the C1 stepping. Even when taking the power savings of half the RAM versus the 4 GB version into account, the D0 stepping seems significantly more optimized. The main question now is when we can expect to see it appear on the 4 and 8 GB versions of the SBC, though the answer there is likely ‘when current C1 stocks run out’.
It may be the last gasp of summer here in the Northern Hemisphere, but it’s always cold somewhere, whether it’s outdoors or inside. If you suffer from cold, stiff hands, you know how difficult it can be to work comfortably on a computer all day. Somehow, all that typing and mousing does little to warm things up. What you need are hand warmers, obviously, and they might as well be smart and made to fit your hands.
Fifteen-year-old [Printerforge] created these bad boys in an effort to learn how to code LCDs and control heat like Magneto controls ferrous metals. Thanks to digital control, they can heat up to specific temperatures, and they happen to run for a long time.
Power-wise, these warmers use a 18650 cell and a TP4056 charging module. Everything is controlled by an Arduino Nano, which reads from both a thermistor and a potentiometer to control the output.
[Printerforge] really thought this project through, as you’ll see in the Instructable. There’s everything from a table of design requirements to quick but thorough explanations of nichrome wire and basic electronic theory.
And then there’s the material consideration. [Printerforge] decided that polymer clay offers the best balance of heat conductivity and durability. They ended up with two styles — flat, and joystick grip. The best part is, everything can fit in a generous pocket.
If there’s a reason that fancy holographic displays that respond to gestures are a science fiction staple, it’s probably because our current display technology is terrible. Oh sure, Retina displays and big curved gaming monitors are things of wonder, but they’re also things that occupy space even when they’re off — hence the yearning for a display that can appear and disappear at need.
Now, we’re not sure if [Maker Mac70]’s floating display is the answer to your sci-fi dreams, but it’s still pretty cool. And, as with the best of tricks, it’s all done with mirrors. The idea is to use a combination of a partially reflective mirror, a sheet of retroreflective material, and a bright LCD panel. These are set up in an equilateral triangle arrangement, with the partially reflective mirror at the top. Part of the light from the LCD bounces off the bottom surface of the mirror onto a retroreflector — [Mac] used a sheet of material similar to what’s used on traffic signs. True to its name, the retroreflector bounces the light directly back at the semi-transparent mirror, passing through it to focus on a point in space above the whole contraption. To make the display interactive, [Mac] used a trio of cheap time-of-flight (TOF) sensors to watch for fingers poking into the space into which the display is projected. It seemed to work well enough after some tweaking; you can check it out in the video below, which also has some great tips on greebling, if that’s your thing.
We suspect that the thumbnail for the video is a composite, but that’s understandable since the conditions for viewing such a display have to be just right in terms of ambient light level and the viewer’s position relative to the display. [Mac] even mentions the narrow acceptance angle of the display, touting it as a potential benefit for use cases where privacy is a concern. In any case, it’s very different from his last sci-fi-inspired volumetric display, which was pretty cool too.
