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!

This entry was posted in Ethical Hacking, Publikációk and tagged , , , , , , , . Bookmark the permalink.

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

  1. Pingback: Receiving, Decoding and Decrypting GSM Signals with the RTL-SDR - rtl-sdr.com

  2. Pyro says:

    Excellent post, but don’t you mean Ross Anderson rather than Ron Anderson?

  3. Sylvain Munaut says:

    Where did you see the attack to uncover the TMSI at 25c3 ???
    25C3 presented the HLR query where you can recover the IMSI from the phone number. The technique to uncover the TMSI by correlating it with activity triggered on the cell was presented first at 27C3 AFAIK. Also the version that’s explained at 27C3 is a bit more advanced and filters false positives much better.

    The rest of the post is also riddled by inacuracies. There is no such things as an encrypted “System Information 1″ those are on the BCCH only and that logical channel is never encrypted. You’ll only ever find SI5/6 (and their variations) ciphered and those will be on the SACCH.

    • domi007 says:

      Sylvain,

      Thank you for your comment – I am really glad and grateful that you took the time to correct my errors. I didn’t go into the GSM standard so deep as I probably should have, but I thought that raising awareness is more important than getting all the details right, however naturally I am going to fix everything you pointed out.

      I looked it up now, and you are right, the talk at 25c3 wasn’t exactly about what I remembered, so I fixed the reference.

      Thank you for pointing out the problems in my example. My main goal was to make people understand how the known-plaintext attack works (I even say something like it is only a fictional set of bursts), but I used wrong types of bursts. I fixed that now.

      I hope the updated version is better than it was.

      • gat3way says:

        Paging requests are also on BCCH only.

        BTW thanks for your posts, I got a lot of inspiration from your site for my A5/1 crypto research :)

  4. Peter Kaloczy says:

    This method can be possible to do in real time or in almost real time basically…. the rainbow tables need big I/O and SSD discs has big I/O so if we put rainbow tables on SSD discs (on raid fo.) then the decryption of the data will be much faster (maybe not real time but for sure quicker than from classic HDD…)

    • Peter Kaloczy says:

      here is some software called Cryptohaze GPU Rainbow Cracker …
      GPU (with CUDA or GPGPU), BIG BIG RAM, i7, BIG BIG MANY SSD DISCS IN RAID, fast internet and RTL-SDR usb dvbt tuner + eventually raspberry pi as client (capture device sending through internet to server)

      http://www.cryptohaze.com/gpurainbowcracker.php

      The ideal system to run this on would be something very, very powerful. The cracker will use all the GPUs in your system (so load up with 580s or 6970s if performance is critical), but the table searching is a significant portion of the cracking time. SSDs are perfect, except for the size limitations – the tables get very, very big (100s of GB or larger). If SSDs aren’t large enough, the next best option is a big RAID array with high linear read speeds. The cracking code is tuned for spindle disk RAID arrays. I suspect a multi-disk mirrored array (4-5 disks mirroring each other) would be very fast as well, but have not tried it. Get a lot of RAM too – the more RAM you have, the bigger index files you can have, which will improve cracking speed. The increased RAM performance of an i5/i7 board is useful.

  5. Hien says:

    Hello,

    I’m so new at GSM. I’ve one question: How to determine encryption algorithm specific cell is using ? Please let me know. Thanks in advance.

  6. Neal says:

    Hey,

    where I can find rainbow-tables and Kraken?

    Thanks

  7. Pingback: Déchiffrer les communications GSM avec une simple clé tuner TV RTL2832 | Radioamateurs-France

  8. mevinto says:

    Hi, so we can’t decode gsm live ? we must capture the gsm (when somebody make a call) and then decrypt ? (I am a begginer:)

  9. mannee says:

    Hello,
    I have a question, is it also possible to send GSM signals?
    Could i, for example, send an SMS to everyone in my range?

    • domi007 says:

      Hi,

      Using only RTL-SDR it is not possible (rtlsdr can only receive, not transmit). Also on a commercial network no, but if you operate your own network and can attract users to it then naturally you can do whatever you want.

      • max says:

        hi ,

        what is the difference between hopping and non – hopping chanel? so
        can be caller and called party listen, or only one of them?

        Thank you very much

        • domi007 says:

          A hopping channel means that an operator has 2-3 or even more frequencies to operate on, so after the encryption has turned on it sends to the phone these frequencies and some more information, so the phone while doing the call will rapidly switch between those towers. This increases resistance to interference and makes captureing data for an attacker harder (since you either need to follow the victim while it is hopping between frequencies or capture all possible frequencies and then fit the pieces together).
          There is some more information about the topic here:
          http://yo3iiu.ro/blog/?p=1069

  10. Pingback: Knacken, auswerten, manipulieren: Wie GSM-Handys gehackt werden können - TechNet Blog Deutschland - Site Home - TechNet Blogs

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>