Hackaday Editors Elliot Williams and Mike Szczys talk turkey on the latest hacks. Random numbers, art, and electronic geekery combine into an entropic masterpiece. We saw Bart Dring bring new life to a cool little multi-pen plotter from the Atari age. Researchers at UCSD built a very very very slow soft robot, and a broken retrocomputer got a good dose of the space age. A 555 is sensing earthquakes, there’s an electric motor that wants to drop into any vehicle, and did you know someone used to have to read the current time into the telephone ad nauseam?
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
Direct download (59 MB)
Places to follow Hackaday podcasts:
Continue reading “Hackaday Podcast 042: Capacitive Earthquakes, GRBL On ESP32, Solenoid Engines, And The TI-99 Space Program”
We’ll be honest. When we first heard about a mouse, we weren’t convinced. The argument was that business people weren’t familiar with computers. That didn’t ring true since every business person in the last century had at least seen a typewriter keyboard, but most of them had never seen a mouse before the 1980s. The mouse has since become totally ubiquitous, so presumably, it was the right choice. However, if you are a serious touch typer, it is annoying to have to move your hands off the keyboard to a different location each time. There are several solutions for that, but the oldest one is probably the trackball. Ploopy is an open source trackball you can build yourself and it looks pretty capable.
While we aren’t wild about the name, Ploopy looks pretty good and is one of those projects that would have been very difficult ten years ago. It requires two PC boards. Those used to be hard to get. It also requires some very customized plastic parts. Getting a handful of plastic parts made used to be hard, too. But now you probably have a 3D printer that is just begging for something to do.
Continue reading “Ploopy Open Source Trackball Keeps Rolling Along”
The always interesting Project Zero has a pair of stories revolving around security research itself. The first, from this week, is all about one man’s quest to build a debug iPhone for research. [Brandon Azad] wanted iOS debugging features like single-stepping, turning off certain mitigations, and using the LLDB debugger. While Apple makes debug iPhones, those are rare devices and apparently difficult to get access to.
[Brandon] started looking at the iBoot bootloader, but quickly turned his attention to the debugging facilities baked into the Arm chipset. Between the available XNU source and public Arm documentation, he managed to find and access the CoreSight debug registers, giving him single-step control over a core at a time. By triggering a core halt and then interrupting that core during reset, he was able to disable the code execution protections, giving him essentially everything he was looking for. Accessing this debug interface still requires a kernel level vulnerability, so don’t worry about this research being used maliciously.
The second Google Zero story that caught my eye was published earlier in the month, and is all about finding useful information in unexpected places. Namely, finding debugging symbols in old versions of Adobe Reader. Trying to understand what’s happening under the hood of a running application is challenging when all you have is a decompiler output. Adobe doesn’t ship debug builds of Reader, and has never shipped debug information on Windows. Reader has been around for a long time, and has supported quite a few architectures over the years, and surprisingly quite a few debug builds have been shipped as a result.
How useful could ancient debugging data be? Keep in mind that Adobe changes as little as possible between releases. Some code paradigms, like enums, tend to be rather static as well. Additional elements might be added to the end of the enum, but the existing values are unlikely to change. [Mateusz Jurczyk], the article’s author, then walks us through an example of how to take that data and apply it to figuring out what’s going on with a crash. Continue reading “This Week In Security: Project Zero’s IPhone, BBC The Onion, Rooting Androids, And More”
It’s safe to say that most of us have at least one Raspberry Pi hanging from a USB cable someplace, silently hammering away at some unglamorous task that you’d rather not do on a “real” computer. With as cheap as they are, it’s not like there’s a big concern about where it sets up shop. But if you’re like [Jeremy S. Cook] and want your $35 Linux computer to be a permanent member of the family, then his tips on turning an old PC into a gloriously overkill Pi NAS may be of interest.
The main component [Jeremy] salvages from the old Lenovo desktop PC is, obviously, the case itself. Stripped of its original components, the case gives him plenty of room to mount the Pi as well as a couple of hard drives and a powered USB hub. To prevent the bottom of the Raspberry Pi from shorting out against the metal computer case, he designed and 3D printed a mount for it. Everything else is held down with hook and loop fastener, making it quick and easy to move things around and make adjustments.
While it might not be strictly necessary, [Jeremy] also took the time to salvage the computer’s old heatsink. Being far too large to fit on the Pi as-is, he ran a line down the back of it with his mill and snapped it in half. He uses a bit of thermal tape to hold the bisected heatsink onto the Pi’s SoC, with a couple pieces of electrical tape to make sure it doesn’t short out on anything.
Raspberry Pi NAS builds are exceptionally popular, and we’ve seen more than we can count over the years. You can build one out of parts from IKEA, and if you don’t mind plastic, you can always 3D print the whole thing. If you really want to go minimal, you can even hang some files on the network with little more than a Pi Zero stuck into a USB port.
Continue reading “Raspberry Pi NAS Makes Itself At Home In Donor PC”
Anyone who’s ever had the pleasure of programming FPGAs knows that it’s a land of proprietary tools that almost require marriage level commitment to a specific platform to be effective. Symbiflow hopes to solve this by becoming the GCC of FPGAs.
Rather than a tool built around a specific chip or architecture, Symbiflow will provide a more universal interface. Users can program in Verilog; architecture definitions define how the code will be compiled for the right chip. They are currently targeting the popular Xilinx 7-series, the very affordable iCE40 series from lattice, and the ECP5 FPGAs also from Lattice.
If you’re headed to Hackaday Supercon this year, [Timothy Ansell] will be giving a talk on how Symbiflow is making this process much more approachable and much less proprietary. Overall we’re very excited about a common interface, especially as the price of FPGAs keep dropping into micro controller territory while also increasing in capability.
(Speaking of Supercon, and maybe this is a spoiler, the badge would not have been possible without Symbiflow, Project Trellis, Yosys, and NextPNR.)