Aerospace Cybersecurity Student Research Spotlight Cal Poly

Clara Davis, a Cal Poly student, opens with why third-party code matters for satellites, where software often cannot be patched after launch. Many C and C++ dependencies arrive implicitly through build scripts rather than package managers, so they are easy to miss. She describes extending an existing dependency scanner to detect multiple toolchains, adding code-clone detection to find vendored code, and building transitive dependency graphs checked against CVE data. Automated matching sometimes returns unrelated repositories, so results need manual review.

Dylan Gururajan then presents a post-compromise attack against CubeSat flight software built on NASA's F Prime running on Linux. Assuming an attacker can uplink and execute user-level code, the injector attaches to the main flight process with ptrace, saves its register state, and triggers a remote mmap to obtain writable memory. It writes a shared object path there, finds libc through the process maps, and redirects execution to dlopen so the library's constructor runs. He demonstrated the chain on a Raspberry Pi, and no kernel bug or file on disk is required.

The main lesson is that the attack depends on intended Linux behavior, so fixing a single exploit does not solve it. Options such as hiding process metadata, restricting ptrace, or restricting dlopen each carry tradeoffs for mission debugging. The speaker argues that developers should treat the flight process as its own protected boundary. Clara closes by recommending that every space project generate a software bill of materials, since you cannot protect components you do not know you have.