Xem dữ liệu WiFi trên chuyến bay Southwest mà không cần Internet

 (jamesbvaughan.com)
1 điểm bởi GN⁺ 2023-09-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi chuyến bay thẳng St. Louis-Oakland trở về từ Strange Loop không thể thanh toán $8 cho Internet, tác giả đã kiểm tra những dữ liệu có thể truy cập mà không cần Internet trong khi vẫn kết nối với WiFi trên máy bay
  • Trong các yêu cầu mạng của cổng WiFi Southwest, tác giả phát hiện endpoint current.json liên tục trả về thành công, và có vẻ đây là dữ liệu nền cho trang trạng thái chuyến bay
  • Endpoint này có thể được gọi bằng curl ngay cả khi không có cookie hay header, và trả về độ cao, tọa độ, thời gian đến dự kiến, tốc độ bay theo mặt đất, quãng đường còn lại, tiến độ chuyến bay, trạng thái kết nối vệ tinh, v.v.
  • Từ dữ liệu thu thập được, tác giả trực quan hóa độ cao, ETA và tốc độ bay theo mặt đất; ngoại trừ giai đoạn hạ độ cao, độ cao chỉ dao động khoảng 20–30 feet
  • Dù không phải một phát hiện đặc biệt hữu ích, chỉ riêng JSON trạng thái chuyến bay mà cổng WiFi trên máy bay để lộ cũng đủ để thử thu thập và phân tích dữ liệu trong chuyến bay

Khám phá WiFi trên máy bay bắt đầu từ một lần thanh toán thất bại

  • Trên chuyến bay thẳng St. Louis-Oakland trở về từ Strange Loop, tác giả định mua quyền truy cập Internet giá $8 qua cổng WiFi trên máy bay của Southwest, nhưng không có phương thức thanh toán nào được chấp nhận
  • Trang web không hiển thị thông báo lỗi hữu ích, nên tác giả dùng công cụ phát triển mạng của trình duyệt để kiểm tra các yêu cầu bị lỗi
  • Bản thân yêu cầu thất bại không cho thấy nhiều manh mối, nhưng yêu cầu current.json liên tục thành công đã thu hút sự chú ý

Dữ liệu trạng thái chuyến bay mà current.json trả về

  • Phản hồi từ current.json có vẻ là dữ liệu dùng để vận hành trang trạng thái chuyến bay của cổng WiFi trên máy bay
  • Phản hồi mẫu bao gồm các giá trị sau
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: giá trị có vẻ là tiến độ chuyến bay
    • altVal: độ cao hiện tại
    • lat, lon: tọa độ hiện tại
    • dtzone: múi giờ của điểm đến
    • within_us: có phải chuyến bay nội địa Mỹ hay không
    • etad: thời gian dự kiến đến điểm đến
    • gspdVal: tốc độ bay theo mặt đất hiện tại
    • ttgc: giá trị có vẻ là thời gian còn lại
    • dist_remain: quãng đường còn lại
    • actime24: thời gian hiện tại ở một múi giờ nào đó

Tái hiện yêu cầu của trình duyệt bằng curl

  • Tính năng “Copy as cURL” của trình duyệt giúp lấy nhanh lệnh gọi endpoint
  • Tính năng này có trong Firefox và các trình duyệt dựa trên Chromium, và hữu ích khi cần tái hiện yêu cầu mà trình duyệt đã gửi cùng các header tương ứng
  • Thử nghiệm cho thấy cookie hay header đi kèm yêu cầu không phải là bắt buộc, và có thể lấy dữ liệu chỉ với lệnh curl đơn giản như sau
curl 'https://getconnected.southwestwifi.com/current.json'
  • Sau đó, tác giả chạy một vòng lặp để lấy dữ liệu mỗi 30 giây và ghi vào file log
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

Những câu hỏi còn bỏ ngỏ trong các trường phản hồi

  • Phần lớn các trường khá trực quan, nhưng vẫn có vài giá trị chưa rõ nghĩa hoàn toàn
    • Sự khác biệt giữa sat_commlink_portal.status và satcomm_status.commlink
    • pcent_flt_complete được tính theo quãng đường hay theo thời gian dự kiến
    • altVal, etad, gspdVal dao động ra sao trong suốt chuyến bay
    • ac trong actime24 có nghĩa là gì
  • actime24 trông giống thời gian hiện tại ở điểm đến hơn là thời gian hiện tại tại vị trí máy bay, nên khó diễn giải ac là “aircraft”

Trực quan hóa dữ liệu thu thập trong chuyến bay

  • Từ dữ liệu thu thập được, tác giả trực quan hóa biến động của độ cao, ETA và tốc độ bay theo mặt đất

  • Biến động độ cao

    • Ban đầu, mục tiêu là xem dữ liệu độ cao có nhiều nhiễu đến mức nào
    • Vì dải giá trị tổng thể quá lớn nên khó nhìn ra nhiễu; sau khi loại bỏ giai đoạn hạ độ cao, độ dao động chỉ còn khoảng 20–30 feet
    • Mức ổn định này cao hơn dự đoán, nhưng không rõ đó có phải phạm vi bình thường hay phản ánh độ chính xác của dữ liệu hay không

  • Biến động ETA

    • ETA được kỳ vọng là khá ổn định, và trong một chuyến bay êm sau giai đoạn cất cánh ban đầu thì thực tế cũng như vậy
    • Nếu việc hạ cánh bị trì hoãn do thời tiết, vẫn chưa rõ ETA sẽ tăng dần từ từ hay chỉ tăng mạnh ở cuối chặng

  • Biến động tốc độ bay theo mặt đất

    • Tốc độ bay theo mặt đất cũng ổn định đúng như dự đoán
    • Ban đầu tác giả hiển thị đơn vị tốc độ là MPH, nhưng độc giả HN chỉ ra rằng giá trị này nhiều khả năng là knots
    • Vì không thu thập dữ liệu từ rất sớm trong chuyến bay nên không thể thấy đường cong ở giai đoạn tăng dần tới tốc độ hành trình

Kết luận

  • Không có điều gì đặc biệt hữu ích hay đáng ngạc nhiên trong dữ liệu thu thập được
  • Ngay cả khi không có kết nối Internet, vẫn có thể dùng JSON trạng thái chuyến bay mà cổng WiFi trên máy bay để lộ để thu thập và phân tích dữ liệu trong chuyến bay

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-29
Ý kiến trên Hacker News

  • Khi con trai tôi khoảng 9–10 tuổi, tôi thấy nó dùng Internet trên điện thoại trong máy bay, nên hỏi nó dùng bằng cách nào vì tôi chưa từng trả tiền Internet
    Nó nói một bạn ở trường chỉ rằng chỉ cần đổi các con số trong địa chỉ IP được cấp qua DHCP ở phần cài đặt Wi‑Fi là được; có vẻ lúc đó American Airlines chỉ cho phép IP của người dùng trả phí, nên nếu ai đó đoán đúng IP trong dải 192.168 và giả mạo thì có thể dùng kết nối mà không cần xác thực thêm
    Tôi có bảo nó đừng làm nữa, nhưng cũng hơi tự hào vì nó dám thử

    • Trước đây tôi cũng thường làm tương tự ở các hotspot Wi‑Fi trả phí
      Đầu tiên dùng nmap -sP để ping sweep toàn bộ subnet, lấp đầy ARP cache bằng các cặp địa chỉ IP/MAC có thể dùng, rồi lần lượt đổi địa chỉ IP và MAC để tìm tổ hợp vượt qua được tường lửa
      Việc từng làm kỹ sư NOC tại Wayport (nay là AT&T WiFi) đã giúp tôi hiểu cấu trúc này
    • Tôi đã dùng cách đó trên máy bay và ở khách sạn, trong đó khách sạn có tỷ lệ thành công cao hơn
      Vì khả năng người khác đang dùng đúng lúc đó thấp hơn và khả năng bị ngắt cũng thấp hơn
      Hồi nhỏ tôi còn làm một trò hack nhỏ khác: thời các hãng hàng không bán hoặc cho thuê tai nghe đặc biệt để xem phim trên máy bay, cổng cắm gồm hai lỗ đặt cạnh nhau và phích cắm là hai ống
      Trước khi lên máy bay, tôi lấy vài cái ống hút ở cửa hàng đồ ăn nhanh trong nhà ga, tốt nhất là loại ống hút gập được, nối chúng lại thành một ống hút dài; cắm một đầu vào cổng và đặt đầu kia lên tai là có thể nghe âm thanh phim miễn phí
    • Vài năm trước trên một chuyến bay Southwest, tôi quên tắt OpenVPN và vẫn có thể truy cập Internet qua tunnel mà không trả phí
      Khi đó có vẻ họ chỉ chặn các cổng phổ biến (80, 443, 53, v.v.) đối với người dùng chưa thanh toán, và sau này lỗ hổng đó đã bị bịt
    • Một giai thoại thật sự đáng kinh ngạc
      Tình trạng bảo mật Wi‑Fi mở thực ra khá đáng tiếc, và tôi cũng không rõ hãng hàng không có cách nào dễ dàng hơn để làm tốt hơn nhiều hay không
      Nếu thiết bị hỗ trợ, có thể dùng Opportunistic Wireless Encryption [1] và gắn xác thực với một phiên OWE cụ thể thay vì một địa chỉ MAC cụ thể, nhưng tôi không biết phiên OWE ổn định đến mức nào
      Nếu mỗi lần đổi điểm truy cập đều phải đăng nhập lại thì sẽ rất bất tiện
      Thật tiếc là bảo mật Wi‑Fi trả phí hoặc Wi‑Fi miễn phí vẫn chưa phải là vấn đề đã được giải quyết, và vẫn cần các giải pháp tạm thời tùy biến như captive portal thiếu ổn định, vốn phải cho phép một số lưu lượng chọn lọc đi qua như thanh toán, 3DS, email đặt lại mật khẩu
      Sẽ tốt hơn nếu có endpoint và API chuẩn để client biết trạng thái hiện tại là đã kết nối, bị hạn chế, hay cần thanh toán/xác thực, cũng như có thể nhận token xác thực để tái kết nối tự nhiên trong cùng phiên
      Có Hotspot 2.0 và WPA-EAP (WPA Enterprise), nhưng chúng lần lượt phù hợp hơn với mạng hotspot do nhà mạng vận hành và môi trường doanh nghiệp, nên không thật sự khớp với trường hợp “trả tiền qua cổng web”
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • Trước đây từng có ứng dụng quét địa chỉ IP và MAC của các thiết bị trong mạng đã kết nối Internet
      Nếu đổi cài đặt sang một trong các địa chỉ MAC đó, sau khi người dùng ban đầu dùng xong, bạn có thể một mình dùng kết nối ấy
      Khi đi công tác tôi từng từ chối trả tiền Wi‑Fi, và vào thời sân bay với quán cà phê vẫn còn thu phí truy cập, cách này khá hữu ích
      Giờ thì hầu như không cần nữa, nhưng ở những nơi vẫn tính phí kết nối thì có thể vẫn có ích

  • “Theo dữ liệu này, độ cao của máy bay chỉ dao động khoảng 20–30 foot. Ổn định hơn tôi tưởng!”
    Hệ thống lái tự động rất tốt và điều khiển servo dựa trên độ cao khí áp
    Nhiều bộ mã hóa độ cao khí áp trên máy bay hiện đại, ví dụ các thiết bị cung cấp độ cao mà transponder báo cáo qua radar SSR hoặc ADS-B, có độ phân giải mã hóa 25 foot
    Khả năng cao những gì thấy ở đây cũng là độ phân giải 25 foot đó; cũng có bộ mã hóa độ phân giải 10 foot, nhưng 25 foot rất phổ biến

    • Tôi không biết API trong bài nhận dữ liệu từ cảm biến nào, nhưng hầu hết máy bay chở khách đều phát cả độ chính xác của vị trí được xác định, cũng như độ chính xác vị trí/độ cao theo phương thẳng đứng
      Trên bản đồ https://globe.adsbexchange.com/, nhấp vào máy bay rồi kéo thanh bên trái xuống tận cuối sẽ thấy mục “Accuracy”
      ADS-B Exchange không hiển thị Rc/v, tức độ chính xác vị trí thẳng đứng, nhưng có hiển thị các giá trị khác
      Xem thêm chi tiết tại https://mode-s.org/decode/content/ads-b/7-uncertainty.html
    • Với máy bay nhỏ, khi bay tay và chú ý điều khiển thì phạm vi 20–30 foot không phải bất thường
      Khi bay hành trình, máy bay chở khách tất nhiên có lẽ sẽ dùng lái tự động
      Trước đây, khi đang được hỗ trợ theo dõi chuyến bay, tôi tụt xuống khoảng 100 foot thì kiểm soát viên hỏi tôi có ổn không, và tôi ngạc nhiên vì họ theo dõi chi tiết đến vậy
      Khi đó trước đoạn bay trên mặt nước tôi quên mặc áo phao, và trong lúc mặc thì giao cần lái cho vợ, người lúc ấy chưa từng học bay
      Sau này vợ tôi cũng lấy bằng, và tôi thấy thú vị khi việc theo dõi của kiểm soát không lưu đủ chính xác để can thiệp như vậy
    • Nếu ghi lại track GPS bằng điện thoại, bao gồm cả độ cao, rồi so sánh thì hẳn sẽ rất hay
      Khí áp và GPS khác nhau, và tôi cũng tò mò liệu khi đặt lại đồng hồ đo độ cao khí áp theo một chuẩn AWOS khác thì chênh lệch có nhảy rõ rệt hay không
      Tôi không biết máy bay lớn làm thế nào, nhưng với máy bay nhỏ thì phải đặt đồng hồ đo độ cao theo thời tiết địa phương
      Trạm khí tượng đo áp suất tại độ cao của mình, “hiệu chỉnh về mực nước biển” rồi báo qua vô tuyến; phi công nhập giá trị đó vào đồng hồ đo độ cao để hiệu chỉnh số đọc độ cao khí áp theo biến đổi thời tiết địa phương
      Bay một giờ rồi quay lại cùng một nơi, thiết lập đồng hồ đo độ cao cũng có thể đã khác đi vài millibar
    • Việc áp dụng RVSM có lẽ đã khiến mọi thứ chính xác hơn nhiều
      Tiêu chuẩn phân cách dọc giữa các máy bay từng là 2000 foot, nhưng đã giảm xuống 1000 foot vào đầu thập niên 2000
    • Tôi từng đọc rằng trong một số tình huống, độ chính xác quá cao lại có thể nguy hiểm
      Ví dụ nếu một phi công bay ở 3000 foot thì sẽ đúng chính xác 3000 foot, và nếu một phi công khác trên đường va chạm cũng muốn 3000 foot thì va chạm sẽ trở thành chắc chắn
      Nếu độ cao kém chính xác hơn, khả năng cao hơn là chỉ thành một vụ suýt va chạm
      Giải pháp có lẽ là tránh các số tròn và dùng những mức như 2950 foot, 3050 foot
      Chi tiết có thể tôi nhớ sai, nhưng tôi khá chắc rằng vấn đề này đã được xem xét nghiêm túc

  • Vài tháng trước tôi cũng phát hiện ra điều tương tự và đã làm một trình theo dõi chuyến bay CLI dùng API này
    Tôi đã thử với vài hãng hàng không, và vì tất cả đều dùng cùng một nhà cung cấp Internet trên máy bay nên nó hoạt động gần như hoàn hảo
    [1]: https://github.com/NalinPlad/OuterFlightTracker

    • Hay quá
      Tôi cũng từng muốn làm thứ tương tự, nhưng không đủ kinh nghiệm để tạo TUI khi đang bay mà không tra cứu Internet
      Dù vậy, tôi rất vui vì đã có người làm sẵn

  • Cách lấy cùng dữ liệu trên chuyến bay Delta là như sau

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

    Cũng có một mẩu thú vị

    $ 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
    • Nếu dùng tính năng nội suy chuỗi của jq thì có thể làm đơn giản hơn 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • Vừa thử vào URL này ngay trên máy bay và nó thực sự hoạt động
      Đây là thông tin cũng có thể xem trong UI cổng Wi-Fi, nhưng nhìn dưới dạng một cục JSON lại có cảm giác khác 
      {"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"}
      Đang dùng di động nên mong thông cảm cho định dạng JSON
    • Nếu muốn hít không khí trong lành thì giá mà có thể mở cửa bằng một yêu cầu POST
    • Lựa chọn dùng vehicleId chung hơn thay vì planeId hay tailNumber khá thú vị
      Không biết trong thiết bị vận hành của Delta có loại nào khác có API khớp như thế này không
      Cũng tò mò không biết người biết các hệ thống nội bộ khác có thể suy luận được bao nhiêu về cấu trúc hệ thống từ flightId
      Nhìn bề ngoài thì có vẻ không hơn gì một khóa ghép tạo từ dữ liệu có thể biết được, nhưng dù sao vẫn thú vị
    • "airspeed": null
      Khiến tôi bất an nhìn ra ngoài cửa sổ

  • Muốn thấy ai đó làm một proxy để gửi dữ liệu tùy ý bằng kết nối cho phép iMessage hoặc WhatsApp miễn phí
    Kiểu như dựng một relay WhatsApp ở nhà rồi gửi nhận tin nhắn từ trên máy bay
    Ở mức cơ bản nhất, có lẽ có thể gửi URL tới WhatsApp ở nhà, máy ở nhà tải trang web rồi gửi HTML lại bằng tin nhắn WhatsApp để render
    Tò mò không biết có thể làm chạy được đến mức nào
    Có vẻ đã có người làm TCP relay qua WhatsApp rồi, khá hay

    • https://github.com/aleixrodriala/wa-tunnel
    • Chưa đọc điều khoản sử dụng, nhưng tôi nghĩ liệu có thể cứ đặt một IP router thật sự không
      Trả phí đăng ký và cũng phát một mạng Wi-Fi
      Nếu SSID trên máy bay là “Foo” thì đặt tên là “Foo discounted”, rồi trong captive portal cho chọn nhiều loại “giảm giá” như cựu chiến binh, người cao tuổi, trẻ em
      Chọn cái nào thì ở trang thanh toán cũng thu 2 đô la
      Khi đã thu hồi chi phí dịch vụ, hiển thị cho khách truy cập sau đó rằng “mọi ưu đãi đã hết, hãy dùng Foo”
      Như vậy tôi dùng Internet miễn phí, còn người dùng router/portal thì dùng Internet giá 2 đô la
      Băng thông upstream chắc chắn sẽ tệ, nên việc multiplex toàn bộ dữ liệu qua một kết nối của tôi cũng sẽ dễ
      Đưa vào một thiết bị như RPi, nhưng để qua được kiểm tra an ninh thì nó phải trông như một sản phẩm hoàn chỉnh, kiểu máy nghe nhạc, và phải tiếp tục hoạt động khi phải dựng bàn lên hoặc đi vệ sinh
      Khả năng trên máy bay có WIPS hay WIDS để ngắt các kết nối Wi-Fi giả mạo trông rất thấp
      Mà ngay từ đầu đâu phải LAN party bị cấm đâu nhỉ
    • Khoảng 1–2 năm trước, một hai ngày sau khi bản beta đầu tiên của Apple Private Relay ra mắt, tôi đi máy bay và đã dùng được Wi-Fi miễn phí suốt chuyến bay
      Có lẽ vì danh sách cho phép dành cho iMessage hoặc thông báo push đã bao gồm cả thứ đó
      Trước chuyến bay về vài ngày sau thì nó đã bị chặn rồi
    • Điều đầu tiên tôi nghĩ không phải là “ồ, hay quá” mà là “nhắn tin miễn phí là một quyền lợi tốt, nhưng nếu bị lạm dụng thì họ sẽ đóng lại mất”
      Có vẻ thời hacker của tôi đã qua rồi
    • Tôi từng thấy Wi-Fi hàng không không chặn lưu lượng DNS
      Rất có khả năng cũng có thể làm điều tương tự bằng DNS tunnel như Iodine(https://github.com/yarrick/iodine)

  • Southwest hiển thị cùng dữ liệu đó trên một màn hình đẹp hơn
    Ngay cả khi không trả phí Wi-Fi, vẫn có thể xem rất nhiều thông tin như theo dõi chuyến bay, độ cao hiện tại, thời gian dự kiến đến nơi, vị trí trên bản đồ, v.v.
    Có lẽ họ dùng cùng dữ liệu với dữ liệu mà tác giả đã tạo chương trình xử lý, về bản chất giống như có một trang web có thể truy cập miễn phí

    • Đúng, chính xác là như vậy
      Có thể xem miễn phí một trang trạng thái đẹp giúp trực quan hóa dữ liệu này
      Dù vậy, có hai lý do khiến tôi vẫn scrape dữ liệu
      Thứ nhất, trang trạng thái chỉ hiển thị giá trị hiện tại nên tôi muốn xem toàn bộ dữ liệu chuyến bay
      Thứ hai, vì nó thú vị
    • Trên một chuyến bay nội địa Mỹ gần đây, hình như là Alaska Airlines, có một hộp LAN cục bộ cho phép xem phim và chương trình TV qua Wi-Fi ngay cả khi không có kết nối Internet
    • Thắc mắc “tại sao khi cố mở trang portal lại trả về cả đống dữ liệu máy bay?” đã được giải đáp

  • Rất thích tinh thần của bài viết này
    Tác giả có lẽ cũng đã có thể scrape bằng Git thông tin này
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • Tôi nghĩ có thể chụp ảnh ngoài cửa sổ rồi liên kết tọa độ GPS trong output JSON đó với ảnh
    Trông khá hữu ích

    • Nếu bật quyền vị trí cho ứng dụng camera, tọa độ sẽ được đưa vào dữ liệu EXIF của ảnh
      Thiết bị GPS dân dụng của Mỹ bị cấm hoạt động ở độ cao trên 60.000 feet so với mực nước biển và tốc độ trên 1.000 knot do hạn chế xuất khẩu quân dụng ITAR

  • Nếu muốn so sánh dữ liệu máy bay với dữ liệu ADS-B, có vẻ đây là chuyến bay của tác giả bài gốc
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • Nguồn dữ liệu ADS-B và nguồn dữ liệu của API này ít nhất có khả năng được tính toán từ cùng thiết bị đo và hệ thống bay
    • Đúng là chuyến bay đó
      Ý tưởng hay, tiếc là tôi đã không nghĩ ra

  • Câu chuyện thú vị
    Nhưng không ai thấy khó chịu với định dạng time đó sao
    Trông như một lựa chọn kỳ lạ, tôi đã mong đợi thứ gì đó chuẩn hơn như ISO 8601 có offset múi giờ
    "time": "Sun Sep 24 22:02:19 2023"

    • Tôi cũng cảm thấy tương tự
      Có vẻ người thiết kế hệ thống này đã chuyển đổi thời gian trên server thành biểu diễn đã bản địa hóa theo vị trí chuyến bay, rồi định đưa thẳng vào web UI mà không cần logic phía client
    • Trông giống định dạng mặc định mà ctime dùng
      Có thể là manh mối về backend nền tảng
      https://cplusplus.com/reference/ctime/ctime/