pwnapplehat/iPASide v1.2.11

iPASide 1.2.11

on GitHub

Apple ID sign-in no longer dead-ends at the text-message step, and a refused text now explains itself (#12).

What was wrong. When Apple asks for a code by text message, iPASide always asked it to text phone number id 1. That is a guess that is only right for an account with a single number that was never replaced. On the reporter's account Apple answered the request with HTTP 403 and sign-in stopped before any code screen appeared. The same 403 is reported by iloader users.

What changed.

• iPASide now asks Apple for the account's trusted phone numbers and texts a real one (preferring a number Apple delivers by text). The code is submitted for the same number. If Apple cannot list the numbers, the old default is used, so accounts that worked keep working.
• A refused text now says so ("Apple would not text a verification code (HTTP 403)") and quotes Apple's own explanation when it gives one, instead of a generic connection error.
• If Apple had already pushed a code to the person's devices during the same sign-in, iPASide now asks for that code when the text is refused. Replies that mean "a code is already on its way" (Apple's -22979 / -22981 and an open challenge) are accepted, so you are asked for the last code instead of being blocked.
• gsa-trace.log now records Apple's error code and how many trusted numbers it listed for these steps, never a number or a message.

Verified. 693 engine tests and 799 app tests pass, including a clean run on fresh dependencies in CI; each of 16 deliberate breaks of the new logic was caught by a test; the unchanged parts of sign-in (trusted-device codes) are covered by the existing tests. The installer was built clean; installed over 1.2.10 it verified itself (the engine answered as 1.2.11) and the saved Apple ID kept working.
Not verified. That this fixes the reporter's account, and anything involving a connected iPhone (none was connected for this build's checks). Apple's 403 has no readable explanation in the log, so a wrong number id is the most likely cause, not a confirmed one. I could not reproduce it because it depends on that Apple ID, and I did not run a live text-message sign-in with this build. If it still fails, the red message now says which step Apple refused, and %LOCALAPPDATA%\iPASide\gsa-trace.log has the rest.

The installer is unsigned, so SmartScreen will warn — the SHA-256 is in SHA256SUMS.txt.