whalibmob 5.12.16 → 5.13.1

package/.env.example

@@ -4,7 +4,10 @@
 #
 #     cp node_modules/whalibmob/.env.example .env
 #
-# The CLI loads `.env` from the current working directory automatically.
+# The CLI loads `.env` from the current working directory automatically — from
+# the directory the command runs in, not from where whalibmob is installed. Run
+# `wa` somewhere else and this file does not apply; export the variables in your
+# shell profile instead if you want them everywhere.
 # If you use the library programmatically, call `require('dotenv').config()`
 # yourself before creating a client.
 #
@@ -17,6 +20,19 @@
 # Values: ios | android
 # WA_OS=ios
 
+# Register as WhatsApp Business instead of the consumer app.
+# Values: 1 | true | yes | on  (anything else, or unset, means the consumer app)
+#
+# This has to be set before the code is requested: an account is created as
+# Business or as consumer, and the token, the User-Agent and the verified-name
+# certificate all have to keep saying which. A session already part-way through
+# registering keeps what it started as and says so.
+#
+# On Android the token material is read from com.whatsapp.w4b rather than
+# com.whatsapp, and is cached in its own file, so the two never overwrite each
+# other. On iOS the version comes from the Business App Store listing.
+# WA_BUSINESS=1
+
 # Named predefined device profile. Takes priority over the individual
 # WA_DEVICE_* variables below.
 #
@@ -51,15 +67,25 @@
 
 
 # ─── WhatsApp version ────────────────────────────────────────────────────────
-# Pin the WhatsApp client version. When set, the live version lookup is skipped
-# entirely, and this is what is announced on connect in place of the version
-# stored in the session. Leave unset to fetch the current version automatically.
-#
-# On Android this is normally not needed: the version comes from the APK the
-# token material was read from. On iOS it is looked up on the App Store, and a
-# lookup that fails leaves a built-in fallback version in the session — which
-# the server refuses at connect with a 405. That is what this is for.
-# WA_VERSION=2.24.10.75
+# LEAVE THIS UNSET. It is a temporary override, not a setting.
+#
+# When set, the live version lookup is skipped and this value is announced on
+# connect in place of the version the session was registered with — every
+# connect started from this directory, for every number, until it is removed.
+# The version WhatsApp accepts moves on every few weeks, so a value left here
+# eventually refuses every connect with `<failure reason="405">`, on sessions
+# that were working the day before. It is the single most common cause of that
+# error.
+#
+# On Android it is never needed: the version comes out of the APK the
+# registration token was signed over, which is the build the token actually
+# proves. Pinning something else here makes the two describe different builds.
+#
+# On iOS it is the escape hatch: the version is looked up on the App Store, and
+# a lookup that times out leaves a built-in fallback in the session that the
+# server may refuse. Pin a current version, connect, then remove the line —
+# uncomment this only when you have a 405 and a version to put in it.
+# WA_VERSION=
 
 # Override the static registration token. iOS only — Android has no static token
 # and signs its own out of the APK (see below). Leave unset to use the built-in

package/README.md

@@ -121,6 +121,7 @@ npm install -g whalibmob
   - [Connecting Account](#connecting-account)
     - [Register a New Number](#register-a-new-number)
     - [Registering as Android](#registering-as-android)
+    - [Registering a WhatsApp Business account](#registering-a-whatsapp-business-account)
       - [Why an APK is involved at all](#why-an-apk-is-involved-at-all)
       - [Fetching the APK on its own](#fetching-the-apk-on-its-own)
       - [Reading it out of an APK you already have](#reading-it-out-of-an-apk-you-already-have)
@@ -255,6 +256,7 @@ npm install -g whalibmob
   - [Custom Device Fields](#custom-device-fields)
   - [Version & Token Overrides](#version--token-overrides)
   - [When the server answers 405 on connect](#when-the-server-answers-405-on-connect)
+  - [Finding out what a 405 objects to](#finding-out-what-a-405-objects-to)
 
 ---
 
@@ -399,6 +401,14 @@ Use a custom session directory with `--session`:
 wa connect 919634847671 --session /data/my-sessions
 ```
 
+> [!IMPORTANT]
+> **If this is refused with `405`, do not re-register the number.** The account
+> is fine; the server declined the version the connect announced. Check for a
+> `WA_VERSION` in your shell or in a `.env` file in the directory you ran the
+> command from — it overrides the version the session registered with, and a
+> stale one left there refuses every connect from that directory. See
+> [When the server answers 405 on connect](#when-the-server-answers-405-on-connect).
+
 ### CLI Pairing Code
 
 If the number is already in use on a phone, or the verification SMS never arrives, link to the existing account instead. When it is not obvious which way you mean, `wa connect` asks:
@@ -1635,6 +1645,47 @@ unasked, and `wa apk-material` below does the same job by hand.
 The rest of this section is what happens behind that one command, and how to
 drive each part yourself.
 
+### Registering a WhatsApp Business account
+
+Set `WA_BUSINESS`, or pass `--business`, and the whole registration switches to
+the Business build:
+
+```sh
+WA_OS=android WA_BUSINESS=1 wa registration --request-code 919634847671
+wa registration --register 919634847671 --code 123456
+wa connect 919634847671
+```
+
+Everything that names the app follows from that one variable:
+
+| | consumer | Business |
+|---|---|---|
+| announced platform | `ANDROID` / `IOS` | `ANDROID_BUSINESS` / `IOS_BUSINESS` |
+| User-Agent | `Android/…` · `iOS/…` | `SMBA/…` · `SMB iOS/…` |
+| Android token material | `com.whatsapp` | `com.whatsapp.w4b` |
+| iOS token constant | consumer | Business |
+| version lookup | consumer listing | Business listing |
+| `vname` field | not sent | a self-signed verified-name certificate |
+| Frida attestation port | 1119 | 1120 |
+
+The Android token material lives in its own file
+(`android-apk-material-business.json`), so the two builds never overwrite each
+other and `wa apk-material --download --business` can sit beside the consumer
+one.
+
+`vname` is a `VerifiedNameCertificate` the client signs itself, carrying an
+empty name, the issuer `smb:wa` and a random serial. The name is empty because
+nothing is verified yet — WhatsApp issues the real one after it reviews the
+business. What the server checks is that the signature over those details was
+made with the identity key the same request registers.
+
+> [!IMPORTANT]
+> **Decide before the code goes out.** An account is created as Business or as
+> consumer, and the token, the User-Agent and the certificate all have to keep
+> saying which. A session that is already part-way through registering keeps
+> what it started as and says so rather than flipping halfway; delete the
+> session file to start it over as the other one.
+
 #### Why an APK is involved at all
 
 The registration token is computed differently on each platform, and only iOS
@@ -2163,7 +2214,7 @@ Every event from the SMS primary API fires here too — `message`, `receipt`, `p
 | `pair_device` | `{ refs }` | the QR path produced reference strings |
 | `history_sync` | `{ syncTypeName, chats, contacts, pushNames, merged }` | a chunk of history arrived |
 | `history_sync_error` | `{ err, notification }` | a chunk could not be fetched or decrypted |
-| `client_rejected` | `{ reason, location, message }` | the server refused the client itself, not the session — `405` means the announced version is not accepted. Distinct from `auth_failure`, and there is nothing to re-pair. |
+| `client_rejected` | `{ reason, location, message }` | the server refused the client itself, not the session — `405` means the announced version is not accepted. Fires whether the refusal arrives during the handshake or once the stream is open, and the client stops retrying either way. Distinct from `auth_failure`, and there is nothing to re-pair. |
 
 ### Reading What the Phone Sent
 
@@ -4467,47 +4518,176 @@ These variables override individual fields on top of the selected profile:
 
 | Variable | Description |
 |---|---|
-| `WA_VERSION` | Pin the WhatsApp version (e.g. `2.24.13.80`). Skips the live store fetch, and is announced on connect in place of the version stored in the session. |
-| `WA_STATIC_TOKEN` | Override the static token used in registration token computation. iOS only — Android has no static token. |
+| `WA_VERSION` | Pin the WhatsApp version (e.g. `2.24.13.80`). Skips the live store fetch, and is announced on connect **in place of the version stored in the session**. The CLI also reads it from a `.env` file in the working directory, so one left there is announced by every connect from that directory — which is how a working session starts being refused with [405](#when-the-server-answers-405-on-connect). Pin it deliberately, unset it when done. |
+| `WA_STATIC_TOKEN` | Override the static token used in registration token computation. iOS only — Android has no static token. Overrides both the consumer and the Business constant. |
+| `WA_BUSINESS` | Register and connect as WhatsApp Business (`1`/`true`/`yes`/`on`). Decides the announced platform, the User-Agent, which APK the token material comes from, and the `vname` certificate. See [Registering a WhatsApp Business account](#registering-a-whatsapp-business-account). |
 
 ### When the server answers 405 on connect
 
 ```
-WhatsApp auth failure 405 — client outdated — the version this session
-announces is not one the server accepts.
+WhatsApp auth failure 405 — client outdated. The server refused the version
+this connect announced, which was 2.24.10.75. That value came from WA_VERSION
+in the environment — the CLI also reads it out of a .env file in the directory
+it runs from — while the session itself holds 2.26.29.73.
 ```
 
 **The session is fine and the number is still registered.** 405 is the server
-declining the *client*, not the account: the version being announced is one it no
-longer accepts. Registering the number again is the one move that cannot help —
-the same version would go out and be refused identically, at the cost of a real
+declining the *client*, not the account: the version being announced is not one
+it accepts. Registering the number again is the one move that cannot help — the
+same version would go out and be refused identically, at the cost of a real
 phone number and a code request.
 
-Announce a current version instead:
+Connecting announces exactly one version, and there are only two places it can
+come from:
+
+| order | where the announced version comes from |
+|---|---|
+| 1 | `WA_VERSION`, from the shell **or from a `.env` file in the directory the command runs in** |
+| 2 | the version stored in the session file — what the number was registered with |
+
+Almost every 405 is the first line winning when nobody meant it to.
+
+#### Check `WA_VERSION` before anything else
+
+The CLI loads `.env` from the working directory before it does anything else, so
+a `WA_VERSION` left in that file is announced by *every* connect started from
+that directory — in place of the version the session registered with, which the
+server would have accepted. Nothing about the session changes, so the failure
+looks like a dead account and is not one.
+
+```sh
+grep -i wa_version .env ~/.env
+env | grep WA_VERSION
+```
+
+Remove or comment the line, then connect again. Since 5.12.17 you do not have to
+go looking: the CLI says so before it connects,
+
+```
+warning: WA_VERSION=2.24.10.75 is pinned (shell or .env in /home/you) —
+connecting announces it instead of the version stored in the session.
+```
+
+and a 405 names the version that went out and which of the two places it came
+from, because that decides the remedy — unset the override, or pin a newer one.
+
+Pin `WA_VERSION` deliberately and temporarily, to force one specific build:
 
 ```sh
 WA_VERSION=2.26.30.3 wa connect 919634847671
 ```
 
-Or put `WA_VERSION` in the `.env` file, where it applies to every command.
+Leaving it in `.env` means every session on that machine announces it until the
+day it goes stale, wherever those sessions came from.
 
-**Where the stale version comes from.** Each platform learns its version
-differently:
+#### Keeping the session's own version current
+
+With no override, the session announces the version it was registered with, and
+each platform learns that differently:
 
 | | how the version is found | what happens when that fails |
 |---|---|---|
 | iOS | looked up on the App Store | falls back to a version compiled into the library, which goes stale |
-| Android | read from the APK the token material came from | `wa apk-material --download` fetches the current one |
+| Android | read from the APK the registration token material came from | `wa apk-material --download` fetches the current one |
+
+**That version is written once, at registration, and nothing else ever touches
+it.** A number registered today announces today's version next year too, and one
+day the server stops accepting it — a 405 with nothing wrong with the account.
+Refreshing the APK material does not reach the sessions already on disk.
 
-So this is mostly an iOS story: a lookup that times out or is rate limited leaves
-a months-old fallback version in the session, and nothing says so until the
-handshake is refused. On Android the version travels with the APK, and refreshing
-the material refreshes the version with it:
+`wa refresh-version` is the part that does:
 
 ```sh
-wa apk-material --download
+wa apk-material --download        # Android: pick up the current APK first
+wa refresh-version 5568936182750  # then write its version into the session
 ```
 
+```
++5568936182750  android       2.24.10.75  →  2.26.30.5
+
+  1 session(s) updated
+  read from the APK the token material came from.
+  reconnect for it to be announced.
+```
+
+It touches `version` and nothing else — the keys, the device profile and the
+registration are left exactly as they were. `--all` does every session in the
+session directory, which is what belongs in a monthly cron for a bot that is
+meant to stay up:
+
+```sh
+wa apk-material --download && wa refresh-version --all
+```
+
+`--version 2.26.30.5` writes one you name instead of looking one up. And if
+`WA_VERSION` is set, the command says so — the override would mask whatever it
+writes.
+
+From Node, the same thing:
+
+```js
+const { refreshSessionVersion, currentVersionFor } = require('whalibmob')
+
+await refreshSessionVersion('/home/you/.waSession/5568936182750.json')
+await currentVersionFor({ os: 'android' })   // { version, source }
+```
+
+#### If every Android session is refused, whatever the version
+
+Then it is the library, not the version — update it. Until 5.12.15 the Android
+device profiles announced platform `3`, which is BlackBerry, a client WhatsApp
+stopped building in 2017. The server validates the announced app version
+*against the platform it was announced with*, so a current Android build arrived
+looking like an impossible BlackBerry one, and nothing in the failure named the
+platform. iOS announced `1` and was never affected.
+
+Sessions written before the fix repair themselves the next time they are loaded
+— the platform is derived from the profile's `os` rather than trusted from the
+file — so nothing has to be registered again.
+
+One other field in the same payload was wrong rather than merely unusual:
+`connectType` sent `3` on every reconnect, and the enum has no `3` — the legal
+values are `0` (cellular, unknown radio), `1` (wifi) and `100`–`112` for the
+named cellular radios. It now sends `1`.
+
+Nothing else in the payload changed. Other clients announce no carrier
+(`mcc`/`mnc` as `000`) and `en`/`US` regardless of the number; this library
+announces the carrier and locale the number actually belongs to, and a live
+session was tried against the server both ways — neither is refused. `000/000`
+is what a handset with no SIM reports, so a number with a carrier behind it
+saying so is the more ordinary thing to be.
+
+### Finding out what a 405 objects to
+
+When the version is right and the connect is still refused, stop guessing:
+`tools/diagnose-405.js` runs the login once per payload variation and prints
+what the server answered each time.
+
+```sh
+node tools/diagnose-405.js 5568936182750
+
+# installed globally:
+node $(npm root -g)/whalibmob/tools/diagnose-405.js 5568936182750
+```
+
+```
+what this library sends           ok — LOGIN ACCEPTED
+  without the carrier (000/000)   ok — LOGIN ACCEPTED
+  without the locale (en/US)      ok — LOGIN ACCEPTED
+```
+
+`405` means that row was refused, `401` means the client was accepted and only
+the credentials failed, `ok` means the login went through. The first row is what
+a real connect puts on the wire, and each row after it changes exactly one
+field, so a row that behaves differently from the first names the field the
+server objected to. Every row uses the session already on disk: nothing is
+registered, no code is requested, and the session is never written to.
+`--dry-run` prints the payload sizes without opening a socket.
+
+**If the first row is accepted while `wa connect` is refused, the payload is not
+the problem.** The difference is then in what the CLI reads and this tool does
+not — `WA_VERSION`, from `.env`. Go back to the top of this section.
+
 ## License
 
 MIT

package/cli.js

@@ -957,6 +957,17 @@ async function doConnectWeb(phone, opts) {
 
 async function doConnect(phone) {
   phone = normalizePhone(phone);
+
+  // A WA_VERSION left in .env is announced by every connect from this
+  // directory, in place of the version the session was registered with, and a
+  // stale one is refused with a 405 that says nothing about where the value
+  // came from. Say it out loud before connecting rather than after failing.
+  if (process.env.WA_VERSION) {
+    warn('WA_VERSION=' + process.env.WA_VERSION + ' is pinned (shell or .env in ' +
+         process.cwd() + ') — connecting announces it instead of the version ' +
+         'stored in the session. Unset it to use the session\'s own.');
+  }
+
   const client = new WhalibmobClient({ sessionDir: _sessDir });
   attachEvents(client);
 
@@ -2347,6 +2358,7 @@ usage:
   wa registration --check <phone>
   wa apk-material <base.apk> [split.apk ...]  read the Android token material
   wa apk-material --download                  fetch that APK from Google Play
+  wa refresh-version <phone>                  update the version a session announces
   wa version
 
 options:
@@ -2356,6 +2368,9 @@ options:
   --pair            connect by linking to an existing account (8-digit code)
   --method          sms | voice | wa_old | email  (default: sms)
   --email <address> email address (required when --method email)
+  --business        register/connect as WhatsApp Business (same as WA_BUSINESS=1)
+  --all             refresh-version: every session in the session directory
+  --version <x>     refresh-version: write this version instead of looking one up
 
 debug:
   an interactive session asks once whether to trace the protocol.
@@ -2437,6 +2452,12 @@ async function main() {
 
   _sessDir = flags.session || defaultSessionDir();
 
+  // `--business` is the flag form of WA_BUSINESS, mapped onto the environment
+  // before anything reads a device profile. The device config is env-driven, so
+  // this is the whole of it: the profile, the token material, the version
+  // lookup and the vname certificate all follow from that one variable.
+  if (flags.business) process.env.WA_BUSINESS = '1';
+
   if (!cmd) {
     out('whalibmob v' + VERSION + '  —  type /help for commands');
     openShell();
@@ -2454,6 +2475,67 @@ async function main() {
     return;
   }
 
+  // Bring a session's stored version up to date.
+  //
+  // A session announces the version it registered with, forever — nothing else
+  // writes that field, so a number registered today is still announcing today's
+  // version next year, and one day the server stops accepting it. Refreshing
+  // the APK material does not reach the sessions already on disk; this does.
+  // Run it after `wa apk-material --download`, or on a schedule.
+  if (cmd === 'refresh-version') {
+    const { refreshSessionVersion } = require('./lib/Registration');
+    const one = normalizePhone(sub || '');
+
+    if (!one && !flags.all) {
+      fail('usage: wa refresh-version <phone>   (or --all for every session)');
+      process.exit(1);
+    }
+
+    let files;
+    if (flags.all) {
+      try {
+        files = fs.readdirSync(_sessDir)
+          .filter(f => /^\d+\.json$/.test(f))
+          .map(f => path.join(_sessDir, f));
+      } catch (_) { files = []; }
+      if (!files.length) { fail('no sessions in ' + _sessDir); process.exit(1); }
+    } else {
+      files = [path.join(_sessDir, one + '.json')];
+    }
+
+    if (process.env.WA_VERSION) {
+      warn('WA_VERSION=' + process.env.WA_VERSION + ' is set — connecting will announce ' +
+           'that instead of what this command writes. Unset it for the refresh to take effect.');
+    }
+
+    let changed = 0, failed = 0;
+    const sources = new Set();
+    for (const file of files) {
+      try {
+        const r = await refreshSessionVersion(file, flags.version ? { version: flags.version } : null);
+        const who = '+' + r.phoneNumber + '  ' + r.os + (r.business ? '/business' : '');
+        if (r.changed) {
+          changed++;
+          sources.add(r.source);
+          out(who.padEnd(30) + r.before + '  →  ' + r.after);
+        } else {
+          out(who.padEnd(30) + r.after + '  (already current)');
+        }
+      } catch (e) {
+        failed++;
+        fail(path.basename(file) + ': ' + e.message);
+      }
+    }
+
+    out('');
+    out('  ' + changed + ' session(s) updated' + (failed ? ', ' + failed + ' failed' : ''));
+    if (changed) {
+      out('  read from ' + [...sources].join(', ') + '.');
+      out('  reconnect for it to be announced.');
+    }
+    process.exit(failed ? 1 : 0);
+  }
+
   // Read the Android registration token material out of a WhatsApp APK.
   //
   // Registering as Android signs its token with the APK's own signing
@@ -2468,9 +2550,15 @@ async function main() {
       out('       wa apk-material --download        fetch the APK from Google Play instead');
       process.exit(1);
     }
+    // The Business build gets its own file: it is signed with different
+    // certificates and carries a different classes.dex, so its token cannot be
+    // computed from the consumer material. `wa apk-material --download` and
+    // `--download --business` therefore do not overwrite each other.
     const outFile = flags.out ||
       process.env.WA_ANDROID_APK_MATERIAL ||
-      path.join(_sessDir, 'android-apk-material.json');
+      path.join(_sessDir, flags.business
+        ? 'android-apk-material-business.json'
+        : 'android-apk-material.json');
     try {
       const AndroidApk = require('./lib/AndroidApk');
       let material;

package/index.js

@@ -2,7 +2,7 @@
 
 const { WhalibmobClient, checkNumberStatus, fetchIosVersion, fetchWaVersion, assertRegistrationKeys } = require('./lib/Client');
 const { getDeviceConfig } = require('./lib/DeviceConfig');
-const { fetchAndroidVersion } = require('./lib/Registration');
+const { fetchAndroidVersion, currentVersionFor, refreshSessionVersion } = require('./lib/Registration');
 const { createNewStore, saveStore, loadStore, toSixParts, fromSixParts, storeToJson, storeFromJson } = require('./lib/Store');
 const { checkIfRegistered, requestSmsCode, verifyCode } = require('./lib/Registration');
 const { SignalProtocol } = require('./lib/signal/SignalProtocol');
@@ -65,6 +65,10 @@ module.exports = {
   fetchWaVersion,
   fetchIosVersion,
   fetchAndroidVersion,
+  // What a device profile should be announcing now, and writing it into a
+  // session that registered long enough ago to have gone stale.
+  currentVersionFor,
+  refreshSessionVersion,
   // Device config — reads WA_OS / WA_DEVICE / WA_DEVICE_* from process.env
   getDeviceConfig,
   // Store helpers

package/lib/Attestation.js

@@ -23,7 +23,8 @@
 const crypto = require('crypto');
 const http   = require('http');
 
-const DEFAULT_PORT   = 1119;   // WhatsApp consumer; Business build listens on 1120
+const DEFAULT_PORT   = 1119;   // WhatsApp consumer
+const BUSINESS_PORT  = 1120;   // the Business build's own attestation server
 const REQUEST_TIMEMS = 15000;
 
 // ─── Empty (NONE) fallbacks ───────────────────────────────────────────────────
@@ -36,8 +37,12 @@ function fridaHost() {
   return process.env.WA_FRIDA_HOST || null;
 }
 
-function fridaPort() {
-  return parseInt(process.env.WA_FRIDA_PORT, 10) || DEFAULT_PORT;
+// The Business build's attestation server listens on its own port, because a
+// device can have both apps installed and each hooks its own process. An
+// explicit WA_FRIDA_PORT still wins over both.
+function fridaPort(device) {
+  return parseInt(process.env.WA_FRIDA_PORT, 10) ||
+    ((device && device.business) ? BUSINESS_PORT : DEFAULT_PORT);
 }
 
 function isEnabled() {
@@ -62,7 +67,7 @@ function toHex(buf) {
 // Returns the parsed JSON object on success, or null on any failure/timeout so
 // the caller can fall back to the empty NONE attestation.
 
-function fridaGet(pathname, query) {
+function fridaGet(pathname, query, device) {
   return new Promise((resolve) => {
     const host = fridaHost();
     if (!host) return resolve(null);
@@ -75,7 +80,7 @@ function fridaGet(pathname, query) {
       : '';
 
     const req = http.request(
-      { host, port: fridaPort(), path: pathname + qs, method: 'GET', timeout: REQUEST_TIMEMS },
+      { host, port: fridaPort(device), path: pathname + qs, method: 'GET', timeout: REQUEST_TIMEMS },
       (res) => {
         const chunks = [];
         res.on('data', d => chunks.push(d));
@@ -99,9 +104,9 @@ function fridaGet(pathname, query) {
 // leaves them empty — the server accepts a gpia-only attestation.
 //
 // nonceB64 is the URL-safe base64 request nonce (see attestationFieldsAndroid).
-async function androidIntegrity(nonceB64) {
+async function androidIntegrity(nonceB64, device) {
   if (!isEnabled()) return { ...EMPTY_ANDROID };
-  const res = await fridaGet('/integrity', { authKey: nonceB64 });
+  const res = await fridaGet('/integrity', { authKey: nonceB64 }, device);
   if (!res || !res.token) return { ...EMPTY_ANDROID };
   return { gpia: res.token, gg: '', gi: '', gp: '', ge: '', ga: '' };
 }
@@ -117,18 +122,18 @@ async function androidIntegrity(nonceB64) {
 //             server signs exactly those bytes.
 // The server returns { signature, certificate }: signature → the &H= body
 // suffix, certificate → the Authorization cert-chain header.
-async function androidAttestBody(encB64, authKeyB64) {
+async function androidAttestBody(encB64, authKeyB64, device) {
   if (!isEnabled()) return { ...EMPTY_BODY };
   const encParam = Buffer.from(encB64, 'utf8').toString('base64');
-  const res = await fridaGet('/cert', { authKey: authKeyB64, enc: encParam });
+  const res = await fridaGet('/cert', { authKey: authKeyB64, enc: encParam }, device);
   if (!res || !res.signature || !res.certificate) return { ...EMPTY_BODY };
   return { bodyAttestation: res.signature, authorizationHeader: res.certificate };
 }
 
 // ─── Android: device /info (apk hashes / signature / secret key) ──────────────
-async function androidInfo() {
+async function androidInfo(device) {
   if (!isEnabled()) return null;
-  return fridaGet('/info');
+  return fridaGet('/info', null, device);
 }
 
 // ─── iOS: App Attest (attestation + assertion + keyId) ────────────────────────
@@ -137,9 +142,9 @@ async function androidInfo() {
 // { attestation, assertion }; the keyId is generated per call on-device and
 // echoed by the server when available. clientDataHash is the base64 of the
 // Noise public key (the server SHA-256-hashes it internally).
-async function iosAppAttest(noisePubB64) {
+async function iosAppAttest(noisePubB64, device) {
   if (!isEnabled()) return { ...EMPTY_IOS };
-  const res = await fridaGet('/integrity', { authKey: noisePubB64 });
+  const res = await fridaGet('/integrity', { authKey: noisePubB64 }, device);
   if (!res || !res.attestation || !res.assertion) return { ...EMPTY_IOS };
   return {
     attestation: res.attestation,
@@ -171,7 +176,7 @@ async function attestationFields(device, nonceB64, opts) {
   const pushToken = orNull(opts.pushToken);
 
   if (device && device.os === 'android') {
-    const a = await androidIntegrity(nonceB64 || '');
+    const a = await androidIntegrity(nonceB64 || '', device);
     return [
       'gpia',       orNull(a.gpia),
       '_gg',        orNull(a.gg),
@@ -197,9 +202,9 @@ async function attestationFields(device, nonceB64, opts) {
 async function attestBody(encB64, device, keys) {
   keys = keys || {};
   if (device && device.os === 'android') {
-    return androidAttestBody(encB64, keys.noisePubB64 || '');
+    return androidAttestBody(encB64, keys.noisePubB64 || '', device);
   }
-  const data = await iosAppAttest(keys.noisePubB64 || '');
+  const data = await iosAppAttest(keys.noisePubB64 || '', device);
   if (!data.attestation || !data.assertion || !data.keyId) return { ...EMPTY_BODY };
   return {
     bodyAttestation:     '{"assertion":"' + data.assertion + '"}',

package/lib/Client.js

@@ -705,6 +705,26 @@ class WhalibmobClient extends EventEmitter {
    * Anything the handshake marked as a spent session stops the loop here.
    */
   _onSocketError(err) {
+    // The server declined the client, not the session. The next attempt
+    // announces exactly the same thing and is refused exactly the same way, so
+    // this stops here instead of retrying once a second forever. _handleFailure
+    // already reads a 405 this way, but it only runs once a stream is open — a
+    // 405 during the handshake never reached it, which is why a refused client
+    // reconnected in a loop.
+    if (err && String(err.code) === '405') {
+      _whaDbg('[DBG] HANDSHAKE_REJECTED code=405 — client refused, not a dead session');
+      this._fatal       = true;
+      this._reconnecting = false;
+      this.emit('client_rejected', {
+        reason:   '405',
+        location: null,
+        message:  err.message,
+        node:     null
+      });
+      this.emit('error', err);
+      return;
+    }
+
     if (err && err.loggedOut) {
       _whaDbg('[DBG] HANDSHAKE_REJECTED code=' + err.code + ' — not retrying');
       this._fatal = true;