Explorando os dados do Wi‑Fi sem internet em um voo da Southwest

 (jamesbvaughan.com)
1 pontos por GN⁺ 2023-09-29 | 1 comentários | Compartilhar no WhatsApp
  • Em um voo direto de St. Louis para Oakland na volta da Strange Loop, uma compra de internet por $8 falhou, então foi verificado quais dados estavam acessíveis sem internet, apenas conectado ao Wi‑Fi de bordo
  • Nas requisições de rede do portal Wi‑Fi da Southwest, foi encontrado o endpoint current.json, que respondia com sucesso repetidamente, e essa resposta parecia ser a base dos dados da página de status do voo
  • Esse endpoint podia ser chamado com curl sem cookies nem headers, e retornava altitude, coordenadas, horário estimado de chegada, velocidade sobre o solo, distância restante, progresso do voo, estado da conexão via satélite e mais
  • Com os dados coletados, foram visualizadas altitude, ETA e velocidade sobre o solo; fora o trecho de descida, a altitude variava apenas cerca de 20 a 30 pés
  • Não foi uma descoberta especialmente prática, mas só com o JSON de status do voo exposto pelo portal Wi‑Fi de bordo já dá para coletar e analisar dados durante o voo

Explorando o Wi‑Fi de bordo a partir de uma falha no pagamento

  • Em um voo direto de St. Louis para Oakland na volta da Strange Loop, tentou-se comprar o acesso à internet por $8 pelo portal de Wi‑Fi de bordo da Southwest, mas nenhum método de pagamento foi aceito
  • A página web não mostrava uma mensagem de erro útil, então a requisição com falha foi inspecionada nas ferramentas de desenvolvimento de rede do navegador
  • A própria requisição que falhava não dava muitas pistas, mas a chamada repetidamente bem-sucedida para current.json chamou atenção

Os dados de status do voo retornados por current.json

  • A resposta de current.json parecia ser a fonte de dados que alimenta a página de status do voo no portal Wi‑Fi de bordo
  • Um exemplo de resposta incluía os seguintes valores
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: valor que parece indicar o progresso do voo
    • altVal: altitude atual
    • lat, lon: coordenadas atuais
    • dtzone: fuso horário do destino
    • within_us: se o voo está dentro dos Estados Unidos
    • etad: horário estimado de chegada ao destino
    • gspdVal: velocidade atual sobre o solo
    • ttgc: valor que parece ser o tempo restante
    • dist_remain: distância restante
    • actime24: horário atual em algum fuso

Reproduzindo a requisição do navegador com curl

  • O recurso “Copy as cURL” do navegador foi usado para obter rapidamente o comando de chamada ao endpoint
  • Esse recurso existe no Firefox e em navegadores baseados em Chromium, e é útil para reproduzir a requisição enviada pelo navegador com os mesmos headers
  • Nos testes, os cookies e headers incluídos na requisição não eram obrigatórios, e os dados podiam ser obtidos com uma chamada simples de curl como esta
curl 'https://getconnected.southwestwifi.com/current.json'
  • Depois disso, foi executado um loop que buscava os dados a cada 30 segundos e os acumulava em um arquivo de log
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

Dúvidas que restaram sobre os campos da resposta

  • A maioria dos campos era intuitiva, mas alguns valores ainda não tinham significado claro
    • a diferença entre sat_commlink_portal.status e satcomm_status.commlink
    • se pcent_flt_complete é baseado em distância ou em tempo estimado
    • o quanto altVal, etad e gspdVal oscilam durante o voo
    • o que significa o ac em actime24
  • actime24 não parecia ser o horário atual na posição da aeronave, mas sim o horário atual do destino, então era difícil interpretar ac como “aircraft”

Visualizando os dados coletados durante o voo

  • Com os dados coletados, foram visualizadas as variações de altitude, ETA e velocidade sobre o solo

  • Variação da altitude

    • No começo, a ideia era verificar quanto ruído existia nos dados de altitude
    • Como a faixa total era grande demais para perceber o ruído, o trecho de descida foi removido; então a variação de altitude apareceu em torno de 20 a 30 pés
    • Esse nível de estabilidade foi maior do que o esperado, mas não foi possível saber qual é a faixa normal nem a precisão dos dados

  • Variação do ETA

    • Esperava-se que o ETA fosse razoavelmente estável e, após a decolagem inicial, durante um voo suave, ele realmente se mostrou estável
    • Se houvesse atraso no pouso por causa do clima, ainda restava a dúvida se o ETA aumentaria gradualmente ou subiria de forma brusca no fim

  • Variação da velocidade sobre o solo

    • A velocidade sobre o solo também se mostrou estável, como esperado
    • No início, a unidade de velocidade foi mostrada como MPH, mas leitores do HN apontaram que esse valor provavelmente está em knots
    • Como os dados não foram coletados desde o início do voo, não foi possível ver a curva do trecho em que a aeronave se aproxima da velocidade de cruzeiro

Conclusão

  • Não havia nada particularmente útil ou surpreendente nos dados coletados
  • Mesmo sem acesso à internet, é possível coletar e analisar dados durante o voo usando apenas o JSON de status do voo exposto pelo portal Wi‑Fi de bordo

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-29
Comentários do Hacker News

  • Quando meu filho tinha uns 9 ou 10 anos, vi que ele estava usando internet no celular dentro do avião; como eu nunca tinha pago pelo acesso, perguntei como ele estava fazendo isso.
    Ele disse que um colega da escola tinha ensinado que bastava ficar mudando os números do endereço IP atribuído por DHCP nas configurações de Wi-Fi. Na época, aparentemente a American Airlines funcionava liberando apenas os IPs de usuários pagantes, então, se outra pessoa acertasse um IP da faixa 192.168 e se passasse por ele, conseguia assumir a conexão sem autenticação adicional.
    Eu disse para ele não fazer aquilo, mas fiquei um pouco orgulhoso da ousadia de tentar.

    • Eu fazia algo parecido com frequência em antigos hotspots Wi-Fi pagos.
      Primeiro eu fazia uma varredura de ping em toda a sub-rede com nmap -sP para preencher o cache ARP com endereços IP/MAC úteis e, depois, ia trocando o IP e o endereço MAC um por um até encontrar uma combinação que passasse pelo firewall.
      Ter trabalhado como engenheiro de NOC na Wayport (hoje AT&T WiFi) ajudou a entender a arquitetura.
    • Usei o mesmo método em aviões e hotéis, e nos hotéis a taxa de sucesso era maior.
      Isso porque era menos provável que outra pessoa estivesse usando naquele exato momento e também menos provável que a conexão caísse.
      Quando era criança, também fiz outro pequeno hack: na época em que as companhias aéreas vendiam ou alugavam fones especiais para os filmes de bordo, a porta tinha dois orifícios lado a lado e o plugue eram dois tubos.
      Antes de embarcar, eu pegava alguns canudos em uma lanchonete de fast-food do terminal, de preferência aqueles dobráveis, encaixava um no outro para formar um canudo comprido, colocava uma ponta na porta e a outra no ouvido, e conseguia ouvir o áudio do filme de graça.
    • Alguns anos atrás, em um voo da Southwest, esqueci de desligar o OpenVPN e consegui acessar a internet pelo túnel sem pagar.
      Na época, acho que eles só bloqueavam portas comuns (80, 443, 53 etc.) para usuários que não tinham pago; depois, essa brecha foi fechada.
    • É uma história realmente incrível.
      A situação da segurança em Wi-Fi aberto é, na prática, bem lamentável, e também não sei muito bem como uma companhia aérea poderia fazer melhor de forma simples.
      Se os dispositivos suportarem, talvez dê para usar Opportunistic Wireless Encryption [1] e vincular a autenticação a uma sessão OWE específica, em vez de a um endereço MAC específico, mas não sei o quão estável uma sessão OWE é.
      Se for preciso fazer login de novo toda vez que o ponto de acesso mudar, isso seria muito inconveniente.
      É uma pena que a segurança de Wi-Fi pago ou gratuito ainda não seja um problema resolvido, e que ainda sejam necessárias soluções temporárias personalizadas, como portais cativos frágeis que precisam deixar passar tráfego seletivo, como pagamentos, 3DS e e-mails de redefinição de senha.
      Também seria bom haver um endpoint e uma API padrão para o cliente saber se está conectado, limitado ou precisando de pagamento/autenticação, e poder receber um token de autenticação para se reconectar naturalmente na mesma sessão.
      Hotspot 2.0 e WPA-EAP (WPA Enterprise) existem, mas são mais voltados, respectivamente, a redes de hotspots operadas por operadoras e a ambientes corporativos, então não se encaixam muito bem no caso de “pagar por um portal web”.
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • Antigamente havia aplicativos que escaneavam os IPs e endereços MAC de uma rede que já estava conectada à internet.
      Se você mudasse a configuração para um daqueles endereços MAC, depois que o usuário original terminasse, podia usar aquela conexão sozinho.
      Eu me recusava a pagar por Wi-Fi quando viajava a trabalho, e isso era bem útil na época em que aeroportos e cafeterias ainda cobravam pelo acesso.
      Hoje quase não é mais necessário, mas ainda pode ajudar em lugares onde há custo para se conectar.

  • “Segundo estes dados, a altitude do avião oscilou só cerca de 20 a 30 pés. É mais estável do que eu imaginava!”
    Os pilotos automáticos são muito bons e fazem o controle por servos com base na altitude barométrica.
    Muitos codificadores de altitude barométrica em aeronaves modernas, por exemplo os dispositivos que alimentam a altitude reportada por transponders via radar SSR ou ADS-B, têm resolução de codificação de 25 pés.
    O que se vê aqui provavelmente também é essa resolução de 25 pés; existem codificadores com resolução de 10 pés, mas 25 pés é muito comum.

    • Não sei quais dados de sensores a API mencionada no texto recebe, mas a maioria dos aviões de passageiros transmite até a precisão da posição detectada e a precisão da posição vertical/altitude.
      No mapa https://globe.adsbexchange.com/, clique em uma aeronave e role a barra lateral esquerda até o fim para ver a seção “Accuracy”.
      O ADS-B Exchange não mostra o Rc/v, que é a precisão da posição vertical, mas exibe os outros valores.
      Para mais detalhes, veja https://mode-s.org/decode/content/ads-b/7-uncertainty.html.
    • Em uma aeronave pequena, uma variação de 20 a 30 pés não é anormal quando se pilota manualmente com atenção.
      Em cruzeiro, um avião de passageiros certamente deve usar piloto automático.
      Certa vez, enquanto recebia suporte de acompanhamento de voo, desci cerca de 100 pés e o controlador perguntou se estava tudo bem, e fiquei surpreso por estarem observando com tanto detalhe.
      Eu tinha esquecido de vestir o colete salva-vidas antes de um trecho sobre água e, enquanto o colocava, passei os controles para minha esposa, que ainda não tinha feito aulas de voo.
      Mais tarde ela também tirou a licença, e achei interessante que o acompanhamento do controle fosse preciso a ponto de intervir.
    • Teria sido legal registrar uma trilha de GPS com altitude no celular e comparar.
      Pressão barométrica e GPS são coisas diferentes, e também tenho curiosidade para saber se a diferença salta de forma evidente quando se redefine o altímetro barométrico usando outra referência AWOS.
      Não sei como isso é feito em aeronaves grandes, mas em aviões pequenos é preciso ajustar o altímetro de acordo com o clima local.
      A estação meteorológica mede a pressão em sua própria altitude, informa pelo rádio um valor “corrigido para o nível do mar”, e esse valor é inserido no altímetro para corrigir a leitura de altitude barométrica conforme as variações meteorológicas locais.
      Mesmo voando por uma hora e voltando ao mesmo lugar, o ajuste do altímetro pode mudar alguns milibares.
    • Com a introdução do RVSM, imagino que isso tenha ficado muito mais preciso.
      O padrão de separação vertical entre aeronaves era de 2000 pés, mas no início dos anos 2000 foi reduzido para 1000 pés.
    • Já li que, em algumas situações, precisão excessiva pode ser até perigosa.
      Por exemplo, se um piloto vai para 3000 pés, ele fica exatamente a 3000 pés; se outro piloto em rota de colisão também quiser 3000 pés, a colisão pode se tornar garantida.
      Se a altitude for menos precisa, é mais provável que vire apenas uma quase colisão.
      Acho que a solução talvez fosse evitar números redondos e usar algo como 2950 pés ou 3050 pés.
      Os detalhes podem estar errados, mas tenho bastante certeza de que esse problema foi considerado seriamente.

  • Alguns meses atrás descobri a mesma coisa e criei um rastreador de voos em CLI que usa essa API.
    Testei em algumas companhias aéreas e, como todas usavam o mesmo provedor de internet a bordo, funcionou quase perfeitamente.
    [1]: https://github.com/NalinPlad/OuterFlightTracker

    • Legal.
      Eu queria fazer algo parecido, mas não tinha experiência suficiente para criar uma TUI durante o voo sem consultar a internet.
      Ainda assim, fico feliz que isso já exista.

  • A forma de obter os mesmos dados em voos da Delta é 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"  
}

    Também há um trecho interessante

    $ 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 o recurso de interpolação de strings do jq, dá para simplificar ainda mais 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • Estou no avião agora e acessei essa URL, e ela realmente funciona
      É uma informação que também dá para ver na UI do portal Wi-Fi, mas vê-la como um bloco de JSON passa uma sensação diferente 
      {"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"}
      Estou no celular, então desculpem a formatação do JSON
    • Se a ideia é ar fresco, seria bom se desse para abrir a porta com uma requisição POST
    • É interessante a escolha de usar um vehicleId mais genérico em vez de planeId ou tailNumber
      Fico curioso se há outros tipos de equipamento operacional da Delta com uma API compatível com isso
      Também fico curioso sobre quanto alguém que conheça outros sistemas internos conseguiria inferir da estrutura do sistema a partir de flightId
      À primeira vista, não parece ser mais do que uma chave composta criada com dados observáveis, mas ainda assim é interessante
    • "airspeed": null
      Faz a gente olhar pela janela meio apreensivo

  • Eu gostaria de ver alguém criar um proxy que envie dados arbitrários usando a conexão permitida para iMessage ou WhatsApp grátis
    Algo como manter um relay do WhatsApp em casa e trocar mensagens a partir do avião
    No nível mais básico, parece possível enviar uma URL para o WhatsApp de casa; lá ele carregaria a página web e enviaria o HTML de volta como resposta pelo WhatsApp para renderização
    Fico curioso para saber quanta coisa daria para fazer funcionar
    Parece que alguém já fez um relay TCP por WhatsApp, o que é legal

    • https://github.com/aleixrodriala/wa-tunnel
    • Não li os termos de uso, mas fico pensando se não daria para simplesmente ter um roteador IP de verdade
      Você paga a assinatura e também sobe uma rede Wi-Fi
      Se o SSID do avião for “Foo”, você a batiza de “Foo discounted” e, no portal cativo, deixa a pessoa escolher vários “descontos”, como veteranos, idosos, crianças etc.
      Não importa qual opção ela escolha, a página de pagamento cobra US$ 2
      Depois que você recupera o custo do serviço, passa a mostrar aos visitantes posteriores “todos os descontos se esgotaram, use o Foo”
      Assim eu uso internet grátis, e os usuários do roteador/portal usam internet de US$ 2
      A largura de banda de upload certamente seria péssima, então também deve ser fácil multiplexar todos os dados em uma única conexão minha
      Seria colocado em um dispositivo como um RPi, mas, para passar pela inspeção de segurança, teria que parecer um produto acabado, como um tocador de música, e teria que continuar funcionando quando fosse preciso levantar a mesinha ou ir ao banheiro
      Parece muito improvável que o avião tenha WIPS ou WIDS para derrubar conexões Wi-Fi maliciosas
      Afinal, uma LAN party nem é proibida, não é?
    • Há 1 ou 2 anos, peguei um voo um ou dois dias depois do lançamento do primeiro beta do Apple Private Relay e consegui usar Wi-Fi grátis durante todo o voo
      Provavelmente porque os destinos colocados na lista de permissões para iMessage ou notificações push acabaram incluindo isso também
      Alguns dias depois, antes do voo de volta, isso já tinha sido bloqueado
    • Em vez de “uau, que legal”, a primeira coisa que me vem à cabeça é “mensagens grátis são um benefício bom, mas, se houver abuso, vão acabar fechando isso”
      Parece que meus tempos de hacker ficaram para trás
    • Já vi Wi-Fi de companhia aérea não bloquear tráfego DNS
      Há uma boa chance de ser possível fazer algo parecido com um túnel DNS como o Iodine(https://github.com/yarrick/iodine)

  • A Southwest mostra os mesmos dados em uma tela mais bonita
    Mesmo sem pagar pela Wi-Fi, dá para ver muitas informações, como rastreamento do voo, altitude atual, horário estimado de chegada e posição no mapa
    Provavelmente usa os mesmos dados para os quais o autor criou o programa de processamento; essencialmente, é como se houvesse um site que dá para acessar de graça

    • Sim, é exatamente isso
      Dá para ver gratuitamente uma ótima página de status que visualiza esses dados
      Ainda assim, fiz o scraping por dois motivos
      Primeiro, a página de status mostra apenas os valores atuais, e eu queria ver todos os dados do voo
      Segundo, foi divertido
    • Em um voo recente nos EUA, acho que foi da Alaska Airlines, havia uma caixa de LAN local que permitia assistir a filmes e programas de TV via Wi-Fi mesmo sem acesso à internet
    • Fica resolvida a dúvida: “por que um monte de dados do avião volta quando tento abrir a página do portal?”

  • Gosto do espírito deste texto
    O autor provavelmente também poderia ter feito Git scraping dessas informações
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • Pensei que seria possível tirar uma foto pela janela e associar as coordenadas GPS daquela saída JSON à imagem
    Parece bastante útil

    • Se a permissão de localização estiver ativada no app da câmera, as coordenadas entram nos dados EXIF da imagem
      Dispositivos GPS civis dos EUA são proibidos de funcionar acima de 60.000 pés de altitude e acima de 1.000 nós por causa das restrições de exportação de material militar do ITAR

  • Se quiser comparar os dados da aeronave com dados ADS-B, este parece ser o voo do autor do post original
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • É possível que as fontes dos dados ADS-B e dos dados desta API sejam calculadas pelo menos a partir dos mesmos instrumentos e sistemas de voo
    • É o voo certo
      É uma boa ideia; pena que não pensei nisso

  • É uma história interessante
    Mas ninguém mais se incomoda com esse formato de time?
    Parece uma escolha estranha; eu esperava algo mais padrão, como ISO 8601 com offset de fuso horário
    "time": "Sun Sep 24 22:02:19 2023"

    • Tive uma impressão parecida
      Parece que quem projetou este sistema converteu a hora no servidor para uma representação localizada conforme a posição do voo e quis inseri-la diretamente na UI web sem lógica do lado do cliente
    • Parece o formato padrão usado por ctime
      Pode ser uma pista sobre o backend subjacente
      https://cplusplus.com/reference/ctime/ctime/