I just read this quite nice article about a backdoor in HP’s D2D/StorOnce Storage unit. It is unbelievable how a vendor can ignore such a huge problem.
Anyhow, I decided to publish the password behind the SHA1, mainly because the first Google hit for “online sha1 cracker” simply had this hash already in it, so I don’t see the point of not publishing it. I am just making your life easier to spare you a trip to this free service, enter their captcha and see the password:
As I can read it it says Badgers, so I assume HPSuport must be in love with Wisconsin, which is a good thing: the Wisconsin Badgers are the athletic teams representing University of Wisconsin from Madison (Wisconsin’s capital). I like the Badgers too, that’s why I have a badger hangin’ on my keychain all the time. Guess I am kind of similar to HPSupport (? :D).
I decided to create a new, separate project for all my GSM research. My goal is to sniff my own data, crack the key, and read the SMS I sent/listen to the voice call I made. I am still hesitating in terms of hardware to use between OsmocomBB phones (a lot better, more accurate hardware for voice especially) and rtl-sdr (much easier to use, and  so far it already showed how awesome it is and how great capabilities it has).
Anyhow, for key cracking you need to have the a51_table files, which are available from torrents. Sadly I wasn’t able to find a correctly formatted file containing MD5 hashes for these 40 files, so I collected all the hashes from the a51 mailing list’s archives and put them in a format that could be used with the Linux utility ‘md5sum’ to automatically check integrity.
I will also commit a list containing exact sizes of the table files into this repository, so if you would not like to wait for md5sum you can just check the files based on size.
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
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.
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.
I jsut bought some really old data cables for my Nokia 3410 and I must tell you they suck really bad. Let me tell you a little bit about the background:
I am currently really into everything that is security & GSM, therefore I thought it would be great to have a data cable which I can use with my old Nokia 3410 to enable the so called “Network Monitor” mode. In this mode the phone shows you a lot of useful information like the frequency it is using (ARFCN) or the current temporary ID of the SIM card (TMSI).
So, as a normal user would do I went to my friend Google and asked him about this cable. He quickly showed me some results which were quite funny: some Hungarian webshops still have these cables in stock! I was quite happy because the price was really low and I thought it would be great to buy from a shop and not from some random person.
So the cables came like two days later, and I tried to connect them to my phone. None of the cables seemed to fit. I was really angry, and thought about calling the shop telling them they are selling junk (which wouldn’t be surprising at all sadly) but then I found an archive website that shows you how to connect the cable properly.
The secret is quite easy once you know it: you need to get rid of the nice soft protecting foam that is glued all around the pins of the cable (who would have thought…). After that I connected the phone to my computer and I was able to turn on the Network Monitor – yeah, let’s all be happy.
But how is this related to poor quality Chinese cables?
Let me finish the story:
As time went on I wanted to get more information out of the phone and I already found the tool for this, naturally it is part of the Osmocom-family, it is called dct3-gsmtap. It can use the serial connection to your phone to actually capture GSM and SIM-card data and then forward it to Wireshark for later analysis. Sweet, just what I wanted to try out.
I installed it, tried to run it, and it says something like “no answer from the phone”. What the ****? I just communicated with the phone, and turned on the Network Monitor!
So I went back to Google and tried to research this, and finally found the cause:
Apparently for Nokia phones you can have 2 kind of cables, one is called MBUS (M2BUS) the other one is called FBUS. They differ in speed, baudrate and also capabilities. MBUS is an older simpler implementation of a serial line – it only uses GND and MBUS_PIN (data pin) to communicate. It is slow, and not really useful, that’s why Nokia decided to introduce FBUS which uses GND, RX_PIN and TX_PIN so it is a lot faster and more reliable serial connection.
Guess which connection is supported by pretty much all of the tools available. Yes, FBUS.
Guess what kind of cable do I have? Yes, MBUS. Sweet…
But I didn’t stop there, I wanted to see, if there were truly only 2 pins connected in my cable, or what was going on (because the interface facing the phone actually has all 4 pins). It turned out, that I do have 4 pins connected, but if I trace the whole cable it turns out that one of the magic plastic boxes on the cable (you know those little plastic boxes that are  on some cables for noise-cancelling or something like that) has all 4 cables coming in and only 2 cables going out.
So, I have an awesome cable which has all of its capabilities limited because some retard thought ‘yeah, why don’t we cut these two wires right at the middle of the cable?’.
Fortunately Google is still my friend and I found a random guy on the Internet who is Hungarian and has one perfectly fine FBUS cable for Nokia 3310/3410 which he is willing to sell. Ironic.
I started trying out Karsten Nohl’s and Luca Melette’s GPRS sniffing tutorial (https://srlabs.de/gprs) and I found out that because of some changes that were made to the code the patch provided with the tutorial fails to work.
After some searching I found the solution which was pretty much manually fixing some lines of the code and of the patch file. I ended up with a new patch file that works with the latest burst_ind branch of Sylvain Munaut. I put it up here: https://github.com/domi007/gprs_sniff/blob/master/gprs_new_patch
I just came across again Samy Kamkar’s great DEFCON 18 talk – How I met your girlfriend? and I really liked when he explained how to ‘bing’ something, so here is the part of his presentation in a separate video:
