[whydr4]

Since October 13 every sign-in from AltServer 1.8.1 fails with -80045 (This action cannot be completed at this time). That's what people are reporting in #1828, and Sideloadly, SideStore and iloader all started failing the same day.

AnisetteKit provisions an Android device, but the anisette data we pass to AltSign still describes a Mac in X-MMe-Client-Info (it comes from AnisetteConstants.defaultClientInfo). Apple seems to have started checking that the two match. I sent the same GsService2 init request with the same Android provisioned anisette data twice, once with the Mac client info and once with a Pixel one. The Mac one gets -80045 back and the Pixel one goes through to the normal account checks. iloader shipped the same change in 2.3.7 and it fixed sign-in for them.

So LocalAnisetteDataManager now puts the Android client info into ALTAnisetteData. Provisioning itself is untouched and still uses AnisetteKit's default client info. isideload found that the lookup endpoint returns a different URL bag to Android clients, so I didn't want to change that part without a reason.

After that, accounts with 2FA run into -22411 right after the password step, because Apple now sends the code on its own and answers with hsc 409 instead of setting au. That part is fixed in rileytestut/AltSign#59. This PR bumps the submodule to that commit and sets ALTAppleAPI.anisetteDataRefreshHandler so AltSign can fetch fresh anisette data between steps. If you'd rather look at the AltSign change on its own first, I'm happy to drop the submodule bump from here.

Tested on macOS 27.0.1 with an iPhone 13 mini on iOS 27 and a free Apple ID with 2FA. Installing AltStore from AltServer works, and refreshing apps from AltStore over USB works too.

[kisnner26]

Heads up: since Oct 14 (~20:50 UTC) gsa.apple.com answers requests with the Pixel 7 client info with a 503 HTML page, so this approach stopped working shortly after it was opened. I tested a build of classic + this PR at 03:40 UTC on Oct 15 and got exactly that ("The data is not in the correct format" / NSCocoaErrorDomain 3840). iloader/isideload hit the same thing (nab138/iloader#920, #921).

What passes now is Windows anisette (iTunes ADI) from an anisette v3 server, with the server's own client info and user agent. I built on your AltSign 2FA fix (rileytestut/AltSign#59) and opened #1834 + rileytestut/AltSign#61, tested end-to-end (sign-in, 2FA, AltStore installed on iPadOS 27.2). Credited you in both. Thanks for the groundwork.

[whydr4]

Thanks for the heads up and for picking this up. I can reproduce it here too. An init request with the Pixel 7 client info now gets the 503 HTML page back, while Windows anisette from ani.jkcoxson.com with the server's own client info gets a normal plist answer. So the Android approach is dead and #1834 is the way to go. Closing this one in favor of it.