Question RE: cloudkit.rs

[parawanderer]

Hi, I'm here from malmeloo/FindMy.py#173

I'm admittedly completely unfamiliar with Rust. I'm curious if the code @ https://github.com/OpenBubbles/rustpush/blob/master/src/cloudkit.rs#L828 actually fully implements the whole "retrieve all data for the iDevices in your account" logic? And if it does, is there any easy entry point for this or some test code that covers that use-case?

A bunch of people from the "FindMy space" (me included with this app: https://github.com/parawanderer/OpenTagViewer) are very interested in allowing users to fetch data for their AirTags without requiring a MacOS device to extract the information from (see: malmeloo/FindMy.py#173 and malmeloo/FindMy.py#177)

Thx in advance!

[TaeHagen]

Hi, That code you linked implements CloudKit. It's open to third party developers, but Apple uses it for many things, including storing FindMy item keys. The code to retrieve the keys is here FindMy.

This code is currently distributed in OpenBubbles (an Android App). If you install OpenBubbles, you can log into your Apple account and see your FindMy items with no Apple device involved (however it cannot setup airtags, only track at this time).

[parawanderer]

Oh interesting @TaeHagen , thanks for the info! I think we have a slightly overlapping use-case then with my app and yours.

From the website for OpenBubbles I see that you don't actively advertise the whole "AirTag on Android" use-case and require setting up a server, though. I guess the main difference with my app is that you don't necessarily require a server or all that much further setup, past just logging in to an apple account.

I probably need to think about this a bit, but for the FindMy.py library (which aims at providing an interface to the apple FindMy world for anybody, which my app then just uses basically) I think people would probably really like it if they could fetch the tags for their devices the way you do in your app/code here, without any "we need to steal files from the cache of a Mac" hacks as we have now. Though, I also don't want to steal your use-case 😅 and I'm not all that attached to my app either -- I just made it because I googled if there was a simple solution for displaying the data on android and there seemingly wasn't, so I wrote one up really quickly.

Nonetheless, would you be open in looking into how your existing work could be combined into that FindMy.py library? Whether via a bridge or by just copying over the relevant parts for "retrieving the airtags for a user account dynamically"?

[TaeHagen]

We don't require setting up a server. You just need hardware data to authenticate with Apple. We don't advertise the Airtag on Android use case because it is brand new, just came out last version.

The problem with just "copying over the parts" is, there are a lot of parts. You need to implement GSA circle for 2fa, Cuttlefish/Octagon for trust, PCS for cloudkit encryption, cloudkit for cloudkit, and then you can finally pull + decrypt the keys. I did all that work for Messages in iCloud, FindMy was just a nice bonus.

[parawanderer]

Oh interesting, alright, I see. I think in that case your app might just cover what I wanted to achieve with my app directly now, from the sounds of it. I'll have to look into that and maybe just point people to your app for this use-case moving forward.

Got it regarding how much there is to copy here for the more wider FindMy.py setup. Though, I am wondering if there'd still be some avenue of integrating anything at all via a bridge for the FindMy.py library? I imagine there are still many people who'd love to write up their own logic around retrieving their tags' data outside of the "I want to just see them on android" case that is now covered.

[TaeHagen]

You could always use rustpush just to extract keys and move them over to FindMy.py or your app.

If it's helpful, I could add a function to OpenBubbles that exports keys to disk in a community-defined format. Right now I already have them all stored in a plist file on device, it's just a matter of copying them.

[parawanderer]

I think that if you could have a function that does the export to disk that would be very helpful to a bunch of people involved! 🙏

I think from the FindMy side the "canonical format" the community has been using for the plist files is this XML format:

• shared AirTags incompatible (only key provided is peerTrustSharedSecret) malmeloo/FindMy.py#34 (comment)
• How to obtain .plist files malmeloo/FindMy.py#31 (comment)

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

People already wrote a bunch of convertors to work with this format, so that's probably the one to use.

[parawanderer]

Here you go, this should get you the right thing format. This is "OwnedBeacon":

parawanderer/OpenTagViewer#24 (comment)

Bonus points if you could include "BeaconNamingRecord":

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>associatedBeacon</key>
	<string>11111111-1111-1111-1111-111111111111 <!-- UUID, relates to a beacon in OwnedBeacons --></string>
	<key>cloudKitMetadata</key>
	<data>
	<!-- Base64 blob, multi-line -->
	</data>
	<key>emoji</key>
	<string>👵<!-- emoji, selectable in UI --></string>
	<key>identifier</key>
	<string>11111111-1111-1111-1111-111111111111<!-- UUID --></string>
	<key>name</key>
	<string>My Tag Name<!-- Name, as defined in the apple UI --></string>
	<key>roleId</key>
	<integer>999 <!-- no idea --></integer>
</dict>
</plist>

The canonical output format that all the existing tools use for the XML is this:

<generated output folder>/
├── BeaconNamingRecord/
│   ├── <UUID 1>/
│   │   └── <UUID 2>.plist
│   └── ...
├── OwnedBeacons/
│   ├── <UUID 1>.plist
│   └── ...
└── ...

[malmeloo]

Ha, I was already thinking of looking into how feasible it'd be to wrap rustpush in a simple CLI utility. Is the Apple hardware requirement only for iMessage or is it also required to access the keychain? If it still requires a mac or iPhone like OpenBubbles does now, that kind of defeats the idea of having a cross-platform utility.

As for the format: simply outputting the plist would totally work, but one downside is that the initial alignment data would not be included. FindMy.py currently uses a rather simple JSON format for accessories, so that would be ideal. But honestly, having support for macless accessory dumping in the first place would be a blessing already.

[TaeHagen]

Apple hardware requirement is techincally required to access keychain, but i don't think apple cares if the hardware is valid, should just be able to randomize most of the data and it should let you in fine.

I have access to alignment data, I can put anything in the plist I want to, including that if that's what you need.

[malmeloo]

If you think it could work without access to actual apple hardware that'd be perfect. As for the format, whatever is convenient would work really. I can add support to FindMy.py to import from any arbitrary format. But access to alignment data would be nice just so that the first fetch isn't a complete shot in the dark.

[malmeloo]

I have a few questions regarding what this solution would look like. It seems I was a bit misinformed about the nature of rustpush as an open source project.

From what I understand:

• Rustpush uses a closed-source dependency that prevents us from using it as a dependency in another Rust project
• No binaries are provided that can be linked against or would allow us to use a CLI built into rustpush
• OpenBubbles still requires a mac or iPhone to set up

Correct? If so that'd be quite a bummer, because it would mean we'd still require access to Apple hardware to export airtag keys. Is there a way around this?

[TaeHagen]

There are two closed source dependencies.

• OpenAbsinthe, used for registration with iMessage. This does not affect you, because you do not seek to register with iMessage
• ClearADI, for generation of Anisette Data. You do need anisette data, however, you likely already have your own code to get that (using sidestore's server probably).

So while yes, parts are closed, they shouldn't affect you.