Sec, schneider: Iridium Update

Listening to satellites and decoding is fun. We show interesting stuff we found, and how you can get into it.

Sec, schneider

32C3 preroll music

Herald: I think hacking satellites is fun.

I think it’s even more fun when
it’s all ‘security by obscurity’.

I would like to present you
Sec and schneider.

Both are members of the Munich CCC.
Sec worked as a security consultant

but he’s probably best known for the
‘Hacker Jeopardy’. Which he has been doing

for more than a decade.
And obviously the rad1o!

applause

And schneider is an awesome developer
for hardware and software.

So, who has been to Camp and
seen the talk about Iridium there?

Please raise your hand.
Wow.

And who has seen
the Iridium talk on 31C3?

Even more people. And who hasn’t
had any Iridium update at all?

Wow. Okay, so without further ado,
here is your yearly Iridium update!

applause
Sec laughs

schneider: Yes, hello, thank you for
coming to this Congress’ edition

of the Iridium talk. laughs We’ve
increased our slot size by 100%

compared to one year ago. And we’ve also,
I guess, increased the amount of content

by quite a bit. In the last
year we’ve got ourselves

some devices to play with from Iridium.
Modems, actually. More than one of them.

A phone, with contract. And that helped
us a lot getting more knowledge

about Iridium. Now, apparently, I guess
half of you haven’t seen any talk

about Iridium from us before. So here’s
a short introduction. Iridium is a global

satellite network made out of Low Earth
Orbit satellites, built by Motorola

in the nineties. It has 66 active logical
satellites. And with ‘logical’ we mean

one satellite can be more than one
satellite in orbit. Maybe it has failed

a little bit and now they have two
satellites in one spot producing

one logical satellite still functioning.
You have worldwide global coverage,

even at the poles, on every place on
earth, on the water – everywhere.

Services: you’ve got messaging, you’ve
got voice, you’ve got internet IP data.

And even some special services which are
broadcast-only, which they only send down

to earth, and the receiver doesn’t receive
anything. Now, Iridium coverage –

there’s a lot of Iridium satellites, and
they produce a spot beam pattern

on the planet. There’s 48 spot beams,
each of them covering roughly 400 km

in diameter. All spot beams together
roughly 4500 km. Now, if you have

a very sensitive setup you can receive
more than one spot beam at the same time.

And that’s going to be another issue
during this talk. If you want to have

a look at this on a global scale you can
see how much area one Iridium satellite

is covering on earth. Quite a lot. And by
receiving them you get a lot of knowledge.

Why look at it? Now. There’s almost
no info about Iridium available online

or in paper, or any way. It’s a completely
proprietary protocol. There’s nothing

about it available. Its worldwide visible.
You go out there you get Iridium signals.

You go to the pole you get Iridium signals.
So it’s nice to have a look at it and

talk about it, and everyone can just go
out and have a look at it. Low barrier

of entry. Cheap RTLSDRs are good enough
to get pager messages from Iridium.

There’s lots of interesting services: the
pagers, Iridium Burst. The devices for that

are passive. They don’t send anything
out. So probably interesting

for Intelligence services also. And
future-proof. There’s nation states

interested in Iridium, namely the United
States and also quite a commercial

venture behind it. There’s going to be
Iridium Next, launched next year.

At least that’s the plan. It’s going
to replace all of the satellites,

66 more satellites. They will de-orbit
the old ones. But still the system will

stay compatible with the current system.
So, worth the effort. Applications.

Tracking, fleet management, mobile data,
emergency services. There are devices

for emergency responders to tell
them where to go, based on Iridium.

Maybe that’s in a helicopter or a plane.
Maritime sensors – very interesting.

With Iridium antennas you don’t have to
point the antenna at a specific point

in the sky. You have something, it can
wobble around, will still work fine.

Aircraft communications – we’ve seen that.
While the spot beams cover all of earth,

apparently they also work 10 kilometers
up, and there’s a lot of applications

for aircrafts. We have been
doing this for almost 2 years.

And one year ago at Congress
we had pager messages. Nice.

We also had the downlink demodulated
and descrambling going on.

The Ring Alert Channel identified, and
some data stuff. Then the rad1o happened.

And really, the rad1o was a secret project
to get more Iridium receivers out there.

That worked great. It has good coverage
on Iridium. It did delay us a little bit, so

after the rad1o we spent a lot of time
again on Iridium. And we got a lot of stuff

going: short-burst data decoding. We've
raided a phone, had a look at that.

We looked at IP traffic on Iridium. And
even got more data out of that SBD modem

than just data which it receives. So.

One year ago this was our recommended
setup: passive antenna and very expensive

bandpass and low noise amplifiers.
That works but since Camp we’ve got

a much better setup: modified GPS
antennas – they’re super cheap,

they work almost out-of-the-box, you
remove one filter, you maybe replace

one of the components in there, you’ve
got a pretty nice Iridium antenna.

Optionally, you can add an Iridium filter
in there and then you can also use it

in busy environments. Just one thing:
if you get one of these antennas

make sure it has screws in it so you can
reseal it again and take it outdoors.

Modifications: you remove one filter,
you get an Iridium patch antenna

– available on Mouser, Digikey… –
that’s no big deal. You solder it in,

you’ve got a nice antenna. We’ve got
this thing documented in our Wiki.

Have a look at that. You will get a good
Iridium antenna. Though, one thing is

potentially…
applause

– thanks! – …missing if you
are in an urban environment

and there’s lots of GSM and UMTS going on
you probably want to add an Iridium filter

in there. Murata actually makes one
specifically for Iridium. You pop that in

and you’ve got a nice and clean signal.
It depends on the environment

but highly recommended.
Now, receiver setups.

Cheapest option: take that antenna,
attach it to an RTLSDR (preferably

E4000 tuner) and you get Iridium
reception. Just a portion of the band,

roughly 20..40%, but still enough
to get a good idea about Iridium.

We’ve started with that, we’ve been
running this for a long time. And,

example for pagers – more
than enough. Next best thing:

“real” SDR: rad1o, HackRF, USRP.
With more coverage.

Passive antenna works with these, they
have a good enough amplifier to do it. But

the cabling must be quite short. You
cannot have many losses in the cable.

So, therefor the really recommended setup
from us is having an active antenna

with an SDR. You can take the antenna
outside, have 5 meters of cable,

put the SDR inside. Weatherproof setup.
You can leave it there. We have

something like that in Munich,
works a treat. Yes.

State of the tool chain: we’ve improved
that quite a lot. It’s a lot speedier now.

We have better signal processing, we get
the signals down a little bit nicer, faster,

and also now have the option to cover
a much wider band of Iridium,

like the whole band. And now it’s feasible
for us to actually decode everything

on the Iridium. Not real-time, that’s way
too much computing effort now. But we can

put it on a disk and decode it then. For
real-time processing really a major effort

has still to be done. But,
well, we’ll see what happens.

applause

Continuing on that… to make use of
modern multi-core processors we’ve added

a Queue in there. And you can utilize
as many cores as you want to decode

Iridium signals. Just one thing: the stuff
on the left still runs on a single CPU,

or a single core. And that’s limiting us in
terms of what we can do. But really,

most faster cores right now can handle the
whole Iridium band, so, should be fine.

We had a play with an Iridium test set.
Dieter from the Osmocom guys got one.

We had a play session. That was
a real boost. He also helped us a lot

on the Link Control Word (LCW) and other
stuff to decode. That gave us a boost.

At the beginning of this year, just before
doing the rad1o, and got a lot off of that.

Barrier Air recommended (?) these
devices, nice. Now, SBD modems.

We got ourselves a few of these things.
They’re ‘Short Burst Data modems’.

‘Short Burst Data’ means that you get
little packets of data. You can send it

to the satellite, the satellite can send it
back to you. They’re used all over the place

for all kinds of services for Iridium.
These ones are specifically cheap.

We got a group order going, from SteveM,
also Osmocom guy. 50 Euros per piece,

was rather cheap. Now, the thing is
these are really simple SBD modems.

They don’t have a SIM card. They
really rely only on the internal IMEI.

They don’t have a secret in there,
or nothing else… anything else.

They don’t authenticate themselves
against the network, the network doesn’t

authenticate it[self] against the modem.
Nothing. You supply your contract guy

with your IMEI, and you get a contract
for that thing. Really interesting.

This modem also has debug interfaces,
a test port interface which we found

interesting because it was mentioned in
the documentation, quote: “maybe

you can change the IMEI, or stuff
like that”. Interesting. It runs

over the Digital Peripheral Link (DPL)
which is like some other multiplex thingy

over that, which is actually a physical
link. And in there, there’s the TPI.

There’s absolutely no documentation
available about TPI. There’s a small bit

of documentation about DPL for
another device. We had a look at that.

DPL format then looks like that: You
have a start byte, a length, data, checksum

and an X. So that’s pretty easy. That
was fast implement. But the TPI stuff

was more tricky, so we had to get into
the firmware. During the OsmoDevCon

tnt got into extracting firmware from an
update image, and we had a look at that.

And really, you get a table of
TPI commands and most of them are

not implemented but some are. And
after reversing a lot of the firmware

we figured out where to go and where to
look for the EEPROM stuff. And now

we have on Github available TPI support
for this modem. You can change the IMEI,

so what you can do is get a contract for
one modem, take another modem, you clone

this modem onto that modem, now you have
a contract for two modems. Interesting.

laughter and applause

And also these IMEIs are not… I mean

they are blocks, probably you can
guess one. You shouldn’t do that.

I think that’s a big hole. They did that
on purpose. There are modems with SIM.

They authenticate themselves against
the network. But that’s about it.

And who knows how secure that is. We’ll
have a look at that at some point later.

The code is on Github but
not quite everything. laughs

Then there’s another thing. There’s a debug
interface. It spits out debug information

all the time. You enable it also via
writing to some EEPROM location.

And if you do that what it spits at you
is this. From 1990, really! laughs

Interesting. So this stuff evolved quite
a lot. So we’re now 25 years later

and this code is still running. If you
enable all of the debug information

you get lots of stuff.
First two lines: Ring Alert channel.

This we had decoded already,
earlier this year, most of it.

It proved that most of the stuff we did
is right. We also got more stuff,

broadcast channel, some sync packets,
traffic channels. Some of these information

you already have integrated
into the tool chain. Not all of it yet,

but this firmware is a real nice thing

to get data from.
Packets.

Iridium has 10.5 MHz of bandwidth. At
the moment they’re using ca. 8.5 MHz,

at least in Europe. We see roughly 2,000
detected bursts per second on average.

And we decode of these roughly
1,200 into Iridium frames.

And roughly 80% of these don’t have severe
errors, so we can get a link control word

or decode some stuff –
at least categorize it.

If you look at that this is
a four-minute interval on Iridium.

The whole band; these are roughly
a few hundred thousand packets,

so there’s quite a lot going on.
At the top you see the pager channels.

Every 20 seconds this small burst on the
Ring Alert Channel, always active, and

then down there there’s data channels,
broadcast channels and more of this stuff.

Last year we looked at pager channels,
that’s only 500 kHz of data.

Now we’re looking at 10 MHz, that’s
not going to be done in real time

with our current tool chain. Right now,
we can look at roughly 2 MHz, do it

in real time, so that you get a good idea
about Iridium. There’s a lot of room

for improvement, at least that’s what you
think. So if someone wants to help us there

we are happy about to do that.
At the moment it’s good enough for us

to get more data
out of the Iridium system.

We usually just record to hard disk,
get the data off. It’s lots of data.

I mean, you have to think about 80 GB
per hour if you capture the whole band.

So you only can do that for specific
things, if you maybe want to have

one transaction of a modem. We’re
only looking at the downlink but

at the same time Iridium suggests that
people use their service so that it goes

up to the satellite, across to another
satellite, and down again. Because

that will save them bandwidth on their
single gateway somewhere in the U.S.

And now Sec will tell you more
about different frame types.

applause

Sec: Thank you. So we’re
going to look a little bit into

what is all coming down
from the Iridium satellites.

I mean, a little bit of it
we already know. Like…

this is the overview of the packets.
I mean, schneider already told you

the small bits at the top, the green
ones are the pager channel where

all the pager messages come, which
were part of our last year’s talk.

The red below that is the Ring Alert
channel. And then we have

categorized the other traffic, like
the blue are the Broadcast channels.

Interestingly, not all of the frequencies
are used at the same time, but

that changes over time. And then
we have several things like blocks

of IP packets, blocks of streams of voice
packets, and other data packets. And

now we are going to look at them one by
one. The first is the Pager Message frames

which are already known from the talk.
We identified them, they start with

a unique pattern at the beginning,
which is hex 9669 encoded

as binary phase-shift keying (BPSK). And
our cool tool chain decodes them, and

this is the message I think we used last
year. It’s not very interesting, it was

just for testing. There’s not much to say
about this, I think that’s more or less

completely solved. Then we have…
Oh, what I wanted to say is that

Iridium doesn’t really want you to use
this anymore. They say: “If you can

get a pager [device] somewhere, then we
will still honor it but you can’t get one

from us!” That makes them hard to
get, maybe a little bit expensive but

they’re still in use. I mean we see lots
of messages going on. Then there are

the Ring Alert frames. We can’t identify
them by looking at them alone.

We identify them by the frequency
range they’re in. This is a little bit

like randomly guessed
where the best cut-off point is.

The format is mostly known from our play
session with the Racal thing we showed you

before. Dieter took a lot of work from
us [off us] by reversing the firmware

and getting us info how to decode
this. We did a brief overview

at the Camp talk. The frames
look like this. laughs

It contains mostly information like the
current satellite and the beam you are

seeing at the moment. Then it contains
the position which alternates between

the position where the satellite is at and
the position where the beam that you are

currently seeing hits the earth. So that
could, in theory, be used for geolocation

but it’s really, really very broad
information. I mean you could probably

average this or something like that.
And then it also contains the pages,

so when the network wants a device
to contact the network because it has

some information for it it sends the PAGE
message. Unfortunately, that TMSI,

that’s a temporary identity, so we can’t
really tell you which actual device it is.

We intend to look into how this
is mapped in the future, but

we didn’t have time for it. This is
as the Ring Alert channel sends

the Beam ID. You can see as a satellite
passes over our receiver. Which Beam IDs

we see you can see that depending
on the noise and whatever…

you can also see several spot beams at the
same time, or shortly after each other.

The next part of the family of packets
are the Broadcast frames.

We can identify them by
a checksum, a BCH checksum.

The polynomial is 1207 which is actually
the bit-reverse of the polynomial that’s

used to protect the messaging
packets. I don’t really know why but

it helps to distinguish those packets.
Most info about those packets are also

taken from the Racal Test Set firmware.
We’ve also shown them at the Camp talk

very briefly. They look like this!

They contain information about the
network where it tells the devices

what frequency offset they have and what
timing offset they have, to correct for this,

or what power they are receiving so they
can adjust the power. That’s not really

our focus at the moment because that’s
boring stuff like about the internals

of the network. And the interesting
stuff are the data frames.

We can identify them, they have a valid
Link Control Word. I mean, at the beginning

a special set of bits that is protected

by BCH checksum but before you get to the
correct bits you have to re-sort those bits,

and it’s the most bizarre scrambling of
bits I’ve seen so far, and I have no idea

how they came up with this order. If anyone
has an idea I would be offering a beer.

This is three different parts and the
content after the Link Control Word

is always 312 bits long which is
the maximum packet length.

If you look at the descrambled Link
Control Word those three parts

are protected by separate
BCH checksum polynomials,

like the first 29, and then
465 and 41.There’s

one interesting thing: the middle part of
the Link Control Word is missing one bit.

Fortunately, the BCH checksum can correct
bit errors, so you’re expected to have like…

in half of the packets you’re expected
to have a bit error there because they

obviously didn’t have the space to fit
this bit and just dropped it on the floor.

The first part of the Link Control Word
which is three bits long – that gives us

eight choices – is the Sub-type of
the data frame. That we can use

to differentiate the packets.
The second and third part contain

more network information about handoff
and acquisition channel and stuff

which we took from the TPI debug code
that schneider mentioned before.

But we’re not too interested in that
network management stuff at the moment.

So we are going through the Sub-types of
the data packets now, starting at the top,

the ‘Sub-type 7’. This is just
a synchronization packet.

If you look at the packet in a waterfall
diagram you can see that it’s

a single line which can be used by the
receiver to get frequency offsets and stuff.

It’s about 43% of all the
data packets we see.

It’s just alternating 0 and 1 bits, and
our tool chain just decodes them as it’s

a sync packet, and all the bits were as
expected so it’s also not very interesting.

The next Sub-type we see is (3).
We don’t see (4) to (6),

we have not seen them anywhere. The
Sub-type 3 is packets that look like this.

And they have a little bit [of] information
at the beginning, and a little bit more

information at the end. So to me it looks
like one of those two parts is supposedly

a checksum but I have no idea what’s
encoded there. We have found no information

and, maybe at some later date.
The next Sub-type…

– Oh I forgot! The next Sub-type

is Sub-type 2 which is…
the packets are descrambled,

I mean the same descrambling algorithm
as we had before at the Pager channel,

just in three different blocks, and is
again protected with a BCH checksum

with yet another polynomial. I can give
a whole other talk about reversing

BCH checksums and CRCs now.
laughs

After the BCH checksum is removed
there’s a CRC which protects this again.

It’s a common polynomial, the CCITT
polynomial. And the packet then has

a little bit header at the beginning which
is in blue, and the CRC of this packet

is okay. And the header has fields
that we don’t know but one field is

the 3 bit counter. That can be used
to reassemble longer packets.

This is one example. We have several
packets and the counter… we sorted them

by this counter so we can reassemble
them into a larger packet.

If you then look at the thus
reassembled packets they have

what I call an identifier, of 2 bytes at
the start of the datagram which identifies

which kind of data is in there. We’ve seen
about 40 different identifiers so far,

roughly. Most of them we still
don’t know what’s in there.

That’s about 70% of the stuff
we see inside the data packets.

Many are empty, they consist of Zeros.
Even some of them don’t have a valid CRC,

there are just Zeros where the CRC is
supposed to be. We will be looking at those

later on but we’ve identified some
identifiers which contain interesting stuff.

The first one of those is 09.01
which contains SMS messages.

We did lease us a telephone and just sent
some SMS, and looked at what comes down.

This is one re-assembled SMS message.
And if you put it into our current tool chain

it results in this output. The format is
very similar to the SMS PDU format

used in GSM. The only difference is
the orange bytes which are not part

of the PDU format and we just removed
them. And if you remove them

this comes out. This is
just the decoded message.

applause

So, the green numbers, one is the SMSC
Centre Number, and the other is

the Sender Number. And date and time
when it was sent. And the blue numbers

are just length indicators. The message
is encoded in the 7-bit GSM alphabet

which is basically ASCII except
for umlauts and other stuff. Then

the other identifier we got is 76.08 which
contains short burst data messages

which are sent by those modems that
schneider showed you. Those modems…

SBD messages itself can be from the
specification 1960 or 1890 bytes,

depending if they’re mobile-originated or
mobile-terminated. That means send them

from a modem or receive them with a modem.
But the one we have can only send

messages up to 340 or 270 bytes. Still
this is longer than what the reassembled

3 bit counter gives us. So we have another
type for continuation of those messages.

And then we have the SBD message,
if you want to send it. The interface is

very simple. You just send an email to
[e-mail], put the IMEI

you want to send it to in the subject,
and put an attachment on it, and it gets

sent out. You can also have a contract
where you send it via just TCP connection

to an IP port. That works in both
directions. You can send it from the modem

to test your computer, or the other way
but Iridium-side… while there is

some documentation where you have to
connect to they have a firewall which is

source IP based, so if you just send
something you cannot reach random people’s

SBD modems. Many applications that we’ve
seen use probably transfer from SBD modem

to SBD modem. As we are only looking
at the downlink we can still see those

messages as they’re coming down to
another modem. And the cost of this thing

is about roughly $1 per kilobyte, which
I think reminds me of the nineties’

internet costs. laughs
We have an example SBD message

that is not very interesting. It looks like
this if you put it through our tool chain.

It contains lots of Zero bytes because
that was of one of our test messages,

to check for the CRCs
and the continuation stuff.

The users we found for this is
stuff like buoys for tuna fishing,

or standalone GPS trackers that send
just NMEA sentences of GPS over SBD.

And this Moving Map System which is
used by the helicopters from the ADAC

to tell the pilot where to go,
where the next emergency is.

We have two more Sub-types to go.
The Sub-type 1 packets are protected

with a 24 bit frame checksum, yet another
CRC polynomial that had to be reversed.

And then when you find it you’ll find out
that, hey, it’s the same one that GSM uses.

The header of those packets contains
an 8 bit counter for reassembly.

So you can reassemble more packets.
And a length. The raw data itself

is bit-reversed, so we have to reflect
each byte. And if you look at it

maybe some of you already realized
what this looks like. And otherwise

it could have been a Jeopardy question.
So, on the next slide – yes it is PPP –

so they’re just transmitting PPP over the
serial line that they have on the air.

It can also do multilink PPP, and it can
also do like a raw telnet connection,

like just a stream of bytes. Luckily for
us Wireshark supports this PPP dump format

and we tested it with Linux and had our
PPP connection and put this into Wireshark

and – hey! yeah! – we can see the HTTP
request. Wireshark is a little bit annoyed

of the fact that we’re missing half of the
connection, but that’s not a problem.

The unfortunate problem of this is,
on the next slide, nobody uses Linux.

Windows also uses PPP but Windows
also uses the Microsoft point-to-point

compression protocol. The Microsoft
point-to-point compression protocol

has one problem: Wireshark can’t decode
it. It just says “compressed data”.

So I went and looked it up. And
– why is the slide here?

Go one slide farther. The Microsoft
PPP compression is not that difficult.

There’s an RFC for it. It’s a very simple
algorithm but someone just needs to do it.

We didn’t have the time, maybe someone
can do it. Otherwise we’ll have to do it

next year. The other stuff we found,
you will remember the green blobs for IP,

this is probably multi-link PPP (MLPPP),
we have seen up to 14 channels active

at the same time. We have not gotten
around to looking at this very much

but I think it’s a lot of traffic. So
now that we’ve had this there’s…

I told you it’s not all PPP on it,
there’s also non-PPP traffic which is…

You can’t see the string coming
around and it looks like a Cisco

which is telnetting somewhere. Why
is there a Cisco telnet somewhere?

And if you look around on the internet you
can find some slides where people are

describing the setup, and –hey!–
there’s actually a Cisco on site

at the Iridium people, and if you do that
connection the Cisco actually executes

a telnet command to somewhere.
applause

And the last Sub-type we have
is the Sub-type 0. And this is

the interesting part of the talk.
It’s just… voice!

And it’s just 312 bit maximum length
of raw voice data. The problem here is

that there’s a voice codec, an AMBE voice
codec which is completely undocumented.

It has a very low bit rate. And we were
stumped and had no idea how to decode this.

And so there were several different
options. The first option was:

other people can do it for us!!
Luckily, AMBE is a family of codecs, and

tnt did really great work in osmo-gmr and
Thuraya which is a similar AMBE codec.

And you can go and see his talk from
last year about this. And we gave him

some sample files, and in record time
we got the first version of a decoder

for Iridium voice frames. He’s releasing
his code right for this Congress.

This is the repository. It should be
accessible by now. This is very fast

and has good quality. It’s not perfect,
applause

but it’s good.
ongoing applause

But wait! We have more.
So the next option is emulation.

As you have seen before we’ve got the
firmware for the SBD modem. Interestingly,

on the SBD modem there’s the whole
DSP code also, also the voice codec.

It’s also on there. So this is an TI DSP
chip which has really, really ugly

assembler code. But there is an now
unavailable – except if you know

the right people – version of Code Composer
Studio, a Windows software to emulate

this DSP chip. And also with the help
of tnt you can get the stuff running.

This is the Windows software. It looks
very Windows-software-like. laughter

And you can run the codec in there
and it produces the same output

as a telephone would.
The only problem is this thing is slow!

It takes about… more than one minute
to process a second of voice data.

Yeah, this is not fun. And it’s not really
automatable. You have this Windows software

and have to click somewhere, and mhmm…

Now, you don’t want to do this.
It’s roughly three or four weeks ago

[that] I thought: “maybe there’s a third
option?” And the third option is to use

the DSP code but, we don’t want to
understand it, but maybe we can just

“wing it” and emulate it
by translating into crappy C,

and the optimizer will fix it.
It will run fast.

laughter and applause

There’s documentation for this chip which
describes the CPU and the opcodes.

And then you just write a small little
Perl script which looks partly like this.

It takes the object dump output which has
the assembler code and then returns

parts of C, and puts them all into a file,
and we put it all into the compiler,

and –hey!– we’ve got an option which produces...
bit perfect decoder,

and it’s running really fast!
The optimizer does it.

applause

The only problem is that
you need the DSP code for it.

So it’s not entirely free because we
can’t really redistribute it. I suspect

that nobody really cares about this
old codec but I don’t want to risk it.

But the firmware updates for like the SBD
modem are for free on the internet.

So it’s just a matter of a little shell
script that grabs the firmware and puts it

through the compiler. And then you
should have a perfect thing to decode.

I didn’t get around to write this shell
script yet but it will be there soon.

If not you can pesten (?) me and I will do it.
And now we have perfect voice decoding,

and we want to show this to you.
So we have a demo.

applause

One of those windows…
schneider: Alt-Tab…

Sec: Ich weiß nicht welches
das richtige Fenster ist.

laughs
Ich bin kurzsichtig!

Was tust du da?
laughs

This is really well-prepared.
schneider: Ja, das ist es.

Sec: So there’s this tool
which you can run on

the output of our tool chain which
contains the packets, and it shows you

the frequency and the time of packets
which are supposedly voice frames.

And then you can just click
a start point and an end point.

audio playback starts
Female TTS voice: You have five hundred

and five minutes and 40 seconds left
for this call. Please dial or text 2888

for more account information. Please wait
while your call is connected. Beep sound

Male caller voice: incomprehensible …
applause in Congress hall

the Eagle has landed.
Coast is clear, coast is clear.

I need to … terminate this
call now ’cause we have problems…

audio cut off
audio playback ends

applause

schneider: Needless to say, this was of
course recorded from this very phone,

from one of our members at the
Munich CCC knowing what we’re doing.

So, no problem there.

Sec: Was muss ich denn drücken?
schneider: Shift-F5!

Sec: Hallo!? … Ah!

schneider: So, that’s voice. And… working
quite fine. If you get the packets in,

and for the decoder no problem.
We can decode that. But there’s still

lots of stuff we don’t… we’re not able to
decode. And they look like voice frames.

But they’re not voice.
hey decode as 100% non-decodable.

They usually come in trains of three,
so you have on three channels activity

with things that looks like voice. It’s not
– so what is it? We have no idea at all.

Might be encrypted voice. There are people
who have the idea maybe they used

channel-bundling to use some more
bandwidth-intensive cipher.

If anyone has any idea about that
that would be great … or a device

which uses this would be
even more interesting.

Range. Now, we had the phone and
we were traveling a little bit in Germany.

And at a distance of roughly 300 km
we placed a call. And in fact could

receive that in Munich. Roughly half
of it, and that puts around this circle

around Munich where we can receive calls
with Iridium. That’s quite an area. Now,

there is no encryption at all on the voice
frames, nothing. They just didn’t bother.

The phone has a little bit of
authentication with usually GSM algorithms

from the nineties. Nice. But the voice is
unencrypted. So you can bet your ass

that if you place a call on Iridium
not only will the U.S. listen to you

but everyone else will listen to you.
Just be aware.

These things are also available
commercially. We found at least three

different vendors supplying the stuff.
Probably only to government agencies

and other… well…
laughs

I guess if you really want to get
these things you can get them.

So, future plans: looking at uplink!
At the moment if we take this phone,

place a call, we get what’s coming down
from the satellite. The uplink has

a slightly different modulation, at least
in the beginning. We suspect that

everything else will be the same.
But so far we haven’t looked at that.

Shouldn’t be a big deal, we just need to
take some time and actually do that.

Then, there's the ‘GSM tap for Wireshark’
which is a nice interface to put in

your own protocol into Wireshark and
decode that. Would be very nice and

we’re already working on that. So you can
have a nice view in Wireshark, do filters

and see what’s actually going on on the
network. Decoding unknown packets:

there’s lots of stuff going on on type
number (2) and type number (0)

which we don’t know what it’s yet. Really,
the limiting factor there is devices,

which brings us to the next slide. We
need to get access to more devices and

we have some on our list to have a look
at. Because if you have a device –

it’s the easiest option to actually see
what’s going on. You know which one

of these packets is yours, you can decode
these, you can send some special data

and play around a little bit. That makes
things really easy, in fact. Then,

signaling, handover and authentication.
We haven’t looked at that at all so far.

It’s actually not needed, really,
if you just want to get to the data but

it’s quite interesting, for example
these phones, they look all the time at

what satellites are available and they’d
chose which satellite they want to use.

They perform the handovers and all of
these things. We want to have a look

at that, too. Further reversing the
firmware. There’s lots of stuff to be learned

from firmware and still I guess we
reversed like 10% of that SBD modem.

Maybe it has still things to show.
Performance – well, we have already

mentioned it, lots of stuff to do. Now,
the code is on Github, almost all of it.

Maybe a few bits are missing to get the
whole tool chain working really smoothly.

So if you discover that jump into the IRC
channel, bug us and we’ll have a look

in our stash and see if there’s something
missing. In general, all the information

we’ve presented today is public and in the
Github repository. Again, we’re looking

for specification, and especially products
– Iridium GO, OpenPort devices,

any SBD enabled device, e.g. Rock Seven
devices, if you have access to this stuff.

If you can lend that to us for like two
weeks, would be very nice. And then

there’s also Iridium Burst which might
replace some pagers for some of these

users. These are modified SBD modems,
they’re passive and you tell Iridium:

“Hey, send me this message to Europe, send
me this message to the U.S. or maybe

to the globe”. And then these devices will
pick it up, undetectable, and we have

an idea which frames these are. These
are special pager frames, we suspect.

We see them all around the world,
the same format, probably encrypted,

but maybe only somehow cobbled-together,
a somehow cobbled-together encoding

which we haven’t seen yet. So,
that’s going to be very interesting.

Then, thanks again to tnt, Dieter and
SteveM. That was a great help,

very inspiring people. Thanks to the
Osmocom guys. Thank you very much!

applause

Herald: Thank you for the awesome talk.
Unfortunately, we won’t have any time

for questions anymore.
Sec: What??

Herald: But I guess we can
contact you via e-mail or IRC

or anything else. I’m sorry.
Sec: Why?

schneider: We’re on time!
Sec: We’re on time, we have 15 minutes left!

discussion on stage

Herald: Ooh yeah, I fucked that one up.
We have plenty of time for Q&A!

applause

I am really sorry. So please line up
at the microphones and get ready

to hit Sec and schneider with your
questions. While you do that,

Signal Angel, is there something that
we should answer for the internet?

Signal Angel: Yes, there is one
question. There is someone asking

if the mystery data could be
like sensitive, I don’t know,

military, police, or something
like a custom codec?

schneider: We have absolutely no idea.

Signal Angel: Okay, thanks.
schneider: But… likely!

Signal Angel: Thanks.
Sec laughs

Herald: Microphone 2, please.

Question: Thank you. I heard that the NSA
was trying to secure the Iridium network.

Where did they go wrong?

schneider: Securing the Iridium network?
laughs

Sec: As far as we can tell, at least the
parts that we looked at, there was

no attempt to secure it. It’s still
the same stuff that was used

when it was built. I mean, we see
some messages that we don’t know.

It’s possible that those are encrypted
communications going on. We can’t tell

at this point. So, there might be
encrypted communication going on

in Iridium that we don’t know about.

Herald: Thank you. Microphone No.3,
in the back there. No, nobody!

Question: Since it’s conceivable that
you could actually… I mean the actual

database that’s verifying the
contracts is ground-based.

Does this mean that if you transmit
a phone call to the satellite,

that it has to first re-transmit it back
to earth in order to verify that data

is allowed to be sent and
relayed, so you should

typically be able to make
a phone call over the 150 km radius

that the satellite will repeat
back to earth to… no idea?

Sec: Actually I don’t really know.
We haven’t gotten that far

in our protocol understanding to
even be able to try this. But it would

definitely be interesting to try it.

Question: I don’t mind throwing a bit
money at that you are gonna try it!

Herald: Are there any more questions?
Right now I can’t see any of them… oh!

On microphone No.4 there’s a question!
Someone: No!

Herald: Then, Signal Angel!

Signal Angel: Okay, I have currently
got three questions from internet.

I’m going to start with the first one.
That is: the Code Composer Studio version

that you found, the old one, whether
it’s specifically to the DSP or…

it’s… basically… did the DSP support go
away or what’s the deal with this version?

schneider: Yes, exactly. At some point
Code Composer Studio dropped

the support for this specific DSP and
we had to get a very old version

to have still support for it.
I think it’s CCS version 3.

Question: Okay!
Herald: So I would say another question

from microphone No.2.

Ray: I just wanted to ask: is it legal
to receive these things?

Sec: This is a very good question!
And I refer to you:

the ‘Weltraum-Theorie’!
wild applause and cheers

So as far as I can tell
there’s no problem.

laughter, applause and cheers

schneider: And if you have a problem

we’ll just overrule you.
laughs

laughter
Sec: Sorry, it’s only in German!

schneider: Thank you for that question!
Herald: Okay, we have another question

from the internet.
Signal Angel: Yes, the question is:

what is the state of being able to
geo-locate Iridium terminals?

schneider: So, during the Ring Alert
you see where a device gets paged.

And that’s paging a specific cell.
You know where that cell comes down.

So that will tell you a rough estimate
where that terminal is.

Of course the cell is big, many
hundreds of kilometers, so

probably you can have a look at this
over time and see how the pagings change

when the cells hit some border.
If the terminal doesn’t move

you can probably pinpoint it better
using that. We haven’t tried that yet.

But that’s our guess how it would work.

Herald: Okay, bevor wir zur nächsten
Frage kommen eine kurze Durchsage

an die Tür-Engel: Der Saal ist voll, liebe
Tür-Engel, bitte lasst niemanden mehr rein.

something shouted from audience
Herald continues in German by accident:

The next question
from the internet, please!

Signal Angel: The question is:
is your data that you collected

available somewhere
for somebody else to have a look at?

schneider: No. laughs
Okay, so, we won’t publish

any recordings or anything like that.

We might publish some samples
of our own messages.

I mean, you’ve seen a few
on the slides now. If you bug us on IRC

we’ll probably have something.
But, in general,

you can’t just collect data
and make it public.

Sec: I mean the great thing about
this Iridium is: just open your window,

you will get data!
schneider: Pretty much!

Sec: Lots of data!

Herald: Then we have another
question at microphone No.3.

Question: So since recording
the data is obviously legal,

is it against, like, some policy of Iridium,
that you get angry emails from them?

Did you have any contact with them?

schneider: As far as I can tell
they are aware of this,

and for them it’s a jungle and
I think they just deal with it.

Or, in fact, who cares?

GSM has been shown to be insecure
for a long time – what’s the most used

cellphone network on the planet?

Herald: Thanks for that answer.
Microphone No.2, please.

Question: Thank you. We’ve talked about
listening. What about manipulating?

Sec: As we said we don’t really
have a good understanding

of all the signaling and more intricate
details of the handover and stuff,

and the authentication. We haven’t really
looked at this because the data we got

was so interesting that
we spent our time there.

There’s probably lots of possibilities
but we haven’t tried anything yet.

schneider: And I would recommend
to not just try that.

These things have been built in the
beginning of the nineties and,

I’m not sure. Maybe just before they
de-orbit it, so one can have a play.

But I wouldn’t. Really.

Herald: Do we have more
questions from the internet?

Signal Angel: We do.
The next question is…

Somebody wanted to know if you… well, they
think you know more than you tell and ask

if you’ve got a gag order.

Sec: We have definitely not gotten a gag
order. I have had no contact from anyone

who is affiliated with Iridium,
or any law at all.

schneider: I’ve once checked the logs
on my web server and Iridium servers

did access some of my files. Then I got
a little bit scared. And then I realized

that was me going over the phone and
downloading something. laughs

laughter and applause

Herald: Okay, then, microphone No.2!
There’s just the Microphone Angel. Okay.

No question from that person.
Then, the internet, please go ahead!

Signal Angel: Okay, the internet wants to
know how many uplink stations there are.

Sec: There’s one for civilian
use and one for military use.

At least as far as
the published information goes.

schneider: And one more which we
don’t know what it it’s exactly doing

but it’s near the pole.
mumble in the audience

Sec: There have been many more in the
past. I mean when they built this thing

they had one in Japan. But as far
as the documentation goes

they are all inactive.

schneider: Yes. You have to know that
Iridium went bankrupt beginning 2000s.

And at that point they scaled down
the whole thing a lot to make it

more cost-efficient. And they also
scaled-down the amount of gateways.

So, sometimes you get references
for lots of gateways for Iridium but

they’re all inactive. Not sure what
they’re doing with these any more.

Herald: Okay. I think we have
questions from the internet left?

Signal Angel: Actually as far
as I know right now we don’t.

Herald: Great. Then give a warm hand
of applause for Sec and schneider!

applause

postroll music

subtitles created by c3subtitles.de
in the year 2017. Join, and help us!