nccgroup/nobexnOBEX ermöglicht die Emulation der PBAP-, MAP- und HFP-Profile, um Fahrzeug-Infotainmentsysteme und ähnliche Geräte zu testen, die diese Profile verwenden.
nOBEX ermöglicht die Emulation der Profile PBAP, MAP und HFP, um Fahrzeug-Infotainmentsysteme und ähnliche Geräte zu testen, die diese Profile verwenden. nOBEX stellt PBAP- und MAP-Clients bereit, um die echten virtuellen Dateisysteme dieser Profile von echten Telefonen zu klonen. Das bedeutet, das gesamte Telefonbuch und alle Textnachrichten herunterzuladen. Roh-Vcards, XML-Auflistungen und MAP-BMSG-Strukturen werden gespeichert und können für Negativtests beliebig verändert werden. nOBEX kann dann als PBAP- und MAP-Server fungieren und Fahrzeugen sowie anderen Geräten erlauben, sich zu verbinden und Telefonbuch- und Nachrichteninformationen abzurufen. Vcards, BMSGs und XML-Auflistungen werden exakt so gesendet, wie sie gespeichert sind, sodass fehlerhaft vom Benutzer veränderte Daten durchgehen. Da die meisten Fahrzeug-Head-Units HFP-Unterstützung benötigen, bevor sie PBAP und MAP verwenden, bietet nOBEX auch eine rudimentäre HFP-Unterstützung. Es sendet benutzerdefinierbare voreingestellte Antworten auf AT-Befehle, die vom Head-Unit des Fahrzeugs kommen. Dadurch kann ein echtes Mobiltelefon nachgeahmt werden.
nOBEX basiert auf dem Projekt PyOBEX von David Boddie. Dieses Werkzeug wäre ohne Davids große Bemühungen, OBEX zugänglich und einfach handhabbar zu machen, nicht möglich gewesen. nOBEX erweitert PyOBEX um Unterstützung für große mehrteilige OBEX-Nachrichten, HFP-Emulation, PBAP- und MAP-Server, einen MAP-Client und einen verbesserten PBAP-Client.
nOBEX (und PyOBEX) verwenden den BlueZ-Bluetooth-Stack, um über das Service Discovery Protocol (SDP) zu werben und RFCOMM-Verbindungen aufzubauen. nOBEX/PyOBEX enthalten eigenständige Implementierungen der OBEX-Spezifikation für Client- und Serverrollen. Sowohl Python 2 als auch 3 werden unterstützt.
Im Client-Modus verwendet nOBEX BlueZ, um die vom Server angebotenen Dienste abzufragen. Wenn es erkennt, dass der angeforderte Dienst verfügbar ist, verbindet es sich über RFCOMM mit dem Server auf dem über SDP angegebenen Port. OBEX-Anfragen werden entsprechend des verwendeten Profils erstellt und an den Server gesendet. Antworten werden interpretiert und auf der Festplatte gespeichert. Die Client-Modi für PBAP und MAP können verwendet werden, um ein echtes Telefon zu klonen.
Im Server-Modus bewirbt nOBEX die verfügbaren Dienste über SDP. Wenn ein Client eine RFCOMM-Verbindung auf dem beworbenen Port herstellt, akzeptiert der Server die Verbindung und verarbeitet OBEX-Anfragen. OBEX-Antworten auf Anfragen werden mithilfe der auf der Festplatte gespeicherten Daten gesendet. Die PBAP- und MAP-Server liefern Datei-/Ordnerstrukturen, die den von den jeweiligen Clients erzeugten entsprechen.
Die folgenden Einrichtungsanweisungen wurden auf Fedora 24, 27 und 29 getestet. Andere aktuelle Distributionen funktionieren möglicherweise ebenfalls, aber die Erfahrungen können unterschiedlich sein. Möglicherweise müssen Sie die älteren BlueZ-Werkzeuge (einschließlich sdptool) installieren, wenn Ihre Distribution sdptool nicht enthält. Beachten Sie außerdem, dass OBEX-Server in virtuellen Maschinen mit gemeinsam genutzten Bluetooth-Adaptern tendenziell nicht funktionieren. Führen Sie Linux entweder nativ aus oder verwenden Sie einen dedizierten USB-Bluetooth-Adapter, der nur von der VM verwendet wird.
Versuchen Sie, die beworbenen lokalen Dienste über SDP abzufragen:
sudo sdptool browse local
Wenn Sie eine aktuelle Distribution verwenden, schlägt dies wahrscheinlich aufgrund einiger bahnbrechender API-Änderungen in BlueZ 5 fehl. Sie können das beheben, indem Sie bluetoothd im Kompatibilitätsmodus ausführen. Tun Sie dies, indem Sie den systemd-Dienst für bluetoothd bearbeiten.
sudo vi /usr/lib/systemd/system/bluetooth.service
Fügen Sie --compat zur ExecStart-Zeile hinzu:
ExecStart=/usr/libexec/bluetooth/bluetoothd --compat
Starten Sie nun bluetoothd neu:
sudo service bluetooth stop
sudo systemctl daemon-reload
sudo service bluetooth start
sudo hciconfig -a hci0 reset
Testen Sie erneut das Durchsuchen lokaler SDP-Dienste (diesmal sollte es funktionieren):
sudo sdptool browse local
Holen Sie sich nOBEX und installieren Sie es:
git clone https://github.com/nccgroup/nOBEX.git
cd nOBEX
sudo python3 setup.py install
Ermitteln Sie die MAC-Adresse eines Telefons, dessen Telefonbuch Sie klonen möchten:
hcitool scan
Klonen Sie den PBAP-Inhalt eines vorhandenen Telefons (verwenden Sie Ihre korrekte MAC-Adresse und ein möglichst leeres oder nicht vorhandenes Zielverzeichnis Ihrer Wahl):
python3 examples/pbapclient.py 5C:51:88:8A:EC:5B ~/pbap_root/
Alternativ können Sie den PBAP-Beispieldatenbaum im Ordner examples/pbap_root verwenden.
Ändern Sie die Vcards und Listing-XMLs in Ihrem PBAP-Dump-Verzeichnis nach Wunsch. Führen Sie nun einen PBAP-Server mit dem geklonten Telefonbuch aus:
sudo python3 examples/multiserver.py --pbap ~/pbap_root/
Sie müssen außerdem Ihren PBAP-Client mit dem Computer (PBAP-Server) koppeln.
Ziehen Sie die Nachrichtendaten von Ihrem Telefon, um einen MAP-Testbaum einzurichten:
python3 examples/mapclient.py 5C:51:88:8A:EC:5B ~/map_root/
Alternativ können Sie, wenn Ihr Telefon MAP nicht ordnungsgemäß unterstützt, den MAP-Beispieldatenbaum im Ordner examples/map_root verwenden.
Ändern Sie die Beispieldaten nach Wunsch. Führen Sie dann den Server aus und geben Sie an, wo er die Wurzel des MAP-Baums suchen soll.
sudo python3 examples/multiserver.py --map ~/map_root/
Der HFP-Client (Freisprecheinrichtung, Fahrzeug-Freisprecheinrichtungs-Emulator) bietet eine AT-Befehls-CLI, um mit Ihrem HFAG (Telefon/Modem) zu sprechen. Ich nenne ihn den "HFP-Client", obwohl er ein RFCOMM-Server ist, weil er ein "Client" für den HFAG (Telefon/Modem) ist. Sie verwenden den HF-Emulator ("Client"), um AT-Befehle an den HFAG zu senden, obwohl der "Server" (HFAG) derjenige ist, der die RFCOMM-Verbindung initiiert.
Um den HF-Emulator auszuführen:
sudo python3 examples/hfpclient.py
Möglicherweise müssen Sie den HF-Emulator starten, um über SDP zu bewerben, dass Sie ein HF sind, bevor Sie Ihr Telefon koppeln. Wenn der HF-Emulator läuft, initiiert Ihr Telefon eine AT-Befehls-RFCOMM-Verbindung mit dem Emulator-Skript. Um diesen Prozess zu beschleunigen, können Sie in den Bluetooth-Einstellungen Ihres Telefons auf Ihren gekoppelten Computer klicken, um eine Verbindung/Wiederverbindung auszulösen.
Sobald der HFAG (Telefon/Modem) eine Verbindung initiiert, haben Sie normalerweise ein begrenztes Zeitfenster (30 Sekunden bis eine Minute), um die HFP-Sitzung zu konfigurieren. Bevor Sie nützliche AT-Befehle senden können (z. B. Telefonanrufe initiieren), müssen Sie innerhalb des begrenzten Zeitfensters eine Reihe von AT-Befehlen senden, andernfalls könnte sich der HFAG von Ihnen trennen. Die folgende anfängliche AT-Befehlssequenz sollte bei den meisten Telefonen funktionieren:
AT+BRSF=39
AT+CIND=?
AT+CIND?
AT+CMER=3,0,0,1
AT+CHLD=?
AT+CCWA=1
AT+CLIP=1
AT+NREC=0
Der HFP-Server (Audio Gateway) ist recht einfach gehalten und sendet vorkonfigurierte Antworten auf ausgewählte Befehle zurück. Der Server ist so eingerichtet, dass er gängige HFP-Befehle standardmäßig unterstützt, aber jedes Fahrzeug wird wahrscheinlich ein paar zusätzliche Befehle und/oder Änderungen an den Antworten erfordern. Benutzerdefinierte Antworten können über eine Textdatei konfiguriert werden, deren Format in jeder Zeile ein Paar aus Befehl und Antwort ist, wobei Befehl und Antwort durch einen Tabulator getrennt sind. Beispielkonfigurationsdateien finden Sie im Ordner examples/bbeast.