1 Prologue

A while ago, I took a flight from Canada back to Hong Kong - about 12 hours in total with Air Canada.

Interestingly, the plane actually had WiFi:

However, the WiFi had restrictions. For Aeroplan members who hadn’t paid, it only offered Free Texting, meaning you could only use messaging apps like WhatsApp, Snapchat, and WeChat to send text messages, but couldn’t access other websites.

If you wanted unlimited access to other websites, it would cost CAD $30.75:

And if you wanted to watch videos on the plane, that would be CAD $39:

I started wondering: for the Free Texting service, could I bypass the messaging app restriction and access other websites freely?

Essentially, could I enjoy the benefits of the $30.75 paid service without actually paying the fee? After all, with such a long journey ahead, I needed something interesting to pass the 12 hours.

Since I could use WeChat in flight, I could also call for help from the sky.

Coincidentally, my roommate happens to be a security and networking expert who was on vacation at home. When I mentioned this idea, he thought it sounded fun and immediately agreed to collaborate. So we started working on it together across the Pacific.

2 The Process

After selecting the only available WiFi network acwifi.com on the plane, just like other login-required WiFi networks, it popped up a webpage from acwifi.com asking me to verify my Aeroplan membership. Once verified, I could access the internet.

There’s a classic software development interview question: what happens after you type a URL into the browser and press enter?

For example, if you type https://acwifi.com and only focus on the network request part, the general process is: DNS query -> TCP connection -> TLS handshake -> HTTP request and response.

Let’s consider github.com as our target website we want to access. Now let’s see how we can break through the network restrictions and successfully access github.com.

3 Approach 1: Disguise Domain

Since acwifi.com is accessible but github.com is not, is it possible that the network has imposed restrictions on the DNS server, only resolving domain names within a whitelist (such as instant messaging domains)?

If this is the case, can I modify /etc/hosts to disguise my server as acwifi.com, so that all request traffic passes through my server before reaching the target website (github.com)? For example:

The general idea is that I modify the DNS record to bind our proxy server’s IP 137.184.231.87 to acwifi.com. Since the local /etc/hosts file takes precedence over the DNS server, I can then use a self-signed certificate to tell the browser that this IP is bound to this domain and that it should trust it.

Let me first test this idea:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

> ping 137.184.231.87
PING 137.184.231.87 (137.184.231.87): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
--- 137.184.231.87 ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss

Unexpectedly, the IP was completely unreachable via ping, meaning the IP was likely blocked entirely.

I tried other well-known IPs, like Cloudflare’s CDN IP, and they were also unreachable:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

> ping 172.67.133.121
PING 172.67.133.121 (172.67.133.121): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
--- 172.67.133.121 ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss

It seems this approach won’t work. This approach might only work if:

  • The DNS server only answers queries for a specific list of domain names (e.g., WhatsApp, Snapchat, WeChat), which means the firewall’s filtering mechanism was solely based on DNS resolution.
  • The network allows connections to arbitrary IP addresses

After all, if the IPs are directly blocked, no amount of disguise will help. This network likely maintains some IP whitelist (such as WhatsApp and WeChat’s egress IPs), and only IPs on the whitelist can be accessed.

If a ping to a specific IP times out, I wouldn’t say the IP is blocked. It could be that ICMP specifically is blocked, following some network rules on the firewall. This is pretty common in entreprise networks to not allow endpoint discovery. I could be missing something and happy to be corrected here, but I was surprised to read that. – HackerNews top comment

https://news.ycombinator.com/item?id=45536325

Actually, I did verified whether only ICMP was blocked, was it possible to create a connection through TLS:

1
2
3
4
5
6
7
8

> curl -Lkv https://172.67.133.121
*   Trying 172.67.133.121:443...
* Connected to 172.67.133.121 (172.67.133.121) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 172.67.133.121:443
* Closing connection
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 172.67.133.121:443

However, it turned out that both ICMP and TLS were blocked

4 Approach 2: DNS Port Masquerading

When the first approach failed, my roommate suggested a second approach: try using DNS service as a breakthrough:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

> dig http418.org

; <<>> DiG 9.10.6 <<>> http418.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64160
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;http418.org.			IN	A

;; ANSWER SECTION:
http418.org.		300	IN	A	172.67.133.121
http418.org.		300	IN	A	104.21.5.131

;; Query time: 3288 msec
;; SERVER: 172.19.207.1#53(172.19.207.1)
;; WHEN: Sat Oct 04 14:18:24 PDT 2025
;; MSG SIZE  rcvd: 94

This is good news! It means there are still ways to reach external networks, and DNS is one of them.

Looking at the record above, it shows our DNS query for http418.org was successful, meaning DNS requests work.

4.1 Arbitrary DNS Servers

My roommate then randomly picked another DNS server to see if the network had a whitelist for DNS servers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

> dig @40.115.144.198 http418.org

; <<>> DiG 9.10.6 <<>> @40.115.144.198 http418.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58958
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1224
;; QUESTION SECTION:
;http418.org.			IN	A

;; ANSWER SECTION:
http418.org.		275	IN	A	104.21.5.131
http418.org.		275	IN	A	172.67.133.121

;; Query time: 1169 msec
;; SERVER: 40.115.144.198#53(40.115.144.198)
;; WHEN: Sat Oct 04 14:24:25 PDT 2025
;; MSG SIZE  rcvd: 72

We can actually use arbitrary DNS servers - even better!

4.2 TCP Queries

The fact that arbitrary DNS servers can be queried successfully is excellent news. DNS typically uses UDP protocol, but would TCP-based DNS requests be blocked?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

> dig @40.115.144.198 http418.org +tcp

; <<>> DiG 9.10.6 <<>> @40.115.144.198 http418.org +tcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30355
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1224
;; QUESTION SECTION:
;http418.org.			IN	A

;; ANSWER SECTION:
http418.org.		36	IN	A	172.67.133.121
http418.org.		36	IN	A	104.21.5.131

;; Query time: 4679 msec
;; SERVER: 40.115.144.198#53(40.115.144.198)
;; WHEN: Sat Oct 04 14:28:24 PDT 2025
;; MSG SIZE  rcvd: 72

DNS TCP queries also work! This indicates the plane network’s filtering policy is relatively lenient, standing a chance of our subsequent DNS tunneling approach.

4.3 Proxy Service on Port 53

It seems the plane network restrictions aren’t completely airtight - we’ve found a “backdoor” in this wall.

So we had a clever idea: since the plane gateway doesn’t block DNS requests, theoretically we could disguise our proxy server as a DNS server, expose port 53 for DNS service, route all requests through the proxy server disguised as DNS requests, and thus bypass the restrictions.

My roommate spent about an hour setting up a proxy server exposing port 53 using xray 1, and sent me the configuration via WeChat:

The proxy server configuration my roommate set up with Xray included the following sample configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "our-proxy-server-domain",
            "port": 53,
            "users": [
              {
                "id": "some-uuid",
                "flow": "xtls-rprx-vision",
                "encryption": "none",
                "level": 0
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "allowInsecure": false,
          "allowInsecureCiphers": false,
          "alpn": [
            "h2"
          ]
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

And I already had an xray client on my computer, so no additional software was needed to establish the connection.

Everything was ready. The exciting moment arrived - pressing enter to access github.com:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

/Users/ramsayleung [ramsayleung@ramsayleungs-Laptop] [18:28]
> curl -v github.com -x socks5://127.0.0.1:10810
*   Trying 127.0.0.1:10810...
* Connected to 127.0.0.1 (127.0.0.1) port 10810
* SOCKS5 connect to 172.19.1.1:80 (locally resolved)
* SOCKS5 request granted.
* Connected to 127.0.0.1 (127.0.0.1) port 10810
> GET / HTTP/1.1
> Host: github.com
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-Length: 0
< Location: https://github.com/
<
* Connection #0 to host 127.0.0.1 left intact

/Users/ramsayleung [ramsayleung@ramsayleungs-Laptop] [18:28]
> curl -v github.com -x socks5://127.0.0.1:10810
*   Trying 127.0.0.1:10810...
* Connected to 127.0.0.1 (127.0.0.1) port 10810
* SOCKS5 connect to 172.19.1.1:80 (locally resolved)
* SOCKS5 request granted.
* Connected to 127.0.0.1 (127.0.0.1) port 10810
> GET / HTTP/1.1
> Host: github.com
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-Length: 0
< Location: https://github.com/
<
* Connection #0 to host 127.0.0.1 left intact

The request actually succeeded! github.com returned a successful result!

This means we’ve truly broken through the network restrictions and can access any website!

We hadn’t realized before that xray could be used in this clever way :)

Here we exploited a simple cognitive bias: not all services using port 53 are DNS query requests.

5 Ultimate Approach: DNS Tunnel

If Approach 2 still didn’t work, we had one final trick up our sleeves.

Currently, the gateway only checks whether the port is 53 to determine if it’s a DNS request. But if the gateway were stricter and inspected the content of DNS request packets, it would discover that our requests are “disguised” as DNS queries rather than genuine DNS queries:

Since disguised DNS requests would be blocked, we could embed all requests inside genuine DNS request packets, making them DNS TXT queries. We’d genuinely be querying DNS, just with some extra content inside:

However, this ultimate approach requires a DNS Tunnel client to encapsulate all requests(for example: https://github.com/yarrick/iodine). Unfortunately, I didn’t have such software on my computer while I was on board, so this remained a theoretical ultimate solution that couldn’t be practically verified.

6 Conclusion

With the long journey ahead, my roommate and I spent about 4 hours remotely breaking through the network restrictions, having great fun in the process, proving that our problem-solving approach was indeed feasible.

The successful implementation of the solution was mainly thanks to my roommate, the networking expert, who provided remote technical and conceptual support.

The only downside was that although we broke through the network restrictions and could access any website, the plane’s bandwidth was extremely limited, making web browsing quite painful. So I didn’t spend much time browsing the web.

For the remaining hours, I rewatched the classic 80s time-travel movie: "Back to the Future" , which was absolutely fantastic.

Last and not least, it’s the disclaimer:

This technical exploration is intended solely for educational and research purposes. We affirm our strict adherence to all relevant regulations and service terms throughout this project.

Discuss this post on HackerNews, or Reddit

7 Follow up: Can we bypass the speed limit?

There’s a speed limit. No matter what you try, you can’t break through it.

The bandwidth for free texting is the ultimate bottleneck. Even if you bypass the restrictions, without solving the bandwidth issue, you can’t use it like paid Wi-Fi 😭

This is a comment from a reader. Is this true?

Not exactly.

There are actually ways to bypass it. During communication on the network, there is no business marker indicating “paid user” attached. So, if I were designing this paid system, after a user pays, I would add the unique identifier of the paid user’s device, typically the MAC address, to the gateway’s whitelist. Then, all traffic from that MAC address could use the higher-bandwidth line.

Furthermore, because of this whitelist, even if free users bypass the free texting restrictions, they still cannot enjoy the higher bandwidth – killing two birds with one stone.

Once we guess this principle, I can “pretend to be a paid user.”

Since the MAC address is essentially assigned by the computer itself and then communicated to the gateway using the ARP protocol.

The ARP (Address Resolution Protocol) is used to resolve an IP address into its corresponding MAC address. The basic idea of the ARP protocol is to broadcast an ARP request within the network:

Gateway: Whose IP address is 192.168.1.100? Please tell me your MAC address. Device with that IP: I am 192.168.1.100, my MAC address is XX:XX:XX:XX:XX:XX.

The ARP protocol itself has no security verification mechanism – it unconditionally trusts the received ARP replies. I could also tell the gateway that my IP address corresponds to the MAC address of a user who has already paid. This way, all traffic coming from me would enjoy the benefits of the paid line. This is the so-called ARP Spoofing.

The final question is, how do we know which MAC address belongs to a paid user?

It’s quite easy, just brute-force: try every known MAC address in the network. If there is a paid user’s MAC address, requests from that MAC address should definitely be able to access sites like YouTube/Netflix. This can easily be automated and detected with a script.

My previous solution of disguising the DNS server would not affect the aircraft’s network in any way, nor would it intrude into any aircraft systems. It’s essentially the same as running a VPN on your computer that uses port 53.

However, this ARP Spoofing method is very “criminal” – as it constitutes unauthorized access to the plane’s network system. I’ll just share the idea here; I don’t want FBI or RCMP waiting for me at the gate when the airplane lands

  1. https://github.com/XTLS/Xray-core ↩︎