Programmation bluetooth sous Gnu/Linux

Fiou! Voici enfin terminé le premier semestre (et sa fin pour le moins chaotique). Nous voila donc à quelques jours des traditionnelles fêtes de fin d'année. Fêtes au cours desquelles des millions de personnes vont s'adonner au "plaisir d'offrir, joie de recevoir". Et parmis les présents échangés se trouveront une foule d'objets high-tech, autement communicants, et sans fils, il s'entend!

Depuis quelques jours une idée me trotte donc dans la tête (au détriment de mes examens :'(), celle de l'écriture d'un petit framework d'exploration des réseaux bluetooth environnants. Je ne parle pas ici de sniffers (même si me connaissant j'y reviendrais, hcidump est déjà installé!). Mais plutôt d'une exploration active.

En effet le protocole bluetooth spécifie que les appareils, en plus de contenir un code spécifique à leur constructeur, renferment et peuvent communiquer leur complète description (les services qu'ils hébergent, des détails sur leur mode de communication etc...)
Hmm, appétissant non? Alors imaginez qu'en plus j'apprends que la pile bluetooth de linux (bluez) est la plus solide et la meilleure implémentation (en ce qu'elle permet au programmeur un accès aux couches bas niveau du protocole) comment pourrais-je me détourner d'un tel projet?!!


Je ne suis qu'au début de mes investigations dans ce domaine, mais les nouvelles sont bonnes, toutes les sources font l'apologie de la lib bluez, la programmation client et serveur se fait via les primitives socket() et bind().

J'ai donc commencé mon apprentissage via un code établissant une liaison série entre deux périphériques. Je ne le copie pas en entier, il est relativement classique pour tout ce qui est des parties qui prennent de la place...

Je conserve :

#include <rfcomm.h> /* définition des adresses bluetooth */

fd = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);


/* CLIENT */
connect(fd, (struct sockaddr *)&sa_rfcomm,
   \ sizeof(struct sockaddr_rc));

/* SERVEUR */
bind(fd, (struct sockaddr *)&sa_rfcomm,
    \ sizeof(struct sockaddr_rc));
listen(fd, MAX_CONN);

Rien de spécial pour l'appel à socket() à part que c'est beau. sa_rfcomm est une structure contenant l'adresse du serveur et le canal employé pour communiquer, via send() et recv().

Pour les plus pressés, l'accès bas niveau se fait en spécifiant les protocoles BTPROTO_HCI ou BTPROTO_L2CAP lors de la création du descripteur de fichier, mais ceci est une autre histoire.

Histoire qui s'annonce passionnante, au vu de la convergence des menaces et des protections vers l'informatique mobile (j'inclus là téléphones, PDA et consoles de jeu). On peut légitimement penser que cette convergence risque fort de s'accélérer lorsque l'on observe les comportements actuels relatifs à la sécurité. Un Buffer Overflow sur l'iphone, permettant d'executer du code noyau devient quasiment un élément de publicité ("installez ce que vous voulez sur votre Iphone!!"). Ou ces hotspots wifi un peu partout, les logiciels de gestion de finance sur téléphone portable... Toutes ces aberrations sont monnaies courantes. Contrairement aux logiciels antiviraux pour systèmes, tellement rares qu'on peut les considérer comme inexistant!
La lecture des 1200 pages de spécifications du protocole constitue une bonne explication quant à l'existence de nombreuses implémentations buggées.

Bref, de là à voir le bluetooth fricoter avec le metasploit framework comme le fait le wifi depuis la V3.0 il n'y a qu'un pas, qui sera sans doute franchi relativement rapidement...

Je releaserais mes codes ici au fur et à mesure de l'avancement du projet.