Menjelajahi data WiFi tanpa internet di penerbangan Southwest

 (jamesbvaughan.com)
1 poin oleh GN⁺ 2023-09-29 | 1 komentar | Bagikan ke WhatsApp
  • Saat penerbangan langsung St. Louis-Oakland sepulang dari Strange Loop, pembayaran internet $8 gagal, lalu diperiksa data yang bisa diakses tanpa internet saat terhubung ke WiFi dalam pesawat
  • Dari permintaan jaringan di portal WiFi Southwest, ditemukan endpoint current.json yang berulang kali berhasil, dan respons ini tampak menjadi data dasar untuk halaman status penerbangan
  • Endpoint tersebut bisa dipanggil dengan curl tanpa cookie maupun header, dan mengembalikan ketinggian, koordinat, perkiraan waktu tiba, kecepatan darat, sisa jarak, progres penerbangan, status koneksi satelit, dan lainnya
  • Dengan data yang dikumpulkan, ketinggian, ETA, dan kecepatan darat divisualisasikan; selain saat fase turun, ketinggian hanya berfluktuasi sekitar 20~30 kaki
  • Meski bukan temuan yang terlalu praktis, hanya dengan JSON status penerbangan yang terekspos di portal WiFi dalam pesawat pun kita bisa mencoba mengumpulkan dan menganalisis data selama penerbangan

Eksplorasi WiFi dalam pesawat yang berawal dari kegagalan pembayaran

  • Dalam penerbangan langsung St. Louis-Oakland sepulang dari Strange Loop, sempat mencoba membeli akses internet $8 melalui portal WiFi dalam pesawat milik Southwest, tetapi tidak ada metode pembayaran yang diterima
  • Halaman web tidak menampilkan pesan kesalahan yang membantu, jadi permintaan yang gagal diperiksa lewat alat pengembang jaringan di browser
  • Sulit menemukan petunjuk dari permintaan yang gagal itu sendiri, tetapi permintaan current.json yang terus berhasil terlihat menonjol

Data status penerbangan yang dikembalikan current.json

  • Respons current.json tampak menjadi data yang menggerakkan halaman status penerbangan di portal WiFi dalam pesawat
  • Contoh respons mencakup nilai-nilai berikut
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: nilai yang tampaknya menunjukkan progres penerbangan
    • altVal: ketinggian saat ini
    • lat, lon: koordinat saat ini
    • dtzone: zona waktu tujuan
    • within_us: apakah penerbangan berada di dalam AS
    • etad: perkiraan waktu tiba di tujuan
    • gspdVal: kecepatan darat saat ini
    • ttgc: nilai yang tampaknya menunjukkan sisa waktu
    • dist_remain: sisa jarak
    • actime24: waktu saat ini dalam suatu zona waktu tertentu

Mereproduksi permintaan browser dengan curl

  • Dengan fitur “Copy as cURL” di browser, perintah untuk memanggil endpoint bisa didapat dengan cepat
  • Fitur ini tersedia di Firefox dan browser berbasis Chromium, dan berguna saat ingin mereproduksi permintaan yang dikirim browser beserta header yang sama
  • Hasil eksperimen menunjukkan cookie maupun header yang disertakan dalam permintaan tidak wajib, dan data bisa diambil hanya dengan pemanggilan curl sederhana seperti berikut
curl 'https://getconnected.southwestwifi.com/current.json'
  • Setelah itu dijalankan loop yang mengambil data setiap 30 detik dan menumpuknya ke file log
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

Pertanyaan yang masih tersisa dari field respons

  • Sebagian besar field cukup intuitif, tetapi ada beberapa nilai yang maknanya belum sepenuhnya jelas
    • perbedaan antara sat_commlink_portal.status dan satcomm_status.commlink
    • apakah pcent_flt_complete berbasis jarak atau berbasis estimasi waktu
    • seberapa besar altVal, etad, dan gspdVal berfluktuasi selama penerbangan
    • apa arti ac dalam actime24
  • actime24 tampaknya bukan waktu saat ini di posisi pesawat, melainkan waktu saat ini di tujuan, sehingga sulit menafsirkan ac sebagai “aircraft”

Visualisasi data yang dikumpulkan selama penerbangan

  • Dengan data yang dikumpulkan, divisualisasikan perubahan ketinggian, ETA, dan kecepatan darat

  • Perubahan ketinggian

    • Awalnya ingin memeriksa seberapa banyak noise pada data ketinggian
    • Karena rentang keseluruhan terlalu besar, noise sulit terlihat; setelah fase turun dihapus, variasi ketinggian tampak berada di kisaran 20~30 kaki
    • Tingkat kestabilan ini lebih tinggi dari perkiraan, tetapi tidak diketahui apakah itu masih dalam batas normal atau seberapa akurat datanya

  • Perubahan ETA

    • ETA diperkirakan akan cukup stabil, dan pada penerbangan mulus setelah keberangkatan awal memang terlihat stabil
    • Jika pendaratan tertunda karena cuaca, masih menjadi pertanyaan apakah ETA akan bertambah perlahan atau melonjak tajam di bagian akhir

  • Perubahan kecepatan darat

    • Kecepatan darat juga stabil sesuai perkiraan
    • Awalnya satuan kecepatan ditampilkan sebagai MPH, tetapi pembaca HN menunjukkan bahwa nilai ini kemungkinan besar adalah knots
    • Karena data tidak terkumpul sejak awal penerbangan, kurva saat mendekati kecepatan jelajah tidak bisa diamati

Kesimpulan

  • Tidak ada hal yang sangat berguna atau mengejutkan dari data yang dikumpulkan
  • Bahkan tanpa akses internet, kita tetap bisa mengumpulkan dan menganalisis data selama penerbangan menggunakan JSON status penerbangan yang terekspos di portal WiFi dalam pesawat

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-29
Komentar Hacker News

  • Ketika anak saya berusia sekitar 9–10 tahun, saya melihat dia memakai internet di ponselnya saat di pesawat. Karena saya tidak pernah membayar biaya internet, saya bertanya bagaimana dia bisa memakainya.
    Dia bilang teman sekolahnya memberi tahu bahwa cukup mengubah-ubah angka alamat IP yang dialokasikan DHCP di pengaturan Wi-Fi. Saat itu American Airlines tampaknya hanya mengizinkan IP pengguna berbayar, jadi kalau seseorang menebak IP di rentang 192.168 dan menyamar, koneksi bisa diambil tanpa autentikasi tambahan.
    Saya memang bilang jangan dilakukan, tapi diam-diam agak bangga dengan keberaniannya mencoba.

    • Dulu saya sering melakukan hal serupa di hotspot Wi-Fi berbayar.
      Pertama, dengan nmap -sP, saya melakukan ping sweep seluruh subnet untuk mengisi cache ARP dengan alamat IP/MAC yang bisa dipakai, lalu satu per satu mengganti alamat IP dan MAC untuk mencari kombinasi yang bisa melewati firewall.
      Pengalaman bekerja sebagai engineer NOC di Wayport (sekarang AT&T WiFi) membantu saya memahami arsitekturnya.
    • Saya memakai cara yang sama di pesawat dan hotel, dan tingkat keberhasilannya lebih tinggi di hotel.
      Alasannya, kecil kemungkinan orang lain sedang memakainya pada saat itu dan kecil pula kemungkinan koneksi terputus.
      Saat kecil saya juga melakukan peretasan kecil lain: pada masa maskapai menjual atau menyewakan earphone khusus untuk film di pesawat, port-nya berupa dua lubang berdampingan dan colokannya berupa dua tabung.
      Sebelum naik pesawat, saya mengambil beberapa sedotan dari gerai fast food di terminal—kalau bisa sedotan yang bisa ditekuk—lalu menyambungkannya menjadi sedotan panjang. Dengan memasukkan satu ujung ke port dan menempelkan ujung lainnya ke telinga, saya bisa mendengar audio film gratis.
    • Beberapa tahun lalu di pesawat Southwest, saya lupa mematikan OpenVPN, dan ternyata bisa mengakses internet lewat tunnel tanpa membayar.
      Sepertinya saat itu mereka hanya memblokir port umum (80, 443, 53, dan sebagainya) untuk pengguna yang belum membayar, dan kemudian celah itu ditutup.
    • Kisah yang benar-benar mengejutkan.
      Kondisi keamanan Wi-Fi terbuka sebenarnya cukup memprihatinkan, dan saya juga tidak tahu cara yang jauh lebih mudah bagi maskapai untuk memperbaikinya.
      Jika perangkat mendukungnya, mereka bisa memakai Opportunistic Wireless Encryption [1] dan mengikat autentikasi ke sesi OWE tertentu, bukan ke alamat MAC tertentu, tetapi saya tidak tahu seberapa stabil sesi OWE itu.
      Kalau harus login ulang setiap kali titik akses berubah, itu akan sangat merepotkan.
      Sayangnya, keamanan Wi-Fi berbayar maupun Wi-Fi gratis masih belum menjadi masalah yang benar-benar terselesaikan, sehingga solusi sementara kustom seperti captive portal yang rapuh—yang harus meloloskan trafik opsional seperti pembayaran, 3DS, dan email reset kata sandi—masih tetap diperlukan.
      Akan bagus juga jika ada endpoint dan API standar agar klien bisa mengetahui apakah saat ini terhubung, dibatasi, atau perlu pembayaran/autentikasi, serta bisa menerima token autentikasi agar dapat tersambung kembali secara natural dalam sesi yang sama.
      Hotspot 2.0 dan WPA-EAP (WPA Enterprise) memang ada, tetapi masing-masing lebih ditujukan untuk jaringan hotspot yang dioperasikan operator telekomunikasi dan lingkungan perusahaan, sehingga tidak terlalu cocok untuk skenario “bayar lewat portal web”.
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • Dulu ada aplikasi yang memindai alamat IP dan MAC pada jaringan yang sudah terhubung ke internet.
      Jika pengaturan diubah ke salah satu alamat MAC tersebut, setelah pengguna aslinya selesai, koneksi itu bisa dipakai sendiri.
      Saat sering bepergian untuk bisnis, saya menolak membayar biaya Wi-Fi, dan pada masa bandara serta kedai kopi masih mengenakan biaya untuk akses, ini cukup berguna.
      Sekarang hampir tidak diperlukan, tetapi di tempat yang masih mengenakan biaya akses, ini masih bisa membantu.

  • “Menurut data ini, ketinggian pesawat hanya berfluktuasi sekitar 20–30 kaki. Lebih stabil dari yang saya kira!”
    Autopilot sangat canggih dan melakukan kontrol servo berdasarkan ketinggian barometrik.
    Banyak encoder ketinggian barometrik pada pesawat modern, misalnya perangkat yang menggerakkan ketinggian yang dilaporkan transponder melalui radar SSR atau ADS-B, memiliki resolusi encoding 25 kaki.
    Yang terlihat di sini kemungkinan besar juga resolusi 25 kaki itu; ada juga encoder beresolusi 10 kaki, tetapi 25 kaki sangat umum.

    • Saya tidak tahu data sensor apa yang diterima API yang disebutkan di artikel, tetapi sebagian besar pesawat penumpang menyiarkan akurasi posisi yang terdeteksi, termasuk akurasi posisi vertikal/ketinggian.
      Jika Anda membuka peta https://globe.adsbexchange.com/, mengeklik pesawat, lalu menggulir sidebar kiri sampai paling bawah, Anda bisa melihat bagian “Accuracy”.
      ADS-B Exchange tidak menampilkan Rc/v, yaitu akurasi posisi vertikal, tetapi menampilkan nilai-nilai lainnya.
      Untuk detailnya, lihat https://mode-s.org/decode/content/ads-b/7-uncertainty.html.
    • Untuk pesawat kecil, rentang 20–30 kaki bukan hal yang tidak biasa saat diterbangkan manual dengan penuh perhatian.
      Saat jelajah, pesawat penumpang tentu saja kemungkinan memakai autopilot.
      Dulu, ketika saya sedang mendapat dukungan pelacakan penerbangan, saya turun sekitar 100 kaki dan petugas ATC bertanya apakah saya baik-baik saja; saya terkejut mereka memperhatikan sedetail itu.
      Situasinya waktu itu saya lupa memakai rompi pelampung sebelum segmen di atas air, dan saat memakainya saya menyerahkan kendali kepada istri saya, yang saat itu belum pernah mendapat pelajaran terbang.
      Belakangan istri saya juga mendapat lisensi, dan menarik bahwa pelacakan ATC cukup presisi sampai bisa ikut menyoroti hal seperti itu.
    • Akan keren kalau bisa merekam track GPS termasuk ketinggian dengan ponsel lalu membandingkannya.
      Tekanan barometrik dan GPS berbeda, dan saya juga penasaran apakah perbedaannya akan tampak melonjak jelas ketika altimeter barometrik disetel ulang dengan acuan AWOS yang berbeda.
      Saya tidak tahu bagaimana pesawat besar melakukannya, tetapi pada pesawat kecil altimeter harus disetel sesuai cuaca setempat.
      Stasiun cuaca mengukur tekanan udara pada ketinggiannya sendiri, lalu memberikan lewat radio nilai yang “dikoreksi ke permukaan laut”; nilai ini dimasukkan ke altimeter untuk mengoreksi pembacaan ketinggian barometrik terhadap perubahan cuaca setempat.
      Bahkan setelah terbang satu jam dan kembali ke tempat yang sama, setelan altimeter bisa berbeda beberapa milibar.
    • Dengan penerapan RVSM, sepertinya presisinya menjadi jauh lebih tinggi.
      Standar pemisahan vertikal antarpesawat dulunya 2000 kaki, tetapi pada awal 2000-an dikurangi menjadi 1000 kaki.
    • Saya pernah membaca bahwa dalam situasi tertentu, presisi yang berlebihan justru bisa berbahaya.
      Misalnya, jika seorang pilot menuju 3000 kaki, ia akan tepat berada di 3000 kaki; jika pilot lain di jalur tabrakan juga menginginkan 3000 kaki, tabrakan bisa menjadi pasti.
      Jika ketinggiannya kurang akurat, kemungkinan lebih besar itu hanya menjadi insiden nyaris tabrakan.
      Solusinya mungkin adalah menghindari angka bulat dan memakai angka seperti 2950 kaki atau 3050 kaki.
      Detailnya mungkin saja keliru, tetapi saya cukup yakin masalah ini pernah dikaji secara serius.

  • Beberapa bulan lalu saya menemukan hal yang sama dan membuat pelacak penerbangan CLI yang memakai API ini.
    Saya mencobanya di beberapa maskapai, dan karena semuanya memakai penyedia internet dalam pesawat yang sama, alat itu bekerja hampir sempurna.
    [1]: https://github.com/NalinPlad/OuterFlightTracker

    • Keren.
      Saya ingin membuat sesuatu yang mirip, tetapi pengalaman saya belum cukup untuk membuat TUI tanpa merujuk ke internet selama penerbangan.
      Tetap saja senang melihat ternyata sudah ada yang membuatnya.

  • Cara mendapatkan data yang sama di penerbangan Delta adalah seperti ini

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

    Ada juga potongan yang menarik

    $ 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
    • Dengan memakai fitur interpolasi string milik jq, ini bisa dibuat lebih sederhana 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • Saya baru saja membuka URL ini di dalam pesawat, dan memang benar-benar berfungsi
      Informasi ini juga bisa dilihat di UI portal Wi-Fi, tapi melihatnya sebagai gumpalan JSON memberikan kesan yang berbeda 
      {"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"}
      Mohon maklum format JSON-nya karena saya di ponsel
    • Kalau ingin udara segar, akan bagus kalau pintunya bisa dibuka dengan request POST
    • Pilihan memakai vehicleId yang lebih umum, alih-alih planeId atau tailNumber, terasa menarik
      Saya penasaran apakah ada jenis peralatan operasi Delta lain yang punya API yang cocok dengan ini
      Saya juga penasaran seberapa jauh orang yang tahu sistem internal lain bisa menebak struktur sistem dari flightId
      Sekilas sepertinya tidak lebih dari composite key yang dibuat dari data yang terlihat, tapi tetap menarik
    • "airspeed": null
      Membuat saya gelisah melihat ke luar jendela

  • Saya ingin melihat ada yang membuat proxy untuk mengirim data arbitrer lewat koneksi yang mengizinkan iMessage atau WhatsApp gratis
    Misalnya menyiapkan relay WhatsApp di rumah, lalu saling mengirim pesan dari pesawat
    Dalam bentuk paling dasar, sepertinya bisa saja mengirim URL ke WhatsApp di rumah, lalu mesin di rumah memuat halaman web dan mengirim HTML-nya kembali sebagai balasan WhatsApp untuk dirender
    Penasaran seberapa banyak hal yang bisa dibuat berjalan
    Sepertinya sudah ada orang yang membuat relay TCP lewat WhatsApp; keren

    • https://github.com/aleixrodriala/wa-tunnel
    • Saya belum membaca ketentuan layanannya, tapi rasanya kenapa tidak sekalian menaruh router IP sungguhan saja
      Bayar biaya langganan dan pancarkan juga jaringan Wi-Fi
      Kalau SSID pesawatnya “Foo”, beri nama “Foo discounted”, lalu di captive portal biarkan orang memilih berbagai “diskon” seperti veteran, lansia, anak-anak, dan sebagainya
      Apa pun yang dipilih, kenakan biaya 2 dolar di halaman pembayaran
      Setelah biaya layanan tertutup, tampilkan kepada pengunjung berikutnya bahwa “semua diskon sudah habis, silakan gunakan Foo”
      Dengan begitu saya memakai internet gratis, sementara pengguna router/portal memakai internet seharga 2 dolar
      Bandwidth uplink-nya pasti payah, jadi akan mudah juga memultipleks semua data ke satu koneksi milik saya
      Masukkan ke perangkat seperti RPi, tapi agar lolos pemeriksaan keamanan perangkat itu harus terlihat seperti produk jadi, misalnya pemutar musik, dan harus bisa terus berjalan saat meja harus dinaikkan atau saat pergi ke toilet
      Kemungkinan pesawat punya WIPS atau WIDS yang memutus koneksi Wi-Fi nakal tampaknya sangat kecil
      Lagi pula, LAN party memang tidak dilarang, kan
    • Satu atau dua tahun lalu, sehari-dua hari setelah beta pertama Apple Private Relay keluar, saya naik pesawat dan bisa memakai Wi-Fi gratis sepanjang penerbangan
      Mungkin karena daftar izin untuk iMessage atau push notification ikut mencakup itu
      Sebelum penerbangan pulang beberapa hari kemudian, celah itu sudah ditutup
    • Yang terlintas lebih dulu bukan “wah, keren”, melainkan “messaging gratis itu benefit yang bagus, tapi kalau disalahgunakan mereka akan menutupnya”
      Sepertinya masa-masa hacker saya sudah lewat
    • Saya pernah melihat Wi-Fi maskapai tidak memblokir traffic DNS
      Kemungkinan besar hal serupa juga bisa dilakukan dengan tunnel DNS seperti Iodine(https://github.com/yarrick/iodine)

  • Southwest menampilkan data yang sama dengan antarmuka yang lebih cantik
    Meski tidak membayar biaya Wi-Fi, Anda bisa melihat banyak informasi seperti pelacakan penerbangan, ketinggian saat ini, perkiraan waktu tiba, dan posisi di peta
    Sepertinya mereka memakai data yang sama dengan yang dipakai penulis untuk membuat program pemrosesnya; pada dasarnya ada satu situs yang bisa dikunjungi gratis

    • Benar, memang persis begitu
      Ada halaman status keren yang memvisualisasikan data ini dan bisa dilihat gratis
      Tetap saja, ada dua alasan saya melakukan scraping
      Pertama, halaman status hanya menampilkan nilai saat ini, jadi saya ingin melihat seluruh data penerbangan
      Kedua, karena menyenangkan
    • Pada penerbangan domestik AS baru-baru ini, sepertinya Alaska Airlines, ada kotak LAN lokal yang memungkinkan menonton film dan acara TV lewat Wi-Fi meski tanpa akses internet
    • Rasa penasaran seperti “kenapa saat mencoba membuka halaman portal malah ada banyak data pesawat yang kembali?” jadi terjawab

  • Saya suka semangat tulisan ini
    Penulis sepertinya juga bisa melakukan Git scraping untuk informasi ini
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • Saya terpikir bahwa foto dari jendela bisa diambil lalu koordinat GPS dari keluaran JSON itu dihubungkan ke gambar
    Kelihatannya cukup berguna

    • Jika izin lokasi diaktifkan di aplikasi kamera, koordinat akan masuk ke data EXIF gambar
      Perangkat GPS sipil AS dilarang beroperasi di atas 60.000 kaki dan di atas 1.000 knot karena pembatasan ekspor perlengkapan militer ITAR

  • Jika ingin membandingkan data pesawat dengan data ADS-B, ini tampaknya penerbangan milik penulis asli
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • Ada kemungkinan sumber data ADS-B dan sumber data API ini setidaknya dihitung dari instrumen dan sistem penerbangan yang sama
    • Itu penerbangan yang benar
      Ide bagus, sayang saya tidak kepikiran

  • Cerita yang menarik
    Tapi apakah tidak ada yang terganggu dengan format time itu?
    Terlihat seperti pilihan yang aneh; saya mengira akan memakai sesuatu yang lebih standar seperti ISO 8601 dengan offset zona waktu
    "time": "Sun Sep 24 22:02:19 2023"

    • Saya juga merasa mirip
      Sepertinya orang yang merancang sistem ini mengonversi waktu di server menjadi representasi terlokalisasi yang terlihat berdasarkan posisi penerbangan, lalu ingin langsung memasukkannya ke UI web tanpa logika di sisi klien
    • Tampaknya seperti format default yang dipakai ctime
      Bisa jadi petunjuk tentang backend yang mendasarinya
      https://cplusplus.com/reference/ctime/ctime/