Hackaday Editors Elliot Williams and Tom Nardi discuss all the week’s best and most interesting hacks and stories, starting with Canada’s misguided ban on the Flipper Zero for being too spooky. From there they’ll look at the state-of-the-art in the sub-$100 3D printer category, Apple’s latest “Right to Repair” loophole, running UNIX on the NES (and how it’s different from Japan’s Famicom), and the latency of various wireless protocols.
After singing the praises of the new Bus Pirate 5, discussion moves on to embedded Linux on spacecraft, artfully lifting IC pins, and the saga of the blue LED. Finally you’ll hear the how and why behind electrical steel, and marvel at a Mach 10 missile that (luckily) never needed to be used.
Reading through a vulnerability report about ClamAV, I came across a phrase that filled me with dread: “The file name is not sanitized”. It’s a feature, VirusEvent, that can be enabled in the ClamnAV config. And that configuration includes a string formatting function, where the string includes %v and %s, which gets replaced with a detected virus name and the file name from the email. And now you see the problem, I hope: The filename is attacker supplied input.
Where this really gets out of hand is what ClamAV does with this string. execle("/bin/sh", "sh", "-c", buffer_cmd, NULL, env). So let’s talk defensive program design for a minute. When it comes to running a secondary command, there are two general options, system() and the exec*() family of system calls. system() is very simple to use. It pauses execution of the main process and asks the operating system to run a string, just as if the user had typed that command into the shell. While this is very convenient to use, there is a security problem if any of that command string is user-supplied. All it takes is a semicolon or ampersand to break assumptions and inject a command.
To the rescue comes exec(). It’s a bit more complicated to use, requiring the programmer to manually call fork() and wait(). But it’s not running the command via the shell. exec() executes a program directly, totally eliminating the potential for command injection! Except… oops.
Yeah, exec() and related calls don’t offer any security protections when you use them to execute /bin/sh. I suspect the code was written this way to allow running a script without specifying /bin/sh in the config. The official fix was to disable the filename format character, and instead supply it as an environment variable. That certainly works, and that fix is available in 1.0.5, 1.2.2, and 1.3.0.
Sometimes, it pays to read the man pages of commands you use often. There might be a gem hidden in there that you don’t know about. Case in point: I’ve used curl (technically, cURL, but I’m going to stick with curl) many times to grab data from some website or otherwise make a web request. But what happens if you want to do the same thing from a C program? Well, you could be lazy and just spawn a copy of curl. But it turns out curl has a trick up its sleeve that can help you. If only I’d read the man page sooner!
First Things
The simplest use of curl is to just name a URL on the command line. For example, consider this session:
$ curl http://www.hackaday.com
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
This isn’t so useful because it is a 301 response (to send you to the https server, in this case). The -L option will make curl go get the page instead of the redirect. Try:
If you’ve been involved with electronics and hardware hacking for awhile, there’s an excellent chance you’ve heard of the Bus Pirate. First introduced on the pages of Hackaday back in 2008 by creator Ian Lesnet, the open hardware multi-tool was designed not only as away to easily tap into a wide array of communication protocols, but to provide various functions that would be useful during hardware development or reverse engineering. The Bus Pirate could talk to your I2C and SPI devices, while also being able to measure frequencies, check voltages, program chips, and even function as a logic analyzer or oscilloscope.
Bus Pirate 3, circa 2012
The Bus Pirate provided an incredible number of tools at a hobbyist-friendly price, and it wasn’t long before the device became so popular that it achieved a milestone which only a few hardware hacking gadgets can boast: its sales started to get undercut by cheap overseas clones. Of course, as an open hardware device, this wasn’t really a problem. If other companies wanted to crank out cheap Bus Pirates, that’s fine. It freed Ian up to research a next-generation version of the device.
But it turns out that was easier said than done. It’s around this point that the Bus Pirate enters what might be considered its Duke Nukem Forever phase. It took 15 years to release the sequel to 1996’s Duke Nukem 3D because the state-of-the-art in video games kept changing, and the developers didn’t want to be behind the curve. Similarly, Ian and his team spent years developing and redeveloping versions of the Bus Pirate that utilized different hardware platforms, such as the STM32 and ICE40 FPGA. But each time, there would be problems sourcing components, or something newer and more interesting would be released.
But then in 2021 the Raspberry Pi Pico hit the scene, and soon after, the bare RP2040 chip. Not only were the vast I/O capabilities of the new microcontroller a perfect fit for the Bus Pirate, but the chip was cheap and widely available. Finally, after years of false starts, the Bus Pirate 5 was born.
I was able to grab one of the first all-new Bus Pirates off the production line in January, and have been spending the last week or so playing around with it. While there’s definitely room for improvement on the software side of things, the hardware is extremely promising, and I’m very excited to be see how this new chapter in the Bus Pirate story plays out.
Canada’s intent to ban the Flipper Zero wireless tool over car thefts is, on the one hand, an everyday example of poorly researched government action. But it may also be a not-so-subtle peek into the harm misinformation online can cause by leading to said government action.
And yet, defeating a rolling code keyless entry system is a trick a device like the Flipper Zero simply cannot pull off. (What cars have such a system? Any car made in roughly the last thirty years, for a start.)
Although factors like bandwidth, power usage, and the number of (kilo)meters reach are important considerations with wireless communication for microcontrollers, latency should be another important factor to pay attention to. This is especially true for projects like controllers where round-trip latency and instant response to an input are essential, but where do you find the latency number in datasheets? This is where [Michael Orenstein] and [Scott] over at Electric UI found a lack of data, especially when taking software stacks into account. In other words, it was time to do some serious benchmarking.
The question to be answered here was specifically how fast a one-way wireless user interaction can be across three levels of payload sizes (12, 128, and 1024 bytes). The effective latency is measured from when the input is provided on the transmitter, and the receiver has processed it and triggered the relevant output pin. The internal latency was also measured by having a range of framework implementations respond to an external interrupt and drive a GPIO pin high. Even this test on an STM32F429 MCU already showed that, for example, the STM32 low-level (LL) framework is much faster than the stm32duino one.
Younger electronic engineers may see resistors with old-style color codes to display their values a little less than those from previous years, but if there’s a shibboleth among those who wield a soldering iron it’s probably something similar to instinctively saying “1K” when asked “Brown-black-red?”. Colors as numbers can be used outside resistors, for example in a clock, as [Det Builds Stuff] shows us with an ESP32 TFT dev board.
It’s fair to say that this is more of a software project than a hardware one, but that’s not necessarily a bad thing as he takes us though the process of creating a Network Time Protocol (NTP) capable clock with the dev board. He claims it may be the world’s first resistor clock, something we’d have to disagree with, but beside that we can see this could make a neat little desk ornament with a 3D printed case.
Oddly though, we’d expect older engineers to face the same steep learning curve as younger ones when reading it, because it’s easier to recognize visual sequences of numbers as preferred resistor values than it is to visually decode each one every time.
