Cracking and sniffing GSM with a RTL-SDR

a) Decoding an SMS:
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

As you can see these are the GSM configurations used in the different frames and you will have to be able to recognize each one to identify if you must use an airprobe configuration or another to decode the data of your call or SMS. 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

I will explain how to get the Kc key with my method in a later thread.
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.
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):

b) Decoding a Voice call:
Now 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:

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 toast tool is a software to convert files and I will explain the setup process of this software on another thread. The resulting .au file could be played back using any player, e.g. cvlc (Command Line VLC):

cvlc speech.au

So you must download and install VLC player too.
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:

cvlc speech.amr

All the threads related to this topic will be classified under the category of GSM software setup!!! You can read them on the first page!!!

 https://ferrancasanovas.wordpress.com/cracking-and-sniffing-gsm-with-rtl-sdr-concept/