Protocol Prying: Vulnerability Research in AirDrop and Quick Share

# Systematic Vulnerability Research in the Apple AirDrop and Android Quick Share Proximity Transfer Protocols
Source: [https://arxiv.org/html/2606.26967](https://arxiv.org/html/2606.26967)
###### Abstract

Apple AirDrop and Google/Samsung Quick Share are proximity file\-transfer protocols used by over five billion devices, yet their application\-layer security properties remain largely unstudied because both stacks are proprietary and undocumented\. Both protocols are reachable from wireless proximity without any prior pairing and process complex serialized content \(binary plists, CPIO archives, Protocol Buffers, UKEY2 handshakes\) inside privileged daemons, making them attractive zero\-click targets across multiple operating systems\. We perform the first cross\-platform reverse engineering and protocol\-aware fuzzing study of both stacks\. We reconstruct AirDrop’s seven\-layer state machine and DVZip adaptive compression from binary analysis, buildAirFuzz, a protocol\-aware fuzzer that mutates pre\-compression representations, and complement it with targeted hand\-written analyses of Samsung’s Quick Share service and Google’s Quick Share for Windows\. We discover six vulnerabilities \(V1\-V6\): three pre\-authentication issues inmacOS/iOSAirDrop \(V1: SwiftfatalErrorDoS in the HTTP path router; V2: unbounded XML plist recursion inFoundation, V3: NULL deref inNetwork\.framework’s HTTP/1\.1 parser\), two protocol\-layer flaws in Samsung Quick Share \(V4: pre\-authenticationOfflineFramedispatch, V5: D2D encryption bypass for three frame types\), and a heap use\-after\-free in Google Quick Share for Windows \(V6\) for which Google awarded a bounty\. We responsibly disclosed all findings, Apple, Samsung, and Google have acknowledged the reports\. For transparency and reproducibility, the AirFuzz artifacts are publicly available on Zenodo:[https://zenodo\.org/records/20442029](https://zenodo.org/records/20442029)\.

## 1Introduction

Proximity\-based file transfer is a fundamental feature of modern mobile and desktop operating systems\. Apple’s AirDrop, introduced in 2011, and Google’s Nearby Share \(now Quick Share\), launched in 2020, collectively serve over five billion active devices\[apple\-active\-devices,google\-android\-devices\]\. These protocols enable ad hoc peer\-to\-peer file transfer between nearby devices over a combination of Bluetooth Low Energy \(BLE\) for discovery and Wi\-Fi for data transfer, without requiring shared network infrastructure\.

From a security perspective, proximity transfer protocols present a compelling attack surface\[beer2020awdl,silvanovich2019zeroclick,gross2020remote,yair2024quickshell,toothpicker\]\. The attacker need only be within wireless range \(typically 10–30 m for AWDL/Wi\-FiDirect\), and the initial protocol phases \(service discovery and connection establishment\) require*no authentication*\. On Apple devices configured with “Everyone” visibility, the entire Discover and Ask phases are reachable without any user interaction or prior pairing\. This creates a zero\-click, pre\-authentication attack surface that extends from the privilegedsharingddaemon \(which also manages AirPlay, Handoff, Universal Clipboard, and Continuity Camera\) all the way down into the kernel: Beer’s iOS zero\-click radio\-proximity exploit\[beer2020awdl\]demonstrated remote code execution against the AWDL kernel driver itself, showing that the attack surface is not limited to user\-space sharing code\.

Despite the ubiquity and security relevance of these protocols, prior academic work has focused primarily on privacy aspects of AirDrop’s contact discovery mechanism\[heinrich2021opendrop,heinrich2021privatedrop,stute2021disrupting,martin2019handoff\]and the underlying AWDL link layer\. The foundational work of Stute et al\.\[stute2018billion,stute2019openwifi,stute2021disrupting\]reverse engineered AWDL itself, released the open\-source OWL stack, and demonstrated link\-layer denial\-of\-service and man\-in\-the\-middle attacks; their results provide the wireless substrate on which our application\-layer analysis builds\. In parallel, Project Zero\[beer2020awdl\]weaponised the AWDL kernel attack surface againstiOS\. A comprehensive security analysis of the*application\-layer*AirDrop protocol \(binary property lists, DVZip compression, CPIO archive extraction, and the HTTP\-layer state machine insharingd\) has not been published\. Similarly, while Google’s Quick Share has received attention following the SafeBreach RCE chain in its Windows client\[yair2024quickshell\], the Samsung Android implementation’s security properties remain largely unexamined\.

In this paper, we bridge this gap with a systematic security analysis of both Apple AirDrop and Android Quick Share\. Our work makes the following contributions:

1. 1\.Application\-layer reverse engineering of AirDrop\.Building on the AWDL link\-layer work of Stute et al\.\[stute2018billion,stute2019openwifi\], we reverse engineer the complete*application\-layer*AirDrop stack on currentmacOSandiOS, documenting seven protocol layers from AWDL up through DVZip/CPIO archive extraction\. We reconstruct the receiver\-side state machine ofsharingd, document the previously unpublished DVZip adaptive chunked compression format, and catalogue 40\+ protocol commands\. Detailed offsets, disassembly, and symbol lists for specific binary versions are released as artifacts rather than reproduced inline\.
2. 2\.Protocol\-Aware Fuzzer\.We developAirFuzz, a protocol\-aware fuzzer with nine mutation layers \(HTTP, binary plist, DVZip, CPIO, DER, havoc, memcorrupt, and field\-level\) and Frida\-based coverage collection\. We discuss why we did not use FridaStalker,fpicker\[fpicker,toothpicker\], orTinyInst/Jackalope\[tinyinst,jackalope,p0\-coreaudiod\]as our coverage engine; in particular, we reproduce the Stalker breakage on arm64emacOS/iOS\(Section[4](https://arxiv.org/html/2606.26967#S4)\)\.
3. 3\.AirDrop Vulnerabilities\.We discover two zero\-click, and one post\-accept pre\-authentication vulnerabilities: \(V1\) a remote DoS via SwiftfatalErrorin the HTTP path router, \(V2\) a stack overflow inFoundation’s XML property list parser and \(V3\) a NULL pointer dereference inNetwork\.framework\.
4. 4\.Quick Share Vulnerabilities\.We discover three vulnerabilities in Quick Share: \(V4\) a pre\-authentication frame processing bypass that allows unauthenticated protocol interaction before UKEY2 handshake completion, \(V5\) a device\-to\-device \(D2D\) encryption bypass where 3 out of 7 post\-handshake frame types are processed without the mandatorySecureMessageencryption wrapper in Samsung’s Android implementation, and \(V6\) a critical use\-after\-free via an endpoint collision race condition in Google Quick Share for Windows which leads to remote\-code\-execution \(version 1\.2\.2472\.1\)\.
5. 5\.Cross\-Platform Comparison\.We provide the first cross\-platform security comparison of Apple and Google/Samsung proximity transfer implementations, identifying shared vulnerability patterns and divergent design decisions across six total vulnerabilities spanning macOS, iOS, Android, and Windows\.

We responsibly disclosed all vulnerabilities to Apple Product Security, Samsung Mobile Security, and the Google Vulnerability Reward Program\. Apple acknowledged V1–V3 and remediation is in progress; Samsung transferred V4–V5 to Google; Google acknowledged V6 and awarded a bounty for the Windows Quick Share use\-after\-free, with a CVE pending assignment\. Section[7\.5](https://arxiv.org/html/2606.26967#S7.SS5)provides the full disclosure timeline and vendor responses\.

##### Vulnerability overview\.

Table[1](https://arxiv.org/html/2606.26967#S1.T1)summarises the six vulnerabilities, their target component, the precondition required to reach them, and the observed impact\. We use this table as a roadmap throughout the paper\.

Table 1:Overview of the six vulnerabilities \(V1–V6\)\.Precond\.: “Everyone” = AirDrop in “Everyone for 10 minutes” visibility; “Visible” = Quick Share visible to nearby devices; “On\-path” = same\-LAN attacker \(V5 only\); “Race” = concurrent connect/disconnect \(V6\)\.Impact: DoS = denial of service; PoP = protocol\-state manipulation; UAF = potentially exploitable use\-after\-free\.

## 2Background

### 2\.1Apple AirDrop

AirDrop, introduced in OS X Lion \(2011\) and iOS 7 \(2013\), enables peer\-to\-peer file transfer between Apple devices\. It relies on two wireless technologies:*Bluetooth Low Energy*\(BLE\) for initial device discovery and wake\-up, and*Apple Wireless Direct Link*\(AWDL\) for the actual data transfer\. AWDL is a proprietary Wi\-Fi\-based protocol that creates an ad\-hoc mesh network on theawdl0virtual interface using IPv6 link\-local addresses\[stute2018billion\]\.

The AirDrop application logic is implemented insharingd, a privileged daemon that manages multiple Apple continuity services\. On the receiver side,sharingdlistens on TCP port 8770 over AWDL with TLS, serving an HTTP/1\.1 API\. The daemon is managed bylaunchdand automatically restarts on crash, but with exponentially increasing throttle delays after consecutive failures\.

sharingdis a large, monolithic system daemon\. On iOS 18\.1/26\.3 \(ARM64e\), The binary has*stripped*only one exported symbols \(\_mainand\_\_mh\_execute\_header\) are visible via standard tools\. It dynamically loads the privateSharing\.framework\(3\.8 MB, 5,032 exported symbols\), which implements the core AirDrop protocol logic, and links against approximately 30 system frameworks includingFoundation,Security,Network,CoreFoundation, andlibswift\_Concurrency\. The daemon manages not only AirDrop but also AirPlay, Handoff, Universal Clipboard, Continuity Camera, NameDrop, and SharePlay, meaning a crash in any subsystem disrupts all Continuity services simultaneously\.

AirDrop supports three visibility modes:*Receiving Off*\(no AWDL listener\),*Contacts Only*\(requires Apple ID certificate chain verification\), and*Everyone for 10 Minutes*\(accepts connections from any device\)\. In “Everyone for 10 Minutes” mode, the complete HTTP API is reachable without any form of authentication\. On iOS, Apple added a 10\-minute auto\-timeout that reverts “Everyone” to “Contacts Only” , but this mitigation does not protect against attacks during the window of exposure, and does not apply to macOS\.

### 2\.2Android Quick Share

Quick Share \(formerly Nearby Share\) is Google’s cross\-platform file\-sharing feature for Android, Chrome OS, and Windows\. On Samsung devices, it is deeply integrated as the default sharing mechanism, replacing Samsung’s earlier “Nearby Share” implementation\. Quick Share uses a combination of BLE, Wi\-Fi Direct, Wi\-Fi LAN, and may also use WebRTC depending on the scenario\.

Quick Share’s session traffic is largely structured as Protobuf\-serialized messages \(e\.g\., theOfflineFramefamily\), and is typically protected by an authenticated key\-exchange followed by encrypted transport\. In particular, reverse\-engineering of the Quick Share for Windows implementation reports an initial UKEY2 handshake after which subsequentOfflineFramepackets are encrypted\.\[safebreachQuickShareRCE\]

At a high level, the connection lifecycle can be described in four phases: \(1\)*Discovery / advertising*, where nearby devices become visible to each other using short\-range radios \(commonly Bluetooth/BLE\) and exchange ephemeral endpoint identifiers; \(2\)*Bandwidth upgrade negotiation*, where the peers negotiate a higher\-throughput out\-of\-band channel \(e\.g\., Wi\-Fi Direct or a temporary Wi\-Fi hotspot / access point\) for bulk transfer; \(3\)*Introduction & consent*, where the sender transmits file\-introduction metadata and the receiver is prompted to accept the transfer; and \(4\)*Payload transfer*, where the file bytes are transmitted over the negotiated high\-bandwidth channel\.\[yair2024quickshell,googleQuickShareHelp\]

Samsung’s implementation extends the base Quick Share with additional features including link sharing with server\-side URL preview generation, a feature not present in Google’s reference implementation\. On the Samsung Galaxy S23 Ultra \(our test device\), Quick Share runs as a system\-level service \(com\.samsung\.android\.nearby\.discovery\) with access to network I/O, file system operations, and WebView rendering for link previews\.

Google’s Quick Share for Windows implementation handles endpoint management, the lifecycle of connected peers through a state machine that allocates and deallocates endpoint objects as devices connect and disconnect\. During concurrent transfers involving multiple devices, these endpoint objects can be subject to race conditions if connection and disconnection events arrive simultaneously, a property we exploit in v6 \(Section[6\.4](https://arxiv.org/html/2606.26967#S6.SS4)\)\.

### 2\.3Threat Model

We consider an attacker in wireless proximity to the target device \(within AWDL/Wi\-Fi Direct range, typically 10\-30 meters\)\. The attacker has a commodity laptop with Wi\-Fi capability and requires no prior relationship with the target \(no pairing, no contact exchange, no shared network\)\. The target device has AirDrop or Quick Share enabled in a mode that accepts connections \(“Everyone” for AirDrop; default visibility for Quick Share\)\. We focus on*zero\-click*attacks that require no user interaction on the target device\. For AirDrop, this means exploiting the pre\-authentication phases \(Discover, Ask routing\) before the user acceptance prompt is displayed\.

## 3AirDrop Protocol Reverse Engineering

We reverse engineered the AirDrop protocol by static and dynamic analysis ofsharingdand the privateSharing\.frameworkonmacOS15\.7\.4 and on the latestmacOS26\.3 andiOS18\.1/26\.3 releases\. Throughout the paper we describe findings at the protocol level; exact symbol offsets and per\-build disassembly listings are released as artifacts\.

### 3\.1Protocol Stack Overview

Table[2](https://arxiv.org/html/2606.26967#S3.T2)summarizes the seven\-layer AirDrop protocol stack we identified\. Each layer introduces distinct serialization formats and potential vulnerability surfaces\.

Table 2:AirDrop protocol stack\. Each layer adds serialization complexity and attack surface\.
### 3\.2Discovery and Connection Establishment

AirDrop device discovery uses DNS\-SD \(mDNS\) over AWDL, advertising service type\_airdrop\.\_tcp\.local\.with∼\\sim25 TXT keys; theflagsfield is a bitmask \(e\.g\.,0x3FB\) encoding DVZip, pipelined uploads, mixed content types, URL sharing, contact resolution, and BLE support\. Upon discovery, the sender opens a TLS connection to port 8770 on the receiver’s IPv6 link\-local address over AWDL, using self\-signed certificates with no hostname verification and no client certificate\.*Any device within AWDL range can establish a TLS connection and interact with the HTTP API*regardless of the receiver’s visibility mode\.

### 3\.3HTTP API and State Machine

The AirDrop HTTP API exposes seven POST endpoints:

/Discover,/Hello,/Ask,/Upload, /Exchange,/SharedIdentity,/Error

The receiver\-side state machine is implemented inSDAirDropConnection\. Each TLS connection has three*request slots*—one each forDiscover,Ask, andUpload—plus control flags and adispatch\_semaphore\_tthat blocks the request handler while the user\-consent prompt is on screen\. A slot isNULLuntil the corresponding request arrives\.*Discover*is accepted only when all three slots areNULLand returns a plistStatusCodeof 100 \(Everyone\), 200 \(contacts matched\), or 401 \(Contacts\-only, no match\)\.*Ask*also requires all slotsNULL\(a prior Discover slot is cleared first\), stores the payload, displays the consent prompt, and blocks on the semaphore until accept/decline or a 15 s timeout\.*Upload*requires the Upload slotNULLand normally follows a successful Ask on the*same*TLS connection; two TXT\-record flags from discovery are consulted—SupportsUPP\(bit0xb\) permits Upload*without*a prior Ask, andSupportsDVZipenables adaptive compression\. Upload data*streams into memory while the Ask prompt is displayed*; the semaphore gates processing, not reception\.

A normal AirDrop transfer is therefore: Discover \(optional\)→\\rightarrowAsk \(same TLS connection\)→\\rightarrowUpload \(same TLS connection\)\. The protocol requires Ask and Upload to share the same TLS session; Upload on a separate connection is rejected\. Figure[1](https://arxiv.org/html/2606.26967#S3.F1)shows this exchange end\-to\-end\.

![Refer to caption](https://arxiv.org/html/2606.26967v1/x1.png)Figure 1:End\-to\-end AirDrop exchange\. Discover and Ask are reachable pre\-consent on the same TLS connection\. The receiver’sflagsTXT record \(e\.g\.,0x3FB, with bit0xb=SupportsUPP\) is consulted on Upload to decide whether pipelined uploads are allowed\.#### 3\.3\.1Path Routing Vulnerability Surface

The HTTP path router lives inSharing\.framework\(fileNetwork\+SFAirDropMessage\.swiftin Apple’s source layout\) and dispatches incoming request paths via a Swiftswitchstatement over anSFAirDropMessagePathenum\. Thedefaultcase callsfatalError\("Unhandled Path \\\(path\)"\), which the Swift compiler lowers to a trapping instruction that aborts the process on any architecture\. Any unauthenticated client sending an HTTP request to an unrecognised path triggers this trap; we exploit it as V1 \(Section[5\.1](https://arxiv.org/html/2606.26967#S5.SS1)\)\.

### 3\.4Serialization Formats

##### Binary Property Lists\.

Discover and Ask request/response bodies are serialized as Apple binary property lists \(bplist00\), parsed byCFPropertyListCreateWithDataand type\-checked asCFDictionary\.

##### DVZip Adaptive Compression\.

Upload bodies use DVZip \(Content\-Type: application/x\-dvzip\), an Apple\-proprietary adaptive chunked format we identified through binary analysis: 4\-byte big\-endian chunk\-length headers wrap individual zlib \(deflate\) blocks, with adaptive switching between gzip and DVZip mid\-stream depending on compressibility, and graceful fallback to plain gzip when the receiver does not advertiseSupportsDVZip\.

##### CPIO Archives\.

The compressed payload contains a CPIO “newc” archive \(magic070701\) terminated byTRAILER\!\!\!\. After decompression,sharingdextracts files via Apple’s BOM \(Bill of Materials\) library usingBOMCopierCopyWithOptions, with CPIO filenames passed toBOMFSObjectNewFromPath—the surface for path\-traversal, symlink, and filename\-based attacks\.

### 3\.5Authentication and Identity

#### 3\.5\.1Protocol Keys \(summary\)\.

Through string extraction and cross\-referencing with disassembly we identified 40\+ protocol commands in AirDrop’s binary\-property\-list messages, grouped into Discover keys \(e\.g\.,SenderComputerName,SenderModelName,SenderRecordData—the DER\-encoded Apple ID certificate chain,SenderID,TransferVersion\), Ask keys \(Files,FileType,FileName,FileBomPath,ConvertMediaFormats\), and capability flags \(SupportsDVZip,SupportsUPP,SupportsMixedTypes,SupportsURLSharing,SupportsStreamZip\)\. The complete key list with descriptions is released as an artifact\. The three security\-sensitive keys areSenderRecordData\(parses untrusted DER\),FileBomPath\(path\-traversal surface, mitigated byBOMCopierCopyWithOptionssandboxing\), andTransferVersion\(gates DVZip and pipelined\-upload behaviour\)\.

#### 3\.5\.2AirDrop Authentication Model

AirDrop’s authentication is layered\.*TLS*uses self\-signed certificates and provides encryption only, not peer verification\.*Contact resolution*parses the DER\-encoded Apple ID certificate chain inSenderRecordDataviaSFAppleIDVerifyCertificateChainto decide whether the sender is a known contact\.*Auto\-accept*is gated by thecanAutoAcceptpredicate, whosesenderIsMeflag is set only whenSFAppleIDVerifyCertificateChainsucceeds against the local user’s iCloud\-bound certificate and the resulting Apple ID matches the receiver’s;senderIsMeis*not*a plist field controlled by the sender\.*User consent*is enforced by the Ask\-phase UI prompt gated on adispatch\_semaphore; all file delivery requires either user acceptance or same\-Apple\-ID auto\-accept\. We tested 15\+ bypass variants that manipulate plist\-level fields purporting to setsenderIsMeor replaceSenderRecordData; all were rejected \(Section[3\.5\.3](https://arxiv.org/html/2606.26967#S3.SS5.SSS3)\)\.

#### 3\.5\.3Zero\-Click Bypass Analysis

We systematically tested ten strategies to bypass the user\-acceptance requirement—direct Upload skipping Ask, HTTP\-pipelined atomic Ask\+\+Upload, plist\-field manipulation ofSenderIsMe, forgedSenderRecordData, fifteen further Ask\-field manipulations, notification flooding, repurposing the Exchange/NameDropTransferType, Upload on a separate TLS session, chunked\-Upload interleaving, and forgedTransferID\.*All ten*were rejected or timed out oniOS18\.1/26\.3 andmacOS15\.7\.4/26\.3: the auto\-accept decision is gated behindSDAppleIDAuthenticateCertificateChainSync, which verifies the sender’s Apple ID against a hardware\-bound chain that cannot be forged without access to the sender’s iCloud credentials\. V1 \(Section[5\.1](https://arxiv.org/html/2606.26967#S5.SS1)\) instead abuses the unrecognised\-path trap before any state transition occurs\.

## 4Fuzzing Methodology

### 4\.1Challenges

Fuzzing AirDrop presents four unique challenges compared to traditional network protocol fuzzing:

1. 1\.AWDL transport: The target is only reachable over theawdl0interface via IPv6 link\-local addresses, requiring active AWDL participation \(BLE advertising \+ Wi\-Fi channel synchronization\)\.
2. 2\.TLS requirement: All HTTP communication is over TLS with self\-signed certificates, requiring a proper TLS handshake for each connection\.
3. 3\.Multi\-layer encoding: A valid Upload requires DVZip\-compressed CPIO archives containing binary plist metadata\-mutations at any single layer are likely rejected by parsers at other layers\.
4. 4\.State dependency: Upload requires a prior Ask on the*same*TLS connection, and the Ask phase blocks on user interaction \(15\-second timeout without our auto\-accept hook\)\.

### 4\.2AirFuzzArchitecture

We developedAirFuzz, a 12,300\-line Python protocol\-aware fuzzer\. Figure[2](https://arxiv.org/html/2606.26967#S4.F2)shows its architecture\.

![Refer to caption](https://arxiv.org/html/2606.26967v1/x2.png)Figure 2:AirFuzzarchitecture\. Mutations are applied to seed inputs*before*DVZip compression; Frida hooks bypass the user\-acceptance prompt; coverage feedback guides mutation selection\.##### Frida Auto\-Accept Daemon\.

To remove the user\-interaction dependency, we deploy a Frida\-based instrumentation agent on the target machine\. The agent hooks five functions insharingdthree ObjC auto\-accept predicates, the nativecanAutoAcceptat offset\+0x041f10, and theUNUserNotificationCenternotification suppressor, forcing acceptance while leaving all other code paths unmodified\. This enables fully automated fuzzing without user interaction\. The daemon monitors the target process and automatically reattaches after crashes with configurable recovery usinglaunchctlbootout/bootstrap to reset launchd throttling\.

##### Mutation Engine\.

AirFuzzimplements nine mutation layers spanning the protocol stack: HTTP \(24 strategies: path corruption, header smuggling, content\-length mismatch, chunked\-encoding abuse, method fuzzing\), binary plist \(12 strategies: type confusion, key deletion, oversized strings, nested\-container injection, cross\-type substitution\), DVZip \(chunk\-length corruption, truncated/oversized chunks, adaptive\-mode confusion\), CPIO \(header corruption, path traversal, symlink/device\-node injection, deep path nesting\), DER \(ASN\.1 length overflows, zero\-key injection\), havoc \(random bit flips and byte insert/delete\), memcorrupt \(25 strategies: boundary values, arithmetic, dictionary ops, block shuffling\), and field\-level mutations that target specific protocol keys while preserving overall structure\.

##### Pre\-Compression Mutation \(Key Insight\)\.

Our initial fuzzer \(AF1–AF3\) mutated the*compressed*DVZip output, resulting in near\-zero \(<1%\{<\}1\\%\) server acceptance because even single\-byte mutations in the compressed stream corrupt the zlib checksum\. The critical design insight in v4 was to mutate the raw CPIO archive*before*DVZip compression\. This ensures that the compressed output has valid zlib framing while carrying mutated content, increasing the acceptance rate to over 90% and enabling meaningful exploration of the archive extraction code paths\.

### 4\.3Fuzzer Evolution

AirFuzzevolved through four versions \(AF1–AF4\) totalling 1\.8K→\\rightarrow12\.3K LoC\. AF1 \(HTTP \+ plist only\) and AF2 \(added DVZip/CPIO mutations\) had<5%\{<\}5\\%server acceptance but AF2 still surfaced V1 within the first 200 test cases\. AF3 added DER/havoc mutations, Frida auto\-accept, and coverage\-guided feedback, discovering V2 and V3\. AF4’s key change was*pre\-compression*mutation plus memcorrupt and field\-level strategies, raising acceptance above 90% and expanding edge coverage from 120 to 950 edges intoFoundationandNetwork\.framework\.

### 4\.4Seed Corpus and Coverage

We constructed the seed corpus by capturing legitimate AirDrop transfers between two Apple devices, covering six scenarios: single image, multi\-file, large file \(500 MB\), URL sharing, contact card \(VCF\), and directory transfer\. Using Wireshark with TLS key logging, we extracted 162 seed templates in total: 70 for Discover, 45 Ask, plus 42 complete Upload payloads\. We additionally generated synthetic seeds with boundary values and maximum\-length strings for 40\+ protocol commands\. Coverage is collected via Frida Interceptor hooks on∼\\sim100 manually selected functions acrosssharingd,Sharing\.framework, and system frameworks, achieving approximately 950 unique edges across 250K\+ executions\.

##### Choice of coverage instrumentation\.

Frida’sStalkerengine in principle yields basic\-block and edge coverage without manual hook selection, andfpicker\[fpicker\]\(an extension ofToothPicker\[toothpicker\]\) wraps it for AFL\+\+\-style feedback\. We initially attempted this route and found that on our test hosts \(macOS 26\.3 / Apple Silicon ARM64eandiOS 26\.3 / arm64e\)Stalkerreliably crashes the*target*once it begins instrumenting an arm64e thread that executes inside system frameworks: the target is killed withSIGKILLby the kernel, consistent with arm64e codesigning / pointer\-authentication enforcement againstStalker’s in\-process code rewriting\. The Frida agent itself loads and runs fine, baselineInterceptorhooks are stable, andStalker\.follow\(\)on Frida’s own injected thread also works; the failure is specific to following arm64e threads that re\-enter signed system code, which is exactly wheresharingdspends most of its time\. We reproduced this in isolation withStalker\.follow\(\)on the main thread of/usr/bin/osascripton macOS 26\.3, which kills the target on script load\. For the same reason,fpicker’s LibAFL/Rust mode hits identical mitigations andTinyInst/Jackalope\[tinyinst,jackalope\]\(which performs out\-of\-process binary rewriting and was used by Project Zero againstcoreaudiod\[p0\-coreaudiod\]\) would require porting to AWDL\-boundsharingdand re\-implementing the seven\-layer AirDrop encoding stack as a TinyInst harness, which we leave to future work\. We therefore fall back to a smaller, hand\-picked set ofInterceptorhooks placed at the input boundary of each protocol layer \(HTTP path router, plist scanner, DVZip header, CPIO header, DER/SecureMessage parser\)\. This loses fine\-grained edge coverage but is stable on arm64e, survives launchd respawns, and is sufficient to discover V1–V3 and to guide AF4’s pre\-compression mutation strategy\.

### 4\.5Crash Detection and Recovery

Crash detection is performed via SSH\-based health monitoring of the target machine\. Whensharingdcrashes,launchdrestarts it automatically\. Our fuzzer detects the restart \(new PID\) and automatically:

1. 1\.Reattaches the Frida auto\-accept daemon to the new process\.
2. 2\.Copies the triggering input to a crash corpus\.
3. 3\.Iflaunchdthrottles restarts \(consecutive crash count≥4\\geq 4, resulting in exponentially increasing delays\), useslaunchctl bootout/bootstrapto reset the throttle state\.

Crash reports \(\.ipsfiles\) are automatically collected from the target’sDiagnosticReportsdirectory for post\-mortem analysis\.

## 5AirDrop Vulnerabilities

We discovered two zero\-click and one post\-accept pre\-authentication vulnerabilities in AirDrop, summarised alongside the Quick Share findings in Table[1](https://arxiv.org/html/2606.26967#S1.T1)\(Section[1](https://arxiv.org/html/2606.26967#S1)\)\. We detail each AirDrop vulnerability below\.

### 5\.1V1: Remote DoS via Unhandled HTTP Path

##### Root Cause\.

The HTTP path router inSharing\.framework\(seeNetwork\+SFAirDropMessage\.swiftin Apple’s source layout\) maps incoming request paths toSFAirDropMessagePathenum values via a Swiftswitchstatement\. Any path that does not match a defined enum value falls into thedefaultcase, which callsfatalError\("Unhandled Path \\\(path\)"\)\. Unlike Swift’sassertionFailure\(compiled out in release builds\),fatalErroris unconditionally fatal, so the process traps and is terminated\. The vulnerability is therefore a simple, architecture\-independent crash: any unauthenticated client that POSTs to an unrecognised URI path forcessharingdto abort\. The impact is bounded to a denial of service \(no attacker\-controlled register or memory state at the crash point\) and does not require deep protocol knowledge to reach\.

##### Trigger\.

A single HTTP POST request with any unrecognized URI path and a non\-empty body, sent over TLS to port 8770 on the AWDL interface \(e\.g\.,POST /X HTTP/1\.1\\r\\nContent\-Length: 1\\r\\n\\r\\nA\)\.

##### Impact\.

The crash killssharingd, immediately disabling AirDrop, AirPlay, Handoff, Universal Clipboard, and Continuity Camera\. Whilelaunchdrestarts the daemon, an attacker can send crash packets in a loop \(approximately one every two seconds\) to create a*persistent*denial of service\. During active loop attack, 0 out of 6 legitimate AirDrop connection attempts succeeded, all 10 attempts succeeded after stopping the attack\.

##### Affected Versions\.

Confirmed on macOS 15\.7\.3, iOS 18\.x, macOS 26\.3, and iOS 26\.3\. The vulnerability is*not present*on iOS 16\.7\.11, which returns HTTP 400 for unknown paths, suggesting thefatalErrorwas introduced during a Swift port of the path router\.

### 5\.2V2: Foundation XML Plist Stack Overflow

##### Root Cause\.

TheXMLPlistScanner\.scanDict\(\)ofFoundation\.frameworkuses recursive descent parsing with*no depth limit*\. Each recursion level consumes approximately 2,960 bytes of stack \(0x60 bytes for register saves plus 0xb30 bytes for locals\)\. On cooperative thread pools \(stack size∼\\sim512 KB\), approximately 180–200 levels of nesting exhaust the stack\. The next recursive call attempts to write its prologue \(saved registers and locals\) into the unmapped*stack guard page*, raising a memory*write*fault that the kernel reports as SIGBUS /KERN\_PROTECTION\_FAILURE\. The fault address is fully determined by the recursion \(the bottom of the cooperative\-pool stack\) and is not attacker\-controlled; no useful register or memory write primitive is exposed\.

##### Trigger\.

An HTTP POST to/Discoverwith a∼\\sim6 KB XML property list containing∼\\sim200 nested<dict\>elements \(a<dict\><key\>a</key\>\.\.\.cascade terminated by matching close tags\)\.

##### Impact\.

This vulnerability affects not justsharingd, butFoundation\.frameworkitself\.*Any Apple application*that deserializes untrusted XML property lists viaPropertyListDecoderorPropertyListSerializationis vulnerable\. The attack surface spans macOS, iOS, watchOS, tvOS, and visionOS\. We reproduced the crash on all three architectures Apple currently ships AirDrop on:Apple Silicon Mac\(macOS 26\.3, ARM64e\),Intel Mac\(macOS 15\.7\.4, x86\_64\), andiPhone with PAC\(iOS 26\.3, arm64e\)\. The crash threshold varies slightly with cooperative\-thread\-pool stack allocation \(approximately 200 levels on macOS and 180 on iOS\); PAC on arm64e does not change the outcome because the fault originates from the recursive prologue itself rather than a corrupted return pointer\. Symbolicated crash logs and reproduction artifacts for each platform are included in the artifact undercrash\-notes/report\-3\-sigbus\-xmlplist\-recursion/\.

### 5\.3V3: Network\.framework NULL Pointer Dereference

##### Root Cause\.

WithinNetwork\.framework, the HTTP/1\.1 connection\-setup pathnw\_protocol\_http1\_connect\(\)contains a NULL\-pointer dereference reachable when the framer is forced into an inconsistent state\. The crash happens at a fixed offset into a connection structure whose backing object isnil, so the faulting address sits in the unmapped low page; the precise struct\-member offset shifts between builds but the bug is identical across them\.

##### Trigger\.

Crafted HTTP requests with one of: \(a\)Transfer\-Encoding: chunkedwith negative chunk sizes \(\-1\), \(b\) duplicateContent\-Lengthheaders with conflicting values, or \(c\)Content\-Lengthvastly exceeding the actual body size\.

##### Impact\.

SIGSEGV \(KERN\_INVALID\_ADDRESS\) on standard systems where the zero page is unmapped\. This vulnerability is inNetwork\.framework’s HTTP/1\.1 parser, potentially affecting other Apple applications that process untrusted HTTP traffic through the system networking stack, though the specific trigger conditions \(conflicting framing under concurrent load\) may limit practical reachability beyondsharingd\.

## 6Quick Share Vulnerabilities

In addition to AirDrop, we analyzed Quick Share implementations across platforms\. On a Samsung Galaxy S23 Ultra running Android 16 \(firmware S918BXXS8EZA1, Quick Share v13\.8\.01\.11, GMS 26\.05\.34\), we discovered two vulnerabilities \(V4, V5\) in the Nearby Connections protocol layer underlying Samsung’s Quick Share service\. We additionally analyzed Google Quick Share for Windows \(version 1\.0\.2472\.1\), discovering a critical use\-after\-free \(v6\) in the endpoint management subsystem\.

### 6\.1Quick Share Protocol Analysis

To understand the attack surface, we reverse engineered the Quick Share on Samsung Android by combining protobuf definition extraction from the GMS APK, traffic captures between two Samsung devices, and systematic probing of the TCP listener\.

##### Wire Format\.

Quick Share communicates over TCP using a simple framing protocol: each message is preceded by a 4\-byte big\-endian length prefix, followed by a Protocol Buffer payload\. Application\-level messages use theOfflineFrameprotobuf, which contains aV1Framewith atypeenum field that determines the message category\. We identified seven frame types in active use:CONNECTION\_REQUEST\(1\),CONNECTION\_RESPONSE\(2\),PAYLOAD\_TRANSFER\(3\),BANDWIDTH\_UPGRADE\(4\),KEEP\_ALIVE\(5\),DISCONNECTION\(6\), andPAIRED\_KEY\_ENCRYPTION\(7\)\. APAIRED\_KEY\_RESULT\(8\) type is also defined in the binary\.

##### UKEY2 Handshake\.

After the initialCONNECTION\_REQUEST/CONNECTION\_RESPONSEexchange registers the endpoint, UKEY2\[yair2024quickshell\]performs mutual authentication via an Elliptic\-Curve Diffie\-Hellman \(ECDH\) key agreement on NIST P\-256\. The handshake proceeds in three messages using the same 4\-byte length\-prefix framing but with rawUkey2Messageprotobufs \(not wrapped inOfflineFrame\):*ClientInit*\(client→\\rightarrowserver, containing a SHA\-512 commitment hash of the*ClientFinished*message, a random nonce, and the selected cipher suite\),*ServerInit*\(server→\\rightarrowclient, containing the server’s ephemeral P\-256 public key, a random nonce, and the selected cipher suite\), and*ClientFinished*\(client→\\rightarrowserver, revealing the client’s ephemeral P\-256 public key\)\. This commit\-then\-reveal scheme prevents an attacker from choosing a public key that is a function of the peer’s key\. Both parties then derive a shared secret via ECDH and expand it using HKDF\-SHA256 with a protocol\-specific salt \(D2D\_SALT, 32 bytes, hardcoded in GMS\) to produce per\-direction session keys for AES\-256\-CBC encryption and HMAC\-SHA256 authentication\.

##### D2D Encryption Layer\.

After UKEY2 completes, all subsequent frames are expected to use the D2DSecureMessagewire format: the plaintextOfflineFrameprotobuf is encrypted with AES\-256\-CBC \(IV prepended\), then an HMAC\-SHA256 tag is computed over the ciphertext\. The encrypted payload and tag are wrapped in aSecureMessageprotobuf containingheader\_and\_body\(the encrypted frame\) andsignature\(the HMAC tag\)\. On the receiver side, theD2DConnectionContextclass is responsible for unwrapping, verifying, and decryptingSecureMessageenvelopes before passing the plaintext frame to the dispatcher\. As we show in V4 and V5, this decryption step is not enforced uniformly\. We detail the three discovered vulnerabilities below\. Figure[3](https://arxiv.org/html/2606.26967#S6.F3)shows the intended Quick Share connection flow that V4/V5 violate\.

![Refer to caption](https://arxiv.org/html/2606.26967v1/x3.png)Figure 3:Intended Quick Share connection flow\. V4 sendsOfflineFrames above the dashed encryption boundary \(before UKEY2 finishes\), and V5 sends threeOfflineFrametypes in plaintext below the boundary \(after UKEY2 finishes\), in both cases bypassing theSecureMessageenvelope\.

### 6\.2V4: Pre\-Authentication Frame Processing Bypass

##### Root Cause\.

The Nearby Connections protocol used by Samsung Quick Share is designed to enforce a strict handshake sequence: aConnectionRequestregisters the endpoint, then UKEY2 \(ClientInit→\\rightarrowServerInit→\\rightarrowClientFinished\) establishes mutual authentication and derives D2D encryption keys\. Only after this four\-step handshake should the server process application\-level OfflineFrame messages\. However, thePcpManagerin Google Mobile Services \(GMS\) begins dispatching OfflineFrame messages to handlers*immediately after Step 1*\(ConnectionRequest\), without waiting for UKEY2 to complete\. An unauthenticated attacker needs only to send a single, fixed\-formatConnectionRequestprotobuf \(requiring no secrets\), after which the server parses, dispatches, and responds toKEEP\_ALIVE,BANDWIDTH\_UPGRADE, andCONNECTION\_RESPONSEframes, despite never having established an authenticated or encrypted session\.

##### Trigger\.

The attacker opens a TCP connection to the Quick Share port \(53601 in our tests\), sends a validConnectionRequest, and immediately follows it with an OfflineFrame of any of the three affected types\. No UKEY2 handshake messages are required\. The server responds within milliseconds: forKEEP\_ALIVE, a 58\-byte UKEY2 error message \("Expected, but did not find ClientInit message type"\) confirming the frame was parsed and dispatched to the UKEY2 state machine; forBANDWIDTH\_UPGRADEandCONNECTION\_RESPONSE, similar error responses\. We confirmed this at every stage of the connection lifecycle across 5 independent trials each \(100% reproduction rate\)\.

##### Systematic Verification\.

To characterize the pre\-authentication attack surface, we tested frame processing at each stage of the connection lifecycle \(5 trials/stage\)\. Without any priorConnectionRequest\(CR\) all frames are silently dropped \(negative control, 5/5\); immediately after a single CR—with*no*UKEY2 message exchanged—KEEP\_ALIVE,BANDWIDTH\_UPGRADE, andCONNECTION\_RESPONSEare all dispatched and produce server responses \(5/5 each\); after CR\+\+ClientInit,KEEP\_ALIVEis still processed \(5/5\); after CR\+\+ClientInit\+\+ServerInit, the server transitions to a state that expects onlyClientFinishedand drops non\-handshake frames \(5/5\); after the full handshake all frames are accepted \(positive control, 5/5\)\. Stages 1–1c are the key finding—three frame types are dispatched to handlers before any UKEY2 authentication\.

##### Impact\.

This vulnerability \(CWE\-287, CWE\-306\) breaks the fundamental assumption that no application\-level interaction occurs before cryptographic authentication: the attacker drives the Quick Share protocol state machine without any authentication;KEEP\_ALIVEinjection prevents connection timeouts; and the dispatcher processes attacker\-controlled protobuf content before any integrity check, expanding the pre\-authentication surface to frame types designed to be post\-authentication only\. Combined with V5, this lets a fully unauthenticated attacker inject and have processed all three affected frame types without ever establishing encryption\.

### 6\.3V5: Device\-to\-Device Encryption Bypass

##### Root Cause\.

After the UKEY2 handshake completes and derives AES\-256\-CBC \+ HMAC\-SHA256 session keys, all subsequent OfflineFrame messages*must*be wrapped in a D2DSecureMessageenvelope that provides both confidentiality and integrity\. However, the frame dispatcher in theEndpointChannelManagerroutes incoming frames based on theV1Frame\.typefield*before*checking whether the frame was received through the D2D decryption pathway\. As a result, 3 out of 7 post\-handshake OfflineFrame types are processed as raw \(unencrypted\) protobuf:CONNECTION\_RESPONSE\(type 2\),BANDWIDTH\_UPGRADE\(type 4\), andKEEP\_ALIVE\(type 5\)\. The remaining 4 types \(PAYLOAD\_TRANSFER,DISCONNECTION,PAIRED\_KEY\_ENCRYPTION,PAIRED\_KEY\_RESULT\) are correctly rejected when sent without encryption, indicating the encryption check is performed per\-handler rather than at the dispatcher level and three handlers simply omit it\.

##### Trigger\.

The attacker completes a full UKEY2 handshake with the target device over TCP \(ConnectionRequest→\\rightarrowClientInit→\\rightarrowServerInit→\\rightarrowClientFinished→\\rightarrowConnectionResponse\), deriving D2D encryption keys\. The attacker then sends a*raw*OfflineFrame protobuf not wrapped in the mandatorySecureMessagefor any of the three affected types\. The server processes the frame and responds:

- •CONNECTION\_RESPONSE: 104\-byte response; the server advances its connection state machine to “accepted,” as confirmed by logcat:"Endpoint \[id\] has accepted the connection"\.
- •BANDWIDTH\_UPGRADE: 29\-byte response containing aSAFE\_TO\_CLOSEevent that*echoes back*the attacker\-supplied IP address and port number, proving the server parsed attacker\-controlled data from the unencrypted frame\.
- •KEEP\_ALIVE: 16\-byte response withack=true, demonstrating the KeepAlive handler has no encryption check whatsoever\.

We confirmed all three bypasses across 5 independent trials with 100% reproduction rate on Samsung Galaxy S23 Ultra running Quick Share v13\.8\.01\.11 with GMS 26\.05\.34\. Figure[4](https://arxiv.org/html/2606.26967#S6.F4)highlights which post\-handshake frame types cross theSecureMessageboundary and which do not\.

![Refer to caption](https://arxiv.org/html/2606.26967v1/x4.png)Figure 4:V5 per\-handler encryption enforcement\. Four of seven post\-handshakeOfflineFrametypes are correctly rejected when unencrypted; the three red types are dispatched and processed even when delivered as a raw, unwrapped protobuf, despite the active D2D session\.
##### Impact\.

An on\-path attacker on the sameWi\-Finetwork can inject unencrypted control frames into an active Quick Share session, defeating the D2D encryption layer: unencryptedCONNECTION\_RESPONSEforces a connection into “accepted” state, potentially bypassing user consent;KEEP\_ALIVEinjection prevents timeouts and keeps sessions alive indefinitely; and unencryptedBANDWIDTH\_UPGRADEframes cause the server to process attacker\-supplied IP/port values, leaking endpoint state\.

### 6\.4v6: Use\-After\-Free via Endpoint Collision Race Condition

##### Root Cause\.

Google Quick Share for Windows \(version 1\.0\.2472\.1\) manages connected peers through dynamically allocatedEndpointChannelobjects in the Nearby Connections library\. We discovered a critical use\-after\-free \(UAF\) in theOnEncryptionFailedcallback, triggered whenEncryptionRunner::StartServer\(\)inencryption\_runner\.ccfails the UKEY2 handshake\. The vulnerability manifests when two connections arrive with*identical endpoint identifiers and nonce values*: a collision handler inbase\_pcp\_handler\.cctears down the endpoint \(closing both channels and freeing theEndpointChannelobject\), while a concurrent thread pool worker executes the encryption failure callback that still holds a raw pointer to the freed object\. The stale pointer is subsequently dereferenced for a vtable virtual function call, causing anACCESS\_VIOLATION\.

Notably, the source code atbase\_pcp\_handler\.cc\(line 814\) contains a developer comment acknowledging a*previous bug*in this exact code path:"We had a bug here, caused by a race with EncryptionRunner\."The applied fix performs a channel identity comparison \(\*endpoint\_channel \!= \*pending\_connection\_info\.channel\), but this comparison*itself dereferences the freed pointer*before comparing, creating a new UAF\.

##### Trigger\.

We developed a multi\-phase Python reproducer that rapidly cycles real ECDH handshakes against the Quick Share TCP listener using a*fixed*endpoint identifier \("FZ"\), causing register/teardown task queue races\. The reproducer proceeds through six phases: sequential handshake cycling \(30 rounds\), concurrent handshake storm \(4 threads×\\times15\), interleaved collision during handshake \(30 rounds\), heavy sustained cycling \(100 handshakes\), final storm \(6 threads×\\times20\), and a combined attack phase\. The crash typically occurs when the collision handler logs"cleaned up the collision with endpoint FZ by closing both channels\. Our nonces were identical’’while a concurrent worker inencryption\_runner\.ccattempts to invoke a virtual method on the freedEndpointChannel\. The race window is wide \(∼\\sim11\+ seconds of task queue stall\), making reproduction reliable\.

##### Crash Analysis\.

Under WinDbg with Page Heap enabled, the crash manifests as a vtable dereference on a freedEndpointChannel:mov rcx,\[rdi\+20h\];mov rax,\[rcx\]\(read freed vtable\);call \[rax\+60h\]\. The exception occurs atnearby\_share\!GetStringFeatureFlagDart\+0xaa61e\(file offset0x0116fb0e\), withrcxpointing into a PageHeap guard page \(MEM\_RESERVEstate\), confirming the object has been freed\. The call stack originates fromntdll\!TppWorkerThreadthrough the Nearby Connections thread pool\.

##### Impact\.

The crash primitive is a classic vtable\-hijack pattern and exploitation is plausible: \(i\) Control Flow Guard is*disabled*innearby\_share\.exe, so no indirect\-call target validation is performed; \(ii\) without Page Heap, the freed slot falls into the normal process heap and can be reclaimed by a subsequent same\-size\-class allocation; \(iii\) the attacker controls incoming heap\-allocated connection data that could reclaim the freedEndpointChannel; \(iv\) the wide∼\\sim11 s race window provides ample time for heap spraying between free and use\. A standard exploitation path is fake\-vtable→\\rightarrowROP→\\rightarrowVirtualProtect→\\rightarrowshellcode \(the usual DEP bypass for CFG\-disabled binaries\)\. We confirmed the DoS impact but did not develop a full exploit\.

##### Disclosure\.

We reported V4–V6 through Samsung Mobile Security and the Google Vulnerability Reward Program \(VRP\)\. Samsung transferred V4 and V5 to Google after determining that the affected code paths originate in Google’s Nearby/Quick Share components shipped to Samsung; those reports are under investigation at the time of writing\. Google’s security team acknowledged the validity of V6 against Quick Share for Windows version 1\.0\.2472\.1 and awarded a bounty; a CVE identifier is pending assignment\. Section[7\.5](https://arxiv.org/html/2606.26967#S7.SS5)summarises the full disclosure status\.

## 7Discussion

### 7\.1Cross\-Platform Comparison

Both protocols expose pre\-authentication attack surfaces from wireless proximity \(AirDrop’s TLS listener accepts any connection; Quick Share’s BLE/Wi\-Fi\-Direct discovery is similarly open\) and exhibit insufficient input validation at the application layer—Apple in HTTP path handling and plist parsing, Samsung in pre\-authentication frame dispatching and encryption enforcement, Google in endpoint lifecycle management\. The designs diverge in encoding \(AirDrop’s seven\-layer HTTP→\\rightarrowbplist→\\rightarrowDVZip→\\rightarrowCPIO stack vs\. Quick Share’s flatter Protocol Buffers\) and in concurrency model \(AirDrop serializes via a dispatch semaphore, while Quick Share’s multi\-threaded endpoint manager admits the V6 use\-after\-free\)\. Each of V1–V6 instantiates a distinct root\-cause class—reachable assertion \(V1\), unbounded recursion \(V2\), parser state confusion \+ NULL deref \(V3\), missing pre\-authentication frame check \(V4\), missing encryption enforcement \(V5\), and concurrent endpoint UAF \(V6\)—suggesting that proximity transfer protocols expose a broad spectrum of bug classes rather than a single dominant failure mode\. The recurrence of assertion\- and parser\-class bugs in Apple’s code indicates that defensive patterns suited to application reliability \(fatalError\) become liabilities in network\-facing daemons; in Quick Share, V4 and V5 share a single root cause—authentication and encryption checks delegated to individual frame handlers rather than enforced at the dispatcher\.

### 7\.2Recommended Mitigations

##### For Apple AirDrop \(V1–V3\)\.

Replace everyfatalError\(\)and force\-unwrap reachable from network input withguard letand a graceful error return \(V1\); enforce a maximum nesting depth inFoundation’sXMLPlistScanner\(e\.g\., 64 levels; legitimate AirDrop traffic uses depth≤4\\leq 4\) together with a maximum HTTP body size \(V2\); and validate HTTP framing strictly per RFC 9110 §8\.6, rejecting conflictingContent\-Lengthheaders, negative chunk sizes, and oversized header values \(V3\)\.

##### For Quick Share \(V4–V6\)\.

Reject allOfflineFrametypes except UKEY2 handshake messages until authentication completes \(V4\); decrypt and integrity\-verify all post\-handshake frames at the dispatcher rather than per\-handler \(V5\); and protect both the endpoint map and endpoint objects with a single lock and defer deallocation via reference counting or epoch\-based reclamation until all in\-flight operations complete \(V6\)\.

### 7\.3Broader Impact

The vulnerabilities affect a substantial device population: Apple reports over 2\.2 billion active devices\[apple\-active\-devices\]runningsharingd, and Google reports over 3 billion active Android devices\[google\-android\-devices\]with Quick Share as the default sharing mechanism on Samsung devices and available system\-wide on Android\. Since V4 and V5 reside in Samsung’s Quick Share service layer, further investigation is needed to determine whether other Android OEMs that integrate Quick Share share the same vulnerable code paths\. While proximity limits the attack radius to∼\\sim10\-30 m, high\-density environments \(airports, transit, conferences\) enable a single attacker to reach hundreds of devices simultaneously\.

### 7\.4Future Work

Promising directions include escalating V3’s NULL\-pointer dereference to code execution; verifying V4 and V5 on other Android OEMs that integrate Quick Share, exploring LLM\-assisted decompilation to reduce the manual binary analysis effort our AirDrop reverse engineering required, fuzzing XNU’sIO80211AWDLPeerAWDL driver at the link layer, and formally verifying the state machine in FigureLABEL:fig:state\-machinewith ProVerif or Tamarin\.

### 7\.5Ethical Considerations and Responsible Disclosure

All testing was performed exclusively on devices we own in an isolated network environment with no bystander devices in wireless range\. All six vulnerabilities were reported to the respective vendors through their coordinated disclosure channels:

- •Apple \(V1–V3\)\.Reported to Apple Product Security\. All three issues were*acknowledged*and are currently*under fix*; no CVE identifiers have been assigned at the time of writing\.
- •Samsung \(V4–V5\)\.Reported to Samsung Mobile Security, who*transferred*the cases to Google after determining that the affected code paths originate in Google’s Nearby/Quick Share components shipped to Samsung\.
- •Google \(V4–V6\)\.Reported via Google’s Vulnerability Reward Program\. V6 \(the Windows Quick Share use\-after\-free\) was acknowledged and Google awarded a bounty for this report; a CVE identifier for V6 is pending assignment\. V4 and V5 remain under investigation\.

We released AIRFUZZ, crash reproduction scripts, the Frida auto\-accept daemon, protocol documentation, and the seed corpus for WOOT artifact evaluation on Zenodo:[https://zenodo\.org/records/20442029](https://zenodo.org/records/20442029)

### 7\.6Limitations

Our analysis has several limitations:sharingdis stripped, so our symbolication relies on export tables, string references, and function boundary heuristics; Frida\-based coverage instrumentation may mask or trigger additional race conditions; our Quick Share analysis focused on Samsung Android and Google Windows, other OEMs may differ, and we achieved code execution only once for V6, though V3 to V5 warrant further investigation\.

## 8Related Work

##### AWDL and AirDrop Protocol Analysis\.

Stute et al\.\[stute2018billion,stute2019openwifi,stute2021disrupting\]reverse engineered the AWDL link layer, released the open\-source OWL implementation, and demonstrated denial\-of\-service and man\-in\-the\-middle attacks at the wireless layer\. Their work forms the substrate on which the present paper’s application\-layer analysis builds: where OWL exposed AWDL itself, we focus on the HTTP/binary\-plist/DVZip/CPIO stack served over AWDL bysharingd\. Project Zero’s Beer\[beer2020awdl\]subsequently demonstrated a fulliOSzero\-click radio\-proximity exploit against the AWDL kernel driver, showing that the AWDL surface extends below user space; our V1\-V3 add three new pre\-authentication bugs on the same wireless reach, but in the user\-space sharing daemon and its supporting frameworks\.

##### AirDrop Privacy\.

Heinrich et al\.\[heinrich2021opendrop\]developed OpenDrop, an open\-source AirDrop implementation, and analyzed privacy issues in AirDrop’s contact discovery and authentication design, showing that exchanged hash\-based contact identifiers can enable leakage of phone numbers and email addresses to nearby adversaries\. Public reporting has also discussed how such weaknesses may be abused in practice; for example, Bloomberg news\[bloomberg2024airdrop\]reported claims by Chinese authorities about identifying AirDrop message sources\. Martin et al\.\[martin2019handoff\]analyzed privacy properties of Apple’s broader Continuity protocol family over BLE, demonstrating identifying and behavioral leakage in related always\-on proximity services\.

##### PrivateDrop\.

Heinrich et al\.\[heinrich2021privatedrop\]proposed PrivateDrop, a privacy\-preserving mutual authentication design based on Private Set Intersection \(PSI\) to replace AirDrop’s hash\-based contact verification\. Apple later introduced an “Everyone” receive\-mode time limit \(first deployed in China with iOS 16\.1\.1 and then rolled out more broadly\) which mitigates some abuse scenarios but does not adopt PSI\-style mutual verification\[heinrich2021privatedrop\]\.

##### Nearby Connections, Quick Share, and Nearby Share\.

Antonioli et al\.\[antonioli2019nearby\]reverse engineered and analyzed Google’s*Nearby Connections*framework on Android, uncovering design and implementation weaknesses in proximity\-based device\-to\-device communication\. More recently, Yair and Cohen\[yair2024quickshell\]analyzed Google’s Quick Share for Windows and reported a remote code execution attack chain \(including CVE\-2024\-38271 and CVE\-2024\-38272\) exploiting file\-handling and protocol\-frame processing\. Complementing these vulnerability\-centric analyses, Kleidermacher\[kleidermacher2025quickshare\]describes Google’s security\-driven design considerations for enabling Android Quick Share interoperability with Apple’s AirDrop\. Our work differs in focus by examining Samsung’s extended Android Quick Share implementation and by developing protocol\-aware fuzzing tailored to multilayer proximity\-transfer stacks\.

##### Mobile Daemon Fuzzing and Zero\-Click Surfaces\.

Protocol\-aware fuzzing of mobile system components and always\-on daemons has been explored in several contexts\. Groß\[gross2020remote\]demonstrated remote exploitation of the iPhone via iMessage, highlighting the risk of zero\-click attack surfaces in background services\. Silvanovich\[silvanovich2019zeroclick\]systematically analysed the fully remote attack surface of the iPhone, cataloguing zero\-click entry points across system services\. Closest to our fuzzing methodology,ToothPicker\[toothpicker\]fuzzed theiOSBluetooth daemon over the BLE link layer using Frida\-based in\-process feedback, andfpicker\[fpicker\]extends that approach with AFL\+\+\-style mutation, FridaStalkercoverage, and richer mode support; both target the same class of always\-on Apple daemons we analyse, and we discuss why their Stalker\-based coverage fails on current arm64emacOS/iOS\(Section[4](https://arxiv.org/html/2606.26967#S4)\)\. Project Zero’s binary\-instrumentation toolchain,TinyInstandJackalope\[tinyinst,jackalope\], was used to fuzzcoreaudiodonmacOS15\[p0\-coreaudiod\]; porting that out\-of\-process rewriting model to AWDL\-attachedsharingdis left to future work\. Our fuzzer therefore borrows the protocol\-aware, Frida\-based posture of ToothPicker/fpicker while replacing Stalker coverage with hand\-selectedInterceptorhooks at each layer boundary of the AirDrop stack\.

## 9Conclusion

We presented the first cross\-platform security analysis of Apple AirDrop and Android Quick Share, the two dominant proximity file\-transfer protocols serving over five billion devices\. By reverse engineering AirDrop’s seven\-layer protocol stack\-including the undocumented DVZip compression format and developing theAirFuzzprotocol\-aware fuzzer, we discovered three pre\-authentication vulnerabilities in Apple AirDrop \(V1–V3\): two zero\-click and one post\-accept\. Through complementary manual security assessment of Android Quick Share, we found three additional vulnerabilities: a pre\-authentication frame\-processing bypass \(V4\) and a D2D encryption bypass \(V5\) in Samsung Quick Share, and a use\-after\-free in Google Quick Share for Windows \(V6\)\. Our findings show that proximity protocols are a*structural*vulnerability class: fatal assertions in network\-facing code, missing dispatcher\-level authentication and encryption enforcement, and unsynchronized concurrent endpoint management recur across independently developed implementations\. All six vulnerabilities have been responsibly disclosed;AirFuzzand all reproduction artifacts released as open source\.

## References