In the middle of the 20th century, the atom was all the rage. Radiation was the shiny new solution to everything while being similarly poorly understood by the general public and a great deal of those working with it.
Against this backdrop, Firestone Tire and Rubber Company decided to sprinkle some radioactive magic into spark plugs. There was some science behind the silliness, but it turns out there are a number of good reasons we’re not using nuke plugs under the hood of cars to this day.
This build goes a bit of a different route to many other DIY keyboards out there, in that [Lambert] was keen to build it around an FPGA instead of an off-the-shelf microcontroller. To that end, the entire USB HID stack was implemented in VHDL on a Lattice ECP5 chip. It was a heavy-duty way to go, but it makes the keyboard quite unique compared to those that just rely on existing HID libraries to do the job. This onboard hardware also allowed [Lambert] to include JTAG, SPI, I2C, and UART interfaces right on the keyboard, as well as a USB hub for good measure.
As for the mechanical design, it’s a full-size 105-key ISO keyboard with one bonus key for good measure. That’s the coffee key, which either locks the attached computer when you’re going for a break, or resets the FPGA with a long press just in case it’s necessary. It’s built with Cherry MX compatible switches, has N-key rollover capability, and a mighty 1000 Hz polling rate. If you can exceed that by hand, you’re some sort of superhuman.
There’s an old saying (paraphrasing a quote attributed to Hoare): “I don’t know what language scientists will use in the future, but I know it will be called Fortran.” The truth is, there is a ton of very sophisticated code in Fortran, and if you want to do something more modern, it is often easier to borrow it than to reinvent the wheel. When [Valgriz] picked up a textbook on aircraft simulation, he noted that it had an F-16 simulation in it. In Fortran. The challenge? Port it to Unity3D.
If you have a gamepad, you can try the result. However, the real payoff is the blog posts describing what he did. They go back to 2021, although the most recent was a few months ago, and they cover the entire process in great detail. You can also find the code on GitHub. If you are interested in flight simulation, flying, Fortran, or Unity3D, you’ll want to settle in and read all four posts. That will take some time.
[Zoltan] was developing a workshop on Matter for DEF CON, and wanted to whip up a fun IoT project to go with it. His idea was simple—take a simple toy train, and put it on the Internet of Things.
Speed and low cost were the goals here, with a budget of around $40 and a timeline of one week. The train set sourced for the build was a 43 piece set with a locomotive, one carriage, and a simple oval track, retailing for $25. The toy train got a new brain in the form of an ESP32-C3 DevKitM-1, with the goal of commanding the device over Wi-Fi for ease of use. The microcontroller was set up to control the train’s brushed DC motor with an IRL540 MOSFET. A USB battery bank was initially employed to power the rig, which sat neatly on the train’s solitary carriage. This was later swapped out for a CR123A battery, which did the job for the train’s short duration in service.
Code for the project was simple enough. The ESP32 simply listens for commands via Matter protocol, and turns the train on and off as instructed. [Zoltan] demos the simple interoperability of the Matter protocol by switching the train on and off with Google Home voice commands, and it works perfectly well.
Toy trains aren’t something we typically see included in smart homes, but maybe they should be. If you’re cooking up your own oddball IoT hacks, be sure to let us know on the tipsline!
Unitree have a number of robotic offerings, and are one of the first manufacturers offering humanoid robotic platforms. It seems they are also the subject of UniPwn, one of the first public exploits of a vulnerability across an entire robotic product line. In this case, the vulnerability allows an attacker not only to utterly compromise a device from within the affected product lines, but infected robots can also infect others within wireless range. This is done via a remote command-injection exploit that involves a robot’s Bluetooth Low Energy (BLE) Wi-Fi configuration service.
Unitree’s flagship G1 humanoid robot platform (one of the many models affected)
While this may be the first public humanoid robot exploit we have seen (it also affects their quadruped models), the lead-up to announcing the details in a post on X is a familiar one. Researchers discover a security vulnerability and attempt responsible disclosure by privately notifying the affected party. Ideally the manufacturer responds, communicates, and fixes the vulnerability so devices are no longer vulnerable by the time details come out. That’s not always how things go. If efforts at responsible disclosure fail and action isn’t taken, a public release can help inform people of a serious issue, and point out workarounds and mitigations to a vulnerability that the manufacturer isn’t addressing.
The biggest security issues involved in this vulnerability (summed up in a total of four CVEs) include:
Hardcoded cryptographic keys for encrypting and decrypting BLE control packets (allowing anyone with a key to send valid packets.)
Trivial handshake security (consists simply of checking for the string “unitree” as the secret.)
Unsanitized user data that gets concatenated into shell commands and passed to system().
The complete attack sequence is a chain of events that leverages the above in order to ultimately send commands which run with root privileges.
We’ve seen a Unitree security glitch before, but it was used to provide an unofficial SDK that opened up expensive features of the Go1 “robot dog” model for free. This one is rather more serious and reportedly affects not just the humanoid models, but also newer quadrupeds such as the Go2 and B2. The whole exploit is comprehensively documented, so get a fresh cup of whatever you’re drinking before sitting down to read through it.
In the late 2010s, the Ender 3 printers were arguably the most popular line of 3D printers worldwide, and for good reason. They combined simplicity and reliability in a package that was much less expensive than competitors, giving a much wider range of people access to their first printers. Of course there are much better printers on the market today, leaving many of these printers sitting unused. [Irbis3D] had an idea that with so many of these obsolete, inexpensive printers on the secondhand market, he could build something better with their parts.
The printer he eventually pieces together takes parts from two donor Ender printers and creates a printer with a CoreXY design instead of the bedslinger (Cartesian) design of the originals. CoreXY has an advantage over other printer topologies in that the print head moves in X and Y directions, allowing for much faster print times at the expense of increased complexity. There are some challenges to the design that [Irbis3D] had to contend with, such as heating problems with the extruder head that needed some modifications, as well as a resonance problem common with many printer designs which can generally be solved by replacing parts one-by-one until satisfactory prints are achieved.
Of course, not all of the parts for the new printer come from the old Ender printers. The longer belts driving the print head needed to be ordered, as well as a few other miscellaneous bits. But almost everything else is taken from these printers, which can be found fairly cheaply on the secondhand market nowadays. In theory it’s possible to build this version for much less cost than an equivalent printer as a result. If you’re looking for something even more complicated to build, we’d recommend this delta printer with a built-in tool changer.
Have you ever wanted to find a Bluetooth device out in the wild while looking like the comic relief character from a science-fiction series? You might like Dendrite, the direction-finding hat from [SolidStat3].
Dendrite is intended for hunting down Bluetooth devices. It’s capable of direction estimation based on signal strength readings from four ESP32 microcontrollers mounted on an off-the-shelf hard hat. Each ESP32 searches for BLE devices in the immediate area and reports the apparent signal strength to a fifth ESP32, which collates readings from all units. It then runs a simple multilateration algorithm to estimate the direction of the device. This information is then displayed via a ring of addressable LEDs around the perimeter of the hat. White LEDs marking the direction of the detected device. The only problem? You can’t see the LEDs while you’re wearing the hat. You might need a friend to help you… or you can simply take it off to see what it’s doing.
