nccgroup/nobexnOBEX permite emular los perfiles PBAP, MAP y HFP para probar sistemas de infoentretenimiento de vehículos y dispositivos similares que utilizan estos perfiles
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.