Lessons Learned From A CubeSat Postmortem

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.

[Thanks to ppkt for the tip.]

This Week In Security: Chrome Speech Bug, UDP Fragmentation, And The Big Citrix Vulnerability

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”

A Raspberry Pi Terminal That’s Always Within Reach

Inspired by films such as The Matrix, where hackers are surrounded by displays and keyboards on articulated arms, [Jay Doscher] created this cyberpunk “floating” terminal so your favorite Linux single board computer is always close at hand. Do you actually need such a thing mounted to the wall next to the workbench? Probably not. But when has that ever stopped a Hackaday reader?

[Jay] has come up with a modular design for the “A.R.M. Terminal” that allows the user to easily augment it with additional hardware. The 3D printed frame of the terminal has hardpoints to bolt on new modules, which thanks to threaded metal inserts, will have no problem surviving multiple configurations.

This initial version features a panel on the left side that holds various buttons and switches attached to the Pi’s GPIO pins. With a bit of code, it’s easy to pick up the status of these controls and use them to fire off whatever tasks your imagination can come up with. On the bottom [Jay] has mounted a stand-alone VFD audio spectrum display that’s hooked up to the Pi’s 3.5 mm jack. It’s totally unnecessary and costs as much as the Raspberry Pi itself, but it sure is pretty.

If there’s a downside to the design, it’s that the only display currently supported is the official Raspberry Pi touchscreen which is only 800×480 and a bit pricey compared to more modern panels. On the other hand, there’s something to be said for the standardized bolt pattern on the back of the official screen; so if you want to use a higher resolution display, be prepared to design your own mounting bracket. Extra points if you share your changes with the rest of the class.

For anyone who likes the look of the A.R.M. Terminal but isn’t too keen on being tethered to the wall, you’re in luck. [Jay] previously created the Raspberry Pi Recovery Kit which shares many of the same design principles but puts them into a ruggedized case that’s ready for life in the field.

Students Use Low Tech Hacks On High Tech Parking Enforcer

If you are a college student and you get too many parking fines, you are going to get in trouble. But one school didn’t count on students hacking their high tech parking violation deterrent. Some even got free internet from the devices.

You pay your taxes or — in the case of students — your tuition. But still, the city or university wants you to pay to park your car. In the old days, you’d get your car towed. But the people running the parking lot don’t really like having to share the fees they charge you with a tow truck driver. Many places clamp a device to your tire that makes it impossible to drive. Oklahoma University decided that was too much trouble, also, so they turned to Barnacle. Barnacle is a cheaper alternative to the old parking clamp. In sticks to your windshield so you can’t see to drive. The suction cups have an air pump to keep them secure and a GPS squeals if you move the car with it on there anyway.

Continue reading “Students Use Low Tech Hacks On High Tech Parking Enforcer”