*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 data@sbd.iridium.com, 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!*