Sure, GPS SDR Sim[1] works just fine. You will want to be in an RF chamber of some kind not only to prevent the terminal from seeing natural GPS signals, but also to prevent you from screwing up the GPS in nearby satnav systems. Also because broadcasting on those bands on public airwaves is illegal as a private citizen.
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.
From working on hardware with GPS-functionality tacked on before, I can suggest a simpler solution;
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)
Spoofing GPS might be dangerous should the dish detect coarsely its position also from the IP satellite link. If it does, then having the incoming data telling one position and the GPS a very different one, would likely trigger some protection.
I'd have to imagine in this case it's using the GPS location to assist in acquiring and tracking the satellites (though that's entirely a guess based on the "auto-adjusting" that's claimed). Spoofing your GPS location like that may work as far as bypassing the geofence, but you may not get internet at the same time.
Right, if the UT has a mistaken idea of its position, it won't find the satellites that it is looking for in orbit, and simply not work. Alternatively, if it DID find satellites, then it will know at least what cell it is in (how big are these?) regardless of the spoofed GPS fix.
I'm not sure the dish can continue to work if it doesn't have a real GPS lock. That said, this is a mechanism that they found on the dish side in the firmware - firmware that is unencrypted stored on that flash chip - so you can obviously manipulate the firmware side to ignore the debug fuse stuff.
> so you can obviously manipulate the firmware side to ignore the debug fuse stuff.
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."
Yeah. If you can futz with the hardware, pretty much any security can be circumvented.
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...
I have no info about the UT's use of GPS, but given that you can basically construct a practically-unbreakable geofence around the fact that the UT can only physically see a specific set of satellite(s) at any particular point in time (and space), and you get this property for free given the UT's purpose, I can't imagine that not being leveraged in the design.
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?