1 00:00:00,000 --> 00:00:09,469 *32C3 preroll music* 2 00:00:09,469 --> 00:00:13,350 Herald: I think hacking satellites is fun. 3 00:00:13,350 --> 00:00:19,940 I think it’s even more fun when it’s all ‘security by obscurity’. 4 00:00:19,940 --> 00:00:23,990 I would like to present you Sec and schneider. 5 00:00:23,990 --> 00:00:28,610 Both are members of the Munich CCC. Sec worked as a security consultant 6 00:00:28,610 --> 00:00:32,680 but he’s probably best known for the ‘Hacker Jeopardy’. Which he has been doing 7 00:00:32,680 --> 00:00:37,390 for more than a decade. And obviously the rad1o! 8 00:00:37,390 --> 00:00:42,449 *applause* 9 00:00:42,449 --> 00:00:46,630 And schneider is an awesome developer for hardware and software. 10 00:00:46,630 --> 00:00:52,290 So, who has been to Camp and seen the talk about Iridium there? 11 00:00:52,290 --> 00:00:56,710 Please raise your hand. Wow. 12 00:00:56,710 --> 00:01:02,680 And who has seen the Iridium talk on 31C3? 13 00:01:02,680 --> 00:01:08,760 Even more people. And who hasn’t had any Iridium update at all? 14 00:01:08,760 --> 00:01:14,510 Wow. Okay, so without further ado, here is your yearly Iridium update! 15 00:01:14,510 --> 00:01:21,470 *applause* *Sec laughs* 16 00:01:21,470 --> 00:01:24,800 schneider: Yes, hello, thank you for coming to this Congress’ edition 17 00:01:24,800 --> 00:01:29,820 of the Iridium talk. *laughs* We’ve increased our slot size by 100% 18 00:01:29,820 --> 00:01:33,310 compared to one year ago. And we’ve also, I guess, increased the amount of content 19 00:01:33,310 --> 00:01:38,770 by quite a bit. In the last year we’ve got ourselves 20 00:01:38,770 --> 00:01:43,710 some devices to play with from Iridium. Modems, actually. More than one of them. 21 00:01:43,710 --> 00:01:49,340 A phone, with contract. And that helped us a lot getting more knowledge 22 00:01:49,340 --> 00:01:56,180 about Iridium. Now, apparently, I guess half of you haven’t seen any talk 23 00:01:56,180 --> 00:02:01,829 about Iridium from us before. So here’s a short introduction. Iridium is a global 24 00:02:01,829 --> 00:02:07,020 satellite network made out of Low Earth Orbit satellites, built by Motorola 25 00:02:07,020 --> 00:02:13,040 in the nineties. It has 66 active logical satellites. And with ‘logical’ we mean 26 00:02:13,040 --> 00:02:18,079 one satellite can be more than one satellite in orbit. Maybe it has failed 27 00:02:18,079 --> 00:02:23,239 a little bit and now they have two satellites in one spot producing 28 00:02:23,239 --> 00:02:27,979 one logical satellite still functioning. You have worldwide global coverage, 29 00:02:27,979 --> 00:02:34,229 even at the poles, on every place on earth, on the water – everywhere. 30 00:02:34,229 --> 00:02:40,159 Services: you’ve got messaging, you’ve got voice, you’ve got internet IP data. 31 00:02:40,159 --> 00:02:45,129 And even some special services which are broadcast-only, which they only send down 32 00:02:45,129 --> 00:02:51,469 to earth, and the receiver doesn’t receive anything. Now, Iridium coverage – 33 00:02:51,469 --> 00:02:57,090 there’s a lot of Iridium satellites, and they produce a spot beam pattern 34 00:02:57,090 --> 00:03:03,849 on the planet. There’s 48 spot beams, each of them covering roughly 400 km 35 00:03:03,849 --> 00:03:09,230 in diameter. All spot beams together roughly 4500 km. Now, if you have 36 00:03:09,230 --> 00:03:12,939 a very sensitive setup you can receive more than one spot beam at the same time. 37 00:03:12,939 --> 00:03:17,949 And that’s going to be another issue during this talk. If you want to have 38 00:03:17,949 --> 00:03:23,870 a look at this on a global scale you can see how much area one Iridium satellite 39 00:03:23,870 --> 00:03:32,449 is covering on earth. Quite a lot. And by receiving them you get a lot of knowledge. 40 00:03:32,449 --> 00:03:37,779 Why look at it? Now. There’s almost no info about Iridium available online 41 00:03:37,779 --> 00:03:43,519 or in paper, or any way. It’s a completely proprietary protocol. There’s nothing 42 00:03:43,519 --> 00:03:48,180 about it available. Its worldwide visible. You go out there you get Iridium signals. 43 00:03:48,180 --> 00:03:52,469 You go to the pole you get Iridium signals. So it’s nice to have a look at it and 44 00:03:52,469 --> 00:03:58,270 talk about it, and everyone can just go out and have a look at it. Low barrier 45 00:03:58,270 --> 00:04:04,479 of entry. Cheap RTLSDRs are good enough to get pager messages from Iridium. 46 00:04:04,479 --> 00:04:09,569 There’s lots of interesting services: the pagers, Iridium Burst. The devices for that 47 00:04:09,569 --> 00:04:12,840 are passive. They don’t send anything out. So probably interesting 48 00:04:12,840 --> 00:04:17,570 for Intelligence services also. And future-proof. There’s nation states 49 00:04:17,570 --> 00:04:22,100 interested in Iridium, namely the United States and also quite a commercial 50 00:04:22,100 --> 00:04:26,710 venture behind it. There’s going to be Iridium Next, launched next year. 51 00:04:26,710 --> 00:04:29,900 At least that’s the plan. It’s going to replace all of the satellites, 52 00:04:29,900 --> 00:04:34,379 66 more satellites. They will de-orbit the old ones. But still the system will 53 00:04:34,379 --> 00:04:39,139 stay compatible with the current system. So, worth the effort. Applications. 54 00:04:39,139 --> 00:04:45,640 Tracking, fleet management, mobile data, emergency services. There are devices 55 00:04:45,640 --> 00:04:49,699 for emergency responders to tell them where to go, based on Iridium. 56 00:04:49,699 --> 00:04:54,330 Maybe that’s in a helicopter or a plane. Maritime sensors – very interesting. 57 00:04:54,330 --> 00:04:58,620 With Iridium antennas you don’t have to point the antenna at a specific point 58 00:04:58,620 --> 00:05:02,669 in the sky. You have something, it can wobble around, will still work fine. 59 00:05:02,669 --> 00:05:08,040 Aircraft communications – we’ve seen that. While the spot beams cover all of earth, 60 00:05:08,040 --> 00:05:11,850 apparently they also work 10 kilometers up, and there’s a lot of applications 61 00:05:11,850 --> 00:05:18,860 for aircrafts. We have been doing this for almost 2 years. 62 00:05:18,860 --> 00:05:24,980 And one year ago at Congress we had pager messages. Nice. 63 00:05:24,980 --> 00:05:29,860 We also had the downlink demodulated and descrambling going on. 64 00:05:29,860 --> 00:05:33,910 The Ring Alert Channel identified, and some data stuff. Then the rad1o happened. 65 00:05:33,910 --> 00:05:38,919 And really, the rad1o was a secret project to get more Iridium receivers out there. 66 00:05:38,919 --> 00:05:44,009 That worked great. It has good coverage on Iridium. It did delay us a little bit, so 67 00:05:44,009 --> 00:05:47,909 after the rad1o we spent a lot of time again on Iridium. And we got a lot of stuff 68 00:05:47,909 --> 00:05:52,710 going: short-burst data decoding. We've raided a phone, had a look at that. 69 00:05:52,710 --> 00:05:57,781 We looked at IP traffic on Iridium. And even got more data out of that SBD modem 70 00:05:57,781 --> 00:06:03,340 than just data which it receives. So. 71 00:06:03,340 --> 00:06:09,379 One year ago this was our recommended setup: passive antenna and very expensive 72 00:06:09,379 --> 00:06:14,500 bandpass and low noise amplifiers. That works but since Camp we’ve got 73 00:06:14,500 --> 00:06:20,090 a much better setup: modified GPS antennas – they’re super cheap, 74 00:06:20,090 --> 00:06:24,129 they work almost out-of-the-box, you remove one filter, you maybe replace 75 00:06:24,129 --> 00:06:27,720 one of the components in there, you’ve got a pretty nice Iridium antenna. 76 00:06:27,720 --> 00:06:30,770 Optionally, you can add an Iridium filter in there and then you can also use it 77 00:06:30,770 --> 00:06:35,310 in busy environments. Just one thing: if you get one of these antennas 78 00:06:35,310 --> 00:06:41,729 make sure it has screws in it so you can reseal it again and take it outdoors. 79 00:06:41,729 --> 00:06:46,489 Modifications: you remove one filter, you get an Iridium patch antenna 80 00:06:46,489 --> 00:06:50,919 – available on Mouser, Digikey… – that’s no big deal. You solder it in, 81 00:06:50,919 --> 00:06:55,150 you’ve got a nice antenna. We’ve got this thing documented in our Wiki. 82 00:06:55,150 --> 00:06:59,810 Have a look at that. You will get a good Iridium antenna. Though, one thing is 83 00:06:59,810 --> 00:07:02,740 potentially… *applause* 84 00:07:02,740 --> 00:07:07,960 – thanks! – …missing if you are in an urban environment 85 00:07:07,960 --> 00:07:12,000 and there’s lots of GSM and UMTS going on you probably want to add an Iridium filter 86 00:07:12,000 --> 00:07:17,610 in there. Murata actually makes one specifically for Iridium. You pop that in 87 00:07:17,610 --> 00:07:21,169 and you’ve got a nice and clean signal. It depends on the environment 88 00:07:21,169 --> 00:07:26,490 but highly recommended. Now, receiver setups. 89 00:07:26,490 --> 00:07:30,570 Cheapest option: take that antenna, attach it to an RTLSDR (preferably 90 00:07:30,570 --> 00:07:35,749 E4000 tuner) and you get Iridium reception. Just a portion of the band, 91 00:07:35,749 --> 00:07:41,069 roughly 20..40%, but still enough to get a good idea about Iridium. 92 00:07:41,069 --> 00:07:44,910 We’ve started with that, we’ve been running this for a long time. And, 93 00:07:44,910 --> 00:07:51,750 example for pagers – more than enough. Next best thing: 94 00:07:51,750 --> 00:07:58,020 “real” SDR: rad1o, HackRF, USRP. With more coverage. 95 00:07:58,020 --> 00:08:01,819 Passive antenna works with these, they have a good enough amplifier to do it. But 96 00:08:01,819 --> 00:08:06,139 the cabling must be quite short. You cannot have many losses in the cable. 97 00:08:06,139 --> 00:08:12,180 So, therefor the really recommended setup from us is having an active antenna 98 00:08:12,180 --> 00:08:15,800 with an SDR. You can take the antenna outside, have 5 meters of cable, 99 00:08:15,800 --> 00:08:19,260 put the SDR inside. Weatherproof setup. You can leave it there. We have 100 00:08:19,260 --> 00:08:23,540 something like that in Munich, works a treat. Yes. 101 00:08:23,540 --> 00:08:27,740 State of the tool chain: we’ve improved that quite a lot. It’s a lot speedier now. 102 00:08:27,740 --> 00:08:33,909 We have better signal processing, we get the signals down a little bit nicer, faster, 103 00:08:33,909 --> 00:08:38,529 and also now have the option to cover a much wider band of Iridium, 104 00:08:38,529 --> 00:08:42,979 like the whole band. And now it’s feasible for us to actually decode everything 105 00:08:42,979 --> 00:08:47,591 on the Iridium. Not real-time, that’s way too much computing effort now. But we can 106 00:08:47,591 --> 00:08:53,140 put it on a disk and decode it then. For real-time processing really a major effort 107 00:08:53,140 --> 00:08:58,000 has still to be done. But, well, we’ll see what happens. 108 00:08:58,000 --> 00:09:00,980 *applause* 109 00:09:00,980 --> 00:09:05,480 Continuing on that… to make use of modern multi-core processors we’ve added 110 00:09:05,480 --> 00:09:09,529 a Queue in there. And you can utilize as many cores as you want to decode 111 00:09:09,529 --> 00:09:15,200 Iridium signals. Just one thing: the stuff on the left still runs on a single CPU, 112 00:09:15,200 --> 00:09:21,010 or a single core. And that’s limiting us in terms of what we can do. But really, 113 00:09:21,010 --> 00:09:27,949 most faster cores right now can handle the whole Iridium band, so, should be fine. 114 00:09:27,949 --> 00:09:34,710 We had a play with an Iridium test set. Dieter from the Osmocom guys got one. 115 00:09:34,710 --> 00:09:38,270 We had a play session. That was a real boost. He also helped us a lot 116 00:09:38,270 --> 00:09:42,000 on the Link Control Word (LCW) and other stuff to decode. That gave us a boost. 117 00:09:42,000 --> 00:09:46,699 At the beginning of this year, just before doing the rad1o, and got a lot off of that. 118 00:09:46,699 --> 00:09:51,830 Barrier Air recommended (?) these devices, nice. Now, SBD modems. 119 00:09:51,830 --> 00:09:56,060 We got ourselves a few of these things. They’re ‘Short Burst Data modems’. 120 00:09:56,060 --> 00:10:00,480 ‘Short Burst Data’ means that you get little packets of data. You can send it 121 00:10:00,480 --> 00:10:04,040 to the satellite, the satellite can send it back to you. They’re used all over the place 122 00:10:04,040 --> 00:10:08,880 for all kinds of services for Iridium. These ones are specifically cheap. 123 00:10:08,880 --> 00:10:13,910 We got a group order going, from SteveM, also Osmocom guy. 50 Euros per piece, 124 00:10:13,910 --> 00:10:17,680 was rather cheap. Now, the thing is these are really simple SBD modems. 125 00:10:17,680 --> 00:10:21,700 They don’t have a SIM card. They really rely only on the internal IMEI. 126 00:10:21,700 --> 00:10:25,910 They don’t have a secret in there, or nothing else… anything else. 127 00:10:25,910 --> 00:10:29,050 They don’t authenticate themselves against the network, the network doesn’t 128 00:10:29,050 --> 00:10:35,070 authenticate it[self] against the modem. Nothing. You supply your contract guy 129 00:10:35,070 --> 00:10:41,529 with your IMEI, and you get a contract for that thing. Really interesting. 130 00:10:41,529 --> 00:10:46,839 This modem also has debug interfaces, a test port interface which we found 131 00:10:46,839 --> 00:10:49,340 interesting because it was mentioned in the documentation, quote: “maybe 132 00:10:49,340 --> 00:10:52,500 you can change the IMEI, or stuff like that”. Interesting. It runs 133 00:10:52,500 --> 00:10:55,580 over the Digital Peripheral Link (DPL) which is like some other multiplex thingy 134 00:10:55,580 --> 00:10:58,860 over that, which is actually a physical link. And in there, there’s the TPI. 135 00:10:58,860 --> 00:11:02,731 There’s absolutely no documentation available about TPI. There’s a small bit 136 00:11:02,731 --> 00:11:08,580 of documentation about DPL for another device. We had a look at that. 137 00:11:08,580 --> 00:11:13,900 DPL format then looks like that: You have a start byte, a length, data, checksum 138 00:11:13,900 --> 00:11:18,800 and an X. So that’s pretty easy. That was fast implement. But the TPI stuff 139 00:11:18,800 --> 00:11:23,530 was more tricky, so we had to get into the firmware. During the OsmoDevCon 140 00:11:23,530 --> 00:11:28,510 tnt got into extracting firmware from an update image, and we had a look at that. 141 00:11:28,510 --> 00:11:32,019 And really, you get a table of TPI commands and most of them are 142 00:11:32,019 --> 00:11:36,209 not implemented but some are. And after reversing a lot of the firmware 143 00:11:36,209 --> 00:11:40,770 we figured out where to go and where to look for the EEPROM stuff. And now 144 00:11:40,770 --> 00:11:48,420 we have on Github available TPI support for this modem. You can change the IMEI, 145 00:11:48,420 --> 00:11:54,000 so what you can do is get a contract for one modem, take another modem, you clone 146 00:11:54,000 --> 00:11:57,670 this modem onto that modem, now you have a contract for two modems. Interesting. 147 00:11:57,670 --> 00:12:00,880 *laughter and applause* 148 00:12:00,880 --> 00:12:05,610 And also these IMEIs are not… I mean 149 00:12:05,610 --> 00:12:09,310 they are blocks, probably you can guess one. You shouldn’t do that. 150 00:12:09,310 --> 00:12:14,920 I think that’s a big hole. They did that on purpose. There are modems with SIM. 151 00:12:14,920 --> 00:12:18,060 They authenticate themselves against the network. But that’s about it. 152 00:12:18,060 --> 00:12:23,019 And who knows how secure that is. We’ll have a look at that at some point later. 153 00:12:23,019 --> 00:12:28,850 The code is on Github but not quite everything. *laughs* 154 00:12:28,850 --> 00:12:33,110 Then there’s another thing. There’s a debug interface. It spits out debug information 155 00:12:33,110 --> 00:12:38,500 all the time. You enable it also via writing to some EEPROM location. 156 00:12:38,500 --> 00:12:45,520 And if you do that what it spits at you is this. From 1990, really! *laughs* 157 00:12:45,520 --> 00:12:50,759 Interesting. So this stuff evolved quite a lot. So we’re now 25 years later 158 00:12:50,759 --> 00:12:55,930 and this code is still running. If you enable all of the debug information 159 00:12:55,930 --> 00:13:00,600 you get lots of stuff. First two lines: Ring Alert channel. 160 00:13:00,600 --> 00:13:04,560 This we had decoded already, earlier this year, most of it. 161 00:13:04,560 --> 00:13:11,200 It proved that most of the stuff we did is right. We also got more stuff, 162 00:13:11,200 --> 00:13:16,410 broadcast channel, some sync packets, traffic channels. Some of these information 163 00:13:16,410 --> 00:13:21,080 you already have integrated into the tool chain. Not all of it yet, 164 00:13:21,080 --> 00:13:27,259 but this firmware is a real nice thing 165 00:13:27,259 --> 00:13:32,290 to get data from. Packets. 166 00:13:32,290 --> 00:13:36,480 Iridium has 10.5 MHz of bandwidth. At the moment they’re using ca. 8.5 MHz, 167 00:13:36,480 --> 00:13:44,010 at least in Europe. We see roughly 2,000 detected bursts per second on average. 168 00:13:44,010 --> 00:13:52,089 And we decode of these roughly 1,200 into Iridium frames. 169 00:13:52,089 --> 00:13:56,800 And roughly 80% of these don’t have severe errors, so we can get a link control word 170 00:13:56,800 --> 00:14:01,720 or decode some stuff – at least categorize it. 171 00:14:01,720 --> 00:14:07,160 If you look at that this is a four-minute interval on Iridium. 172 00:14:07,160 --> 00:14:14,970 The whole band; these are roughly a few hundred thousand packets, 173 00:14:14,970 --> 00:14:21,469 so there’s quite a lot going on. At the top you see the pager channels. 174 00:14:21,469 --> 00:14:25,060 Every 20 seconds this small burst on the Ring Alert Channel, always active, and 175 00:14:25,060 --> 00:14:32,750 then down there there’s data channels, broadcast channels and more of this stuff. 176 00:14:32,750 --> 00:14:38,149 Last year we looked at pager channels, that’s only 500 kHz of data. 177 00:14:38,149 --> 00:14:43,670 Now we’re looking at 10 MHz, that’s not going to be done in real time 178 00:14:43,670 --> 00:14:46,540 with our current tool chain. Right now, we can look at roughly 2 MHz, do it 179 00:14:46,540 --> 00:14:51,940 in real time, so that you get a good idea about Iridium. There’s a lot of room 180 00:14:51,940 --> 00:14:56,509 for improvement, at least that’s what you think. So if someone wants to help us there 181 00:14:56,509 --> 00:15:00,130 we are happy about to do that. At the moment it’s good enough for us 182 00:15:00,130 --> 00:15:05,410 to get more data out of the Iridium system. 183 00:15:05,410 --> 00:15:10,350 We usually just record to hard disk, get the data off. It’s lots of data. 184 00:15:10,350 --> 00:15:14,880 I mean, you have to think about 80 GB per hour if you capture the whole band. 185 00:15:14,880 --> 00:15:18,560 So you only can do that for specific things, if you maybe want to have 186 00:15:18,560 --> 00:15:23,069 one transaction of a modem. We’re only looking at the downlink but 187 00:15:23,069 --> 00:15:27,509 at the same time Iridium suggests that people use their service so that it goes 188 00:15:27,509 --> 00:15:31,480 up to the satellite, across to another satellite, and down again. Because 189 00:15:31,480 --> 00:15:36,420 that will save them bandwidth on their single gateway somewhere in the U.S. 190 00:15:36,420 --> 00:15:42,999 And now Sec will tell you more about different frame types. 191 00:15:42,999 --> 00:15:48,579 *applause* 192 00:15:48,579 --> 00:15:53,110 Sec: Thank you. So we’re going to look a little bit into 193 00:15:53,110 --> 00:15:58,660 what is all coming down from the Iridium satellites. 194 00:15:58,660 --> 00:16:03,720 I mean, a little bit of it we already know. Like… 195 00:16:03,720 --> 00:16:07,240 this is the overview of the packets. I mean, schneider already told you 196 00:16:07,240 --> 00:16:11,170 the small bits at the top, the green ones are the pager channel where 197 00:16:11,170 --> 00:16:15,120 all the pager messages come, which were part of our last year’s talk. 198 00:16:15,120 --> 00:16:18,769 The red below that is the Ring Alert channel. And then we have 199 00:16:18,769 --> 00:16:23,779 categorized the other traffic, like the blue are the Broadcast channels. 200 00:16:23,779 --> 00:16:28,670 Interestingly, not all of the frequencies are used at the same time, but 201 00:16:28,670 --> 00:16:34,850 that changes over time. And then we have several things like blocks 202 00:16:34,850 --> 00:16:43,179 of IP packets, blocks of streams of voice packets, and other data packets. And 203 00:16:43,179 --> 00:16:48,720 now we are going to look at them one by one. The first is the Pager Message frames 204 00:16:48,720 --> 00:16:52,779 which are already known from the talk. We identified them, they start with 205 00:16:52,779 --> 00:16:57,689 a unique pattern at the beginning, which is hex 9669 encoded 206 00:16:57,689 --> 00:17:02,889 as binary phase-shift keying (BPSK). And our cool tool chain decodes them, and 207 00:17:02,889 --> 00:17:06,970 this is the message I think we used last year. It’s not very interesting, it was 208 00:17:06,970 --> 00:17:13,920 just for testing. There’s not much to say about this, I think that’s more or less 209 00:17:13,920 --> 00:17:20,240 completely solved. Then we have… Oh, what I wanted to say is that 210 00:17:20,240 --> 00:17:26,630 Iridium doesn’t really want you to use this anymore. They say: “If you can 211 00:17:26,630 --> 00:17:31,130 get a pager [device] somewhere, then we will still honor it but you can’t get one 212 00:17:31,130 --> 00:17:36,800 from us!” That makes them hard to get, maybe a little bit expensive but 213 00:17:36,800 --> 00:17:42,000 they’re still in use. I mean we see lots of messages going on. Then there are 214 00:17:42,000 --> 00:17:48,820 the Ring Alert frames. We can’t identify them by looking at them alone. 215 00:17:48,820 --> 00:17:55,100 We identify them by the frequency range they’re in. This is a little bit 216 00:17:55,100 --> 00:18:01,390 like randomly guessed where the best cut-off point is. 217 00:18:01,390 --> 00:18:07,500 The format is mostly known from our play session with the Racal thing we showed you 218 00:18:07,500 --> 00:18:14,010 before. Dieter took a lot of work from us [off us] by reversing the firmware 219 00:18:14,010 --> 00:18:20,810 and getting us info how to decode this. We did a brief overview 220 00:18:20,810 --> 00:18:28,850 at the Camp talk. The frames look like this. *laughs* 221 00:18:28,850 --> 00:18:35,320 It contains mostly information like the current satellite and the beam you are 222 00:18:35,320 --> 00:18:40,050 seeing at the moment. Then it contains the position which alternates between 223 00:18:40,050 --> 00:18:44,410 the position where the satellite is at and the position where the beam that you are 224 00:18:44,410 --> 00:18:48,810 currently seeing hits the earth. So that could, in theory, be used for geolocation 225 00:18:48,810 --> 00:18:53,540 but it’s really, really very broad information. I mean you could probably 226 00:18:53,540 --> 00:18:59,090 average this or something like that. And then it also contains the pages, 227 00:18:59,090 --> 00:19:03,270 so when the network wants a device to contact the network because it has 228 00:19:03,270 --> 00:19:09,350 some information for it it sends the PAGE message. Unfortunately, that TMSI, 229 00:19:09,350 --> 00:19:17,020 that’s a temporary identity, so we can’t really tell you which actual device it is. 230 00:19:17,020 --> 00:19:21,390 We intend to look into how this is mapped in the future, but 231 00:19:21,390 --> 00:19:27,690 we didn’t have time for it. This is as the Ring Alert channel sends 232 00:19:27,690 --> 00:19:33,440 the Beam ID. You can see as a satellite passes over our receiver. Which Beam IDs 233 00:19:33,440 --> 00:19:39,500 we see you can see that depending on the noise and whatever… 234 00:19:39,500 --> 00:19:49,870 you can also see several spot beams at the same time, or shortly after each other. 235 00:19:49,870 --> 00:19:56,190 The next part of the family of packets are the Broadcast frames. 236 00:19:56,190 --> 00:20:01,580 We can identify them by a checksum, a BCH checksum. 237 00:20:01,580 --> 00:20:07,630 The polynomial is 1207 which is actually the bit-reverse of the polynomial that’s 238 00:20:07,630 --> 00:20:14,460 used to protect the messaging packets. I don’t really know why but 239 00:20:14,460 --> 00:20:21,300 it helps to distinguish those packets. Most info about those packets are also 240 00:20:21,300 --> 00:20:25,450 taken from the Racal Test Set firmware. We’ve also shown them at the Camp talk 241 00:20:25,450 --> 00:20:30,620 very briefly. They look like this! 242 00:20:30,620 --> 00:20:36,670 They contain information about the network where it tells the devices 243 00:20:36,670 --> 00:20:43,070 what frequency offset they have and what timing offset they have, to correct for this, 244 00:20:43,070 --> 00:20:47,750 or what power they are receiving so they can adjust the power. That’s not really 245 00:20:47,750 --> 00:20:52,880 our focus at the moment because that’s boring stuff like about the internals 246 00:20:52,880 --> 00:20:58,180 of the network. And the interesting stuff are the data frames. 247 00:20:58,180 --> 00:21:03,330 We can identify them, they have a valid Link Control Word. I mean, at the beginning 248 00:21:03,330 --> 00:21:10,560 a special set of bits that is protected 249 00:21:10,560 --> 00:21:17,660 by BCH checksum but before you get to the correct bits you have to re-sort those bits, 250 00:21:17,660 --> 00:21:22,970 and it’s the most bizarre scrambling of bits I’ve seen so far, and I have no idea 251 00:21:22,970 --> 00:21:29,880 how they came up with this order. If anyone has an idea I would be offering a beer. 252 00:21:29,880 --> 00:21:36,320 This is three different parts and the content after the Link Control Word 253 00:21:36,320 --> 00:21:42,340 is always 312 bits long which is the maximum packet length. 254 00:21:42,340 --> 00:21:48,450 If you look at the descrambled Link Control Word those three parts 255 00:21:48,450 --> 00:21:54,460 are protected by separate BCH checksum polynomials, 256 00:21:54,460 --> 00:22:00,100 like the first 29, and then 465 and 41.There’s 257 00:22:00,100 --> 00:22:06,450 one interesting thing: the middle part of the Link Control Word is missing one bit. 258 00:22:06,450 --> 00:22:11,540 Fortunately, the BCH checksum can correct bit errors, so you’re expected to have like… 259 00:22:11,540 --> 00:22:16,040 in half of the packets you’re expected to have a bit error there because they 260 00:22:16,040 --> 00:22:21,220 obviously didn’t have the space to fit this bit and just dropped it on the floor. 261 00:22:21,220 --> 00:22:26,340 The first part of the Link Control Word which is three bits long – that gives us 262 00:22:26,340 --> 00:22:33,330 eight choices – is the Sub-type of the data frame. That we can use 263 00:22:33,330 --> 00:22:37,460 to differentiate the packets. The second and third part contain 264 00:22:37,460 --> 00:22:41,450 more network information about handoff and acquisition channel and stuff 265 00:22:41,450 --> 00:22:48,830 which we took from the TPI debug code that schneider mentioned before. 266 00:22:48,830 --> 00:22:53,880 But we’re not too interested in that network management stuff at the moment. 267 00:22:53,880 --> 00:23:00,770 So we are going through the Sub-types of the data packets now, starting at the top, 268 00:23:00,770 --> 00:23:04,040 the ‘Sub-type 7’. This is just a synchronization packet. 269 00:23:04,040 --> 00:23:08,600 If you look at the packet in a waterfall diagram you can see that it’s 270 00:23:08,600 --> 00:23:14,770 a single line which can be used by the receiver to get frequency offsets and stuff. 271 00:23:14,770 --> 00:23:21,820 It’s about 43% of all the data packets we see. 272 00:23:21,820 --> 00:23:27,790 It’s just alternating 0 and 1 bits, and our tool chain just decodes them as it’s 273 00:23:27,790 --> 00:23:34,720 a sync packet, and all the bits were as expected so it’s also not very interesting. 274 00:23:34,720 --> 00:23:38,820 The next Sub-type we see is (3). We don’t see (4) to (6), 275 00:23:38,820 --> 00:23:45,400 we have not seen them anywhere. The Sub-type 3 is packets that look like this. 276 00:23:45,400 --> 00:23:48,180 And they have a little bit [of] information at the beginning, and a little bit more 277 00:23:48,180 --> 00:23:54,810 information at the end. So to me it looks like one of those two parts is supposedly 278 00:23:54,810 --> 00:24:02,170 a checksum but I have no idea what’s encoded there. We have found no information 279 00:24:02,170 --> 00:24:09,500 and, maybe at some later date. The next Sub-type… 280 00:24:09,500 --> 00:24:16,910 – Oh I forgot! The next Sub-type 281 00:24:16,910 --> 00:24:23,270 is Sub-type 2 which is… the packets are descrambled, 282 00:24:23,270 --> 00:24:27,530 I mean the same descrambling algorithm as we had before at the Pager channel, 283 00:24:27,530 --> 00:24:33,740 just in three different blocks, and is again protected with a BCH checksum 284 00:24:33,740 --> 00:24:39,780 with yet another polynomial. I can give a whole other talk about reversing 285 00:24:39,780 --> 00:24:45,010 BCH checksums and CRCs now. *laughs* 286 00:24:45,010 --> 00:24:51,080 After the BCH checksum is removed there’s a CRC which protects this again. 287 00:24:51,080 --> 00:24:56,860 It’s a common polynomial, the CCITT polynomial. And the packet then has 288 00:24:56,860 --> 00:25:01,120 a little bit header at the beginning which is in blue, and the CRC of this packet 289 00:25:01,120 --> 00:25:06,300 is okay. And the header has fields that we don’t know but one field is 290 00:25:06,300 --> 00:25:13,080 the 3 bit counter. That can be used to reassemble longer packets. 291 00:25:13,080 --> 00:25:17,710 This is one example. We have several packets and the counter… we sorted them 292 00:25:17,710 --> 00:25:24,090 by this counter so we can reassemble them into a larger packet. 293 00:25:24,090 --> 00:25:30,600 If you then look at the thus reassembled packets they have 294 00:25:30,600 --> 00:25:36,130 what I call an identifier, of 2 bytes at the start of the datagram which identifies 295 00:25:36,130 --> 00:25:43,130 which kind of data is in there. We’ve seen about 40 different identifiers so far, 296 00:25:43,130 --> 00:25:48,110 roughly. Most of them we still don’t know what’s in there. 297 00:25:48,110 --> 00:25:53,830 That’s about 70% of the stuff we see inside the data packets. 298 00:25:53,830 --> 00:25:59,060 Many are empty, they consist of Zeros. Even some of them don’t have a valid CRC, 299 00:25:59,060 --> 00:26:04,160 there are just Zeros where the CRC is supposed to be. We will be looking at those 300 00:26:04,160 --> 00:26:11,350 later on but we’ve identified some identifiers which contain interesting stuff. 301 00:26:11,350 --> 00:26:18,170 The first one of those is 09.01 which contains SMS messages. 302 00:26:18,170 --> 00:26:22,920 We did lease us a telephone and just sent some SMS, and looked at what comes down. 303 00:26:22,920 --> 00:26:27,970 This is one re-assembled SMS message. And if you put it into our current tool chain 304 00:26:27,970 --> 00:26:34,750 it results in this output. The format is very similar to the SMS PDU format 305 00:26:34,750 --> 00:26:41,020 used in GSM. The only difference is the orange bytes which are not part 306 00:26:41,020 --> 00:26:46,170 of the PDU format and we just removed them. And if you remove them 307 00:26:46,170 --> 00:26:51,250 this comes out. This is just the decoded message. 308 00:26:51,250 --> 00:26:59,290 *applause* 309 00:26:59,290 --> 00:27:04,250 So, the green numbers, one is the SMSC Centre Number, and the other is 310 00:27:04,250 --> 00:27:08,660 the Sender Number. And date and time when it was sent. And the blue numbers 311 00:27:08,660 --> 00:27:14,870 are just length indicators. The message is encoded in the 7-bit GSM alphabet 312 00:27:14,870 --> 00:27:22,500 which is basically ASCII except for umlauts and other stuff. Then 313 00:27:22,500 --> 00:27:29,630 the other identifier we got is 76.08 which contains short burst data messages 314 00:27:29,630 --> 00:27:34,640 which are sent by those modems that schneider showed you. Those modems… 315 00:27:34,640 --> 00:27:42,630 SBD messages itself can be from the specification 1960 or 1890 bytes, 316 00:27:42,630 --> 00:27:46,600 depending if they’re mobile-originated or mobile-terminated. That means send them 317 00:27:46,600 --> 00:27:51,960 from a modem or receive them with a modem. But the one we have can only send 318 00:27:51,960 --> 00:27:58,070 messages up to 340 or 270 bytes. Still this is longer than what the reassembled 319 00:27:58,070 --> 00:28:05,490 3 bit counter gives us. So we have another type for continuation of those messages. 320 00:28:05,490 --> 00:28:14,120 And then we have the SBD message, if you want to send it. The interface is 321 00:28:14,120 --> 00:28:18,530 very simple. You just send an email to data@sbd.iridium.com, put the IMEI 322 00:28:18,530 --> 00:28:21,960 you want to send it to in the subject, and put an attachment on it, and it gets 323 00:28:21,960 --> 00:28:29,270 sent out. You can also have a contract where you send it via just TCP connection 324 00:28:29,270 --> 00:28:34,050 to an IP port. That works in both directions. You can send it from the modem 325 00:28:34,050 --> 00:28:39,150 to test your computer, or the other way but Iridium-side… while there is 326 00:28:39,150 --> 00:28:43,080 some documentation where you have to connect to they have a firewall which is 327 00:28:43,080 --> 00:28:49,020 source IP based, so if you just send something you cannot reach random people’s 328 00:28:49,020 --> 00:28:57,261 SBD modems. Many applications that we’ve seen use probably transfer from SBD modem 329 00:28:57,261 --> 00:29:02,510 to SBD modem. As we are only looking at the downlink we can still see those 330 00:29:02,510 --> 00:29:06,780 messages as they’re coming down to another modem. And the cost of this thing 331 00:29:06,780 --> 00:29:12,550 is about roughly $1 per kilobyte, which I think reminds me of the nineties’ 332 00:29:12,550 --> 00:29:18,570 internet costs. *laughs* We have an example SBD message 333 00:29:18,570 --> 00:29:23,410 that is not very interesting. It looks like this if you put it through our tool chain. 334 00:29:23,410 --> 00:29:27,860 It contains lots of Zero bytes because that was of one of our test messages, 335 00:29:27,860 --> 00:29:34,600 to check for the CRCs and the continuation stuff. 336 00:29:34,600 --> 00:29:42,570 The users we found for this is stuff like buoys for tuna fishing, 337 00:29:42,570 --> 00:29:49,220 or standalone GPS trackers that send just NMEA sentences of GPS over SBD. 338 00:29:49,220 --> 00:29:56,840 And this Moving Map System which is used by the helicopters from the ADAC 339 00:29:56,840 --> 00:30:04,600 to tell the pilot where to go, where the next emergency is. 340 00:30:04,600 --> 00:30:10,030 We have two more Sub-types to go. The Sub-type 1 packets are protected 341 00:30:10,030 --> 00:30:15,440 with a 24 bit frame checksum, yet another CRC polynomial that had to be reversed. 342 00:30:15,440 --> 00:30:22,610 And then when you find it you’ll find out that, hey, it’s the same one that GSM uses. 343 00:30:22,610 --> 00:30:27,300 The header of those packets contains an 8 bit counter for reassembly. 344 00:30:27,300 --> 00:30:31,540 So you can reassemble more packets. And a length. The raw data itself 345 00:30:31,540 --> 00:30:36,790 is bit-reversed, so we have to reflect each byte. And if you look at it 346 00:30:36,790 --> 00:30:41,830 maybe some of you already realized what this looks like. And otherwise 347 00:30:41,830 --> 00:30:50,210 it could have been a Jeopardy question. So, on the next slide – yes it is PPP – 348 00:30:50,210 --> 00:30:56,530 so they’re just transmitting PPP over the serial line that they have on the air. 349 00:30:56,530 --> 00:31:03,070 It can also do multilink PPP, and it can also do like a raw telnet connection, 350 00:31:03,070 --> 00:31:11,250 like just a stream of bytes. Luckily for us Wireshark supports this PPP dump format 351 00:31:11,250 --> 00:31:17,210 and we tested it with Linux and had our PPP connection and put this into Wireshark 352 00:31:17,210 --> 00:31:21,970 and – hey! yeah! – we can see the HTTP request. Wireshark is a little bit annoyed 353 00:31:21,970 --> 00:31:25,770 of the fact that we’re missing half of the connection, but that’s not a problem. 354 00:31:25,770 --> 00:31:32,460 The unfortunate problem of this is, on the next slide, nobody uses Linux. 355 00:31:32,460 --> 00:31:36,180 Windows also uses PPP but Windows also uses the Microsoft point-to-point 356 00:31:36,180 --> 00:31:40,600 compression protocol. The Microsoft point-to-point compression protocol 357 00:31:40,600 --> 00:31:47,650 has one problem: Wireshark can’t decode it. It just says “compressed data”. 358 00:31:47,650 --> 00:31:55,380 So I went and looked it up. And – why is the slide here? 359 00:31:55,380 --> 00:32:01,230 Go one slide farther. The Microsoft PPP compression is not that difficult. 360 00:32:01,230 --> 00:32:07,290 There’s an RFC for it. It’s a very simple algorithm but someone just needs to do it. 361 00:32:07,290 --> 00:32:11,260 We didn’t have the time, maybe someone can do it. Otherwise we’ll have to do it 362 00:32:11,260 --> 00:32:19,510 next year. The other stuff we found, you will remember the green blobs for IP, 363 00:32:19,510 --> 00:32:24,000 this is probably multi-link PPP (MLPPP), we have seen up to 14 channels active 364 00:32:24,000 --> 00:32:29,390 at the same time. We have not gotten around to looking at this very much 365 00:32:29,390 --> 00:32:37,230 but I think it’s a lot of traffic. So now that we’ve had this there’s… 366 00:32:37,230 --> 00:32:44,820 I told you it’s not all PPP on it, there’s also non-PPP traffic which is… 367 00:32:44,820 --> 00:32:51,430 You can’t see the string coming around and it looks like a Cisco 368 00:32:51,430 --> 00:32:55,510 which is telnetting somewhere. Why is there a Cisco telnet somewhere? 369 00:32:55,510 --> 00:33:00,710 And if you look around on the internet you can find some slides where people are 370 00:33:00,710 --> 00:33:07,520 describing the setup, and –hey!– there’s actually a Cisco on site 371 00:33:07,520 --> 00:33:14,910 at the Iridium people, and if you do that connection the Cisco actually executes 372 00:33:14,910 --> 00:33:27,390 a telnet command to somewhere. *applause* 373 00:33:27,390 --> 00:33:31,960 And the last Sub-type we have is the Sub-type 0. And this is 374 00:33:31,960 --> 00:33:37,930 the interesting part of the talk. It’s just… voice! 375 00:33:37,930 --> 00:33:43,400 And it’s just 312 bit maximum length of raw voice data. The problem here is 376 00:33:43,400 --> 00:33:48,410 that there’s a voice codec, an AMBE voice codec which is completely undocumented. 377 00:33:48,410 --> 00:33:54,820 It has a very low bit rate. And we were stumped and had no idea how to decode this. 378 00:33:54,820 --> 00:34:01,280 And so there were several different options. The first option was: 379 00:34:01,280 --> 00:34:07,710 other people can do it for us!! Luckily, AMBE is a family of codecs, and 380 00:34:07,710 --> 00:34:13,770 tnt did really great work in osmo-gmr and Thuraya which is a similar AMBE codec. 381 00:34:13,770 --> 00:34:17,989 And you can go and see his talk from last year about this. And we gave him 382 00:34:17,989 --> 00:34:22,908 some sample files, and in record time we got the first version of a decoder 383 00:34:22,908 --> 00:34:28,949 for Iridium voice frames. He’s releasing his code right for this Congress. 384 00:34:28,949 --> 00:34:33,750 This is the repository. It should be accessible by now. This is very fast 385 00:34:33,750 --> 00:34:37,459 and has good quality. It’s not perfect, *applause* 386 00:34:37,459 --> 00:34:43,850 but it’s good. *ongoing applause* 387 00:34:43,850 --> 00:34:49,929 But wait! We have more. So the next option is emulation. 388 00:34:49,929 --> 00:34:55,849 As you have seen before we’ve got the firmware for the SBD modem. Interestingly, 389 00:34:55,849 --> 00:35:01,990 on the SBD modem there’s the whole DSP code also, also the voice codec. 390 00:35:01,990 --> 00:35:08,060 It’s also on there. So this is an TI DSP chip which has really, really ugly 391 00:35:08,060 --> 00:35:12,800 assembler code. But there is an now unavailable – except if you know 392 00:35:12,800 --> 00:35:17,670 the right people – version of Code Composer Studio, a Windows software to emulate 393 00:35:17,670 --> 00:35:24,460 this DSP chip. And also with the help of tnt you can get the stuff running. 394 00:35:24,460 --> 00:35:30,459 This is the Windows software. It looks very Windows-software-like. *laughter* 395 00:35:30,459 --> 00:35:36,490 And you can run the codec in there and it produces the same output 396 00:35:36,490 --> 00:35:43,479 as a telephone would. The only problem is this thing is slow! 397 00:35:43,479 --> 00:35:49,700 It takes about… more than one minute to process a second of voice data. 398 00:35:49,700 --> 00:35:54,500 Yeah, this is not fun. And it’s not really automatable. You have this Windows software 399 00:35:54,500 --> 00:35:58,580 and have to click somewhere, and mhmm… 400 00:35:58,580 --> 00:36:03,509 Now, you don’t want to do this. It’s roughly three or four weeks ago 401 00:36:03,509 --> 00:36:10,120 [that] I thought: “maybe there’s a third option?” And the third option is to use 402 00:36:10,120 --> 00:36:15,780 the DSP code but, we don’t want to understand it, but maybe we can just 403 00:36:15,780 --> 00:36:21,630 “wing it” and emulate it by translating into crappy C, 404 00:36:21,630 --> 00:36:25,490 and the optimizer will fix it. It will run fast. 405 00:36:25,490 --> 00:36:33,890 *laughter and applause* 406 00:36:33,890 --> 00:36:38,770 There’s documentation for this chip which describes the CPU and the opcodes. 407 00:36:38,770 --> 00:36:44,809 And then you just write a small little Perl script which looks partly like this. 408 00:36:44,809 --> 00:36:49,750 It takes the object dump output which has the assembler code and then returns 409 00:36:49,750 --> 00:36:54,880 parts of C, and puts them all into a file, and we put it all into the compiler, 410 00:36:54,880 --> 00:37:01,810 and –hey!– we’ve got an option which produces... bit perfect decoder, 411 00:37:01,810 --> 00:37:05,660 and it’s running really fast! The optimizer does it. 412 00:37:05,660 --> 00:37:12,230 *applause* 413 00:37:12,230 --> 00:37:17,359 The only problem is that you need the DSP code for it. 414 00:37:17,359 --> 00:37:22,349 So it’s not entirely free because we can’t really redistribute it. I suspect 415 00:37:22,349 --> 00:37:26,839 that nobody really cares about this old codec but I don’t want to risk it. 416 00:37:26,839 --> 00:37:31,710 But the firmware updates for like the SBD modem are for free on the internet. 417 00:37:31,710 --> 00:37:36,980 So it’s just a matter of a little shell script that grabs the firmware and puts it 418 00:37:36,980 --> 00:37:41,460 through the compiler. And then you should have a perfect thing to decode. 419 00:37:41,460 --> 00:37:45,550 I didn’t get around to write this shell script yet but it will be there soon. 420 00:37:45,550 --> 00:37:52,330 If not you can pesten (?) me and I will do it. And now we have perfect voice decoding, 421 00:37:52,330 --> 00:37:56,049 and we want to show this to you. So we have a demo. 422 00:37:56,049 --> 00:38:08,240 *applause* 423 00:38:08,240 --> 00:38:16,290 One of those windows… schneider: Alt-Tab… 424 00:38:16,290 --> 00:38:19,080 Sec: Ich weiß nicht welches das richtige Fenster ist. 425 00:38:19,080 --> 00:38:26,880 *laughs* Ich bin kurzsichtig! 426 00:38:26,880 --> 00:38:30,890 Was tust du da? *laughs* 427 00:38:30,890 --> 00:38:34,240 This is really well-prepared. schneider: Ja, das ist es. 428 00:38:34,240 --> 00:38:41,760 Sec: So there’s this tool which you can run on 429 00:38:41,760 --> 00:38:46,960 the output of our tool chain which contains the packets, and it shows you 430 00:38:46,960 --> 00:38:52,450 the frequency and the time of packets which are supposedly voice frames. 431 00:38:52,450 --> 00:39:00,250 And then you can just click a start point and an end point. 432 00:39:00,250 --> 00:39:02,189 *audio playback starts* Female TTS voice: You have five hundred 433 00:39:02,189 --> 00:39:07,569 and five minutes and 40 seconds left for this call. Please dial or text 2888 434 00:39:07,569 --> 00:39:13,319 for more account information. Please wait while your call is connected. *Beep sound* 435 00:39:13,319 --> 00:39:14,979 Male caller voice: *incomprehensible* … *applause in Congress hall* 436 00:39:14,979 --> 00:39:22,069 the Eagle has landed. Coast is clear, coast is clear. 437 00:39:22,069 --> 00:39:25,620 I need to … terminate this call now ’cause we have problems… 438 00:39:25,620 --> 00:39:28,660 *audio cut off* *audio playback ends* 439 00:39:28,660 --> 00:39:35,520 *applause* 440 00:39:35,520 --> 00:39:39,360 schneider: Needless to say, this was of course recorded from this very phone, 441 00:39:39,360 --> 00:39:43,310 from one of our members at the Munich CCC knowing what we’re doing. 442 00:39:43,310 --> 00:39:46,735 So, no problem there. 443 00:39:57,480 --> 00:40:01,360 Sec: Was muss ich denn drücken? schneider: Shift-F5! 444 00:40:01,360 --> 00:40:06,129 Sec: Hallo!? … Ah! 445 00:40:06,129 --> 00:40:14,720 schneider: So, that’s voice. And… working quite fine. If you get the packets in, 446 00:40:14,720 --> 00:40:18,280 and for the decoder no problem. We can decode that. But there’s still 447 00:40:18,280 --> 00:40:24,150 lots of stuff we don’t… we’re not able to decode. And they look like voice frames. 448 00:40:24,150 --> 00:40:30,290 But they’re not voice. hey decode as 100% non-decodable. 449 00:40:30,290 --> 00:40:37,029 They usually come in trains of three, so you have on three channels activity 450 00:40:37,029 --> 00:40:43,259 with things that looks like voice. It’s not – so what is it? We have no idea at all. 451 00:40:43,259 --> 00:40:47,190 Might be encrypted voice. There are people who have the idea maybe they used 452 00:40:47,190 --> 00:40:52,759 channel-bundling to use some more bandwidth-intensive cipher. 453 00:40:52,759 --> 00:40:57,770 If anyone has any idea about that that would be great … or a device 454 00:40:57,770 --> 00:41:04,289 which uses this would be even more interesting. 455 00:41:04,289 --> 00:41:10,660 Range. Now, we had the phone and we were traveling a little bit in Germany. 456 00:41:10,660 --> 00:41:16,490 And at a distance of roughly 300 km we placed a call. And in fact could 457 00:41:16,490 --> 00:41:22,710 receive that in Munich. Roughly half of it, and that puts around this circle 458 00:41:22,710 --> 00:41:28,430 around Munich where we can receive calls with Iridium. That’s quite an area. Now, 459 00:41:28,430 --> 00:41:34,519 there is no encryption at all on the voice frames, nothing. They just didn’t bother. 460 00:41:34,519 --> 00:41:39,380 The phone has a little bit of authentication with usually GSM algorithms 461 00:41:39,380 --> 00:41:46,249 from the nineties. Nice. But the voice is unencrypted. So you can bet your ass 462 00:41:46,249 --> 00:41:49,480 that if you place a call on Iridium not only will the U.S. listen to you 463 00:41:49,480 --> 00:41:55,160 but everyone else will listen to you. Just be aware. 464 00:41:55,160 --> 00:41:58,960 These things are also available commercially. We found at least three 465 00:41:58,960 --> 00:42:04,440 different vendors supplying the stuff. Probably only to government agencies 466 00:42:04,440 --> 00:42:10,970 and other… well… *laughs* 467 00:42:10,970 --> 00:42:16,989 I guess if you really want to get these things you can get them. 468 00:42:16,989 --> 00:42:23,330 So, future plans: looking at uplink! At the moment if we take this phone, 469 00:42:23,330 --> 00:42:28,450 place a call, we get what’s coming down from the satellite. The uplink has 470 00:42:28,450 --> 00:42:31,240 a slightly different modulation, at least in the beginning. We suspect that 471 00:42:31,240 --> 00:42:34,910 everything else will be the same. But so far we haven’t looked at that. 472 00:42:34,910 --> 00:42:38,359 Shouldn’t be a big deal, we just need to take some time and actually do that. 473 00:42:38,359 --> 00:42:44,200 Then, there's the ‘GSM tap for Wireshark’ which is a nice interface to put in 474 00:42:44,200 --> 00:42:48,900 your own protocol into Wireshark and decode that. Would be very nice and 475 00:42:48,900 --> 00:42:53,420 we’re already working on that. So you can have a nice view in Wireshark, do filters 476 00:42:53,420 --> 00:42:57,979 and see what’s actually going on on the network. Decoding unknown packets: 477 00:42:57,979 --> 00:43:02,940 there’s lots of stuff going on on type number (2) and type number (0) 478 00:43:02,940 --> 00:43:08,490 which we don’t know what it’s yet. Really, the limiting factor there is devices, 479 00:43:08,490 --> 00:43:13,089 which brings us to the next slide. We need to get access to more devices and 480 00:43:13,089 --> 00:43:17,559 we have some on our list to have a look at. Because if you have a device – 481 00:43:17,559 --> 00:43:21,369 it’s the easiest option to actually see what’s going on. You know which one 482 00:43:21,369 --> 00:43:25,420 of these packets is yours, you can decode these, you can send some special data 483 00:43:25,420 --> 00:43:31,209 and play around a little bit. That makes things really easy, in fact. Then, 484 00:43:31,209 --> 00:43:35,190 signaling, handover and authentication. We haven’t looked at that at all so far. 485 00:43:35,190 --> 00:43:39,060 It’s actually not needed, really, if you just want to get to the data but 486 00:43:39,060 --> 00:43:43,240 it’s quite interesting, for example these phones, they look all the time at 487 00:43:43,240 --> 00:43:47,500 what satellites are available and they’d chose which satellite they want to use. 488 00:43:47,500 --> 00:43:51,029 They perform the handovers and all of these things. We want to have a look 489 00:43:51,029 --> 00:43:55,619 at that, too. Further reversing the firmware. There’s lots of stuff to be learned 490 00:43:55,619 --> 00:44:03,010 from firmware and still I guess we reversed like 10% of that SBD modem. 491 00:44:03,010 --> 00:44:07,460 Maybe it has still things to show. Performance – well, we have already 492 00:44:07,460 --> 00:44:13,289 mentioned it, lots of stuff to do. Now, the code is on Github, almost all of it. 493 00:44:13,289 --> 00:44:18,340 Maybe a few bits are missing to get the whole tool chain working really smoothly. 494 00:44:18,340 --> 00:44:23,140 So if you discover that jump into the IRC channel, bug us and we’ll have a look 495 00:44:23,140 --> 00:44:27,190 in our stash and see if there’s something missing. In general, all the information 496 00:44:27,190 --> 00:44:32,200 we’ve presented today is public and in the Github repository. Again, we’re looking 497 00:44:32,200 --> 00:44:38,529 for specification, and especially products – Iridium GO, OpenPort devices, 498 00:44:38,529 --> 00:44:43,999 any SBD enabled device, e.g. Rock Seven devices, if you have access to this stuff. 499 00:44:43,999 --> 00:44:48,039 If you can lend that to us for like two weeks, would be very nice. And then 500 00:44:48,039 --> 00:44:55,359 there’s also Iridium Burst which might replace some pagers for some of these 501 00:44:55,359 --> 00:45:00,549 users. These are modified SBD modems, they’re passive and you tell Iridium: 502 00:45:00,549 --> 00:45:05,569 “Hey, send me this message to Europe, send me this message to the U.S. or maybe 503 00:45:05,569 --> 00:45:10,650 to the globe”. And then these devices will pick it up, undetectable, and we have 504 00:45:10,650 --> 00:45:16,080 an idea which frames these are. These are special pager frames, we suspect. 505 00:45:16,080 --> 00:45:20,670 We see them all around the world, the same format, probably encrypted, 506 00:45:20,670 --> 00:45:27,740 but maybe only somehow cobbled-together, a somehow cobbled-together encoding 507 00:45:27,740 --> 00:45:31,930 which we haven’t seen yet. So, that’s going to be very interesting. 508 00:45:31,930 --> 00:45:36,140 Then, thanks again to tnt, Dieter and SteveM. That was a great help, 509 00:45:36,140 --> 00:45:41,010 very inspiring people. Thanks to the Osmocom guys. Thank you very much! 510 00:45:41,010 --> 00:45:51,969 *applause* 511 00:45:51,969 --> 00:45:55,359 Herald: Thank you for the awesome talk. Unfortunately, we won’t have any time 512 00:45:55,359 --> 00:45:58,260 for questions anymore. Sec: What?? 513 00:45:58,260 --> 00:46:04,180 Herald: But I guess we can contact you via e-mail or IRC 514 00:46:04,180 --> 00:46:07,939 or anything else. I’m sorry. Sec: Why? 515 00:46:07,939 --> 00:46:14,650 schneider: We’re on time! Sec: We’re on time, we have 15 minutes left! 516 00:46:14,650 --> 00:46:21,509 *discussion on stage* 517 00:46:21,509 --> 00:46:26,200 Herald: Ooh yeah, I fucked that one up. We have plenty of time for Q&A! 518 00:46:26,200 --> 00:46:29,970 *applause* 519 00:46:29,970 --> 00:46:33,799 I am really sorry. So please line up at the microphones and get ready 520 00:46:33,799 --> 00:46:37,069 to hit Sec and schneider with your questions. While you do that, 521 00:46:37,069 --> 00:46:40,759 Signal Angel, is there something that we should answer for the internet? 522 00:46:40,759 --> 00:46:46,369 Signal Angel: Yes, there is one question. There is someone asking 523 00:46:46,369 --> 00:46:50,019 if the mystery data could be like sensitive, I don’t know, 524 00:46:50,019 --> 00:46:54,770 military, police, or something like a custom codec? 525 00:46:54,770 --> 00:46:57,279 schneider: We have absolutely no idea. 526 00:46:57,279 --> 00:47:00,349 Signal Angel: Okay, thanks. schneider: But… likely! 527 00:47:00,349 --> 00:47:04,089 Signal Angel: Thanks. *Sec laughs* 528 00:47:04,089 --> 00:47:06,270 Herald: Microphone 2, please. 529 00:47:06,270 --> 00:47:10,830 Question: Thank you. I heard that the NSA was trying to secure the Iridium network. 530 00:47:10,830 --> 00:47:13,099 Where did they go wrong? 531 00:47:13,099 --> 00:47:15,430 schneider: Securing the Iridium network? *laughs* 532 00:47:15,430 --> 00:47:19,530 Sec: As far as we can tell, at least the parts that we looked at, there was 533 00:47:19,530 --> 00:47:23,920 no attempt to secure it. It’s still the same stuff that was used 534 00:47:23,920 --> 00:47:28,250 when it was built. I mean, we see some messages that we don’t know. 535 00:47:28,250 --> 00:47:33,500 It’s possible that those are encrypted communications going on. We can’t tell 536 00:47:33,500 --> 00:47:37,720 at this point. So, there might be encrypted communication going on 537 00:47:37,720 --> 00:47:42,630 in Iridium that we don’t know about. 538 00:47:42,630 --> 00:47:50,710 Herald: Thank you. Microphone No.3, in the back there. No, nobody! 539 00:47:50,710 --> 00:47:55,270 Question: Since it’s conceivable that you could actually… I mean the actual 540 00:47:55,270 --> 00:48:00,499 database that’s verifying the contracts is ground-based. 541 00:48:00,499 --> 00:48:05,709 Does this mean that if you transmit a phone call to the satellite, 542 00:48:05,709 --> 00:48:10,630 that it has to first re-transmit it back to earth in order to verify that data 543 00:48:10,630 --> 00:48:15,340 is allowed to be sent and relayed, so you should 544 00:48:15,340 --> 00:48:19,630 typically be able to make a phone call over the 150 km radius 545 00:48:19,630 --> 00:48:26,020 that the satellite will repeat back to earth to… no idea? 546 00:48:26,020 --> 00:48:33,739 Sec: Actually I don’t really know. We haven’t gotten that far 547 00:48:33,739 --> 00:48:37,980 in our protocol understanding to even be able to try this. But it would 548 00:48:37,980 --> 00:48:43,869 definitely be interesting to try it. 549 00:48:43,869 --> 00:48:53,539 Question: I don’t mind throwing a bit money at that you are gonna try it! 550 00:48:53,539 --> 00:48:56,930 Herald: Are there any more questions? Right now I can’t see any of them… oh! 551 00:48:56,930 --> 00:49:05,040 On microphone No.4 there’s a question! Someone: No! 552 00:49:05,040 --> 00:49:09,499 Herald: Then, Signal Angel! 553 00:49:09,499 --> 00:49:12,859 Signal Angel: Okay, I have currently got three questions from internet. 554 00:49:12,859 --> 00:49:18,049 I’m going to start with the first one. That is: the Code Composer Studio version 555 00:49:18,049 --> 00:49:23,309 that you found, the old one, whether it’s specifically to the DSP or… 556 00:49:23,309 --> 00:49:27,680 it’s… basically… did the DSP support go away or what’s the deal with this version? 557 00:49:27,680 --> 00:49:32,239 schneider: Yes, exactly. At some point Code Composer Studio dropped 558 00:49:32,239 --> 00:49:37,499 the support for this specific DSP and we had to get a very old version 559 00:49:37,499 --> 00:49:40,630 to have still support for it. I think it’s CCS version 3. 560 00:49:40,630 --> 00:49:44,510 Question: Okay! Herald: So I would say another question 561 00:49:44,510 --> 00:49:46,560 from microphone No.2. 562 00:49:46,560 --> 00:49:52,760 Ray: I just wanted to ask: is it legal to receive these things? 563 00:49:52,760 --> 00:49:57,930 Sec: This is a very good question! And I refer to you: 564 00:49:57,930 --> 00:50:19,299 the ‘Weltraum-Theorie’! *wild applause and cheers* 565 00:50:19,299 --> 00:50:22,539 So as far as I can tell there’s no problem. 566 00:50:22,539 --> 00:50:25,430 *laughter, applause and cheers* 567 00:50:25,430 --> 00:50:30,539 schneider: And if you have a problem 568 00:50:30,539 --> 00:50:32,269 we’ll just overrule you. *laughs* 569 00:50:32,269 --> 00:50:42,250 *laughter* Sec: Sorry, it’s only in German! 570 00:50:42,250 --> 00:50:44,069 schneider: Thank you for that question! Herald: Okay, we have another question 571 00:50:44,069 --> 00:50:47,900 from the internet. Signal Angel: Yes, the question is: 572 00:50:47,900 --> 00:50:53,280 what is the state of being able to geo-locate Iridium terminals? 573 00:50:53,280 --> 00:50:59,450 schneider: So, during the Ring Alert you see where a device gets paged. 574 00:50:59,450 --> 00:51:04,329 And that’s paging a specific cell. You know where that cell comes down. 575 00:51:04,329 --> 00:51:08,680 So that will tell you a rough estimate where that terminal is. 576 00:51:08,680 --> 00:51:11,869 Of course the cell is big, many hundreds of kilometers, so 577 00:51:11,869 --> 00:51:17,140 probably you can have a look at this over time and see how the pagings change 578 00:51:17,140 --> 00:51:21,480 when the cells hit some border. If the terminal doesn’t move 579 00:51:21,480 --> 00:51:27,109 you can probably pinpoint it better using that. We haven’t tried that yet. 580 00:51:27,109 --> 00:51:32,639 But that’s our guess how it would work. 581 00:51:32,639 --> 00:51:35,759 Herald: Okay, bevor wir zur nächsten Frage kommen eine kurze Durchsage 582 00:51:35,759 --> 00:51:42,519 an die Tür-Engel: Der Saal ist voll, liebe Tür-Engel, bitte lasst niemanden mehr rein. 583 00:51:42,519 --> 00:51:51,280 *something shouted from audience* *Herald continues in German by accident:* 584 00:51:51,280 --> 00:51:54,750 The next question from the internet, please! 585 00:51:54,750 --> 00:51:57,349 Signal Angel: The question is: is your data that you collected 586 00:51:57,349 --> 00:52:02,260 available somewhere for somebody else to have a look at? 587 00:52:02,260 --> 00:52:09,040 schneider: No. *laughs* Okay, so, we won’t publish 588 00:52:09,040 --> 00:52:12,430 any recordings or anything like that. 589 00:52:12,430 --> 00:52:17,079 We might publish some samples of our own messages. 590 00:52:17,079 --> 00:52:22,039 I mean, you’ve seen a few on the slides now. If you bug us on IRC 591 00:52:22,039 --> 00:52:26,549 we’ll probably have something. But, in general, 592 00:52:26,549 --> 00:52:29,230 you can’t just collect data and make it public. 593 00:52:29,230 --> 00:52:34,099 Sec: I mean the great thing about this Iridium is: just open your window, 594 00:52:34,099 --> 00:52:37,689 you will get data! schneider: Pretty much! 595 00:52:37,689 --> 00:52:40,899 Sec: Lots of data! 596 00:52:40,899 --> 00:52:44,969 Herald: Then we have another question at microphone No.3. 597 00:52:44,969 --> 00:52:49,730 Question: So since recording the data is obviously legal, 598 00:52:49,730 --> 00:52:54,810 is it against, like, some policy of Iridium, that you get angry emails from them? 599 00:52:54,810 --> 00:52:58,250 Did you have any contact with them? 600 00:52:58,250 --> 00:53:03,719 schneider: As far as I can tell they are aware of this, 601 00:53:03,719 --> 00:53:11,250 and for them it’s a jungle and I think they just deal with it. 602 00:53:11,250 --> 00:53:16,480 Or, in fact, who cares? 603 00:53:16,480 --> 00:53:22,480 GSM has been shown to be insecure for a long time – what’s the most used 604 00:53:22,480 --> 00:53:29,439 cellphone network on the planet? 605 00:53:29,439 --> 00:53:32,640 Herald: Thanks for that answer. Microphone No.2, please. 606 00:53:32,640 --> 00:53:39,560 Question: Thank you. We’ve talked about listening. What about manipulating? 607 00:53:39,560 --> 00:53:44,319 Sec: As we said we don’t really have a good understanding 608 00:53:44,319 --> 00:53:50,880 of all the signaling and more intricate details of the handover and stuff, 609 00:53:50,880 --> 00:53:55,210 and the authentication. We haven’t really looked at this because the data we got 610 00:53:55,210 --> 00:53:59,729 was so interesting that we spent our time there. 611 00:53:59,729 --> 00:54:05,210 There’s probably lots of possibilities but we haven’t tried anything yet. 612 00:54:05,210 --> 00:54:09,880 schneider: And I would recommend to not just try that. 613 00:54:09,880 --> 00:54:14,259 These things have been built in the beginning of the nineties and, 614 00:54:14,259 --> 00:54:18,230 I’m not sure. Maybe just before they de-orbit it, so one can have a play. 615 00:54:18,230 --> 00:54:23,890 But I wouldn’t. Really. 616 00:54:23,890 --> 00:54:27,259 Herald: Do we have more questions from the internet? 617 00:54:27,259 --> 00:54:41,339 Signal Angel: We do. The next question is… 618 00:54:41,339 --> 00:54:45,910 Somebody wanted to know if you… well, they think you know more than you tell and ask 619 00:54:45,910 --> 00:54:48,640 if you’ve got a gag order. 620 00:54:48,640 --> 00:54:53,460 Sec: We have definitely not gotten a gag order. I have had no contact from anyone 621 00:54:53,460 --> 00:55:00,930 who is affiliated with Iridium, or any law at all. 622 00:55:00,930 --> 00:55:03,779 schneider: I’ve once checked the logs on my web server and Iridium servers 623 00:55:03,779 --> 00:55:09,259 did access some of my files. Then I got a little bit scared. And then I realized 624 00:55:09,259 --> 00:55:13,949 that was me going over the phone and downloading something. *laughs* 625 00:55:13,949 --> 00:55:20,330 *laughter and applause* 626 00:55:20,330 --> 00:55:26,589 Herald: Okay, then, microphone No.2! There’s just the Microphone Angel. Okay. 627 00:55:26,589 --> 00:55:30,010 No question from that person. Then, the internet, please go ahead! 628 00:55:30,010 --> 00:55:35,619 Signal Angel: Okay, the internet wants to know how many uplink stations there are. 629 00:55:35,619 --> 00:55:41,319 Sec: There’s one for civilian use and one for military use. 630 00:55:41,319 --> 00:55:44,079 At least as far as the published information goes. 631 00:55:44,079 --> 00:55:49,369 schneider: And one more which we don’t know what it it’s exactly doing 632 00:55:49,369 --> 00:55:54,549 but it’s near the pole. *mumble in the audience* 633 00:55:54,549 --> 00:55:58,480 Sec: There have been many more in the past. I mean when they built this thing 634 00:55:58,480 --> 00:56:03,509 they had one in Japan. But as far as the documentation goes 635 00:56:03,509 --> 00:56:06,279 they are all inactive. 636 00:56:06,279 --> 00:56:10,210 schneider: Yes. You have to know that Iridium went bankrupt beginning 2000s. 637 00:56:10,210 --> 00:56:13,820 And at that point they scaled down the whole thing a lot to make it 638 00:56:13,820 --> 00:56:16,509 more cost-efficient. And they also scaled-down the amount of gateways. 639 00:56:16,509 --> 00:56:19,599 So, sometimes you get references for lots of gateways for Iridium but 640 00:56:19,599 --> 00:56:25,440 they’re all inactive. Not sure what they’re doing with these any more. 641 00:56:25,440 --> 00:56:29,959 Herald: Okay. I think we have questions from the internet left? 642 00:56:29,959 --> 00:56:33,600 Signal Angel: Actually as far as I know right now we don’t. 643 00:56:33,600 --> 00:56:39,019 Herald: Great. Then give a warm hand of applause for Sec and schneider! 644 00:56:39,019 --> 00:56:47,169 *applause* 645 00:56:47,169 --> 00:56:50,359 *postroll music* 646 00:56:50,359 --> 00:56:58,201 *subtitles created by c3subtitles.de in the year 2017. Join, and help us!*