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.
A differenza degli altri server, l'implementazione HFP AG di nOBEX non accetta effettivamente connessioni RFCOMM. Lo standard HFP è ambiguo su come dovrebbero essere stabilite le connessioni e quindi sia HF che AG possono accettare e avviare connessioni. Diversi moduli head unit si comportano in modo diverso per quanto riguarda le pratiche di stabilimento della connessione. Tuttavia, la maggior parte dei dispositivi HF tende ad accettare la connessione da parte dell'AG se l'AG non accetta connessioni sulla propria porta. Pertanto, il "server" HFP AG di nOBEX cerca semplicemente tra i dispositivi associati quelli che supportano il servizio HF e poi si connette al dispositivo HF.
Tieni presente che il codice HFP AG proverà a connettersi a qualsiasi dispositivo elencato in
/var/lib/bluetooth/*/* che dichiari di supportare il ruolo HFP HF. Pertanto, dovresti eliminare
eventuali associazioni errate in quella directory prima di tentare di utilizzare il server HFP.
Per eseguire un HFP AG standalone (il file di configurazione è opzionale):
sudo python3 examples/multiserver.py --hfp [config_file]
Il server HFP (HFAG) supporta anche l'operazione interattiva in cui puoi modificare le auto-risposte a runtime o inviare manualmente risposte AT. Il server HFP ascolta i comandi sulla porta 7137 di localhost. Puoi connetterti ad esso usando netcat come mostrato di seguito:
nc localhost 7137
Ci sono solo due semplici comandi per questa interfaccia:
send <atresp> - invia atresp come risposta ATursp <atcmd> <atresp> - aggiorna/imposta l'auto-risposta per atcmd a atrespI seguenti comandi di esempio simuleranno una chiamata in arrivo:
ursp AT+CLCC +CLCC: 1,1,4,0,0,"1234567890",129
send RING
Il client FTP (File Transfer Profile) consente di navigare tra i file su un server OBEX FTP, come un altro computer che esegue nOBEX o un telefono Android che esegue l'app Bluetooth File Transfer. C'è un programma di esempio per il client FTP nella directory examples.
python3 examples/ftpclient.py SERVER_MAC_ADDRESS [save_directory]
Eseguendo il client FTP di esempio con solo un indirizzo MAC Bluetooth come argomento verrà stampato
un elenco ricorsivo delle directory di tutti i file accessibili tramite OBEX FTP sul server. Se viene
fornito l'argomento opzionale save_directory, lo script scaricherà ogni file accessibile sul server
e lo salverà nella directory di salvataggio specificata sul tuo computer.
Il server FTP consente a un client di navigare tra i file sul tuo computer (server) all'interno di una cartella specificata.
sudo python3 examples/multiserver.py --ftp PATH_TO_FTP_FOLDER
Il client OPP (Object Push Profile) consente di inviare un file dal tuo computer a un server OBEX OPP.
python3 examples/pushclient.py SERVER_MAC_ADDRESS FILE_TO_PUSH
Il server OPP consente a un client di inviare file al tuo computer (server) all'interno di una cartella specificata.
sudo python3 examples/multiserver.py --opp PATH_TO_OPP_FOLDER
Lo script multiserver.py consente di eseguire simultaneamente qualsiasi combinazione di server HFP, MAP, PBAP, FTP e OPP. Basta combinare gli argomenti degli esempi mostrati sopra. Per eseguire HFP, MAP e PBAP simultaneamente:
python3 examples/multiserver.py --map ~/map_root/ --pbap ~/pbap_root/ --hfp [config_file]
La combinazione di HFP e PBAP è stata testata con successo su una Ford Focus del 2012.
Lo scopo principale di nOBEX è eseguire test negativi e fuzzing dei client PBAP e MAP sui moduli head unit automobilistici. Il supporto HFP e il supporto client PBAP/MAP hanno lo scopo di facilitare questo obiettivo. Il fuzzing manuale può essere eseguito avviando un server con elenchi XML, vcard e BMSG modificati manualmente. OBEX è un ricco bersaglio per il fuzzing con molte strutture TLV annidate che possono estendersi su messaggi multiparte. PBAP e MAP aumentano notevolmente la superficie di attacco con parser vcard, BMSG e XML.
nOBEX non ha supporto integrato per il fuzzing automatizzato, ma poiché è scritto in Python, è facile da estendere. Capacità di fuzzing più potenti possono essere costruite abbinandolo a un motore di mutazione e strumentando il dispositivo di destinazione.
Oltre al fuzzing di MAP e PBAP sui moduli head unit automobilistici, nOBEX può essere utilizzato anche per normali test positivi di PBAP, MAP e altri profili OBEX (come FTP) sia per i ruoli di client che di server. I server PBAP e MAP sono stati testati con l'app OBEX Commander per Android, nella quale molti crash possono essere innescati da comunicazioni OBEX errate e dati specifici del profilo malformati. Inoltre, il supporto HFP può essere utilizzato per eseguire fuzzing manuale dei comandi AT.