Documente Academic
Documente Profesional
Documente Cultură
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.
First Step: understanding the basics of GSM, whats the theory behind GSM-cracking?
GSM (Global System for Mobile communication) was introduced as a standard in 1991. The cipher used in GSM hasnt 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 isnt 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, dont 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.
2.
3.
4.
5.
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).
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). Thats why we need to analyze the cells 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
Thats 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 isnt 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!
1. RTL-SDR :
http://www.rtl-sdr.com/rtl-sdr-tutorial-analyzing-gsm-with-airprobe-and-wireshark/
This article is the best, it simply covers the whole process from A to Z.
To get the best reception you should always calibrate your RTL-SDR dongle:
http://www.rtl-sdr.com/how-to-calibrate-rtl-sdr-using-kalibrate-rtl-on-linux/
It is important to know that decoding GSM requires quite an amount of processing power (even more if you do it in real-time using gsm_receive) so if
you use it in a virtual machine dont forget to give it at least 2 processor cores. On my machine (Core i5 first generation) using just one core
gsm_receive wasnt usable at all.
2. OsmocomBB:
I assume you completed the first step, so you already have libosmocore installed (!).
First of all you will need to set up an ARM cross compiler, like this:
wget http://gnuarm.com/bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.tar.bz2
tar xf bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.tar.bz2
Now it is a good time to do some testing whether OsmocomBB compiled fine or not. Connect your OsmocomBB phone to your PC and run the
following command (assuming you are in the src directory):
./host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor -c ./target/firmware/board/compal_e88/rssi.highram.bin
./target/firmware/board/compal_e88/chainload.compalram.bin
If everything is fine your phone should have the RSSI firmware loaded. If you get errors while loading the firmware you need to make sure your cable
is fine and you are not using a virtual machine (the virtualized USB controller tends to mess up timings causing the chainloader code to fail).
Now that you can compile and run OsmocomBB code you will be able to run the my modified version of it (will be posted soon).
later.
UPDATE (19/10/2013): I started fixing the code, first up is the Android app which seems to be ready from my point of view, but since I havent
checked it with anyone else I am going to say it is alpha quality code, a little bit better than a PoC.
https://github.com/domi007/silentSMS
UPDATE (05/09/2014): Since I didnt have time in the past to release tmsi_buster.py I will at least add some guidance here if someone wants to create
it:
1. Install my SilentSMS application onto an Android phone, then decide which way to connect to the phone (USB tethering/WiFi/WiFi tethering
all are options)
2. Start the app, it will start listening on the port 1337
3. You can telnet to this port, and enter a phone number and hit enter the app will send a silentSMS to that phone number
So, you now have a way of sending silent text messages, so you now you just need to monitor all the paging requests. You can use RTL-SDR for that or
osmocomBB. The thing left is to collect all the TMSIs, and try to figure out from them which is the one you are looking for.
First observe the paging requests (especially the TMSIs in them) on the console how many times is the same TMSI paged? Some networks page 2,
even 3 times and then continue with the transaction, so if you sent 3 SMSes you will see a TMSI being paged 6 times, not 3 times as one would
expect. So you need to create a script that counts how many times is a TMSI paged based on the output of RTL-SDR (+ tshark + a good wireshark
filter) or osmocomBB and while doing that it sends out silent SMS messages via the telnet interface. After 2-3 messages you can see how many TMSIs
you have with 2 (or 4)-3 (or 6) pagings. If you get multiple results you can eliminate the wrong ones easily by sending more SMSes, but monitoring
only the TMSIs you got from the previous run.
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).
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.
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.
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 its 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 doesnt 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):
Now that we were able to decode an SMS lets 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 didnt provide the key, so lets 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
Srlabss 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:
https://www.youtube.com/watch?v=0hjn-BP8nro&feature=player_embedded