BEESAT-1 is a 1U cubesat launched in 2009 by the Technical University of Berlin. Like all good satellites, it has redundant computers onboard, so when the first one failed in 2011, it just switched over to the second. And when the backup failed in 2013, well, the satellite was “dead” — or rather sending back all zeroes. Until [PistonMiner] took a look at it, that is.
Getting the job done required debugging the firmware remotely — like 700 km remotely. Because it was sending back all zeroes, but sending back valid zeroes, that meant there was something wrong either in the data collection or the assembly of the telemetry frames. A quick experiment confirmed that the assembly routine fired off very infrequently, which was a parameter that’s modifiable in SRAM. Setting a shorter assembly time lead to success: valid telemetry frame.
Then comes the job of patching the bird in flight. [PistonMiner] pulled the flash down, and cobbled together a model of the satellite to practice with in the lab. And that’s when they discovered that the satellite doesn’t support software upload to flash, but does allow writing parameter words. The hack was an abuse of the fact that the original code was written in C++. Intercepting the vtables let them run their own commands without the flash read and write conflicting.
Of course, nothing is that easy. Bugs upon bugs, combined with the short communication window, made it even more challenging. And then there was the bizarre bit with the camera firing off after every flash dump because of a missing break in a case statement. But the camera never worked anyway, because the firmware didn’t get finished before launch.
Challenge accepted: [PistonMiner] got it working, and after fifteen years in space, and ten years of being “dead”, BEESAT-1 was taking photos again. What caused the initial problem? NAND flash memory needs to be cleared to zeroes before it’s written, and a bug in the code lead to a long pause between the two, during which a watchdog timeout fired and the satellite reset, blanking the flash.
This talk is absolutely fantastic, but may be of limited practical use unless you have a long-dormant satellite to play around with. We can nearly guarantee that after watching this talk, you will wish that you did. If so, the Orbital Index can help you get started.
Ond must wonder how many more “dead” satellites are currently in orbit… That can make a wild new community.
somebody might want to vastly update the wikipedia entry for this bird — it is way out of date.
The video feed is also trash, I wonder why they haven’t mirrored it yet. Also is that guy wearing cat ears
“Also is that guy wearing cat ears”
You must be new to hackerdom.
There is IRC and Discord and all that, then there is seeing someone in person. Like going to a Sci-Fi Con and finding it is not quite what you expected. Maybe Egyptian God Ears?
My question is, does the hair mean he is a Half-Ada?
Cat ears gives you +2 to Hardware Hacking. A Lain onsie gives you +5. A full furry suit doubles all your hacking related stats. I thought this was common knowledge.
Bugs Bugs Bugs. For something like this you REALLY want to be using Rust. Seriously.
Google learned this the hard way with project loon and Oxide spent a lot of time and effort developing the Hubris RTOS (and Humility debugger), for applications exactly like this which demand high reliability and correctness.
For this particular case, Rust wouldn’t have saved you. All the issue boiled down to the flash page for settings being completely empty due to a reset during a read-erase-write cycle, in turn caused by an implementation error.
While I am generally a fan of rust, this rustism is just not true.
Yes rust can make it harder to write bad code, but it will not fully prevent it. Case in point the missing break. A linter might warn you ‘hey is this what you really want’ but in the end, its a logical flaw.Could have also be the other way arounf …failed because an extra break where the code was supposed to fall through …
Sloppy code under high time pressure is almost a guarantee shit fails, even with rust. Heck rust may have made it so that the pressure on timelines where to be higher.
I think python is a great example here, where there’s plenty of bugs around, but memory safety isn’t really one of them.
So yes, rust is great. No, rust won’t solve all problems. Netter developers, (static) code analysis, test automation, heck even AI, etc might.
Was rust even around when the code in question was written?
Too bad the students that built the satellite have since graduated, got jobs, got married, got kids, and got no time to spare.
B^)
(No I didn’t read the link!)