A ideia de criar uma ferramenta portátil para análise de redes WiFi me foi inspirada por .
Obrigado a eles pela ideia. Eu realmente não tinha nada para fazer.
Todo o trabalho foi realizado como parte de um hobby, visando obter prazer e expandir meus conhecimentos em tecnologia de redes. Sem pressa, de 1 a 4 horas por semana, desde o início deste ano.
Não planejava um uso prático. Ou seja, esta NÃO é uma ferramenta para hackers.
Atualmente, toda a funcionalidade projetada está em funcionamento. Todo o código-fonte, completamente pronto para compilação, . Lá também está a instrução de montagem e outros detalhes. Neste artigo, não vou duplicar as informações publicadas no github. Vou falar apenas sobre o que considero necessário descrever separadamente.
Minha opinião sobre a "ferramenta universal" e a razão da escolha do ESP32
Não estou reivindicando a verdade. Cada um tem a sua. Tentarei justificar minha escolha de "hardware".
é uma combinação de Linux (originalmente Raspberry Pi) + "periféricos" em forma de controlador (STM32) + CC1110 (núcleo 8051) e a intenção de incluir tudo que for possível (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) parecia inadequada para mim. No entanto, parece que permanecerá privado e fechado (flipper-zero github "Esta organização não tem repositórios públicos.") e fui em direção a um hardware não muito comum.
Pode ser que eu esteja errado, e no futuro os autores publiquem o código-fonte do software de forma aberta. Mas se não, eu não compraria esse hardware sem os códigos-fonte.
Meus requisitos para a "ferramenta"
A "caixinha" deve ser pequena (quanto menor, melhor).
Portanto:
- Uma bateria embutida não é necessária. Com uma corrente > 100 mA ao trabalhar com Wifi, a bateria embutida será grande ou durará pouco. Portanto, vamos deixar a "caixinha" alimentada por um power bank padrão. Afinal, sempre tenho um power bank no bolso/carro.
- A ideia é manter o Linux com ferramentas dentro da "caixinha", escritas ao longo de muitos anos em todas as linguagens não faz sentido com uma tela pequena e um conjunto escasso de botões de controle. Os resultados podem ser vistos/processados em um notebook normal com um teclado e tela adequados.
- Os componentes devem ser facilmente acessíveis e amplamente conhecidos (SDK disponível, muitos exemplos e documentação).
Como resultado, para mim, a escolha foi óbvia — ESP32.
Para todas as tarefas mencionadas no artigo que me levaram a agir, as capacidades do ESP32 são mais do que suficientes. Embora o máximo que eu queira fazer a seguir seja:
- Brincar com Bluetooth.
- Brincar com a faixa de 433mHz com hardware simples (apenas modulação de amplitude, que é suficiente para necessidades práticas).
Um ponto negativo no ESP32
- O SDK (IDF) do ESP32 é um pouco desajeitado.
- Parte da funcionalidade (pilha WiFi, por exemplo) vem sem o código-fonte em forma de bibliotecas estáticas compiladas.
- A faixa de 5gHz não é suportada e há algumas limitações e falhas no funcionamento do WiFi.
Mas o preço/tamanho compensa essas deficiências.
Funcionalidade principal do software
Vou descrever brevemente a funcionalidade e minha opinião sobre…
Gerenciamento de configurações e upload de arquivos com SD
Todo o controle externo é feito através de uma página Web simples, lançada em um menu separado. O ESP32 inicia em modo WiFi AP e fornece uma página em um endereço IP fixo.
Embora os núcleos do ESP32 sejam bastante rápidos, como mostram os experimentos, o funcionamento simultâneo do serviço Web integrado e, por exemplo, do modo roteador não se combina muito bem. Portanto, não há controle dinâmico e em todos os outros modos a página não está disponível.
Ainda mais porque para fins de pesquisa o controle dinâmico não é necessário.
Modo de operação com pacotes Beacon
Os modos são banais e não muito interessantes. Foram feitos "porque era possível". Apenas para cumprir tabela.
Há exemplos nos exemplos oficiais da Espressif.
Modo de escaneamento de listas AP.
Na verdade, qualquer smartphone pode fazer isso.
E nesse modo será salvo a lista de AP.
Beacon spammer.
O ESP32 inicia como AP com SSID oculto e MAC aleatório e começa a enviar [beacon frame] de uma lista de SSID previamente criada (criada manualmente ou obtida anteriormente ao escanear a lista de AP).
Modo de sniffing de pacotes WiFi
Os desenvolvedores da Espressif adicionaram a capacidade de o software aplicativo obter, através de uma função callback, todos os pacotes WiFi "que passam pelo ar". Na verdade, não todos, pois você pode definir o modo apenas para um canal fixo.
A função callback é sujeita a restrições de tempo muito rigorosas. Enquanto isso não representa um problema no modo de coleta simples de estatísticas, no modo de gravação de arquivo PCAP no cartão SD, foi necessário organizar a gravação por meio de uma fila na memória e semáforos. Considerando que o processo que chama o callback roda em um núcleo, enquanto o processo que grava no SD está em outro.
Em um 'ar ruidoso', alguns pacotes são perdidos (porque não há espaço na fila e são descartados), mas em um 'ar típico' em apartamentos à noite (5 a 7 AP ao alcance), a gravação em PCAP é realizada sem perdas de pacotes.
Além disso, para monitoramento e gravação de PCAP, existe um modo de filtragem por lista de MAC nos cabeçalhos dos pacotes.
Por exemplo, é possível rastrear a entrada de uma pessoa em um clube/cafeteria antes mesmo de ela entrar ou aparecer no campo de visão. Poucas pessoas desativam o WiFi e a conexão automática com APs conhecidos. (Agora eu desligo...)
Visualizar o tráfego gravado no Wireshark é educativo e interessante para entender como tudo isso funciona.
Modo de operação com pacotes de deauth
Por padrão, o envio desses pacotes é proibido na biblioteca libnet80211.a, que vem sem fontes. Mas não é complicado contornar isso, ajustando alguns bytes. No começo eu hesitava em divulgar o patch. Mas, ao visitar vários lugares com o modo de escaneamento de fontes de envio [deauthentication frame] ativado, pensei: 'por que não?'. Além disso, no esp8266 o envio desses pacotes não é bloqueado e há compilações no GitHub para esp8266.
Em muitos lugares (não vou dizer onde) a supressão de APs indesejados é feita por esse método. E não são 'vândalos'...
Eu também me perguntei por que a distribuição de internet do meu telefone às vezes não funcionava...
O modo de rastreamento da quantidade e RSSI desses pacotes é muito útil para entender 'onde não gostam de APs indesejados'.
Modo router
Esta função é, provavelmente, a mais interessante para pesquisa.
O ESP32 suporta operação simultânea em modo STA + SoftAP. Portanto, é possível implementar um roteador NAT clássico.
Para suportar a pilha de rede, a Espressif utiliza um fork (praticamente sem alterações) da biblioteca lwip.
No entanto, por padrão, na versão padrão, na biblioteca esp-lwip não há previsão de encaminhamento entre as interfaces netif 'ap' (SoftAP) e 'st' (STA).
Claro que é possível fazer sem NAT, mas surge o problema de conectar simultaneamente dois ou mais STA à interface 'ap' e sincronizar os endereços IP da interface de rede 'st' para 'ap'. Portanto, as dificuldades não valem a pena e é mais simples usar NAT.
Além disso, existe um fork do esp-lwip do martin-ger que inclui uma implementação simples de NAT para IP4.
Embora eu quisesse reformulá-lo apenas esteticamente (na minha opinião, seria mais fácil sem o fork do projeto, mas através do LWIP)GANCHO funções definidas durante a compilação), mas a preguiça venceu e a versão do martin-ger é usada como está.
No modo router, o tráfego IP4 de entrada e saída é monitorado.
Em particular, são extraídos para exibição na tela e coleta de estatísticas em arquivo:
- O nome do dispositivo que se conectou ao SoftAP ESP32 (pacotes DHCP)
- URL das solicitações DNS (porta UDP 53) do dispositivo conectado ao SoftAP ESP32.
Além disso, é possível ativar o registro do tráfego em um arquivo PCAP.
Esse modo é muito útil, por exemplo, para entender o que seu telefone está enviando para a rede e para onde está indo.
É possível pensar em outras maneiras de usar esse modo, considerando a capacidade de gerenciar programaticamente o tráfego de entrada e saída do SoftAP ESP32 no nível da interface de rede: cabeçalho Ethernet (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DHCP, entre outros tipos).
Em princípio, o ESP32 consegue lidar bem com a função de roteador WiFi->WiFi, passando o tráfego normal sem grandes atrasos. Subjetivamente, os atrasos no telefone conectado via router ao ESP32 são imperceptíveis.
Infelizmente, na API da Espressif não há possibilidade de estabelecer um filtro por MAC para dispositivos conectados ao SoftAP ESP32. Em vez disso, é sugerido dizer 'adeus' (esp_wifi_deauth_sta) para os STA já conectados que são 'indesejados'.
A filtragem por MAC dos STA conectados teve que ser feita através da chamada esp_wifi_deauth_sta()
Para concluir
Embora eu não tenha inventado nada novo no contexto do trabalho com o ESP32, pode ser que alguém ache o resultado (códigos fonte) interessante.
Gostaria de ressaltar que escrevi o código exclusivamente para fins educativos. Para "hackear" etc., ele foi propositalmente feito de maneira não muito conveniente.
Não fiz uma placa impressa, pois o tempo gasto para soldar as placas prontas com fio foi de cerca de 1.5-2 horas.
E se fosse fazer, seria necessário não montar a partir de placas prontas, mas a partir de componentes separados. Assim, as dimensões seriam ainda menores.
Fonte: habr.com
