nccgroup/nobexnOBEX allows emulating the PBAP, MAP, and HFP profiles to test vehicle infotainment systems and similar devices using these profiles
nOBEX permite emular los perfiles PBAP, MAP y HFP para probar sistemas de infoentretenimiento de vehículos y dispositivos similares que usan estos perfiles. nOBEX proporciona clientes PBAP y MAP para clonar los sistemas de archivos virtuales genuinos de estos perfiles desde un teléfono real. Esto significa descargar la agenda telefónica completa y todos los mensajes de texto. Las vcards sin procesar, los listados XML y las estructuras MAP BMSG se almacenan y pueden modificarse según se desee para pruebas negativas. nOBEX puede actuar entonces como servidor PBAP y MAP, permitiendo que vehículos y otros dispositivos se conecten a él y recuperen información de la agenda y los mensajes. Las vcards, BMSGs y listados XML se envían exactamente como se guardaron, permitiendo que datos malformados modificados por el usuario pasen. Dado que la mayoría de las unidades principales de vehículos requieren soporte HFP antes de intentar usar PBAP y MAP, nOBEX también proporciona soporte rudimentario para HFP. Enviará respuestas preestablecidas personalizables por el usuario a los comandos AT que provengan de la unidad principal del vehículo. Esto permite imitar un teléfono celular real.
nOBEX está construido sobre el proyecto PyOBEX de David Boddie. Esta herramienta no habría sido posible sin los grandes esfuerzos de David para hacer que OBEX sea accesible y fácil de usar. nOBEX extiende PyOBEX añadiendo soporte para mensajes OBEX grandes de múltiples partes, emulación HFP, servidores PBAP y MAP, un cliente MAP y un cliente PBAP mejorado.
nOBEX (y PyOBEX) usan la pila Bluetooth BlueZ para anunciarse a través del Protocolo de Descubrimiento de Servicios (SDP) y establecer conexiones RFCOMM. nOBEX/PyOBEX contienen implementaciones independientes de la especificación OBEX para roles de cliente y servidor. Se admiten tanto Python 2 como 3.
En modo cliente, nOBEX usa BlueZ para consultar los servicios ofrecidos por el servidor. Si detecta que el servicio solicitado está disponible, se conecta al servidor a través de RFCOMM en el puerto especificado a través de SDP. Las solicitudes OBEX se construyen y se envían al servidor de acuerdo con el perfil en uso. Las respuestas se interpretan y se guardan en disco. Los modos cliente para PBAP y MAP se pueden usar para clonar un teléfono real.
En modo servidor, nOBEX anuncia los servicios disponibles a través de SDP. Cuando un cliente realiza una conexión RFCOMM en el puerto anunciado, el servidor aceptará y manejará las solicitudes OBEX. Las respuestas OBEX a las solicitudes se enviarán usando los datos en disco. Los servidores PBAP y MAP sirven estructuras de archivos/carpetas que coinciden con las generadas por los respectivos clientes.
Las siguientes instrucciones de configuración se probaron en Fedora 24, 27 y 29. Otras distribuciones recientes también pueden funcionar, pero las experiencias pueden variar. Es posible que necesites instalar herramientas bluez heredadas (incluido sdptool) si tu distribución no incluye sdptool. Ten en cuenta también que los servidores OBEX tienden a no funcionar dentro de máquinas virtuales con adaptadores Bluetooth compartidos. Ejecuta Linux de forma nativa o ten un adaptador Bluetooth USB dedicado usado solo por la VM.
Intenta explorar los servicios locales anunciados en SDP:
sudo sdptool browse local
Si estás ejecutando una distribución reciente, probablemente fallará debido a algunos cambios importantes en la API de BlueZ 5. Puedes solucionarlo ejecutando bluetoothd en modo compat. Hazlo editando el servicio systemd para bluetoothd.
sudo vi /usr/lib/systemd/system/bluetooth.service
Añade --compat a la línea ExecStart:
ExecStart=/usr/libexec/bluetooth/bluetoothd --compat
Ahora reinicia bluetoothd:
sudo service bluetooth stop
sudo systemctl daemon-reload
sudo service bluetooth start
sudo hciconfig -a hci0 reset
Prueba de nuevo a explorar los servicios SDP locales (esta vez debería funcionar):
sudo sdptool browse local
Obtén nOBEX e instálalo:
git clone https://github.com/nccgroup/nOBEX.git
cd nOBEX
sudo python3 setup.py install
Encuentra la dirección MAC de un teléfono cuya agenda telefónica desees clonar:
hcitool scan
Clona el contenido PBAP de un teléfono existente (usa tu MAC correcta y, preferiblemente, un directorio de destino vacío o inexistente de tu elección):
python3 examples/pbapclient.py 5C:51:88:8A:EC:5B ~/pbap_root/
Alternativamente, usa el árbol de datos de muestra PBAP ubicado en la carpeta examples/pbap_root.
Modifica las vcards y los XML de listados en tu directorio de volcado PBAP como desees. Ahora ejecuta un servidor PBAP usando la agenda telefónica clonada:
sudo python3 examples/multiserver.py --pbap ~/pbap_root/
También necesitarás vincular tu cliente PBAP con la computadora (servidor PBAP).
Extrae los datos de mensajes de tu teléfono para establecer un árbol MAP de prueba:
python3 examples/mapclient.py 5C:51:88:8A:EC:5B ~/map_root/
Alternativamente, si tu teléfono no soporta MAP correctamente, usa el árbol de datos de muestra MAP
ubicado en la carpeta examples/map_root.
Modifica los datos de muestra como desees. Luego ejecuta el servidor, indicando dónde debe buscar la raíz del árbol MAP.
sudo python3 examples/multiserver.py --map ~/map_root/
El cliente HFP (manos libres, emulador de kit de coche) proporciona una CLI de comandos AT para hablar con tu HFAG (teléfono/módem). Lo llamo "cliente HFP" a pesar de ser un servidor RFCOMM porque es un "cliente" para el HFAG (teléfono/módem). Usas el emulador HF ("cliente") para enviar comandos AT al HFAG, a pesar de que el "servidor" (HFAG) es el que inicia la conexión RFCOMM.
Para ejecutar el emulador HF:
sudo python3 examples/hfpclient.py
Puede que necesites iniciar el emulador HF para anunciar que eres un HF a través de SDP antes de vincular tu teléfono. Cuando el emulador HF está en ejecución, tu teléfono iniciará una conexión RFCOMM de comandos AT con el script del emulador. Para acelerar este proceso, puedes hacer clic en tu computadora vinculada en la configuración de Bluetooth de tu teléfono para activar una conexión/reconexión.
Una vez que el HFAG (teléfono/módem) inicia una conexión, normalmente tienes una ventana limitada (30 segundos a un minuto) para configurar la sesión HFP. Antes de poder enviar comandos AT útiles (como iniciar llamadas telefónicas), tienes que enviar una secuencia de comandos AT dentro de la ventana limitada, de lo contrario el HFAG podría desconectarte. La siguiente secuencia inicial de comandos AT debería funcionar para la mayoría de los teléfonos:
AT+BRSF=39
AT+CIND=?
AT+CIND?
AT+CMER=3,0,0,1
AT+CHLD=?
AT+CCWA=1
AT+CLIP=1
AT+NREC=0
El servidor HFP (puerta de enlace de audio) es bastante básico, enviando respuestas preconfiguradas a comandos seleccionados. El servidor está configurado para soportar comandos HFP comunes de serie, pero cada vehículo probablemente requerirá algunos comandos adicionales y/o cambios en las respuestas. Las respuestas personalizadas se pueden configurar a través de un archivo de texto con un formato de pares comando y respuesta en cada línea, donde el comando y la respuesta están separados por un tabulador. Los archivos de configuración de muestra se pueden encontrar en la carpeta examples/bbeast.
A diferencia de los otros servidores, la implementación HFP AG de nOBEX en realidad no acepta conexiones RFCOMM. El estándar HFP es ambiguo sobre cómo se deben establecer las conexiones y, por lo tanto, tanto el HF como el AG pueden aceptar e iniciar conexiones. Diferentes unidades principales se comportan de manera diferente en lo que respecta a las prácticas de establecimiento de conexiones. Sin embargo, la mayoría de los dispositivos HF tienden a aceptar ser conectados por el AG si el AG no acepta conexiones en su propio puerto. Por lo tanto, el "servidor" HFP AG de nOBEX simplemente busca entre los dispositivos vinculados aquellos que soporten el servicio HF, y luego nOBEX se conecta al dispositivo HF.
Ten en cuenta que el código HFP AG intentará conectarse a cualquier dispositivo listado bajo
/var/lib/bluetooth/*/* que afirme soportar el rol HFP HF. Por lo tanto, debes
eliminar cualquier vinculación errónea en ese directorio antes de intentar usar el servidor HFP.
Para ejecutar un HFP AG independiente (el archivo de configuración es opcional):
sudo python3 examples/multiserver.py --hfp [config_file]
El servidor HFP (HFAG) también soporta operación interactiva donde puedes editar las auto-respuestas en tiempo de ejecución o enviar respuestas AT manualmente. El servidor HFP escucha en el puerto 7137 de localhost para comandos. Puedes conectarte a él usando netcat como se muestra a continuación:
nc localhost 7137
Solo hay dos comandos simples para esta interfaz:
send <atresp> - envía atresp como una respuesta ATursp <atcmd> <atresp> - actualiza/establece la auto-respuesta para atcmd a atrespLos siguientes comandos de ejemplo simularán una llamada entrante:
ursp AT+CLCC +CLCC: 1,1,4,0,0,"1234567890",129
send RING
El cliente FTP (Perfil de Transferencia de Archivos) te permite navegar por archivos en un servidor OBEX FTP, como otra computadora que ejecute nOBEX, o un teléfono Android que ejecute la aplicación Bluetooth File Transfer. Hay un programa de ejemplo de cliente FTP ubicado en el directorio examples.
python3 examples/ftpclient.py SERVER_MAC_ADDRESS [save_directory]
Ejecutar el cliente FTP de ejemplo con solo una dirección MAC Bluetooth como argumento imprimirá
un listado recursivo de directorios de todos los archivos accesibles a través de OBEX FTP en el servidor. Si
se proporciona el argumento opcional save_directory, el script descargará cada archivo que sea
accesible en el servidor y lo guardará en el directorio de guardado especificado en tu computadora.
El servidor FTP permite a un cliente navegar por archivos en tu computadora (servidor) dentro de una carpeta especificada.
sudo python3 examples/multiserver.py --ftp PATH_TO_FTP_FOLDER
El cliente OPP (Perfil de Envío de Objetos) permite enviar un archivo en tu computadora a un servidor OBEX OPP.
python3 examples/pushclient.py SERVER_MAC_ADDRESS FILE_TO_PUSH
El servidor OPP permite a un cliente enviar archivos a tu computadora (servidor) dentro de una carpeta especificada.
sudo python3 examples/multiserver.py --opp PATH_TO_OPP_FOLDER
El script multiserver.py permite ejecutar cualquier combinación de servidores HFP, MAP, PBAP, FTP y OPP simultáneamente. Solo combina los argumentos de los ejemplos mostrados arriba. Para ejecutar HFP, MAP y PBAP simultáneamente:
python3 examples/multiserver.py --map ~/map_root/ --pbap ~/pbap_root/ --hfp [config_file]
La combinación de HFP y PBAP se ha probado con éxito en un Ford Focus 2012.
El propósito principal de nOBEX es realizar pruebas negativas y fuzzing de clientes PBAP y MAP en unidades principales automotrices. El soporte HFP y el soporte de clientes PBAP/MAP están destinados a facilitar este objetivo. El fuzzing manual se puede realizar ejecutando un servidor con listados XML, vcards y BMSGs modificados a mano. OBEX es un objetivo de fuzzing rico con muchas estructuras TLV anidadas que pueden abarcar mensajes de múltiples partes. PBAP y MAP aumentan enormemente la superficie de ataque con analizadores de vcard, BMSG y XML.
nOBEX no tiene soporte integrado para fuzzing automatizado, pero dado que está escrito en Python, es fácil de extender. Se pueden construir capacidades de fuzzing más potentes combinándolo con un motor de mutación e instrumentando el dispositivo objetivo.
Más allá del fuzzing de MAP y PBAP en unidades principales automotrices, nOBEX también se puede usar para pruebas positivas normales de PBAP, MAP y otros perfiles OBEX (como FTP) tanto para roles de cliente como de servidor. Los servidores PBAP y MAP se probaron con la aplicación OBEX Commander para Android, en la que se pudieron provocar muchos bloqueos mediante comunicación OBEX defectuosa y datos específicos del perfil malformados. Además, el soporte HFP se puede usar para hacer fuzzing manual de comandos AT.