Explorando datos del WiFi en un vuelo de Southwest sin Internet

 (jamesbvaughan.com)
1 puntos por GN⁺ 2023-09-29 | 1 comentarios | Compartir por WhatsApp
  • Al fallar el pago de US$8 por Internet en un vuelo directo St. Louis-Oakland de regreso de Strange Loop, se revisaron los datos accesibles sin Internet mientras se estaba conectado al WiFi a bordo
  • En las solicitudes de red del portal WiFi de Southwest se encontró un endpoint current.json que respondía correctamente de forma repetida, y esa respuesta parece ser la base de la página de estado del vuelo
  • Ese endpoint podía llamarse con curl sin cookies ni headers, y devolvía altitud, coordenadas, hora estimada de llegada, velocidad sobre el terreno, distancia restante, porcentaje de avance del vuelo, estado de conexión satelital y más
  • Con los datos recopilados se visualizaron la altitud, la ETA y la velocidad sobre el terreno; salvo en el tramo de descenso, la altitud solo fluctuaba alrededor de 20 a 30 pies
  • No fue un hallazgo especialmente práctico, pero solo con el JSON de estado del vuelo expuesto por el portal WiFi a bordo se pueden recopilar y analizar datos durante el vuelo

Exploración del WiFi a bordo a partir de un pago fallido

  • En un vuelo directo St. Louis-Oakland de regreso de Strange Loop, se intentó comprar acceso a Internet por US$8 mediante el portal WiFi a bordo de Southwest, pero no aceptó ningún método de pago
  • La página web no mostraba un mensaje de error útil, así que se revisaron las solicitudes fallidas con las herramientas de desarrollo de red del navegador
  • En la solicitud fallida en sí era difícil encontrar pistas, pero llamó la atención una solicitud a current.json que respondía correctamente de forma repetida

Datos de estado del vuelo devueltos por current.json

  • La respuesta de current.json parece ser la información que alimenta la página de estado del vuelo del portal WiFi a bordo
  • Una respuesta de ejemplo incluía los siguientes valores
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: valor que parece indicar el porcentaje de avance del vuelo
    • altVal: altitud actual
    • lat, lon: coordenadas actuales
    • dtzone: zona horaria del destino
    • within_us: si el vuelo está dentro de Estados Unidos
    • etad: hora estimada de llegada al destino
    • gspdVal: velocidad actual sobre el terreno
    • ttgc: valor que parece ser el tiempo restante
    • dist_remain: distancia restante
    • actime24: hora actual de alguna zona horaria

Reproducir la solicitud del navegador con curl

  • Con la función “Copy as cURL” del navegador se obtuvo rápidamente el comando para llamar al endpoint
  • Esta función existe en Firefox y en navegadores basados en Chromium, y resulta útil para reproducir una solicitud enviada por el navegador con los mismos headers
  • En el experimento, las cookies o headers incluidos en la solicitud no eran necesarios, y bastaba con una llamada simple a curl como esta para obtener los datos
curl 'https://getconnected.southwestwifi.com/current.json'
  • Después se ejecutó un loop que obtenía datos cada 30 segundos y los acumulaba en un archivo de logs
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

Dudas pendientes sobre los campos de la respuesta

  • La mayoría de los campos eran intuitivos, pero el significado de algunos valores no estaba claro
    • La diferencia entre sat_commlink_portal.status y satcomm_status.commlink
    • Si pcent_flt_complete se basa en distancia o en tiempo estimado
    • Cuánto fluctúan altVal, etad y gspdVal durante el vuelo
    • Qué significa ac en actime24
  • actime24 parecía ser la hora actual del destino, no la hora actual de la ubicación del avión, por lo que es difícil interpretar ac como “aircraft”

Visualización de los datos recopilados durante el vuelo

  • Con los datos recopilados se visualizaron los cambios de altitud, ETA y velocidad sobre el terreno

  • Cambios de altitud

    • Al principio se intentó comprobar cuánto ruido había en los datos de altitud
    • Como el rango total era grande, era difícil ver el ruido; tras eliminar el tramo de descenso, la variación de altitud resultó ser de alrededor de 20 a 30 pies
    • Ese nivel de estabilidad fue mayor de lo esperado, aunque no se podía conocer el rango normal ni la precisión de los datos

  • Cambios de ETA

    • Se esperaba que la ETA fuera razonablemente estable, y en un vuelo fluido después del despegue inicial efectivamente lo fue
    • Si el aterrizaje se retrasara por el clima, queda la duda de si la ETA aumentaría gradualmente o si subiría de forma brusca hacia el final

  • Cambios de velocidad sobre el terreno

    • La velocidad sobre el terreno también fue estable, como se esperaba
    • Al principio se mostró la unidad de velocidad como MPH, pero lectores de HN señalaron que era muy probable que el valor estuviera en knots
    • Como no se pudieron recopilar datos desde el inicio del vuelo, no se observó la curva del tramo en que se aproxima a la velocidad de crucero

Conclusión

  • En los datos recopilados no hubo nada especialmente útil o sorprendente
  • Incluso sin acceso a Internet, se puede usar el JSON de estado del vuelo expuesto por el portal WiFi a bordo para recopilar y analizar datos durante el vuelo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-29
Comentarios de Hacker News

  • Cuando mi hijo tenía unos 9 o 10 años, lo vi usando internet en su teléfono durante un vuelo. Como yo nunca había pagado por el servicio, le pregunté cómo lo estaba usando.
    Me dijo que un amigo de la escuela le había contado que bastaba con ir cambiando los números de la dirección IP asignada por DHCP en la configuración de Wi-Fi. En ese momento, American Airlines aparentemente solo autorizaba las IP de los usuarios de pago, así que si alguien adivinaba una IP del rango 192.168 y se hacía pasar por otra persona, podía tomar la conexión sin autenticación adicional.
    Le dije que no lo hiciera, pero me sentí un poco orgulloso de que tuviera la audacia de intentarlo.

    • Yo hacía algo parecido con frecuencia en los viejos hotspots Wi-Fi de pago.
      Primero hacía un barrido de ping de toda la subred con nmap -sP para llenar la caché ARP con direcciones IP/MAC útiles, y luego iba cambiando una por una la dirección IP y la dirección MAC hasta encontrar una combinación que pasara el firewall.
      Haber trabajado como ingeniero de NOC en Wayport (ahora AT&T WiFi) me ayudó a entender la arquitectura.
    • Usé el mismo método en aviones y hoteles, y en los hoteles funcionaba mejor.
      Era menos probable que otra persona lo estuviera usando justo en ese momento y también menos probable que se cortara.
      De chico también hacía otro pequeño hack: en la época en que las aerolíneas vendían o alquilaban audífonos especiales para las películas a bordo, el puerto tenía dos orificios uno al lado del otro y el conector eran dos tubos.
      Antes de abordar, tomaba algunas pajillas en un local de comida rápida de la terminal, de ser posible de las flexibles, las unía para formar una pajilla larga, metía un extremo en el puerto y ponía el otro en el oído para escuchar gratis el audio de la película.
    • Hace unos años, en un avión de Southwest, olvidé apagar OpenVPN y pude acceder a internet a través del túnel sin pagar.
      En ese momento parece que solo bloqueaban los puertos comunes (80, 443, 53, etc.) para los usuarios que no habían pagado, y después cerraron ese agujero.
    • Es una anécdota realmente sorprendente.
      El estado de la seguridad en Wi-Fi abierto es bastante lamentable, y tampoco veo una forma fácil de que las aerolíneas lo hagan mucho mejor.
      Si los dispositivos lo soportan, podrían usar Opportunistic Wireless Encryption [1] y vincular la autenticación no a una dirección MAC específica, sino a una sesión OWE específica, aunque no sé qué tan estable sea una sesión OWE.
      Si hubiera que volver a iniciar sesión cada vez que cambia el punto de acceso, sería muy incómodo.
      Es una lástima que la seguridad del Wi-Fi de pago o gratuito todavía no sea un problema resuelto, y que aún se necesiten soluciones temporales a medida como portales cautivos frágiles que deben dejar pasar tráfico selectivo, como pagos, 3DS y correos de restablecimiento de contraseña.
      También sería bueno contar con un endpoint y una API estándar para que el cliente sepa si está conectado, limitado o si requiere pago/autenticación, y que pudiera recibir un token de autenticación para reconectarse de forma natural dentro de la misma sesión.
      Existen Hotspot 2.0 y WPA-EAP (WPA Enterprise), pero cada uno está más orientado a redes de hotspots operadas por telcos y a entornos empresariales, respectivamente, así que no encajan del todo con el caso de “pagar mediante un portal web”.
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • Antes existían apps que escaneaban las direcciones IP y MAC de una red que ya estuviera conectada a internet.
      Si cambiabas tu configuración para usar una de esas direcciones MAC, después de que el usuario original terminara podías usar esa conexión para ti solo.
      Cuando viajaba por trabajo me negaba a pagar por el Wi-Fi, y en la época en que todavía cobraban por el acceso en aeropuertos y cafeterías, era bastante útil.
      Hoy casi no hace falta, pero todavía puede servir en lugares donde cobran por conectarse.

  • “Según estos datos, la altitud del avión solo osciló unos 20 a 30 pies. ¡Es más estable de lo que pensaba!”
    Los pilotos automáticos son muy buenos y realizan control por servo en función de la altitud barométrica.
    Muchos codificadores de altitud barométrica en aviones modernos, por ejemplo los dispositivos que alimentan la altitud que reporta el transpondedor por radar SSR o ADS-B, tienen una resolución de codificación de 25 pies.
    Lo que se ve aquí probablemente también sea esa resolución de 25 pies; existen codificadores con resolución de 10 pies, pero 25 pies es muy común.

    • No sé qué datos de sensores recibe la API mencionada en el artículo, pero la mayoría de los aviones comerciales transmiten la precisión de la posición detectada, incluida la precisión de posición vertical/altitud.
      En el mapa de https://globe.adsbexchange.com/, si haces clic en una aeronave y bajas hasta el final de la barra lateral izquierda, puedes ver la sección “Accuracy”.
      ADS-B Exchange no muestra Rc/v, que es la precisión de la posición vertical, pero sí muestra otros valores.
      Para más detalles, consulta https://mode-s.org/decode/content/ads-b/7-uncertainty.html.
    • En una aeronave pequeña, un rango de 20 a 30 pies no es anormal cuando se pilota manualmente con atención.
      En crucero, obviamente esperaría que un avión comercial use el piloto automático.
      Hace tiempo, mientras recibía apoyo de seguimiento de vuelo, descendí unos 100 pies y el controlador me preguntó si todo estaba bien, y me sorprendió que estuvieran mirando con tanto detalle.
      La situación era que había olvidado ponerme el chaleco salvavidas antes de un tramo sobre agua y, mientras me lo ponía, le pasé los controles a mi esposa, que todavía no había recibido clases de vuelo.
      Más tarde mi esposa también obtuvo la licencia, y me pareció interesante que el seguimiento de control fuera lo bastante preciso como para intervenir.
    • Habría sido genial registrar una traza GPS con la altitud incluida en el teléfono y compararla.
      La presión barométrica y el GPS son distintos, y también me da curiosidad si al reajustar el altímetro barométrico con otro ajuste AWOS la diferencia salta de forma evidente.
      No sé cómo lo hacen los aviones grandes, pero en aeronaves pequeñas hay que ajustar el altímetro según el clima local.
      La estación meteorológica mide la presión a su propia altitud, transmite por radio el valor “corregido al nivel del mar”, y uno lo introduce en el altímetro para corregir la lectura de altitud barométrica según los cambios meteorológicos locales.
      Incluso si vuelas una hora y vuelves al mismo lugar, el ajuste del altímetro puede haber cambiado algunos milibares.
    • Con la introducción de RVSM, supongo que se volvió mucho más preciso.
      El estándar de separación vertical entre aeronaves era de 2000 pies, pero a principios de los 2000 se redujo a 1000 pies.
    • He leído que, en ciertas situaciones, un exceso de precisión puede ser más bien peligroso.
      Por ejemplo, si un piloto va a 3000 pies, queda exactamente a 3000 pies; y si otro piloto también quiere 3000 pies en una trayectoria de colisión, el choque puede quedar garantizado.
      Si la altitud es menos precisa, es más probable que todo termine en un incidente de proximidad.
      Creo que la solución probablemente era evitar números redondos y usar algo como 2950 pies o 3050 pies.
      Puede que los detalles estén mal, pero estoy bastante seguro de que este problema se analizó seriamente.

  • Hace unos meses descubrí lo mismo y creé un rastreador de vuelos por CLI que usa esta API.
    Lo probé con varias aerolíneas y, como todas usaban el mismo proveedor de internet a bordo, funcionó casi a la perfección.
    [1]: https://github.com/NalinPlad/OuterFlightTracker

    • Genial.
      Quería hacer algo parecido, pero no tenía suficiente experiencia como para crear una TUI en pleno vuelo sin consultar internet.
      Aun así, me alegra que ya exista.

  • La forma de obtener los mismos datos en vuelos de Delta es esta

    $ curl https://wifi.delta.com/api/flight-data | jq  

    {  
"timestamp": "2023-07-11T14:54:41Z",  
"eta": "17:48",  
"flightDuration": 278,  
"flightNumber": "DAL786",  
"latitude": 39.723472595214844,  
"longitude": -97.1514205932617,  
"noseId": "3879",  
"paState": false,  
"vehicleId": "N879DN",  
"destination": "KPDX",  
"origin": "KATL",  
"flightId": "N879DN_SF_20230711121358",  
"airspeed": null,  
"airTemperature": 24,  
"altitude": 33922,  
"distanceToGo": 179,  
"doorState": "Closed",  
"groundspeed": 442,  
"heading": -73,  
"timeToGo": 174,  
"wheelWeightState": "Off"  
}

    También hay un fragmento interesante

    $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=";, .latitude, ",", .longitude' | tr -d '\n'; echo  
https://maps.google.com/?q=40.5615234375,-101.2824478149414
    • Usando la función de interpolación de strings de jq, se puede simplificar más 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • Acabo de probar esta URL dentro del avión y realmente funciona
      Es información que también se puede ver en la UI del portal Wi-Fi, pero verla como un bloque de JSON se siente distinto 
      {"timestamp":"2023-09-28T21:57:39Z","eta":"23:45","flightDuration":164,"flightNumber":"DAL992","latitude":47.4557876586914,"longitude":-111.73490905761719,"noseId":"3883","paState":false,"vehicleId":"N883DN","destination":"KMSP","origin":"KSEA","flightId":"N883DN_SF_20230928195737","airspeed":null,"airTemperature":null,"altitude":35273,"distanceToGo":13,"doorState":"Closed","groundspeed":499,"heading":95,"timeToGo":107,"wheelWeightState":"Off"}
      Disculpen el formato del JSON, estoy en móvil
    • Si quieres aire fresco, estaría bueno poder abrir la puerta con una solicitud POST
    • Es interesante la decisión de usar el más general vehicleId en vez de planeId o tailNumber
      Me pregunto si entre los equipos de operación de Delta hay otros tipos que tengan una API compatible con esto
      También me pregunto cuánto podría inferir alguien que conozca otros sistemas internos sobre la arquitectura del sistema a partir de flightId
      A simple vista no parece ser más que una clave compuesta hecha con datos visibles, pero aun así es interesante
    • "airspeed": null
      Me hace mirar por la ventana con inquietud

  • Me gustaría ver que alguien haga un proxy que envíe datos arbitrarios usando la conexión permitida para iMessage o WhatsApp gratis
    Algo como montar un relay de WhatsApp en casa y enviar y recibir mensajes desde el avión
    En lo más básico, podrías mandar una URL al WhatsApp de tu casa, que en casa cargue la página web y te devuelva el HTML como respuesta de WhatsApp para renderizarlo
    Me pregunto cuántas cosas se podrían hacer funcionar
    Parece que ya hay alguien que hizo un relay TCP sobre WhatsApp, genial

    • https://github.com/aleixrodriala/wa-tunnel
    • No he leído los términos de servicio, pero me pregunto si no bastaría con poner un router IP real
      Pagas la suscripción y también levantas una red Wi-Fi
      Si el SSID del avión es “Foo”, la llamas “Foo discounted” y en el portal cautivo haces que elijan entre varios “descuentos”, como veteranos, adultos mayores o niños
      Elijan lo que elijan, en la página de pago les cobras 2 dólares
      Una vez recuperado el costo del servicio, a los visitantes siguientes les muestras “se agotaron todos los descuentos, usa Foo”
      Así yo uso Internet gratis y los usuarios del router/portal usan Internet de 2 dólares
      El ancho de banda de subida seguramente será pésimo, así que también debería ser fácil multiplexar todos los datos sobre mi única conexión
      Habría que meterlo en un dispositivo tipo RPi, pero para pasar el control de seguridad tendría que verse como un producto terminado, como un reproductor de música, y tendría que seguir funcionando cuando haya que subir la mesita o ir al baño
      Parece muy poco probable que el avión tenga WIPS o WIDS para cortar conexiones Wi-Fi no autorizadas
      Para empezar, no es como si estuvieran prohibidas las LAN parties, ¿no?
    • Hace uno o dos años, uno o dos días después de que saliera la primera beta de Apple Private Relay, tomé un avión y pude usar Wi-Fi gratis durante todo el vuelo
      Probablemente porque los destinos que habían puesto en la lista de permitidos para iMessage o notificaciones push también incluían eso
      Para el vuelo de regreso unos días después, ya lo habían bloqueado
    • Antes que “wow, qué genial”, lo primero que se me viene a la mente es “la mensajería gratis es un buen beneficio, pero si se abusa lo van a cerrar”
      Parece que mis días de hacker ya quedaron atrás
    • He visto que el Wi-Fi de aerolíneas no bloquea el tráfico DNS
      Es muy probable que se pueda hacer algo parecido con un túnel DNS como Iodine(https://github.com/yarrick/iodine)

  • Southwest muestra los mismos datos en una pantalla más bonita
    Aunque no pagues por el Wi-Fi, puedes ver mucha información, como el seguimiento del vuelo, la altitud actual, la hora estimada de llegada y la ubicación en el mapa
    Probablemente use los mismos datos con los que el autor hizo su programa de procesamiento; en esencia, es como si hubiera un sitio que puedes visitar gratis

    • Correcto, exactamente eso
      Puedes ver gratis una buena página de estado que visualiza estos datos
      Aun así, los extraje por dos razones
      Primero, la página de estado solo muestra los valores actuales, y yo quería ver todos los datos del vuelo
      Segundo, fue divertido
    • En un vuelo reciente en EE. UU., creo que quizás de Alaska Airlines, había una caja de LAN local que permitía ver películas y programas de TV por Wi-Fi sin acceso a Internet
    • Se resolvió la duda de “¿por qué al intentar abrir la página del portal me devuelve un montón de datos del avión?”

  • Me gusta el espíritu de este artículo
    Parece que el autor también podría haber hecho Git scraping de esta información
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • Pensé que se podría tomar una foto por la ventana y asociar a la imagen las coordenadas GPS de esa salida JSON
    Parece bastante útil

    • Si activas el permiso de ubicación en la app de cámara, las coordenadas se incluyen en los datos EXIF de la imagen
      Debido a las restricciones de exportación de material militar de ITAR, los dispositivos GPS civiles de EE. UU. tienen prohibido funcionar por encima de 60,000 pies de altitud y por encima de 1,000 nudos

  • Si quieres comparar los datos de la aeronave con los datos ADS-B, este parece ser el vuelo del autor original
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • Es posible que la fuente de datos ADS-B y la fuente de datos de esta API se hayan calculado, al menos, a partir de los mismos instrumentos y sistemas de vuelo
    • Es el vuelo correcto
      Es una buena idea; lástima que no se me ocurrió

  • Es una historia interesante
    Pero ¿a nadie más le molesta ese formato de time?
    Parece una elección rara; habría esperado algo más estándar, como ISO 8601 con desplazamiento de zona horaria
    "time": "Sun Sep 24 22:02:19 2023"

    • Sentí algo parecido
      Parece que quien diseñó este sistema convirtió la hora en el servidor a una representación localizada según la ubicación del vuelo, para insertarla directamente en la UI web sin lógica del lado del cliente
    • Parece el formato predeterminado que usa ctime
      Podría ser una pista sobre el backend subyacente
      https://cplusplus.com/reference/ctime/ctime/