Ian Beer's detailed blog post said he was unsure whether anyone else had been able to exploit this flaw - which was notified to Apple and patched some time ago - but pointed out that he had noticed a tweet from Australian security ace Mark Dowd about Apple having patched the flaw.

Dowd is the founder of Sydney-based Azimuth Security, a company that was acquired by US-based defence contractor L3 Intelligence in September 2018.

In February 2018, Dowd's firm was reported to be involved in playing a crucial role in helping spies and law enforcement break into smartphones and also supplying them with zero-day exploits.

Beer said he had spent six months to find the flaw and perfect his remote exploit. Despite the amount of difficulty and labour involved, he said the takeaway was not that someone could not do something similar because of the time and effort involved.

"The takeaway from this project should not be: no-one will spend six months of their life just to hack my phone, I'm fine," he wrote. "Instead, it should be: one person, working alone in their bedroom, was able to build a capability which would allow them to seriously compromise iPhone users they'd come into close contact with."

This demo shows the attacker successfully exploiting a victim iPhone 11 Pro device located in a different room through a closed door.

Beer said he had found the vulnerabilities after Apple shipped a beta build of iOS in which function name symbols were not stripped from the kernelcache.

He said he had been looking the cross-refeernces made by the debugger IDA to the function memmove.

Having function names made it possible to search even a binary blob that was more than 30MB to see how everything fitted together, Beer pointed out.

"What bits of code are exposed to attackers? What sanity checking is happening and where? What execution context are different parts of the code running in?" Beer asked.

"In this case, this particular driver is also available on MacOS, where function name symbols are not stripped."

The function name that attracted his attention was IO80211AWDLPeer::parseAwdlSyncTreeTLV. He had no idea what AWDL was at that point in time. "But I did know that TLVs (Type, Length, Value) are often used to give structure to data, and parsing a TLV might mean it's coming from somewhere untrusted," Beer said. "And the 80211 is a giveaway that this probably has something to do with Wi-Fi. Worth a closer look."

The second thing that stood out to him was the error message string: ""Peer %02X:%02X:%02X:%02X:%02X:%02X: PATH LENGTH error hc %u calc %u\n"

Beer also examined the control flow graph. "Reading the code a bit more closely it appears that although the log message contains the word 'error' there's nothing which is being treated as an error condition here. IO80211Peer::logDebug isn't a fatal logging API, it just logs the message string," he said.

"Tracing back the length value which is passed to memmove, regardless of which path is taken we still end up with what looks like an arbitrary u16 value from the input buffer (rounded down to the nearest multiple of 6) passed as the length argument to memmove.

"Can it really be this easy? Typically, in my experience, bugs this shallow in real attack surfaces tend to not work out. There's usually a length check somewhere far away; you'll spend a few days trying to work out why you can't seem to reach the code with a bad size until you find it and realise this was a CVE from a decade ago. Still, worth a try."

He described AWDL as being "an Apple-proprietary mesh networking protocol designed to allow Apple devices like iPhones, iPads, Macs and Apple Watches to form ad-hoc peer-to-peer mesh networks".

He then located a defect in the TLV data handling code, built an AWDL driver stack to create malicious packets, found out how to get these packets past safety checks in other locations, learnt how to turn the buffer overflow into heap corruption that was controllable, and testing his findings with 13 different Wi-Fi adaptors to discover a way to carry out a successful attack.

Beer wanted to convert his findings into a way of staging a zero-click attack where the victim merely had to be using their phone in order to be a target.

To do this, he had also to find a way whereby an attacker could pretend to be offering files to share via AirDrop and to make it possible to steal arbitrary files from the victim's device.

He has put up a video showing how the attack works, though summarising these complext findings into a short video is well nigh impossible.

Thanks to Sophos security guru Paul Ducklin whose breakdown of the massive write-up made my job of writing this up a lot easier.