{"id":"a5b94de4-af17-419e-b97a-d3bc41765a47","arxiv_id":"2507.07210","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":8.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"First public reverse engineering of the Apple Watch's wireless protocol stack, a working Android reimplementation, and two disclosed vulnerabilities (one fixed by Apple).","lead":"Researchers reverse-engineered the Apple Watch's private wireless protocols and built an Android app, WatchWitch, that pairs with the watch, receives its health data, forwards notifications, and filters its Internet traffic. The work also uncovers two security flaws in Apple's design, one allowing forged health values to be inserted when an attacker already holds certain encryption keys.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The health-data forgery in §6.3 may exceed Attacker 2's stated capabilities: it assumes plaintext knowledge (block offset and original type byte) that the §6.1 threat model does not grant, and the paper reports no end-to-end confirmation that the forged sample is accepted by the health daemon.","rationale":"The reader's weakest assumption (firmware version drift) is real but secondary: the authors partially mitigate it for A-over-C and it affects all reverse-engineering work. My concern targets internal consistency of the security claim. Section 6.1 defines Attacker 2 as holding IPSec keys only; Section 6.3 silently adds 'partial knowledge of their plaintext content.' That added capability is load-bearing: without knowing the plaintext block layout and the original type byte, the bit-flip mask cannot be constructed and the target block cannot be located. The paper should either add this assumption to the threat model, justify how an Attacker 2 obtains it (e.g., from a locked phone's memory under the border-control scenario), or demonstrate the attack blind. The paper also lacks an explicit end-to-end check that the modified NanoSync message is accepted by the health daemon and persisted in the SQLite database; Apple's denial of exploitability makes this check necessary. If the attack fails either condition, the second half of the strongest claim collapses, though the interoperability contribution would remain intact. The version concern raised by the reader overlaps with the need for more evidence but is not the same; I therefore mark partial agreement. The appropriate verdict remains CONDITIONAL, but the condition should be sharpened: either demonstrate the forgery under the stated Attacker 2 capabilities or revise the claim to acknowledge the plaintext-knowledge assumption.","tokens_in":26634,"tokens_out":15588,"duration_ms":171160,"concrete_test":"Reproduce the Section 6.3 attack under the Section 6.1 Attacker 2 model in a blind setup: capture a real A-over-C health-sync ciphertext, hand the experimenter only the IPSec keys derived from the test phone, the Section 4 protocol documentation, and the ability to inject packets on the Wi-Fi link, but withhold the decrypted plaintext and any Frida access. Ask the experimenter to convert an active-energy sample into a heart-rate sample and then inspect the SQLite database on the receiving iPhone (healthdb_secure.sqlite) for the new row. If the attack cannot be mounted without the plaintext oracle, or if the forged row is absent, the Section 6.3 claim is overstated and the verdict should require either a weaker claim ('malleability' instead of 'forgery') or an explicit additional attacker capability.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The most load-bearing claim is the concrete health-data forgery in Section 6.3. The stated threat model (Section 6.1, Attacker 2) grants only IPSec key material and brief physical access to a locked phone; it does not grant knowledge of A-over-C plaintext. The CBC bit-flip attack, however, requires the attacker to know (a) the exact byte offset at which the 16-byte sample UUID begins, so that it aligns with a block boundary, and (b) the current value of the type byte (e.g., 0x0a for active energy) in order to construct the XOR mask that turns it into 0x05. Without a plaintext oracle, locating the target block in a variable-length NanoSync message and choosing the correct mask is not guaranteed by the described capabilities. The demonstration in Figure 13 appears to have been performed with the plaintext in hand (via Frida); the paper does not report a blind attack under the threat model. It also does not show the forged row actually being inserted into healthdb_secure.sqlite after delivery to the health daemon. Apple's non-fix decision based on 'cannot be exploited' is consistent with the possibility that the health daemon rejects or never parses the modified sample; the paper counters this only with the theorem-level observation that AES-CBC is malleable, not with an end-to-end database check. The vulnerability may be real, but as stated it is not fully established.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents WatchWitch, an open-source Android reimplementation of parts of the Apple Watch-to-iPhone protocol stack, based on extensive reverse engineering of the proprietary wireless protocols (NRLP, Magnet, IKEv2/LDM, Alloy, A-over-C, NanoSync, and Shoes). The authors document these protocols, provide tooling, and demonstrate several smartwatch features on Android: notification forwarding and reply, Internet sharing with a user-controlled firewall, and health-data synchronization. The paper also reports security findings: unauthenticated IKEv2 Link Director Messages enable packet injection and traffic redirection; the A-over-C health-protection layer is malleable because the payload is encrypted with unauthenticated AES-CBC; and cycle-tracking deletions leave metadata behind. The central claims are that third-party Android interoperability is technically feasible despite Apple's stated position, and that the extra health-protection layer can be bypassed to forge health samples.","tokens_in":26908,"tokens_out":6776,"duration_ms":69856,"significance":"If the central claims survive scrutiny, this is a substantial contribution. It is the first public documentation of the Apple Watch's wireless protocol stack, it directly challenges Apple's claimed infeasibility of Android interoperability, and it identifies concrete security weaknesses in a widely deployed health-data protection mechanism. The work is unusually concrete: the source code and tooling are published, the protocol descriptions are specific enough to be independently checked, the app is demonstrated on real devices, and the security findings were responsibly disclosed to Apple. The main caveat is that the headline health-forgery claim is not fully established under the paper's own threat model, and the 'practical interoperability' characterization is heavily qualified by Section 5.4. Overall, this is a strong systems-security contribution that merits publication after the load-bearing claims are tightened and supported.","major_comments":[{"comment":"Section 6.3, Figure 13: the claimed health-data forgery goes beyond the stated threat model. Section 6.1 defines Attacker 2 as having access to IPSec key material (e.g., after brief physical access to a locked phone), which lets the attacker read A-over-C ciphertexts but not A-over-C plaintexts. The attack, however, requires knowledge of the exact byte offset at which the 16-byte sample UUID begins relative to CBC block boundaries, and of the current type byte (e.g., 0x0a) so that the XOR mask can be constructed. The paper's own wording conditions the attack on 'partial knowledge of their plaintext content,' but this capability is not derived from the assets listed in Section 6.1; it is an additional assumption that must be stated and justified in the threat model. Moreover, the paper does not show how Attacker 2 obtains this plaintext knowledge in practice, and the demonstration in Figure 13 is not reported as a blind attack performed under the threat model. Finally, the paper does not show that the modified sample is accepted by the health daemon (for example, that a forged row appears in healthdb_secure.sqlite); the evidence presented is the CBC malleability property, not an end-to-end exploit. Because Apple's non-fix decision was based on 'cannot be exploited,' this end-to-end step is load-bearing. Please either extend the threat model and present a blind end-to-end demonstration, or downgrade the claim to a conditional malleability property that requires an additional plaintext-knowledge assumption.","section":"6.3 / 6.1"},{"comment":"The abstract and conclusion describe the result as 'practical interoperability' and 'true interoperability,' but Section 5.4 states that the current setup requires a rooted Android phone, a jailbroken iPhone on the same Wi-Fi network to bootstrap the connection, does not support a Bluetooth link, and sometimes relies on 'stealing' a protocol session from the previously connected iPhone. These limitations do not invalidate the technical feasibility result, which is valuable, but the wording overstates what was demonstrated. Please align the abstract and conclusion with the limitations in Section 5.4 by referring to a technical proof of concept, or by presenting a concrete user-facing scenario that is actually supported by the prototype.","section":"Abstract / Section 5.4 / Section 9"}],"minor_comments":[{"comment":"There is a typo in the phrase 'maintain the the app's functionality'; it should read 'maintain the app's functionality.'","section":"5.3.2"},{"comment":"Reference [13] is titled 'Track your sleep with Apple Watch,' but the URL and surrounding context indicate that it should instead be the Apple WatchOS feature-availability page; please correct the citation.","section":"References"},{"comment":"The hex dump in Figure 13 is difficult to follow without explicit row and column annotations; adding byte offsets and a parsed structure showing where the 16-byte UUID and the type byte reside would make the attack description much easier to verify.","section":"Figure 13"},{"comment":"Section 6.4 is presented as a security finding, but it is essentially a data-retention observation about local database contents. It would be clearer to state the relevant attacker model (for example, device seizure) and to distinguish this issue from the over-the-air vulnerabilities in Sections 6.2 and 6.3.","section":"6.4"}],"recommendation":"major_revision","confidential_remarks":"This is a solid and timely paper that will likely have high impact if the authors tighten the threat model and evidence around the health-forgery claim. The protocol documentation and Android reimplementation alone are strong contributions. I would not recommend reject because the remaining issues are fixable by adding an experiment or by narrowing the claims. The main risk is that readers will take the Section 6.3 attack as proven under the stated threat model even though it currently rests on an unstated plaintext-knowledge assumption."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read the WatchWitch paper. The headline: it is a genuine first—public documentation of the Apple Watch's application-layer wireless protocols and a working open-source Android reimplementation. That part is solid and worth building on. But the paper's most dramatic security claim, the forged health values in A-over-C, is not fully supported as written, and the abstract oversells 'practical interoperability.'\n\nWhat's new: NRLP, Alloy, LDM, NanoSync, Shoes, and A-over-C are documented for the first time. The WatchWitch app actually pairs an Apple Watch with an Android phone and supports push notifications, internet sharing, health sync, and a host-level firewall. The code and tools are on GitHub, and the authors are transparent about the setup: jailbroken iPhone, rooted Android, session stealing (Section 5.4). That is an existence proof, not a consumer product, and the paper mostly says so.\n\nThe security section has two real findings. The IKEv2/LDM issue—unauthenticated notify payloads after encryption is established—is concrete, reproducible, and fits Apple's fix in watchOS 10.3. The A-over-C malleability is also real as a cryptographic property, but the paper's exploit claim overreaches. Attacker 2 in Section 6.1 is granted IPSec key material, not plaintext knowledge. Section 6.3 then adds 'partial knowledge of their plaintext content' as a requirement. That is a gap between model and attack. The demo in Figure 13 appears to have been done with plaintext in hand via Frida, and there is no end-to-end check that a forged sample actually lands in healthdb_secure.sqlite. Apple's refusal to fix may be dismissive, but the paper's counterargument is only that CBC is malleable—which is true but not the same as showing exploitation under the stated threat model. This needs tightening before publication, not rejection: the reverse-engineering and tooling alone justify the paper.\n\nAlso, the 'practical interoperability' in the abstract should be softened to 'demonstrates technical feasibility,' given the required setup. The protocol analysis relies on iOS 14.8 and two watch models; the paper notes the jailbreak constraint, which is a minor caveat rather than a flaw. Citation pattern is fine: the self-cited prior work covers lower-layer protocols and isn't load-bearing for the new claims.\n\nBottom line: this is a strong paper for security and protocol researchers and for anyone working on interoperability policy. The core contributions hold up; the health attack needs a revised threat model and a blind demonstration. I'd send it to a serious venue with a request for revision. Yes, it deserves peer review.","headline":"First real documentation of the Apple Watch's wireless stack plus a working Android reimplementation; the core holds up, but the health-data forgery claim needs a tighter threat model and an end-to-end demonstration.","tokens_in":27468,"tokens_out":3444,"would_cite":true,"duration_ms":37158,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The Apple Watch can be used with Android phones, a new open-source app shows.","keywords":["Apple Watch","wireless protocol reverse engineering","Android interoperability","Alloy messaging protocol","NanoSync health synchronization","health data privacy","IKEv2 custom notify payloads","A-over-C encryption malleability"],"falsifier":"Capture a real health-synchronization message from a current-generation Apple Watch, recover the A-over-C ciphertext, flip the bits that correspond to the type byte of a known sample, and deliver the modified message to a paired phone; if the phone's health database does not record a sample of the changed type, or rejects the message as unauthenticated, the forgery claim is falsified. Similarly, if a current watch no longer answers the documented IKEv2 custom notify payloads with the expected Link Director Messages, the interoperability claim is falsified.","tokens_in":1744,"feed_emoji":"⌚","tokens_out":2394,"duration_ms":105028,"temperature":0.7,"pith_summary":"The paper sets out to show that the Apple Watch's wireless protocol stack can be reverse-engineered and reimplemented on a third-party phone, directly contradicting Apple's claim that Android interoperability is infeasible. It presents WatchWitch, an Android app that reproduces several core watch features—push notifications with reply actions, Internet sharing, and health-data synchronization—while keeping cryptographic keys in hardware-backed storage and the user's health database encrypted on-device. In the process, the paper documents previously unpublished protocols and reports security weaknesses: custom IKEv2 messages can be forged to redirect traffic, and the extra encryption layer that protects health data is malleable, allowing an attacker with ciphertext access to alter the type of a health sample and insert forged values into the health database. If these claims hold, users would have a practical path out of Apple's ecosystem lock-in, and Apple's security justifications for the walled garden would be weakened.","feed_headline":"Apple Watch can be used with Android phones, new app shows","feed_subtitle":"A custom app reimplements notifications, internet sharing, and health sync—and exposes a health-data forgery.","key_machinery":"The load-bearing mechanism is the layered protocol stack that carries every watch-phone message, with the A-over-C encryption layer as the specific hinge for the security claims. A-over-C wraps class-A health data by encrypting the payload with AES-CBC under a fresh key, encapsulates that key in a message-protection envelope using RSA-OAEP, AES-CTR, and an ECDSA signature, and sends the result over the class-C IPSec tunnel. Because the CBC payload is not authenticated, an attacker who knows some plaintext can flip ciphertext bits so that the corrupted block decrypts to a random-looking but valid 16-byte UUID while the bit flips carry into the following block and alter the sample type byte; the attack exploits the alignment of these 16-byte UUIDs with cipher blocks. The same stack, on the constructive side, is what WatchWitch reimplements: the IKEv2 handshake with custom Link Director Messages, Alloy messaging, Shoes proxying, and NanoSync database synchronization.","core_discovery":"The central discovery is that the Apple Watch's proprietary communication stack is learnable and replicable. The paper reconstructs the chain from Bluetooth and Wi-Fi transport through an IKEv2/IPSec tunnel, the Alloy messaging bus, the Shoes Internet-sharing proxy, and the NanoSync health-synchronization format, then reimplements enough of it on Android to deliver notifications, reply actions, Internet sharing, and health-data synchronization to a real watch. Alongside this constructive result, the security analysis finds that Apple's deviations from standard protocols introduce weaknesses: custom IKEv2 notify payloads carrying Link Director Messages are accepted in unauthenticated contexts, enabling traffic redirection, and the A-over-C encryption used for class-A health data encrypts the payload with unauthenticated AES-CBC, so flipping bits in one ciphertext block can change the type byte of a health sample in the next block and inject forged readings into the health database. The paper also documents that deleted health samples retain their type and deletion timestamp, which it argues can harm users.","pith_inferences":["If the protocol stack is representative beyond the tested devices, the same reverse-engineering route likely opens up other Apple peripherals that reuse the same lower-level transports, such as Magnet or CLink.","A natural next experiment is to implement the Bluetooth path over raw L2CAP sockets; the paper identifies this as missing work, and success would remove the current need for a modified iPhone in the setup.","Regulators weighing interoperability mandates may treat a working third-party implementation as evidence that technical infeasibility claims deserve closer scrutiny.","The A-over-C result suggests that any vendor that layers unauthenticated encryption under a secure tunnel should re-examine the inner layer, since an attacker who obtains one layer's keys can still break the next layer."],"forward_implications":["Android interoperability is practically feasible: a proof-of-concept app reimplements push notification forwarding with replies, Internet sharing, and health-data sync, so Apple's infeasibility claim is contradicted.","The A-over-C layer should be fixed with authenticated encryption; the paper notes Apple could encrypt the entire message with the message-protection mechanism or use an authenticated algorithm.","Custom IKEv2 extensions should be accepted only in encrypted and authenticated contexts; otherwise any in-range packet injector can forge Wi-Fi address updates or redirect Shoes proxy traffic.","Users can gain privacy controls not available on iOS: an on-device firewall, full health-database access, and regional feature unlocking such as ECG, all without cloud involvement.","Interoperability need not mean downgraded security; keys can stay in hardware-backed storage and health data can remain encrypted on the device."],"supporting_citations":[{"why":"Prior documentation of the Magnet protocol and terminus daemon, the Bluetooth foundation this work builds on.","marker":"[48]"},{"why":"Prior analysis of the same message-protection construction used by iMessage, grounding the A-over-C security discussion.","marker":"[44]"},{"why":"The IKEv2 standard whose handshake Apple extends with vendor-specific notify payloads.","marker":"[53]"},{"why":"The ESP standard that provides the tunnel encryption for watch-phone traffic.","marker":"[54]"},{"why":"Reporting that Apple called Android interoperability infeasible after three years, the claim the demonstration contradicts.","marker":"[67]"},{"why":"The antitrust complaint that frames the Apple Watch as part of a smartphone monopoly and demands interoperability.","marker":"[90]"},{"why":"Earlier full protocol-stack reimplementation for a fitness tracker, establishing the reverse-engineering-and-reimplementation method.","marker":"[26]"},{"why":"The dynamic instrumentation toolkit used to extract session key material and decrypt live watch traffic.","marker":"[75]"}],"fun_headline_variants":["WatchWitch app unlocks Apple Watch for Android and reveals data flaws","Apple Watch health data can be forged, Android app demonstrates","Android app reverse-engineers Apple Watch, exposes security weaknesses","New app lets Android users run Apple Watch without iPhone","Apple Watch security flaws exposed by Android compatibility app"],"cache_read_input_tokens":29568,"weakest_assumption_plain":"The argument rests on the assumption that how the tested watches and phones behaved is how Apple's current and future devices behave; for the newest models the paper could not observe the encryption algorithms, so a change in the protocol stack would break both the interoperability demo and the attacks.","fun_headline_variants_meta":{"raw":{"variants":["WatchWitch app unlocks Apple Watch for Android and reveals data flaws","Apple Watch health data can be forged, Android app demonstrates","Android app reverse-engineers Apple Watch, exposes security weaknesses","New app lets Android users run Apple Watch without iPhone","Apple Watch security flaws exposed by Android compatibility app"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000595,"raw_usage":{"total_tokens":2745,"prompt_tokens":866,"completion_tokens":1879,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":482,"completion_tokens_details":{"reasoning_tokens":1799}},"tokens_in":482,"tokens_out":1879,"duration_ms":14804,"temperature":1.0,"reasoning_tokens":1799,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T18:46:27.147268+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Capture a real health-synchronization message from a current-generation Apple Watch, recover the A-over-C ciphertext, flip the bits that correspond to the type byte of a known sample, and deliver the modified message to a paired phone; if the phone's health database does not record a sample of the changed type, or rejects the message as unauthenticated, the forgery claim is falsified. Similarly, if a current watch no longer answers the documented IKEv2 custom notify payloads with the expected Link Director Messages, the interoperability claim is falsified.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Prior documentation of the Magnet protocol and terminus daemon, the Bluetooth foundation this work builds on."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Prior analysis of the same message-protection construction used by iMessage, grounding the A-over-C security discussion."},{"cited_title":"Hoffman, Yoav Nir, Pasi Eronen, and Tero Kivinen","cited_arxiv_id":null,"evidence_quote":"The IKEv2 standard whose handshake Apple extends with vendor-specific notify payloads."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The ESP standard that provides the tunnel encryption for watch-phone traffic."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Reporting that Apple called Android interoperability infeasible after three years, the claim the demonstration contradicts."},{"cited_title":"Apple Inc., No","cited_arxiv_id":null,"evidence_quote":"The antitrust complaint that frames the Apple Watch as part of a smartphone monopoly and demands interoperability."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The dynamic instrumentation toolkit used to extract session key material and decrypt live watch traffic."}],"review_version":1}