nccgroup/nobexnOBEX consente di emulare i profili PBAP, MAP e HFP per testare i sistemi di infotainment dei veicoli e dispositivi simili che utilizzano questi profili.
nOBEX consente di emulare i profili PBAP, MAP e HFP per testare i sistemi di infotainment dei veicoli e dispositivi simili che utilizzano questi profili. nOBEX fornisce client PBAP e MAP per clonare i filesystem virtuali genuini di questi profili da telefoni reali. Ciò significa scaricare l'intera rubrica telefonica e tutti i messaggi di testo. Vcard grezze, elenchi XML e strutture MAP BMSG vengono salvati e possono essere modificati a piacere per test negativi. nOBEX può quindi agire come server PBAP e MAP, consentendo a veicoli e altri dispositivi di connettersi e recuperare informazioni di rubrica e messaggi. Vcard, BMSG ed elenchi XML vengono inviati esattamente come salvati, consentendo il passaggio di dati malformati modificati dall'utente. Poiché la maggior parte dei moduli head unit dei veicoli richiede il supporto HFP prima di tentare di utilizzare PBAP e MAP, nOBEX fornisce anche un supporto rudimentale per HFP. Invia risposte preimpostate personalizzabili dall'utente ai comandi AT provenienti dal modulo head unit del veicolo. Ciò consente di simulare un vero telefono cellulare.
nOBEX è costruito sul progetto PyOBEX di David Boddie. Questo strumento non sarebbe stato possibile senza i grandi sforzi di David nel rendere OBEX accessibile e facile da usare. nOBEX estende PyOBEX aggiungendo il supporto per messaggi OBEX multiparte di grandi dimensioni, emulazione HFP, server PBAP e MAP, un client MAP e un client PBAP migliorato.
nOBEX (e PyOBEX) utilizzano lo stack Bluetooth BlueZ per pubblicizzare i servizi tramite il Service Discovery Protocol (SDP) e stabilire connessioni RFCOMM. nOBEX/PyOBEX contengono implementazioni standalone della specifica OBEX per i ruoli di client e server. Sono supportati sia Python 2 che Python 3.
Nella modalità client, nOBEX utilizza BlueZ per interrogare i servizi offerti dal server. Se rileva che il servizio richiesto è disponibile, si connette al server tramite RFCOMM sulla porta specificata tramite SDP. Le richieste OBEX vengono costruite e inviate al server in base al profilo in uso. Le risposte vengono interpretate e salvate su disco. Le modalità client per PBAP e MAP possono essere utilizzate per clonare un telefono reale.
Nella modalità server, nOBEX pubblicizza i servizi disponibili tramite SDP. Quando un client stabilisce una connessione RFCOMM sulla porta pubblicizzata, il server accetta e gestisce le richieste OBEX. Le risposte OBEX alle richieste verranno inviate utilizzando i dati su disco. I server PBAP e MAP servono strutture di file/cartelle corrispondenti a quelle generate dai rispettivi client.
Le seguenti istruzioni di configurazione sono state testate su Fedora 24, 27 e 29. Anche altre distribuzioni recenti potrebbero funzionare, ma l'esperienza può variare. Potrebbe essere necessario installare i tool bluez legacy (incluso sdptool) se la vostra distribuzione non include sdptool. Inoltre, tieni presente che i server OBEX tendono a non funzionare all'interno di macchine virtuali con adattatori Bluetooth condivisi. Esegui Linux nativamente oppure utilizza un adattatore Bluetooth USB dedicato usato solo dalla VM.
Prova a interrogare i servizi locali pubblicizzati su SDP:
sudo sdptool browse local
Se stai eseguendo una distribuzione recente, probabilmente fallirà a causa di alcune modifiche alle API che rompono la compatibilità in BlueZ 5. Puoi risolverlo eseguendo bluetoothd in modalità compat. Per farlo, modifica il servizio systemd per bluetoothd.
sudo vi /usr/lib/systemd/system/bluetooth.service
Aggiungi --compat alla riga ExecStart:
ExecStart=/usr/libexec/bluetooth/bluetoothd --compat
Ora riavvia bluetoothd:
sudo service bluetooth stop
sudo systemctl daemon-reload
sudo service bluetooth start
sudo hciconfig -a hci0 reset
Testa di nuovo la navigazione dei servizi SDP locali (questa volta dovrebbe funzionare):
sudo sdptool browse local
Ottieni nOBEX e installalo:
git clone https://github.com/nccgroup/nOBEX.git
cd nOBEX
sudo python3 setup.py install
Trova l'indirizzo MAC di un telefono di cui desideri clonare la rubrica:
hcitool scan
Clona il contenuto PBAP di un telefono esistente (usa il tuo MAC corretto e una directory di destinazione preferibilmente vuota o inesistente a tua scelta):
python3 examples/pbapclient.py 5C:51:88:8A:EC:5B ~/pbap_root/
In alternativa, utilizza l'albero di dati di esempio PBAP situato nella cartella examples/pbap_root.
Modifica le vcard e gli XML di elenco nella tua directory di dump PBAP come desideri. Ora esegui un server PBAP utilizzando la rubrica clonata:
sudo python3 examples/multiserver.py --pbap ~/pbap_root/
Dovrai anche associare il tuo client PBAP al computer (server PBAP).
Recupera i dati dei messaggi dal tuo telefono per creare un albero MAP di test:
python3 examples/mapclient.py 5C:51:88:8A:EC:5B ~/map_root/
In alternativa, se il tuo telefono non supporta MAP correttamente, utilizza l'albero di dati
di esempio MAP situato nella cartella examples/map_root.
Modifica i dati di esempio come desideri. Quindi esegui il server, indicando dove deve cercare la radice dell'albero MAP.
sudo python3 examples/multiserver.py --map ~/map_root/
Il client HFP (viva voce, emulatore di kit auto) fornisce una CLI per comandi AT per comunicare con il tuo HFAG (telefono/modem). Lo chiamo "client HFP" nonostante sia un server RFCOMM perché è un "client" per l'HFAG (telefono/modem). Usi l'emulatore HF ("client") per inviare comandi AT all'HFAG, nonostante sia il "server" (HFAG) a iniziare la connessione RFCOMM.
Per eseguire l'emulatore HF:
sudo python3 examples/hfpclient.py
Potrebbe essere necessario avviare l'emulatore HF per pubblicizzare tramite SDP che sei un HF prima di associare il telefono. Quando l'emulatore HF è in esecuzione, il telefono inizierà una connessione RFCOMM per comandi AT con lo script dell'emulatore. Per accelerare il processo, puoi fare clic sul computer associato nelle impostazioni Bluetooth del telefono per attivare una connessione/riconnessione.
Una volta che l'HFAG (telefono/modem) avvia una connessione, di solito hai una finestra di tempo limitata (da 30 secondi a un minuto) per configurare la sessione HFP. Prima di poter inviare comandi AT utili (come avviare chiamate), devi inviare una sequenza di comandi AT entro la finestra di tempo limitata, altrimenti l'HFAG potrebbe disconnettersi. La seguente sequenza iniziale di comandi AT dovrebbe funzionare per la maggior parte dei telefoni:
AT+BRSF=39
AT+CIND=?
AT+CIND?
AT+CMER=3,0,0,1
AT+CHLD=?
AT+CCWA=1
AT+CLIP=1
AT+NREC=0
Il server HFP (audio gateway) è abbastanza semplice: invia risposte preconfigurate a comandi selezionati. Il server è configurato per supportare i comandi HFP comuni fin da subito, ma ogni veicolo richiederà probabilmente alcuni comandi aggiuntivi e/o modifiche alle risposte. Le risposte personalizzate possono essere configurate tramite un file di testo con un formato di coppie comando e risposta su ogni riga, comando e risposta separati da una tabulazione. I file di configurazione di esempio si trovano nella cartella examples/bbeast.