nccgroup/nobexnOBEX permet d'émuler les profils PBAP, MAP et HFP pour tester les systèmes d'infodivertissement des véhicules et les appareils similaires utilisant ces profils.
nOBEX permet d'émuler les profils PBAP, MAP et HFP afin de tester les systèmes d'infodivertissement automobiles et les appareils similaires utilisant ces profils. nOBEX fournit des clients PBAP et MAP pour cloner les systèmes de fichiers virtuels authentiques de ces profils à partir de téléphones réels. Cela signifie télécharger l'intégralité du répertoire téléphonique et tous les messages texte. Les vcards brutes, les listes XML et les structures MAP BMSG sont stockées et peuvent être modifiées à volonté pour des tests négatifs. nOBEX peut ensuite agir comme un serveur PBAP et MAP, permettant aux véhicules et autres appareils de s'y connecter et de récupérer les informations du répertoire téléphonique et des messages. Les vcards, BMSG et listes XML sont envoyées exactement telles qu'elles sont enregistrées, ce qui permet aux données malformées modifiées par l'utilisateur de passer. Comme la plupart des autoradios exigent la prise en charge du HFP avant de tenter d'utiliser PBAP et MAP, nOBEX fournit également une prise en charge rudimentaire du HFP. Il renvoie des réponses prédéfinies personnalisables aux commandes AT provenant de l'autoradio. Cela permet d'imiter un véritable téléphone portable.
nOBEX est construit sur le projet PyOBEX de David Boddie. Cet outil n'aurait pas été possible sans les efforts considérables de David pour rendre OBEX accessible et facile à utiliser. nOBEX étend PyOBEX en ajoutant la prise en charge des messages OBEX volumineux en plusieurs parties, l'émulation HFP, les serveurs PBAP et MAP, un client MAP et un client PBAP amélioré.
nOBEX (et PyOBEX) utilisent la pile Bluetooth BlueZ pour annoncer les services via le Service Discovery Protocol (SDP) et établir des connexions RFCOMM. nOBEX/PyOBEX contiennent des implémentations autonomes de la spécification OBEX pour les rôles de client et de serveur. Python 2 et 3 sont tous deux pris en charge.
En mode client, nOBEX utilise BlueZ pour interroger les services offerts par le serveur. S'il détecte que le service demandé est disponible, il se connecte au serveur via RFCOMM sur le port spécifié via SDP. Les requêtes OBEX sont construites et envoyées au serveur conformément au profil utilisé. Les réponses sont interprétées et enregistrées sur le disque. Les modes clients pour PBAP et MAP peuvent être utilisés pour cloner un téléphone réel.
En mode serveur, nOBEX annonce les services disponibles via SDP. Lorsqu'un client établit une connexion RFCOMM sur le port annoncé, le serveur accepte et traite les requêtes OBEX. Les réponses OBEX aux requêtes sont envoyées à l'aide des données présentes sur le disque. Les serveurs PBAP et MAP servent des structures de fichiers/dossiers correspondant à celles générées par les clients respectifs.
Les instructions d'installation suivantes ont été testées sur Fedora 24, 27 et 29. D'autres distributions récentes peuvent également fonctionner, mais les résultats peuvent varier. Vous devrez peut-être installer les anciens outils bluez (y compris sdptool) si votre distribution ne fournit pas sdptool. Sachez également que les serveurs OBEX ont tendance à ne pas fonctionner dans les machines virtuelles avec des adaptateurs Bluetooth partagés. Exécutez Linux nativement ou disposez d'un adaptateur Bluetooth USB dédié utilisé uniquement par la VM.
Essayez de sonder les services locaux annoncés sur SDP :
sudo sdptool browse local
Si vous utilisez une distribution récente, cela échouera probablement en raison de certains changements d'API cassant la compatibilité dans BlueZ 5. Vous pouvez corriger cela en exécutant bluetoothd en mode de compatibilité. Pour ce faire, modifiez le service systemd pour bluetoothd.
sudo vi /usr/lib/systemd/system/bluetooth.service
Ajoutez --compat à la ligne ExecStart :
ExecStart=/usr/libexec/bluetooth/bluetoothd --compat
Redémarrez maintenant bluetoothd :
sudo service bluetooth stop
sudo systemctl daemon-reload
sudo service bluetooth start
sudo hciconfig -a hci0 reset
Testez à nouveau la navigation dans les services SDP locaux (cela devrait fonctionner cette fois) :
sudo sdptool browse local
Récupérez nOBEX et installez-le :
git clone https://github.com/nccgroup/nOBEX.git
cd nOBEX
sudo python3 setup.py install
Trouvez l'adresse MAC d'un téléphone dont vous souhaitez cloner le répertoire téléphonique :
hcitool scan
Clonez le contenu PBAP d'un téléphone existant (utilisez votre bonne adresse MAC et un répertoire de destination de votre choix, de préférence vide ou inexistant) :
python3 examples/pbapclient.py 5C:51:88:8A:EC:5B ~/pbap_root/
Alternativement, utilisez l'arborescence de données d'exemple PBAP située dans le dossier examples/pbap_root.
Modifiez les vcards et les XML de listage dans votre répertoire de vidage PBAP comme vous le souhaitez. Lancez maintenant un serveur PBAP en utilisant le répertoire téléphonique cloné :
sudo python3 examples/multiserver.py --pbap ~/pbap_root/
Vous devrez également apparier votre client PBAP avec l'ordinateur (serveur PBAP).
Récupérez les données de messages de votre téléphone pour établir une arborescence MAP de test :
python3 examples/mapclient.py 5C:51:88:8A:EC:5B ~/map_root/
Alternativement, si votre téléphone ne prend pas correctement en charge MAP, utilisez l'arborescence de données d'exemple MAP située dans le dossier examples/map_root.
Modifiez les données d'exemple comme vous le souhaitez. Lancez ensuite le serveur, en indiquant où il doit rechercher la racine de l'arborescence MAP.
sudo python3 examples/multiserver.py --map ~/map_root/
Le client HFP (mains libres, émulateur de kit automobile) fournit une interface en ligne de commande AT pour communiquer avec votre HFAG (téléphone/modem). Je l'appelle le « client HFP » bien qu'il s'agisse d'un serveur RFCOMM, car il est un « client » pour le HFAG (téléphone/modem). Vous utilisez l'émulateur HF (« client ») pour envoyer des commandes AT au HFAG, même si le « serveur » (HFAG) est celui qui initie la connexion RFCOMM.
Pour exécuter l'émulateur HF :
sudo python3 examples/hfpclient.py
Vous devrez peut-être démarrer l'émulateur HF pour annoncer que vous êtes un HF via SDP avant d'apparier votre téléphone. Lorsque l'émulateur HF est en cours d'exécution, votre téléphone initiera une connexion RFCOMM de commandes AT avec le script de l'émulateur. Pour accélérer ce processus, vous pouvez cliquer sur l'ordinateur apparié dans les paramètres Bluetooth de votre téléphone pour déclencher une connexion/reconnexion.
Une fois que le HFAG (téléphone/modem) initie une connexion, vous disposez généralement d'une fenêtre limitée (30 secondes à une minute) pour configurer la session HFP. Avant de pouvoir envoyer des commandes AT utiles (comme initier des appels téléphoniques), vous devez envoyer une séquence de commandes AT dans cette fenêtre limitée, sinon le HFAG pourrait se déconnecter de vous. La séquence initiale de commandes AT suivante devrait fonctionner pour la plupart des téléphones :
AT+BRSF=39
AT+CIND=?
AT+CIND?
AT+CMER=3,0,0,1
AT+CHLD=?
AT+CCWA=1
AT+CLIP=1
AT+NREC=0
Le serveur HFP (audio gateway) est assez basique, renvoyant des réponses préconfigurées à certaines commandes. Le serveur est configuré pour prendre en charge les commandes HFP courantes dès le départ, mais chaque véhicule nécessitera probablement quelques commandes supplémentaires et/ou des modifications des réponses. Des réponses personnalisées peuvent être configurées via un fichier texte avec un format de paires commande et réponse sur chaque ligne, la commande et la réponse étant séparées par une tabulation. Des exemples de fichiers de configuration se trouvent dans le dossier examples/bbeast.