2026-03-07 02:30:29
Out of all of Batman’s massive array of tools which turn a relatively ordinary person into a superhero, perhaps his most utilitarian is his grappling gun — allowing him the ability to soar around his city like Spiderman or Superman. [John Boss] isn’t typically fighting crime, but he did develop his own grappling gun of sorts which gives him another superpower: the ability to easily scale snowy hills to quickly get back to the top.
The grappling gun takes inspiration from a commonly used tool called a power ascender, which is often used in industry applications where climbing is required. This one is held in the hand and uses a brushless motor with a belt-driven 3:1 reduction for increased torque. The pulley system, bearings, and motor are all housed in a 3D printed enclosure and are powered by rechargeable Milwaukee power tool batteries. During prototyping the rope intake and output feed locations had to be moved to increase the pulley’s grabbing ability, and with a working prototype he swapped a lot of the plastic 3D printed parts out for metal to increase the sturdiness of the device.
The grappling gun was originally designed for a smaller child to get hoisted up a hill on a sled, but when stress testing the device [John] found out that it actually has more than enough capability to haul even an adult up a hill on skis. As an added bonus, the outfeed for the rope can be put into a bag and used to automatically coil the rope up when he’s done at the hill. Although this is a great solution for a portable rope tow, for something more permanent and more powerful take a look at this backyard rope tow that was built from spare parts.
2026-03-07 01:30:12
This week, Hackaday’s Elliot Williams and Kristina Panos met up over assorted beverages to bring you the latest news, mystery sound results show, and of course, a big bunch of hacks from the previous seven days or so.
In the news, we’ve launched a brand-new contest! Yes, the Green-Powered Challenge is underway, and we need your entry to truly make it a contest. You have until April 24th to enter, so show us what you can do with power you scrounge up from the environment around you!
On What’s That Sound, Kristina was leaning toward some kind of distant typing sounds, but [Konrad] knew it was our own Tom Nardi’s steam heat radiator pinging away.
After that, it’s on to the hacks and such, beginning with an exploration of all the gross security vulnerabilities in a cheap WiFi extender, and we take a look inside a little black and white pay television like you’d find in a Greyhound station in the 80s and 90s.
We also discuss the idea of mixing custom spray paint colors on the fly, a pen clip that never bends out of shape, and running video through a guitar effects pedal. Finally, we discuss climate engineering with disintegrating satellites, and the curse of everything device.
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!
Download in DRM-free MP3 and savor at your leisure.
2026-03-07 00:30:45
The SGI O2 was SGI’s last-ditch attempt at a low-end MIPS-based workstation back in 1996, and correspondingly didn’t use the hottest parts of the time, nor did it offer much of an upgrade path. None of which is a concern to hobbyists who are more than happy to work around any hardware- and software limitations to e.g. install much faster CPUs. While quite a few CPU upgrades were possible with just some BGA chip reworking skills, installing the 900 MHz RM7900 would require some PROM hacking, which [mattst88] recently took a shake at.
The initial work on upgrading SGI O2 systems was done in the early 2000s, with [Joe Page] and [Ian Mapleson] running into the issue that these higher frequency MIPS CPUs required a custom IP32 PROM image, for which they figured that they’d need either SGI’s help. Since SGI is no longer around, [mattst88] decided to take up the torch.
After downloading a 512 kB binary dump of the last version of the O2’s PROM, he set to work reverse-engineering it, starting by dissembling the file. A big part of understanding MIPS PROM code is understanding how the MIPS architecture works, including its boot process, so much of what followed was a crash-course on the subject.
With that knowledge it was much easier to properly direct the Capstone disassembler and begin the arduous process of making sense of the blob of data and code. The resulting source files now reassemble into bit-identical ROM files, which makes it likely that modifying it to support different CPUs is now possible with just a bit more work.
For those who want to play along, [mattst88] has made his ip32prom-decompiler project available on GitHub.
Thanks to [adistuder] for the tip.
Top image: Silicon Graphics 1600SW LCD display and O2 workstation. (Source: Wikimedia)
2026-03-06 23:00:50
Editor’s Note: Over the course of nearly 300 posts, Jonathan Bennett set a very high bar for this column, so we knew it needed to be placed in the hands of somebody who could do it justice. That’s why we’re pleased to announce that Mike Kershaw AKA [Dragorn] will be taking over This Week In Security! Mike is a security researcher with decades of experience, a frequent contributor to 2600, and perhaps best known as the creator of the Kismet wireless scanner.
He’ll be bringing the column to you regularly going forward, but given the extended period since we last checked in with the world of (in)security, we thought it would be appropriate to kick things off with a review of some of the stories you may have missed.
Hello all! It’s a pleasure to be here, and it already seems like a theme of the new year so far has bringing in the old bugs – what’s old is new again, and 2026 has seen several fixes to some increasingly ancient bugs.
Reported on the OpenWall list, the GNU inetd suite brings an update to the telnet server (yes, telnet) that closes a login bug present since 2015 linked to environment variable sanitization.
Under the covers, the telnet daemon uses /bin/login to perform user authentication, but also has the ability to pass environment variables from the client to the host. One of these variables, USER, is passed directly to login — unfortunately this time with no checking to see what it contains. By simply passing a USER variable of “-froot”, login would accept the “-f” argument, or “treat this user as already logged in”. Instant root!
If this sounds vaguely familiar, it might be because the exact same bug was found in the Solaris telnetd service in 2007, including using the “-f” argument in the USER variable. An extremely similar bug targeting other variables (LD_PRELOAD) was found in the FreeBSD telnetd service in 2009, and other historical similar bugs have afflicted AIX and other Unix systems in the past.
Of course, nobody in 2026 should be running a telnet service, especially not exposed to the Internet, but it’s always interesting to see the old style of bugs resurface.
Also reported on the OpenWall list, glibc — the GNU LibC library which underpins most binaries on Linux systems, providing kernel interfaces, file and network I/O, string manipulation, and most other common functions programmers expect — has killed another historical bug, present since 1996 in the DNS resolver functions which could be used to expose some locations in the stack.
Although not exploitable directly, the getnetbyaddr resolution functions could still ease in breaking ASLR, making other exploits viable.
Address Space Layout Randomization (ASLR) is a common method of randomizing where in memory a process and its data are loaded, making trivial exploits like buffer overflows much harder to execute. Being able to expose the location of the binary in memory by leaking stack locations weakens this mechanism, possibly exposing a vulnerable program to more traditional attacks.
In February, Microsoft released fixes under CVE-2026-21513 for the MSHTML Trident renderer – the one used in Internet Explorer 5. Apparently still present in Windows, and somehow still accessible through specific shortcut links, it’s the IE5 and Active-X gift that keeps giving, being actively exploited.
After that bit of computing nostalgia, let’s look at some interesting stories involving slightly more contemporary subjects.
It’s easy to think of JavaScript as simply a client-side language, but of course it’s also used in server frameworks like node.js and React, the latter being used heavily in the popular Next.JS framework server components.
Frameworks like React blur the lines between client and server, using the same coding style and framework conventions in the browser and in the server-side engine. React and NextJS allow calling server-side functions from the client side, mixing client and server side rendering of content, but due to a deserialization bug, React allowed any function to be called from a non-privileged client.
Cleverly named React2Shell, it has rapidly become a target for bulk exploitation, with Internet-scale monitoring firm GreyNoise reporting 8 million logged attempts by early January 2026. At this point, it’s safe to assume any Internet-exposed vulnerable service has been compromised.
As previously covered by Hackaday, the Curl project is officially ending bug bounties due to the flood of bogus submissions from AI tools. The founder and project lead, Daniel Sternberg, has been critical of AI-generated bug bounties in the past, and has finally decided the cost is no longer worth the gains.
In many ways this calls to mind the recent conflict between the ffmpeg team and Google, where Google Project Zero discovered a flaw in the decoding of a relatively obscure codec, assigning it a 90-day disclosure deadline and raising the ire of the open source volunteer team.
The influx of AI-generated reports is the latest facet of the friction between volunteer-led open source projects, and paid bug bounties or other commercial interests. Even with sponsorship backing, the reach of popular open-source libraries and tools like Curl, OpenSSL, BusyBox, and more is often far, far greater than the compensation offered by the biggest users of those libraries — often trillion dollar multinational companies.
Many open source projects are the passion project of a small set of people, even if they become massively popular and critical to commercial tools and infrastructure. While AI tooling may generate actionable reports, when it is deployed by users who may not themselves be programmers and are unable to verify the results, it puts the time drain of determining the validity, and at times, arguing with the submitter, entirely on the project maintainers. As the asymmetry increases, more small open source teams may start rejecting clearly AI generated reports as well.
The OpenSSL library, another critical component of Internet infrastructure with a very small team, suffers from a vulnerability in PKCS12 parsing which appears to be a relatively traditional memory bug leaning to null pointers, stack corruption, or buffer overflows, which in the best case causes a crash and the worst case allows for arbitrary code execution. (Insert obligatory XKCD reference here.)
PKCS12 is a certificate storage format which bundles multiple certificates and private keys in a single file – similar to a zip or tar for certificate credentials. Fortunately PKCS12 files are typically already trusted, and methods to upload them are not often exposed to the Internet at large, unfortunately, potential code execution even when limited to a trusted network interface is rarely a positive thing.
The Notepad++ team has released a write-up about the infrastructure compromise which appears to have enabled a state-level actor to deliver infected updates to select customers.
Notepad++ is a fairly popular alternative to the classic Notepad app found on Windows, with support for syntax highlighting, multiple programming languages, and basic IDE functionality. According to the write-up by the team based on findings by independent researchers, in June 2025 the shared hosting service which served updates to Notepad++ was compromised, and remained so until September of 2025.
The root of the issue lies in the update library WinGUp, used by Notepad++, which did not validate the downloaded update, leaving it vulnerable to redirection and modification. With control of the update servers, the attackers were able to send specific customers to modified, trojaned updates.
An important take-away for all developers: if your project can self-update, make sure that the update process is secure against malicious actors. Which can mean the complex issues of not only validating the certificate chain, but sometimes embedding trusted certificates in your software (or firmware) and using them to validate that the update file itself has not been modified.
Finally, we have a new paper on WiFi security, with a new attack dubbed “AirSnitch”. From a team of collaborators including Mathy Vanhoef (a frequent publisher of modern WiFi attacks including the WPA2 KRACK attacks, and a driving force behind deprecating WPA2), AirSnitch defeats a protection in wireless networks known as “client isolation”.
Client isolation acts essentially as a firewall mechanism, which attempts to offer wireless clients an additional layer of security by preventing communication between clients on the same network. Optimally, this would prevent a hostile or infected client from communicating with other clients, despite being on the same shared network.
On a WPA encrypted WiFi network, each client has an individual key used for encryption, and a shared group key used by all clients for broadcast and multicast communication. For one client to communicate with another, the access point must decrypt the traffic from the first and re-encrypt it to the second. Preventing communication between clients should be as simple as not performing the encryption between clients, however by cloning the MAC address of the target client and establishing a second connection to the access point, and further manipulating the internal state of the access point with injected packets, a hostile device can cause the access point to share the data of the target, essentially converting the behavior of the network to a legacy Ethernet hub.
How significantly this might impact you will vary wildly, and likely the full impacts of the attack will take some time to be understood. An attacker still needs access to the network – for a WPA network this means the PSK must be known, and for an Enterprise network, login credentials are still required. Typically home networks don’t use client isolation at all – most home users expect devices to be able to communicate directly, and most public access networks use no encryption at all, leaving clients exposed to the same level of risk by default. Networks with untrusted clients, like educational campus networks or business bring-your-own-device networks, are likely at the greatest risk, but time will tell.
2026-03-06 20:00:12
There was a time when Linux was much simpler. You’d load a driver, it would find your device at boot up, or it wouldn’t. That was it. Now, though, people plug and unplug USB devices all the time and expect the system to react appropriately. [Arcanenibble] explains all “the gory details” about what really happens when you plug or unplug a device.
You might think, “Oh, libusb handles that.” But, of course, it doesn’t do the actual work. In fact, there are two possible backends: netlink or udev. However, the libusb developers strongly recommend udev. Turns out, udev also depends on netlink underneath, so if you use udev, you are sort of using netlink anyway.
If netlink sounds familiar, it is a generic BSD-socket-like API the kernel can use to send notifications to userspace. The post shows example code for listening to kernel event messages via netlink, just like udev does.
When udev sees a device add message from netlink, it resends a related udev message using… netlink! Turns out, netlink can send messages between two userspace programs, not just between the kernel and userspace. That means that the code to read udev events isn’t much different from the netlink example.
The next hoop is the udev event format. It uses a version number, but it seems stable at version 0xfeedcafe. Part of the structure contains a hash code that allows a bloom filter to quickly weed out uninteresting events, at least most of the time.
The post documents much of the obscure inner workings of USB hotplug events. However, there are some security nuances that aren’t clear. If you can explain them, we bet [Arcanenibble] would like to hear from you.
If you like digging into the Linux kernel and its friends, you might want to try creating kernel modules. If you get overwhelmed trying to read the kernel source, maybe go back a few versions.
2026-03-06 17:00:40
Light aircraft often use a heading indicator as a way to know where they’re going. Retired instrumentation engineer [Don Welch] recreated a heading indicator of his own, using cheap off-the-shelf hardware to get the job done.
The heart of the build is a Teensy 4.0 microcontroller. It’s paired with a BNO085 inertial measurement unit (IMU), which combines a 3-axis gyro, 3-axis accelerometer, and 3-axis magnetometer into a single package. [Don] wanted to build a heading indicator that was immune to magnetic disturbances, so ignored the magnetometer readings entirely, using the rest of the IMU data instead.
Upon startup, the Teensy 4.0 initializes a small round TFT display, and draws the usual compass rose with North at the top of the display. Any motion after this will update the heading display accordingly, with [Don] noting the IMU has a fast update rate of 200 Hz for excellent motion tracking. The device does not self-calibrate to magnetic North; instead, an encoder can be used to calibrate the device to match a magnetic compass you have on hand. Or, you can just ensure it’s already facing North when you turn it on.
Thanks to the power of the Teensy 4.0 and the rapid updates of the BNO085, the display updates are nicely smooth and responsive. However, [Don] notes that it’s probably not quite an aircraft-spec build. We’ve featured some interesting investigations of just how much you can expect out of MEMS-based sensors like these before, too.
