China’s Moon Mission Was About More Than Rocks

December 14, 2020 by Tom Nardi 67 Comments

If everything goes according to plan, China will soon become the third country behind the United States and the Soviet Union to successfully return a sample of lunar material. Their Chang’e 5 mission, which was designed to collect 2 kilograms (4.4 pounds) of soil and rock from the Moon’s surface, has so far gone off without a hitch. Assuming the returning spacecraft successfully renters the Earth’s atmosphere and lands safely on December 16th, China will officially be inducted into a very exclusive club of Moon explorers.

Of course, spaceflight is exceedingly difficult and atmospheric reentry is particularly challenging. Anything could happen in the next few days, so it would be premature to celebrate the Chang’e 5 mission as a complete success. But even if ground controllers lose contact with the vehicle on its return to Earth, or it burns up in the atmosphere, China will come away from this mission with a wealth of valuable experience that will guide its lunar program for years to come.

In fact, one could argue that was always the real goal of the mission. While there’s plenty of scientific knowledge and not an inconsequential amount of national pride to be gained from bringing a few pounds of Moon rocks back to Earth, it’s no secret that China has greater aspirations when it comes to our nearest celestial neighbor. Starting with the launch of the Chang’e 1 in 2007, the Chinese Lunar Exploration Program has progressed through several operational phases, each more technically challenging than the last. Chang’e 5 represents the third phase of the plan, with only the establishment of robotic research station to go before the country says they’ll proceed with a crewed landing in the 2030s.

Which helps explain why, even for a sample return from the Moon, Chang’e 5 is such an extremely complex mission. A close look at the hardware and techniques involved shows a mission profile considerably more difficult than was strictly necessary. The logical conclusion is that China intentionally took the long way around so they could use it as a dry run for the more challenging missions that still lay ahead.

Continue reading “China’s Moon Mission Was About More Than Rocks” →

Hackaday Links: December 13, 2020

December 13, 2020 by Dan Maloney 16 Comments

Our Sun is getting a bit frisky these days, and has rewarded us with perhaps the best screensaver image ever taken. The incredibly detailed photo of a sunspot was actually taken back in January by the Daniel K. Inouye Solar Telescope, a 4-meter instrument with adaptive optics that can image the sun from the near-infrared to visible wavelengths and resolve surface details down to 20 km. The photo, with a distinct “Eye of Sauron” look, shows the massive convection cells surrounding the dark sunspot; an accompanying animation shows the movement of plasmas along the tortured lines of magnetic flux that cause the sunspot to form. It’s fascinating to watch, and even more interesting to mull over the technology that went into capturing it.

With the dustup surrounding the youtube-dl DCMA takedown by GitHub fresh on the open-source community’s minds, GitHub Universe 2020 had an interesting discussion about maintaining open-source software projects that’s worth watching. They focused on the challenges that youtube-dl maintainers face in keeping the tool working, and the impact their effort has on the people and groups that rely on them. To underscore that point, they featured a researcher with Human Rights Watch who depends on youtube-dl in her work, and made it quite clear that keeping up with all the API changes that constantly break open source tools like youtube-dl make the role of the maintainers that much more critical.

Speaking of GitHub, here’s a frightening and fascinating new tool: Depix, the password de-pixelizer. Developer Sipke Mellema noticed that his company often used pixelization to obscure passwords in documentation, and wondered if he could undo the process. He wrote up an article describing the pixelization process using a linear box filter and his method for attacking it, which involves generating a De Bruijn sequence in the same font, text size, and colors as the original document and feeding a screenshot of that and the pixellated password into the tool. We suspect it’ll only work for a subset of obfuscated passwords, but it’s still pretty clever.

‘Tis the season for Advent calendars, and the folks at QEMU have posted theirs. Open each of 24 doors on the calendar and you’re rewarded with a downloadable QEMU disk image that implements something fun. Minesweeper, a ray tracer that fits into a boot loader, and of course Conway’s Game of Life. The GW-BASIC image on Day 3 caught our eye — brings back some memories.

For anyone who has ever watched a Pixar film and wondered how all that animation actually works, here’s a great lesson in making art with math. The video is by Inigo Quilez and goes through the basics of rendering images using raymarching SDFs, or signed distance functions. In the beginning, it seemed like it was going to be a little bit like drawing an owl, but his descriptions of the math involved and how each element of the animation is just another formula is fascinating. What’s more, there’s a real-time rendering tool where you can inspect the code and edit it. Alas, my changes only made things worse, but it was still fun and instructive to play with. Check out the video after the break!

Continue reading “Hackaday Links: December 13, 2020” →

How Much Is Too Much?

December 12, 2020 by Elliot Williams 52 Comments

I definitely tend towards minimalism in my personal projects. That often translates into getting stuff done with the smallest number of parts, or the cheapest parts, or the lowest tech. Oddly enough that doesn’t extend to getting the project done in the minimum amount of time, which is a resource no less valuable than money or silicon. The overkill road is often the smoothest road, but I’ll make the case for taking the rocky, muddy path. (At least sometimes.)

There are a bunch of great designs for CNC hot-wire foam cutters out there, and they range from the hacky to the ridiculously over-engineered, with probably most of them falling into the latter pile. Many of the machines you’ll see borrow heavily from their nearest cousins, the CNC mill or the 3D printer, and sport hardened steel rails or ballscrews and are constructed out of thick MDF or even aluminum plates.

All a CNC foam cutter needs to do is hold a little bit of tension on a wire that gets hot, and pass it slowly and accurately through a block of foam, which obligingly melts out of the way. The wire moves slowly, so the frame doesn’t need to handle the acceleration of a 3D printer head, and it faces almost no load so it doesn’t need any of the beefy drives and ways of the CNC mill. But the mechanics of the mill and printer are so well worked out that most makers don’t feel the need to minimize, simply build what they already know, and thereby save time. They build a machine strong enough to carry a small child instead of a 60 cm length of 0.4 mm wire that weighs less than a bird’s feather.

I took the opposite approach, building as light and as minimal as possible from the ground up. (Which is why my machine still isn’t finished yet!) By building too little, too wobbly, or simply too janky, I’ve gotten to see what the advantages of the more robust designs are. Had I started out with an infinite supply of v-slot rail and ballscrews, I wouldn’t have found out that they’re overkill, but if I had started out with a frame that resisted pulling inwards a little bit more, I would be done by now.

Overbuilding is expedient, but it’s also a one-way street. Once you have the gilded version of the machine up and running, there’s little incentive to reduce the cost or complexity of the thing; it’s working and the money is already spent. But when your machine doesn’t quite work well enough yet, it’s easy enough to tell what needs improving, as well as what doesn’t. Overkill is the path of getting it done fast, while iterated failure and improvement is the path of learning along the way. And when it’s done, I’ll have a good story to tell. Or at least that’s what I’m saying to myself as I wait for my third rail-holder block to finish printing.

Remoticon Video: Breaking Encrypted Firmware Workshop

December 11, 2020 by Mike Szczys 6 Comments

If only you could get your hands on the code to fix the broken features on your beloved electronic widget. But wait, hardware hackers have the skills to write their own firmware… as long as we can get the compiled binary into a format the hardware needs.

Luckily, we have Uri Shaked to walk us through that process. This workshop from the 2020 Hackaday Remoticon demonstrates how to decipher the encryption scheme used on the firmware binary of a 3D printer. Along the way, we learn about the tools and techniques that are useful for many encrypted binary deciphering adventures.

Continue reading “Remoticon Video: Breaking Encrypted Firmware Workshop” →

Bare-Metal STM32: Blinky And The Secret Of Delay Functions

December 11, 2020 by Maya Posch 35 Comments

One of the very first examples for an MCU or SoC usually involves the famous ‘Blinky‘ example, where an LED is pulsed on and off with a fixed delay. This is actually a lot more complicated than the ‘Pushy‘ example which we looked at in the first installment of this series. The reason for this is that there’s actually quite a story behind a simple call to delay() or its equivalent.

The reason for this is that there are many ways to implement a delay function on a microcontroller (MCU), each of which comes with their own advantages and disadvantages. On an STM32 MCU, we get to choose between essentially an active delay (while loop), one implemented using the SysTick timer and using one of the peripheral timers. In the latter two cases we also have to use interrupts.

In this article we’ll take a look at all three approaches, along with their advantages and disadvantages.

Continue reading “Bare-Metal STM32: Blinky And The Secret Of Delay Functions” →

Hackaday Podcast 097: We ♥ MicroMice, The Case Of The Missing Drones, And 3D Prints Tested For Rocketry And Food Prep

December 11, 2020 by Mike Szczys 3 Comments

Hackaday editors Mike Szczys and Elliot Williams round up the latest hardware hacks. This week we check out the latest dead-simple automation — a wire cutting stripping robot that uses standard bypass strippers. Put on your rocket scientist hat and watch what happens in a 3D-printed rocket combustion chamber. Really small robots are so easy to love, this micromouse is the size of a coin. And whatever happened to those drone sightings at airports? We talk about all that, and round up the episode with Hyperloop, and Xiaomi thermometers.

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)

Places to follow Hackaday podcasts:

Continue reading “Hackaday Podcast 097: We ♥ MicroMice, The Case Of The Missing Drones, And 3D Prints Tested For Rocketry And Food Prep” →

This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More

December 11, 2020 by Jonathan Bennett 9 Comments

There’s a VMWare problem that’s being exploited in the wild, according to the NSA (PDF). The vulnerability is a command injection on an administrative console. The web host backing this console is apparently running as root, as the vulnerability allows executing “commands with unrestricted privileges on the underlying operating system.”

The wrinkle that makes this interesting is that VMWare learned about this vuln from the NSA, which seems to indicate that it was a zero-day being used by a foreign state. The compromise chain they list is also oddly specific, making me suspect that it is a sanitized account of observed attacks.

Microsoft Teams, And the Non-CVE

[Oskars Vegeris] found a pair of interesting problems in the Microsoft Teams client, which together allows an interactionless, wormable RCE. The first vuln is an XSS problem, where a message containing a “mention” can be modified in transit to include arbitrary Javascript. To get that JS past the XSS protection filter, a unicode NULL byte is included in the payload. The second vuln is using the built-in file download code in the Teams app to download and auto-run a binary. Put together, anyone who simply loads the message in their Teams app runs the code.

Vegeris points out that since so many users have a presence in multiple rooms, it would be trivial to use this exploit to build a worm that could infect the majority of Teams users worldwide. The bug was reported privately to Microsoft and fixed back in October. A wormable RCE in a widely used tool seems like a big deal, and should net a high CVE score, right? Microsoft gave two ratings for this attack chain, for the two versions of Teams that it can affect. For the Office365 client, it’s “Important, Spoofing”, which is about as unimportant as a bug can be. The desktop app, at least, was rated “critical” for an RCE. The reason for that seems to be that the sandbox escape only works on the standalone desktop app.

But no CVE was issued for the exploit chain. In the security community, collecting CVEs is an important proof of work for your resume. Microsoft replied that they don’t issue CVEs for products that get updated automatically without user interaction. Kerfuffle ensued. Continue reading “This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More” →