nccgroup/nobexnOBEX allows emulating the PBAP, MAP, and HFP profiles to test vehicle infotainment systems and similar devices using these profiles
O nOBEX permite emular os perfis PBAP, MAP e HFP para testar sistemas de infoentretenimento veiculares e dispositivos similares que usam esses perfis. O nOBEX fornece clientes PBAP e MAP para clonar os sistemas de arquivos virtuais genuínos desses perfis a partir de telefones reais. Isso significa baixar a agenda telefônica inteira e todas as mensagens de texto. Vcards brutos, listagens XML e estruturas MAP BMSG são armazenados e podem ser modificados conforme desejado para testes negativos. O nOBEX pode então atuar como servidor PBAP e MAP, permitindo que veículos e outros dispositivos se conectem a ele e recuperem informações de agenda e mensagens. Vcards, BMSGs e listagens XML são enviados exatamente como salvos, permitindo que dados malformados modificados pelo usuário passem. Como a maioria das unidades de cabeça veiculares exige suporte a HFP antes de tentar usar PBAP e MAP, o nOBEX também fornece suporte rudimentar a HFP. Ele envia de volta respostas predefinidas personalizáveis a comandos AT provenientes da unidade de cabeça do veículo. Isso permite imitar um celular real.
O nOBEX é construído sobre o projeto PyOBEX de David Boddie. Esta ferramenta não teria sido possível sem os grandes esforços de David em tornar o OBEX acessível e fácil de trabalhar. O nOBEX estende o PyOBEX adicionando suporte a mensagens OBEX grandes de múltiplas partes, emulação HFP, servidores PBAP e MAP, um cliente MAP e um cliente PBAP melhorado.
O nOBEX (e o PyOBEX) usam a pilha Bluetooth BlueZ para anunciar serviços pelo Protocolo de Descoberta de Serviços (SDP) e estabelecer conexões RFCOMM. O nOBEX/PyOBEX contêm implementações independentes da especificação OBEX para papéis de cliente e servidor. Ambos Python 2 e 3 são suportados.
No modo cliente, o nOBEX usa BlueZ para consultar serviços oferecidos pelo servidor. Se detectar que o serviço solicitado está disponível, ele se conecta ao servidor via RFCOMM na porta especificada pelo SDP. As solicitações OBEX são construídas e enviadas ao servidor de acordo com o perfil em uso. As respostas são interpretadas e salvas em disco. Os modos cliente para PBAP e MAP podem ser usados para clonar um telefone real.
No modo servidor, o nOBEX anuncia os serviços disponíveis via SDP. Quando um cliente faz uma conexão RFCOMM na porta anunciada, o servidor aceita e lida com as solicitações OBEX. As respostas OBEX às solicitações serão enviadas usando os dados em disco. Os servidores PBAP e MAP servem estruturas de arquivos/pastas correspondentes às geradas pelos respectivos clientes.
As instruções de configuração a seguir foram testadas no Fedora 24, 27 e 29. Outras distribuições recentes também podem funcionar, mas as experiências podem variar. Talvez seja necessário instalar ferramentas bluez legadas (incluindo sdptool) se sua distribuição não incluir o sdptool. Esteja ciente de que servidores OBEX tendem a não funcionar em máquinas virtuais com adaptadores Bluetooth compartilhados. Ou execute Linux nativamente, ou tenha um adaptador Bluetooth USB dedicado usado apenas pela VM.
Tente consultar os serviços locais anunciados no SDP:
sudo sdptool browse local
Se você estiver usando uma distribuição recente, provavelmente falhará devido a algumas mudanças de API quebrando no BlueZ 5. Você pode corrigir isso executando o bluetoothd em modo compat. Faça isso editando o serviço systemd para bluetoothd.
sudo vi /usr/lib/systemd/system/bluetooth.service
Adicione --compat à linha ExecStart:
ExecStart=/usr/libexec/bluetooth/bluetoothd --compat
Agora reinicie o bluetoothd:
sudo service bluetooth stop
sudo systemctl daemon-reload
sudo service bluetooth start
sudo hciconfig -a hci0 reset
Teste novamente a consulta aos serviços SDP locais (deve funcionar desta vez):
sudo sdptool browse local
Obtenha o nOBEX e instale-o:
git clone https://github.com/nccgroup/nOBEX.git
cd nOBEX
sudo python3 setup.py install
Encontre o endereço MAC de um telefone cuja agenda você deseja clonar:
hcitool scan
Clone o conteúdo PBAP de um telefone existente (use seu MAC correto e um diretório de destino de sua preferência, de preferência vazio ou inexistente):
python3 examples/pbapclient.py 5C:51:88:8A:EC:5B ~/pbap_root/
Alternativamente, use a árvore de dados de exemplo PBAP localizada na pasta examples/pbap_root.
Modifique os vcards e os XMLs de listagem no diretório de dump PBAP conforme desejado. Agora execute um servidor PBAP usando a agenda clonada:
sudo python3 examples/multiserver.py --pbap ~/pbap_root/
Você também precisará parear seu cliente PBAP com o computador (servidor PBAP).
Extraia os dados de mensagens do seu telefone para estabelecer uma árvore MAP de teste:
python3 examples/mapclient.py 5C:51:88:8A:EC:5B ~/map_root/
Alternativamente, se seu telefone não suportar MAP corretamente, use a árvore de dados de exemplo MAP localizada na pasta examples/map_root.
Modifique os dados de exemplo conforme desejado. Em seguida, execute o servidor, indicando onde ele deve procurar a raiz da árvore MAP.
sudo python3 examples/multiserver.py --map ~/map_root/
O cliente HFP (hands-free, emulador de viva-voz veicular) fornece uma CLI de comandos AT para conversar com seu HFAG (telefone/modem). Eu o chamo de "cliente HFP" apesar de ser um servidor RFCOMM porque é um "cliente" para o HFAG (telefone/modem). Você usa o emulador HF ("cliente") para enviar comandos AT ao HFAG, apesar de o "servidor" (HFAG) ser o que inicia a conexão RFCOMM.
Para executar o emulador HF:
sudo python3 examples/hfpclient.py
Talvez seja necessário iniciar o emulador HF para anunciar via SDP que você é um HF antes de parear seu telefone. Quando o emulador HF estiver em execução, seu telefone iniciará uma conexão RFCOMM de comandos AT com o script do emulador. Para agilizar esse processo, você pode clicar no computador pareado nas configurações de Bluetooth do seu telefone para acionar uma conexão/reconexão.
Assim que o HFAG (telefone/modem) iniciar uma conexão, normalmente você tem uma janela limitada (30 segundos a um minuto) para configurar a sessão HFP. Antes de poder enviar comandos AT úteis (como iniciar chamadas telefônicas), você precisa enviar uma sequência de comandos AT dentro da janela limitada, caso contrário o HFAG pode desconectar de você. A seguinte sequência inicial de comandos AT deve funcionar na maioria dos telefones:
AT+BRSF=39
AT+CIND=?
AT+CIND?
AT+CMER=3,0,0,1
AT+CHLD=?
AT+CCWA=1
AT+CLIP=1
AT+NREC=0
O servidor HFP (gateway de áudio) é bastante básico, enviando respostas pré-configuradas para comandos selecionados. O servidor está configurado para suportar comandos HFP comuns pronto para uso, mas cada veículo provavelmente exigirá alguns comandos adicionais e/ou alterações nas respostas. Respostas personalizadas podem ser configuradas por meio de um arquivo de texto com um formato de pares de comando e resposta em cada linha, comando e resposta separados por uma tabulação. Exemplos de arquivos de configuração podem ser encontrados na pasta examples/bbeast.
Diferentemente dos outros servidores, a implementação HFP AG do nOBEX não aceita conexões RFCOMM de fato. O padrão HFP é ambíguo sobre como as conexões devem ser estabelecidas e, portanto, tanto o HF quanto o AG podem aceitar e iniciar conexões. Diferentes unidades de cabeça se comportam de maneira diferente quando se trata de práticas de estabelecimento de conexão. No entanto, a maioria dos dispositivos HF tende a aceitar ser conectado pelo AG se o AG não aceitar conexões em sua própria porta. Assim, o "servidor" HFP AG do nOBEX apenas pesquisa entre dispositivos pareados aqueles que suportam o serviço HF, e o nOBEX então se conecta ao dispositivo HF.
Esteja ciente de que o código HFP AG tentará se conectar a qualquer dispositivo listado em /var/lib/bluetooth/*/* que afirme suportar o papel HFP HF. Portanto, você deve excluir quaisquer pareamentos errôneos nesse diretório antes de tentar usar o servidor HFP.
Para executar um HFP AG autônomo (o arquivo de configuração é opcional):
sudo python3 examples/multiserver.py --hfp [config_file]
O servidor HFP (HFAG) também suporta operação interativa, onde você pode editar respostas automáticas em tempo de execução ou enviar respostas AT manualmente. O servidor HFP escuta na porta 7137 do localhost para comandos. Você pode se conectar a ele usando netcat, como mostrado abaixo:
nc localhost 7137
Há apenas dois comandos simples para esta interface:
send <atresp> - envia atresp como uma resposta ATursp <atcmd> <atresp> - atualiza/define a resposta automática para atcmd como atrespOs seguintes comandos de exemplo simularão uma chamada telefônica recebida:
ursp AT+CLCC +CLCC: 1,1,4,0,0,"1234567890",129
send RING
O cliente FTP (Perfil de Transferência de Arquivos) permite navegar por arquivos em um servidor OBEX FTP, como outro computador executando nOBEX ou um telefone Android executando o aplicativo Bluetooth File Transfer. Há um programa de exemplo de cliente FTP localizado no diretório examples.
python3 examples/ftpclient.py SERVER_MAC_ADDRESS [save_directory]
Executar o cliente FTP de exemplo com apenas um endereço MAC Bluetooth como argumento imprimirá uma listagem recursiva de diretórios de todos os arquivos acessíveis via OBEX FTP no servidor. Se o argumento opcional save_directory for fornecido, o script baixará todos os arquivos acessíveis no servidor e os salvará no diretório de salvamento especificado no seu computador.
O servidor FTP permite que um cliente navegue por arquivos no seu computador (servidor) dentro de uma pasta especificada.
sudo python3 examples/multiserver.py --ftp PATH_TO_FTP_FOLDER
O cliente OPP (Perfil de Envio de Objetos) permite enviar um arquivo do seu computador para um servidor OBEX OPP.
python3 examples/pushclient.py SERVER_MAC_ADDRESS FILE_TO_PUSH
O servidor OPP permite que um cliente envie arquivos para o seu computador (servidor) dentro de uma pasta especificada.
sudo python3 examples/multiserver.py --opp PATH_TO_OPP_FOLDER
O script multiserver.py permite executar qualquer combinação de servidores HFP, MAP, PBAP, FTP e OPP simultaneamente. Basta combinar os argumentos dos exemplos mostrados acima. Para executar HFP, MAP e PBAP simultaneamente:
python3 examples/multiserver.py --map ~/map_root/ --pbap ~/pbap_root/ --hfp [config_file]
A combinação de HFP e PBAP foi testada com sucesso em um Ford Focus 2012.
O propósito principal do nOBEX é realizar testes negativos e fuzzing de clientes PBAP e MAP em unidades de cabeça automotivas. O suporte a HFP e o suporte a clientes PBAP/MAP destinam-se a facilitar esse objetivo. Fuzzing manual pode ser realizado executando um servidor com listagens XML, vcards e BMSGs modificados à mão. OBEX é um alvo rico para fuzzing, com muitas estruturas TLV aninhadas que podem abranger mensagens de múltiplas partes. PBAP e MAP aumentam muito a superfície de ataque com parsers de vcard, BMSG e XML.
O nOBEX não possui suporte integrado para fuzzing automatizado, mas, como é escrito em Python, é fácil de estender. Capacidades de fuzzing mais poderosas podem ser construídas combinando-o com um mecanismo de mutação e instrumentando o dispositivo alvo.
Além do fuzzing de MAP e PBAP em unidades de cabeça automotivas, o nOBEX também pode ser usado para testes positivos normais de PBAP, MAP e outros perfis OBEX (como FTP), tanto para papéis de cliente quanto de servidor. Os servidores PBAP e MAP foram testados com o aplicativo OBEX Commander para Android, no qual muitas falhas puderam ser acionadas por comunicação OBEX defeituosa e dados específicos de perfil malformados. Além disso, o suporte a HFP pode ser usado para fazer fuzzing manual de comandos AT.