Hoy voy a estar todo el día en OpenExpo Europe 2024 con una agenda intensa que os he dejado ayer publicada, pero antes de salir para allá, quería dejar publicado mi post diario de El lado del mal, así que me he levantado y he pensado en compartiros hoy una curiosidad de iPhone y las "Contraseñas Compartidas de redes WiFi", que puede que lo desconozcas. Es solo una curiosidad, pero me gusta mucho cómo está implementado.
Figura 1: El "misterio" de la Contraseña WiFi compartida con tu iPhone
(que no es tan misterio)
Si eres usuario de iPhone seguro que has visto alguna vez la opción de compartir una contraseña de una red WiFi. El funcionamiento es muy sencillo y cómodo, se trata de que si te vas a conectar a una red WiFi, y alguno de tus contactos está ya conectada a ella, ese contacto recibe una alerta que le permite compartir la contraseña de la WiFi contigo, con un solo clic, sin necesidad de escribir la clave ni decírtela.
Cuando lo vi por primera vez, lo que se me pasan por la cabeza son muchos posibles escenarios de seguridad, que ya sabéis que el tema de Hacking de dispositivos iOS es algo siempre estamos investigando.
El primero es de privacidad, porque le estás diciendo a todos tus contactos de esa red que te vas a conectar, y se anuncia a tus contactos que estás haciendo una acción concreta. Por supuesto, no parece muy relevante, porque solo se hace la primera vez que te conectas, y a los contactos tuyos conectados a esa red, así que es poco probable que eso signifique un problema para el usuario. Y a cambio tenemos la opción tan cómoda de compartir la WiFi. Así que casi que desechamos esto como riesgo.
Figura 3: Servicio de Compartir Contraseñas de Redes WiFi
Otro podría ser un problema de acceso no autorizado, y en una red WiFi de mucha gente conectada, puede ser como jugar a la lotería a ver si te toca, por lo que llegas a una empresa que tiene una red WiFi, y te intentas conectar, y esperas a ver qué pasa. Si alguno de tus contactos está por ahí conectado, y te comparte la WiFi, pues premio, tienes conexión. De nuevo, él sabrá que estás por ahí, y la probabilidad de que sea un riesgo es muy baja.
Además, en una empresa esto no debería ser un problema porque la seguridad de las redes WiFi no deben ser basadas en PSK, que son bien conocidas las técnicas de Hacking de Redes WiFi para estas infraestructuras, sino en otros protocolos de autenticación. Así que este riesgo lo desechamos también.
El último de los escenarios es el de que estás dando tu contraseña, y si la das por error, esa persona podrá compartirla libremente por ahí o conocer cómo configuras tú tus passwords. Este es real, aunque también de poco impacto, pero aún así, Apple ha metido una medida de protección, y es que cuando recibes la contraseña de una red WiFi por medio del servicio de "Compartir Claves WiFi", en el interfaz de usuario no te permite acceder a esta contraseña fácilmente.
Figura 4: Cuando has configurado tú la clave
en iOS siempre puedes consultar la contraseña
Por supuesto, la clave está almacenada en el dispositivo, y siempre existirá un medio de acceder a ella, pero esto será con más dificultad que con ir a ver la información de la red WiFi y consultar la password. Así que, con esta opción se ha reducido la superficie de exposición de que tu clave esté en manos de cualquiera, además de dar a los usuarios mayor sensación de privacidad - aunque como he dicho, la clave está ahí y se puede sacar -.
Figura 5: Cuando la clave te la han compartido, no la puedes ver.
¿Cómo? No es tan complicado, así que si he logrado picar tu curiosidad con esto, te dejo el problema para que lo intentes resolver tú. ¿Cómo puedes sacar la contraseña de una WiFi en iPhone cuya clave ha sido compartida por el servicio de Compartir Claves WiFi? Os leo...
El deber de prácticamente todo fabricante es acabar sellando sus creaciones con un injerto que estipula/marca el último día de uso o funcionamiento. Al igual que se le exige y obliga a un producto comprado en un supermercado establecer una fecha de caducidad, los dispositivos electrónicos tienen también su cuenta regresiva final -“final countdown”-.
Puede que acabe llegando algún día la hora de la temida obsolescencia programada, que determina cuando es el mejor momento para emprender ruta hacia el último destino -la basura- antes de despedirse de su dueño/a, dejando pocas opciones cara al cliente;
Adquirir uno de igual o similares características.
Vivir prescindiendo del mismo (vamos, como el hecho de dejar de fumar, evitando así la compra de más cigarrillos y oye ¡ahorrando dinero!).
Pero... ¿y sí todavía no llega el día de despedirse? Se dice que la vida son dos días, pues ¿a que esperas a vivirla intensamente? Siempre y cuando se disfrute con cabeza, por supuesto ;).
Gozando de un momento de paz en el sofá de casa frente a mi Smart TV consumiendo/viendo contenido bajo demanda, de pronto la televisión se apagó y… se encendió. Sí, se reinició, como cuando se actualiza un equipo o éste tiene un fallo y decide reiniciarse a modo aleatorio. Me pareció un comportamiento un tanto raruno en una TV “inteligente”. Pensé que tal vez estaba llegando su hora, bien por una programación obsoleta o por un fallo real en hardware. La TV estaba al día de firmware pero ya hacía tiempo que no se disponía de actualizaciones por caer en el olvido/abandono.
Lo primero que se me ocurrió es mirar el perímetro de su software y ver si existían algunos fallos y/o vulnerabilidades reportadas por los usuarios, y de eso va a ir este artículo, donde vamos a ver un ataque de DoS a través de un servicio de conexión WiFi en la SmartTV llamado SWL [Samsung Wireless Link]. Es decir, vamos a tener un poco de Hacking WiFi en SmartTV.
SWL [Samsung Wireless Link] - El HotSpot de la TV
Esta tele en concreto, con el servicio SWL, permite generar un punto de acceso WiFi como tal. Por defecto sale desactivado (al menos, en la última versión disponible de firmware). Monta una subred distinta a la de tu red local -10.123.12.0/24- pero da conexión a Internet a los dispositivos que allí conectes.
Figura 3: Arquitectura de Smart TV actuando de router
Según la figura anterior, el dispositivo P1 puede comunicarse con los que se encuentran en la red local del hogar -192.168.1.0/24- conducido por el NAT generado por TV, por lo que P2 verá la IP asignada a la interfaz Ethernet de la tele. Sí P2 quiere hablar con P1, debe existir una ruta en el router (para que no sea necesario configurarse en el host) o bien crear la ruta manualmente en el propio P2 (más engorroso para el usuario).
El proceso de activación de SWL se muestra en el siguiente vídeo. También se aprecia en el vídeo cómo lograr que un dispositivo Android posterior a la versión 9 (sin soporte para WPS - WiFi Protected Setup), se conecte a la red WiFi que es accesible solamente por mecanismo WPS (ya que no se conoce la contraseña WPA2, no aparece en ningún manual, ni detrás de la SmartTV, ni nada...).
Figura 4: Extract/Obtain/Get WPA/2 Password from a WPS WiFi for Android -
Por desgracia/suerte, todavía existen sistemas que apuestan por WPS, como las ediciones actuales de Windows. Es tan simple como conectarse y extraer el password con el siguiente mandato:
netsh wlan show profile SEC_LinkShare_* key=clear
Donde SEC_LinkShare_* es el nombre de la red WiFi creada por la SmartTV, el asterisco funciona para el resto del texto, que en este caso, contiene parte de la MAC Ethernet de la tele.
Probando a explotar la vulnerabilidad VDB-12842
La vulnerabilidad recae en la explotación del código PIN de 8 dígitos por tener expuesto WPS. La clave era 8 ceros, y fue descubierto por un tal John, quien dejó plasmada su hazaña en el comentario nº 229 de la web de Stefan Viehböck (uno de los principales descubridores de la deficiencia en WPS). No existe CVE asignado pero sí fue recogido por VulDB (Vulnerability Database) con código VDB-12842.
Decidí probar si a mí me sucedía lo mismo con la herramienta Reaver -primera hack tool pública para explotar WPS y… mi sorpresa fue “reavelar” un incidente distinto, y provocar un ataque DoS hacia mi SmartTV... Ésta se reinició a los 20 segundos aproximadamente. Y lo mejor de todo es que si dejas la herramienta corriendo, el DoS sigue y sigue produciéndose hasta que SWL es deshabilitado en SmartTV.
La herramienta Bully también daba el mismo resultado, pero tardaba algo menos en hacerla caer del “ring”. Así que “una de cal y otra de arena”, Samsung arregló la fuga de la password WPS pero en su contra, creó un grande problema.
Reaver vs Bully: Analizando el Comportamiento
Me asombró tanto lo que sucedía que quise ver lo que se estaba lanzando “al aire”, por lo que me hice con un par de .cap’s bajo las herramientas Reaver y Bully.
La herramienta Bully es muy similar en manejo a Reaver. Coloqué las peticiones por orden de aparición, creando así un diagrama de interacción.
Figura 5: Diagrama de interacción entre portátil y TV bajo ataque con Bully
Las peticiones fueron grabadas con airodump-ng. El ataque DoS empieza cuando se emplazan los primeros paquetes EAPOL. Se muestran en color rojo y exceptuando el primero después de -D o S START-, se emplea una serie de 6 paquetes (Deauthentication, Authentication x 2, Association Request-Respond y EAPOL - Start) que se repiten en bucle 3 veces más hasta que se reinicia la SmartTV. Esto seria como introducir papel de aluminio en una botella de salfuman y esperar a que eclosione.
La información WSC_NACK del primer paquete rojo, parece un paquete trampa para obtener la configuración del AP, según lo interpretado en Wireshark y contrastándolo con la especificación WPS. Al disponer del archivo de captura, Wireshark proporciona una funcionalidad para hacer gráficas de paquetes según el paso del tiempo. Es algo útil para ver si existen patrones similares, distancias entre ciertos protocolos, cúmulo de paquetes máximo-mínimo, etcétera.
Figura 6: Wireshark: Gráfica de I/O de ataque con Bully hasta el primer reinicio de la TV
A simple vista ya se puede ver un claro patrón. Expliquemos un poco la dinámica de este tipo de gráficas; El eje Y muestra el conteo de paquetes comprendidos en una mitad de segundo (o 500 milisegundos). El eje X es el tiempo expresado en segundos. Acerca de los colores, las líneas y los puntos:
Línea negra: Son todos los paquetes aparecidos en el ataque.
Línea verde: Los beacon frames que provienen de TV.
Puntos azules: Es un pack, un conjunto de paquetes de deauthentication, authentication y association (request & response).
Puntos granates: Paquetes EAPOL (incluyendo los de EAP).
Dicho esto, se observa que en el arranque, paquetes granates y azules cogen bastante energía, pero sobretodo granates porque luego podemos ver como se estabilizan a nivel de cantidad de paquetes por cada 1/2 fracción de segundo. Hay una tregua hasta el segundo 10. Este paquete granate es visto en la figura del diagrama de interacción, EAP - Response, Expanded Type, WPS, WSC_NACK. Luego puede verse cómo los granates van de la mano de los azules. Start + deauthentication,… En las dos primeras series, la distancia es mas corta que la segunda contrastada con la tercera serie (1 segundo de más aprox.). A los 15 segundos se produce el reinicio.
En la segunda parte del vídeo, el ataque es reflejado para la herramienta Bully. El atacante se aprovecha de que se dejara en activo el debilitado SWL -HotSpot de la SmartTV, y lo tumba en más de una ocasión…
Me suele ir muy bien insertar un cronómetro para tomar mis mediciones y sincronizar todos los clips de vídeo implicados en el ataque. Sin un editor de vídeo me es imposible poder ver el comportamiento de cada objeto en cada instante. No tiene mayor misterio, utilizo trucos como el de dar “una palmada al aire” para sincronizarlos por sonido o bien, grabando sobre la pantalla de otro elemento para casar la inserción de una letra (p. ej.).
¿Que sucede ahora con Reaver? Por las pruebas realizadas, podemos decir que no parece estar tan pulido a nivel de código, hay un desgaste mayor de paquetes y se toma algo mas de tiempo hasta que TV es reiniciada. Sí queréis profundizar al detalle en mi investigación, podéis leer el Whitepaper que subí en Slideshare.
Bonus Track
La vulnerabilidad que descubrí no es reciente, data de finales de marzo del pasado año 2022. A mediados de abril, generé un reporte que envié cifrado a Samsung por la plataforma de programa Bugbounty. Me dieron las gracias -por nada- la televisión era del 2011 y que por lo tanto ya no la barajan. Pero es la forma de trabaja de un "Cazarecompensas"
Entonces me decidí contactar con INCIBE, las conversaciones han durado desde finales de Junio de 2022 hasta mediados de Octubre de este año 2023 (bastante tiempo, pero para estas cosas nunca debéis tener prisa). Me dijeron que la asignación del CVE es posible gracias al uso de un “tag” en el propio CVE que indique que se trata de un producto “legacy”.
También me comentaron que nunca habían asignado un CVE con dicho “tag” pero para todo hay una primera vez. Pasó el tiempo y lancé un “par de pings” (de manera muy respetuosa, como siempre :) ) y finalmente obtuve contestación final. Mejor lo dejo en una imagen, la verdad que son gente maja y se nota que hay mucha empatía detrás. Pero las cosas son así a veces en esta vida, que le vamos a hacer…
Figura 10: Mensaje final de INCIBE, indicando que el CVE con ellos no es posible
Sobre el ranking que mencionan, yo figuro en él por la vulnerabilidad sobre el dispositivo del fabricante Meross que sí fue con su cooperación. Eso no es problema, la competición nunca ha sido de mi agrado, me prima participar y aportar mi granito como cualquier otro/a, y ante todo ser persona honesta, jugar limpio y reconocer mis errores.
P.D.: El CVE se está moviendo con MITRE ¡A ver que se cuece!
Reflexiones finales
Esta mal tocar cosas que no son tuyas (incluso puede ser de mala educación). Activar funciones de una cosa que es tuya sin tener ni idea, está igual de mal porque no sabes la repercusión que puede llegar a tener. Con suerte se borrará la configuración.
Creo que no os lo he contado, pero yo dejé un portátil “frito”, sirviendo sólo de pisapapeles (pasó a un rol muy precario pero al menos, servía para algo :P ). Lo que pasó es que actualicé la BIOS por una no compatible (con un disquete de 3 ½ pulgadas, en mis inicios de la informática) y mira que me avisó de que no era la correspondida… pero quería ser valiente, y me sirvió, y tanto..., para aprender de una muy buena lección de la vida.
Como de costumbre, los vídeos que hago pretenden reflejar situaciones reales. La mamá que aparece en el segundo vídeo del artículo, seguro que tirará la SmartTV “por la ventana”, y ya no querrá saber más nada de Samsung… El pobre bebé, que estaba tan a gusto viendo sus dibujos, se irrita porque... ¡Alguien se los quita!
También se ha observado que el canal del punto de acceso de la tele, a veces usa el 1 y otras el 11. ¿Alguna herramienta válida para no enfangarse con un script? ¡Claro! ¿Para que reinventar la rueda si Bully ya lo hace? Seria tal que así;
bully -b E4:E0:C5:XX:XX:XX -c 1,11 -v 4 wlan0mon
Para acabar, la tele la uso (es de las pocas que tienen la modalidad 3D, aunque no lo use) es decir funciona y de maravilla. Creo que este tipo de dispositivos merecen una segunda vida y, si no prosperará en innovar su software (eso sí tiene más sentido) ¿que menos que subsanar vulnerabilidades de este tipo? Y la solución es simple, para protegerse, basta con desactivar el SWL, pero se ganarían su respeto y reputación como fabricante sí lo corrigen (aunque sea capando la función/botón de activación... aunque a lo mejor hay gente que aún usa esa función y entonces es peor... ¿quién sabe?). ¿Quien en su sano juicio, abandona a sus abuelos? ¿Cuando o a que edad se le considera a una persona como “obsoleta”?
La última parte de esta serie dedicada a Wild Wild WiFi tiene que ver con el último de los trabajos que hicimos en este área de estudio. Se trata de dar una vuelta de tuerca a la idea del protocolo WEP-TOTP, WPA-TOTP y WPA2-TOTP de la que os hablé en la parte 4 de esta serie. Se trata de no utilizar una Pre-Shared Key en el proceso, y sustituirla por un derivado biométrico del usuario de la red.
Figura 34: Wild Wild Wifi "Dancing with wolves": 5 WEP/WPA/WPA2-TOTP-Biometry
Este método lo depositamos en una patente en Julio de 2017, debido a que la idea tenía suficientes avances tecnológicos como para merecer la invención, y el funcionamiento es bastante sencillo una vez vistas las partes anteriores.
Figura 35: Patente registrada en Julio de 2017
El objetivo es generar una clave de una red WEP, WPA o WPA que sigan utilizando el protocolo PSK estandarizado, pero hacer que la clave PSK que tienen los protocolos estándares se cambie cada cierto tiempo, utilizando una clave generada por un algoritmo TOTP. Este algoritmo generará la clave final utilizando como parte del proceso un derivado de la biometría de la persona que quiere usar la red WiFi.
Figura 36: Parte biométrica del proceso de enrollment.
Para ello, durante la fase de aprovisionamiento inicial de la red WiFi se hará un proceso de enrollment de la biometría del usuario - solo una vez - en el Access Point. El proceso generará un hash de la biometría que será utilizado posteriormente.
Con el valor biométrico como dato de entrada se generará un valor aleatorio que será parte de la semilla del algoritmo TOTP que generará las claves que la red WEP, WPA o WPA2 TOTP utilizará para cifrar los datos del usuario por la red. Este valor será pasado al cliente usando algún método, como mostrarlo por pantalla con un QRCode o de cualquier otra forma.
Figura 37: Parte aleatoria del proceso de aprovisionamiento
En cualquier intento de conexión el cliente pedirá conexión, y el servidor (Access Point) le hará un "Challenge" que deberá cumplir. Para ello, el cliente pedirá las credenciales biométricas al usuario para hacer el derivado de la misma. Después extraerá el valor aleatorio que el Access Point le entregó como parte final del proceso de enrollment, y con la suma de ambos tendrá la semilla del algoritmo TOTP para generar la clave de cifrado temporal.
Figura 38: Proceso de establecimiento de conexión a la red WiFi
Con este valor, cifrará un mensaje "Hello" que podrá ser descifrado solo por el Access Point que tiene el valor biométrico del usuario (que obtuvo durante el proceso de enrollment) y el valor aleatorio que se generó, lo que le permitirá tener el mismo algoritmo TOTP de generación de claves en ambos puntos de la comunicación.
Conclusiones
Al final, el trabajo que hemos visto en esta serie no es más que una reflexión continua sobre cómo se pueden mejorar las medidas de seguridad que tienen los protocolos conocidos y cómo podrían funcionar de manera diferente.
A lo largo de las partes hemos visto que se podrían mejorar las opciones de seguridad que tienen los clientes WiFi de dispositivos móviles o sistemas operativos para detectar ataques en la red, para acotar los ataques de Rogue AP utilizando SSID Pinning. Cómo se pueden reducir las ventanas de exposición de las claves PSK en protocolos WEP, WPA o WPA2-PSK utilizando algoritmos TOTP, y cómo se puede hacer este proceso más robusto haciendo uso de biometría.
Para poder seguir el trabajo completo, os dejo las diapositivas subidas a SlideShare, y la lista completa de todos los artículos publicados en esta serie, con las explicaciones correspondientes.
En la primera parte de esta serie os conté los pensamientos que en el año 2010 tuvimos para crear Mummy y ayudar a hacer un cliente Wi-Fi que protegiera un poco más a los usuarios en el cada vez más beligerante entorno de ataques en redes inalámbricas, en la segunda parte os hablé de lo que nos llevó a pensar en el concepto de SSID Pinning y en la tercera entrega os hablé de PsicoWiFi, la PoC para Windows y Android de estos conceptos. En esta cuarta entrega os voy a hablar de la PoC que hicimos con WEP-TOTP y con WPA-TOTP.
Figura 25: WEP/WPA*-TOTP
El objetivo de este hack era ver cómo podíamos dificultar los ataques que se producen a la clave en las protocolos de redes Wi-Fi que teníamos hoy en día, haciendo algo muy sencillo. La idea era ver cómo clientes que no pudieran ser migrados a entornos empresariales con EAP (Extended Authentication Protocol) - donde se pudieran utilizar sistemas de autenticación basados en certificados digitales -, pudieran ser modificados ligeramente para hacer que el cambio de clave WEP, WPA o WPA2 en entornos PSK se controlara como si fuera un token temporal, tipo TOTP que se cambiara de forma continuada y periódica.
Si repasamos los ataques WEP que tenemos hoy en día, necesitan un alto número de paquetes inyectados y manipulados para conseguir romper la clave en muy poco tiempo con un ataque Online, o tener muchos paquetes para poder hacer un ataque Offline en una captura grabada del tráfico de red en la que no se pueda inyectar tráfico.
En el caso de los ataques WPA-PSK o WPA2-PSK los escenarios existentes (hasta la llegada de Krack) se basaban en capturar el paquete de autenticación y hacer un ataque de fuerza bruta o diccionario a la clave configurada, lo que lleva un coste en tiempo alto - dependiendo de la dificultad de la clave -.
Con la llegada de Krack esto deja de ser así, ya que el ataque es un fallo lógico del protocolo que no depende de la fortaleza de la clave, y es WPA3 el destinado a corregir estos fallos lógicos de seguridad, y se pueden fortalecer los entornos empresariales con soluciones WPA2-EAP-TLS o WPA2-PEAP-TLS (con una capa TLS en la negociación EAP) para conseguir entornos más robustos.
WEP-TOTP & WPA/2-TOTP
En nuestro hack lo que buscábamos era ver si una persona se podría configurar una capa de cambio de contraseña sincroniza mediante un algoritmo TOTP en un entorno en el que su dispositivo cliente, por ejemplo un hardwareIoT o un terminal antiguo, como una impresora con conexión Wi-Fi solo para protocolos WEP, haciendo uso de una configuración de semillas TOTP.
Tómese esta parte como un hack de laboratorio para entornos en los que clientes empresariales o el soporte para criptografía moderna no está disponible y se quiere establecer un cambio de contraseña sincronizado para cada muy poco tiempo, limitando la ventana de oportunidad de un ataque a la clave al tiempo que esta se encuentra activa: 1 minuto, 2 minutos, 1 hora, 1 día, etcétera. Lo que se quiera configurar en la generación de las claves TOTP y que llamamos TTR (Time To Renew).
Figura 27: PoC de Ping en MacOS con un WPA2-TOTP
Este modo de funcionamiento lo habíamos probado ya en Pigram, donde el cifrado de los mensajes SMS que se envían entre la app móvil, y el servidor de backend utilizan claves TOTP, lo que sirve para cifrar y firmar los mensajes al mismo tiempo.
Figura 28: PoC de HTTP Dowwnload en MacOS con un WPA2-TOTP
Para ello, en las pruebas de nuestro laboratorio en lugar de configurar una clave en el cliente, y en el AP Wi-Fi, configuramos una semilla de un algoritmo TOTP, y mediante un servicio, la clave Wi-Fi utilizada en la red WEP o WPA/WPA2 se va cambiando. Por supuesto, si el tiempo es muy corto, el reinicio de los clientes y el daemon del servidor puede ser incómodo, pero el entorno sigue siendo totalmente funcional.
Figura 29: Esquema de generación de clave WEP/WPA/WPA2-TOTP
Para configurar la clave de WEP, WPA-PSK o WPA2-PSK utilizando el algoritmo TOTP, lo que hacíamos era generar un derivado de la combinación del código TOTP más una Pre-Shared Password (en la siguiente parte os contaremos más de esto) que genera una clave Wi-Fi del tipo que se puede ver en la siguiente imagen.
Figura 30: Claves WEP/WPA/WPA2-TOTP generadas
Después de probar que este función y ver que tiraba, hicimos un par de clientes para Andorid y para Windows y vimos cuál era la experiencia de uso en un entorno de pruebas.
Wild Wild WiFi
Para la prueba configuramos un Router Wi-Fi Amper 26555 de Telefónica con un OpenWRT y un interfaz LUCI personalizado para añadir las opciones de, en este caso, WPA2-TOTP del lado del AP Wi-Fi.
Figura 31: WPA2-TOTP en Interfaz LUCI de un OpenWRT
Por otro lado, del lado del cliente hicimos un par de herramientas que llamamos WildWildWiFi para Android y para Windows. En la imagen siguiente se ve el interfaz del cliente para Windows, y en el vídeo siguiente la demo con el cliente Android.
Figura 32: Cliente Wild Wild WiFi para Windows
En el cliente Windows hicimos un pequeño servicio que cambiaba la clave del cliente Wi-Fi cada cierto tiempo (lo marcado por el valor TTR) y lo mismo para un cliente Android.
Figura 33: Demo de WildWildWiFi en Android
En el vídeo se puede ver un ejemplo con Wild Wild WiFi funcionando en Android. En este caso, el cliente Android no requiere que se haga ningún tipo de rooting. En la siguiente parte os contaremos cómo continuamos con estos trabajos.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
