O que me deu a idea de facer unha ferramenta de peto para analizar redes WiFi foi .
Grazas a eles pola idea. Simplemente non tiña nada que facer.
Todo o traballo realizouse como parte dunha afección coa finalidade de divertirme e ampliar os meus coñecementos no campo das tecnoloxías de rede. Lentamente, 1..4 horas semanais, dende principios deste ano.
Non planeei ningún uso práctico. Eses. Esta NON é unha ferramenta de hackers.
Polo momento, todas as funcións planificadas están funcionando. Todas as fontes, completamente listas para a súa montaxe, . Tamén hai instrucións de montaxe, etc. Nesta nota, non vou duplicar a información publicada en github. Só vos direi o que considero necesario describir por separado.
A miña opinión sobre a "ferramenta universal" e o motivo da elección do ESP32
Non pretendo ser a verdade. Cada un ten o seu. Tentarei xustificar a miña elección de hardware.
o caso de uso dunha combinación de Linux (inicialmente Raspberry Pi) + "periféricos" en forma de controlador (STM32) + CC1110 (núcleo 8051) e o plan de meter todo o posible alí (125 kHz, NFC, 433 mHz, USB, iButton, bluetooth, ?) non me parecían axeitados. Non obstante, Parece que seguirá sendo privado e pechado (flipper-zero github "Esta organización non ten repositorios públicos") e foi cara a un hardware non moi común.
Quizais me equivoque e no futuro os autores farán que as fontes do software sexan publicamente dispoñibles. Pero se non, entón non compraría tal peza de hardware sen o código fonte.
Os meus requisitos para a "ferramenta"
A caixa debe ser pequena (canto máis pequena mellor).
Polo tanto:
- Non se necesita batería incorporada. Cunha corrente > 100 mA cando se traballa con wifi, a batería incorporada será grande ou non durará moito. Polo tanto, deixe que a "caixa" estea alimentada por un banco de enerxía estándar. De todos os xeitos, sempre teño un banco de enerxía no peto/coche.
- Mantén unha "caixa" de Linux con ferramentas dentro, escrito ao longo de moitos anos en todas as linguas Cunha pantalla pequena e un conxunto escaso de botóns de control, non ten sentido. Os resultados pódense ver/procesar nun portátil normal cun teclado e pantalla completos.
- Os compoñentes deben ser facilmente accesibles e amplamente coñecidos (SDK dispoñible, moitos exemplos e documentación).
Como resultado, para min, a elección era obvia: ESP32.
Para todas as tarefas indicadas no artigo que me impulsou a tomar medidas, as capacidades do ESP32 son bastante suficientes. Aínda que o que máis quero facer é:
- Xoga con Bluetooth.
- Xoga coa gama de 433 mHz co hardware máis sinxelo (só a modulación de amplitude, que é suficiente para as necesidades prácticas).
Voa na pomada en ESP32
- O SDK ESP32 (IDF) é algo torpe.
- Algunhas das funcións (pila de WiFi, por exemplo) ven sen código fonte en forma de bibliotecas estáticas ensambladas.
- A banda de 5 GHz non é compatible e hai algunhas limitacións e torpeza ao traballar con WiFi.
Pero o prezo/tamaño compensa completamente estas deficiencias.
Funcionalidade principal do software
Describirei brevemente a funcionalidade e a miña opinión sobre...
Xestionar a configuración e cargar ficheiros desde SD
Todo o control externo realízase a través dunha páxina web sinxela, lanzada nun elemento de menú separado. O ESP32 comeza no modo WiFi AP e mostra unha páxina nun enderezo IP fixo.
Aínda que os núcleos ESP32 son bastante rápidos, como demostraron os experimentos, o funcionamento simultáneo do servizo web incorporado e, por exemplo, o modo enrutador non son moi compatibles. Polo tanto, non hai control dinámico e a páxina non está dispoñible nos demais modos.
Ademais, o control dinámico non é necesario para fins de investigación.
Modo de traballo con paquetes Beacon
Os modos son banais e pouco interesantes. Feito "porque é posible". Para comprobar.
Hai exemplos nos exemplos oficiais de Espressif.
Modo de exploración da lista de AP.
En realidade, calquera teléfono intelixente pode facelo.
Ben, neste modo gardarase a lista de AP.
Spammer de balizas.
O ESP32 comeza como un AP cun SSID oculto e un MAC aleatorio e comeza a enviar [marco de baliza] segundo unha lista pre-creada de SSID (creada manualmente ou obtida anteriormente escaneando a lista de AP)
Modo de detección de paquetes WiFi
Os desenvolvedores de Espressif engadiron a posibilidade de que o software de aplicación reciba todos os paquetes WiFi "voando no aire" a través da función de devolución de chamada. En realidade, non todos, xa que só pode configurar o modo para unha canle fixa.
Impóñense restricións de tempo moi estritas ao procesar unha función de devolución de chamada. Se isto non causa problemas para o modo de recollida de estatísticas simple, entón para o modo de gravación de ficheiros PCAP na tarxeta SD tiven que retocar, organizando a gravación a través dunha cola en memoria e semáforos. Tendo en conta a peculiaridade de que o proceso que chama a devolución de chamada execútase nun núcleo e o proceso que escribe en SD noutro.
Durante o "aire ruidoso", pérdense algúns paquetes (non hai espazo na cola e descártanse), pero cun "aire" típico dun apartamento pola noite (5..7 AP dentro da visibilidade), gravando en PCAP complétase sen perda de paquetes.
Ademais, para o seguimento e gravación de PCAP, hai un modo de filtrado baseado na lista MAC nas cabeceiras dos paquetes.
Por exemplo, pode rastrexar a aparición dunha persoa nun club/cafetería antes de que entre ou apareza á vista. Poucas persoas desactivan as conexións WiFi e automáticas aos AP coñecidos. (Agora estou desactivando..)
Ver o tráfico rexistrado en Wireshark é educativo e interesante para comprender os mapas: todo funciona.
Modo para traballar con paquetes de deauth
Por defecto, o envío destes paquetes está prohibido na biblioteca libnet80211.a, que vén sen fontes. Pero é fácil de arranxar axustando un par de bits. Ao principio dubidei de se pagaba a pena publicar parche. Pero despois de camiñar por diferentes lugares co modo de dixitalización de marcos de desautenticación activado, pensei: "que carallo". Ademais, en esp8266 a entrega destes paquetes non está pechada e hai conxuntos en github para esp8266.
En moitos lugares (non direi onde) úsase a supresión de AP non desexados a través deste método. E estes non son "matones"...
E tamén me sorprendeu que a miña distribución de Internet dende o meu teléfono non funcionase nalgúns lugares...
O modo para rastrexar o número e RSSI destes paquetes é moi útil para entender "onde non lles gusta aos AP da esquerda".
modo enrutador
Esta función é probablemente a máis interesante de todas para explorar.
ESP32 admite o funcionamento simultáneo no modo STA + SoftAP. Polo tanto, pode implementar nel un enrutador NAT clásico.
Para soportar a pila de rede, Espressif usa un fork (practicamente sen cambios) da biblioteca lwip.
Pero, por defecto, na compilación estándar, a biblioteca esp-lwip non proporciona o reenvío entre as interfaces netif 'ap' (SoftAP) e 'st' (STA).
Por suposto, podes facelo sen NAT, pero hai un problema ao conectar simultáneamente dous ou máis STA á interface 'ap' e sincronizar os enderezos IP desde a interface de rede 'st' a 'ap'. Así que as dificultades non pagan a pena e é máis fácil a través de NAT.
Ademais, hai un fork esp-lwip de martin-ger, que engade unha implementación sinxela de NAT para IP4.
Aínda que as miñas mans tiñan moitas ganas de refacelo de xeito puramente estético (na miña opinión, era máis fácil sen garfo do proxecto, pero a través de LWIPGancho funcións definidas durante a montaxe), pero prevaleceu a preguiza e a opción de martin-ger úsase tal e como está.
No modo de enrutador, móstrase o tráfico IP4 entrante e saínte.
En particular, extráese o seguinte para mostrar na pantalla e recoller estatísticas nun ficheiro:
- Nome do dispositivo que se conectou a SoftAP ESP32 (paquetes DHCP)
- URL das solicitudes de DNS (porto UDP 53) desde un dispositivo conectado a SoftAP ESP32.
Ademais, pode activar a gravación de tráfico nun ficheiro PCAP.
Este modo é moi útil, por exemplo, para comprender, por exemplo, o que o teléfono envía á rede e onde vai.
Podes pensar noutras formas de usar este modo, tendo en conta a capacidade de controlar completamente o tráfico entrante e saínte de softAP ESP32 a nivel de interface de rede: cabeceira Ehernet (destMAC[6]+srcMAC[6]+type[2]) + carga útil (tipo IP4, IP6, DCHP, etc.).
En principio, o ESP32 afronta bastante ben a función do enrutador WiFi->WiFi, pasando polo tráfico normal sen ningún atraso especial. Subxectivamente, os atrasos nun teléfono conectado a través dun enrutador nun ESP32 non son perceptibles.
Desafortunadamente, a API Espressif non ten a capacidade de establecer un filtro para MAC conectado a SoftAP EPS32. En cambio, proponse dicir "adeus" (esp_wifi_deauth_sta) ás STA xa conectadas que "non son desexadas".
O filtrado por MAC dos STA conectados tivo que facerse mediante a chamada esp_wifi_deauth_sta()
En conclusión
Aínda que non se me ocorreu nada novo no marco do traballo con ESP32, quizais o resultado (código fonte) sexa interesante para alguén.
Gustaríame sinalar que o código foi escrito unicamente con fins educativos. Para "piratear", etc., non foi deliberadamente feito moi conveniente.
Non fixen unha placa de circuíto impreso porque tardou 1.5-2 horas en soldar as bufandas rematadas con fío.
E se o fas, necesitas montalo non a partir de placas preparadas, senón de compoñentes individuais. Entón as dimensións serán aínda máis pequenas.
Fonte: www.habr.com