 I think hacking satellites is fun. I think it's even more fun when it's all security by obscurity. I would like to present you Zeck and Schneider. Both are members of the Munich CCC. Zeck works as a security consultant, but he's probably best known for the Hacker Jeopardy, which he has been doing for more than a decade. And obviously the radio. And Schneider is an awesome developer for hardware and software. So who has been to camp and seen the talk about the radium there? Please raise your hand. Wow. And who has seen the radium talk on 31C3? Even more people. And who hasn't had any radium update at all? Wow. OK, so without further ado, here is your yearly radium update. Yes. Hello. Thank you for coming to this Congress's edition of the radium talk. We've increased our slot size by 100% compared to one year ago. And we've also, I guess, increased the amount of content by quite a bit. In the last year, we've got ourselves some devices to play with from radium. Modems, actually more than one of them. A phone with contract. And that helped us a lot getting more knowledge about radium. Now, apparently, I guess half of you haven't seen any talk about radium from us before. So here's a short introduction. Radium is a global satellite network made out of low-earth orbit satellites built by motorolas in the 90s. It has 66 active logical satellites. And with logical, we mean one satellite can be more than one satellite in orbit. Maybe it has fade a little bit. And now they have two satellites in one spot, producing one logical satellite still functioning. You have worldwide global coverage, even at the poles on every place on Earth, on the water everywhere. Services, you've got messaging, you've got voice, you've got internet, IP, data, and even some special services which are broadcast only, which they only send down to Earth, and the receiver doesn't receive anything. Now, iridium coverage. There's a lot of iridium satellites, and they produce a spot beam pattern on the planet. There's 48 spot beams, each of them covering roughly 400 kilometers in diameter. All spot beams together are roughly 4,500 kilometers. Now, if you have a very sensitive setup, you can receive more than one spot beam at the same time. And that's going to be another issue during this talk. If you want to have a look at this on a global scale, you can see how much area one iridium satellite is covering on Earth, quite a lot. And by receiving them, you get a lot of knowledge. Well, look at it. Now, there's almost no info about iridium available online or in paper anyway. It's a completely proprietary protocol. There's nothing about it available. It's worldwide visible. You go out there, you get iridium signals. You go to the poll, you get iridium signals. So it's nice to have a look at it and talk about it, and everyone can just go out and have a look at it. Low barrier of entry. Cheap RTLs are good enough to get pager messages from iridium. There's lots of interesting services, the pagers, iridium burst. The devices for that are passive. They don't send anything out. So probably interesting for intelligence services also. And future proof, there's nation states interested in iridium, namely the United States, and also quite a commercial venture behind it. There's going to be iridium next launched next year, at least that's the plan. It's going to replace all of these satellites, 66 more satellites, they will de-orbit the old ones, but still the system will stay compatible with the current system. So worth the effort. Applications, tracking, fleet management, mobile data, emergency services. There are devices for emergency responders to tell them where to go based on iridium, maybe that's in a helicopter or a plane. Maritime sensors, very interesting. With iridium antennas, you don't have to point the antenna at a specific point in the sky. If you have something, it can wobble around, will still work, fine. Aircraft communications, we've seen that. While the spot beams cover all of Earth, apparently they also work 10 kilometers up and there's a lot of applications for aircrafts. So, we have been doing this for almost two years and one year ago at Congress, we had pager messages. Nice, we also had the downlink demodulated and the scrambling going on. The Ring Alert channel identified and some data stuff. Then the radio happened and really the radio was a secret project to get more iridium receivers out there. That worked great. It has good coverage on iridium. It did delay us a little bit, so after the radio we spent a lot of time again on iridium and we got a lot of stuff going. Shortburst data decoding, we ran to the phone, had a look at that. We looked at IP traffic on iridium and even got more data out of that SPD modem than just data which it receives. So, one year ago, this was our recommended setup, passive antenna and very expensive bandpass and low noise amplifiers. That works, but since camp we've got a much better setup. Modified GPS antennas, they're super cheap. They work almost out of the box, you remove one filter, you maybe replace one of the components in there, you've got a pretty nice iridium antenna. Optionally, you can add an iridium filter in there and then you can also use it in busy environments. Just one thing, if you get one of these antennas, make sure it has screws in it so you can reseal it again and take it outdoors. Modifications, you remove one filter, you get an iridium patch antenna, available in Mauser, DigiKey, that's not a big deal. You sold it in, you've got a nice antenna. We've got this thing documented in our wiki. Have a look at that, we'll get a good iridium antenna. Though one thing is potentially missing, if you are in an urban environment and there's lots of GSM and UMTS going on, you probably want to add an iridium filter in there. Murata actually makes one specifically for iridium. You pop that in and you've got a nice and clean signal. It depends on your environment, but highly recommended. Now, receiver setups, cheapest option, take that antenna, attach it to an RTL-SDR, preferably E4000 tuner, and you get iridium reception. Just a portion of the band, roughly 20 to 30%, but still enough to get a good idea about iridium. We've started with that. We've been running this for a long time, and example for pagers, more than enough. Next best thing, real SDR, in quote marks, Radio Hacker F, USRP with more coverage. Passive antenna works with these. They have a good enough amplifier to do it, but the cabling must be quite short. You cannot have many losses in the cable. So therefore, the really recommended setup from us is having an active antenna with an SDR. You can take the antenna outside, have five meters of cable, put the SDR inside. We have a proof setup, you can leave it there. We have something like that in Munich, works a treat. Yes. State of the tool chain, we've improved that quite a lot. It's a lot speedier now. We have better signal processing. We get the signals down a little bit nicer, faster, and also now have the option to cover a much wider band of radio milk, a whole band. And now it's feasible for us to actually decode everything on iridium. Not real time. That's way too much computing effort now, but we can put it on the disk and decode it then. For real time processing, really a major effort has still to be done, but, well, we'll see what happens. So, continuing on that, to make use of modern multicore processes, we've added a queue in there, and you can utilize as many cores as you want to decode iridium signals. Just one thing, the stuff on the left still runs on a single CPU, or a single core, and that's limiting us in terms of what we can do. But really, most faster cores right now can handle the whole iridium band, so it should be fine. We had a play with one of the iridium tests set. Dieter from the OsmoCom guys got one. We had a play session. That was a real boost. He also helped us a lot on the link control word and other stuff to decode. That gave us a boost in the beginning this year, just before doing the radio, and we got a lot of that. Very recommended. These devices, nice. Now, SPD modems. We've got ourselves a few of these things. They're short burst data modems. Short burst data means that you get little packets of data. You can send it to Satellite. Satellite can send it back to you. They're used all over the place for all kinds of services for iridium. These ones are specifically cheap. We got a group order going from Steve M, also OsmoCom guy. 50 euros per piece was rather cheap. Now, the thing is these are really simple SPD modems. They don't have a SIM card. They really rely only on the internal EMI. They don't have a secret in there or nothing else. Anything else? They don't authenticate themselves against the network. The network doesn't authenticate it against the modem. Nothing. You supply your contract guy with your EMI and you get a contract for that thing. Really interesting. Now, this modem also has debug interfaces, a test port interface, which we found interesting because it was mentioned in the documentation for maybe we can change the EMI or stuff like that. Interesting. It runs over the digital peripheral link, which is like some other multiplex thingy over that, which is actually the physical link, and in there there's the TPI. There's absolutely no documentation available about TPI. There's a small bit of documentation about DPL for another device. We had a look at that. DPL format then looks like that. You have a start, byte, length, data, checksum, and an X. That's pretty easy. It was fast to implement. But the TPI stuff was more tricky, so we had to get into the firmware. During the Osmo Defcon TNT got into extracting firmware from an update image, and we had a look at that, and really you get a table of TPI commands, and most of them are not implemented, but some are. And after reversing a lot of the firmware, we figured out where to go and where to look for the EEPROM stuff, and now we have on GitHub available TPI support for this modem. You can change the EMI. So what you can do is get a contract for one modem, take another modem, you clone this modem, onto this modem, now you have a contract for two modems. Interesting. And also, these EMI's are not, I mean they are blocks, probably you can guess one. You shouldn't do that, and I think it's a big hole. They did that on purpose. There are modems with sim. They authenticate themselves against the network, but that's about it. Who knows how secure that is. We'll have a look at that at some point later. Code is on GitHub, but not quite everything. Then there's another thing, there's a debug interface. It spits out debug information all the time. You enable it also by writing to some EEPROM location, and if you do that, what it spits at you is this. From 1990, really. Interesting. So this stuff evolved quite a lot, so we're now 25 years later and this code is still running. If you enable all of the debug information, you get lots of stuff. First two lines. Ring alert channel. We had decoded already earlier this year. Most of it proved that most of the stuff we did is right. We also got more stuff. Broadcast channels, some sync packets, traffic channels. Some of these information we already have integrated into the tool chain. Not all of it yet, but this firmware is a real nice thing to get data from. Packets. Iridium has 10.5 MHz of bandwidth at the moment they're using roughly 8.5 MHz, at least in Europe. We see roughly 2,000 detected bursts per second on average. And we decode of these roughly 1,200 into iridium frames. And roughly 80% of these don't have severe errors, so we can get an incontrol word or decode some stuff or at least categorize it. Yes. And if you look at that, this is a four-minute interval on iridium. The whole band, these are roughly a few hundred thousand packets and so there's quite a lot of going on, a lot going on. At the top you see the pager channels, they're every 20 seconds, small bursts in the ring alert channel, always active, and then down there, there's data channels, broadcast channels, and more of this stuff. Last year we looked at pager channels, that's only 500 kHz of data. Now we're looking at 10 MHz. That's not going to be done in real time with our current tool chain. Now we can look at roughly 2 MHz, do it in real time, so we'll get a lot of good idea about iridium. There's a lot of room for improvement, at least that's what we think. So if someone wants to help us there, we're happy to do that. At the moment it's good enough for us to get more data out of the iridium system. We usually just record to a hard disk, get the data off, there's lots of data. I mean, you have to think about 80 GB per hour for the whole band. So you really only can do that for specific things if you maybe want to have one transaction off a modem. We're only looking at the downlink, but at the same time, iridium suggests that people use their service cell that it goes up to the satellite, across to another satellite, and down again, because that will save them bandwidth on the single gateway somewhere in the US. And now, Sek will tell you more about different frame types. So we're going to look a little bit into what is all coming down from the iridium satellites. I mean, a little bit of it we already know. Like, this is the overview of the packets. I mean, Schneider already told you, the small bits at the top, the green ones are the pager channel, where all the pager methods come, which were part of our last year's talk. The red below that is the ring alert channel, and then we have categorized the other traffic, like the blue is the broadcast channels. Interestingly, not all of the frequencies are used at the same time, but the changes over time. And then we have several things, like blocks of IP packets, blocks of streams of voice packets, and other data packets. And now, we are going to look at them one by one. The first is the pager message frames, which are already known from the talk. We identified them. They start with a unique pattern at the beginning, which is hex 9669 encoded as binary phase shift key. And our toolchain decodes them, and this is the message I think we used last year. It's not very interesting. It was just for testing. There's not much to say about this. I think that's completely, or more or less completely solved. And then we have the... Oh, yeah. What I wanted to say is that iridium doesn't really like you, want you to use this anymore. I mean, they say you can't... If you can get the pager somewhere, then we will still honor it, but you can't get one from us. That makes them hard to get, maybe a little bit expensive, but they're still in use. I mean, we see lots of messages going on. Then there are the little ring alert frames. They can not... Oh, at least we can't identify them by looking at them alone. We identify them by the frequency range they're in. This is a little bit, like, randomly guessed where the best cutoff point is. The format is mostly known from our play session with the Rakhal thing we showed you before. Dita took a lot of work from us by reversing the firmware and getting us info how to de-goat this. We did a brief overview at the camp talk. The frames look like this. It contains mostly information like the current satellite and the beam you are seeing at the moment. Then it contains the position which alternates between the position where the satellite is at and the position where the beam that you are currently seeing hits the earth. It could, in theory, be used for geolocation, but it's really, really very broad information. I mean, you could probably average this or something like that. Then it also contains the pages. When the network wants a device to contact the network because it has some information for it, it sends the page message. Unfortunately, that's Timsy. That's a temporal identity, so we can't really tell you which actual device it is. We intend to look into how this is mapped in the future, but we didn't have time for it. This is, as the ring alert tunnel sends the beam ID, you can see as the satellite passes over our receiver which beam IDs we see. You can see that depending on the noise and whatever, you can also see several spot beams at the same time or shortly after each other. The next part of the family of packets are the broadcast frames. We can identify them by a BCH checksum. The polynomial is 1207, which is actually the bit reverse of the polynomial that's used to protect the messaging packets. I don't really know why, but that helps to distinguish those packets. Most info about those packets are also taken from the RACAL Test Set firmware. We've also shown them at the camp talk very briefly. They look like this. They contain information about the network where it tells the devices what frequency offset they have and what timing offset they have to correct for this or what power they are receiving so they can adjust their power. That's not really our focus at the moment because that's boring stuff like about the internals of the network. The interesting stuff are the data frames. We can identify them. They have a valid link control word. I mean, at the beginning, a special set of bits that is protected by BCH checksum. But before you get to the correct bits, you have to re-sort those bits. It's the most bizarre scrambling of bits I've seen so far. I have no idea how they came up with this order. If anyone has an idea, I would be offering a beer. This is three different parts. The content after the link control word is always 312 bits long, which is the maximum packet length. If you look at the discrepancy link control word, those three parts are protected by separate BCH. Check some polynomials like the first 29 and then 465 and 41. There's one interesting thing. The middle part of the link control word is missing one bit. Fortunately, the BCH checksum can correct bit errors. So you're expected to have, like, in half of the packets, you're expected to have a bit error there because they obviously didn't have the space to fit this bit and just dropped it on the floor. The first part of the link control word, which is 3 bits long, that gives us eight choices, is the subtype of the data frame. That we can use to differentiate the packets. The second and third part contain more network information about handoff and acquisition channel and stuff, which we took from the TPI debug code that Schneider mentioned before. But we're not too interested in that network management stuff at the moment. So we are going through the subtypes of the data packets now, starting at the top, the subtype 7. This is just a synchronization packet. If you look at the packet in a waterfall diagram, you can see that it's a single line, which can be used by the receiver to get frequency offsets and stuff. It's about 43% of all the packets we see of the data packets we see. It's just alternating 0s and 1 bits, and our tool chain just decodes them as it's a sync packet, and all the bits were as expected. So it's also not very interesting. The next subtype we see is 3. We don't see 4 to 6. We have not seen them anywhere. The subtype 3 is packets that look like this, and they have a little bit of information at the beginning and a little bit more information at the end. So to me, it looks like one of those two parts is supposedly a checksum, but I have no idea what's encoded there. We have found no information, and maybe at some later date. The next subtype... Oh, I forgot. Now it's okay. The next subtype is a subtype 2, which is the packets are descrambled. I mean the same descrambling algorithm as we had before at the Patreon channel, just in three different blocks, and it's again protected with a BCH checksum with yet another polynomial. I can give a whole other talk about reversing BCH checksums and CRCs now. After the BCH checksum is removed, there's a CRC which protects this. Again, it's a common polynomial, the CCITT polynomial, and the packet then has a little bit header at the beginning, which is in blue, and the CRC of this packet is okay. The header has fields that we don't know, but one field is a three-bit counter that can be used to reassemble longer packets. I mean this is one example. We have several packets, and we sorted them by this counter, so we can reassemble them into a larger packet. If you then look at the thus reassembled packets, they have what I call an identifier of two bytes at the start of the datagram, which identifies which kind of data is in there. We've seen about 40 different identifiers so far, roughly. Most of them, we still don't know what's in there. That's about 70% of the stuff we see inside the data packets. Many are empty. I mean they consist of zeroes. Even some of them don't have a valid CRC. They're just zeroes where the CRC is supposed to be. We will be looking at those later on, but we've identified some identifiers which contain interesting stuff. The first one of those is 0901, which contains SMS messages. We did lease a telephone and just sent some SMS and looked at what comes down. This is one reassembled SMS message, and if you put it into our current tool chain, it results in this output. The format is very similar to the SMS PDU format used in GSM. The only difference is the orange bytes, which are not part of the PDU format, and we just remove them. If we remove them, this comes out. This is just a decoded message. The green numbers, one is the SMSC central number, and the other is the sender number. The date and time when it was sent, the blue numbers are just length indicators. The message is encoded in a 7-bit GSM alphabet, which is basically ASCII except for umlauts and other stuff. Then the other identifier we got is 76.08, which contains short burst data messages, which are sent by those modems that Schneider showed you. Those modems, SPD messages, in itself can be from the specification 1,960 or 1,890 bytes, depending if they are mobile-originated or mobile-terminated. That means send them from a modem or receive them with a modem. But the one we have can only send messages up to 340 or 270 bytes. Still, this is longer than what the reassembled 3-bit counter gives us, so we have another type for continuation of those messages. And then we have the SPD message. If you want to send it, the interface is very simple. You just send an email to data at sbederidium.com, put the email you want to send it to in the subject, and put an attachment on it, and it gets sent out. You can also have a contract where you send it via just TCP connection to an IP port. That works in both directions. You can set it from the modem to just your computer. Or the other way, but iridium side, while there is some documentation where you have to connect to, they have a firewall which is source IP based, so if you just send something, you cannot reach random people's SPD modems. Many applications that we've seen use probably transfer from SPD modem to SPD modem. As we are only looking at the downlink, we can still see those messages as they are coming down to another modem. And the cost of this thing is about roughly $1 per kilobyte, which I think reminds me of the 90s internet costs. Yeah, we have an example SPD message that is not very interesting. It looks like this. If you put it through our toolchain, it contains lots of zero bytes because that was one of our test messages to check for the CRCs and the continuation stuff. Yeah, the users we found for this is stuff like voice for tuna fishing or standalone GPS trackers that has sent just the NMEA sentences of GPS over SPD and this moving map system, which is used by the helicopters from the ADAC to tell the pilot where to go, where the next emergency is. We have two more subtypes to go. The subtype 1 packets are protected with a 24-bit frame checksum, yet another CRC polynomial that had to be reversed. And then when you find it, you find out that, oh, hey, it's the same one that GSM uses. The header of those packets contains an 8-bit counter for reassembly, so you can reassemble more packets and the length. The raw data itself is a bit reversed, so you have to reflect each byte. And if you look at it, maybe some of you already realized what this looks like, and otherwise it could have been a jeopardy question. So on the next slide, yes, it is PPP. So they're just transmitting PPP over the serial line that they have on the air. It can also do multilink PPP, and it can also do a raw telnet connection, like just a stream of bytes. Luckily for us, Wireshark supports this PPP dump format, and we tested it with Lidocs and had our PPP connection and put this into Wireshark and hey, yeah, we can see the HTTP request. Wireshark is a little bit annoyed of the fact that we're missing half of the connection, but that's not a problem. The unfortunate problem of this is, on the next slide, nobody uses Linux. Windows also uses PPP, but Windows also uses the Microsoft Point-to-Point compression protocol. The Microsoft Point-to-Point compression protocol has one problem. Wireshark can't decode it. It just says, compress data. So I went and looked it up, and why is the slide here? Go one slide, father. The Microsoft PPP compression is not that difficult. There's an RC for it. It's a very simple algorithm, but someone just needs to do it. We didn't have the time. Maybe someone can do it. Otherwise, we will have to do it next year. The other stuff we found, you remember the green blobs for IP. This is probably multi-link PPP. We have seen up to 14 channels active at the same time. We have not gotten around to looking at this very much, but I think it's a lot of traffic. So now that we've had this, I told you it's not all PPP on it. There's also non-PPP traffic, which is... You can see this string coming around, and it looks like a Cisco, which is telnetting somewhere. And I was, why is there a Cisco telnet somewhere? And if you look around on the Internet, you can find some slides where people are describing the setup. And hey, that's actually a Cisco on site at the Iridium people. And if you do that connection, the Cisco actually executes a telnet command to somewhere. Yeah. And the last subtype we have is the subtype 0. And this is the interesting part of the talk. It's just voice. And this is just 312-bit maximum length of raw voice data. The problem here is that there is a voice codec, an MB voice codec, which is completely undocumented. It has a very low bit rate. And we were stumped and had no idea how to decode this. And so there were several different options. And the first option was, other people can do it for us. Luckily, MB is a family of codecs, and TNT did really great work in Osmo GMR and Toraya, which is a similar MB codec. You can go and see his talk from last year about this. And we gave him some sample files. And in record time, we got the first version of a decoder for Iridium voice frames. He's releasing his code right for this Congress. This is the repository. It should be accessible by now. This is very fast and has good quality. It's not perfect, but it's good. But wait, we have more. So the next option is emulation. As you've seen before, we've got the firmware for the SPD modem. Interestingly, on the SPD modem, there's the whole DSP code also. Also the voice codec is also on there. So this is an TI DSP chip, which has really, really ugly assembler code. But there is an now unavailable, except if you know the right people, version of Code Composer Studio, a Windows software to emulate this DSP chip. And also with the help of TNT, you can get the stuff running. This is the Windows software it looks very Windows software like. And you can run the codec in there. And it produces the same output as a telephone would. The only problem is this thing is slow. It takes about more than one minute to process a second of voice data. Yeah, that's not fun. And it's not really automatable. You have this Windows software and have to click somewhere. No, you don't want to do this. And roughly three or four weeks ago, I thought maybe there's a third option. And the third option is to use the DSP code. But I mean, we don't want to understand it, but maybe we can just wing it and emulate it by translating into crappy C. And the optimizer will fix it. It will run fast. There's documentation for this chip, which describes the CPU and the op codes. And then you just write a small little Perl script, which looks partly like this. It takes the object dump output, which has the assembler code, and then returns parts of C and puts them all into a file. And we put it all into the compiler. And hey, we've got an option, which produces a bit perfect decoder and is running really fast. The optimizer does it. The only problem is that you need the DSP code for it. So it's not entirely free because we can't really redistribute it. I suspect that nobody really cares about this old codec, but I don't want to risk it. But the firmware updates for the SPD modem are for free on the Internet. So it's just a matter of a little shell script to grab that firmware and put it through the compiler. And then you should have a perfect thing to decode. I didn't get around to write this shell script yet, but it will be there soon. You can pass it to me and I will do it. And now we have perfect voice decoding. And we want to show this to you. So we have a demo. One of those windows. I don't know which is the right window. I'm short-sighted! What are you doing? This is really well prepared. Yeah, that's it. So there's this tool, which you can run on an output of our tool chain, which contains the packets. And it shows you the frequency and the time of packets, which are supposedly voice frames. And then you can just click a start point and an end point. You have 509 minutes and 40 seconds left for this call. Or text 2888 for more account information. Please wait while your call is connected. The video has landed. Coast is clear. Coast is clear. I need to terminate this call now. We have problems. Needless to say, this was of course recorded from this very phone. From one of our members at the Munich CCC knowing what we're doing. No problem there. That's voice and working quite fine. If you get the packets in and for the decoder, no problem, we can decode that. But there's still lots of stuff we're not able to decode. And they look like voice frames, but they're not voice. They decode as 100% non-decodable. They usually come in trains of free. So you have on free channels activity with things that looks like voice. It's not. So what is it? We have no idea at all. Might be encrypted voice. There are people who have the idea maybe they use channel bundling to use some more bandwidth intensive cipher. If anyone has any idea about that, that would be great. But the only way to decode voice which uses this would be more interesting. Range. We had the phone and we were traveling a little bit in Germany. And at a distance of roughly 300 km we placed a call. And in fact could receive that in Munich. Roughly half of it. That puts around this circle around Munich where we can receive calls of iridium. That's quite an area. So there is no encryption at all on the voice frames. Nothing. They just didn't bother. The phone has a little bit of authentication with the usual GSM algorithms from the 90s. Nice. But the voice is unencrypted. So you can bet your ass that if you place a call on iridium not only will the US listen to you but everyone else will listen to you. Just be aware. We found at least three different vendors supplying this stuff. Probably only to government agencies and other... Well... Yes. I guess if you really want to get these things you can get them. So our future plans looking at uplink. At the moment if we take this phone place a call. We get what's coming down from the satellite. There's a slightly different modulation at least in the beginning. We suspect that everything else will be the same but so far we haven't looked at that. Shouldn't be a big deal. We just need to take some time and actually do that. Then there's the GSM tab for Wireshark which is a nice interface to put in your own protocol into Wireshark and decode that. Would be very nice and we're already working on that so you can have a nice view in Wireshark to filters that work. Decoding unknown packets. There's lots of stuff going on on type number 2 and type number 0 which we don't know what it's yet. Really the limiting factor there is devices which brings us to the next. We need to get access to more devices and we have some on our list to have a look at because if you have a device it's the easiest option to actually see what's going on. You know which one of these packets is yours. You can send special data and play around a little bit that makes things really easy in fact. Then signalling handover and authentication. We haven't looked at that at all so far. It's actually not needed really if you just want to get to the data but it's quite interesting for example these phones they look all the time at what satellites are available and they choose which satellite they want to use. They perform the handovers and all of these things we want to have a look at that too. Further reusing of firmware has lots of stuff to be learned from firmware and still. I guess we reversed like 10% of that SPD modem. Maybe it has still things to show. Performance we've already mentioned it. Lots of stuff to do. Now the code is on GitHub. Almost all of it, maybe a few bits missing to get the whole tool chain working really smoothly. We're going to jump into the ISC channel and we'll have a look in our stash and see if there's something missing. In general all the information we've presented today is public and in the GitHub repository. Again we're looking for specification and it's actually products, iridium go, open port devices, any SPD enabled devices for example rock 7 devices if you have access to the stuff if you can lend that to us for like 2 weeks would be very nice and then there's also iridium burst which might replace some pages for some of these users. These are modified SPD modems, they're passive and you tell iridium hey, send me this message to Europe, send me this message to the US or maybe to the globe and then these devices will pick it up undetectable and we have an idea which frames these are. These are special pager frames we suspect we see them all around the world same format probably encrypted but maybe only somehow cobbled together encoding which we haven't seen yet so that's going to be very interesting and thanks again to TNT, Dita and Steve M. There was a great help, very inspiring people thanks to the OsmoCom guys thank you very much. Thank you for that awesome talk we don't have any time for questions anymore but I guess we can contact you via email or IRC or anything else I'm sorry We're on time, we're on time we have 15 minutes left Oh yeah I fucked that one up, we have plenty of time for Q&A I am really sorry so please line up with the microphones and get ready to hit and shout out with your questions while you do that, signal Angel is there something we should answer for the internet? Testing, yes Yes, there is one question there is someone asking if the mystery data could be like sensitive, I don't know, military police, something like a custom codec We have absolutely no idea Okay, thanks But likely Thanks Thank you I heard that the NSA was trying to secure the iridium network where did they go on? Secure the iridium network As far as we can tell at least the part that we looked at there was no attempt to secure it, it's still the same stuff that was used when it was built I mean we see some messages that we don't know, it's possible that those are encrypted communications going on but we can't tell at this point so there might be encrypted communication going on in iridium that we don't know about Thank you, microphone number 3 in the back there, no, nobody Since it's conceivable that you can actually I mean the actual database that's verifying the contracts is ground based, does this mean that if you transmit a phone call to the satellite that it has to first send it back to Earth in order to verify that data is allowed to be sent and relayed so you should, I mean typically be able to make a phone call over the 150km radius that the satellite will repeat back to Earth too No idea Actually I don't really know we haven't gotten that far in our protocol understanding to even be able to try this would definitely be interesting to try it I don't mind throwing a bit of money at that if you want to try it Are there any more questions? Right now I can't see any of them Oh, microphone number 4, there is a question Then signal Angel I have currently got three questions from the internet I'm going to start with the first one that is the code composer studio version that you found, the old one Was it specifically to the DSP or did the DSP support go away or what to deal with this version? Yes, exactly At some point code composer studio dropped the support for this specific DSP and we had to get a very old version to have still support for it I think it's CCS version 3 So I would say another question from microphone number 2 I just wanted to ask is it legal to receive these things? This is a very good question and I refer to you the Weltraumtheorie So as far as I can tell there's no problem We'll just overrule you We have another question from the internet The question is what is the state of being able to geolocate iridium terminals? During the ring alert you see where the device gets paged and that's paging a specific cell You know where that cell comes down So that will tell you a rough estimate where that terminal is Of course the cell is big many hundreds of kilometers So probably you can have a look at this over time and see how the paging change when the cells hit some border If the terminal doesn't move you can probably pinpoint it better using that We haven't tried that yet but that's our guess how it would work Before we get to the next question I have a short statement about the door handle The hall is full Please don't let anyone in The next question from the internet The question is is your data that you collected available somewhere for somebody else to have a look at? No Okay We won't publish any recordings or anything like that We might publish some samples of our own messages I mean you've seen a few on the slides now If you bug us on IRC we'll probably have something But in general there's you can't just collect data and make it public I mean the great thing about this iridium is just open your window you will get data Lots of data Then we have another question at microphone number three So since recording the data is obviously legal Is it against some policy of iridium that you get angry emails from them that you have any contact with them? As far as I can tell they are aware of this and for them it's a jungle and I think they just deal with it or in fact who cares? GSM has been shown to be insecure for a long time What's the most used cell phone network on the planet? Thanks for that answer Thank you We've talked about listening What about manipulating? As we said we don't really have a good understanding of all the signaling and more intricate details of the handover and stuff and the authentication We haven't really looked at this because the data we got was so interesting that we spent our time there There's probably lots of possibilities but we haven't tried anything yet And I would recommend to not just try that These things have been built in the beginning of the 90s and I'm not sure maybe just before they de-orbit it if someone can have a play but I wouldn't really Do we have more questions from the internet? We do The next question is if where is it gone? Where is that question gone? If somebody wanted to know they think you know more than you tell and ask if you've got a gag order We definitely have not gotten a gag order I have had no contact from anyone who is affiliated with iridium or any law at all I've once checked the logs of my web server iridium service did access some of my files then I got a little bit scared and then I realized that was me going over the phone and downloading something Okay, then microphone number 2 That's just the microphone Angel No question from that person Then the internet, please go ahead Okay, hello? The internet wants to know how many uplink stations there are There's one civilian use and one for military use at least as far as the published information goes And one more which we don't know what it's exactly doing but it's near the pole There have been many more in the past I mean when they built this thing they had one in Japan but as far as the documentation goes they are all inactive You have to know that iridium went bankrupt beginning 2000s and at that point they scaled down the whole thing a lot to make it more cost efficient and also scaled down the amount of gateways So sometimes you get references for lots of gateways for iridium but they're all inactive I'm not sure what they're doing with these anymore Okay, I think we have questions from the internet left Actually as far as I know right now we don't Great, then give a warm hand of applause for a second Schneider