Today, movie effects are mostly done in CGI, especially if they’re of the death-defying type. [Tyler Bell] shows us how they shot actors with arrows before CGI.

Almost every medieval movie has someone getting shot with an arrow, but how do you do that non-destructively? [Bell] shows us two primary methods that were used, the pop up rig and steel pronged arrows. The pop up rig is a spring loaded device with one end of an arrow attached that pops up when a mechanism is triggered. [Bell] 3D printed his own version of the mechanism and shows us how it can be used to great effect on shots from the side or rear of the victim.

But what about straight on shots where the rig would be blatantly obvious? That’s when you get to actually shoot the actor (or their stunt double anyway). To do this safely, actors would wear wooden body armor under their costumes and arrows with two small prongs would be shot along a wire into the desired impact site. We appreciate [Bell] using a mannequin for testing before letting his brother shoot him with an arrow. That’s definitely the next level above a trust fall.

We even get a look at using air cannons to launch arrow storms at the end which is particularly epic. Looking for more movie magic? How about the effects from King Kong or Flight of the Navigator?

Thanks to [Xerxes3rd] on Discord for the tip!

We love seeing the incredible work many RF enthusiasts manage to pull off — they make it look so easy! Though RF can be tricky, it’s not quite the voodoo black art that it’s often made out to be. Many radio protocols are relatively simple and with tools like gnuradio and PocketSDR you can quickly put together a small system to receive and decode just about anything.

[Jean-Michel] wanted to learn more about GNSS and USB communication. Whenever you start a project like this, it’s a good idea to take a look around at existing projects for designs or code you can reuse, and in this case, the main RF front-end board is taken from the PocketSDR project. This is then paired with a Cypress FX2 development board, and he re-wrote almost all of the PocketSDR code so that it would compile using sdcc instead of the proprietary Keil compiler. Testing involved slowly porting the code while learning about using Python 3 to receive data over USB, and using other equipment to simulate antenna diversity (using multiple antennas to increase the signal-to-noise ratio):

The main board uses two MAX2771 GNSS front-ends, which filter and convert the received signals to either a digital output or optionally as I and Q outputs for conversion with discrete ADCs. This data is then read by the 8051 core on the FX2, and the data is sent over USB to maintain a fast and reliable stream. On the PC side, this can be decoded using the original PocketSDR software, or one can build a decoder using gnuradio.

The result is a working GNSS decoder. If you would like to see more detail about the project, [Jean-Michel] put together a YouTube video talking about his work in cloning and porting the code, which you can see below:

The 2024 Hackaday Supercon is on in Pasadena, but if you couldn’t make it to sunny California this year, don’t worry. We’ve got a live streams of the main stage talks, and all of the second track talks are being recorded and will be put up on the YouTube channel after the con.

If you’re watching from home and want to join the conversation, today might be a good time to join the official Hackaday Discord server.

Many MacOS users are probably used by now to the annoyance that comes with unsigned applications, as they require a few extra steps to launch them. This feature is called Gatekeeper and checks for an Apple Developer ID certificate. Starting with MacOS Sequoia 15, the easy bypassing of this feature with e.g. holding Control when clicking the application icon is now no longer an option, with version 15.1 disabling ways to bypass this completely. Not unsurprisingly, this change has caught especially users of open source software like OpenSCAD by surprise, as evidenced by a range of forum posts and GitHub tickets.

The issue of having to sign applications you run on MacOS has been a longstanding point of contention, with HomeBrew applications affected and the looming threat for applications sourced from elsewhere, with OpenSCAD issue ticket #880 from 2014 covering the saga for one OSS project. Now it would seem that to distribute MacOS software you need to have an Apple Developer Program membership, costing $99/year.

So far it appears that this forcing is deliberate on Apple’s side, with the FOSS community still sorting through possible workarounds and the full impact.

Thanks to [Robert Piston] for the tip.

Wired has a fascinating story this week, about the length Sophos has gone to for the last 5 years, to track down a group of malicious but clever security researchers that were continually discovering vulnerabilities and then using those findings to attack real-world targets. Sophos believes this adversary to be overlapping Chinese groups known as APT31, APT41, and Volt Typhoon.

The story is actually refreshing in its honesty, with Sophos freely admitting that their products, and security products from multiple other vendors have been caught in the crosshairs of these attacks. And indeed, we’ve covered stories about these vulnerabilities over the past weeks and months right here on this column. The sneaky truth is that many of these security products actually have pretty severe security problems.

The issues at Sophos started with an infection of an informational computer at a subsidiary office. They believe this was an information gathering exercise, that was a precursor to the widespread campaign. That campaign used multiple 0-days to crack “tens of thousands of firewalls around the world”. Sophos rolled out fixes for those 0-days, and included just a bit of extra logging as an undocumented feature. That logging paid off, as Sophos’ team of researchers soon identified an early signal among the telemetry. This wasn’t merely the first device to be attacked, but was actually a test device used to develop the attack. The game was on.

Sophos managed to deploy it’s own spyware to these test devices, to stealthily keep an eye on this clever opponent. This even thwarted a later attack before it could really start. Among the interesting observations was a bootkit infection on one of these firewalls. This wasn’t ever found in the wild, but the very nature of such an attack makes it hard to discover.

There’s one more interesting wrinkle to this story. In at least one case, Sophos received the 0-day vulnerability used in an attack through their bug bounty program, right after the wave of attacks was launched. The timing, combined with the Chinese IP Address makes it pretty clear this was more than a coincidence. This might be a Chinese hacker making a bit of extra cash on the side. It’s also reminiscent of the Chinese law requiring companies to disclose vulnerabilities to the Chinese government.

PTA 0-Day

GreyNoise runs a honeypot and an AI threat detection system, and found something interesting with that combination. The PTZOptics network security camera was the intended target, and there were a pair of vulnerabilities that this attack was intended to exploit. The first is a simple authorization bypass, where sending HTTP packets without an authorization header to the param.cgi endpoint returns data without any authorization needed. Use the get_system_conf parameter, and the system helpfully prints out valid username and password hashes. How convenient.

Gaining arbitrary command execution is trivial, as the ntp configuration isn’t properly sanitized, and the ntp binary is called insecurely. A simple $(cmd) can be injected for easy execution. Those two were being chained together for a dead simple attack chain, presumably to add the IoT devices to a botnet. The flaws have been fixed, and law enforcement have been on the case, at least seizing the IP address observed in the attacks.

Speaking of camera hacks, we do have an impressive tale from Pwn2Own 2024, where researchers at Synacktiv used a format string vulnerability to pwn the Synology TC500 camera. The firmware in question had a whole alphabet of security features, like ASLR, PIE, NX, and Full RelRO. That’s Address Space Layout Randomization, Position Independent Executables, Non-Executable memory, and Full Relocation Read-Only protections. Oh, and the payload was limited to 128 characters, with the first 32 ASCII characters unavailable for use.

How exactly does one write an exploit in this case? A bit of a lucky break with the existing memory layout gave access to what the write-up calls a “looping pointer”. That seems to be a pointer that points to itself, which is quite useful to work from offsets instead of precise memory locations. The vulnerability allowed for writing a shell command into unused memory. Then finally a bit of Return Oriented Programming, a ROP gadget, manages to launch a system call on the saved command line. Impressive.

Maybe It Wasn’t a Great Idea

…to give LLMs code execution capabilities. That’s the conclusion we came to after reading CyberArk’s post on how to achieve Remote Code Execution on a Large Language Model. The trick here is that this particular example, LoLLMs, can run python code on the backend to perform certain tasks, like do math calculations. This implementation uses Python sandboxing, and naturally there’s a known way to defeat it. The trick can be pulled off just by getting the model to evaluate the right JSON snippet, but it’s smart enough to realize that something is off and refuse to evaluate the JSON.

The interesting detail here is that it is the LLM itself that is refusing, so it’s the LLM that needs bypassed. There has been very interesting work done on LLM jailbreaks, like DAN, the Do Anything Now prompt. That would probably have worked, but this exploit can be even sneakier than that. Simply ask the LLM to help you write some JSON. Specify the payload, and ask it to add something to it. It gladly complies, and code is executed. Who knew that LLMs were so gullible?

More Quantum Erratta

This story just keeps on giving. This time it’s [Dan Goodin] at Ars Technica that has the lowdown, filling in the last few missing details about the much over-hyped quantum computing breakthrough. One of the first of those details is that the story of the compromise of AES was published in the South China Morning Post, which has over-hyped Chinese quantum progress before. What [Goodin]’s article really adds to the discussion is opinions from experts. The important takeaway is that the performance of the D-Wave quantum computer is comparable to classical approaches.

Bits and Bytes

Remember the traffic light hacking? And part two? We now have the third installment, which is really all about you, too, can purchase and hack on one of these traffic controllers. It may or may not surprise you that the answer is to buy them on Ebay and cobble together a makeshift power supply.

It’s amazing how often printers, point of sale, and other IoT gadgets are just running stripped-down, ancient versions of Android. This point of sale system is no exception, running an old, custom Android 6 system, that seems to actually be rather well locked down. Except that it has an NFC reader, and you can program NFC tags to launch Android apps. Use this creative workaround to get into Android settings, and you’re in business.

I have long maintained that printers are terrible. That sentiment apparently is extending into security research on printers, with Lexmark moving to a new encrypted filesystem for printer firmware. Thankfully, like most of these schemes, it’s not foolproof, and [Peter] has the scoop on getting in. May you never need it. Because seriously, printers are the worst.

If you’re hear a rushing noise, don’t be alarmed — that’s just the rapidly approaching 2024 Hackaday Supercon. As hard as it is to believe, a whole year has gone by, and we’re now just a few days away from kicking off our annual hardware hacking extravaganza in Pasadena. Tickets just sold out over the weekend — thank you procrastinators!

For those of you who have tickets to join us this weekend, we’ve got a few last minute announcements and bits of information we wanted to get out to you. As a reminder, you can find the full schedule for all three days on the official Supercon site.

New Events Added!

For those who’ve attended a Supercon before, you know we like to cram as much content as we can into the weekend. But there’s always room for more, and this year we’ve managed to squeeze in a couple extra activities that we’re very excited about.

Halloween Hacker Happy Hour

It just so happens that Halloween is the night before Supercon officially kicks off, and that seemed like too good of an opportunity to pass up. So we’ll be throwing a pre-event party at the nearby KingsRow Gastropub where costumes and all manner of blinking LEDs are very much encouraged. Officially we’ll be hanging out from 7:00 to 10:00 PM, but don’t be surprised if you find yourself still talking to Hackaday folks at last call.

You don’t need tickets for this event, but we’d like to have a rough head count, so if you could RSVP through Eventbrite we’d appreciate it.

Tina’s Junk Challenge

We’ve always wanted to introduce some kind of swap meet aspect to Supercon, but the logistics have always been a challenge. This year though, we’re finally going to get the chance to test out the idea. Former DesignLab Resident Tina Belmont is in the process of moving out of the country and needs to find a new home for her electronic bric-a-brac.

Everything is free, so attendees are encouraged to take anything they think they can make use of. Naturally, an influx of interesting hardware could provide for some very unique badge hacking possibilities. If we can get enough people to graft these second-hand components onto their badges, we just might be able to turn it into a proper category come Sunday night.

A table where folks can offload their electronic bits and bobs has worked well at other hacker cons, so we’re eager to see how it goes at Supercon. If this is something you’d like to see more of, or would potentially like to participate in next year, let us know.

Krux’s Side Quests

Let’s be honest, most of us are already taking our marching orders from the computer in one way or another. So why not turn it into a fun interactive game?

The idea is simple: use the mysterious retrocomputer oracle, and it gives you a quest. Maybe you’ll have to find a hidden item, or solve a riddle. Krux has a run a variation of this game at Toor Con in the past, but the challenges spit out by the computer this time will be tailored to Supercon.

Windows Through Wires Exhibition

You may recall that we asked the Hackaday community if they had any unusual display technology they’d like to show off during Supercon as part of an exhibit.

Well, as you might have imagined, the response was incredible. From gorgeous vintage pieces to completely custom hardware, there’s going to be a wide array of fascinating hardware for attendees to study up-close.

While getting a chance to see various display technologies throughout the years would have our attention as it is, what’s really exciting is that many of the custom-built devices in the exhibit are either projects hosted on Hackaday.io or ones that we’ve covered at some point on the front page.

Considering how gorgeous some of them have looked in photographs, we’re eager to drool over them in the real world — and we bet you are to.

Workshop Technical Difficulties

Hopefully we’ve provided enough good news that we can slip in a bit of the bad. Unfortunately, we’ve had to cancel the “Hands on with an Electron Microscope” workshop that was to be hosted by Adam McCombs and Isabel Burgos. Everyone with tickets will of course be getting a refund, and you should be receiving an email to that effect shortly if you haven’t already.

While we’re just as disappointed by this news as you are, it’s one of those situations where there simply weren’t any good solutions. Long story short, the scanning electron microscope that was small enough to bring to Supercon is down, and there’s just not enough time to get it up and running at this point. An attempt was made to find another small-ish electron microscope on short notice but…well, that’s just as tricky to pull off as it sounds.

Send Us Your Lightning Talks!

To end this update on a high note, we want to remind everyone that this year we’ll once again be going Lighting Talks on Sunday morning. If you’ve never given a talk before, the shorter seven minute format is perfect for getting your feet wet. Or maybe you’ve got something you want to talk about that doesn’t take a whole hour to explain. Either way, the Lightning Talks are a great way to share what your passionate about with the Supercon audience.

If you’d like to give a Lightning Talk, simply fill out this form. You can upload slides if you’ve got them, but they aren’t strictly necessary.

With the latest release of Raspberry Pi OS (formerly Raspbian) the end of the X Window System has become reality, completing a years-long transition period. Although this change between display servers is not something which should be readily apparent to the casual user, the change from the client-server-based X11 protocol to the monolithic Wayland protocol has a number of implications. A major change is that with the display server and window manager no longer being separate units, features such as network transparency (e.g. remote X-sessions) are no longer a native feature, but have to be implemented separately by e.g. the Wayland compositor.

For Raspberry Pi the transition to Wayland was based on the perceived efficiency and security benefits of the monolithic architecture, with the 2021 release of Raspbian (based on Debian Bullseye) testing the waters using the hybrid X11 window manager/Wayland compositor Mutter. This allowed for switching between X11 and Wayland without committing. In 2023 Mutter was replaced with the Wayfire compositor with Wayland becoming the default on Raspberry Pi 4 and 5 platforms. Along the way it was found that the Wayfire project wasn’t developing in a way that would benefit Raspberry Pi OS, which led to what should now be the final Wayland compositor in the form of Labwc.

One advantage of Labwc is that it is more lightweight than Wayfire and Raspberry Pi has judged that this means that it should be the default across all Raspberry Pi systems. Compatibility with X11-based software is maintained with the XWayland library, so that users should ideally not notice any difference after switching to Labwc even on lower-end boards. Unless you’re one one of those people who use features such as (remote) X-sessions, nothing should feel markedly different.

In addition to this big change, the new Raspberry Pi OS release also improves touch screen support with the integrated Squeekboard virtual keyboard popping up when a touch screen is detected. Finally, the remote access Raspberry Pi Connect feature sees a few tweaks, which is the feature that effectively replaces remote X-sessions. Considering how glacially slow X desktop sessions can be, this is something which can be considered an improvement, but it would be nice if there was an alternative that didn’t rely on Raspberry Pi-provided services to work.