Hackaday Links Column Banner

Hackaday Links: July 3, 2022

Looks like we might have been a bit premature in our dismissal last week of the Sun’s potential for throwing a temper tantrum, as that’s exactly what happened when a G1 geomagnetic storm hit the planet early last week. To be fair, the storm was very minor — aurora visible down to the latitude of Calgary isn’t terribly unusual — but the odd thing about this storm was that it sort of snuck up on us. Solar scientists first thought it was a coronal mass ejection (CME), possibly related to the “monster sunspot” that had rapidly tripled in size and was being hyped up as some kind of planet killer. But it appears this sneak attack came from another, less-studied phenomenon, a co-rotating interaction region, or CIR. These sound a bit like eddy currents in the solar wind, which can bunch up plasma that can suddenly burst forth from the sun, all without showing the usually telltale sunspots.

Then again, even people who study the Sun for a living don’t always seem to agree on what’s going on up there. Back at the beginning of Solar Cycle 25, NASA and NOAA, the National Oceanic and Atmospheric Administration, were calling for a relatively weak showing during our star’s eleven-year cycle, as recorded by the number of sunspots observed. But another model, developed by heliophysicists at the U.S. National Center for Atmospheric Research, predicted that Solar Cycle 25 could be among the strongest ever recorded. And so far, it looks like the latter group might be right. Where the NASA/NOAA model called for 37 sunspots in May of 2022, for example, the Sun actually threw up 97 — much more in line with what the NCAR model predicted. If the trend holds, the peak of the eleven-year cycle in April of 2025 might see over 200 sunspots a month.

So, good news and bad news from the cryptocurrency world lately. The bad news is that cryptocurrency markets are crashing, with the flagship Bitcoin falling from its high of around $67,000 down to $20,000 or so, and looking like it might fall even further. But the good news is that’s put a bit of a crimp in the demand for NVIDIA graphics cards, as the economics of turning electricity into hashes starts to look a little less attractive. So if you’re trying to upgrade your gaming rig, that means there’ll soon be a glut of GPUs, right? Not so fast, maybe: at least one analyst has a different view, based mainly on the distribution of AMD and NVIDIA GPU chips in the market as well as how much revenue they each draw from crypto rather than from traditional uses of the chips. It’s important mainly for investors, so it doesn’t really matter to you if you’re just looking for a graphics card on the cheap.

Speaking of businesses, things are not looking too good for MakerGear. According to a banner announcement on their website, the supplier of 3D printers, parts, and accessories is scaling back operations, to the point where everything is being sold on an “as-is” basis with no returns. In a long post on “The Future of MakerGear,” founder and CEO Rick Pollack says the problem basically boils down to supply chain and COVID issues — they can’t get the parts they need to make printers. And so the company is looking for a buyer. We find this sad but understandable, and wish Rick and everyone at MakerGear the best of luck as they try to keep the lights on.

And finally, if there’s one thing Elon Musk is good at, it’s keeping his many businesses in the public eye. And so it is this week with SpaceX, which is recruiting Starlink customers to write nasty-grams to the Federal Communications Commission regarding Dish Network’s plan to gobble up a bunch of spectrum in the 12-GHz band for their 5G expansion plans. The 3,000 or so newly minted experts on spectrum allocation wrote to tell FCC commissioners how much Dish sucks, and how much they love and depend on Starlink. It looks like they may have a point — Starlink uses the lowest part of the Ku band (12 GHz – 18 GHz) for data downlinks to user terminals, along with big chunks of about half a dozen other bands. It’ll be interesting to watch this one play out.

Not On The Internet

Whenever you need to know something, you just look it up on the Internet, right? Using the search engine of your choice, you type in a couple keywords, hit enter, and you’re set. Any datasheet, any protocol specification, any obscure runtime error, any time. Heck, you can most often find some sample code implementing whatever it is you’re looking for. In a minute or so.

It is so truly easy to find everything technical that I take it entirely for granted. In fact, I had entirely forgotten that we live in a hacker’s utopia until a couple nights ago, when it happened again: I wanted to find something that isn’t on the Internet. Now, to be fair, it’s probably out there and I just need to dig a little deeper, but the shock of not instantly finding the answer to a random esoteric question reminded me how lucky we actually are 99.99% of the time when we do find the answer straight away.

So great job, global hive-mind of über-nerds! This was one of the founding dreams of the Internet, that all information would be available to everyone anywhere, and it’s essentially working. Never mind that we can stream movies or have telcos with people on the other side of the globe – when I want a Python library for decoding Kansas City Standard audio data, it’s at my fingertips. Detailed SCSI specifications? Check.

But what was my search, you ask? Kristina and I were talking about Teddy Ruxpin, and I thought that the specification for the servo track on the tape would certainly have been reverse engineered and well documented. And I’m still sure it is – I was just shocked that I couldn’t instantly find it. The last time this happened to me, it was the datasheet for the chips that make up a Speak & Spell, and it turned out that I just needed to dig a lot harder. So I haven’t given up hope yet.

And deep down, I’m a little bit happy that I found a hole in the Internet. It gives Kristina and me an excuse to reverse engineer the format ourselves. Sometimes ignorance is bliss. But for the rest of those times, when I really want the answer to a niche tech question, thanks everyone!

Unraveling The Hackaday Podcast Hidden Message

When Elliot and I record the raw audio for the weekly podcast, it’s not unusual for us to spend the better part of two hours meandering from topic to topic. During one of these extended gab sessions, we wondered if it would be possible to embed a digital signal into the podcast in such a way that it could be decoded by the listener. Of course, storing and transmitting data via sound is nothing new — but the podcast format itself introduced some level of uncertainty.

Would the encoded sound survive the compression into MP3? Would the syndication service that distributes the file, or the various clients listeners will use to play it back, muddy the waters even further? Was it possible that the whole episode would get flagged somewhere along the line as malicious? After a bit of wild speculation, the conversation moved on to some other topic, and the idea was left to stew on one of our infinite number of back burners.

That is, until Elliot went on vacation a couple weeks back. In place of a regular episode, we agreed that I’d try my hand at putting together a special edition that consisted of pre-recorded segments from several of the Hackaday contributors. We reasoned this simplified approach would make it easier for me to edit, or to look at it another way, harder for me to screw up. For the first time, this gave me the chance to personally oversee the recording, production, and distribution of an episode. That, and the fact that my boss was out of town, made it the perfect opportunity to try and craft a hidden message for the Hackaday community to discover.

I’m now happy to announce that, eleven days after the EMF Camp Special Edition episode was released, ferryman became the first to figure out all the steps and get to the final message. As you read this, a coveted Hackaday Podcast t-shirt is already being dispatched to their location.

As there’s no longer any competition to see who gets there first, I thought it would be a good time to go over how the message was prepared, and document some interesting observations I made during the experiment.

Continue reading “Unraveling The Hackaday Podcast Hidden Message”

Hackaday Podcast 175: Moonrocks And Cockroach Chyme, A Raspberry Pi IPad, And A Retro-Respectful Tape Deck

Join Editor-in-Chief Elliot Williams and Assignments Editor Kristina Panos as we cuss and discuss all the gnarliest hacks from the past week. We kick off this episode with a gentle reminder that the Odd Inputs and Peculiar Peripherals Contest ends this Monday, July 4th, at 8:30 AM PDT. We’ve seen a ton of cool entries so far, including a new version of [Peter Lyons]’ Squeezebox keyboard that we’re itching to write up for the blog.

In other contest news, the Round 2 winners of the Reuse, Recycle, Revamp challenge of the 2022 Hackaday Prize have been announced. Elliot is super stoked about [Jason Knight]’s open-source recycled skateboard deck-making apparatus, and Kristina wishes she had the time and money to build some of the fundamental Precious Plastic machines.

Elliot managed to stump Kristina with this week’s What’s That Sound, though she probably should have made a semi-educated guess. From there, it’s on to missing moon rocks and the word of the day before we get into a handful of contest entries, including a mechanical keyboard to end all mechanical keyboards.

This really just scratches the surface of this week’s show, which includes some new hardware stuffed into old, as well as modern implementations of old technology. And in case you didn’t get enough of Kristina’s childhood memoirs, she goes a bit deeper into the teddy bears and telephones rooms of her memory palace.

Direct download, record it to tape, and play it on your boombox.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Continue reading “Hackaday Podcast 175: Moonrocks And Cockroach Chyme, A Raspberry Pi IPad, And A Retro-Respectful Tape Deck”

This Week In Security: Zimbra RCE, Routers Under Attack, And Old Tricks In WebAssembly

There’s a problem in the unrar utility, and as a result, the Zimbra mail server was vulnerable to Remote Code Execution by simply sending an email. So first, unrar is a source-available command-line application made by RarLab, the same folks behind WinRAR. CVE-2022-30333 is the vulnerability there, and it’s a classic path traversal on archive extraction. One of the ways this attack is normally pulled off is by extracting a symlink to the intended destination, which then points to a location that should be restricted. unrar has code hardening against this attack, but is sabotaged by its cross-platform support. On a Unix machine, the archive is checked for any symbolic links containing the ../ pattern. After this check is completed, a function runs to convert any Windows paths to Unix notation. As such, the simply bypass is to include symlinks using ..\ traversal, which don’t get caught by the check, and then are converted to working directories.

That was bad enough, but Zimbra made it worse by automatically extracting .rar attachments on incoming emails, in order to run a virus and spam check. That extraction isn’t sandboxed, so an attacker’s files are written anywhere on the filesystem the zimbra user can write. It’s not hard to imagine how this turns into a full RCE very quickly. If you have an unrar binary based on RarLab code, check for version 6.1.7 or 6.12 of their binary release. While Zimbra was the application specifically called out, there are likely to be other cases where this could be used for exploitation.
Continue reading “This Week In Security: Zimbra RCE, Routers Under Attack, And Old Tricks In WebAssembly”

Raspberry Pi Pico W Adds Wireless

News just in from the folks at Raspberry Pi: the newest version of their Pico has WiFi and is called, obviously, the Pico W. We were going to get our hands on a sample unit and kick its tires, but it’s stuck in customs. Boo! So until it shows up, here’s what we can glean from the press releases and documentation.

The Pico is, of course, the Raspberry Pi microcontroller dev board based on their RP2040 microcontroller. This in turn has two Cortex M0+ cores and a good chunk of onboard RAM, which has made it a popular target for MicroPython. They had some extra real estate on the PCB, so they’ve added an Infineon CYW43439 WiFi chip, and voila: Pico W.

As of now, the WiFi is supported in both the C SDK and the pre-baked MicroPython image. It looks trivially easy to get it working, and it’s based on the time-tested lwIP stack, a classic in the embedded world. The CYW43439 is also Bluetooth capable, but there’s no firmware support for that yet, but we wouldn’t be surprised if it showed up soon.

The price? $6 for the whole shooting match. You can view this two ways: a small $2 premium over the old Pico, or a price increase of 50%. How you see things probably depends on your order quantity. Either way, it’s firmly in the ESP32 module price range, so you’ve got some comparison shopping to do if your project needs a microcontroller and WiFi. And in these days of silicon shortages, it’s nice to have a couple of options.

Bare-Metal STM32: Adding An Analog Touch With ADCs

An Analogue to Digital Converter (ADC) is at its core a straight-forward device: by measuring an analog voltage within a set range and converting the measured level to a digital value we can use this measurement value in our code. Through the use of embedded ADCs in microcontrollers we can address many essential use cases, ranging from measuring the setting on a potentiometer, to reading an analog output line on sensors, including the MCU’s internal temperature and voltage sensors.

The ADCs found in STM32 MCUs have a resolution between 12 to 16 bits, with the former being the most common type. An ADC can be configured to reduce this resolution, set a specific sampling speed, and set up a multi-mode configuration depending on the exact ADC peripheral. STM32 MCUs feature at least a single ADC peripheral, while some have multiple. In this article we will take a look at how to configure and use the basic features of the ADCs in STM32 MCUs, specifically the ADCs found in F0 and the ADC5_V1_1 type as found in most F3-family MCUs.

Continue reading “Bare-Metal STM32: Adding An Analog Touch With ADCs”