Southwest uçuşunda internet olmadan WiFi verilerine bakmak

 (jamesbvaughan.com)
1 puan yazan GN⁺ 2023-09-29 | 1 yorum | WhatsApp'ta paylaş
  • Strange Loop’tan dönüşte St. Louis-Oakland direkt uçuşunda 8 dolarlık internet ödemesi başarısız olunca, uçak içi WiFi’ye bağlıyken internet olmadan erişilebilen veriler incelendi
  • Southwest WiFi portalının ağ isteklerinde tekrar tekrar başarılı olan current.json endpoint’i bulundu; bu yanıtın uçuş durumu sayfasının temel verisi olduğu görülüyor
  • Bu endpoint, çerez veya header olmadan da curl ile çağrılabiliyordu ve irtifa, koordinatlar, tahmini varış zamanı, yer hızı, kalan mesafe, uçuş ilerleme yüzdesi, uydu bağlantı durumu gibi bilgileri döndürüyordu
  • Toplanan verilerle irtifa, ETA ve yer hızı görselleştirildi; alçalma bölümü hariç tutulduğunda irtifa yalnızca yaklaşık 20-30 fit seviyesinde dalgalanıyordu
  • Özellikle pratik bir keşif olmasa da, uçak içi WiFi portalının açığa sunduğu uçuş durumu JSON’u ile uçuş sırasında veri toplama ve analiz yapılabiliyor

Ödeme hatasından başlayan uçak içi WiFi keşfi

  • Strange Loop’tan dönüşte St. Louis-Oakland direkt uçuşunda Southwest’in uçak içi WiFi portalı üzerinden 8 dolarlık internet erişimi satın alınmaya çalışıldı, ancak hiçbir ödeme yöntemi kabul edilmedi
  • Web sayfası yardımcı olacak bir hata mesajı göstermedi; tarayıcının ağ geliştirici araçları ile başarısız istek incelendi
  • Başarısız isteğin kendisinde ipucu bulmak zordu, ancak tekrar tekrar başarılı olan current.json isteği dikkat çekti

current.jsonın döndürdüğü uçuş durumu verileri

  • current.json yanıtı, uçak içi WiFi portalının uçuş durumu sayfasını çalıştıran veri gibi görünüyor
  • Örnek yanıtta şu değerler yer alıyordu
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: uçuş ilerleme oranı gibi görünen değer
    • altVal: mevcut irtifa
    • lat, lon: mevcut koordinatlar
    • dtzone: varış noktasının saat dilimi
    • within_us: uçuşun ABD içinde olup olmadığı
    • etad: varış noktasına tahmini varış zamanı
    • gspdVal: mevcut yer hızı
    • ttgc: kalan süre gibi görünen değer
    • dist_remain: kalan mesafe
    • actime24: bir saat dilimindeki mevcut saat

Tarayıcı isteğini curl ile yeniden üretmek

  • Tarayıcının “Copy as cURL” özelliğiyle endpoint çağrısı komutu hızlıca elde edildi
  • Bu özellik Firefox ve Chromium tabanlı tarayıcılarda bulunur; tarayıcının gönderdiği isteği aynı header’larla yeniden üretmek için yararlıdır
  • Deney sonucunda istekte yer alan çerez veya header’ların zorunlu olmadığı görüldü; aşağıdaki gibi basit bir curl çağrısıyla veri alınabiliyordu
curl 'https://getconnected.southwestwifi.com/current.json'
  • Ardından her 30 saniyede bir veriyi alıp log dosyasına biriktiren bir döngü çalıştırıldı
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

Yanıt alanlarında kalan sorular

  • Alanların çoğu sezgiseldi, ancak bazı değerlerin anlamı net değildi
    • sat_commlink_portal.status ile satcomm_status.commlink arasındaki fark
    • pcent_flt_complete değerinin mesafeye mi, tahmini süreye mi dayandığı
    • altVal, etad, gspdVal değerlerinin uçuş sırasında ne kadar dalgalandığı
    • actime24 içindeki acnin ne anlama geldiği
  • actime24, uçağın konumundaki mevcut saat değil de varış noktasının mevcut saati gibi göründüğünden, acyi “aircraft” olarak yorumlamak zor

Uçuş sırasında toplanan verilerin görselleştirilmesi

  • Toplanan verilerle irtifa, ETA ve yer hızı değişimleri görselleştirildi

  • İrtifa değişimi

    • Başta irtifa verisinde ne kadar gürültü olduğunu görmek amaçlandı
    • Genel aralık büyük olduğu için gürültüyü görmek zordu; alçalma bölümü çıkarıldıktan sonra irtifa dalgalanmasının yaklaşık 20-30 fit seviyesinde olduğu görüldü
    • Bu düzeydeki kararlılık beklenenden yüksekti, ancak normal aralık veya veri doğruluğu bilinmiyordu

  • ETA değişimi

    • ETA’nın makul ölçüde kararlı olması bekleniyordu; ilk kalkıştan sonra düzgün bir uçuşta gerçekten de kararlıydı
    • Hava durumu nedeniyle inişin geciktiği bir durumda ETA’nın yavaş yavaş mı uzayacağı, yoksa son kısımda keskin biçimde mi artacağı hâlâ bir soru

  • Yer hızı değişimi

    • Yer hızı da beklendiği gibi kararlıydı
    • Başta hız birimi MPH olarak gösterildi, ancak HN okurları bu değerin büyük olasılıkla knots olduğunu belirtti
    • Uçuşun başından itibaren veri toplanamadığı için, seyir hızına yaklaşma bölümündeki eğri görülemedi

Sonuç

  • Toplanan verilerde özellikle yararlı veya şaşırtıcı bir nokta yoktu
  • İnternet erişimi olmadan da uçak içi WiFi portalının açığa sunduğu uçuş durumu JSON’u kullanılarak uçuş sırasında veri toplanıp analiz edilebiliyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-29
Hacker News yorumları

  • Oğlum 9-10 yaşlarındayken uçakta telefonundan internet kullandığını gördüm; internet ücreti hiç ödemediğim için nasıl kullandığını sordum.
    Okuldan bir arkadaşının öğrettiğini, Wi-Fi ayarlarındaki DHCP tarafından atanmış IP adresi rakamlarını değiştirince olduğunu söyledi. O dönemde American Airlines yalnızca ücretli kullanıcıların IP’lerine izin veriyor gibiydi; biri 192.168 aralığındaki bir IP’yi tahmin edip kendini onun yerine koyarsa ek kimlik doğrulama olmadan bağlantıyı alabiliyordu.
    Yapmamasını söyledim ama denemeye cesaret etmesiyle biraz gurur duydum.

    • Eskiden ücretli Wi-Fi hotspot’larında benzerini sık sık yapardım.
      Önce nmap -sP ile tüm subnet’e ping sweep yapıp ARP önbelleğini işe yarar IP/MAC adresleriyle doldurur, sonra tek tek IP ve MAC adresini değiştirerek güvenlik duvarını aşan kombinasyonu bulurdum.
      Wayport’ta (şimdiki AT&T WiFi) NOC mühendisi olarak çalışmış olmam, yapıyı anlamama yardımcı olmuştu.
    • Aynı yöntemi uçaklarda ve otellerde kullandım; otellerde başarı oranı daha yüksekti.
      Çünkü başka birinin o anda kullanıyor olma ihtimali ve bağlantının kopma ihtimali daha düşüktü.
      Çocukken yaptığım başka küçük bir hack daha vardı: Havayollarının uçak içi filmler için özel kulaklık sattığı veya kiraladığı dönemde, port yan yana iki delikten, fiş de iki tüpten oluşuyordu.
      Uçağa binmeden önce terminaldeki fast food restoranından birkaç pipet, mümkünse bükülebilen pipet alıp birbirine ekleyerek uzun bir pipet yapar, bir ucunu porta takıp diğer ucunu kulağıma dayadığımda ücretsiz film sesini dinleyebiliyordum.
    • Birkaç yıl önce bir Southwest uçağında OpenVPN’i kapatmayı unutmuştum; ücret ödemeden de tünel üzerinden internete erişebildim.
      O dönemde ödeme yapmamış kullanıcılar için yalnızca yaygın portları (80, 443, 53 vb.) engelliyorlar gibiydi; daha sonra bu açık kapatıldı.
    • Gerçekten şaşırtıcı bir anekdot.
      Açık Wi-Fi güvenliği durumu aslında epey üzücü ve havayollarının bundan daha iyi bir şeyi kolayca nasıl yapabileceğini de pek bilmiyorum.
      Cihaz destekliyorsa Opportunistic Wireless Encryption [1] kullanıp kimlik doğrulamayı belirli bir MAC adresine değil belirli bir OWE oturumuna bağlamak mümkün olabilir; ama OWE oturumunun ne kadar kararlı olduğunu bilmiyorum.
      Erişim noktası her değiştiğinde yeniden giriş yapmak gerekirse bu çok rahatsız edici olurdu.
      Ücretli Wi-Fi ya da ücretsiz Wi-Fi güvenliğinin hâlâ çözülmüş bir sorun olmaması üzücü; ödeme, 3DS, parola sıfırlama e-postası gibi seçili trafiği geçirmek zorunda olan kırılgan captive portal’lar gibi özel geçici çözümlere hâlâ ihtiyaç var.
      İstemcinin o anda bağlı mı, sınırlı mı, ödeme/kimlik doğrulama mı gerekiyor anlayabileceği standart bir endpoint ve API olsa da iyi olurdu; ayrıca bir kimlik doğrulama token’ı alıp aynı oturumda doğal biçimde yeniden bağlanabilse güzel olurdu.
      Hotspot 2.0 ve WPA-EAP (WPA Enterprise) var, ancak bunlar sırasıyla operatörlerin işlettiği hotspot ağlarına ve kurumsal ortamlara daha uygun; “web portalı üzerinden ödeme” kullanımı için pek örtüşmüyorlar.
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • Eskiden, zaten internete bağlı olan ağdaki IP ve MAC adreslerini tarayan uygulamalar vardı.
      Ayarı bunlardan birinin MAC adresine değiştirirseniz, asıl kullanıcı işi bittikten sonra o bağlantıyı tek başınıza kullanabiliyordunuz.
      İş seyahatlerinde Wi-Fi ücreti ödemeyi reddederdim; havaalanları ve kafelerin hâlâ ücretli erişim aldığı zamanlarda epey işe yarıyordu.
      Artık neredeyse gerek kalmadı, ama hâlâ bağlantı ücreti olan yerlerde yardımcı olabilir.

  • “Bu verilere göre uçağın irtifası yalnızca 20–30 feet kadar dalgalanmış. Beklediğimden daha stabil!”
    Otopilotlar çok başarılıdır ve barometrik irtifayı temel alarak servo kontrolü yapar.
    Modern uçaklardaki birçok barometrik irtifa enkoderi, örneğin transponder’ın SSR radarı veya ADS-B üzerinden raporladığı irtifayı sağlayan cihazlar, 25 feet kodlama çözünürlüğüne sahiptir.
    Burada görünenin de büyük olasılıkla o 25 feet çözünürlük olduğu söylenebilir; 10 feet çözünürlüklü enkoderler de var ama 25 feet çok yaygındır.

    • Yazıda geçen API’nin hangi sensör verilerini aldığını bilmiyorum ama çoğu yolcu uçağı algıladığı konumun doğruluğunu, hatta dikey konum/irtifa doğruluğunu da yayınlar.
      https://globe.adsbexchange.com/ haritasında bir uçağa tıklayıp soldaki kenar çubuğunu en alta kadar kaydırırsanız “Accuracy” bölümünü görebilirsiniz.
      ADS-B Exchange dikey konum doğruluğu olan Rc/v’yi göstermiyor, ancak diğer değerleri gösteriyor.
      Ayrıntılar için https://mode-s.org/decode/content/ads-b/7-uncertainty.html sayfasına bakın.
    • Küçük bir uçakta, dikkatli manuel uçuş sırasında 20–30 feet aralığı olağandışı değildir.
      Seyir sırasında bir yolcu uçağının elbette otopilot kullanacağını varsayarım.
      Eskiden uçuş takibi desteği alırken yaklaşık 100 feet alçalınca kontrolörün iyi olup olmadığımı sormasına ve bu kadar ayrıntılı izlediklerini görmeme şaşırmıştım.
      Su üzerindeki bölüme girmeden önce can yeleğini giymeyi unutmuştum; onu giyerken de henüz uçuş dersi almamış olan eşime kumandaları devretmiştim.
      Daha sonra eşim de lisans aldı ve hava trafik kontrol takibinin araya girecek kadar hassas olması ilginçti.
    • Telefonla irtifa dahil bir GPS izi kaydedip karşılaştırmak harika olurdu.
      Barometrik irtifa ile GPS farklı şeyler; ayrıca barometrik altimetreyi farklı bir AWOS referansına göre yeniden ayarlayınca farkın belirgin biçimde sıçrayıp sıçramadığını da merak ediyorum.
      Büyük uçaklarda nasıl yapıldığını bilmiyorum ama küçük uçaklarda altimetreyi yerel hava durumuna göre ayarlamak gerekir.
      Meteoroloji istasyonu kendi irtifasındaki basıncı ölçüp “deniz seviyesine göre düzeltilmiş” değeri telsizle bildirir; bu değer altimetreye girilerek yerel hava değişimlerine bağlı barometrik irtifa okumaları düzeltilir.
      Bir saat uçup aynı yere geri dönseniz bile altimetre ayarı birkaç milibar değişmiş olabilir.
    • RVSM ile bunun çok daha hassas hâle gelmiş olması muhtemel.
      Uçaklar arasındaki dikey ayırma standardı 2000 feet iken 2000’lerin başında 1000 feet’e düşürüldü.
    • Bazı durumlarda aşırı hassasiyetin tersine tehlikeli olabileceğini okumuştum.
      Örneğin bir pilot 3000 feet’e giderse tam olarak 3000 feet’te olur; başka bir pilot da çarpışma rotasında 3000 feet isterse çarpışma kesinleşebilir.
      İrtifa daha az hassas olsaydı bunun yakın geçiş olayı olarak kalma ihtimali daha yüksek olurdu.
      Çözümün muhtemelen yuvarlak sayılardan kaçınıp 2950 feet, 3050 feet gibi değerler kullanmak olduğunu hatırlıyorum.
      Ayrıntılarda yanılıyor olabilirim ama bu sorunun ciddi biçimde değerlendirildiğinden oldukça eminim.

  • Birkaç ay önce aynı şeyi keşfedip bu API’yi kullanan bir CLI uçuş takipçisi yaptım.
    Birkaç havayolunda denedim; hepsi aynı uçak içi internet sağlayıcısını kullandığı için neredeyse kusursuz çalıştı.
    [1]: https://github.com/NalinPlad/OuterFlightTracker

    • Harika.
      Benzer bir şey yapmak istiyordum ama uçuş sırasında internete bakmadan bir TUI yapacak kadar deneyimim yoktu.
      Yine de bunun zaten yapılmış olmasına sevindim.

  • Delta uçuşlarında aynı veriyi alma yöntemi şöyle

    $ 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"  
}

    İlginç bir parça da var

    $ 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
    • jq’nun string interpolation özelliğini kullanınca daha da basitleştirilebilir 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • Şu an uçaktayken bu URL’ye girdim ve gerçekten çalışıyor
      Wi-Fi portal arayüzünde de görülebilen bir bilgi ama JSON yığını olarak görmek ayrı bir his veriyor 
      {"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"}
      Mobilde olduğum için JSON biçimlendirmesini mazur görün
    • Temiz hava istiyorsak bir POST isteğiyle kapıyı açabilsek güzel olurdu
    • planeId ya da tailNumber yerine daha genel vehicleId kullanmayı seçmeleri ilginç
      Delta’nın operasyon ekipmanları arasında buna uyan API’ye sahip başka türler var mı merak ediyorum
      Başka iç sistemleri bilen birinin flightId üzerinden sistem yapısını ne kadar çıkarabileceğini de merak ediyorum
      Dışarıdan bakınca bilinen verilerden oluşturulmuş bileşik bir anahtardan fazlası değil gibi görünüyor ama yine de ilginç
    • "airspeed": null
      İnsanı huzursuzca pencereden dışarı baktırıyor

  • Ücretsiz iMessage ya da WhatsApp’a izin verilen bağlantıyı kullanarak rastgele veri gönderen bir proxy yapsa biri, görmek isterdim
    Eve bir WhatsApp relay’i kurup uçaktan mesaj alıp göndermek gibi
    En temel hâliyle, URL’yi evdeki WhatsApp’a gönderince evde web sayfasını yükleyip HTML’i WhatsApp yanıtı olarak geri göndererek render etmek mümkün olabilir
    Ne kadar şeyi çalıştırmanın mümkün olacağını merak ediyorum
    Görünüşe göre WhatsApp üzerinden TCP relay’i yapan biri zaten var, harika

    • https://github.com/aleixrodriala/wa-tunnel
    • Kullanım koşullarını okumadım ama sadece gerçek bir IP router koymak olmaz mı diye düşünüyorum
      Abonelik ücretini ödeyip Wi-Fi ağı da açarsınız
      Uçağın SSID’si “Foo” ise adını “Foo discounted” koyup captive portal’da gaziler, yaşlılar, çocuklar gibi çeşitli “indirimler” seçtirirsiniz
      Hangisi seçilirse seçilsin ödeme sayfasında 2 dolar alırsınız
      Hizmet maliyetini çıkardıktan sonra sonraki ziyaretçilere “tüm indirimler tükendi, Foo’yu kullanın” gösterirsiniz
      Böylece ben ücretsiz internet kullanırım, router/portal kullanıcıları da 2 dolarlık internet kullanmış olur
      Yukarı yönlü bant genişliği kesin berbat olacaktır, bu yüzden tüm verileri tek bağlantım üzerinden çoklamak da kolay olur
      RPi gibi bir cihaza koymak gerekir ama güvenlik kontrolünden geçmesi için müzik çalar gibi bitmiş bir ürün görünümünde olmalı; ayrıca masayı kaldırmak gerektiğinde ya da tuvalete gidince de çalışmaya devam edebilmeli
      Uçakta kötü niyetli Wi-Fi bağlantılarını kesen bir WIPS ya da WIDS bulunma olasılığı çok düşük görünüyor
      Zaten LAN partisi yasak değil, değil mi
    • 1-2 yıl önce Apple Private Relay’in ilk betası çıktıktan bir iki gün sonra uçağa bindim ve uçuş boyunca ücretsiz Wi-Fi kullanabildim
      Muhtemelen iMessage ya da push bildirimleri için izin listesine aldıkları hedefler buna kadar uzanıyordu
      Birkaç gün sonra dönüş uçuşundan önce çoktan kapatılmıştı
    • Aklıma “vay, harika”dan önce “ücretsiz mesajlaşma iyi bir avantaj ama suistimal edilirse kapatırlar” geliyor
      Sanırım hacker günlerim geride kaldı
    • Havayolu Wi-Fi’ının DNS trafiğini engellemediğini gördüğüm oldu
      Iodine(https://github.com/yarrick/iodine) gibi bir DNS tüneliyle de benzer bir şey yapmak büyük ihtimalle mümkün

  • Southwest aynı veriyi daha güzel bir ekranda gösteriyor
    Wi‑Fi ücreti ödemeseniz de uçuş takibi, mevcut irtifa, tahmini varış saati, haritadaki konum gibi pek çok bilgiyi görebiliyorsunuz
    Muhtemelen yazarın işleme programını yaptığı veriyle aynı veriyi kullanıyor; özünde ücretsiz ziyaret edilebilen bir site varmış gibi

    • Evet, tam olarak öyle
      Bu veriyi görselleştiren güzel bir durum sayfasını ücretsiz görebiliyorsunuz
      Yine de veriyi kazımamın iki nedeni vardı
      Birincisi, durum sayfası yalnızca mevcut değeri gösterdiği için tüm uçuş verisini görmek istedim
      İkincisi, eğlenceliydi
    • Yakın zamanda ABD’deki bir uçuşta, sanırım Alaska Airlines’tı, internet erişimi olmadan da Wi‑Fi üzerinden film ve TV programları izleyebileceğiniz bir yerel LAN kutusu vardı
    • “Portal sayfasını açmaya çalışınca neden bir sürü uçak verisi dönüyor?” merakı giderilmiş oldu

  • Bu yazının ruhu hoşuma gitti
    Yazar bu bilgiyi Git scraping ile de toplayabilirmiş gibi görünüyor
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • Pencereden fotoğraf çekip o JSON çıktısındaki GPS koordinatlarını görüntüye bağlayabileceğimi düşündüm
    Oldukça kullanışlı görünüyor

    • Kamera uygulamasında konum iznini açık tutarsanız koordinatlar görüntünün EXIF verisine girer
      ABD’de sivil GPS cihazlarının, ITAR askeri ürün ihracat kısıtlamaları nedeniyle 60.000 feet irtifanın ve 1.000 knot hızın üzerinde çalışması yasaktır

  • Uçak verisiyle ADS-B verisini karşılaştırmak isterseniz, bu özgün yazı yazarının uçuşu gibi görünüyor
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • ADS-B veri kaynağı ile bu API’nin veri kaynağının en azından aynı göstergelerden ve uçuş sistemlerinden hesaplanmış olma ihtimali var
    • Doğru uçuş bu
      İyi fikir; bunu düşünememiş olmam üzücü

  • İlginç bir hikâye
    Ama şu time biçimi kimsenin gözüne batmıyor mu
    Garip bir seçim gibi görünüyor; saat dilimi ofseti olan ISO 8601 gibi daha standart bir şey beklerdim
    "time": "Sun Sep 24 22:02:19 2023"

    • Ben de benzer hissettim
      Bu sistemi tasarlayan kişi, sunucuda zamanı uçuşun konumuna göre görünen yerelleştirilmiş bir gösterime dönüştürüp istemci tarafı mantık olmadan doğrudan web arayüzüne koymak istemiş gibi
    • ctime’ın kullandığı varsayılan biçime benziyor
      Alttaki backend hakkında bir ipucu olabilir
      https://cplusplus.com/reference/ctime/ctime/