La idea de crear una herramienta portátil para analizar redes WiFi me fue sugerida por .
Gracias a ellos por la idea. Justo no tenía nada que hacer.
Todo el trabajo se llevó a cabo como parte de un hobby con el objetivo de disfrutar y ampliar mis conocimientos en tecnologías de red. Sin prisa, de 1 a 4 horas a la semana, desde principios de este año.
No tenía previsto un uso práctico. O sea, NO es una herramienta para hackers.
Actualmente, toda la funcionalidad planeada está operativa. Todos los códigos fuente, completamente listos para compilar, . Allí también hay instrucciones para la compilación, etc. En esta nota no duplicaré la información publicada en github. Solo contaré lo que creo que es necesario describir por separado.
Mi opinión sobre la 'herramienta universal' y la razón de elegir el ESP32
No pretendo tener la verdad. Cada uno tiene la suya. Intentaré justificar mi elección de 'hardware'.
usando una combinación de Linux (originalmente Raspberry Pi) + 'periferia' en forma de controlador (STM32) + CC1110 (núcleo 8051) y el plan de incorporar todo lo posible (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) me pareció inadecuado para mí. Sin embargo, parece que quedará privado y cerrado (flipper-zero github 'Esta organización no tiene repositorios públicos.') y me incliné hacia hardware no tan común.
Es posible que esté equivocado, y que en el futuro los autores publiquen el código fuente del software en acceso abierto. Pero si no, no compraría tal hardware sin el código fuente.
Mis requisitos para la 'herramienta'
La caja debe ser pequeña (cuanto más pequeña, mejor).
Por lo tanto:
- No necesito una batería integrada. Con una corriente > 100 mA al trabajar con Wifi, la batería integrada será grande o no durará mucho. Así que que la 'caja' funcione con un power bank estándar. De todos modos, siempre tengo un power bank en el bolsillo/coche.
- No tiene sentido tener Linux con herramientas dentro de la 'caja', escritas durante muchos años en todos los idiomas con una pequeña pantalla y un escaso conjunto de botones de control. Los resultados se pueden ver/procesar en un buen portátil con teclado y pantalla completos.
- Los componentes deben ser fácilmente accesibles y bien conocidos (SDK disponible, muchos ejemplos y documentación).
Como resultado, para mí, la elección fue obvia: ESP32.
Para todas las tareas mencionadas en el artículo que me llevó a actuar, las capacidades del ESP32 son más que suficientes. Aunque lo máximo que quiero hacer es:
- Jugar con Bluetooth.
- Jugar con la banda de 433mHz con hardware sencillo (solo modulación de amplitud, lo que es suficiente para necesidades prácticas).
Una desventaja del ESP32.
- El SDK (IDF) del ESP32 es algo torpe.
- Parte de la funcionalidad (como el stack WiFi, por ejemplo) viene sin fuentes en forma de bibliotecas estáticas compiladas.
- No se soporta la banda de 5gHz y hay algunas limitaciones y torpezas en el funcionamiento del WiFi.
Pero el precio/tamaño compensan estas desventajas.
Funcionalidad principal del software.
Describiré brevemente la funcionalidad y mi opinión sobre…
Gestión de configuraciones y descarga de archivos desde la SD.
Toda la gestión externa se realiza a través de una sencilla página web, que se inicia en un punto de menú separado. ESP32 se inicia en modo WiFi AP y proporciona la página en una dirección IP fija.
Aunque los núcleos del ESP32 son bastante rápidos, como mostraron los experimentos, el funcionamiento simultáneo del servicio web integrado y, por ejemplo, el modo router no se combinan bien. Por lo tanto, no hay gestión dinámica y en todos los demás modos la página no está disponible.
Sobre todo porque para fines investigativos no se necesita gestión dinámica.
Modo de trabajo con paquetes Beacon.
Los modos son banales y no muy interesantes. Se implementan 'porque se puede'. Solo por cumplir.
Hay ejemplos en los ejemplos oficiales de Espressif.
Modo de escaneo de listas AP.
En realidad, esto lo puede hacer cualquier smartphone.
Y en este modo se guarda la lista de AP.
Beacon spammer.
El ESP32 arranca como AP con SSID oculto y MAC aleatorio y comienza a enviar [beacon frame] de acuerdo con una lista de SSID previamente creada (ya sea manualmente o obtenida anteriormente al escanear la lista de AP).
Modo de sniffing de paquetes WiFi.
Los desarrolladores de Espressif agregaron la capacidad a la aplicación para recibir a través de una función de callback todos los paquetes WiFi que 'pasan por el aire'. En realidad, no todos, ya que se puede establecer el modo solo para un canal fijo.
La llamada de la función de callback está sujeta a restricciones temporales muy estrictas. Mientras que para el modo de recopilación simple de estadísticas esto no representa un problema, para el modo de grabación del archivo PCAP en la tarjeta SD fue necesario hacer algunos ajustes, organizando la grabación a través de una cola en memoria y semáforos. Teniendo en cuenta la particularidad de que el proceso que llama al callback se ejecuta en un núcleo, mientras que el proceso que realiza la grabación en la SD en otro.
Con un "aire ruidoso", se pierden algunos paquetes (no hay espacio en la cola y son descartados), pero en un "aire" típico de un apartamento por la noche (5 a 7 AP visibles) la grabación en PCAP se completa sin pérdidas de paquetes.
Además, para el monitoreo y grabación de PCAP, existe un modo de filtrado por lista de MAC en los encabezados de los paquetes.
Por ejemplo, se puede rastrear la aparición de una persona en un club/cafetería antes de que haya entrado o aparecido en el campo de visión. Pocos desactivan el WiFi y la conexión automática a AP conocidos. (Yo ahora desconecto...).
Ver el tráfico grabado en Wireshark es educativo e interesante para entender cómo funcionan todas estas cosas.
Modo de trabajo con paquetes de deautenticación
Por defecto, el envío de estos paquetes está prohibido en la biblioteca libnet80211.a, que se entrega sin el código fuente. Pero no es difícil alterarlo, ajustando un par de bytes. Al principio dudé en si debía publicar el parche. Pero después de visitar varios lugares con el modo de escaneo de origen de envío [deauthentication frame], pensé: "¿por qué no?" Especialmente porque en esp8266 el envío de estos paquetes no está restringido y hay compilaciones en github para esp8266.
En muchos lugares (no diré dónde) se utiliza la supresión de AP no deseados a través de este método. Y no son 'vándalos'...
Y yo todavía me preguntaba por qué la distribución de internet desde mi teléfono en lugares no funcionaba...
El modo de seguimiento de la cantidad y RSSI de tales paquetes es muy útil para entender "dónde no se toleran los AP ilegítimos".
Modo router
Esta función es, probablemente, la más interesante de todas para investigar.
ESP32 admite el funcionamiento simultáneo en modo STA + SoftAP. Por lo tanto, se puede implementar un router NAT clásico.
Para soportar la pila de red, Espressif utiliza un fork (prácticamente sin cambios) de la biblioteca lwip.
Sin embargo, por defecto, en la compilación estándar, en la biblioteca esp-lwip no está previsto el paso de datos entre las interfaces netif 'ap' (SoftAP) y 'st' (STA).
Se puede hacer sin NAT, pero surge el problema de conectar simultáneamente dos o más STA a la interfaz 'ap' y la sincronización de las direcciones IP desde la interfaz de red 'st' a 'ap'. Así que las complicaciones no valen la pena y es más fácil hacerlo a través de NAT.
Además, existe un fork de esp-lwip de martin-ger en el que se añadió una implementación simple de NAT para IP4.
Aunque tenía la intención de modificarlo estéticamente (en mi opinión, hubiera sido más fácil sin el fork del proyecto, sino a través de LWIP), la pereza ganó y se utiliza la opción de martin-ger tal como está.GANCHO funciones, definidas al compilar), pero la pereza ganó y se utiliza la variante de martin-ger tal cual.
En modo router, se visualiza el tráfico IP4 entrante y saliente.
En particular, se extrae para mostrar en la pantalla y recopilar estadísticas en un archivo:
- El nombre del dispositivo que se conectó al SoftAP ESP32 (paquetes DHCP)
- URL de las solicitudes DNS (puerto UDP 53) del dispositivo conectado al SoftAP ESP32.
Además, se puede habilitar el registro del tráfico en un archivo PCAP.
Este modo es muy útil, por ejemplo, para entender qué está enviando su teléfono a la red y a dónde va.
Se pueden idear otros métodos para utilizar este modo considerando la posibilidad de gestionar completamente el tráfico entrante y saliente del SoftAP ESP32 a nivel de la interfaz de red: encabezado Ethernet (destMAC[6]+srcMAC[6]+type[2]) + carga útil (IP4, IP6, DHCP, etc.).
En principio, el ESP32 maneja bastante bien la función de router WiFi->WiFi, permitiendo pasar tráfico normal sin retrasos significativos. Subjetivamente, los retrasos en el teléfono conectado a través del router en ESP32 no son perceptibles.
Desafortunadamente, en la API de Espressif no existe la opción de establecer un filtro por MAC para los que se conectan al SoftAP EPS32. En lugar de eso, se propone decir 'adiós' (esp_wifi_deauth_sta) a los STA que ya están conectados y que son 'no deseables'.
La filtración por MAC para los STA que se conectan tuvo que hacerse a través de la llamada esp_wifi_deauth_sta()
En conclusión
Aunque no he ideado nada nuevo en el trabajo con el ESP32, quizás a alguien le interese el resultado (código fuente).
Quisiera señalar que escribí el código únicamente con fines educativos. Para 'hackear' y similares, se hizo intencionalmente no muy conveniente.
No hice la placa de circuito impreso, ya que me tomó entre 1.5 y 2 horas juntar las placas listas con un cable.
Y si se va a hacer, no hay que ensamblar a partir de placas listas, sino de componentes individuales. Entonces las dimensiones serán aún más pequeñas.
Fuente: habr.com
