Suche
Beiträge, die mit recovering getaggt sind
38C3: Save your Satellite with these 3 Simple Tricks.
BEESAT-1 is a 1U cubesat launched in 2009 by the TU of Berlin. 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.
https://media.ccc.de/v/38c3-hacking-yourself-a-satellite-recovering-beesat-1
#beesat1 #satellite #recovering #space #science #it #engineer #media #38c3 #tech #news![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.](https://friendica-leipzig.de/photo/preview/600/407833 "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.")
![[ImageSource: media.ccc.de]
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. I can nearly guarantee that after watching this talk, you will wish that you did.](https://friendica-leipzig.de/photo/preview/600/407835 "[ImageSource: media.ccc.de]
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. I can nearly guarantee that after watching this talk, you will wish that you did.")
BEESAT-1 is a 1U cubesat launched in 2009 by the TU of Berlin. 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.
https://media.ccc.de/v/38c3-hacking-yourself-a-satellite-recovering-beesat-1
#beesat1 #satellite #recovering #space #science #it #engineer #media #38c3 #tech #news
![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.](https://nerdculture.de/system/media_attachments/files/113/775/884/503/863/177/original/f10605f43d59c6c8.jpeg "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.")
![[ImageSource: media.ccc.de]
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. I can nearly guarantee that after watching this talk, you will wish that you did.](https://nerdculture.de/system/media_attachments/files/113/775/885/346/238/637/original/163fe15294482862.png "[ImageSource: media.ccc.de]
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. I can nearly guarantee that after watching this talk, you will wish that you did.")
Hacking yourself a satellite - recovering BEESAT-1
In 2013, the satellite BEESAT-1 started returning invalid telemetry, rendering it effectively unusable. Because it is projected to remain...media.ccc.de
