gsm

The big GSM write-up – how to capture, analyze and crack GSM? – 4.

So. I had some requests asking me about how I did what I did with GSM. What tools did I use, what hardware and what options?
Since I believe strongly that GSM needs to be “out in the hands of the people” meaning everybody should have access to cheap hardware and free, opensource software that helps understanding GSM in practice I thought I will create a series of write-ups describing the whole process from the beginning.
Enjoy! :-)

DISCLAIMER: EVERYTHING DESCRIBED HERE IS ONLY FOR EDUCATION PURPOSES. ONLY DECODE YOUR OWN DATA, NEVER TRY TO DECODE ANY DATA THAT IS NOT YOURS/YOU DON’T HAVE PERMISSION TO DECODE, RESPECT THE PRIVACY OF OTHERS!
I don’t take responsibility for how you use the konwledge you gained here.

Fourth step: Capture data with RTL-SDR, decode it with airprobe

As it could be read on RTL-SDR.com (I modified the original text with some enhancements):

Receive a Live Channel

First of all we need to find the frequency of the channel we are going to decode. There are a lot of both online and offline tools to convert an ARFCN number to actual frequency. Here I am going to use an offline tool called arfcncalc:

./arfcncalc -d -a ARFCN

Naturally instead of ARFCN you need to specify the ARFCN number, the -d switch tells the program to give us the downlink frequency (-u would give us the uplink).

To decode a live channel using RTL-SDR type in terminal

./gsm_receive_rtl.py -s 1e6 -f FREQUENCY

A new window will pop up, click in the middle of the GSM channel in the Wideband Spectrum window. Within a few seconds some GSM data should begin to show constantly in wireshark. Type ./gsm_receive_rtl.py -h for information on more options. The -s flag is used here to set the sample rate to 1.0 MSPS, which seems to work much better than the default of 1.8 MSPS as it seems that there should be only one GSM peak in the wideband spectrum window.

GSM Decoding with Airprobe and Wireshark and RTL-SDR Software Defined Radio

If you have trouble getting data, but receive many errors like

sch.c:260 ERR: conv_decode 12

then you should calibrate your RTL-SDR stick using the kalibrate-rtl program, described here.

After you determined the offset of your RTL-SDR calculate average of the different offset values. You will get something like this for example: +24.7 kHz. This actually is 24700 Hz, the plus means that the RTL-SDR tunes itself generally around 24700 Hz ABOVE the frequency you set it on, so you need to SUBTRACT this frequency from the result you got with ARFCNcalc. If your average offset is negative then naturally you need to ADD the average offset to the result of ARFCNcalc instead of subtracting it.

Use the new frequency to fire up RTL-SDR again, and let it warm up for some minutes. You should see some improvement compared to the first, uncalibrated test.

Capturing a cfile with the RTL-SDR (Added: 13/06/13)

I wasn’t able to find a way to use airprobe to capture my own cfile. I did find a way to capture one using ./rtl_sdr and GNU Radio however.

First save a rtl_sdr .bin data file using where -s is the sample rate, -f is the GSM signal frequency and -g is the gain setting. (rtl_sdr is stored in ‘gnuradio-src/rtl-sdr/src’)

./rtl_sdr /tmp/rtl_sdr_capture.bin -s 1.0e6 -f 936.6e6 -g 44.5

Next, download this GNU Radio Companion (GRC) flow graph (scroll all the way down for the link), which will convert the rtl_sdr .bin file into a .cfile. Set the file source to the capture.bin file, and set the file output for a file called capture.cfile which should be located in the ‘airprobe/gsm-receiver/src/python’ folder. Also, make sure that ‘Repeat’ in the File Source block is set to ‘No’.

Now execute the GRC flow graph by clicking on the icon that looks like grey cogs. This will create the capture.cfile. The flow chart will not stop by itself when it’s done, so once the file has been written press the red X icon in GRC to stop the flow chart running.

After we have the cfile we can actually decode it just like as it was captured using a USRP, so you need to fire-up Wireshark listening on lo (localhost) and say:

./go.sh capture.cfile 64 0B

It will probably work for you just fine, data will flow into Wireshark as expected. The 64 is the decimation rate of the RTL-SDR, 0b is the configuration go.sh is going to use: 0 means Timeslot 0 (beacon channel), b is the configuration the cell uses on the beacon channel (see the ‘Signaling Channel Mapping’ in this chapter of ‘Introduction to GSM’ to see what this means).

Here are all the available configurations that are supported by airprobe:

     0C : TimeSlot0  "Combined configuration", with SDCCH/4
          (FCCH + SCH + BCCH + CCCH + SDCCH/4)
     0B : TS0  "FCCH + SCH + BCCH + CCCH"
     1S : TS1  SDCCH/8
     2T : TS2  (Full Rate) Traffic
     1TE: TS1  Enhanced Full Rate Traffic

If you look at the traffic in Wireshark but it doesn’t seem to be right (for example you made a call or sent a text message while capturing but the Ciphering Mode Command is missing) it is pretty sure that you are using the wrong configuration (0b instead of 0c or vise versa). It is important to try both and figure out which one is correct for the cell you are observing.

I will assume you sent a text message to yourself while capturing data.

So now you can see all the messages of the beacon channel, but what are you looking for in the Wireshark log? It is quite simple: first a “Paging Request” for the TMSI of the target phone, then a “Ciphering Mode Command”. These are the messages which indicate that a transaction actually happened.

Now to continue with the flow it is best to try to decode the same cfile but now giving the key too to go.sh:

./go.sh capture.cfile 64 0C KEY

How to get the key? I already posted about that. Since we are testing using our own equipment we have access to the SIM card, so we can extract the key. It is best to extract the key immediately after you did a capture with RTL-SDR because depending on the network configuration the key could change.

What are we looking for now? Well, it depends on the network: either there is an “Immediate Assignment” telling the phone to move to different timeslot (so they are not using the busy beacon channel to do their business) or you will actually be able to see the text message (easy to recognize: its protocol in Wireshark is ‘GSM SMS’), it will look like this:

If instead of the SMS you find an “Immediate Assignment” message you need to open it and see which timeslot the phone is being commanded to and then you need to decode that timeslot using go.sh. So, for example if it says that the phone needs to go to Timeslot 2 then your command would be:

./go.sh capture.cfile 64 2S KEY

Notice that I did not only change the Timeslot number from 0 to 2, but also the configuration from C to S, because the target phone is now on a Standalone Dedicated Control Channel (SDCCH), not on the beacon channel so we need to decode it differently.

Also worth noting that SMS messages are almost always sent on the Control Channel not on the Traffic Channel.

Here is a flowchart of the whole process to make it easier to understand (naturally since we can only see the downlink this shows only what happens on the downlink):

gsm_sms_flowchartNow that we were able to decode an SMS let’s get to something a little bit harder: decoding a voice call!

Well the first step is the same as it was when we decoded a text message: we look at the beacon channel, Timeslot 0:

./go.sh capture.cfile 64 0C

What do we expect to see? Nothing besides the “Cipher Mode Command” because we didn’t provide the key, so let’s do that:

./go.sh capture.cfile 64 0C KEY

All right, what should we see now? Logically there needs to be an “Immediate Assignment” command, because the phone NEEDS to change at least once to a different timeslot to receive voice data (to a Traffic Channel, Timeslot 1-7).  What we saw when decoding the SMS is correct here too: depending on the network configuration we can see some messages about the call setup (if it is an incoming call we can even see the caller ID – the phone number calling our target) then an “Immediate Assignment” (configuration ‘C’ – combined) or we can only see an “Immediate Assignment” directing the phone to a Control Channel (just like it happened when receiving an SMS, configuration ‘B’).
Of course if you follow the phone to the Control Channel you will see the call setup messages (in case of an incoming call) then another “Immediate Assignment” command, this time directing the phone to a Traffic Channel.

Here is again a flow chart showing the process:

gsm_call_flowchart

Now there is only one question left: how do we decode the traffic channel to actually get the voice data?
Again, it is something that depends on the network: if the network uses simply Full Rate Speech then you can do the same what has been written in Srlabs’s tutorial:

./go.sh capture.cfile 64 1T KEY

What does this command do? It decodes Timeslot 1 as a Traffic Channel. We know what timeslot to decode from the “Immediate Assignment” command message, T means Full Rate Speech. The command results in a file called “speech.au.gsm”, which needs to be converted to .au file using ‘toast’:

toast -d speech.au.gsm

The resulting .au file could be played back using any player, e.g. cvlc (Command Line VLC):

cvlc speech.au

If you can not hear anything but beeps and other weird noises then there is a pretty good chance that the cell is using Enhanced Full Rate Speech instead of simple Full Rate Speech. To decode the channel as an Enhanced Full Rate Speech Traffic Channel:

./go.sh capture.cfile 64 1TE KEY

This results in a file called “speech.amr” which could be played back without any more modifications using for example Commandline VLC:

clvc speech.amr

If you have one hour to see everything in more detail, explained by a professional I would encourage you to watch this video:

UPDATE: I also uploaded my slides from Hacktivity.

The big GSM write-up – how to capture, analyze and crack GSM? – 1.

So. I had some requests asking me about how I did what I did with GSM. What tools did I use, what hardware and what options?
Since I believe strongly that GSM needs to be “out in the hands of the people” meaning everybody should have access to cheap hardware and free, opensource software that helps understanding GSM in practice I thought I will create a series of write-ups describing the whole process from the beginning.
Enjoy! :-)

First Step: understanding the basics of GSM, what’s the theory behind GSM-cracking?

GSM (Global System for Mobile communication) was introduced as a standard in 1991. The cipher used in GSM hasn’t been really well known but already in 1994 Ross Anderson published a theory about how to crack the encryption.

Later many people contributed to this theory essentially making GSM theoretically broken since 2003, but practical tools existed only for governmental organizations and mobile operators for such high prices nobody from the hacker community could buy them (not mentioning none of the manufacturers would have given him/her anything).
And this was the time when Karsten Nohl decided to dedicate some years as a researcher and as a manager to create both software and hardware that could turn theory into reality.

Every single year since 2009 Karsten and one member of his team released something, a milestone if you wish, which contributed to the death of myth that GSM is secure.

But there was one problem: all the details could never be released because of the rules of ‘responsible disclosure’ meaning that you can not give access to anybody to tools that exploit unpatched vulnerabilities in a live system. And boy, GSM does have quite some of these. However during the years we always got something, a piece of the puzzle so to speak:

  • 2009 – GSM rainbowtables with the tool Kraken (created by Frank A Stevenson) – they are useless without proper hardware that can capture GSM data but once we have the hardware cracking is possible
  • 2010 – airprobe which makes it possible to capture non-hopping GSM downlink channels with the USRP (combined with Kraken we have a full downlink sniffer on a single cell)

I am not listing 2011 here because there was no code released in that year (since the presented solution was a full blown GSM eavesdropping attack there was nothing to be released).

So, the landscape of GSM hacking consists of two hardware options: USRP or OsmocomBB. The USRP costs a lot, OsmocomBB has pretty much no code available.

My ideal setup would be a combination of these two: cheap hardware and software already available. Is there such a solution? Yes, there is.
You can use an RTL-SDR stick to capture GSM data from the air, just like you would do with a USRP. It is not as accurate, it does lose sync sometimes, but it works. And not only for single transmissions (SMS) but also for calls. I tested both, and I can confirm that it works.

So, now we have an established platform: we are going to sniff single frequency (non-hopping) GSM downlink-traffic. These are our limitations, airprobe is only capable of decoding the downlink and RTL-SDR isn’t capable of hopping along (although in theory you can use more sticks and lock each of them to a frequency and then re-construct the transmission by combining data from all dongles).

BEFORE YOU CONTINUE: if you haver never done anything with GSM, don’t know what a ‘burst’ is, or never heard of a ‘timeslot’ please stop reading this post and read at least the first 4 chapters of this introduction:
http://web.ee.sun.ac.za/~gshmaritz/gsmfordummies/intro.shtml

UPDATE: The page I referenced here went offline, so here is a PDF containing all its content.


Steps to crack GSM (originally outlined by Karsten Nohl):

  1. Get the TMSI of the victim
  2. Analyze the cell you and the victim are camping on
  3. Capture traffic and use the results of your analysis to construct input data for Kraken
  4. Use Kraken to crack the key
  5. Use the key to decode the data you captured

Get the TMSI of the victim

TMSI stands for Temporary Mobile Subscriber Identifier which is used on GSM networks to avoid the transmission of any information that would possibly identify a certain person (customer). We need to know this ID so we can tell when the victim is being paged (meaning that he/she is going to receive something from the network – call or SMS).
The idea behind uncovering a TMSI is quite simple: if the victim receives anything from the network he/she will get paged. So if we keep sending something to the victim (call/SMS) we can correlate the pagings we observe on the air with the frequency of the transactions we initiate. (this technique was first presented at 27c3 by Sylvain Munaut)
The ideal “thing” to send is a silent SMS: it will not show up at all on the victim’s phone (no sound, no notification, nothing) but we will get an acknowledge from the victim saying that our SMS was delivered.

Example scenario: we observe pagings and figure out that they page twice for each transaction, so if we send 3 silent messages there should be a TMSI which has been paged 6 times. By altering the number of messages sent we can quickly distinguish false positives from the real answers.

Test results: I actually did this attack at Hacktivity with a room full of people (meaning that the cell serving us was quite busy) and on my first attempt using 3 messages I only got two results back (meaning one of them was a false positive). Repeating the process would probably eliminate the false positive easily (there is very little chance that the same false positive would show up).

 

Analyze the cell

Since GSM cracking is based on knowing the content of encrypted bursts we need to figure out some information about the cell’s configuration. But wait you might say, what’s the point of this, ‘knowing the content of encrypted bursts’ renders encryption useless, doesn’t it?
Yes and no. Of course if you know the content of something that is encrypted there is no point in encryption. But in case of GSM it isn’t so simple: there are some bursts that are transmitted periodically, usually containing information about the system (System Information bursts). The only rule about these bursts is that they need to be transmitted no matter what. Even if the connection is currently encrypted these bursts will be transmitted (naturally in encrypted form).
So if we keep looking at the cell’s broadcast channel we can easily find a pattern which could be for example something like this

Paging Request for TMSI 11223344
Paging Request for TMSI 55667788
System Information Type 6
Empty Burst

Paging Request for TMSI 99887766
Paging Request for TMSI 00112233
System Information Type 5
Empty Burst

Paging Request containing TMSI 77001122
Paging Request containing TMSI 66005577
System Information Type 1
Empty Burst
and so on. As you can see the pattern repeats itself, just the type of the System Information changes, but for example there is always an empty burst at the end. This is just a fictional pattern but I hope you see the idea: some of these bursts are transmitted even if the connection is encrypted.
So if we look at the cell’s traffic, save the cleartext of a System Information Type 5 message, then capture some encrypted data containing the same message we can do:

cleartext System Information Type 5 XOR encrypted System Information Type 5

The result is the so called keystream (that comes out of the encryption function A5/1). Guess what do we need to feed our cracker, Kraken with? Yep, A5/1 keystream.

The challenge of course is to determine which burst of all the encrypted ones is the one containing in this case the System Information Type 5 message (again, we could have chosen any other message which has a known content). That’s why we need to analyze the cell’s configuration and make maybe one-two test calls to see the call setup.
Usually the call setup always happens the same way, so once you figured out what messages are sent during a call-setup you can safely assume that the same messages will be transmitted whenever there is a call-setup.

Using Kraken

That’s pretty straight forward: download the 1.6 TB of rainbow-tables, write them out to a hard drive and then fire up Kraken.
After it is ready just give it the crack command followed by the burst you would like to crack, like this:

Kraken> crack 001101110011000000001000001100011000100110110110011011010011110001101010100100101111111010111100000110101001101011

Decrypting traffic

Since GSM could be running in many different configurations you might need to try out more config. options of the tool go.sh to get it working properly. Otherwise there isn’t anything fancy about this step, all you need to do is pretty much giving it the key, the filename and ‘let it do the magic’.

This is the end of the first part of the series. I covered just the history of GSM hacking, what hardware do we have to do GSM hacking and basic theory behind the attack. In the next part we are going to set up our environment, then start real hacking with it. Stay tuned!

How do you get the Kc from a SIM card?

Sounds kind of like a magical question, right? It is interesting that there are pretty much no guides on this topic, because for any GSM-debugging you need to have the so called Kc (pretty much a session key) that was used to encrypt the traffic sent over the air.

So let’s get started: there are as many as 4 ways to do this, and some other that I tried and don’t actually work, so let’s see:

Ways that work:

1. BlackBerry Engineering Screen

This is quite an easy catch: pretty much on all of the BlackBerries you can enable the so called “Engineering Mode” which will simply show you the current Kc. Not much of fun, but a reliable, good way to do it.
TESTED: YES (as shown by Karsten Nohl for example at BlackHat 2010)
WORKS: YES

2. OsmocomBB Mobile App

Now, this one is quite a tricky one, because setting up OsmocomBB already requires quite an amount of work, but once you have it up and running AND you are lucky with the cables and the code (which is not usually the case) you can simply run the mobile app and then use the telnet interface to get the Kc:
1. Upload layer1 to your phone
2. Run mobile -i 127.0.0.1
3. telnet 127.0.0.1 4247

After that simply say:
show subscriber 1
At the top you should see the Kc printed.
TESTED: YES
WORKS: PARTIALLY (I was able to get the Kc, but the mobile app itself wasn’t working for me, so I couldn’t place a call or send an SMS just to try out if I have the right Kc or not)

3. AT+CSIM Command

This one is the eldest and most well-known command: some phones allow you to use one of  the standard-defined-but-not-always-implemented AT command AT+CSIM which let’s you to send raw APDUs (=”commands”) to the SIM-card via the modem. The amount of phones supporting this is very limited, according to some people older Siemens and Alcatel phones let you do this. Also older iPhone’s (3GS/3G/2G) let you do this if you are jailbroken (you need to install minicom from Cydia then connect to the device /dev/tty.debug). Newer iPhone’s don’t really let you do this, iPhone 5 owners – we all are out of luck.

The command you would like to send is something like this:

 Sample run:

AT+CSIM=14,"A0A40000026F20"
+CSIM: 34,"000000096F2004001100BB010200009000"

OK
AT+CSIM=10,"A0B0000009"
+CSIM: 22,"E0940FC09AEFA000009000"

OK

Again, you find the last Kc used here: E0 94 0F C0 9A EF A0 00 and also the key sequence number: 00

From: http://openbsc.osmocom.org/trac/wiki/A5_GSM_AT_tricks

TESTED: NO
WORKS: PROBABLY

4. Using a SIM-card reader/Smart Card Reader

Some people said on the A51 mailing list that by using a simple SIM card reader they were able to extract the last used Kc from the card. I am not sure about this, but it sounds reasonable and the people who wrote about were quite convincing.

UPDATE: I tried this method using a simple PC/SC cardreader (exact model: Omnikey CardMan 5321 – it is great because it has both RFID and contact-smart card reading interfaces) and I am happy to tell you it works! Running SIMspyII after I inserted the SIM-card into the reader revealed the Kc and also everything else stored on the SIM card (I already turned off PIN-code verification for the card, not sure however how having a PIN code would change the procedure, but I assume the SIMspyII program has support for PIN-codes).

The only interesting part is that the SIM-card itself is a lot smaller than a standard smart card, so you need to either take the reader apart and insert the card alone, or use the plastic card the SIM-card came with, or use an old credit card.

reading_Kc_simspy

Also there are some rumors that you can’t power down your phone because it would erase the Kc from the SIM card so you need to pull the battery out. According to this mailing list thread you don’t need to do that because according to GSM specification the Kc should remain on the SIM card even if the phone is poweered down (Harald Welte). According to my experience this is true.

TESTED: YES
WORKS: YES

Other ways which don’t work:

1. Nokia DCT3 FBUS Connection:

Sounds like an ideal setup: you use an old Nokia DCT3 (3310/3410 etc.) and an FBUS cable. Using dct3-gsmtap from OsmocomBB you would be able to sniff all the packets the phone receves/sends, and also all communication between the phone and the SIM-card. Since we know the command we are looking for (see above, A0 A4 …) we can easily find the Kc – one would think. Sadly that’s not the case, Nokia’s engineers closed this possibility: after the command the next packet we can see coming from the SIM card is an empty packet. This causes Wireshark to say Malformed packet and shows no data in it – which is totally right, after looking at dct3-gsmtap’s output you can observe the following:

SIM: 0xA0 0xA4 0x00 0x00 0x02 0x7F 0x20
SIM:

So, empty message coming back.
TESTED: YES (Nokia 3410 + FBUS cable)
WORKS: NO

 

I will update this list as soon as I find new ways to extract the KC.