[jkcoxson]

You can test it on my anisette server (ani.jkcoxson.com). Not sure if I did it correctly, you know the code base better than I do.

[illixion]

I've been chasing the same -80045 for my own sideloader, and found a couple of things that might
save you some time here.

Dadoum's server reports a Mac. The claim does need to match the anisette, which is what this
PR gets right. But Dadoum's anisette-v3-server, which most public servers run, always answers
/v3/client_info with <MacBookPro13,2> <macOS;13.1;22C65> <com.apple.AuthKit/1 (com.apple.akd/1.0)>,
while its anisette comes from Apple Music's Android libraries. So with this PR alone, those servers
still claim a Mac and still get -80045. I tested with a made-up Apple ID: same Android anisette,
same request and IP, only X-Mme-Client-Info changed:

X-Mme-Client-Info	Result
<Mac15,7> <macOS;27.0;26A5378j> <com.apple.AuthKit/1 (com.apple.akd/1.0)>	-80045
<PC> <Windows;6.2(0,0);9200> <com.apple.AuthKit/1 (com.apple.iCloud/7.21)>	-80045
<iPhone15,2> <iPhone OS;17.0;21A329> <com.apple.AuthKit/1 (com.apple.akd/1.0)>	-80045
<Pixel 8><Android; 14; UQ1A.240205.004><com.apple.AuthKit/1 (com.apple.android.music/4.9.6)>	accepted (-20101 for the made-up account)

ani.jkcoxson.com reports a Windows claim, so I assume it serves Windows anisette, where this PR
is right as it is.

The next wall, with a real account. With the Android claim, SRP completes with no au, so
login treats the account as signed in, but Apple still pushes a code to the trusted devices.
apptokens for com.apple.gs.xcode.auth answers -22411 ("This action cannot be completed at this
time") until that code is checked. The trusted-device requests (GET /auth for the phone numbers)
answer 401 for this session, but validateCode alone with the pushed code works. After signing in
again, the Xcode token comes back. Once that anisette identity is trusted, later sign-ins need no
code.

I've put both on top of this branch, in case they're useful:
illixion@9e28c0b

1. When the server reports Dadoum's fixed Mac string, claim Android instead.
2. After the password is accepted with an Android claim, login asks for the Xcode token. On
   -22411 it asks for the pushed code through the existing 2FA callback, checks it with
   validateCode, and signs in again. Callers don't change.

Tested against Dadoum's server with a free Apple ID: the first sign-in from a fresh state asked for
the pushed code once and got the Xcode token, and a second run with the same state needed no code.
In one of two first sign-ins, the sign-in after the code check got -22406 ("Enter the correct
password") with the same password; a fresh attempt worked, so I don't know yet if that was
transient.

Something I noticed while reading the resync path, though I haven't seen it trigger: after a
resync, the retried init sends the fresh cpd, but the proof request ("o": "complete") still
sends the cpd from before the resync. If Apple checks they match, that could fail the proof.

One thing it doesn't cover: accounts with no trusted devices (SMS codes only). With the Android
claim they get au=secondaryAuth, and every SMS request was refused for me so I didn't chase it further (401/403).

Happy to open it as a PR against this branch, or for you to take it as you like.

[jkcoxson]

Holy Claude comment

[illixion]

Haha, fair. Short version:

• Dadoum's server reports a Mac but serves Android anisette, so with this PR those servers still get -80045. Claiming Android for that one string fixes it.
• With the Android claim, apptokens returns -22411 until the code pushed to your devices is checked via validateCode.

Both are in illixion/isideload@9e28c0b if you want them.

[nab138]

Looks good to me. I will clean this up a bit later (should probably pull the gsa init request into a seperate method to avoid duplication), but in the interest of getting a patch out quickly I'll merge as is for now