nccgroup/nobexnOBEX allows emulating the PBAP, MAP, and HFP profiles to test vehicle infotainment systems and similar devices using these profiles
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.
Contrairement aux autres serveurs, l'implémentation HFP AG de nOBEX n'accepte pas réellement les connexions RFCOMM. La norme HFP est ambiguë sur la manière dont les connexions doivent être établies, et donc à la fois le HF et l'AG sont autorisés à accepter et à initier des connexions. Différents autoradios se comportent différemment en matière d'établissement de connexion. Cependant, la plupart des appareils HF ont tendance à accepter d'être connectés par l'AG si l'AG n'accepte pas de connexions sur son propre port. Ainsi, le « serveur » HFP AG de nOBEX recherche simplement parmi les appareils appariés ceux qui prennent en charge le service HF, puis nOBEX se connecte à l'appareil HF.
Sachez que le code HFP AG tentera de se connecter à tout appareil listé sous /var/lib/bluetooth/*/* qui prétend prendre en charge le rôle HFP HF. Par conséquent, vous devez supprimer tout appairage erroné dans ce répertoire avant d'essayer d'utiliser le serveur HFP.
Pour exécuter un HFP AG autonome (le fichier de configuration est facultatif) :
sudo python3 examples/multiserver.py --hfp [config_file]
Le serveur HFP (HFAG) prend également en charge le fonctionnement interactif où vous pouvez modifier les réponses automatiques à l'exécution ou envoyer manuellement des réponses AT. Le serveur HFP écoute sur le port 7137 de localhost pour les commandes. Vous pouvez vous y connecter en utilisant netcat comme indiqué ci-dessous :
nc localhost 7137
Il n'y a que deux commandes simples pour cette interface :
send <atresp> - envoyer atresp comme réponse ATursp <atcmd> <atresp> - mettre à jour/définir la réponse automatique pour atcmd à atrespLes exemples de commandes suivants simuleront un appel téléphonique entrant :
ursp AT+CLCC +CLCC: 1,1,4,0,0,"1234567890",129
send RING
Le client FTP (File Transfer Profile) vous permet de parcourir les fichiers sur un serveur OBEX FTP, comme un autre ordinateur exécutant nOBEX, ou un téléphone Android exécutant l'application Bluetooth File Transfer. Un exemple de programme client FTP se trouve dans le répertoire examples.
python3 examples/ftpclient.py SERVER_MAC_ADDRESS [save_directory]
L'exécution de l'exemple de client FTP avec uniquement une adresse MAC Bluetooth comme argument affichera un listage récursif des dossiers de tous les fichiers accessibles via OBEX FTP sur le serveur. Si l'argument facultatif save_directory est fourni, le script téléchargera chaque fichier accessible sur le serveur et l'enregistrera dans le répertoire de sauvegarde spécifié sur votre ordinateur.
Le serveur FTP permet à un client de parcourir les fichiers de votre ordinateur (serveur) dans un dossier spécifié.
sudo python3 examples/multiserver.py --ftp PATH_TO_FTP_FOLDER
Le client OPP (Object Push Profile) permet de pousser un fichier de votre ordinateur vers un serveur OBEX OPP.
python3 examples/pushclient.py SERVER_MAC_ADDRESS FILE_TO_PUSH
Le serveur OPP permet à un client de pousser des fichiers vers votre ordinateur (serveur) dans un dossier spécifié.
sudo python3 examples/multiserver.py --opp PATH_TO_OPP_FOLDER
Le script multiserver.py permet d'exécuter simultanément n'importe quelle combinaison des serveurs HFP, MAP, PBAP, FTP et OPP. Il suffit de combiner les arguments des exemples ci-dessus. Pour exécuter HFP, MAP et PBAP simultanément :
python3 examples/multiserver.py --map ~/map_root/ --pbap ~/pbap_root/ --hfp [config_file]
La combinaison de HFP et PBAP a été testée avec succès sur une Ford Focus 2012.
Le but principal de nOBEX est d'effectuer des tests négatifs et du fuzzing des clients PBAP et MAP sur les autoradios automobiles. La prise en charge du HFP et les clients PBAP/MAP sont destinés à faciliter cet objectif. Le fuzzing manuel peut être effectué en exécutant un serveur avec des listes XML, des vcards et des BMSG modifiées à la main. OBEX est une cible de fuzzing riche avec de nombreuses structures TLV imbriquées pouvant s'étendre sur des messages en plusieurs parties. PBAP et MAP augmentent considérablement la surface d'attaque avec les analyseurs vcard, BMSG et XML.
nOBEX ne dispose pas d'une prise en charge intégrée du fuzzing automatisé, mais comme il est écrit en Python, il est facile à étendre. Des capacités de fuzzing plus puissantes peuvent être construites en le couplant à un moteur de mutation et en instrumentant l'appareil cible.
Au-delà du fuzzing de MAP et PBAP sur les autoradios automobiles, nOBEX peut également être utilisé pour des tests positifs normaux de PBAP, MAP et d'autres profils OBEX (tels que FTP) pour les rôles de client et de serveur. Les serveurs PBAP et MAP ont été testés avec l'application OBEX Commander pour Android, avec laquelle de nombreux crashs ont pu être déclenchés par une communication OBEX défectueuse et des données spécifiques au profil malformées. De plus, la prise en charge du HFP peut être utilisée pour fuzzer manuellement les commandes AT.