nccgroup/nobexnOBEX allows emulating the PBAP, MAP, and HFP profiles to test vehicle infotainment systems and similar devices using these profiles
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.
Anders als die anderen Server akzeptiert die nOBEX-HFP-AG-Implementierung tatsächlich keine RFCOMM-Verbindungen. Der HFP-Standard ist mehrdeutig darüber, wie Verbindungen aufgebaut werden sollen, und daher ist es sowohl dem HF als auch dem AG erlaubt, Verbindungen zu akzeptieren und zu initiieren. Verschiedene Head-Units verhalten sich beim Verbindungsaufbau unterschiedlich. Die meisten HF-Geräte akzeptieren jedoch tendenziell, dass der AG sich mit ihnen verbindet, wenn der AG keine Verbindungen auf seinem eigenen Port akzeptiert. Daher durchsucht der nOBEX-HFP-AG-"Server" einfach gekoppelte Geräte nach solchen, die den HF-Dienst unterstützen, und nOBEX verbindet sich dann mit dem HF-Gerät.
Beachten Sie, dass der HFP-AG-Code versucht, sich mit jedem Gerät unter /var/lib/bluetooth/*/* zu verbinden, das angibt, die HFP-HF-Rolle zu unterstützen. Daher sollten Sie alle fehlerhaften Kopplungen in diesem Verzeichnis löschen, bevor Sie den HFP-Server verwenden.
Um einen eigenständigen HFP-AG auszuführen (Konfigurationsdatei optional):
sudo python3 examples/multiserver.py --hfp [config_file]
Der HFP-Server (HFAG) unterstützt außerdem den interaktiven Betrieb, bei dem Sie automatische Antworten zur Laufzeit bearbeiten oder AT-Antworten manuell senden können. Der HFP-Server lauscht auf Port 7137 von localhost auf Befehle. Sie können sich wie unten gezeigt mit netcat verbinden:
nc localhost 7137
Es gibt nur zwei einfache Befehle für diese Schnittstelle:
send <atresp> - atresp als AT-Antwort sendenursp <atcmd> <atresp> - die automatische Antwort für atcmd auf atresp aktualisieren/festlegenDie folgenden Beispielbefehle simulieren einen eingehenden Telefonanruf:
ursp AT+CLCC +CLCC: 1,1,4,0,0,"1234567890",129
send RING
Der FTP-Client (File Transfer Profile) ermöglicht es Ihnen, Dateien auf einem OBEX-FTP-Server zu durchsuchen, z. B. einem anderen Computer mit nOBEX oder einem Android-Telefon mit der App Bluetooth File Transfer. Im Verzeichnis examples befindet sich ein Beispielprogramm für einen FTP-Client.
python3 examples/ftpclient.py SERVER_MAC_ADDRESS [save_directory]
Wenn Sie den Beispiel-FTP-Client nur mit einer Bluetooth-MAC-Adresse als Argument ausführen, wird eine rekursive Verzeichnisliste aller Dateien ausgegeben, die über OBEX-FTP auf dem Server zugänglich sind. Wenn das optionale Argument save_directory angegeben wird, lädt das Skript jede Datei herunter, die auf dem Server zugänglich ist, und speichert sie im angegebenen Zielverzeichnis auf Ihrem Computer.
Der FTP-Server ermöglicht einem Client, Dateien auf Ihrem Computer (Server) innerhalb eines angegebenen Ordners zu durchsuchen.
sudo python3 examples/multiserver.py --ftp PATH_TO_FTP_FOLDER
Der OPP-Client (Object Push Profile) ermöglicht das Übertragen einer Datei von Ihrem Computer an einen OBEX-OPP-Server.
python3 examples/pushclient.py SERVER_MAC_ADDRESS FILE_TO_PUSH
Der OPP-Server ermöglicht einem Client, Dateien in einen angegebenen Ordner auf Ihrem Computer (Server) zu übertragen.
sudo python3 examples/multiserver.py --opp PATH_TO_OPP_FOLDER
Die Skripte multiserver.py ermöglichen den gleichzeitigen Betrieb einer beliebigen Kombination aus HFP-, MAP-, PBAP-, FTP- und OPP-Servern. Kombinieren Sie einfach die Argumente aus den obigen Beispielen. Um HFP, MAP und PBAP gleichzeitig auszuführen:
python3 examples/multiserver.py --map ~/map_root/ --pbap ~/pbap_root/ --hfp [config_file]
Die Kombination aus HFP und PBAP wurde erfolgreich an einem Ford Focus von 2012 getestet.
Der Hauptzweck von nOBEX ist das Durchführen von Negativtests und Fuzzing von PBAP- und MAP-Clients auf Automotive-Head-Units. Die HFP-Unterstützung und die PBAP/MAP-Clientunterstützung sollen dieses Ziel erleichtern. Manuelles Fuzzing kann durchgeführt werden, indem ein Server mit manuell modifizierten XML-Auflistungen, Vcards und BMSGs ausgeführt wird. OBEX ist ein ergiebiges Fuzzing-Ziel mit vielen verschachtelten TLV-Strukturen, die sich über mehrteilige Nachrichten erstrecken können. PBAP und MAP vergrößern die Angriffsfläche erheblich durch Vcard-, BMSG- und XML-Parser.
nOBEX verfügt über keine integrierte Unterstützung für automatisiertes Fuzzing, aber da es in Python geschrieben ist, lässt es sich leicht erweitern. Leistungsfähigere Fuzzing-Fähigkeiten können aufgebaut werden, indem man es mit einer Mutations-Engine kombiniert und das Zielgerät instrumentiert.
Über das Fuzzing von MAP und PBAP auf Automotive-Head-Units hinaus kann nOBEX auch für normale Positivtests von PBAP, MAP und anderen OBEX-Profilen (wie FTP) sowohl für Client- als auch für Serverrollen verwendet werden. Die PBAP- und MAP-Server wurden mit der Android-App OBEX Commander getestet, bei der viele Abstürze durch fehlerhafte OBEX-Kommunikation und fehlerhafte profilspezifische Daten ausgelöst werden konnten. Darüber hinaus kann die HFP-Unterstützung verwendet werden, um AT-Befehle manuell zu fuzzen.