Spread Spectrum Satcom Hacking
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Moore, Colby
Recently there have been several highly publicized talks about satellite hacking. However, most only touch on the theoretical rather than demonstrate actual vulnerabilities and real world attack scenarios. This talk will demystify some of the technologies behind satellite communications and do what no one has done before - take the audience step-by-step from reverse engineering to exploitation of the GlobalStar simplex satcom protocol and demonstrate a full blown signals intelligence collection and spoofing capability. I will also demonstrate how an attacker might simulate critical conditions in satellite connected SCADA systems. In recent years, Globalstar has gained popularity with the introduction of its consumer focused SPOT asset-tracking solutions. During the session, I’ll deconstruct the transmitters used in these (and commercial) solutions and reveal design and implementation flaws that result in the ability to intercept, spoof, falsify, and intelligently jam communications. Due to design tradeoffs these vulnerabilities are realistically unpatchable and put millions of devices, critical infrastructure, emergency services, and high value assets at risk. Speaker Bios: Colby Moore is Synack's Manager of Special Activities. He works on the oddball and difficult problems that no one else knows how to tackle and strives to embrace the attacker mindset during all engagements. He is a former employee of VRL and has identified countless 0day vulnerabilities in embedded systems and major applications. In his spare time you will find him focusing on that sweet spot where hardware and software meet, usually resulting in very interesting consequences. Twitter: @colbymoore
 All right, as I said, welcome to track one. This is the one o'clock talk as you well know. We have Colby Moore. He's going to talk about satcom hacking. He reportedly found some vulnerabilities and some satellites. So he's going to talk about that. This is a rerun of his talk that he gave at Black Hat. So please help me welcome Colby Moore. Thanks, guys. Good afternoon, DEF CON. Thanks for coming out. So today we're going to talk about spread spectrum signals and hacking the global star simplex data service. But first, who am I? I'm a mechanical engineer that loves computer security. I'm currently working at SINAC on the R&D team. I got interested in satellites and radios a long time ago when I got my ham radio license. And yes, ladies, that's my call sign. So radio me. I'm single. So what is this company SINAC that I work for? Basically we're a new spin on security for the enterprise. We have an army of vetted security researchers out there and hacker clients on a bounty basis for pretty crazy payouts in my opinion. So if you have spare cycles and you want to make some money, join our red team. If you guys are concerned about security in your enterprise, come talk to us as well. But anyway, a little introduction here. Why am I doing this? I wanted to try something new and I was pretty frustrated with kind of the lack of diversity in the talks lately. Satellites are kind of the ultimate hack. And there seems to be one of the satellite hacking talk just about every year. But often they're kind of theoretical. So I wanted to try to do something a little bit more concrete. So I've been doing a lot of location based privacy research at SINAC. And so location monitoring satellite seemed like a good fit. Bottom line, I want to take a stab at something different and hopefully inspire some collaboration on future research in this unexplored area. And I'll be releasing some tools after the talk. So hopefully we can collaborate a little bit. So what are we going to learn? We're going to talk a little bit about RF signals and modulation, about what is spread spectrum. We're going to select a target and reverse engineer it and hopefully exploit it if everything goes well. And the goal of my research here is kind of do it for less than $1,000. I started as kind of a side project. I wanted to do it on the cheap. So hopefully you guys will be able to do it too. There's quite a bit of material to cover as they mentioned but I'll zip through it. Slabs will be online. If you guys need to look at it later, you can email me, whatever. All right. So prerequisites. My intent is to keep it pretty high level at first but with enough detail to get you guys started, really all you're going to need is a high school mathematical knowledge to start taking a look at the stuff. So for you guys that came to Patrick and my talk last year, you know we like to define some key terms up front. So here we have the term, the Vegas interpretation and then it's hacker meaning. So here for a chip, it's a pulse of a spread spectrum code, not a poker chip. Coverage, you know we're not referring to the size of your bikini. It's the area in which the satellite service is available. Recovery, I'm sure you guys are recovering this morning. But we'll be recovering the unknown PN code, spreading code from the signals. And bent pipe, it's not a normal pipe. It refers to a type of satellite system that repeats the data when it's sent up, it comes right back down. And then sampling, I'm sure you guys did a lot of sampling last night. But we're just going to be recording a signal digitally. So targeting, how do we choose our target? And there's a lot of potential targets out there. This doesn't even cover them all. But picking the right one was key. Do we go commercial, do we go military? Bottom line, the technology needed to be consumer accessible and cheap. We're just going to do this as a side project. But I wanted something that would be popular and have a really high impact. You want any vulnerabilities we find to be worthwhile. So as familiar with global stars spot line of consumer products, I use them when I'm backpacking. And personally, I think they're pretty great. They make asset trackers for tracking your car or yacht. And personal locator beacons to call for help when you're lost out in the wild. Or your ship sinking at sea or something like that. So I started looking deeper into the tech. And it turns out that the commercial offerings use the technology as the consumer tech. So basically you can buy a $50 dirt cheap consumer device for research and the research would translate directly to all the enterprise devices out there. Not to mention anything found is going to be high impact because it's pretty widely deployed. So where is this technology used? Really it's used everywhere. It's designed to be integrated anywhere you need low bandwidth off the grid communication. Most interestingly, it's heavily used in SCADA systems, big gas and oil operations, military, and predominantly asset tracking. Shipping containers, armored cars, expensive things. So all this tech operates on what's called the simplex data service. And how does that work? In the case of asset trackers, devices can also send back arbitrary information as well. The tracker gets a location from GPS satellites and then it beams that data and some other metadata up to the global star satellites. And that simply repeats the data back down into the global star ground station which interprets the data packets and forwards the data on over the internet to global stars back in infrastructure or to the customer infrastructure for processing. I kind of liken this to think of it as SMS for the satellite world, just really small, concise messages. So the global star system is a series of low earth orbit bent pipe satellites. And the way a bent pipe satellite works is that whatever signal goes up, simply repeats it, ships it to a different frequency and sends it right back down to be received by the ground stations. And this keeps the cost of the satellite low and future usability really flexible. But notice the data link is one direction, simplex, the simplex data network. So how the heck is that reliable? Well, it turns out that each data packet is sent multiple times to ensure successful transmission. So what's the deal with these ground stations? Turns out there's hundreds of them all around the globe and they handle the reception of the satellite data. There's also two main control centers, one's in San Jose, California, I forget where the other one is, but they're in charge of operating the actual satellites and positioning them and such. So here's the coverage map from global stars website. You can see that there's patches with no coverage out in the ocean, down in Antarctica. And that's because there's no ground station there to submit, to receive the data from the satellite. Each ground station provides up to a couple thousand mile window radius for reception. So you can see down in South Africa there's this nice blob down there. They actually just added this one maybe a couple months ago to get coverage down there. So before I start working, I always like to do a little bit of groundwork just to get the idea of a client's general security posture. So I had a look at their website and I was having issues signing up for an account and logging in. I tried to log in and it looks to me like a little sequel injection. So I'm getting that warm, fuzzy hacker feeling. This is going to be a fun target to hack on. And so as I'm digging a little deeper, it turns out the data from the ground stations appears to be forward to clients over FTP and HTTP. Yeah, there's no S on there. So maybe it just be easier to sniff this data over the internet, but we're going to try to do it over the air just for the hell of it. So things are looking pretty good in general and there's some sort of bug. So let's dig deeper into the actual satellite system itself. But where do we look for information on global stars hardware? Of course Google, you know, I think we all do it. But the SEC database turned out to be like the best wealth of information. If you have a RF transmitting device in the U.S., you need to register with the SEC to make sure you're not stepping on anyone's toes. There are a lot of academic papers on global stars as well. And I found a lot of integrator spec sheets, you know, company proprietary information that was just kind of left out there. So that helped a lot. But I wanted to make sure someone else hadn't already broke the system. So I looked for some prior research. It turns out Travis Goodspeed looked at the blue-tooth protocol of one of global stars devices a while back. Really cool research. And then Natrium 42, some guy on the internet maybe is here, looked at the GPS to microcontroller interface on board an old spot personal locator beacon. But I wanted to dive deeper. This was all great research. But it didn't really deal with the device to satellite communications. So again, looking at the SEC database, a chip called the STX3 kept coming up and being referenced. Turns out it's one of the transmitters used by the Simplex data network. And it was designed for integrators to put in their creations. It's low cost, low power. And you can see it's wicked tiny. That's the chip itself that talks to the satellite. So there are some nice diagrams that came with this chip. And on the diagrams, I kept seeing this DSSS and BPSK coming up. We'll talk about that in more than a minute. I had no idea what it was at the time. But it turns out to be pretty critical to what we're doing. So the SEC databases, they also came up with global stars various frequency ranges as well as the specific range for the global star Simplex data network which we need to know. In this case, the devices were looking at operating around 1.6 figurehertz in frequency. So I kept digging and I found this leaked manufacturer spec sheet from a company called Axon. They used to make transmitter chips for the global star Simplex data network. And I referenced all these parameters that I couldn't help feel like were important but I had no idea what they were. So of note, let's see what it says here. We see that DSSS again and something called a 255 chip PN sequence at a rate of 1.25 megachips per second. And then a reference to a data rate of 100.4 bits per second. After a little reading, it turns out these are parameters for a certain type of spread spectrum modulation. But we'll talk about that more in a minute. So before we talk about spread spectrum, we need to have a basic review of waves and modulation for those that aren't familiar. So remember that radio signals are transmitted on radio waves. And data is encoded on waves by modulating various parameters of that wave. Remember that waves have three main characteristics that we can modify. They have the wavelength essentially the frequency, how many cycles per second the wave moves. And the phase, the position of the wave relative to a fixed point. As well as the amplitude, you know, essentially the height of the wave. And we can look at waves in a few different ways. You guys are probably familiar with the time domain representation of a wave. Where time is on the x-axis and amplitude is on the y-axis. But often we're working with signals, when we're working with signals, we look at the frequency domain representation. Where frequency is on the x-axis and amplitude is on the y-axis. So essentially this shows us what frequency components make up a signal. If you looked at the frequency domain representation of, you know, let's say 100 kilohertz sine wave on this representation, it would show a sharp spike at 100 kilohertz on the frequency domain graph. But oftentimes signals may contain other frequency components. So this is kind of a very unique look for different types of signals we're looking at. So let's start and see kind of how analog modulation is done and we'll move on from there. But we're going to look at both AM and FM, both of which you guys probably use on a regular basis in your car radios. So to send an analog AM signal, essentially you have a carrier wave at the desired frequency you want to transmit on. And then you vary the amplitude of this frequency according to data, the modulating signal. And the resulting signal is what gets sent out over the air and transmits whatever. Notice how we varied one parameter, in this case the amplitude, to send the data over the air. And instead of modulating the carrier analogly, we could have simply varied it between two different amplitudes to encode a digital data signal instead. And then sending a digital data signal over AM is often called OOK for on-off-king or ASK for amplitude shift-king. So we can do the same thing to frequency modulate data except we vary the carrier frequency according to the modulating signal instead of the amplitude. So again we could have shifted it between two distinct frequencies to encode digital data on this wave. And the method of encoding digital data on a frequency modulator wave is called FSK for frequency shift-king. So as we talked about, digital AM is ASK or OOK and digital FM is called FSK. But we can also vary the third parameter, the phase. And a manner that's called phase shift-king. And so we can do this to encode digital data on a wave. So for this talk we're going to focus on BPSK. Remember we saw that earlier in that tech doc. It stands for binary phase shift-king. Basically it's alternating a wave 180 degrees in and out of phase in order to encode binary data on this wave. And a 180 degree phase shift is simply achieved by flipping the wave upside down or just multiplying it by negative one. So here each cycle of the wave corresponds to one symbol, a bit in this case. OK. So I know it's kind of brief but we have the necessary knowledge on how signals are modulated. So let's go one step deeper and talk about what is spread spectrum. Spread spectrum is basically a way to take a narrow band signal, one that doesn't take up too much bandwidth to transmit. And it spreads it out over a much, much, much wider frequency range. And this gives it the ability to be much more jam resistant and introduces a property called processing gain. And essentially this processing gain, the more you spread the signal, the more gain you get at the receiving end. Essentially you can transmit further. The processing gain actually allows for a spread spectrum signal to be received even if it's below the noise floor at the receiving point. Spreading signal also allows for what's called CDMA properties. This stands for code division multiple access. You've probably heard about it in reference to your cell phones. What this means is that multiple devices can transmit on the same frequency at the same time and all the data can still get through. And this is achieved through the use of each device having a unique what we call spreading code. Remember we saw something in the tech doc called a PN sequence or a PN code. This is the same thing. And then there's two types of spread spectrum. DSSS and FHSS. And the difference is that the D-TRIPLE-S operates around one frequency as shown there on the left. Whereas the FHSS hops between multiple frequencies so as you can see on the four peaks on the right. But for the sake of this talk we're just going to focus on D-TRIPLE-S as that was what was referenced in the doc. So to create a DSSS signal in this case a relatively slow BPSK signal in the case of these transmitters 100 bit per second signal is mixed with a very, very, very fast pseudo random signal, the PN sequence. And the resulting signal contains all the original information but is spread out over a much larger bandwidth. So here you can see the data, the data BPSK signal is then spread to 1.25 megahertz. That's 12,500 times wider. Notice the shape of the wave forms are very similar in these two. This is going to be important later. So here's a more concrete example. Our data signal is just zero and one modulated very slowly. Our pseudo random sequence is a binary signal that changes much, much faster. The higher frequency shown there in green. And we mix those two signals together to get a resulting signal with a much higher frequency components you see there in the red. But how do we recover the data? You simply mix the output signal with the pseudo random signal one more time and the original data falls right back out. And so that's how this whole DSSS thing works. So now we talked about these PN sequences briefly. Basically all they are is that they're periodic binary codes that have strong auto correlation properties. Meaning that they're a binary sequence that repeats over and over and over. And just as an interesting piece of information if you guys end up trying something at home, they're commonly generated using linear feedback shift registers. So for this research we're going to look at a specific type of PN sequence called an M sequence. Again we saw that in the original spec doc. And what's interesting about them is that they correlate strongly with themselves at a phase shift of zero, very, very, very poorly at any other phase shift. So let's take a look. Up there on the left we're comparing a very short M sequence, zero, zero, zero, one. And we're comparing it to itself. And at a phase shift of zero, as a perfect correlation of four. If we shift it once to the left, the correlation goes to zero and stays at zero until we bring it back into phase. This is nice because it makes searching for this PN sequence in any other signal very easy. We just look for it using correlation. So this spread spectrum stuff is simple in theory but it's really more difficult in practice. You know, in theory you simply mix the signal being received with the appropriate PN sequence and the signal will emerge. But in a perfect world, our transmitter and receiver are going to have, they're going to be tuned, not going to be tuned to the exact same frequency. So we need to accommodate for this frequency differential somehow. Also remember that if the PN is not properly aligned with itself and incoming data, it won't work. You'll just get a garbage signal out. So we need a way to phase align the PN sequences. So keep thinking how we might do that and it uses those auto correlation properties we talked about just a second ago. All right. So we've kind of got a little rough idea of the theory but now to put it into practice we need to actually build some hardware and do something. So do this. I use software, software to find radio along with Python and GNU radio to write on my code. And I also needed an appropriate antenna that I ended up getting off of eBay. And so for those that wish try this at home, just know that global star antennas are left hand circular polarized. It's a specific type of antenna that you'll need to look up. But that's a little bit out of the scope of the stock. And for those of you who are familiar with RTL, SDR, you know, the really cheap software to find radio dongle, unfortunately you won't be able to use it for this. It doesn't cover enough bandwidth. So I use the USRP B200, great board, you get it for about 600 bucks. And I think, you know, a lot of the other SDRs in the market work just fine. So we also needed a low noise amplifier for receiving some weak signals and supporting the cable and voltage regulators to supply it. I got this LNA off of a company called Mini Circuits. It was, what, 150 bucks. So not too bad. So at this point, you know, I packaged it all up into a box because these things are pretty fragile and hackers are clumsy or I'm clumsy and I didn't really want to break the hardware. So anyway, I mounted the antenna on the outside of the box so we can take this thing places and aim it at things. I had it up in my black hat hotel room, aiming it over at McCarran and sniffing up data from the hardware. So we'll get to try that out. All right. So how does this hardware work? Essentially, the software defined radio, it listens for radio waves which are analog coming in and it converts them to digital data that our computer can process and does this by taking samples of the wave. So this guy named Nyquist back in the day came up to the realization that while sampling, you need to sample it at least twice as fast as a signal's highest frequency in order to accurately reproduce the signal while sampling. A real world example is that the human ear can't hear frequencies higher than 20 kilohertz. And if you recall, CD audio, you know, if you guys still use CDs, is sampled at 44.1 kilohertz. That's just over twice the human frequency hearing range. So you should also know that software defined radio hardware uses what's called IQ sampling or modulation to receive and send these signals. This topic is a little too much to get into for now, but I know that for each sampled data we can, two values are recorded. The I, the in phase value, and the Q, the quadrature value. And using this IQ modulation has strong benefits for processing signals and software. But if you're interested, I suggest you check out this YouTube video. It does a really, really good job explaining, much better than I'll be able to do. But bottom line, you don't need to understand this unless you're going to try this research at home. So the first step to decoding satellite transmissions is to figure out that PN sequence so we can extract the data from the waves. So let's put our hardware to work. So remember that we're looking for a signal, the PN sequence, that is 255 bits in length. It repeats over and over and over and over again. And it repeats at a rate of 1.25 million chips per second. Here I should mention that a chip is the same thing as a bit. We just name it differently so we can distinguish it from actual data bits. So now interestingly enough, we can treat a D, triple S spread spectrum, BPSK signal, the same as we treat BPSK. So check out this graph. It's kind of hard to show. But we can see that the BPSK signal above shifts the wave at its transition, but once every several wave cycles. The DSSS BPSK signal shifts the wave much, much, much faster, but in the same way as the BPSK signal. So this means that we can use an ordinary BPSK demodulator to receive the spread data. Now the downside of doing this is that receiving the data this way is that we don't receive any of the processing gain benefit we talked about from spreading a signal. So this technique only works over really short distances. But it's perfectly legitimate. So I was able to do this across the room, maybe 100 feet away. So to accurately receive the data, we need to set our hardware to sample the data correctly. And we have to meet a few different criteria. First, the USRP, the Cithoff-Rodify radio I use, can only sample at multiples of 32 megahertz. We also need to sample twice as fast as the highest frequency component. And in this case, that's the PN sequence in the signal, 1.25 megahertz due to what Nyquist had to say. We also need to sample at a rate that provides an even number of samples per symbol. In this case, an even number of samples per chip. So we achieve all this by sampling at a rate of 4 megahertz and then re-sampling the signal, essentially just interpolating data points along it to get an up-sampled signal of 5 megahertz. And what's special about this 5 megahertz signal is that it has a sampling rate that corresponds to 4 samples per symbol, which is an even number. But now how do we get the actual PN sequence out of this data we're going to see over there? Well, we know from doing some calculations that the PN sequence repeats 49 times for each bit of data that's sent. And since the PN sequence doesn't cross any bit boundaries, we can simply XOR the PN sequence with a fixed bit of data, you know, the first bit of data, and the resultant is the actual PN code. So let's use GNU radio to decode the signal as BPSK and appropriate, and then it'll output the appropriate data to disk. So here you can see a GNU radio flow graph. I used to do this. And you can see the PSK demodulator has the setting of 4 samples per symbol from our calculations. So the PSK demodulator outputs the decoded symbols to a binary file that we'll then examine in a hex editor. So if you look at the data in the hex editor, we can clearly see that there's a repeating sequence of data, 255 bits long. It's starting to sound kind of familiar. Well, it turns out that repeating sequence of data is the PN code. And it turns out this is pretty much the keys of the kingdom for intercepting all this data. This code is used by all simplex data network devices to encode the data center over the air. So now that we have the code, let's try de-spreading some data. You may recall that we need to mix the PN code with incoming signal to receive the information. And if all goes well, we should expect our output signal to contain a very strong narrow band signal shown as a sharp peak down in that graph below. So above is what the normal simplex data network signal looks like, kind of that lumpy thing. And the graphic below shows what we should see after we de-spread the data, just a nice sharp spike in there. So now before we begin, it's important to know that working with these signals is a very computationally intense procedure. Receiving a signal at 4 megahertz with a software defined radio works out to a data rate of about 30.5 megabytes per second. So for the purposes of this work, we're going to record the data and post-process later. But eventually it will be possible to use more robust custom hardware, you know, think FPGAs to do this work in real time. But that sounds like a pain in the butt, so we're just going to record and do it later. So big thanks to some of my interns over there for helping me optimize this code. It used to take about a minute to run. Now it takes about like 40 seconds. But all right, so how do we de-spread the data? First we need to lock on to the mix PN sequencing the signal. And we do this by correlating the received data signal against the recovered PN at every single point in time. So essentially we're sliding the PN against the received data signal and correlating. And if we plot the correlations over time, when the PN is perfectly aligned, we'll see a sharp spike in the correlation. And that's what you're seeing up there. So this is how we know when to mix the two signals together to de-spread the data. So if we align the PN on the first correlation spike only due to some frequency mismatch, we'll fall out of correlation over time as shown there on the left. So we fix this by adjusting the PN forward or backward at each and every correlation peak to ensure its alignment. At this point, once we're in alignment, we simply mix the data together and the signal should fall out. So let's try that. So after compensating for the frequency differential there, you can see on the left that the correlation over time stays pretty constant with a slight oscillation, but that's okay. And if we zoom in or zoom out really far, we can see the correlation is over a whole data packet. And you can see the negative and positive correlations representing actual data bits flying over the air. So if you look at the signal coming out of our software to spreader, sure enough we see that sharp spike in the center indicative of our signal in question. This means we de-spread our data successfully, theoretically. So zooming way in on that sharp peak, we can see that the waveform looks like a BPSK signal. It's operating at around 100 hertz and we know that that's the data rate in question that we're looking for. So things are looking pretty promising. All right. So now that we're maybe receiving data, let's try to decode it like what's inside. So if you look at the time domain representation of the signal, you can clearly see there's actual data bits coming over there. So that's satellite data. So now let's click up the signal and do something with it. Namely, we just low pass filter it and pipe it into a PSK demodulator. So at that point, the data pretty much just falls right out. You can see at the top, I got this nice binary string out of that data. But we need to validate it. So I found a spec sheet on line that references the data packet format, which is shown right up there. And it starts with a preamble, essentially a constant, unique binary sequence that tells the receiver when the packet is starting. And then it's followed by a manufacturer ID as well as a bunch more data. So if we convert that manufacturer ID set of bits to decimal, sure enough, it lines up with the ESN written on the back of the device. So I'm pretty sure that means we're doing something right. So now the data packets also contain just about any information you want. And this is kind of up to the end integrator. But these devices predominantly are used to send location data in asset trackers. So everyone uses the same data format. So it can be ingested the same on the back end. So after extensive comparison, again, with some help of the interns, we free out the bits 8 to 32 are latitude and 32 to 56 are longitude. You simply convert those binary bits to decimal and multiply it by a degrees per count value. And that will give you the actual latitude and longitude. So I've kind of got a snippet of the code there. It will be online later if you guys want to kind of craft your own packets. We'll talk more about that. So the data packets also contain a checksum. Long story short, we figured out how to calculate the checksum. But this means not only can we validate packets, we should be able to create our own. And from what we saw, the comparison and the devices we looked at, there was no encryption, no signing, or no other protection. So theoretically we can inject our own data back into the satellite network. So now recall that we're doing all this reception here on the data uplink from the device to the satellite. But due to the bent pipe nature of the global star satellites, the data in the downlink is exactly the same as the data on the uplink. So except we just need to compensate for a few other things like Doppler shift and multi-path interference. So this is a kind of avenue for future research if you guys are interested in helping out. But essentially with a bigger dish, a little better hardware, we can start receiving a ton more data doing the same method. But all right, so now we figured out these data packets, you know, can we inject it back into the network? So warning, seriously, don't transmit on global star frequencies. It's probably illegal where you live and it might interfere with critical emergency communications. Fortunately, the simplex frequencies aren't used for satellite control per se. So it's not like you're going to make it fly sideways or anything. But if you wanted to transmit, that's actually the easy part. So don't try this at home, wink, wink. So all you do is really, you simply mix the data together with the PN sequence and the carrier, all of the appropriate rates which are listed here in this talk. I'm not going to be providing my code that I designed, but if you're savvy enough you should be able to do it. But really all you need is about.2 watts of power. And you can write the code and get new radio. It's pretty simple. But what if there was an easier way? Well, global star provides an OSX firmware update utility for one of their spot trace devices, their personal asset trackers. Inside the application package there's a tool, spot3firmwaretool.jar, and it contains all sorts of interesting functionality that's never called by the actual firmware app. So if you look in the jar, there's a debug console class which references something in the spot device class called write ESN, electronic serial number. So what if we wrote a Java app to call that debug console? Sure enough, hidden functionality right there in the software on their website. The debug console essentially lets us update the ESN of any of these spot trace devices out there. So we can change the serial number of any of these devices, and we can actually clone it. So to prove this, I cloned one of my spot trackers with the other ESN and told it to transmit. And sure enough, I got a tracking email back that confirmed, yeah, we were able to clone the device. So for 50 bucks, you can clone satellite network devices and maybe spoof some coordinates and shenanigans. But besides the obvious of using the network to transmit your own custom data or expanding capabilities of your service, sending more packets than you're allowed to per hour, what can we do with the data transmission capability? Can we get in a little bit more trouble? So first, these devices are used very commonly in emergency response. So once in a while, I thought what if an attacker spoofed thousands of false emergencies using these devices and jammed up the emergency response center preventing aid from getting to an actual emergency? Or what about monitoring help requests from these devices and then just cancelling the help request? It's kind of a dick move, but someone might do it. So I talked to a really, really well-known reporter a couple of days ago, and she used to work out in the Middle East as a correspondent for about 10 years. And she said that many of the journalists out there use these spot devices to track their whereabouts in case they're kidnapped. So they're relying on these devices so people know where they are. So what if a foreign adversary was sniffing up this data and then arresting our reporters or people are using these for their safety? That's not cool. So it turns out these chips are also used in access control systems by law enforcement and even for animal tracking. So I think it would be hilarious to say that a wild grizzly had relocated itself into suburban California and see what all the moms say. But I also forgot to mention that they're used heavily in SCADA systems. I'm going to refrain from specifics because I know you guys are a bunch of hooligans and we'll probably get in some trouble. But they're commonly used in water quality sensors, pipeline monitoring, and a lot of big oil and gas operations. So I was thinking, what if there's a big rival oil company that wanted to figure out where its competitor was drilling? Well, why not just fire up your own base station and just have a look for yourself? But wait, there's more. Lockheed Martin Flight Services, the contractor that handles flight planning for the FAA, allows these devices, these spot devices to be used to track any VFR flight. So what if an attacker made an airplane appear to deviate from its original flight plan into tightly controlled airspace? You know, I obviously haven't tried this, but it would be interesting to see what happened. So to demonstrate some of this, I built a little capability, which I'm going to talk a little bit about. And the way it works is that I sit with the device in the uplink path of the transmitter and listen. So this is what I was doing in my hotel room a couple nights ago. And over time, I'm able to pick up countless transmissions from Assist trackers and map their patterns of life. I did some research a year ago at Shmucon talking about mapping patterns of life from mobile vulnerability location tracking. And you know, we were able to monitor users over a fixed period of time and figure out where's home, where's work, just by where they are at different times of the day. So pattern of life is really key to tracking somebody. And this makes it really easy to identify what a rocket is and where it goes. In this case, we're going to monitor an armored car route. Now that I know where the armored car is, I know where to hijack it. And I can hijack the car, disable its beacon and begin spoofing their beacon's ID with my transmitter and spoof GPS coordinates that the armored car is on route. When in reality, I'm driving it somewhere else and robbing the bank blind. So you know, think fast and nefarious. So you might ask, does this work? Short answer is yes. But I needed a high vantage point. So clearly the only solution was to go out and start working on my private pilot license so I could intercept the data from the air. So I've been flying with this thing. We're going to see where it keeps going. But the results are pretty promising so far. So I'm going to do a little demo, show you guys a little bit up close how this works. I decided to not tempt the live demo gods today. But I've broken up the video kind of step by step so we can kind of talk about it. So bear with me here while I fire up the video. Is that up there? Full screen? I can't. Perfect. So okay, so we're going to wait for a data signal from an attacker or someone to transmit. So the attacker is intercepting the data right there. And so we've captured the data, it writes the data out to disk. And then we're going to throw that data in our despreading Python program here. And I've kind of cropped the video because it takes about a minute to analyze the data packet. And okay, so it locks onto the PN signal in the signal and starts despreading. And it'll finish up here. And then we can see that's a pretty constant correlation over time. That's what we're looking for. So that means we locked onto the PN signal successfully. Then we're going to throw that back into some radio code to kind of visualize what we got. And you're going to be able to see that sharp peak in the middle. And we're going to zoom in up there and see the live data bits flying by. And then meanwhile this is writing those data bits out to disk for us to analyze. And then we're going to go ahead and analyze those data bits. We should get the binary packet data out if all goes well. So there's the binary of the packet. Now let's throw that into the packet decoder and verify it. We can successfully validate a packet and print out its parameters. So this code will all be online as well as some more to dive into the actual user specific data and translate that into a latitude and longitude. Let's go back to the presentation. All right. So a couple of conclusions. A few parting thoughts for you guys. I disclosed to global stars senior engineering staff about 180 days ago. And they were actually really friendly in the response and seemed very concerned. I get the impression they don't deal with a lot of these disclosures. It's not very typical. So I provided an in-depth technical detail write up for them hoping and hopes of helping out and never really heard back. After the news broke recently they issued a statement saying they take privacy very seriously and they are monitoring in place to detect these sort of attacks. Unfortunately half of this attack is passive and there's no way that can be detected. And the transmitting portion if targeted really has a low probability of being detected. So in some of the recent statements global stars seem quite defensive. I tend to get upset or find that upset when manufacturers get this way rather than addressing the actual issue at hand. In my experience these vulnerabilities are always discovered one way or another. It's better to get them addressed sooner than later. Last year I disclosed a bug to Grindr about being able to track their users through the mobile dating app and they said it wasn't an issue and didn't patch it. Six months later the Egyptian police got a hold of that bug through other channels and began using it to arrest gay men in Egypt. So I really hate for these vulnerabilities to be used for bad and I'd rather see that these get patched and we're able to make these systems a lot safer for the end users. So I sincerely hope the global star is serious about their statement addressing these issues and I hope other manufacturers are paying attention as well. But I'm really looking forward to seeing the solutions or seeing what solutions come out of the community. Bottom line there's still a lot of work to be done. I'm releasing my code on GitHub later. Apologies I don't have it up yet. It's been kind of crazy here at the conference. Parties and things. But it will be up soon. And I would love to collaborate on improving this whole system. Maybe intercepting data on the downlink. So if you guys are interested let's work on this together. I have a feeling we're only at the tip of the iceberg of seeing where this thing is used. So we're going to start seeing a lot of interesting things fall out. So if you're interested help out. In conclusion I still believe global star makes a good product. But there's a couple of takeaways. Remember that the air space products and satellites and airplanes they have a long life cycle and we're kind of stuck with them for years to come. And the way the global star system is implemented it's not really patchable or easily patchable. A lot of devices don't support firmware upgrades. They're so far out in the boonies that it's not realistic. So the best thing to do going forward is to add a layer of encryption on top of this existing protocol. And remember that obscurity is not security. It's a spectrum of low and low and protect your data. And consumers just assume someone can snoop on your data and act accordingly. I think we hear this a lot. And hold manufacturers to a higher standard. Demand security and if not demand to know how your data is being transmitted and is it encrypted? If not how so? So big thanks to the interns over there for helping out with testing and code optimization. Yeah. Thanks guys. And then to SINAC as well for funding this different crazy research. But yeah, the call will be live later. Hit me up if it doesn't come up. But feel free to email me, tweet me. I know this is a lot to cover. I'm always happy to talk. So thanks for coming out. Questions, comments? We got five minutes. Can we use the bent pipe to tunnel information or like, you know, from one location to another sneak in some information? Yeah, can we use the bent pipe to send other information? That's a great question and you certainly can. I don't recommend it. But there's nothing, I mean, someone probably is. You have to speculate. But yeah, it really repeats anything that hears on that 1.6 gigahertz range and beams it back down on about 7 gigahertz so you can build your own receiver and use your own personal satellite network. So like, does it need to be on a particular protocol or like a packet structure or like it transmits anything that it receives? I'm sorry, I missed that. Like, does it need to be encoded in a specific format? So the data can really be in any format. The bent pipe doesn't do any interpretation. It's a repeater. So you could, it probably needs to be some sort of spread spectrum in order to get it over that distance. But you could use a model very similar to what they're doing here. Thank you. Anyone else? Feel free to come up after. Cool, thanks guys. Appreciate it. Thank you. Thank you.
 All right, as I said, welcome to track one. This is the one o'clock talk as you well know.  We have Colby Moore. He's going to talk about satcom hacking. He reportedly found some  vulnerabilities and some satellites. So he's going to talk about that. This is a rerun  of his talk that he gave at Black Hat. So please help me welcome Colby Moore.  Thanks, guys. Good afternoon, DEF CON. Thanks for coming out. So today we're going to talk  about spread spectrum signals and hacking the global star simplex data service. But first,  who am I? I'm a mechanical engineer that loves computer security. I'm currently working at  SINAC on the R&D team. I got interested in satellites and radios a long time ago when I got  my ham radio license. And yes, ladies, that's my call sign. So radio me. I'm single. So what is  this company SINAC that I work for? Basically we're a new spin on security for the enterprise.  We have an army of vetted security researchers out there and hacker clients on a bounty basis for  pretty crazy payouts in my opinion. So if you have spare cycles and you want to make some money,  join our red team. If you guys are concerned about security in your enterprise, come talk to us as  well. But anyway, a little introduction here. Why am I doing this? I wanted to try something new  and I was pretty frustrated with kind of the lack of diversity in the talks lately. Satellites are  kind of the ultimate hack. And there seems to be one of the satellite hacking talk just about  every year. But often they're kind of theoretical. So I wanted to try to do something a little bit  more concrete. So I've been doing a lot of location based privacy research at SINAC. And so  location monitoring satellite seemed like a good fit. Bottom line, I want to take a stab at  something different and hopefully inspire some collaboration on future research in this unexplored  area. And I'll be releasing some tools after the talk. So hopefully we can collaborate a little  bit. So what are we going to learn? We're going to talk a little bit about RF signals and  modulation, about what is spread spectrum. We're going to select a target and reverse engineer it  and hopefully exploit it if everything goes well. And the goal of my research here is kind of do  it for less than $1,000. I started as kind of a side project. I wanted to do it on the cheap. So  hopefully you guys will be able to do it too. There's quite a bit of material to cover as they  mentioned but I'll zip through it. Slabs will be online. If you guys need to look at it later, you  can email me, whatever. All right. So prerequisites. My intent is to keep it pretty high  level at first but with enough detail to get you guys started, really all you're going to need is a  high school mathematical knowledge to start taking a look at the stuff. So for you guys that came to  Patrick and my talk last year, you know we like to define some key terms up front. So here we have  the term, the Vegas interpretation and then it's hacker meaning. So here for a chip, it's a pulse of a  spread spectrum code, not a poker chip. Coverage, you know we're not referring to the size of your  bikini. It's the area in which the satellite service is available. Recovery, I'm sure you guys are  recovering this morning. But we'll be recovering the unknown PN code, spreading code from the  signals. And bent pipe, it's not a normal pipe. It refers to a type of satellite system that  repeats the data when it's sent up, it comes right back down. And then sampling, I'm sure you guys did  a lot of sampling last night. But we're just going to be recording a signal digitally. So  targeting, how do we choose our target? And there's a lot of potential targets out there. This  doesn't even cover them all. But picking the right one was key. Do we go commercial, do we go  military? Bottom line, the technology needed to be consumer accessible and cheap. We're just going to  do this as a side project. But I wanted something that would be popular and have a really high  impact. You want any vulnerabilities we find to be worthwhile. So as familiar with global stars  spot line of consumer products, I use them when I'm backpacking. And personally, I think they're  pretty great. They make asset trackers for tracking your car or yacht. And personal locator beacons to  call for help when you're lost out in the wild. Or your ship sinking at sea or something like that.  So I started looking deeper into the tech. And it turns out that the commercial offerings use the  technology as the consumer tech. So basically you can buy a $50 dirt cheap consumer device for  research and the research would translate directly to all the enterprise devices out there. Not to  mention anything found is going to be high impact because it's pretty widely deployed. So where is  this technology used? Really it's used everywhere. It's designed to be integrated anywhere you need  low bandwidth off the grid communication. Most interestingly, it's heavily used in SCADA systems,  big gas and oil operations, military, and predominantly asset tracking. Shipping containers,  armored cars, expensive things. So all this tech operates on what's called the simplex data  service. And how does that work? In the case of asset trackers, devices can also send back  arbitrary information as well. The tracker gets a location from GPS satellites and then it beams  that data and some other metadata up to the global star satellites. And that simply repeats the  data back down into the global star ground station which interprets the data packets and  forwards the data on over the internet to global stars back in infrastructure or to the customer  infrastructure for processing. I kind of liken this to think of it as SMS for the satellite world,  just really small, concise messages. So the global star system is a series of low earth orbit  bent pipe satellites. And the way a bent pipe satellite works is that whatever signal goes up,  simply repeats it, ships it to a different frequency and sends it right back down to be  received by the ground stations. And this keeps the cost of the satellite low and future  usability really flexible. But notice the data link is one direction, simplex, the simplex  data network. So how the heck is that reliable? Well, it turns out that each data packet is  sent multiple times to ensure successful transmission. So what's the deal with these  ground stations? Turns out there's hundreds of them all around the globe and they handle the  reception of the satellite data. There's also two main control centers, one's in San Jose,  California, I forget where the other one is, but they're in charge of operating the actual  satellites and positioning them and such. So here's the coverage map from global stars  website. You can see that there's patches with no coverage out in the ocean, down in Antarctica.  And that's because there's no ground station there to submit, to receive the data from the  satellite. Each ground station provides up to a couple thousand mile window radius for  reception. So you can see down in South Africa there's this nice blob down there. They  actually just added this one maybe a couple months ago to get coverage down there. So  before I start working, I always like to do a little bit of groundwork just to get the idea  of a client's general security posture. So I had a look at their website and I was having issues  signing up for an account and logging in. I tried to log in and it looks to me like  a little sequel injection. So I'm getting that warm, fuzzy hacker feeling. This is going to be a  fun target to hack on. And so as I'm digging a little deeper, it turns out the data from the  ground stations appears to be forward to clients over FTP and HTTP. Yeah, there's no S on  there. So maybe it just be easier to sniff this data over the internet, but we're going to try to  do it over the air just for the hell of it. So things are looking pretty good in general  and there's some sort of bug. So let's dig deeper into the actual satellite system itself.  But where do we look for information on global stars hardware? Of course Google, you know, I  think we all do it. But the SEC database turned out to be like the best wealth of information.  If you have a RF transmitting device in the U.S., you need to register with the SEC to make sure  you're not stepping on anyone's toes. There are a lot of academic papers on global stars as  well. And I found a lot of integrator spec sheets, you know, company proprietary information that  was just kind of left out there. So that helped a lot. But I wanted to make sure someone else  hadn't already broke the system. So I looked for some prior research. It turns out Travis Goodspeed  looked at the blue-tooth protocol of one of global stars devices a while back. Really cool  research. And then Natrium 42, some guy on the internet maybe is here, looked at the GPS to  microcontroller interface on board an old spot personal locator beacon. But I wanted to dive  deeper. This was all great research. But it didn't really deal with the device to satellite  communications. So again, looking at the SEC database, a chip called the STX3 kept coming  up and being referenced. Turns out it's one of the transmitters used by the Simplex data network.  And it was designed for integrators to put in their creations. It's low cost, low power. And you  can see it's wicked tiny. That's the chip itself that talks to the satellite. So there are some nice  diagrams that came with this chip. And on the diagrams, I kept seeing this DSSS and BPSK coming  up. We'll talk about that in more than a minute. I had no idea what it was at the time. But it turns  out to be pretty critical to what we're doing. So the SEC databases, they also came up with  global stars various frequency ranges as well as the specific range for the global star Simplex  data network which we need to know. In this case, the devices were looking at operating around  1.6 figurehertz in frequency. So I kept digging and I found this leaked manufacturer spec sheet  from a company called Axon. They used to make transmitter chips for the global star Simplex  data network. And I referenced all these parameters that I couldn't help feel like were  important but I had no idea what they were. So of note, let's see what it says here. We see that  DSSS again and something called a 255 chip PN sequence at a rate of 1.25 megachips per second.  And then a reference to a data rate of 100.4 bits per second. After a little reading, it turns  out these are parameters for a certain type of spread spectrum modulation. But we'll talk about  that more in a minute. So before we talk about spread spectrum, we need to have a basic review of  waves and modulation for those that aren't familiar. So remember that radio signals are  transmitted on radio waves. And data is encoded on waves by modulating various parameters of that  wave. Remember that waves have three main characteristics that we can modify. They have the  wavelength essentially the frequency, how many cycles per second the wave moves. And the phase,  the position of the wave relative to a fixed point. As well as the amplitude, you know,  essentially the height of the wave. And we can look at waves in a few different ways. You guys  are probably familiar with the time domain representation of a wave. Where time is on the  x-axis and amplitude is on the y-axis. But often we're working with signals, when we're working  with signals, we look at the frequency domain representation. Where frequency is on the x-axis  and amplitude is on the y-axis. So essentially this shows us what frequency components make up a  signal. If you looked at the frequency domain representation of, you know, let's say 100  kilohertz sine wave on this representation, it would show a sharp spike at 100 kilohertz on the  frequency domain graph. But oftentimes signals may contain other frequency components. So this  is kind of a very unique look for different types of signals we're looking at. So let's start  and see kind of how analog modulation is done and we'll move on from there. But we're going to  look at both AM and FM, both of which you guys probably use on a regular basis in your car  radios. So to send an analog AM signal, essentially you have a carrier wave at the desired  frequency you want to transmit on. And then you vary the amplitude of this frequency according to  data, the modulating signal. And the resulting signal is what gets sent out over the air and  transmits whatever. Notice how we varied one parameter, in this case the amplitude, to send the  data over the air. And instead of modulating the carrier analogly, we could have simply  varied it between two different amplitudes to encode a digital data signal instead. And then  sending a digital data signal over AM is often called OOK for on-off-king or ASK for amplitude  shift-king. So we can do the same thing to frequency modulate data except we vary the  carrier frequency according to the modulating signal instead of the amplitude. So again we  could have shifted it between two distinct frequencies to encode digital data on this wave. And  the method of encoding digital data on a frequency modulator wave is called FSK for frequency  shift-king. So as we talked about, digital AM is ASK or OOK and digital FM is called FSK. But  we can also vary the third parameter, the phase. And a manner that's called phase shift-king.  And so we can do this to encode digital data on a wave. So for this talk we're going to focus on  BPSK. Remember we saw that earlier in that tech doc. It stands for binary phase shift-king.  Basically it's alternating a wave 180 degrees in and out of phase in order to encode binary data on  this wave. And a 180 degree phase shift is simply achieved by flipping the wave upside  down or just multiplying it by negative one. So here each cycle of the wave corresponds to one  symbol, a bit in this case. OK. So I know it's kind of brief but we have the necessary knowledge  on how signals are modulated. So let's go one step deeper and talk about what is spread  spectrum. Spread spectrum is basically a way to take a narrow band signal, one that doesn't  take up too much bandwidth to transmit. And it spreads it out over a much, much, much wider  frequency range. And this gives it the ability to be much more jam resistant and introduces a  property called processing gain. And essentially this processing gain, the more you spread the  signal, the more gain you get at the receiving end. Essentially you can transmit further. The  processing gain actually allows for a spread spectrum signal to be received even if it's below  the noise floor at the receiving point. Spreading signal also allows for what's called CDMA  properties. This stands for code division multiple access. You've probably heard about it in  reference to your cell phones. What this means is that multiple devices can transmit on the same  frequency at the same time and all the data can still get through. And this is achieved through  the use of each device having a unique what we call spreading code. Remember we saw something  in the tech doc called a PN sequence or a PN code. This is the same thing. And then there's  two types of spread spectrum. DSSS and FHSS. And the difference is that the D-TRIPLE-S  operates around one frequency as shown there on the left. Whereas the FHSS hops between  multiple frequencies so as you can see on the four peaks on the right. But for the sake of  this talk we're just going to focus on D-TRIPLE-S as that was what was referenced in the doc. So to  create a DSSS signal in this case a relatively slow BPSK signal in the case of these  transmitters 100 bit per second signal is mixed with a very, very, very fast pseudo random  signal, the PN sequence. And the resulting signal contains all the original information but is  spread out over a much larger bandwidth. So here you can see the data, the data BPSK signal is  then spread to 1.25 megahertz. That's 12,500 times wider. Notice the shape of the wave forms are  very similar in these two. This is going to be important later. So here's a more concrete  example. Our data signal is just zero and one modulated very slowly. Our pseudo random  sequence is a binary signal that changes much, much faster. The higher frequency shown there in  green. And we mix those two signals together to get a resulting signal with a much higher  frequency components you see there in the red. But how do we recover the data? You simply mix the  output signal with the pseudo random signal one more time and the original data falls right  back out. And so that's how this whole DSSS thing works. So now we talked about these PN  sequences briefly. Basically all they are is that they're periodic binary codes that have  strong auto correlation properties. Meaning that they're a binary sequence that repeats over  and over and over. And just as an interesting piece of information if you guys end up trying  something at home, they're commonly generated using linear feedback shift registers. So for this  research we're going to look at a specific type of PN sequence called an M sequence. Again we  saw that in the original spec doc. And what's interesting about them is that they correlate  strongly with themselves at a phase shift of zero, very, very, very poorly at any other phase  shift. So let's take a look. Up there on the left we're comparing a very short M sequence,  zero, zero, zero, one. And we're comparing it to itself. And at a phase shift of zero, as a  perfect correlation of four. If we shift it once to the left, the correlation goes to zero and  stays at zero until we bring it back into phase. This is nice because it makes searching for this  PN sequence in any other signal very easy. We just look for it using correlation. So this  spread spectrum stuff is simple in theory but it's really more difficult in practice. You know,  in theory you simply mix the signal being received with the appropriate PN sequence and the  signal will emerge. But in a perfect world, our transmitter and receiver are going to have,  they're going to be tuned, not going to be tuned to the exact same frequency. So we need to  accommodate for this frequency differential somehow. Also remember that if the PN is not  properly aligned with itself and incoming data, it won't work. You'll just get a garbage signal  out. So we need a way to phase align the PN sequences. So keep thinking how we might do  that and it uses those auto correlation properties we talked about just a second ago.  All right. So we've kind of got a little rough idea of the theory but now to put it into  practice we need to actually build some hardware and do something. So do this. I use software,  software to find radio along with Python and GNU radio to write on my code. And I also  needed an appropriate antenna that I ended up getting off of eBay. And so for those that wish  try this at home, just know that global star antennas are left hand circular polarized. It's  a specific type of antenna that you'll need to look up. But that's a little bit out of the  scope of the stock. And for those of you who are familiar with RTL, SDR, you know, the  really cheap software to find radio dongle, unfortunately you won't be able to use it for  this. It doesn't cover enough bandwidth. So I use the USRP B200, great board, you get it  for about 600 bucks. And I think, you know, a lot of the other SDRs in the market work just  fine. So we also needed a low noise amplifier for receiving some weak signals and supporting  the cable and voltage regulators to supply it. I got this LNA off of a company called  Mini Circuits. It was, what, 150 bucks. So not too bad. So at this point, you know, I  packaged it all up into a box because these things are pretty fragile and hackers are  clumsy or I'm clumsy and I didn't really want to break the hardware. So anyway, I mounted  the antenna on the outside of the box so we can take this thing places and aim it at things.  I had it up in my black hat hotel room, aiming it over at McCarran and sniffing up data from  the hardware. So we'll get to try that out. All right. So how does this hardware work?  Essentially, the software defined radio, it listens for radio waves which are analog  coming in and it converts them to digital data that our computer can process and does this  by taking samples of the wave. So this guy named Nyquist back in the day came up to the  realization that while sampling, you need to sample it at least twice as fast as a signal's  highest frequency in order to accurately reproduce the signal while sampling. A real world example  is that the human ear can't hear frequencies higher than 20 kilohertz. And if you recall,  CD audio, you know, if you guys still use CDs, is sampled at 44.1 kilohertz. That's just  over twice the human frequency hearing range. So you should also know that software defined  radio hardware uses what's called IQ sampling or modulation to receive and send these signals.  This topic is a little too much to get into for now, but I know that for each sampled data  we can, two values are recorded. The I, the in phase value, and the Q, the quadrature value.  And using this IQ modulation has strong benefits for processing signals and software. But if  you're interested, I suggest you check out this YouTube video. It does a really, really good  job explaining, much better than I'll be able to do. But bottom line, you don't need to understand  this unless you're going to try this research at home. So the first step to decoding satellite  transmissions is to figure out that PN sequence so we can extract the data from the waves. So  let's put our hardware to work. So remember that we're looking for a signal, the PN sequence,  that is 255 bits in length. It repeats over and over and over and over again. And it repeats  at a rate of 1.25 million chips per second. Here I should mention that a chip is the same  thing as a bit. We just name it differently so we can distinguish it from actual data bits.  So now interestingly enough, we can treat a D, triple S spread spectrum, BPSK signal, the same  as we treat BPSK. So check out this graph. It's kind of hard to show. But we can see that the  BPSK signal above shifts the wave at its transition, but once every several wave cycles. The  DSSS BPSK signal shifts the wave much, much, much faster, but in the same way as the BPSK  signal. So this means that we can use an ordinary BPSK demodulator to receive the spread  data. Now the downside of doing this is that receiving the data this way is that we don't  receive any of the processing gain benefit we talked about from spreading a signal. So this  technique only works over really short distances. But it's perfectly legitimate. So I was  able to do this across the room, maybe 100 feet away. So to accurately receive the data, we  need to set our hardware to sample the data correctly. And we have to meet a few different  criteria. First, the USRP, the Cithoff-Rodify radio I use, can only sample at multiples of  32 megahertz. We also need to sample twice as fast as the highest frequency component. And in  this case, that's the PN sequence in the signal, 1.25 megahertz due to what Nyquist had to  say. We also need to sample at a rate that provides an even number of samples per symbol. In  this case, an even number of samples per chip. So we achieve all this by sampling at a rate of  4 megahertz and then re-sampling the signal, essentially just interpolating data points  along it to get an up-sampled signal of 5 megahertz. And what's special about this 5 megahertz  signal is that it has a sampling rate that corresponds to 4 samples per symbol, which is an  even number. But now how do we get the actual PN sequence out of this data we're going to see  over there? Well, we know from doing some calculations that the PN sequence repeats 49  times for each bit of data that's sent. And since the PN sequence doesn't cross any bit  boundaries, we can simply XOR the PN sequence with a fixed bit of data, you know, the first bit  of data, and the resultant is the actual PN code. So let's use GNU radio to decode the  signal as BPSK and appropriate, and then it'll output the appropriate data to disk. So here  you can see a GNU radio flow graph. I used to do this. And you can see the PSK demodulator has  the setting of 4 samples per symbol from our calculations. So the PSK demodulator outputs the  decoded symbols to a binary file that we'll then examine in a hex editor. So if you look at the  data in the hex editor, we can clearly see that there's a repeating sequence of data, 255 bits  long. It's starting to sound kind of familiar. Well, it turns out that repeating sequence of  data is the PN code. And it turns out this is pretty much the keys of the kingdom for  intercepting all this data. This code is used by all simplex data network devices to encode the  data center over the air. So now that we have the code, let's try de-spreading some data. You  may recall that we need to mix the PN code with incoming signal to receive the information.  And if all goes well, we should expect our output signal to contain a very strong narrow band  signal shown as a sharp peak down in that graph below. So above is what the normal simplex data  network signal looks like, kind of that lumpy thing. And the graphic below shows what we should  see after we de-spread the data, just a nice sharp spike in there. So now before we begin, it's  important to know that working with these signals is a very computationally intense procedure.  Receiving a signal at 4 megahertz with a software defined radio works out to a data rate of about  30.5 megabytes per second. So for the purposes of this work, we're going to record the data and  post-process later. But eventually it will be possible to use more robust custom hardware,  you know, think FPGAs to do this work in real time. But that sounds like a pain in the butt, so  we're just going to record and do it later. So big thanks to some of my interns over there for  helping me optimize this code. It used to take about a minute to run. Now it takes about like 40  seconds. But all right, so how do we de-spread the data? First we need to lock on to the mix PN  sequencing the signal. And we do this by correlating the received data signal against the  recovered PN at every single point in time. So essentially we're sliding the PN against the  received data signal and correlating. And if we plot the correlations over time, when the PN is  perfectly aligned, we'll see a sharp spike in the correlation. And that's what you're seeing up  there. So this is how we know when to mix the two signals together to de-spread the data. So if we  align the PN on the first correlation spike only due to some frequency mismatch, we'll fall out of  correlation over time as shown there on the left. So we fix this by adjusting the PN forward or  backward at each and every correlation peak to ensure its alignment. At this point, once we're in  alignment, we simply mix the data together and the signal should fall out. So let's try that. So  after compensating for the frequency differential there, you can see on the left that the correlation  over time stays pretty constant with a slight oscillation, but that's okay. And if we zoom in or  zoom out really far, we can see the correlation is over a whole data packet. And you can see the  negative and positive correlations representing actual data bits flying over the air. So if you  look at the signal coming out of our software to spreader, sure enough we see that sharp spike in  the center indicative of our signal in question. This means we de-spread our data  successfully, theoretically. So zooming way in on that sharp peak, we can see that the waveform  looks like a BPSK signal. It's operating at around 100 hertz and we know that that's the data  rate in question that we're looking for. So things are looking pretty promising. All right. So  now that we're maybe receiving data, let's try to decode it like what's inside. So if you look at the  time domain representation of the signal, you can clearly see there's actual data bits coming  over there. So that's satellite data. So now let's click up the signal and do something with it.  Namely, we just low pass filter it and pipe it into a PSK demodulator. So at that point, the  data pretty much just falls right out. You can see at the top, I got this nice binary string out of  that data. But we need to validate it. So I found a spec sheet on line that references the data packet  format, which is shown right up there. And it starts with a preamble, essentially a constant,  unique binary sequence that tells the receiver when the packet is starting. And then it's followed  by a manufacturer ID as well as a bunch more data. So if we convert that manufacturer ID set  of bits to decimal, sure enough, it lines up with the ESN written on the back of the device. So  I'm pretty sure that means we're doing something right. So now the data packets also contain  just about any information you want. And this is kind of up to the end integrator. But these  devices predominantly are used to send location data in asset trackers. So everyone uses the  same data format. So it can be ingested the same on the back end. So after extensive comparison,  again, with some help of the interns, we free out the bits 8 to 32 are latitude and 32 to  56 are longitude. You simply convert those binary bits to decimal and multiply it by a  degrees per count value. And that will give you the actual latitude and longitude. So I've  kind of got a snippet of the code there. It will be online later if you guys want to kind of craft  your own packets. We'll talk more about that. So the data packets also contain a checksum. Long  story short, we figured out how to calculate the checksum. But this means not only can we validate  packets, we should be able to create our own. And from what we saw, the comparison and the devices  we looked at, there was no encryption, no signing, or no other protection. So theoretically we can  inject our own data back into the satellite network. So now recall that we're doing all this  reception here on the data uplink from the device to the satellite. But due to the bent pipe  nature of the global star satellites, the data in the downlink is exactly the same as the data on  the uplink. So except we just need to compensate for a few other things like Doppler shift and  multi-path interference. So this is a kind of avenue for future research if you guys are  interested in helping out. But essentially with a bigger dish, a little better hardware, we can  start receiving a ton more data doing the same method. But all right, so now we figured out  these data packets, you know, can we inject it back into the network? So warning, seriously,  don't transmit on global star frequencies. It's probably illegal where you live and it might  interfere with critical emergency communications. Fortunately, the simplex frequencies aren't  used for satellite control per se. So it's not like you're going to make it fly sideways or  anything. But if you wanted to transmit, that's actually the easy part.  So don't try this at home, wink, wink. So all you do is really, you simply mix the data  together with the PN sequence and the carrier, all of the appropriate rates which are listed here  in this talk. I'm not going to be providing my code that I designed, but if you're savvy enough  you should be able to do it. But really all you need is about.2 watts of power. And you can  write the code and get new radio. It's pretty simple. But what if there was an easier way?  Well, global star provides an OSX firmware update utility for one of their spot trace devices,  their personal asset trackers. Inside the application package there's a tool, spot3firmwaretool.jar,  and it contains all sorts of interesting functionality that's never called by the actual  firmware app. So if you look in the jar, there's a debug console class which references  something in the spot device class called write ESN, electronic serial number. So what if we wrote  a Java app to call that debug console? Sure enough, hidden functionality right there in the  software on their website. The debug console essentially lets us update the ESN of any of these  spot trace devices out there. So we can change the serial number of any of these devices,  and we can actually clone it. So to prove this, I cloned one of my spot trackers with the  other ESN and told it to transmit. And sure enough, I got a tracking email back that  confirmed, yeah, we were able to clone the device. So for 50 bucks, you can clone satellite  network devices and maybe spoof some coordinates and shenanigans. But besides the obvious of  using the network to transmit your own custom data or expanding capabilities of your service,  sending more packets than you're allowed to per hour, what can we do with the data  transmission capability? Can we get in a little bit more trouble? So first, these devices are  used very commonly in emergency response. So once in a while, I thought what if an attacker  spoofed thousands of false emergencies using these devices and jammed up the emergency  response center preventing aid from getting to an actual emergency? Or what about monitoring  help requests from these devices and then just cancelling the help request? It's kind of a  dick move, but someone might do it. So I talked to a really, really well-known reporter a  couple of days ago, and she used to work out in the Middle East as a correspondent for  about 10 years. And she said that many of the journalists out there use these spot devices  to track their whereabouts in case they're kidnapped. So they're relying on these devices  so people know where they are. So what if a foreign adversary was sniffing up this data  and then arresting our reporters or people are using these for their safety? That's not  cool. So it turns out these chips are also used in access control systems by law enforcement  and even for animal tracking. So I think it would be hilarious to say that a wild grizzly  had relocated itself into suburban California and see what all the moms say. But I also  forgot to mention that they're used heavily in SCADA systems. I'm going to refrain from  specifics because I know you guys are a bunch of hooligans and we'll probably get in some  trouble. But they're commonly used in water quality sensors, pipeline monitoring, and a  lot of big oil and gas operations. So I was thinking, what if there's a big rival oil  company that wanted to figure out where its competitor was drilling? Well, why not just  fire up your own base station and just have a look for yourself? But wait, there's more.  Lockheed Martin Flight Services, the contractor that handles flight planning for the FAA,  allows these devices, these spot devices to be used to track any VFR flight. So what if  an attacker made an airplane appear to deviate from its original flight plan into tightly  controlled airspace? You know, I obviously haven't tried this, but it would be interesting to  see what happened. So to demonstrate some of this, I built a little capability, which I'm  going to talk a little bit about. And the way it works is that I sit with the device in the  uplink path of the transmitter and listen. So this is what I was doing in my hotel room a  couple nights ago. And over time, I'm able to pick up countless transmissions from  Assist trackers and map their patterns of life. I did some research a year ago at Shmucon  talking about mapping patterns of life from mobile vulnerability location tracking. And  you know, we were able to monitor users over a fixed period of time and figure out where's  home, where's work, just by where they are at different times of the day. So pattern of  life is really key to tracking somebody. And this makes it really easy to identify what a  rocket is and where it goes. In this case, we're going to monitor an armored car route.  Now that I know where the armored car is, I know where to hijack it. And I can hijack the  car, disable its beacon and begin spoofing their beacon's ID with my transmitter and  spoof GPS coordinates that the armored car is on route. When in reality, I'm driving it  somewhere else and robbing the bank blind. So you know, think fast and nefarious. So you  might ask, does this work? Short answer is yes. But I needed a high vantage point. So  clearly the only solution was to go out and start working on my private pilot license so I  could intercept the data from the air. So I've been flying with this thing. We're going to see  where it keeps going. But the results are pretty promising so far. So I'm going to do a  little demo, show you guys a little bit up close how this works. I decided to not tempt the  live demo gods today. But I've broken up the video kind of step by step so we can kind of talk  about it. So bear with me here while I fire up the video. Is that up there? Full screen? I  can't. Perfect. So okay, so we're going to wait for a data signal from an attacker or  someone to transmit. So the attacker is intercepting the data right there. And so we've  captured the data, it writes the data out to disk. And then we're going to throw that data in  our despreading Python program here. And I've kind of cropped the video because it takes  about a minute to analyze the data packet. And okay, so it locks onto the PN signal in the  signal and starts despreading. And it'll finish up here. And then we can see that's a pretty  constant correlation over time. That's what we're looking for. So that means we locked onto the  PN signal successfully. Then we're going to throw that back into some radio code to kind of  visualize what we got. And you're going to be able to see that sharp peak in the middle. And  we're going to zoom in up there and see the live data bits flying by. And then meanwhile this is  writing those data bits out to disk for us to analyze. And then we're going to go ahead and  analyze those data bits. We should get the binary packet data out if all goes well. So there's  the binary of the packet. Now let's throw that into the packet decoder and verify it. We can  successfully validate a packet and print out its parameters. So this code will all be online as  well as some more to dive into the actual user specific data and translate that into a  latitude and longitude. Let's go back to the presentation. All right. So a couple of  conclusions. A few parting thoughts for you guys. I disclosed to global stars senior engineering  staff about 180 days ago. And they were actually really friendly in the response and seemed very  concerned. I get the impression they don't deal with a lot of these disclosures. It's not very  typical. So I provided an in-depth technical detail write up for them hoping and hopes of  helping out and never really heard back. After the news broke recently they issued a  statement saying they take privacy very seriously and they are monitoring in place to  detect these sort of attacks. Unfortunately half of this attack is passive and there's no way  that can be detected. And the transmitting portion if targeted really has a low  probability of being detected. So in some of the recent statements global stars seem quite  defensive. I tend to get upset or find that upset when manufacturers get this way rather  than addressing the actual issue at hand. In my experience these vulnerabilities are  always discovered one way or another. It's better to get them addressed sooner than later.  Last year I disclosed a bug to Grindr about being able to track their users through the  mobile dating app and they said it wasn't an issue and didn't patch it. Six months later the  Egyptian police got a hold of that bug through other channels and began using it to arrest  gay men in Egypt. So I really hate for these vulnerabilities to be used for bad and I'd  rather see that these get patched and we're able to make these systems a lot safer for  the end users. So I sincerely hope the global star is serious about their statement addressing  these issues and I hope other manufacturers are paying attention as well. But I'm really  looking forward to seeing the solutions or seeing what solutions come out of the community.  Bottom line there's still a lot of work to be done. I'm releasing my code on GitHub later.  Apologies I don't have it up yet. It's been kind of crazy here at the conference. Parties  and things. But it will be up soon. And I would love to collaborate on improving this  whole system. Maybe intercepting data on the downlink. So if you guys are interested let's  work on this together. I have a feeling we're only at the tip of the iceberg of seeing where  this thing is used. So we're going to start seeing a lot of interesting things fall out.  So if you're interested help out. In conclusion I still believe global star makes a good  product. But there's a couple of takeaways. Remember that the air space products and  satellites and airplanes they have a long life cycle and we're kind of stuck with them for  years to come. And the way the global star system is implemented it's not really patchable or  easily patchable. A lot of devices don't support firmware upgrades. They're so far out in the  boonies that it's not realistic. So the best thing to do going forward is to add a layer of  encryption on top of this existing protocol. And remember that obscurity is not security.  It's a spectrum of low and low and protect your data. And consumers just assume someone  can snoop on your data and act accordingly. I think we hear this a lot. And hold manufacturers  to a higher standard. Demand security and if not demand to know how your data is being  transmitted and is it encrypted? If not how so? So big thanks to the interns over there  for helping out with testing and code optimization. Yeah. Thanks guys. And then to  SINAC as well for funding this different crazy research. But yeah, the call will be live later.  Hit me up if it doesn't come up. But feel free to email me, tweet me. I know this is a lot to  cover. I'm always happy to talk. So thanks for coming out. Questions, comments? We got five  minutes. Can we use the bent pipe to tunnel information or like, you know, from one location to  another sneak in some information? Yeah, can we use the bent pipe to send other information?  That's a great question and you certainly can. I don't recommend it. But there's nothing, I  mean, someone probably is. You have to speculate. But yeah, it really repeats anything that  hears on that 1.6 gigahertz range and beams it back down on about 7 gigahertz so you can build  your own receiver and use your own personal satellite network. So like, does it need to be on  a particular protocol or like a packet structure or like it transmits anything that it  receives? I'm sorry, I missed that. Like, does it need to be encoded in a specific format? So the  data can really be in any format. The bent pipe doesn't do any interpretation. It's a  repeater. So you could, it probably needs to be some sort of spread spectrum in order to get it  over that distance. But you could use a model very similar to what they're doing here. Thank  you. Anyone else? Feel free to come up after. Cool, thanks guys. Appreciate it. Thank you.  Thank you.
DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_0_2111.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_2112_3815.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_3816_4091.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_4092_5327.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_5328_5939.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_5940_6827.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_6828_7367.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_7368_9071.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_9072_9527.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_9528_10163.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_10164_10763.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_10764_11147.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_11148_12035.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_12036_12719.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_12720_14795.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_14796_15563.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_15564_16583.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_16584_18887.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_18888_19559.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_19560_19799.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_19800_21263.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_21264_26171.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_26172_27167.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_27168_27539.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_27540_28055.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_28056_29963.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_29964_30179.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_30180_30683.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_30684_34811.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_34812_35627.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_35628_37679.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_37680_38195.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_38196_38939.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_38940_39347.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_39348_41723.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_41724_42431.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_42432_42599.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_42600_43043.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_43044_44063.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_44064_44891.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_44892_45707.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_45708_46103.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_46104_47303.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_47304_48323.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_48324_48863.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_48864_49991.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_49992_50483.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_50484_50891.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_50892_51191.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_51192_51407.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_51408_53759.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_53760_53831.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_53832_56759.png DEF_CON_23_-_Colby_Moore_-_Spread_Spectrum_Satcom_Hacking_2aBXpho5b7w_56760_60676.png