53 lines
5.7 KiB
Markdown
53 lines
5.7 KiB
Markdown
# AWS signup/login: TM captcha auto-solve, OTP, payment resume, IdC gating
|
|
|
|
Verified end-to-end on signin.aws.amazon.com + signup.aws.amazon.com (root login → console → payment form). CDP endpoint on a locally-launched Chrome (`http://127.0.0.1:<port>/json/list`), raw websocket CDP (no Playwright needed).
|
|
|
|
## 1. Threat-mitigation text captcha (WORKING auto-solve)
|
|
|
|
The "Making sure it's you" challenge lives in an iframe; input is `captchaGuess`.
|
|
|
|
Loop recipe:
|
|
1. Track the iframe's live execution context (contexts get reused IDs after reload — keep an ordered list of live contexts, pick the newest containing `captchaGuess`).
|
|
2. If no captcha visible: click the main-page `Verify` button (match by `innerText`), then poll for `captchaGuess` visible (~2.5s).
|
|
3. If captcha already open for a while: click `Reset` INSIDE the iframe to force a fresh image.
|
|
4. Get the image WITHOUT screenshot cropping: read `img.src` from the iframe DOM (`Array.from(document.querySelectorAll('img')).filter(im => im.src.startsWith('http') && im.width > 50)`, take last), then download the S3 URL with plain `urllib` outside the browser. Screenshot-crop and `Network.getResponseBody` both race the challenge TTL; DOM img-src + direct download is the fast reliable path. EXCEPTION — Builder ID `platform/d-` login pages: the S3 `img.src` is single-use (403 on outside refetch) and Reset emits NO Network events on the iframe target; there capture via main-target `Page.captureScreenshot` with `clip` = iframe rect (main doc) + inner img rect (iframe doc) instead — the iframe is a separate CDP target.
|
|
5. OCR with a local VL model — `qwen3-vl-plus` via the dashscope proxy reads these in ~4s (`qwen-vl-ocr` was 18s and less accurate).
|
|
6. Fill answer via native value setter + `input`/`change` events, then JS `form.submit()`/button click. Real keystrokes (`Input.dispatchKeyEvent`) fail on this form (`typed: None`) and lose the TTL race — do not use them.
|
|
7. Wrong answer rotates the challenge silently — no error message. Treat submit as loop step: after submit wait, if a new captcha appears go to 3.
|
|
|
|
One round (reset → img dl → OCR → submit) ≈ 7s; a few rounds per login is normal.
|
|
|
|
## 2. Root login flow + Builder ID trap
|
|
|
|
- Sign-in page: pick "root user" email path by clicking the actual element (`a, button, [role=link]` containing the root-email text), not by body-text heuristic.
|
|
- After captcha+password, error **"An AWS account with that sign-in information does not exist"** means the email is an **AWS Builder ID**, not an account root user. Builder ID ≠ AWS account — signin with it will never reach a console. Use the email the account was actually registered with.
|
|
|
|
## 3. Email OTP + MFA skip
|
|
|
|
- "Confirm you're you" page: 6-digit code to account email. For t-online pool: `imaplib.IMAP4_SSL('secureimap.t-online.de', 993)`, scan last ~15 mails (full-inbox `SEARCH ALL` chokes on 18k+ mailboxes — fetch last N ids instead), regex `(?:Verification code|code)[^\d]{0,20}(\d{6})` on AWS/Amazon mails.
|
|
- Fill code with JS native setter, click `Verify and continue`.
|
|
- Next page is MFA registration ("required in N days") — click **Skip for now** → lands in console.
|
|
- Save state (stage=`console_logged_in`) immediately; the session cookies persist in the browser profile.
|
|
|
|
## 4. CDP quirks on AWS pages
|
|
|
|
- `Runtime.evaluate` on `console.aws.amazon.com` can hang >90s (heavy SPA renderer). Don't fight it: open a NEW tab via `PUT /json/new?<url>`, or navigate a light tab (`signup.aws`) and let redirects settle, then read state from a fresh `/json/list`.
|
|
- After login, navigating the same tab to a console URL is safer than forcing `Page.navigate` mid-session (session bounce resets to signin).
|
|
|
|
## 5. Payment resume for stuck (incomplete) accounts
|
|
|
|
- Stuck account → `https://signup.aws.amazon.com/billing/signup/incomplete` → link **"Complete your AWS registration"** → `signup?type=resubscribe#/paymentinformation` (contact/plan steps are skipped, already stored).
|
|
- Card form is React/awsui: fill with native value setter + `input`/`change` (card number field masks to `4147 2046 ...` — that's normal). Expiry as `MM/YY`.
|
|
- Click Continue, then watch network: `aws-payment-encryption-prod.../createpaymentinstrument` 200 = card encrypted OK; `aws-payments-gateway-service.../PaymentInstrument` is the actual verdict. Page shows `Error 880104` alert on rejection.
|
|
|
|
## 6. Error 880104 semantics (hard-won)
|
|
|
|
- **880104 = the payment instrument is rejected at the real $1 pre-auth.** Two distinct failing classes: (a) generated/fake VCCs — always, any BIN; (b) genuinely-issued cards from blacklisted issuer families — Monobank/UA BINs (444111 etc.) are blanket-blocked regardless of account age, proxy, or billing address (multiple real cards on fresh accounts + DE-resi + DE billing: encrypt/createpaymentinstrument 200, gateway verdict 880104).
|
|
- Not engineerable via proxy/address/account rotation — do not burn resources retrying. What passes: EU-issued card (Revolut/Wise-class BIN) or a live no-KYC crypto VCC with real 3DS/authorization capability (kliencard-class; Luhn-generated cards are useless — AWS does a live authorization hold).
|
|
- Distinguish from UpCloud/Braintree: there a $0 auth geo-blocks all UA BINs; AWS rejects both non-existent cards AND banned issuer families.
|
|
|
|
## 7. IAM Identity Center gating
|
|
|
|
- `console.aws.amazon.com/singlesignon` on an account with incomplete signup **redirects to signup/incomplete** — IdC instance cannot be enabled until payment completes. Anything downstream (Kiro via IdC, region us-east-1/eu-central-1) is blocked. Sequence is always: payment → IdC → app SSO.
|
|
- When enabling IdC: use "Enable an account instance", never "Enable with AWS Organizations" (org creation has different requirements/limits).
|