Login Notes

Notes on the login process

As of late 2019, the APIs found at developerservices2.apple.com have required an authentication token specifically for Xcode signing requests, generated by AuthKit. This makes use of Anisette data (effectively, unique device metadata) for this token to be created.

Thanks to the work of Riley Testut (@rileytestut) and Kabir Oberai (@kabiroberai), a mostly open implementation of this login process is present in ReProvision. It still however requires the use of AuthKit to fetch Anisette data for the current device, which then is used in the HTTP headers of the requests for login. See RPVLoginImpl.m for details of this process.

Login issues, simplified

Apple restricts generating the specific token needed to Macs, by validating the HTTP headers sent as part of the login process. Initially, this was bypassed by overriding the header X-MMe-Client-Info with an identifier taken from a Mac.

However, this spoofing is not perfect. Other components of Anisette data sent in HTTP headers (see results of AKAppleIDSession -appleIDHeadersForRequest: for the list) are generated including the current platform, making it possible to check if the header X-MMe-Client-Info has been spoofed.

To work around this, any of the following can be done:

a) Manually generate your own Anisette data, by fully reverse engineering AuthKit

• This falls into a grey area of the DCMA, as it involves reversing code that has been obfuscated by the same techniques as used in FairPlay's implementation

b) Calling out to a network of real Macs that then proxy the authentication request with their Anisette data

• This would lead to a unknown device having full unrestricted access to a user's Apple account

c) "Re-generate" the iOS device's Anisette data so that it appears to be a Mac

• This may interfere with other iCloud services on the device
• This approach is used in AltServer for Windows

None of these approaches are ideal.