I’m interested in how to secure the firmware from reverse-engineering in a product. Is there somewhere an introduction to the techniques used by SpaceX there?
Step 1 is things like encrypted firmware, so I’d suspect SpaceX does nothing or is reactive - they had debug pins until someone published attacks utilizing them.
At a minimum you'd want to encrypt your rootfs using secrets that are hard to extract from secure elements. To go a step further you can employ something like ARM's TrustZone to hide away the sensitive operations (bootloader, decryptions, image signing, etc.)
The fact that they could just dump the filesystem tells me there's no protection employed at SpaceX aside from the boot loader mentioned in the article.
As someone who used a bunch of good products with less than great firmwares I would like you to ask to please consider not doing this, unless you have a strong, real and well-analyzed reason.
Rather, please consider spending your resources wisely, on something that benefits everyone and makes your product better. For power users, a theoretical ability to modify your product (possibly, in a ways you've never even thought about) can be a valuable benefit. So, unless you're certain to be seriously harmed by this in some way, please consider not wasting your (and your users') time on something of questionable value.
Just saying how it looks like from a technical end-user perspective. I'm just really tired and even somewhat depressed of having to hack my devices (lights, cat feeders, now a rowing machine) to make them work properly.
