Robotic animal companions were once all the rage, though their limited personalities and annoying sound effects often relegated them to the bin fairly quickly. This makes them all the more ripe for hacking. [David Bynoe] had a Baby Butterscotch that was in need of a new home, and he decided to put the pony to work at his local hackerspace.
The Baby Butterscotch pony is a charming beast in stock form, yet highly menacing once its skin is removed. Mounted to a plaque, the pony has three PIR sensors that detect movement. These sensors are used to allow the pony to act as a door greeter, waking up when people enter the hackerspace and following them around the room. The additional hardware interfaces with the pony’s stock electronics by using floating capacitors and relays to activate the original capacitive touch sensors. The final piece is finished with a coat of gold paint and some RGB eyes to complete the look.
A few years ago, [Wayne] managed to blow out the main board of his Flashforge Finder attempting to change the fan. But the death of one tool ended up being the birth of another, as he ended up using its mechanical components and a Raspberry Pi to create an impressive scanning microscope.
Scan of Ulysses S. Grant from a US $50 bill
As you might have guessed from the name, the idea here is to scan across the object with a digital microscope to create an enlarged image of the entire thing. This requires some very precise control over the microscope, which just so happens to be exactly what 3D printers are good at. All [Wayne] had to do was remove the hotend, and print some adapter pieces which let him mount a USB microscope in its place.
The rest is in the software. The Raspberry Pi directs the stepper motors to move the camera across the object to be scanned in the X and Y dimensions, collecting thousands of individual images along the way. Since the focus of the microscope is fixed and there might be height variations in the object, the Z stage is then lifted up a few microns and the scan is done again. Once the software has collected tens of thousands of images in this manner, it sorts through them to find the ones that are in focus and stitch them all together.
The process is slow, and [Wayne] admits its not the most efficient approach to the problem. But judging by the sample images on the Hackaday.io page, we’d say it gets the job done. In fact, looking at these high resolution scans of 3D objects has us wondering if we might need a similar gadget here at the Hackaday Command Bunker.
There’s nothing quite like a deadline to cut through extras and get right at the heart of the problem. Maybe we should all follow Interpreet’s example and stop thinking about automating our homes and just make it in an eight-day hackathon. His talk at the 2019 Hackaday Superconference covers the zero-to-deployment home automation build he finished in the eight days leading up to his move from one continent to another.
Hackaday’s very own Inderpreet Singh found himself pulling up roots and moving from his home in India to teach at Centennial College in Toronto, Canada. He needed a way to keep an eye on his home from afar and the name of the game is IoT. When the only choice is “whatever works right now”, you can learn a lot about simple solutions.
He chose familiar hardware to work with, with the ESP8266 making up the bulk of the nodes and a Raspberry Pi as as a central hub for the setup. He chose to communicate between all the nodes on his system using WiFi because the hardware is robust and available. With security in mind, he keeps the automation system separate from the daily use WiFi system by grabbing an extra access point to serve as the automation network. The Raspberry Pi serves as a router of sorts; its Ethernet port is connected to the IoT device’s AP, while the onboard WiFi is used to connect to the home’s main AP for a connection to the wider Internet.
Software for the system is built on a REST API served by a Python Flask app. Many would advocate for using MQTT but Inderpreet’s testing with that protocol came up short as the broker he intended to use was no longer available. One of the interesting parts of his system design is that all nodes will check in at regular intervals; this allows them to inquire about actions they need to take, but it also allows the system to detect a malfunctioning node immediately. I’ve seen a similar trick used by Elliot Williams where he assigns a “ping” topic to all MQTT devices that causes them to report in with their IP address. Having a system to query and ensure the health of every node is a big tip to take away from this talk.
Our new part of the day is the ColorLight 5A-75B, a board that’s meant to drive eight of those ubiquitous high-density color LED panels over gigabit Ethernet. If you were building a commercial LED wall, you’d screw a bunch of the LED panels together, daisy-chain a bunch of these boards to drive them, supply power, and you’d be done. Because of that high-volume application, these boards are inexpensive, around $15 each, and available as quickly as you can get stuff shipped from China.
But we’re not here to talk commercial applications. Managing fast Ethernet and pushing so many pixels in real time is a task best handled by an FPGA, and [Tom Verbeure] noticed that these things were essentially amazing FPGA development boards and started hacking on them. [q3k] put it up on GitHub, and you can follow along with the chubby75 reverse engineering project to dig into their secrets.
While the first generations of these boards used the old-standby Spartan 6, things got interesting for fans of open FPGA tools when newer versions were found using the Lattice ECP5-25 chips, the little brother of the stonking big chip [Sprite_TM] used on the 2019 Hackaday Supercon badge. If you want to grab one you’re looking for ColorLight boards marked with revision 6 or 7 as of this writing.
What does this mean? For the price of a gourmet hamburger, you get an FPGA that’s big enough to run a RISC-V softcore, two 166 MHz, 2 MB SDRAMS, flash for the FPGA bitstream, a bazillion digital outputs on 5 V level shifters, and two gigabit Ethernet ports. The JTAG port is broken out in 0.1″ headers, and it works with OpenOCD, which is ridiculously convenient. How’s that for a well-stocked budget FPGA dev board that’s served by a completely open toolchain? Continue reading “New Part Day: LED Driver Is FPGA Dev Board In Disguise”→
Hackaday editors Mike Szczys and Elliot Williams sort through the hacks you might have missed over the past seven days. In FPGA hacking news, there’s a ton of work being done on a newly discovered FPGA dev board. Kristina has a new column on input devices, kicking it off with tongue-actuated controllers. We wax philosophical about what data you need to backup and what you should let go. Plus Audacity is helping tune up CNC machines, copper tape is the prototyper’s friend, and fans of Open should take note of this laptop project.
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!
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!
On the 3rd of June 2019, a 1U CubeSat developed by students of the AGH University of Science and Technology in Kraków was released from the International Space Station. Within a few hours it was clear something was wrong, and by July 30th, the satellite was barely functional. A number of problems contributed to the gradual degradation of the KRAKsat spacecraft, which the team has thoroughly documented in a recently released paper.
We all know, at least in a general sense, that building and operating a spacecraft is an exceptionally difficult task on a technical level. But reading through the 20-pages of “KRAKsat Lessons Learned” gives you practical examples of just how many things can go wrong.
KRAKsat being released from the ISS
It all started with a steadily decreasing battery voltage. The voltage was dropping slowly enough that the team knew the solar panels were doing something, but unfortunately the KRAKsat didn’t have a way of reporting their output. This made it difficult to diagnose the energy deficit, but the team believes the issue may have been that the tumbling of the spacecraft meant the panels weren’t exposed to the amount of direct sunlight they had anticipated.
This slow energy drain continued until the voltage dropped to the point that the power supply shut down, and that’s were things really started going south. Once the satellite shut down the batteries were able to start charging back up, which normally would have been a good thing. But unfortunately the KRAKsat had no mechanism to remain powered down once the voltage climbed back above the shutoff threshold. This caused the satellite to enter into and loop where it would reboot itself as many as 150 times per orbit (approximately 90 minutes).
The paper then goes into a laundry list of other problems that contributed to KRAKsat’s failure. For example, the satellite had redundant radios onboard, but the software on them wasn’t identical. When they needed to switch over to the secondary radio, they found that a glitch in its software meant it was unable to access some portions of the onboard flash storage. The team also identified the lack of a filesystem on the flash storage as another stumbling block; having to pull things out using a pointer and the specific memory address was a cumbersome and time consuming task made all the more difficult by the spacecraft’s deteriorating condition.
Of course, building a satellite that was able to operate for a couple weeks is still an impressive achievement for a student team. As we’ve seen recently, even the pros can run into some serious technical issues once the spacecraft leaves the lab and is operating on its own.
A critical security bug was fixed in Chrome recently, CVE-2020-6378. The CVE report is still marked private, as well as the bug report. All we have is “Use-after-free in speech recognizer”. Are we out of luck, trying to learn more about this vulnerability? If you look closely at the private bug report, you’ll notice it’s in the Chromium bug tracker. Chrome is based primarily on the Chromium project, with a few proprietary features added. Since Chromium is open source, we can go find the code change that fixed this bug, and possibly learn more about it.
Off to the Chromium source, mirrored on Github. We could look at every commit, and eventually find the one we’re looking for, but Chromium commit messages usually include a reference to the bug that is fixed by that commit. So, we can use Github’s search function to find a commit that mentions 1018677. Just like that, we’ve found a single commit and more information.
The shutdown mentioned in the commit message is possibly referring to the browser being closed, but could also refer to the tab doing the speech recognizing, or even the speech system itself. Because multiple parts are being unloaded in parallel, there is a race condition between calling the abort object, and that object being unloaded from memory. This race can result in a classic use-after-free, jumping code execution to a memory location that’s already been freed.
All interesting, but how does this warrant a Critical rating? Enter the Web Speech API. I’m speculating just a bit, but it’s likely that this API uses the speech recognizer code in question. It may even be interacting with the security prompt that triggers the crash. Imagine that an attacking page attempts to use the speech API, and then releases the API object before the user can respond to the prompt. That *might* be the scenario that was discovered, though we’re deep into speculation, now. Continue reading “This Week In Security: Chrome Speech Bug, UDP Fragmentation, And The Big Citrix Vulnerability”→
