Show HN: Forensic evidence of iOS mesh networking bypassing Airplane Mode | Hacker News Reader

Show HN: Forensic evidence of iOS mesh networking bypassing Airplane Mode

github.com

I found evidence of autonomous mesh networking on iOS during Airplane Mode. What am I missing?

Did forensic analysis on my iPhone during Airplane Mode isolation. Kernel stats show 2,657 packets transmitted and 84.5MB processed through mDNSResponder while interfaces report "inactive". Found a parallel utun2 tunnel bound to IDS framework that persists during isolation. Applied Shannon-Hartley theorem to verify the channel capacity supports this volume. Either I'm misunderstanding legitimate system behavior, or this is a covert channel. Reproducible steps and raw evidence included.

https://github.com/JGoyd/NeuralNet

Open articleView on HN

Maybe the culprit is the technology and nasty tricks backing the "Find my device" feature? iOS devices will share their location (and potentially other data) with other nearby devices using a mesh network with certain frequency, even in Airplane mode. Also if the iPhone/iPad is powered off using the "power off" feature, the device will still be findable.

This capability is one of the strong selling points for consumers. The modern, average thief will often toss away these devices and settle with the rest of the loot because of this.

Sounds like OP wasn't aware of this.

I'm aware of "Find My Device" that's a documented feature. Find My beacons go OUT (your device tells others where it is). This is 84MB coming IN. Different thing.

Well, such traffic goes OUT somewhere and that somewhere is other iDevices so that's traffic coming IN for them, no? I don't have evidence supporting either possibility other than the fact that there's indeed an obscure mesh network involved for "Find My" to operate. I hope this is the starting point to figuring out what their infrastructure does.

The repo shows traffic is bound to utun2 (IDSNexusAgent). That’s not a location beacon protocol… that’s an encrypted IP tunnel

Yes, that is used to exchange information between iDevices. The "Find my" mechanism is proprietary and closed source, so you cannot categorically discard the possibility of iOS using such tunnel to send/receive/forward such information. Yes it could be something else. But if we want to be rigorous, we cannot discard possibilities we aren't 100% sure about.

You are right... and being rigorous is the only path to trust. We can shift the issue from "what is it" to "why isn't it documented and why does status report inactive.

84.5 MB through utun2/IDS during stated isolation—benign or not—contradicts "wireless features turned off" and users have no verification path.

The "closed source" problem you identified is the core issue. So to be rigorous, plausible deniability ends where the telemetry contradicts the UI.

I'm left wondering what this covert mesh traffic is actually accomplishing, and whether it's actually controversial or whether the researcher came across a red herring (Perhaps background file transfer such as airdrop while in airplane mode, unlikely as that sounds?).

Good catch! checked sharingd (PID 75) in spindump: <0.001s CPU time while mDNSResponder processed the 84MB. Traffic attribution rules out AirDrop. The 67:1 RX/TX asymmetry and idle sharing daemon confirm this isn't file transfer.

My guess would it has to do with find my iPhone and AirTag tracking features.

Not possible due to directionality and volume:

Find My/AirTag: Characteristic low-payload outbound beacons (Egress).

Observed Reality: 84.5 MB Ingress (Received) vs. 1.25 MB Egress.

verified on iPadOS 26.2 (Opkts: 5,132 while status: inactive). The data is not historical; the bypass is active.

https://github.com/JGoyd/NeuralNet/issues/1#issuecomment-370...

LOL. Seems like the OP is confused and misreading normal macOS/iOS behavior as a conspiracy.

Interface stats are cumulative since boot (eg: not real-time), mDNSResponder traffic includes all historical Bonjour activity. utun tunnels are standard iCloud/VPN infrastructure. Shannon-Hartley math proves WiFi can move data, not that anything covert is happening.

Mathematically invalidated by the temporal anchor in the artifacts.

The spindump captures a precise 2.00-second window (2025-12-31 13:35:14) where mDNSResponder (PID 10252) is in an active execution state with Priority 31 scheduling. Real-time thread activity and kernel buffer management do not occur for "historical" data.

Reply on news.ycombinator.com