WEBVTT
00:00:00.000 --> 00:00:09.469
32C3 preroll music
00:00:09.469 --> 00:00:13.350
Herald: I think hacking satellites is fun.
00:00:13.350 --> 00:00:19.940
I think it’s even more fun when
it’s all ‘security by obscurity’.
00:00:19.940 --> 00:00:23.990
I would like to present you
Sec and schneider.
00:00:23.990 --> 00:00:28.610
Both are members of the Munich CCC.
Sec worked as a security consultant
00:00:28.610 --> 00:00:32.680
but he’s probably best known for the
‘Hacker Jeopardy’. Which he has been doing
00:00:32.680 --> 00:00:37.390
for more than a decade.
And obviously the rad1o!
00:00:37.390 --> 00:00:42.449
applause
00:00:42.449 --> 00:00:46.630
And schneider is an awesome developer
for hardware and software.
00:00:46.630 --> 00:00:52.290
So, who has been to Camp and
seen the talk about Iridium there?
00:00:52.290 --> 00:00:56.710
Please raise your hand.
Wow.
00:00:56.710 --> 00:01:02.680
And who has seen
the Iridium talk on 31C3?
00:01:02.680 --> 00:01:08.760
Even more people. And who hasn’t
had any Iridium update at all?
00:01:08.760 --> 00:01:14.510
Wow. Okay, so without further ado,
here is your yearly Iridium update!
00:01:14.510 --> 00:01:21.470
applause
Sec laughs
00:01:21.470 --> 00:01:24.800
schneider: Yes, hello, thank you for
coming to this Congress’ edition
00:01:24.800 --> 00:01:29.820
of the Iridium talk. laughs We’ve
increased our slot size by 100%
00:01:29.820 --> 00:01:33.310
compared to one year ago. And we’ve also,
I guess, increased the amount of content
00:01:33.310 --> 00:01:38.770
by quite a bit. In the last
year we’ve got ourselves
00:01:38.770 --> 00:01:43.710
some devices to play with from Iridium.
Modems, actually. More than one of them.
00:01:43.710 --> 00:01:49.340
A phone, with contract. And that helped
us a lot getting more knowledge
00:01:49.340 --> 00:01:56.180
about Iridium. Now, apparently, I guess
half of you haven’t seen any talk
00:01:56.180 --> 00:02:01.829
about Iridium from us before. So here’s
a short introduction. Iridium is a global
00:02:01.829 --> 00:02:07.020
satellite network made out of Low Earth
Orbit satellites, built by Motorola
00:02:07.020 --> 00:02:13.040
in the nineties. It has 66 active logical
satellites. And with ‘logical’ we mean
00:02:13.040 --> 00:02:18.079
one satellite can be more than one
satellite in orbit. Maybe it has failed
00:02:18.079 --> 00:02:23.239
a little bit and now they have two
satellites in one spot producing
00:02:23.239 --> 00:02:27.979
one logical satellite still functioning.
You have worldwide global coverage,
00:02:27.979 --> 00:02:34.229
even at the poles, on every place on
earth, on the water – everywhere.
00:02:34.229 --> 00:02:40.159
Services: you’ve got messaging, you’ve
got voice, you’ve got internet IP data.
00:02:40.159 --> 00:02:45.129
And even some special services which are
broadcast-only, which they only send down
00:02:45.129 --> 00:02:51.469
to earth, and the receiver doesn’t receive
anything. Now, Iridium coverage –
00:02:51.469 --> 00:02:57.090
there’s a lot of Iridium satellites, and
they produce a spot beam pattern
00:02:57.090 --> 00:03:03.849
on the planet. There’s 48 spot beams,
each of them covering roughly 400 km
00:03:03.849 --> 00:03:09.230
in diameter. All spot beams together
roughly 4500 km. Now, if you have
00:03:09.230 --> 00:03:12.939
a very sensitive setup you can receive
more than one spot beam at the same time.
00:03:12.939 --> 00:03:17.949
And that’s going to be another issue
during this talk. If you want to have
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
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.
00:03:32.449 --> 00:03:37.779
Why look at it? Now. There’s almost
no info about Iridium available online
00:03:37.779 --> 00:03:43.519
or in paper, or any way. It’s a completely
proprietary protocol. There’s nothing
00:03:43.519 --> 00:03:48.180
about it available. Its worldwide visible.
You go out there you get Iridium signals.
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
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
00:03:58.270 --> 00:04:04.479
of entry. Cheap RTLSDRs are good enough
to get pager messages from Iridium.
00:04:04.479 --> 00:04:09.569
There’s lots of interesting services: the
pagers, Iridium Burst. The devices for that
00:04:09.569 --> 00:04:12.840
are passive. They don’t send anything
out. So probably interesting
00:04:12.840 --> 00:04:17.570
for Intelligence services also. And
future-proof. There’s nation states
00:04:17.570 --> 00:04:22.100
interested in Iridium, namely the United
States and also quite a commercial
00:04:22.100 --> 00:04:26.710
venture behind it. There’s going to be
Iridium Next, launched next year.
00:04:26.710 --> 00:04:29.900
At least that’s the plan. It’s going
to replace all of the satellites,
00:04:29.900 --> 00:04:34.379
66 more satellites. They will de-orbit
the old ones. But still the system will
00:04:34.379 --> 00:04:39.139
stay compatible with the current system.
So, worth the effort. Applications.
00:04:39.139 --> 00:04:45.640
Tracking, fleet management, mobile data,
emergency services. There are devices
00:04:45.640 --> 00:04:49.699
for emergency responders to tell
them where to go, based on Iridium.
00:04:49.699 --> 00:04:54.330
Maybe that’s in a helicopter or a plane.
Maritime sensors – very interesting.
00:04:54.330 --> 00:04:58.620
With Iridium antennas you don’t have to
point the antenna at a specific point
00:04:58.620 --> 00:05:02.669
in the sky. You have something, it can
wobble around, will still work fine.
00:05:02.669 --> 00:05:08.040
Aircraft communications – we’ve seen that.
While the spot beams cover all of earth,
00:05:08.040 --> 00:05:11.850
apparently they also work 10 kilometers
up, and there’s a lot of applications
00:05:11.850 --> 00:05:18.860
for aircrafts. We have been
doing this for almost 2 years.
00:05:18.860 --> 00:05:24.980
And one year ago at Congress
we had pager messages. Nice.
00:05:24.980 --> 00:05:29.860
We also had the downlink demodulated
and descrambling going on.
00:05:29.860 --> 00:05:33.910
The Ring Alert Channel identified, and
some data stuff. Then the rad1o happened.
00:05:33.910 --> 00:05:38.919
And really, the rad1o was a secret project
to get more Iridium receivers out there.
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
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
00:05:47.909 --> 00:05:52.710
going: short-burst data decoding. We've
raided a phone, had a look at that.
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
00:05:57.781 --> 00:06:03.340
than just data which it receives. So.
00:06:03.340 --> 00:06:09.379
One year ago this was our recommended
setup: passive antenna and very expensive
00:06:09.379 --> 00:06:14.500
bandpass and low noise amplifiers.
That works but since Camp we’ve got
00:06:14.500 --> 00:06:20.090
a much better setup: modified GPS
antennas – they’re super cheap,
00:06:20.090 --> 00:06:24.129
they work almost out-of-the-box, you
remove one filter, you maybe replace
00:06:24.129 --> 00:06:27.720
one of the components in there, you’ve
got a pretty nice Iridium antenna.
00:06:27.720 --> 00:06:30.770
Optionally, you can add an Iridium filter
in there and then you can also use it
00:06:30.770 --> 00:06:35.310
in busy environments. Just one thing:
if you get one of these antennas
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.
00:06:41.729 --> 00:06:46.489
Modifications: you remove one filter,
you get an Iridium patch antenna
00:06:46.489 --> 00:06:50.919
– available on Mouser, Digikey… –
that’s no big deal. You solder it in,
00:06:50.919 --> 00:06:55.150
you’ve got a nice antenna. We’ve got
this thing documented in our Wiki.
00:06:55.150 --> 00:06:59.810
Have a look at that. You will get a good
Iridium antenna. Though, one thing is
00:06:59.810 --> 00:07:02.740
potentially…
applause
00:07:02.740 --> 00:07:07.960
– thanks! – …missing if you
are in an urban environment
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
00:07:12.000 --> 00:07:17.610
in there. Murata actually makes one
specifically for Iridium. You pop that in
00:07:17.610 --> 00:07:21.169
and you’ve got a nice and clean signal.
It depends on the environment
00:07:21.169 --> 00:07:26.490
but highly recommended.
Now, receiver setups.
00:07:26.490 --> 00:07:30.570
Cheapest option: take that antenna,
attach it to an RTLSDR (preferably
00:07:30.570 --> 00:07:35.749
E4000 tuner) and you get Iridium
reception. Just a portion of the band,
00:07:35.749 --> 00:07:41.069
roughly 20..40%, but still enough
to get a good idea about Iridium.
00:07:41.069 --> 00:07:44.910
We’ve started with that, we’ve been
running this for a long time. And,
00:07:44.910 --> 00:07:51.750
example for pagers – more
than enough. Next best thing:
00:07:51.750 --> 00:07:58.020
“real” SDR: rad1o, HackRF, USRP.
With more coverage.
00:07:58.020 --> 00:08:01.819
Passive antenna works with these, they
have a good enough amplifier to do it. But
00:08:01.819 --> 00:08:06.139
the cabling must be quite short. You
cannot have many losses in the cable.
00:08:06.139 --> 00:08:12.180
So, therefor the really recommended setup
from us is having an active antenna
00:08:12.180 --> 00:08:15.800
with an SDR. You can take the antenna
outside, have 5 meters of cable,
00:08:15.800 --> 00:08:19.260
put the SDR inside. Weatherproof setup.
You can leave it there. We have
00:08:19.260 --> 00:08:23.540
something like that in Munich,
works a treat. Yes.
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.
00:08:27.740 --> 00:08:33.909
We have better signal processing, we get
the signals down a little bit nicer, faster,
00:08:33.909 --> 00:08:38.529
and also now have the option to cover
a much wider band of Iridium,
00:08:38.529 --> 00:08:42.979
like the whole band. And now it’s feasible
for us to actually decode everything
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
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
00:08:53.140 --> 00:08:58.000
has still to be done. But,
well, we’ll see what happens.
00:08:58.000 --> 00:09:00.980
applause
00:09:00.980 --> 00:09:05.480
Continuing on that… to make use of
modern multi-core processors we’ve added
00:09:05.480 --> 00:09:09.529
a Queue in there. And you can utilize
as many cores as you want to decode
00:09:09.529 --> 00:09:15.200
Iridium signals. Just one thing: the stuff
on the left still runs on a single CPU,
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,
00:09:21.010 --> 00:09:27.949
most faster cores right now can handle the
whole Iridium band, so, should be fine.
00:09:27.949 --> 00:09:34.710
We had a play with an Iridium test set.
Dieter from the Osmocom guys got one.
00:09:34.710 --> 00:09:38.270
We had a play session. That was
a real boost. He also helped us a lot
00:09:38.270 --> 00:09:42.000
on the Link Control Word (LCW) and other
stuff to decode. That gave us a boost.
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.
00:09:46.699 --> 00:09:51.830
Barrier Air recommended (?) these
devices, nice. Now, SBD modems.
00:09:51.830 --> 00:09:56.060
We got ourselves a few of these things.
They’re ‘Short Burst Data modems’.
00:09:56.060 --> 00:10:00.480
‘Short Burst Data’ means that you get
little packets of data. You can send it
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
00:10:04.040 --> 00:10:08.880
for all kinds of services for Iridium.
These ones are specifically cheap.
00:10:08.880 --> 00:10:13.910
We got a group order going, from SteveM,
also Osmocom guy. 50 Euros per piece,
00:10:13.910 --> 00:10:17.680
was rather cheap. Now, the thing is
these are really simple SBD modems.
00:10:17.680 --> 00:10:21.700
They don’t have a SIM card. They
really rely only on the internal IMEI.
00:10:21.700 --> 00:10:25.910
They don’t have a secret in there,
or nothing else… anything else.
00:10:25.910 --> 00:10:29.050
They don’t authenticate themselves
against the network, the network doesn’t
00:10:29.050 --> 00:10:35.070
authenticate it[self] against the modem.
Nothing. You supply your contract guy
00:10:35.070 --> 00:10:41.529
with your IMEI, and you get a contract
for that thing. Really interesting.
00:10:41.529 --> 00:10:46.839
This modem also has debug interfaces,
a test port interface which we found
00:10:46.839 --> 00:10:49.340
interesting because it was mentioned in
the documentation, quote: “maybe
00:10:49.340 --> 00:10:52.500
you can change the IMEI, or stuff
like that”. Interesting. It runs
00:10:52.500 --> 00:10:55.580
over the Digital Peripheral Link (DPL)
which is like some other multiplex thingy
00:10:55.580 --> 00:10:58.860
over that, which is actually a physical
link. And in there, there’s the TPI.
00:10:58.860 --> 00:11:02.731
There’s absolutely no documentation
available about TPI. There’s a small bit
00:11:02.731 --> 00:11:08.580
of documentation about DPL for
another device. We had a look at that.
00:11:08.580 --> 00:11:13.900
DPL format then looks like that: You
have a start byte, a length, data, checksum
00:11:13.900 --> 00:11:18.800
and an X. So that’s pretty easy. That
was fast implement. But the TPI stuff
00:11:18.800 --> 00:11:23.530
was more tricky, so we had to get into
the firmware. During the OsmoDevCon
00:11:23.530 --> 00:11:28.510
tnt got into extracting firmware from an
update image, and we had a look at that.
00:11:28.510 --> 00:11:32.019
And really, you get a table of
TPI commands and most of them are
00:11:32.019 --> 00:11:36.209
not implemented but some are. And
after reversing a lot of the firmware
00:11:36.209 --> 00:11:40.770
we figured out where to go and where to
look for the EEPROM stuff. And now
00:11:40.770 --> 00:11:48.420
we have on Github available TPI support
for this modem. You can change the IMEI,
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
00:11:54.000 --> 00:11:57.670
this modem onto that modem, now you have
a contract for two modems. Interesting.
00:11:57.670 --> 00:12:00.880
laughter and applause
00:12:00.880 --> 00:12:05.610
And also these IMEIs are not… I mean
00:12:05.610 --> 00:12:09.310
they are blocks, probably you can
guess one. You shouldn’t do that.
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.
00:12:14.920 --> 00:12:18.060
They authenticate themselves against
the network. But that’s about it.
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.
00:12:23.019 --> 00:12:28.850
The code is on Github but
not quite everything. laughs
00:12:28.850 --> 00:12:33.110
Then there’s another thing. There’s a debug
interface. It spits out debug information
00:12:33.110 --> 00:12:38.500
all the time. You enable it also via
writing to some EEPROM location.
00:12:38.500 --> 00:12:45.520
And if you do that what it spits at you
is this. From 1990, really! laughs
00:12:45.520 --> 00:12:50.759
Interesting. So this stuff evolved quite
a lot. So we’re now 25 years later
00:12:50.759 --> 00:12:55.930
and this code is still running. If you
enable all of the debug information
00:12:55.930 --> 00:13:00.600
you get lots of stuff.
First two lines: Ring Alert channel.
00:13:00.600 --> 00:13:04.560
This we had decoded already,
earlier this year, most of it.
00:13:04.560 --> 00:13:11.200
It proved that most of the stuff we did
is right. We also got more stuff,
00:13:11.200 --> 00:13:16.410
broadcast channel, some sync packets,
traffic channels. Some of these information
00:13:16.410 --> 00:13:21.080
you already have integrated
into the tool chain. Not all of it yet,
00:13:21.080 --> 00:13:27.259
but this firmware is a real nice thing
00:13:27.259 --> 00:13:32.290
to get data from.
Packets.
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,
00:13:36.480 --> 00:13:44.010
at least in Europe. We see roughly 2,000
detected bursts per second on average.
00:13:44.010 --> 00:13:52.089
And we decode of these roughly
1,200 into Iridium frames.
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
00:13:56.800 --> 00:14:01.720
or decode some stuff –
at least categorize it.
00:14:01.720 --> 00:14:07.160
If you look at that this is
a four-minute interval on Iridium.
00:14:07.160 --> 00:14:14.970
The whole band; these are roughly
a few hundred thousand packets,
00:14:14.970 --> 00:14:21.469
so there’s quite a lot going on.
At the top you see the pager channels.
00:14:21.469 --> 00:14:25.060
Every 20 seconds this small burst on the
Ring Alert Channel, always active, and
00:14:25.060 --> 00:14:32.750
then down there there’s data channels,
broadcast channels and more of this stuff.
00:14:32.750 --> 00:14:38.149
Last year we looked at pager channels,
that’s only 500 kHz of data.
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
00:14:43.670 --> 00:14:46.540
with our current tool chain. Right now,
we can look at roughly 2 MHz, do it
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
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
00:14:56.509 --> 00:15:00.130
we are happy about to do that.
At the moment it’s good enough for us
00:15:00.130 --> 00:15:05.410
to get more data
out of the Iridium system.
00:15:05.410 --> 00:15:10.350
We usually just record to hard disk,
get the data off. It’s lots of data.
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.
00:15:14.880 --> 00:15:18.560
So you only can do that for specific
things, if you maybe want to have
00:15:18.560 --> 00:15:23.069
one transaction of a modem. We’re
only looking at the downlink but
00:15:23.069 --> 00:15:27.509
at the same time Iridium suggests that
people use their service so that it goes
00:15:27.509 --> 00:15:31.480
up to the satellite, across to another
satellite, and down again. Because
00:15:31.480 --> 00:15:36.420
that will save them bandwidth on their
single gateway somewhere in the U.S.
00:15:36.420 --> 00:15:42.999
And now Sec will tell you more
about different frame types.
00:15:42.999 --> 00:15:48.579
applause
00:15:48.579 --> 00:15:53.110
Sec: Thank you. So we’re
going to look a little bit into
00:15:53.110 --> 00:15:58.660
what is all coming down
from the Iridium satellites.
00:15:58.660 --> 00:16:03.720
I mean, a little bit of it
we already know. Like…
00:16:03.720 --> 00:16:07.240
this is the overview of the packets.
I mean, schneider already told you
00:16:07.240 --> 00:16:11.170
the small bits at the top, the green
ones are the pager channel where
00:16:11.170 --> 00:16:15.120
all the pager messages come, which
were part of our last year’s talk.
00:16:15.120 --> 00:16:18.769
The red below that is the Ring Alert
channel. And then we have
00:16:18.769 --> 00:16:23.779
categorized the other traffic, like
the blue are the Broadcast channels.
00:16:23.779 --> 00:16:28.670
Interestingly, not all of the frequencies
are used at the same time, but
00:16:28.670 --> 00:16:34.850
that changes over time. And then
we have several things like blocks
00:16:34.850 --> 00:16:43.179
of IP packets, blocks of streams of voice
packets, and other data packets. And
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
00:16:48.720 --> 00:16:52.779
which are already known from the talk.
We identified them, they start with
00:16:52.779 --> 00:16:57.689
a unique pattern at the beginning,
which is hex 9669 encoded
00:16:57.689 --> 00:17:02.889
as binary phase-shift keying (BPSK). And
our cool tool chain decodes them, and
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
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
00:17:13.920 --> 00:17:20.240
completely solved. Then we have…
Oh, what I wanted to say is that
00:17:20.240 --> 00:17:26.630
Iridium doesn’t really want you to use
this anymore. They say: “If you can
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
00:17:31.130 --> 00:17:36.800
from us!” That makes them hard to
get, maybe a little bit expensive but
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
00:17:42.000 --> 00:17:48.820
the Ring Alert frames. We can’t identify
them by looking at them alone.
00:17:48.820 --> 00:17:55.100
We identify them by the frequency
range they’re in. This is a little bit
00:17:55.100 --> 00:18:01.390
like randomly guessed
where the best cut-off point is.
00:18:01.390 --> 00:18:07.500
The format is mostly known from our play
session with the Racal thing we showed you
00:18:07.500 --> 00:18:14.010
before. Dieter took a lot of work from
us [off us] by reversing the firmware
00:18:14.010 --> 00:18:20.810
and getting us info how to decode
this. We did a brief overview
00:18:20.810 --> 00:18:28.850
at the Camp talk. The frames
look like this. laughs
00:18:28.850 --> 00:18:35.320
It contains mostly information like the
current satellite and the beam you are
00:18:35.320 --> 00:18:40.050
seeing at the moment. Then it contains
the position which alternates between
00:18:40.050 --> 00:18:44.410
the position where the satellite is at and
the position where the beam that you are
00:18:44.410 --> 00:18:48.810
currently seeing hits the earth. So that
could, in theory, be used for geolocation
00:18:48.810 --> 00:18:53.540
but it’s really, really very broad
information. I mean you could probably
00:18:53.540 --> 00:18:59.090
average this or something like that.
And then it also contains the pages,
00:18:59.090 --> 00:19:03.270
so when the network wants a device
to contact the network because it has
00:19:03.270 --> 00:19:09.350
some information for it it sends the PAGE
message. Unfortunately, that TMSI,
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.
00:19:17.020 --> 00:19:21.390
We intend to look into how this
is mapped in the future, but
00:19:21.390 --> 00:19:27.690
we didn’t have time for it. This is
as the Ring Alert channel sends
00:19:27.690 --> 00:19:33.440
the Beam ID. You can see as a satellite
passes over our receiver. Which Beam IDs
00:19:33.440 --> 00:19:39.500
we see you can see that depending
on the noise and whatever…
00:19:39.500 --> 00:19:49.870
you can also see several spot beams at the
same time, or shortly after each other.
00:19:49.870 --> 00:19:56.190
The next part of the family of packets
are the Broadcast frames.
00:19:56.190 --> 00:20:01.580
We can identify them by
a checksum, a BCH checksum.
00:20:01.580 --> 00:20:07.630
The polynomial is 1207 which is actually
the bit-reverse of the polynomial that’s
00:20:07.630 --> 00:20:14.460
used to protect the messaging
packets. I don’t really know why but
00:20:14.460 --> 00:20:21.300
it helps to distinguish those packets.
Most info about those packets are also
00:20:21.300 --> 00:20:25.450
taken from the Racal Test Set firmware.
We’ve also shown them at the Camp talk
00:20:25.450 --> 00:20:30.620
very briefly. They look like this!
00:20:30.620 --> 00:20:36.670
They contain information about the
network where it tells the devices
00:20:36.670 --> 00:20:43.070
what frequency offset they have and what
timing offset they have, to correct for this,
00:20:43.070 --> 00:20:47.750
or what power they are receiving so they
can adjust the power. That’s not really
00:20:47.750 --> 00:20:52.880
our focus at the moment because that’s
boring stuff like about the internals
00:20:52.880 --> 00:20:58.180
of the network. And the interesting
stuff are the data frames.
00:20:58.180 --> 00:21:03.330
We can identify them, they have a valid
Link Control Word. I mean, at the beginning
00:21:03.330 --> 00:21:10.560
a special set of bits that is protected
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,
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
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.
00:21:29.880 --> 00:21:36.320
This is three different parts and the
content after the Link Control Word
00:21:36.320 --> 00:21:42.340
is always 312 bits long which is
the maximum packet length.
00:21:42.340 --> 00:21:48.450
If you look at the descrambled Link
Control Word those three parts
00:21:48.450 --> 00:21:54.460
are protected by separate
BCH checksum polynomials,
00:21:54.460 --> 00:22:00.100
like the first 29, and then
465 and 41.There’s
00:22:00.100 --> 00:22:06.450
one interesting thing: the middle part of
the Link Control Word is missing one bit.
00:22:06.450 --> 00:22:11.540
Fortunately, the BCH checksum can correct
bit errors, so you’re expected to have like…
00:22:11.540 --> 00:22:16.040
in half of the packets you’re expected
to have a bit error there because they
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.
00:22:21.220 --> 00:22:26.340
The first part of the Link Control Word
which is three bits long – that gives us
00:22:26.340 --> 00:22:33.330
eight choices – is the Sub-type of
the data frame. That we can use
00:22:33.330 --> 00:22:37.460
to differentiate the packets.
The second and third part contain
00:22:37.460 --> 00:22:41.450
more network information about handoff
and acquisition channel and stuff
00:22:41.450 --> 00:22:48.830
which we took from the TPI debug code
that schneider mentioned before.
00:22:48.830 --> 00:22:53.880
But we’re not too interested in that
network management stuff at the moment.
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,
00:23:00.770 --> 00:23:04.040
the ‘Sub-type 7’. This is just
a synchronization packet.
00:23:04.040 --> 00:23:08.600
If you look at the packet in a waterfall
diagram you can see that it’s
00:23:08.600 --> 00:23:14.770
a single line which can be used by the
receiver to get frequency offsets and stuff.
00:23:14.770 --> 00:23:21.820
It’s about 43% of all the
data packets we see.
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
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.
00:23:34.720 --> 00:23:38.820
The next Sub-type we see is (3).
We don’t see (4) to (6),
00:23:38.820 --> 00:23:45.400
we have not seen them anywhere. The
Sub-type 3 is packets that look like this.
00:23:45.400 --> 00:23:48.180
And they have a little bit [of] information
at the beginning, and a little bit more
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
00:23:54.810 --> 00:24:02.170
a checksum but I have no idea what’s
encoded there. We have found no information
00:24:02.170 --> 00:24:09.500
and, maybe at some later date.
The next Sub-type…
00:24:09.500 --> 00:24:16.910
– Oh I forgot! The next Sub-type
00:24:16.910 --> 00:24:23.270
is Sub-type 2 which is…
the packets are descrambled,
00:24:23.270 --> 00:24:27.530
I mean the same descrambling algorithm
as we had before at the Pager channel,
00:24:27.530 --> 00:24:33.740
just in three different blocks, and is
again protected with a BCH checksum
00:24:33.740 --> 00:24:39.780
with yet another polynomial. I can give
a whole other talk about reversing
00:24:39.780 --> 00:24:45.010
BCH checksums and CRCs now.
laughs
00:24:45.010 --> 00:24:51.080
After the BCH checksum is removed
there’s a CRC which protects this again.
00:24:51.080 --> 00:24:56.860
It’s a common polynomial, the CCITT
polynomial. And the packet then has
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
00:25:01.120 --> 00:25:06.300
is okay. And the header has fields
that we don’t know but one field is
00:25:06.300 --> 00:25:13.080
the 3 bit counter. That can be used
to reassemble longer packets.
00:25:13.080 --> 00:25:17.710
This is one example. We have several
packets and the counter… we sorted them
00:25:17.710 --> 00:25:24.090
by this counter so we can reassemble
them into a larger packet.
00:25:24.090 --> 00:25:30.600
If you then look at the thus
reassembled packets they have
00:25:30.600 --> 00:25:36.130
what I call an identifier, of 2 bytes at
the start of the datagram which identifies
00:25:36.130 --> 00:25:43.130
which kind of data is in there. We’ve seen
about 40 different identifiers so far,
00:25:43.130 --> 00:25:48.110
roughly. Most of them we still
don’t know what’s in there.
00:25:48.110 --> 00:25:53.830
That’s about 70% of the stuff
we see inside the data packets.
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,
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
00:26:04.160 --> 00:26:11.350
later on but we’ve identified some
identifiers which contain interesting stuff.
00:26:11.350 --> 00:26:18.170
The first one of those is 09.01
which contains SMS messages.
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.
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
00:26:27.970 --> 00:26:34.750
it results in this output. The format is
very similar to the SMS PDU format
00:26:34.750 --> 00:26:41.020
used in GSM. The only difference is
the orange bytes which are not part
00:26:41.020 --> 00:26:46.170
of the PDU format and we just removed
them. And if you remove them
00:26:46.170 --> 00:26:51.250
this comes out. This is
just the decoded message.
00:26:51.250 --> 00:26:59.290
applause
00:26:59.290 --> 00:27:04.250
So, the green numbers, one is the SMSC
Centre Number, and the other is
00:27:04.250 --> 00:27:08.660
the Sender Number. And date and time
when it was sent. And the blue numbers
00:27:08.660 --> 00:27:14.870
are just length indicators. The message
is encoded in the 7-bit GSM alphabet
00:27:14.870 --> 00:27:22.500
which is basically ASCII except
for umlauts and other stuff. Then
00:27:22.500 --> 00:27:29.630
the other identifier we got is 76.08 which
contains short burst data messages
00:27:29.630 --> 00:27:34.640
which are sent by those modems that
schneider showed you. Those modems…
00:27:34.640 --> 00:27:42.630
SBD messages itself can be from the
specification 1960 or 1890 bytes,
00:27:42.630 --> 00:27:46.600
depending if they’re mobile-originated or
mobile-terminated. That means send them
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
00:27:51.960 --> 00:27:58.070
messages up to 340 or 270 bytes. Still
this is longer than what the reassembled
00:27:58.070 --> 00:28:05.490
3 bit counter gives us. So we have another
type for continuation of those messages.
00:28:05.490 --> 00:28:14.120
And then we have the SBD message,
if you want to send it. The interface is
00:28:14.120 --> 00:28:18.530
very simple. You just send an email to
data@sbd.iridium.com, put the IMEI
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
00:28:21.960 --> 00:28:29.270
sent out. You can also have a contract
where you send it via just TCP connection
00:28:29.270 --> 00:28:34.050
to an IP port. That works in both
directions. You can send it from the modem
00:28:34.050 --> 00:28:39.150
to test your computer, or the other way
but Iridium-side… while there is
00:28:39.150 --> 00:28:43.080
some documentation where you have to
connect to they have a firewall which is
00:28:43.080 --> 00:28:49.020
source IP based, so if you just send
something you cannot reach random people’s
00:28:49.020 --> 00:28:57.261
SBD modems. Many applications that we’ve
seen use probably transfer from SBD modem
00:28:57.261 --> 00:29:02.510
to SBD modem. As we are only looking
at the downlink we can still see those
00:29:02.510 --> 00:29:06.780
messages as they’re coming down to
another modem. And the cost of this thing
00:29:06.780 --> 00:29:12.550
is about roughly $1 per kilobyte, which
I think reminds me of the nineties’
00:29:12.550 --> 00:29:18.570
internet costs. laughs
We have an example SBD message
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.
00:29:23.410 --> 00:29:27.860
It contains lots of Zero bytes because
that was of one of our test messages,
00:29:27.860 --> 00:29:34.600
to check for the CRCs
and the continuation stuff.
00:29:34.600 --> 00:29:42.570
The users we found for this is
stuff like buoys for tuna fishing,
00:29:42.570 --> 00:29:49.220
or standalone GPS trackers that send
just NMEA sentences of GPS over SBD.
00:29:49.220 --> 00:29:56.840
And this Moving Map System which is
used by the helicopters from the ADAC
00:29:56.840 --> 00:30:04.600
to tell the pilot where to go,
where the next emergency is.
00:30:04.600 --> 00:30:10.030
We have two more Sub-types to go.
The Sub-type 1 packets are protected
00:30:10.030 --> 00:30:15.440
with a 24 bit frame checksum, yet another
CRC polynomial that had to be reversed.
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.
00:30:22.610 --> 00:30:27.300
The header of those packets contains
an 8 bit counter for reassembly.
00:30:27.300 --> 00:30:31.540
So you can reassemble more packets.
And a length. The raw data itself
00:30:31.540 --> 00:30:36.790
is bit-reversed, so we have to reflect
each byte. And if you look at it
00:30:36.790 --> 00:30:41.830
maybe some of you already realized
what this looks like. And otherwise
00:30:41.830 --> 00:30:50.210
it could have been a Jeopardy question.
So, on the next slide – yes it is PPP –
00:30:50.210 --> 00:30:56.530
so they’re just transmitting PPP over the
serial line that they have on the air.
00:30:56.530 --> 00:31:03.070
It can also do multilink PPP, and it can
also do like a raw telnet connection,
00:31:03.070 --> 00:31:11.250
like just a stream of bytes. Luckily for
us Wireshark supports this PPP dump format
00:31:11.250 --> 00:31:17.210
and we tested it with Linux and had our
PPP connection and put this into Wireshark
00:31:17.210 --> 00:31:21.970
and – hey! yeah! – we can see the HTTP
request. Wireshark is a little bit annoyed
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.
00:31:25.770 --> 00:31:32.460
The unfortunate problem of this is,
on the next slide, nobody uses Linux.
00:31:32.460 --> 00:31:36.180
Windows also uses PPP but Windows
also uses the Microsoft point-to-point
00:31:36.180 --> 00:31:40.600
compression protocol. The Microsoft
point-to-point compression protocol
00:31:40.600 --> 00:31:47.650
has one problem: Wireshark can’t decode
it. It just says “compressed data”.
00:31:47.650 --> 00:31:55.380
So I went and looked it up. And
– why is the slide here?
00:31:55.380 --> 00:32:01.230
Go one slide farther. The Microsoft
PPP compression is not that difficult.
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.
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
00:32:11.260 --> 00:32:19.510
next year. The other stuff we found,
you will remember the green blobs for IP,
00:32:19.510 --> 00:32:24.000
this is probably multi-link PPP (MLPPP),
we have seen up to 14 channels active
00:32:24.000 --> 00:32:29.390
at the same time. We have not gotten
around to looking at this very much
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…
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…
00:32:44.820 --> 00:32:51.430
You can’t see the string coming
around and it looks like a Cisco
00:32:51.430 --> 00:32:55.510
which is telnetting somewhere. Why
is there a Cisco telnet somewhere?
00:32:55.510 --> 00:33:00.710
And if you look around on the internet you
can find some slides where people are
00:33:00.710 --> 00:33:07.520
describing the setup, and –hey!–
there’s actually a Cisco on site
00:33:07.520 --> 00:33:14.910
at the Iridium people, and if you do that
connection the Cisco actually executes
00:33:14.910 --> 00:33:27.390
a telnet command to somewhere.
applause
00:33:27.390 --> 00:33:31.960
And the last Sub-type we have
is the Sub-type 0. And this is
00:33:31.960 --> 00:33:37.930
the interesting part of the talk.
It’s just… voice!
00:33:37.930 --> 00:33:43.400
And it’s just 312 bit maximum length
of raw voice data. The problem here is
00:33:43.400 --> 00:33:48.410
that there’s a voice codec, an AMBE voice
codec which is completely undocumented.
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.
00:33:54.820 --> 00:34:01.280
And so there were several different
options. The first option was:
00:34:01.280 --> 00:34:07.710
other people can do it for us!!
Luckily, AMBE is a family of codecs, and
00:34:07.710 --> 00:34:13.770
tnt did really great work in osmo-gmr and
Thuraya which is a similar AMBE codec.
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
00:34:17.989 --> 00:34:22.908
some sample files, and in record time
we got the first version of a decoder
00:34:22.908 --> 00:34:28.949
for Iridium voice frames. He’s releasing
his code right for this Congress.
00:34:28.949 --> 00:34:33.750
This is the repository. It should be
accessible by now. This is very fast
00:34:33.750 --> 00:34:37.459
and has good quality. It’s not perfect,
applause
00:34:37.459 --> 00:34:43.850
but it’s good.
ongoing applause
00:34:43.850 --> 00:34:49.929
But wait! We have more.
So the next option is emulation.
00:34:49.929 --> 00:34:55.849
As you have seen before we’ve got the
firmware for the SBD modem. Interestingly,
00:34:55.849 --> 00:35:01.990
on the SBD modem there’s the whole
DSP code also, also the voice codec.
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
00:35:08.060 --> 00:35:12.800
assembler code. But there is an now
unavailable – except if you know
00:35:12.800 --> 00:35:17.670
the right people – version of Code Composer
Studio, a Windows software to emulate
00:35:17.670 --> 00:35:24.460
this DSP chip. And also with the help
of tnt you can get the stuff running.
00:35:24.460 --> 00:35:30.459
This is the Windows software. It looks
very Windows-software-like. laughter
00:35:30.459 --> 00:35:36.490
And you can run the codec in there
and it produces the same output
00:35:36.490 --> 00:35:43.479
as a telephone would.
The only problem is this thing is slow!
00:35:43.479 --> 00:35:49.700
It takes about… more than one minute
to process a second of voice data.
00:35:49.700 --> 00:35:54.500
Yeah, this is not fun. And it’s not really
automatable. You have this Windows software
00:35:54.500 --> 00:35:58.580
and have to click somewhere, and mhmm…
00:35:58.580 --> 00:36:03.509
Now, you don’t want to do this.
It’s roughly three or four weeks ago
00:36:03.509 --> 00:36:10.120
[that] I thought: “maybe there’s a third
option?” And the third option is to use
00:36:10.120 --> 00:36:15.780
the DSP code but, we don’t want to
understand it, but maybe we can just
00:36:15.780 --> 00:36:21.630
“wing it” and emulate it
by translating into crappy C,
00:36:21.630 --> 00:36:25.490
and the optimizer will fix it.
It will run fast.
00:36:25.490 --> 00:36:33.890
laughter and applause
00:36:33.890 --> 00:36:38.770
There’s documentation for this chip which
describes the CPU and the opcodes.
00:36:38.770 --> 00:36:44.809
And then you just write a small little
Perl script which looks partly like this.
00:36:44.809 --> 00:36:49.750
It takes the object dump output which has
the assembler code and then returns
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,
00:36:54.880 --> 00:37:01.810
and –hey!– we’ve got an option which produces...
bit perfect decoder,
00:37:01.810 --> 00:37:05.660
and it’s running really fast!
The optimizer does it.
00:37:05.660 --> 00:37:12.230
applause
00:37:12.230 --> 00:37:17.359
The only problem is that
you need the DSP code for it.
00:37:17.359 --> 00:37:22.349
So it’s not entirely free because we
can’t really redistribute it. I suspect
00:37:22.349 --> 00:37:26.839
that nobody really cares about this
old codec but I don’t want to risk it.
00:37:26.839 --> 00:37:31.710
But the firmware updates for like the SBD
modem are for free on the internet.
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
00:37:36.980 --> 00:37:41.460
through the compiler. And then you
should have a perfect thing to decode.
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.
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,
00:37:52.330 --> 00:37:56.049
and we want to show this to you.
So we have a demo.
00:37:56.049 --> 00:38:08.240
applause
00:38:08.240 --> 00:38:16.290
One of those windows…
schneider: Alt-Tab…
00:38:16.290 --> 00:38:19.080
Sec: Ich weiß nicht welches
das richtige Fenster ist.
00:38:19.080 --> 00:38:26.880
laughs
Ich bin kurzsichtig!
00:38:26.880 --> 00:38:30.890
Was tust du da?
laughs
00:38:30.890 --> 00:38:34.240
This is really well-prepared.
schneider: Ja, das ist es.
00:38:34.240 --> 00:38:41.760
Sec: So there’s this tool
which you can run on
00:38:41.760 --> 00:38:46.960
the output of our tool chain which
contains the packets, and it shows you
00:38:46.960 --> 00:38:52.450
the frequency and the time of packets
which are supposedly voice frames.
00:38:52.450 --> 00:39:00.250
And then you can just click
a start point and an end point.
00:39:00.250 --> 00:39:02.189
audio playback starts
Female TTS voice: You have five hundred
00:39:02.189 --> 00:39:07.569
and five minutes and 40 seconds left
for this call. Please dial or text 2888
00:39:07.569 --> 00:39:13.319
for more account information. Please wait
while your call is connected. Beep sound
00:39:13.319 --> 00:39:14.979
Male caller voice: incomprehensible …
applause in Congress hall
00:39:14.979 --> 00:39:22.069
the Eagle has landed.
Coast is clear, coast is clear.
00:39:22.069 --> 00:39:25.620
I need to … terminate this
call now ’cause we have problems…
00:39:25.620 --> 00:39:28.660
audio cut off
audio playback ends
00:39:28.660 --> 00:39:35.520
applause
00:39:35.520 --> 00:39:39.360
schneider: Needless to say, this was of
course recorded from this very phone,
00:39:39.360 --> 00:39:43.310
from one of our members at the
Munich CCC knowing what we’re doing.
00:39:43.310 --> 00:39:46.735
So, no problem there.
00:39:57.480 --> 00:40:01.360
Sec: Was muss ich denn drücken?
schneider: Shift-F5!
00:40:01.360 --> 00:40:06.129
Sec: Hallo!? … Ah!
00:40:06.129 --> 00:40:14.720
schneider: So, that’s voice. And… working
quite fine. If you get the packets in,
00:40:14.720 --> 00:40:18.280
and for the decoder no problem.
We can decode that. But there’s still
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.
00:40:24.150 --> 00:40:30.290
But they’re not voice.
hey decode as 100% non-decodable.
00:40:30.290 --> 00:40:37.029
They usually come in trains of three,
so you have on three channels activity
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.
00:40:43.259 --> 00:40:47.190
Might be encrypted voice. There are people
who have the idea maybe they used
00:40:47.190 --> 00:40:52.759
channel-bundling to use some more
bandwidth-intensive cipher.
00:40:52.759 --> 00:40:57.770
If anyone has any idea about that
that would be great … or a device
00:40:57.770 --> 00:41:04.289
which uses this would be
even more interesting.
00:41:04.289 --> 00:41:10.660
Range. Now, we had the phone and
we were traveling a little bit in Germany.
00:41:10.660 --> 00:41:16.490
And at a distance of roughly 300 km
we placed a call. And in fact could
00:41:16.490 --> 00:41:22.710
receive that in Munich. Roughly half
of it, and that puts around this circle
00:41:22.710 --> 00:41:28.430
around Munich where we can receive calls
with Iridium. That’s quite an area. Now,
00:41:28.430 --> 00:41:34.519
there is no encryption at all on the voice
frames, nothing. They just didn’t bother.
00:41:34.519 --> 00:41:39.380
The phone has a little bit of
authentication with usually GSM algorithms
00:41:39.380 --> 00:41:46.249
from the nineties. Nice. But the voice is
unencrypted. So you can bet your ass
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
00:41:49.480 --> 00:41:55.160
but everyone else will listen to you.
Just be aware.
00:41:55.160 --> 00:41:58.960
These things are also available
commercially. We found at least three
00:41:58.960 --> 00:42:04.440
different vendors supplying the stuff.
Probably only to government agencies
00:42:04.440 --> 00:42:10.970
and other… well…
laughs
00:42:10.970 --> 00:42:16.989
I guess if you really want to get
these things you can get them.
00:42:16.989 --> 00:42:23.330
So, future plans: looking at uplink!
At the moment if we take this phone,
00:42:23.330 --> 00:42:28.450
place a call, we get what’s coming down
from the satellite. The uplink has
00:42:28.450 --> 00:42:31.240
a slightly different modulation, at least
in the beginning. We suspect that
00:42:31.240 --> 00:42:34.910
everything else will be the same.
But so far we haven’t looked at that.
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.
00:42:38.359 --> 00:42:44.200
Then, there's the ‘GSM tap for Wireshark’
which is a nice interface to put in
00:42:44.200 --> 00:42:48.900
your own protocol into Wireshark and
decode that. Would be very nice and
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
00:42:53.420 --> 00:42:57.979
and see what’s actually going on on the
network. Decoding unknown packets:
00:42:57.979 --> 00:43:02.940
there’s lots of stuff going on on type
number (2) and type number (0)
00:43:02.940 --> 00:43:08.490
which we don’t know what it’s yet. Really,
the limiting factor there is devices,
00:43:08.490 --> 00:43:13.089
which brings us to the next slide. We
need to get access to more devices and
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 –
00:43:17.559 --> 00:43:21.369
it’s the easiest option to actually see
what’s going on. You know which one
00:43:21.369 --> 00:43:25.420
of these packets is yours, you can decode
these, you can send some special data
00:43:25.420 --> 00:43:31.209
and play around a little bit. That makes
things really easy, in fact. Then,
00:43:31.209 --> 00:43:35.190
signaling, handover and authentication.
We haven’t looked at that at all so far.
00:43:35.190 --> 00:43:39.060
It’s actually not needed, really,
if you just want to get to the data but
00:43:39.060 --> 00:43:43.240
it’s quite interesting, for example
these phones, they look all the time at
00:43:43.240 --> 00:43:47.500
what satellites are available and they’d
chose which satellite they want to use.
00:43:47.500 --> 00:43:51.029
They perform the handovers and all of
these things. We want to have a look
00:43:51.029 --> 00:43:55.619
at that, too. Further reversing the
firmware. There’s lots of stuff to be learned
00:43:55.619 --> 00:44:03.010
from firmware and still I guess we
reversed like 10% of that SBD modem.
00:44:03.010 --> 00:44:07.460
Maybe it has still things to show.
Performance – well, we have already
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.
00:44:13.289 --> 00:44:18.340
Maybe a few bits are missing to get the
whole tool chain working really smoothly.
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
00:44:23.140 --> 00:44:27.190
in our stash and see if there’s something
missing. In general, all the information
00:44:27.190 --> 00:44:32.200
we’ve presented today is public and in the
Github repository. Again, we’re looking
00:44:32.200 --> 00:44:38.529
for specification, and especially products
– Iridium GO, OpenPort devices,
00:44:38.529 --> 00:44:43.999
any SBD enabled device, e.g. Rock Seven
devices, if you have access to this stuff.
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
00:44:48.039 --> 00:44:55.359
there’s also Iridium Burst which might
replace some pagers for some of these
00:44:55.359 --> 00:45:00.549
users. These are modified SBD modems,
they’re passive and you tell Iridium:
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
00:45:05.569 --> 00:45:10.650
to the globe”. And then these devices will
pick it up, undetectable, and we have
00:45:10.650 --> 00:45:16.080
an idea which frames these are. These
are special pager frames, we suspect.
00:45:16.080 --> 00:45:20.670
We see them all around the world,
the same format, probably encrypted,
00:45:20.670 --> 00:45:27.740
but maybe only somehow cobbled-together,
a somehow cobbled-together encoding
00:45:27.740 --> 00:45:31.930
which we haven’t seen yet. So,
that’s going to be very interesting.
00:45:31.930 --> 00:45:36.140
Then, thanks again to tnt, Dieter and
SteveM. That was a great help,
00:45:36.140 --> 00:45:41.010
very inspiring people. Thanks to the
Osmocom guys. Thank you very much!
00:45:41.010 --> 00:45:51.969
applause
00:45:51.969 --> 00:45:55.359
Herald: Thank you for the awesome talk.
Unfortunately, we won’t have any time
00:45:55.359 --> 00:45:58.260
for questions anymore.
Sec: What??
00:45:58.260 --> 00:46:04.180
Herald: But I guess we can
contact you via e-mail or IRC
00:46:04.180 --> 00:46:07.939
or anything else. I’m sorry.
Sec: Why?
00:46:07.939 --> 00:46:14.650
schneider: We’re on time!
Sec: We’re on time, we have 15 minutes left!
00:46:14.650 --> 00:46:21.509
discussion on stage
00:46:21.509 --> 00:46:26.200
Herald: Ooh yeah, I fucked that one up.
We have plenty of time for Q&A!
00:46:26.200 --> 00:46:29.970
applause
00:46:29.970 --> 00:46:33.799
I am really sorry. So please line up
at the microphones and get ready
00:46:33.799 --> 00:46:37.069
to hit Sec and schneider with your
questions. While you do that,
00:46:37.069 --> 00:46:40.759
Signal Angel, is there something that
we should answer for the internet?
00:46:40.759 --> 00:46:46.369
Signal Angel: Yes, there is one
question. There is someone asking
00:46:46.369 --> 00:46:50.019
if the mystery data could be
like sensitive, I don’t know,
00:46:50.019 --> 00:46:54.770
military, police, or something
like a custom codec?
00:46:54.770 --> 00:46:57.279
schneider: We have absolutely no idea.
00:46:57.279 --> 00:47:00.349
Signal Angel: Okay, thanks.
schneider: But… likely!
00:47:00.349 --> 00:47:04.089
Signal Angel: Thanks.
Sec laughs
00:47:04.089 --> 00:47:06.270
Herald: Microphone 2, please.
00:47:06.270 --> 00:47:10.830
Question: Thank you. I heard that the NSA
was trying to secure the Iridium network.
00:47:10.830 --> 00:47:13.099
Where did they go wrong?
00:47:13.099 --> 00:47:15.430
schneider: Securing the Iridium network?
laughs
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
00:47:19.530 --> 00:47:23.920
no attempt to secure it. It’s still
the same stuff that was used
00:47:23.920 --> 00:47:28.250
when it was built. I mean, we see
some messages that we don’t know.
00:47:28.250 --> 00:47:33.500
It’s possible that those are encrypted
communications going on. We can’t tell
00:47:33.500 --> 00:47:37.720
at this point. So, there might be
encrypted communication going on
00:47:37.720 --> 00:47:42.630
in Iridium that we don’t know about.
00:47:42.630 --> 00:47:50.710
Herald: Thank you. Microphone No.3,
in the back there. No, nobody!
00:47:50.710 --> 00:47:55.270
Question: Since it’s conceivable that
you could actually… I mean the actual
00:47:55.270 --> 00:48:00.499
database that’s verifying the
contracts is ground-based.
00:48:00.499 --> 00:48:05.709
Does this mean that if you transmit
a phone call to the satellite,
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
00:48:10.630 --> 00:48:15.340
is allowed to be sent and
relayed, so you should
00:48:15.340 --> 00:48:19.630
typically be able to make
a phone call over the 150 km radius
00:48:19.630 --> 00:48:26.020
that the satellite will repeat
back to earth to… no idea?
00:48:26.020 --> 00:48:33.739
Sec: Actually I don’t really know.
We haven’t gotten that far
00:48:33.739 --> 00:48:37.980
in our protocol understanding to
even be able to try this. But it would
00:48:37.980 --> 00:48:43.869
definitely be interesting to try it.
00:48:43.869 --> 00:48:53.539
Question: I don’t mind throwing a bit
money at that you are gonna try it!
00:48:53.539 --> 00:48:56.930
Herald: Are there any more questions?
Right now I can’t see any of them… oh!
00:48:56.930 --> 00:49:05.040
On microphone No.4 there’s a question!
Someone: No!
00:49:05.040 --> 00:49:09.499
Herald: Then, Signal Angel!
00:49:09.499 --> 00:49:12.859
Signal Angel: Okay, I have currently
got three questions from internet.
00:49:12.859 --> 00:49:18.049
I’m going to start with the first one.
That is: the Code Composer Studio version
00:49:18.049 --> 00:49:23.309
that you found, the old one, whether
it’s specifically to the DSP or…
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?
00:49:27.680 --> 00:49:32.239
schneider: Yes, exactly. At some point
Code Composer Studio dropped
00:49:32.239 --> 00:49:37.499
the support for this specific DSP and
we had to get a very old version
00:49:37.499 --> 00:49:40.630
to have still support for it.
I think it’s CCS version 3.
00:49:40.630 --> 00:49:44.510
Question: Okay!
Herald: So I would say another question
00:49:44.510 --> 00:49:46.560
from microphone No.2.
00:49:46.560 --> 00:49:52.760
Ray: I just wanted to ask: is it legal
to receive these things?
00:49:52.760 --> 00:49:57.930
Sec: This is a very good question!
And I refer to you:
00:49:57.930 --> 00:50:19.299
the ‘Weltraum-Theorie’!
wild applause and cheers
00:50:19.299 --> 00:50:22.539
So as far as I can tell
there’s no problem.
00:50:22.539 --> 00:50:25.430
laughter, applause and cheers
00:50:25.430 --> 00:50:30.539
schneider: And if you have a problem
00:50:30.539 --> 00:50:32.269
we’ll just overrule you.
laughs
00:50:32.269 --> 00:50:42.250
laughter
Sec: Sorry, it’s only in German!
00:50:42.250 --> 00:50:44.069
schneider: Thank you for that question!
Herald: Okay, we have another question
00:50:44.069 --> 00:50:47.900
from the internet.
Signal Angel: Yes, the question is:
00:50:47.900 --> 00:50:53.280
what is the state of being able to
geo-locate Iridium terminals?
00:50:53.280 --> 00:50:59.450
schneider: So, during the Ring Alert
you see where a device gets paged.
00:50:59.450 --> 00:51:04.329
And that’s paging a specific cell.
You know where that cell comes down.
00:51:04.329 --> 00:51:08.680
So that will tell you a rough estimate
where that terminal is.
00:51:08.680 --> 00:51:11.869
Of course the cell is big, many
hundreds of kilometers, so
00:51:11.869 --> 00:51:17.140
probably you can have a look at this
over time and see how the pagings change
00:51:17.140 --> 00:51:21.480
when the cells hit some border.
If the terminal doesn’t move
00:51:21.480 --> 00:51:27.109
you can probably pinpoint it better
using that. We haven’t tried that yet.
00:51:27.109 --> 00:51:32.639
But that’s our guess how it would work.
00:51:32.639 --> 00:51:35.759
Herald: Okay, bevor wir zur nächsten
Frage kommen eine kurze Durchsage
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.
00:51:42.519 --> 00:51:51.280
something shouted from audience
Herald continues in German by accident:
00:51:51.280 --> 00:51:54.750
The next question
from the internet, please!
00:51:54.750 --> 00:51:57.349
Signal Angel: The question is:
is your data that you collected
00:51:57.349 --> 00:52:02.260
available somewhere
for somebody else to have a look at?
00:52:02.260 --> 00:52:09.040
schneider: No. laughs
Okay, so, we won’t publish
00:52:09.040 --> 00:52:12.430
any recordings or anything like that.
00:52:12.430 --> 00:52:17.079
We might publish some samples
of our own messages.
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
00:52:22.039 --> 00:52:26.549
we’ll probably have something.
But, in general,
00:52:26.549 --> 00:52:29.230
you can’t just collect data
and make it public.
00:52:29.230 --> 00:52:34.099
Sec: I mean the great thing about
this Iridium is: just open your window,
00:52:34.099 --> 00:52:37.689
you will get data!
schneider: Pretty much!
00:52:37.689 --> 00:52:40.899
Sec: Lots of data!
00:52:40.899 --> 00:52:44.969
Herald: Then we have another
question at microphone No.3.
00:52:44.969 --> 00:52:49.730
Question: So since recording
the data is obviously legal,
00:52:49.730 --> 00:52:54.810
is it against, like, some policy of Iridium,
that you get angry emails from them?
00:52:54.810 --> 00:52:58.250
Did you have any contact with them?
00:52:58.250 --> 00:53:03.719
schneider: As far as I can tell
they are aware of this,
00:53:03.719 --> 00:53:11.250
and for them it’s a jungle and
I think they just deal with it.
00:53:11.250 --> 00:53:16.480
Or, in fact, who cares?
00:53:16.480 --> 00:53:22.480
GSM has been shown to be insecure
for a long time – what’s the most used
00:53:22.480 --> 00:53:29.439
cellphone network on the planet?
00:53:29.439 --> 00:53:32.640
Herald: Thanks for that answer.
Microphone No.2, please.
00:53:32.640 --> 00:53:39.560
Question: Thank you. We’ve talked about
listening. What about manipulating?
00:53:39.560 --> 00:53:44.319
Sec: As we said we don’t really
have a good understanding
00:53:44.319 --> 00:53:50.880
of all the signaling and more intricate
details of the handover and stuff,
00:53:50.880 --> 00:53:55.210
and the authentication. We haven’t really
looked at this because the data we got
00:53:55.210 --> 00:53:59.729
was so interesting that
we spent our time there.
00:53:59.729 --> 00:54:05.210
There’s probably lots of possibilities
but we haven’t tried anything yet.
00:54:05.210 --> 00:54:09.880
schneider: And I would recommend
to not just try that.
00:54:09.880 --> 00:54:14.259
These things have been built in the
beginning of the nineties and,
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.
00:54:18.230 --> 00:54:23.890
But I wouldn’t. Really.
00:54:23.890 --> 00:54:27.259
Herald: Do we have more
questions from the internet?
00:54:27.259 --> 00:54:41.339
Signal Angel: We do.
The next question is…
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
00:54:45.910 --> 00:54:48.640
if you’ve got a gag order.
00:54:48.640 --> 00:54:53.460
Sec: We have definitely not gotten a gag
order. I have had no contact from anyone
00:54:53.460 --> 00:55:00.930
who is affiliated with Iridium,
or any law at all.
00:55:00.930 --> 00:55:03.779
schneider: I’ve once checked the logs
on my web server and Iridium servers
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
00:55:09.259 --> 00:55:13.949
that was me going over the phone and
downloading something. laughs
00:55:13.949 --> 00:55:20.330
laughter and applause
00:55:20.330 --> 00:55:26.589
Herald: Okay, then, microphone No.2!
There’s just the Microphone Angel. Okay.
00:55:26.589 --> 00:55:30.010
No question from that person.
Then, the internet, please go ahead!
00:55:30.010 --> 00:55:35.619
Signal Angel: Okay, the internet wants to
know how many uplink stations there are.
00:55:35.619 --> 00:55:41.319
Sec: There’s one for civilian
use and one for military use.
00:55:41.319 --> 00:55:44.079
At least as far as
the published information goes.
00:55:44.079 --> 00:55:49.369
schneider: And one more which we
don’t know what it it’s exactly doing
00:55:49.369 --> 00:55:54.549
but it’s near the pole.
mumble in the audience
00:55:54.549 --> 00:55:58.480
Sec: There have been many more in the
past. I mean when they built this thing
00:55:58.480 --> 00:56:03.509
they had one in Japan. But as far
as the documentation goes
00:56:03.509 --> 00:56:06.279
they are all inactive.
00:56:06.279 --> 00:56:10.210
schneider: Yes. You have to know that
Iridium went bankrupt beginning 2000s.
00:56:10.210 --> 00:56:13.820
And at that point they scaled down
the whole thing a lot to make it
00:56:13.820 --> 00:56:16.509
more cost-efficient. And they also
scaled-down the amount of gateways.
00:56:16.509 --> 00:56:19.599
So, sometimes you get references
for lots of gateways for Iridium but
00:56:19.599 --> 00:56:25.440
they’re all inactive. Not sure what
they’re doing with these any more.
00:56:25.440 --> 00:56:29.959
Herald: Okay. I think we have
questions from the internet left?
00:56:29.959 --> 00:56:33.600
Signal Angel: Actually as far
as I know right now we don’t.
00:56:33.600 --> 00:56:39.019
Herald: Great. Then give a warm hand
of applause for Sec and schneider!
00:56:39.019 --> 00:56:47.169
applause
00:56:47.169 --> 00:56:50.359
postroll music
00:56:50.359 --> 00:56:58.201
subtitles created by c3subtitles.de
in the year 2017. Join, and help us!