Besides, encryption doesn't stop you from receiving the existing signal and repeating it with a well-tuned delay, which is all you really need to do to fake GPS...
That's the old fashioned P(Y) code that they dumped because it sucked and went to the M code that doesn't need P(C) first.
P(Y) code sucked because aside from needing to sync to P(C) first, they fed in the encryption stream at a varying, yet slow enough rate that you essentially got dozens of "known plaintext" packets reporting the same position using the same code. So if you could sync up to the W feed rate, even if you couldn't figure out what it said, you could get a better position after gathering enough data. Then again, for something like a cruise missile while in flight, taking 15 minutes while stationary isn't really all that useful.
The whole design of GPS is an interesting window into tradeoffs between accuracy and time as seen in the 70s. Given enough time you can always average something stationary to ridiculous precision. However the whole thing was designed so strategic weapons in motion couldn't average enough measurements in time to be useful at a strategic weapon level unless you had the .mil keys...
The wikipedia article is kinda interesting.
I currently/used to do stuff in the ham radio microwave bands kinda bracketing the GPS signal, one of those "infinite spare time" projects to program a FPGA to decode my own GPS. Why? Because I can. Right up there with making my own ADS-B receiver which is actually a lot easier on the digital side and about the same level of difficulty on the RF side, more or less.
I imagine it'd be a whole lot easier if you already have gear to receive and sample the RF side, but still an interesting challenge.
Don't forget to implement CoCom restrictions :)
https://github.com/jevinskie/jevps/blob/master/ca.py
Edit: I think I remember the issue. I started out thinking I just had to create a signal at 1.023 MHz, easy to do with an FPGA right? But then I realized that I would need to generate a much higher frequency signal so I could phase shift the different satellite's CA codes before adding them together. Am I correct in my thinking?
You'd be surprised how many people think GPS is a bidirectional protocol like DME/TACAN or an aircraft radar transponder. Its actually a heck of a lot more like the old fashioned TRANSIT sats or VOR or LORAN or OMEGA, with a thin smear of spread spectrum on top to reduce the impact of simplistic jamming and it sends more metadata on top of the nav data than pretty much anything ever invented.
The way GPS works is pretty much like LORAN (well, maybe more like OMEGA) but with embedded metadata. So you've got 40 satellites who know exactly where they are and exactly what time it is and exactly what frequency is the center of their spread spectrum spread, and they're more than glad to tell you all about it. All 40 of them. Maybe you can see a dozen of them at a time?
Anyway you sync up to the SS signal and that gives you a local offset for your clock and your local oscillator and you know the exact orbital position pertaining to that delta-t (aka distance) and delta-f (aka doppler velocity). Now average together a zillion satellites and solve a least squares puzzle for the most likely location for you. Which also feeds out an internal error correction signal for your internal osc and real time clock.
All the .mil signal does is squirt out a slightly more accurate encrypted signal so you need the same key all the satellites use and the key changes rather often.
