This excellent content from the Hackaday writing crew highlights recurring topics and popular series like Linux-Fu, 3D-Printering, Hackaday Links, This Week in Security, Inputs of Interest, Profiles in Science, Retrotechtacular, Ask Hackaday, Teardowns, Reviews, and many more.
If you want a quick view of a Linux system’s process load, you can use top or — slightly nicer — htop. But what if you want a quick snapshot of how the disk system is doing? There are a few tools you can use, some of which are not nearly as common as top.
Most similar to top is iotop. This program shows you the total and current disk read and write numbers for the file system and also shows you who is eating up the most disk I/O. This screen looks busy:
It seems like just yesterday (maybe for some of you it was) we were installing Windows 3.1 off floppy drives onto a 256 MB hard drive, but hard drives have since gotten a lot bigger and a lot more complicated, and there are a lot more options than spinning platters.
The explosion of storage options is the result of addressing a variety of niches of use. The typical torrenter downloads a file, which is written once but read many times. For some people a drive is used as a backup that’s stored elsewhere and left unpowered. For others it is a server frequently reading and writing data like logs or swap files. In all cases it’s physics that sets the limits of what storage media can do; if you choose wisely for your use case you’ll get the bet performance.
The jargon in this realm is daunting: superparamagnetic limit, LMR, PMR, CMR, SMR, HAMR, MAMR, EAMR, XAMR, and QLC to name the most common. Let’s take a look at how we got here, and how the past and present of persistent storage have expanded what the word hard drive actually means and what is found under the hood.
We normally chuckle at high-profile auctions where people compete to pay as much as possible for items they clearly don’t need. It’s easy to laugh when the items on the block are things like paint-spattered canvases, but every once in a while some genuine bit of history that really piques our interest goes on sale. Such is the case with what is claimed to be an original Steve Wozniak-built Blue Box, going on sale November 5. The prospectus has an excellent summary of the history of the “Two Steves” and their early business venture making and selling these devices to Berkeley students eager to make free long distance phone calls. The item on sale is a very early rev, most likely assembled by Woz himself. The current owner claims to have bought it from Woz himself in the summer of 1972 while on a roadtrip from Sunnyvale to Los Angeles. Estimated to go for $4,000 to $6,000, we really hope this ends up in a museum somewhere — while we’ve seen attempts to recreate Woz’s Blue Box on Hackaday.io, letting a museum study an original would be a great glimpse into our shared technological history.
Not in the market for old tech? No problem — Digilent wants to get rid of 3,000 PCBs, and quickly. They posted the unusual offer on reddit a couple of days ago; it seems they have a huge stock of populated boards for a product that didn’t quite take the market by storm. Their intention is likely not to flood the market with scopes cobbled together from these boards, but rather to make them available to someone doing some kind of art installation or for educational purposes. It’s a nice gesture, and a decent attempt to keep these out of the e-waste stream, so check it out if you have a need.
Speaking of PCBs, SparkFun has just launched an interesting new service: SparkFun À La Carte. The idea is to make it really easy to design and build prototype boards. Instead of using traditional EDA software, users select different blocks from a menu. Select your processor, add components like displays and sensors, and figure out how you want to power it, and SparkFun will do the rest, delivering a fully assembled board in a few weeks. It certainly stands to suck the fun out of the design process while also hoovering up your pocketbook: “A $949 design fee will be applied to all initial orders of a design”. You can get your hands on the design files, but that comes with an extra fee: “they can be purchased separately for $150 by filling out this form”. But for someone who just needs to hammer out a quick design and get on with the next job, this could be a valuable tool.
Another day, another IoT ghost: Reciva Radio is shutting down its internet radio service. A large banner at the top of the page warns that the “website will be withdrawn” on January 31, 2021, but functionality on the site already appears limited. Users of the service are also reporting that their Reciva-compatible radios are refusing to stream content, apparently because they can’t download anything from the service’s back end. This probably doesn’t have a huge impact — I’d never heard of Reciva before — but it makes me look at the Squeezebox radio we’ve got in the kitchen and wonder how long for the world that thing is. It’s not all bad news, though — owners of the bricked radios will now have a great opportunity to hack them back into usefulness.
By the time this article is published, Halloween will be history and the hordes of cosplaying candy-grubbers who served as welcome if ironic respite from this non-stop horror show of a year will be gone. Luckily, though, if it should come to pass that the dead rise from their graves — it’s still 2020, after all — we’ll know exactly how to defeat them with this zombie invasion calculator. You may remember that last year Dominik Czernia did something similar, albeit with vampires. Switching things up from the hemophagic to the cerebrophagic this year, his calculator lets you model different parameters, like undead conversion percentage, zombie demographics, and attack speed. You’ve also got tools for modeling the response of the living to the outbreak, to see how best to fight back. Spoiler alert: everyone will need to bring Tallahassee-level badassery if we’re going to get through this.
I did something silly. I bought a lot of ten “broken” cheesy indoor quadcopters on eBay — to hopefully cobble one working one together and to amuse my son. At this point, I’ve got eight working. The bad news is that they all come with dirt-cheap transmitters that aren’t really conducive to flying at all. They’d be a lot more fun if they could be controlled with a real remote. Enter the hackers.
Most all of the cheap quads are based on one of a handful of radio chipsets, although they use different protocols. An enterprising hacker could conceivably just bundle together this handful of radio modules, and the rest would be a simple matter of software. That’s exactly what Pascal Langer’s DIY Multiprotocol TX and supporting firmware does. This hobby project was so successful that compatible hardware is manufactured by more than a few Chinese companies, and non-geeks have them installed in their radios. The module lets you control virtually anything that uses 2.4 GHz. Of course, I’ve got one of them.
I opened up the cheesy drone’s transmitter, found that it used a popular chipset, and worked through all the different supported protocols that used it. No dice. But the radio module did have nicely labeled SPI lines, so I reached out to Pascal. A couple of Sigrok sessions later, he’d figured out that it was trying to bind on a different channel, I’d recompiled the firmware, and was playing with the drone’s other functions.
I just love a good SPI-sniffing session. sigrok-cli -d fx2lafw -c samplerate=4000000 -P spi:clk=D0:mosi=D1:cs=D2 -A spi="mosi transfer" --continuous | grep A0 | uniq reads the SPI lines, decodes the packets, filters out the commands, and removes duplicates, in real-time. All that’s left to do is wiggle the sticks, mash buttons, and take good notes.
None of this was hard, and certainly none of it was expensive. I got my drones under the control of my fancy-schmancy remote, and have a good foothold into controlling them algorithmically later on thanks to everyone’s previous work on reverse engineering these protocols. Support for DF Drone’s SkyTumbler will be included in the next DIY Multiprotocol TX release, and I spent about four or five pleasant hours on this project. Maybe only a handful of people will stumble on this particular protocol — or maybe it will just be me. I did it mostly just to scratch my own particular itch.
But that’s one way open source works, thrives, and grows. Here’s to you all out there, from the Deviation team, who did a lot of the early drone protocol reverse engineering, to Pascal for the DIY Module, to the Sigrok folks who made the tools accessible for me to piggyback on everyone’s previous work. Keep on hacking!
Hackaday editors Mike Szczys and Elliot Williams dig through the greatest hacks that ought not be missed this week. There’s a wild one that flexes engineering skills instead of muscles to beat the homerun distance record with an explosively charged bat. A more elegant use of those engineering chops is shown in a CNC software tool that produces intricate wood joinery without needing an overly fancy machine to fabricate it. If your flesh and blood pets aren’t keeping up with your interests, there’s a new robot dog on the scene that far outperforms its constituent parts which are 3D-printed and of the Pi and Arduino varieties. And just when you thought you’d seen all the craziest retrocomputers, here’s an electromechanical relay based machine that took six years to build (although there’s so much going on here that it should have taken sixteen).
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 (~60 MB)
[Masato Kinugawa] found a series of bugs that, when strung together, allowed remote code execution in the Discord desktop app. Discord’s desktop application is an Electron powered app, meaning it’s a web page rendered on a bundled light-weight browser. Building your desktop apps on JavaScript certainly makes life easier for developers, but it also means that you inherit all the problems from running a browser and JS. There’s a joke in there about finally achieving full-stack JavaScript.
The big security problem with Electron is that a simple Cross Site Scripting (XSS) bug is suddenly running in the context of the desktop, instead of the browser. Yes, there is a sandboxing option, but that has to be manually enabled.
And that brings us to the first bug. Neither the sandbox nor the contextIsolation options were set, and so both defaulted to false. What does this setting allow an attacker to do? Because the front-end and back-end JavaScript runs in the same context, it’s possible for an XSS attack to override JS functions. If those functions are then called by the back-end, they have full access to Node.js functions, including exec(), at which point the escape is complete.
Now that we know how to escape Electron’s web browser, what can we use for an XSS attack? The answer is automatic iframe embeds. For an example, just take a look at the exploit demo below. On the back-end, all I have to do is paste in the YouTube link, and the WordPress editor does its magic, automatically embedding the video in an iframe. Discord does the same thing for a handful of different services, one being Sketchfab.
This brings us to vulnerability #2. Sketchfab embeds have an XSS vulnerability. A specially crafted sketchfab file can run some JS whenever a user interacts with the embedded player, which can be shoehorned into discord. We’re almost there, but there is still a problem remaining. This code is running in the context of an iframe, not the primary thread, so we still can’t override functions for a full escape. To actually get a full RCE, we need to trigger a navigation to a malicious URL in the primary pageview, and not just the iframe. There’s already code to prevent an iframe from redirecting the top page, so this RCE is a bust, right?
Enter bug #3. If the top page and the iframe are on different domains, the code preventing navigation never fires. In this case, JavaScript running in an iframe can redirect the top page to a malicious site, which can then override core JS functions, leading to a full escape to RCE.
It’s a very clever chaining of vulnerabilities, from the Discord app, to an XSS in Sketchfab, to a bug within Electron itself. While this particular example required interacting with the embedded iframe, it’s quite possible that another vulnerable service has an XSS bug that doesn’t require interaction. In any case, if you use Discord on the desktop, make sure the app is up to date. And then, enjoy the demo of the attack, embedded below.
Continue reading “This Week In Security: Discord, Chromium, And WordPress Forced Updates”
There’s just one week left until Hackaday Remoticon, our online gathering in place of our traditional in-person conference during this time of social distancing. Joining the more than 20 hands-on workshops that make up the bulk of Remoticon, we’re excited to announce the two keynote speakers who will be taking the virtual stage: Alfred Jones and Kipp Bradford.
Tickets to see these keynote talks, to watch the SMD Challenge, to see hardware demos, and to take part in the show and tell are free, so get yours today!
Alfred Jones is the Head of Mechanical Engineering at Lyft’s level 5 self-driving division. Level 5 means there are no humans involved in operating the vehicle and it is still capable of driving anywhere a human could have. What goes into modifying a vehicle for this level of self-driving? What processes does his team use to deliver safe automation? And will cars in the near future completely get rid of the driver’s seat? Alfred knows and we’ll be hanging on his every word!
Kipp BradfordKipp Bradford is the CTO of Treau, a company bringing heating, ventilation, and air conditioning (HVAC) into the information age. These systems contribute as much as 20% of global emissions each year, so even small efficiency gains stand to have a huge impact. The industry has remained nearly unchanged for decades, and Kipp is at the forefront of evolving the hidden systems found in nearly every building. Will the air conditioner of tomorrow make the one we have today look like a rotary telephone? We look forward to hearing what Kipp has to say about it.
We’re so excited to have these two phenomenal speakers who have also both been involved as expert judges in the Hackaday Prize (Alfred in 2020, Kipp in 2017 and 2018). Help us show our appreciation by packing the virtual lecture halls for their talks on Saturday, November 7th! Get your free ticket now.
