Great writeup.
I haven't seen products that use geofences to verify debug flags. Would it be possible to spoof this using a fake GPS e.g. with SDR?
I haven't seen products that use geofences to verify debug flags. Would it be possible to spoof this using a fake GPS e.g. with SDR?
Of course putting your satellite antenna inside of a RF chamber also prevents it from working, so this may not be a viable long term strategy. Plus the terminal is undoubtedly using the GPS coordinates to calculate the antenna steering profile so you won't be able to lock on if your GPS is wrong. But since all they want to do is enable access to dump the firmware this probably isn't an issue.
An interesting question, however, is whether Starlink checks whether the satellite you're tuned to is plausible given the GPS coordinates ...
1: Find the GPS module, and look up its data sheet.
2: Spoof the data coming out of its IO ports. Cheap GNSS modules that spit out NMEA messages on a serial line are everywhere. (I guess because they're super cheap, and easy to integrate)
Might not be as trivial as that makes it sound:
"Continuing through the boot process we can see that U-Boot loads a kernel, ramdisk and Flattened Device Tree (FDT) from a Flattened uImage Tree (FIT) image that is stored on an embedded MultiMediaCard (eMMC).
We can also see that the integrity (SHA256) and authenticity (RSA 2048) of the kernel, ramdisk and FDT is being checked. While we would have to perform some more tests it appears that a full trusted boot chain (TF-A) is implemented from the early stage ROM bootloader all the way down to the Linux operating system."
Desoldering a SOC and replacing it with something similar enough but different in its trusted boot config is somewhat less trivial than "manipulate the firmware" though, at least in my opinion...