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!