Live data from Hacker News

Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

evilsocket.net

11–20 of 36 posts

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#11

“Moreover, while sending crafted packets and attempting all sorts of things, I’ve discovered several vulnerabilities in the Apple custom made parsers. I will not discuss them here (exception made for the session spoofing) but at the same time I’m not interested in reporting them to Apple…” Erm, hope they’re not super serious I guess?

[flagged]

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#12
post #3

From a comment in the article: > This gives me chills, the shared clipboard also uses this protocol, right? This means that everything we copy goes through the network via Bluetooth without encryption and can be captured by any Bluetooth sniffer? The shared clipboard uses this protocol?... on what basis is this claim plausible?

> on what basis is this claim plausible?

The article shows the author holds some grudges against Apple. Those grudges probably influence their judgement.

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#13
post #11

“Moreover, while sending crafted packets and attempting all sorts of things, I’ve discovered several vulnerabilities in the Apple custom made parsers. I will not discuss them here (exception made for the session spoofing) but at the same time I’m not interested in reporting them to Apple…” Erm, hope they’re not super serious I guess?

[flagged]

So the question is whether those bugs are in the framework part provided by Apple, or the application specific code handing the individual messages.

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#14
post #7

"custom (and as typical of Apple, undocumented) TCP protocol" Pretty much all custom protocols are undocumented. Not sure why he feels the need to shit on Apple. And any custom protocol parser will be riddled with errors, because they always expect values to be in range.

> And any custom protocol parser will be riddled with errors, because they always expect values to be in range.

I hope you're not working on any products I rely on.

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#15
post #3

From a comment in the article: > This gives me chills, the shared clipboard also uses this protocol, right? This means that everything we copy goes through the network via Bluetooth without encryption and can be captured by any Bluetooth sniffer? The shared clipboard uses this protocol?... on what basis is this claim plausible?

From Apple Platform Security Guide [0] :

> The individual messages are encrypted much like messages in iMessage are. After the devices are paired, each device generates a symmetric 256-bit AES key that gets stored in the device’s keychain. This key can encrypt and authenticate the BLE advertisements that communicate the device’s current activity to other iCloud-paired devices using AES256 in GCM mode, with replay protection measures.

[1]: https://support.apple.com/en-gb/guide/security/secf78dbe639/...

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#16
post #3

From a comment in the article: > This gives me chills, the shared clipboard also uses this protocol, right? This means that everything we copy goes through the network via Bluetooth without encryption and can be captured by any Bluetooth sniffer? The shared clipboard uses this protocol?... on what basis is this claim plausible?

I thought it was clear it ran through iCloud: https://support.apple.com/en-au/HT209460 It only works between devices signed in with the same Apple ID

The encryption keys are shared via the iCloud keychain, but I think the actual sharing happens over a protocol called Companion Link.

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#17
> My informed guess was multicast DNS as I’ve seen this protocol being (ab)used a lot from Apple (Bonjour for instance)

I understand it's in fashion to kick Apple (and not without reason) but mDNS and DNS-SD is their protocol. They made it and they market it combined with link-local addressing, etc as Bonjour. To me writing like this is naff and makes the author seem needlessly salty.

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#18
post #3

From a comment in the article: > This gives me chills, the shared clipboard also uses this protocol, right? This means that everything we copy goes through the network via Bluetooth without encryption and can be captured by any Bluetooth sniffer? The shared clipboard uses this protocol?... on what basis is this claim plausible?

> From a comment in the article:

To be clear, it's a comment on the article, in the public comments section appended to the article. The comment was not made by the article author.

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#19
post #3

From a comment in the article: > This gives me chills, the shared clipboard also uses this protocol, right? This means that everything we copy goes through the network via Bluetooth without encryption and can be captured by any Bluetooth sniffer? The shared clipboard uses this protocol?... on what basis is this claim plausible?

> on what basis is this claim plausible? The article shows the author holds some grudges against Apple. Those grudges probably influence their judgement.

The comment in question was not written by the article author.

Re: Reverse Engineering the Apple Multipeer Connectivity Framework (2022)

#20
post #11

“Moreover, while sending crafted packets and attempting all sorts of things, I’ve discovered several vulnerabilities in the Apple custom made parsers. I will not discuss them here (exception made for the session spoofing) but at the same time I’m not interested in reporting them to Apple…” Erm, hope they’re not super serious I guess?

[flagged]

It's two lines in an otherwise pretty indepth technical article. Hardly a tantrum.
Post reply on HN