Kret = vm_protect(task, base, target_first_size, 0, VM_PROT_ALL) ( id) copyWithZone :( struct _NSZone *) arg1 ( void) URLSession :( id) arg1 task :( id) arg2 getAppleIDHeadersForResponse :( id) arg3 completionHandler :( id) arg4 ( id) appleIDHeadersForRequest :( id) arg1 ( void) handleResponse :( id) arg1 forRequest :( id) arg2 shouldRetry :( char *) arg3 ( id) _genericAppleIDHeadersDictionaryForRequest :( id) arg1 ( id) _generateAppleIDHeadersForRequest :( id) arg1 error :( id *) arg2 ( void) _generateAppleIDHeadersForSessionTask :( id) arg1 withCompletion :( id) arg2 ( void) _handleURLResponse :( id) arg1 forRequest :( id) arg2 withCompletion :( id) arg3 Also, with reference to point 4, this means hardcoding the device ID and Anisette data is a bad idea because Apple can very easily ban that single device ID.Īll in all, any solution to this will probably have to involve entirely reverse-engineering AuthKit, or coming up with a super creative workaround Apple could fully well begin banning/restricting devices that don't strictly adhere to the request format (since they'll know they're from a third-party app then), so we should ensure that the request is indistinguishable from a first-party one. I feel like it might've been failing because of the one-time-password thing I mentioned.Ī little speculation: based on the fact that the new API requires X-Mme-Device-Id and Anisette data, it seems like it'll be really easy to fingerprint devices. Re this, DSESSIONID definitely seems like it's being reused after the first request of the session. However, X-Apple-I-MD represents a one time password which changes between sessions, so updating that might be a little tricky (and once we know how to do that, it's worth updating the other headers too). It's possible to copy most of this data from an existing request and reuse it. Also this means we shouldn't be using clientDaw.cgi anymore – in fact I already have a working 2FA login system in Supercharge but that may have to go too, considering the whole AuthKit thing. X-Apple-I-MD: these headers appear to be related to Anisette ( more info), which replaces myacinfo.X-Apple-I-Client-Time, X-Apple-I-Locale, X-Apple-I-TimeZone: self-explanatory.The other source is AuthKit's headers ( appleIDHeadersForRequest:nil]).X-Apple-I-Identity-Id: ername (refer to GS-Token).I assume this is set while logging in, as it's stored in the keychain thereafter Note that this is not a "password" in the traditional sense, however it does represent a single developer account. X-Mme-Device-Id: uniqueDeviceIdentifier].X-MMe-Client-Info: serverFriendlyDescription] (AK = AuthKit).Firstly, some headers are "manually provided" ( -): The authenticationHeaders method appears to use two sources. To get all of the new headers, run error:nil] authenticationHeaders] while attached to the Xcode process Xcode seems to do most of the header-related magic in amework. I've been looking into this myself for Supercharge, and I made a few discoveries which I'd like to share here in the interest of figuring this out quickly (spoiler alert: if we want future-proofing, those three headers aren't enough).
0 Comments
Leave a Reply. |