whalibmob 5.17.0 → 5.19.0

package/README.md

@@ -1788,9 +1788,9 @@ This runs by itself on a registration that finds no material. To do it separatel
 wa apk-material --download
 ```
 
-It is the route Cobalt takes: an anonymous Play Store token from the Aurora OSS
-dispenser, then Google's own `/fdfe` catalogue and delivery endpoints, then the
-signed CDN URLs. **No Google account of yours is involved.** Only the density
+The route is an anonymous Play Store token from the Aurora OSS dispenser, then
+Google's own `/fdfe` catalogue and delivery endpoints, then the signed CDN URLs.
+**No Google account of yours is involved.** Only the density
 splits are downloaded — the token's key comes from `about_logo.png`, which lives
 in one of those, and the architecture and language splits would be a hundred
 megabytes nothing here reads.
@@ -2322,6 +2322,8 @@ Every event from the SMS primary API fires here too — `message`, `receipt`, `p
 | `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. 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. |
+| `version_update` | `{ from, to, source }` | the announced version was refreshed from the platform's store before a handshake. Fires on reconnects as well as the first connect |
+| `apk_material_stale` | `{ materialVersion, liveVersion, hint }` | Android only: the Play Store listing has moved past the APK the cached token material came from. Nothing is broken — registration is what reads that material — but the next number registered from this install would go out under an older build |
 
 ### Reading What the Phone Sent
 
@@ -2585,40 +2587,53 @@ A session records the version it registered with. Left alone it announces that
 same number forever, so a number registered in spring is still claiming a spring
 build in autumn, and one day the connect simply stops working.
 
-**iOS sessions now refresh themselves.** On every `init()` the client asks the
-App Store what the current build is and writes it into `<phone>.json` before the
-handshake. Nothing to run, nothing to remember:
+**Sessions refresh themselves, on both platforms.** Before every handshake the
+client asks the platform's store what the current build is and writes it into
+`<phone>.json`. iOS reads the App Store listing, Android the Play Store one.
+Nothing to run, nothing to remember:
 
 ```js
-client.on('version_update', ({ from, to }) => {
-  console.log('announcing', to, 'instead of', from)
+client.on('version_update', ({ from, to, source }) => {
+  console.log('announcing', to, 'instead of', from, '—', source)
 })
 
 await client.init('40756469325')
 ```
 
-Three rules keep this from being the thing that breaks a working session:
+**Reconnects are covered too.** The check runs from the socket-connect step
+rather than from `init()`, so the library's own reconnect loop passes through it
+as well. A bot that stays up for weeks does not go on announcing whatever the
+listing said the morning it started. The handshake reads the version out of the
+store at the moment it runs, so a version written here is the one that goes out.
 
-- **It never goes backwards.** The App Store lookup answers with a pinned
-  fallback rather than failing when it cannot reach the network, and that
-  fallback can easily be older than what the session holds. Moving a session to
-  an older version is the one outcome that makes a `405` *more* likely.
+Four rules keep this from being the thing that breaks a working session:
+
+- **It never goes backwards.** Both lookups answer with a pinned fallback rather
+  than failing when they cannot reach the network, and that fallback can easily
+  be older than what the session holds. Moving a session to an older version is
+  the one outcome that makes a `405` *more* likely.
 - **`WA_VERSION` still wins.** A version pinned on the way out of a `405` is a
   decision, and is never quietly replaced.
 - **A failed lookup changes nothing.** The session keeps the version it has and
   the connect carries on.
+- **The network is not asked twice for the same answer.** Each lookup is
+  memoised for six hours, so a connection that flaps every few seconds reaches
+  the store once rather than once per attempt — and a session up for a month
+  still picks up a release the day it lands.
 
 Set `{ refreshVersion: false }` on the client to turn it off.
 
 > [!NOTE]
-> **Android is deliberately left alone.** Its version comes out of the APK the
-> token material was read from, and the two have to agree — the registration
-> token is computed from that build. Refreshing the announced version behind the
-> caller's back would put it out of step with the token. Android keeps the
-> explicit flow: `wa apk-material --download`, then `wa refresh-version`.
+> **Registration still reads the APK.** A number being registered announces the
+> `versionName` of the APK its token material came from, because the Android
+> registration token is signed over that build. Only the *announced* version on
+> an already-registered session follows the Play Store listing — no token
+> travels in the handshake, so there is nothing there for it to fall out of step
+> with. When the listing moves past the cached material the client emits
+> `apk_material_stale`, which is the cue to run `wa apk-material --download`
+> before registering the next number.
 
-The manual tool still works on both platforms, and is the only way to move an
-Android session:
+The manual tool still works on both platforms:
 
 ```bash
 wa refresh-version 40756469325                    # current build for the platform
@@ -4867,7 +4882,7 @@ 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 |
+| 2 | the version stored in the session file — refreshed from the platform's store before every handshake, unless `{ refreshVersion: false }` |
 
 Almost every 405 is the first line winning when nobody meant it to.
 

package/lib/AndroidApk.js

@@ -9,8 +9,7 @@
 // put in WA_STATIC_TOKEN can stand in for it. Sending the iOS-shaped token as
 // Android is answered with {"reason":"bad_token"}.
 //
-// What the native client actually computes, and what this file reproduces from
-// Cobalt's WhatsAppAndroidClientInfo:
+// What the native client actually computes, and what this file reproduces:
 //
 //   key   = PBKDF2-HMAC-SHA1(password = packageName || about_logo.png,
 //                            salt = ANDROID_SALT, iterations = 128, dkLen = 64)
@@ -27,7 +26,7 @@ const crypto = require('crypto');
 const zlib   = require('zlib');
 
 // Reverse engineered from the Android binary and identical for the consumer and
-// business builds. Cobalt notes it has been stable across many releases.
+// business builds, and has been stable across many releases.
 const ANDROID_SALT = Buffer.from(
   'PkTwKSZqUfAUyR0rPQ8hYJ0wNsQQ3dW1+3SCnyTXIfEAxxS75FwkDf47wNv/c8pP' +
   '3p0GXKR6OOQmhyERwx74fw1RYSU10I4r1gyBVDbRJ40pidjM41G1I1oN', 'base64');
@@ -124,7 +123,7 @@ function readZipEntry(buf, entries, name) {
 // ─── DER / PKCS#7 ─────────────────────────────────────────────────────────────
 //
 // The signing certificates come out of the v1 (JAR) signature block, which is
-// what Cobalt reads — apk-parser's getApkSingers() is the v1 signer list. Only
+// what the token derivation needs — the v1 signer list. Only
 // enough DER is parsed to walk into SignedData and lift each certificate out
 // whole; nothing here validates a signature.
 
@@ -174,7 +173,7 @@ function certificatesFromPkcs7(der) {
 //
 // The manifest inside an APK is Android's binary XML, not text. Three things are
 // read out of it — the package name, the version name and the version code —
-// the same three Cobalt takes from its parsed manifest. The version name is the
+// all three off the parsed manifest. The version name is the
 // one that matters most: the token is signed over this APK's classes.dex, so the
 // version announced to the server has to be this APK's, not whatever the Play
 // Store currently lists.
@@ -268,8 +267,8 @@ function parseManifest(buf) {
 }
 
 // A split's own name, as Android files it: "config.xxhdpi" out of
-// "base-config.xxhdpi.apk" or "split_config.xxhdpi.apk". Cobalt only searches
-// splits whose name ends in "dpi", which is the density-qualified set.
+// "base-config.xxhdpi.apk" or "split_config.xxhdpi.apk". Only splits whose name
+// ends in "dpi" are searched, which is the density-qualified set.
 function _isDensitySplit(fileName) {
   const base = String(fileName).replace(/\.apk$/i, '');
   return /dpi$/i.test(base);
@@ -295,8 +294,8 @@ function extractMaterial(base, splits) {
   // — and its bytes are the PBKDF2 password, so picking a different density
   // yields a different key and a token the server will not accept. Searching
   // split by split makes the answer depend on the order the splits happen to be
-  // passed in, which for a shell glob is alphabetical and for Cobalt is whatever
-  // its download map iterated: same APK, different token.
+  // passed in, which for a shell glob is alphabetical and for a download map is
+  // whatever it iterated: same APK, different token.
   //
   // So the path decides, not the split. ABOUT_LOGO_PATHS is ordered — hdpi
   // first, the xxhdpi fallback last — and every candidate is searched for the
@@ -355,9 +354,8 @@ function extractMaterial(base, splits) {
 
 // PBKDF2-HMAC-SHA1 over the package name followed by the raw PNG bytes.
 //
-// Cobalt runs the derivation by hand because the JCA factory rejects a binary
-// password; the loop it runs is standard PBKDF2, so this calls the platform's.
-// The two are checked against each other in the token test.
+// A JCA factory rejects a binary password, so a hand-rolled loop is the usual
+// route on the JVM; that loop is standard PBKDF2, so this calls the platform's.
 function deriveSecretKey(packageName, aboutLogo) {
   const password = Buffer.concat([Buffer.from(packageName, 'utf8'), aboutLogo]);
   return crypto.pbkdf2Sync(password, ANDROID_SALT, PBKDF2_ITERATIONS, PBKDF2_KEY_SIZE, 'sha1');
@@ -415,8 +413,7 @@ function looksLikeWhatsAppCertificate(description) {
 
 // ─── Storage ──────────────────────────────────────────────────────────────────
 //
-// Only the derived pieces are kept, the way Cobalt caches them — the APK itself
-// is never needed again.
+// Only the derived pieces are kept — the APK itself is never needed again.
 
 function materialToJson(material) {
   return {

package/lib/Attestation.js

@@ -4,10 +4,9 @@
 //
 // Talks to the on-device Frida attestation server shipped in ./frida (Android
 // Play Integrity / Keystore attestation, iOS App Attest) and folds its output
-// into the registration request, mirroring how Auties00/cobalt consumes the
-// same scripts.
+// into the registration request.
 //
-// Design (matches Cobalt's LinkedWhatsAppClientDeviceAttestor):
+// Design:
 //   • Two data shapes are produced —
 //       Android: { gpia, gg, gi, gp, ge, ga }  (Play Integrity legs)
 //       iOS:     { attestation, assertion, keyId }  (App Attest)
@@ -155,7 +154,7 @@ async function iosAppAttest(noisePubB64, device) {
 
 // ─── High-level: attestation fields shipped on every attested endpoint ────────
 //
-// Returns the alternating name/value pairs Cobalt ships via attestationFields():
+// Returns the alternating name/value pairs the attested endpoints expect:
 //   Android → gpia,_gg,_gi,_gp,_ge,_ga,push_token
 //   iOS     → push_token
 //

package/lib/Client.js

@@ -9,7 +9,7 @@ const crypto        = require('crypto');
 const { Mutex }     = require('async-mutex');
 const { NoiseSocket }     = require('./noise');
 const { MessageSender, generateMessageId, makeJid, buildOrGetAdvIdentity } = require('./messages/MessageSender');
-const { checkIfRegistered, checkNumberStatus, requestSmsCode, verifyCode, assertRegistrationKeys, fetchIosVersion, fetchWaVersion } = require('./Registration');
+const { checkIfRegistered, checkNumberStatus, requestSmsCode, verifyCode, assertRegistrationKeys, fetchIosVersion, fetchAndroidVersion, fetchWaVersion } = require('./Registration');
 const { defaultBaseDir, sessionDirFor, isLegacyLayout,
         preKeyFilesFor, SESSION_SUFFIXES } = require('./SessionPaths');
 const { getDeviceConfig } = require('./DeviceConfig');
@@ -379,12 +379,11 @@ class WhalibmobClient extends EventEmitter {
     // automatically on the first refused login. Set { autoFixNumber: false } to
     // be told about it instead.
     this._autoFixNumber  = opts.autoFixNumber !== false;
-    // An iOS session checks the App Store for the current build on every
-    // connect and writes it back — see _refreshIosVersion(). Set
-    // { refreshVersion: false } to keep announcing whatever the session
-    // registered with. Android is not affected either way: its version comes
-    // out of the APK the token material was read from, and that stays a
-    // deliberate step.
+    // A session checks its platform's store for the current build before every
+    // handshake and writes it back — see _refreshAnnouncedVersion(). iOS reads
+    // the App Store listing, Android the Play Store one, and reconnects are
+    // covered as well as the first connect. Set { refreshVersion: false } to
+    // keep announcing whatever the session registered with.
     this._refreshVersion = opts.refreshVersion !== false;
     this._numberFixAttempted = false;
     this._pingTimer               = null;
@@ -505,7 +504,7 @@ class WhalibmobClient extends EventEmitter {
   }
 
   /**
-   * Bring an iOS session's announced version up to date, on every connect.
+   * Bring a session's announced version up to date, before every handshake.
    *
    * A session records the version it registered with and announces that
    * forever after. Months later the server stops accepting it and the connect
@@ -515,56 +514,111 @@ class WhalibmobClient extends EventEmitter {
    * connectWeb() reads the live revision every time; this is the same idea for
    * the primary one.
    *
-   * iOS only, and deliberately so. Android's version comes out of the APK the
-   * token material was read from — the two have to agree, because the token is
-   * computed from that build — so refreshing it behind the caller's back would
-   * put the announced version and the token out of step. Android keeps its
-   * Play Store flow exactly as it was.
+   * Both platforms, and the version each one asks for is the one that platform
+   * publishes: the App Store listing for iOS, the Play Store listing for
+   * Android.
+   *
+   * Android was left out of this at first, on the grounds that its version has
+   * to match the APK the token material came from. That holds for registering a
+   * number and nowhere else. The Android token is an HMAC over the APK's
+   * signing certificates, the digest of its classes.dex and the national
+   * number — the version string is not in it — and no token of any kind travels
+   * in the handshake, which carries the version, the username and the device
+   * properties. So there is nothing here for a refreshed version to fall out of
+   * step with. Registration keeps reading the APK's own version through
+   * fetchWaVersion(), so a number being registered still announces the build
+   * its token was computed from.
+   *
+   * Called from _connectSocket() rather than init(), so it covers the
+   * library's own reconnects too. The handshake reads store.version at the
+   * moment it runs, so a version written here is the one that goes out.
    *
    * Three rules keep this from being the thing that breaks a working session:
    *
-   *   • It never goes backwards. fetchIosVersion() answers with the pinned
-   *     fallback rather than failing when the lookup does not work, and that
-   *     fallback can easily be older than what a session already holds. Moving
-   *     a session to an older version is the one outcome that makes a 405 more
-   *     likely rather than less.
+   *   • It never goes backwards. Both lookups answer with a pinned fallback
+   *     rather than failing, and that fallback can easily be older than what a
+   *     session already holds. Moving a session to an older version is the one
+   *     outcome that makes a 405 more likely rather than less.
    *   • WA_VERSION still wins. Someone who has pinned a version on the way out
    *     of a 405 must not have it quietly replaced.
    *   • It never throws, and it never blocks for long. A lookup that fails
-   *     leaves the session exactly as it was and the connect carries on.
+   *     leaves the session exactly as it was and the connect carries on. The
+   *     lookups memoise for six hours, so a connection that flaps every few
+   *     seconds reaches the network once, not once per attempt.
    */
-  async _refreshIosVersion() {
+  async _refreshAnnouncedVersion() {
     if (!this._refreshVersion || this._mode === 'web' || !this._store) return;
     if (process.env.WA_VERSION) {
       _whaDbg('[DBG] VERSION refresh skipped — WA_VERSION is set');
       return;
     }
 
-    const device = this._store.device || getDeviceConfig();
-    if (device.os === 'android') return;   // the APK flow owns this
+    const device   = this._store.device || getDeviceConfig();
+    const business = !!device.business;
+    const android  = device.os === 'android';
+    const source   = android ? 'Play Store listing' : 'App Store listing';
 
     try {
       const { compareVersions } = require('./Registration');
       const before = this._store.version;
-      const live   = await fetchIosVersion(!!device.business);
+      const live   = android
+        ? await fetchAndroidVersion(business)
+        : await fetchIosVersion(business);
       if (!live) return;
 
       if (before && compareVersions(live, before) <= 0) {
-        _whaDbg('[DBG] VERSION already current (' + before + ', App Store says ' + live + ')');
+        _whaDbg('[DBG] VERSION already current (' + before + ', ' + source +
+          ' says ' + live + ')');
         return;
       }
 
       this._store.version = live;
       this._persistStore();
       _whaDbg('[DBG] VERSION refreshed ' + (before || 'none') + ' → ' + live +
-        ' (App Store listing)');
-      this.emit('version_update', { from: before || null, to: live, source: 'App Store listing' });
+        ' (' + source + ')');
+      this.emit('version_update', { from: before || null, to: live, source });
+
+      // On Android the token material carries the version of the APK it was
+      // read from. Once the listing has moved past it, that material is from an
+      // older build — which matters for registering a number, not for this
+      // connection. Say so rather than fetching an APK on the connect path.
+      if (android) this._warnIfApkMaterialStale(device, live);
     } catch (err) {
       // A session that cannot ask keeps the version it has.
       _whaDbg('[DBG] VERSION refresh failed: ' + (err && err.message));
     }
   }
 
+  /**
+   * Note that the cached APK material predates the build Play is serving.
+   *
+   * Only registration reads that material, so nothing is broken here and
+   * nothing is downloaded. It is said once per connection so that a number
+   * registered from this install goes out under a current build if the owner
+   * refreshes the material first.
+   */
+  _warnIfApkMaterialStale(device, liveVersion) {
+    try {
+      const { compareVersions, tryLoadAndroidMaterial } = require('./Registration');
+      if (typeof tryLoadAndroidMaterial !== 'function') return;
+
+      const material   = tryLoadAndroidMaterial(device);
+      const apkVersion = material && material.apkVersion;
+      if (!apkVersion) return;
+      if (compareVersions(liveVersion, apkVersion) <= 0) return;
+
+      _whaDbg('[DBG] APK material is from ' + apkVersion + ', the listing serves ' +
+        liveVersion + ' — run `wa apk-material --download` before registering a number');
+      this.emit('apk_material_stale', {
+        materialVersion: apkVersion,
+        liveVersion,
+        hint: 'wa apk-material --download'
+      });
+    } catch (_) {
+      // Advisory only.
+    }
+  }
+
   async init(phoneNumber) {
     phoneNumber = String(phoneNumber).replace(/\D/g, '');
     this._phoneNumber = phoneNumber;
@@ -594,10 +648,6 @@ class WhalibmobClient extends EventEmitter {
       );
     }
 
-    // Before the handshake, which reads the version straight out of the store.
-    // iOS only; Android keeps its APK flow. See _refreshIosVersion().
-    await this._refreshIosVersion();
-
     const signalFile  = path.join(this._sessionDir, `${phoneNumber}.signal.json`);
     const skFile      = path.join(this._sessionDir, `${phoneNumber}.sk.json`);
     const tcTokenFile = path.join(this._sessionDir, `${phoneNumber}.tctoken.json`);
@@ -702,6 +752,15 @@ class WhalibmobClient extends EventEmitter {
   async _connectSocket() {
     if (this._mode === 'web') return this._connectWebSocket();
 
+    // Before the handshake, which reads the version straight out of the store.
+    //
+    // Here rather than in init() so that the library's own reconnects get it
+    // too: _scheduleReconnect() calls this method directly, and a session that
+    // refreshed only at startup would announce whatever the listing said the
+    // day the process began, however long it then stayed up. The lookups
+    // memoise for six hours, so a flapping connection costs nothing.
+    await this._refreshAnnouncedVersion();
+
     const socket = new NoiseSocket(this._store);
     this._socket = socket;
 
@@ -3433,6 +3492,54 @@ class WhalibmobClient extends EventEmitter {
       const isLid     = fromJid.endsWith('@lid');
       const mappedPn  = isLid && this._lidToPn ? this._lidToPn.get(fromUser) : null;
       const fromPhone = isLid ? mappedPn : fromUser;
+
+      // A contact has two device lists — one under the phone number, one under
+      // the LID — and the notification carries both: `device_hash` for the list
+      // it is addressed under, `device_lid_hash` for the other one, with each
+      // <device> naming its jid and its lid. The server hashes them separately,
+      // so they are checked separately, and one going wrong does not cost the
+      // other. That matters most for the LID half: a LID cache thrown away for
+      // a contact whose number we do not know cannot be refilled by usync,
+      // which only answers questions about phone numbers.
+      const lidAttr = String(attrs.lid || '');
+      const lidUser = isLid ? fromUser
+                    : (lidAttr ? lidAttr.split('@')[0].split(':')[0] : null);
+      // Free mapping, exactly as the notification states it.
+      if (!isLid && lidUser && fromUser) {
+        if (this._lidToPn) this._lidToPn.set(lidUser, fromUser);
+        if (this._pnToLid) this._pnToLid.set(fromUser, lidUser);
+      }
+
+      // Before throwing the cache away: the notification says what changed and
+      // carries the hash of the list it should produce. Apply it, check the
+      // hash, and if it matches there is nothing to invalidate and nothing to
+      // ask usync about — see DeviceManager.verifyDeviceDelta().
+      if (fromUser && this._devMgr) {
+        const delta = this._parseDeviceDelta(node);
+        if (delta) {
+          // The primary half is keyed the way the notification is addressed.
+          const priKey    = isLid ? 'lid:' + fromUser : fromUser;
+          const priServer = isLid ? 'lid' : 's.whatsapp.net';
+          const priOk     = this._devMgr.verifyDeviceDelta(
+            priKey, fromUser, delta.changes, delta.hash, priServer);
+
+          // The secondary half only exists when the notification arrived under
+          // the number and named the LID alongside it.
+          if (!isLid && lidUser && delta.lidHash && delta.lidChanges) {
+            const lidOk = this._devMgr.verifyDeviceDelta(
+              'lid:' + lidUser, lidUser, delta.lidChanges, delta.lidHash, 'lid');
+            _whaDbg('[DBG] NOTIF_DEVICES lid delta ' +
+              (lidOk ? 'verified' : 'unverified') + ' for lid:' + lidUser);
+          }
+
+          if (priOk) {
+            _whaDbg('[DBG] NOTIF_DEVICES delta verified for ' + priKey +
+              ' — cache kept, no usync needed');
+            return;
+          }
+        }
+      }
+
       if (fromUser && this._devMgr) {
         this._devMgr._dcDel(isLid ? [fromUser, 'lid:' + fromUser] : [fromUser]);
         if (mappedPn) this._devMgr._dcDel([mappedPn]);
@@ -3484,6 +3591,86 @@ class WhalibmobClient extends EventEmitter {
     }
   }
 
+  /**
+   * Read a `devices` notification as a change plus the hash it should produce.
+   *
+   *   <notification type="devices" from="…">
+   *     <add device_hash="2:…"><device jid="40711111111:3@s.whatsapp.net"/></add>
+   *   </notification>
+   *
+   * Children are `add`, `remove`, or `update`. Only the first two say something
+   * that can be applied; `update` does not name what it changed, so it is
+   * treated as unreadable here and the caller falls back to invalidating.
+   *
+   * All children must agree on the hash — the server sends one per child, and a
+   * notification carrying two different ones is describing intermediate states
+   * this cannot reconstruct.
+   *
+   * Each child may also carry `device_lid_hash`, and each `<device>` a `lid`
+   * beside its `jid`, describing the same change to the contact's LID device
+   * list. That half is optional: missing on any child, and only the phone-number
+   * half is returned, which is what the caller then verifies. It is never a
+   * reason to reject the notification outright — the two lists are hashed
+   * independently by the server and are checked independently here.
+   *
+   * @returns {{changes: Array<{tag, deviceId}>, hash: string,
+   *            lidChanges: Array<{tag, deviceId}>|null, lidHash: string|null}|null}
+   */
+  _parseDeviceDelta(node) {
+    if (!node || !Array.isArray(node.content)) return null;
+
+    const changes    = [];
+    const lidChanges = [];
+    let hash    = null;
+    let lidHash = null;
+    let lidOk   = true;   // every child so far carried a usable LID half
+
+    // "user:3@server" / "user@server" → 3 / 0, or null when unreadable.
+    const deviceIdOf = (jid) => {
+      if (!jid) return null;
+      const raw   = String(jid).split('@')[0];
+      const colon = raw.indexOf(':');
+      if (colon < 0) return 0;
+      const device = parseInt(raw.slice(colon + 1), 10);
+      return Number.isFinite(device) ? device : null;
+    };
+
+    for (const child of node.content) {
+      if (!child || !child.description) continue;
+      const tag = child.description;
+      if (tag !== 'add' && tag !== 'remove') return null;   // 'update' and friends
+
+      const childHash = child.attrs && child.attrs.device_hash;
+      if (!childHash) return null;
+      if (hash === null) hash = String(childHash);
+      else if (hash !== String(childHash)) return null;     // disagreeing children
+
+      const deviceNode = findChild(child, 'device');
+      const attrs      = (deviceNode && deviceNode.attrs) || {};
+      const device     = deviceIdOf(attrs.jid);
+      if (device === null) return null;
+      changes.push({ tag, deviceId: device });
+
+      // LID half — optional, and giving up on it costs the number half nothing.
+      if (!lidOk) continue;
+      const childLidHash = child.attrs.device_lid_hash;
+      const lidDevice    = deviceIdOf(attrs.lid);
+      if (!childLidHash || lidDevice === null) { lidOk = false; continue; }
+      if (lidHash === null) lidHash = String(childLidHash);
+      else if (lidHash !== String(childLidHash)) { lidOk = false; continue; }
+      lidChanges.push({ tag, deviceId: lidDevice });
+    }
+
+    if (!changes.length || !hash) return null;
+    const haveLid = lidOk && lidHash && lidChanges.length === changes.length;
+    return {
+      changes,
+      hash,
+      lidChanges: haveLid ? lidChanges : null,
+      lidHash:    haveLid ? lidHash    : null
+    };
+  }
+
   _processDeviceUpdate(devicesNode) {
     // Called from _handleNotification(type='account_sync') and type='devices'.
     // Rebuilds the device cache for the affected phones from the server-provided list.
@@ -5551,10 +5738,9 @@ class WhalibmobClient extends EventEmitter {
 
   // Change bio/about text
   //
-  // The <status> child is byte-for-byte what Baileys and whatsmeow send. The
-  // envelope was not: both of them address this IQ to the server as a *JID*
-  // with nobody in the user part — Baileys writes '@s.whatsapp.net', whatsmeow
-  // uses types.ServerJID — which goes out as JID_PAIR + empty user + the server
+  // The <status> child is the shape the server reads. The envelope was not:
+  // this IQ has to be addressed to the server as a *JID* with nobody in the
+  // user part, which goes out as JID_PAIR + empty user + the server
   // token. This wrote the bare string 's.whatsapp.net', and a bare string is
   // encoded as a plain dictionary token, so where every other client puts an
   // address the server was reading text. That is the whole of the difference,

package/lib/DeviceManager.js

@@ -1178,6 +1178,87 @@ class DeviceManager {
   }
 
   // ─── Invalidate cached device list (used on phash mismatch / 421 retry) ───
+  /**
+   * Apply a device-list change and check the result against the server's own
+   * hash of what the list should now be.
+   *
+   * A `devices` notification says what changed — one device added, one removed —
+   * and carries `device_hash`, the participant hash of the list the server
+   * believes we should end up with. That hash is the thing worth having: it
+   * turns "I applied the change, probably correctly" into something checkable.
+   *
+   * So the change is applied to the cached list, the hash of the result is
+   * computed, and the two are compared. Equal, and the cache is provably right
+   * and is kept. Different, and the cache is wrong in some way this side cannot
+   * see, so it is thrown away and the next send asks usync for the whole list.
+   *
+   * That second branch is exactly what this did for every notification before —
+   * drop everything, ask again. Which is safe, and costs a round trip each time
+   * somebody opens WhatsApp Web. This keeps the cache when it can prove it is
+   * right, and falls back to the old behaviour when it cannot.
+   *
+   * Safe by construction: if this hash were computed differently from the
+   * server's, nothing would ever match and every notification would take the
+   * fallback — which is where it started.
+   *
+   * Works for either half of a contact's identity. WhatsApp keeps a device list
+   * under the phone number and another under the LID, hashes them separately,
+   * and sends both hashes on the same notification — so each is verified on its
+   * own, and one going wrong does not cost the other.
+   *
+   * @param   {string} cacheKey     the cache entry: digits, or 'lid:<user>'
+   * @param   {string} user         the JID user part the ids belong to
+   * @param   {Array<{tag: string, deviceId: number}>} changes
+   * @param   {string} serverHash   device_hash, or device_lid_hash
+   * @param   {string} [server]     's.whatsapp.net' (default) or 'lid'
+   * @returns {boolean} whether the result verified and the cache was kept
+   */
+  verifyDeviceDelta(cacheKey, user, changes, serverHash, server) {
+    server = server || 's.whatsapp.net';
+    if (!cacheKey || !user || !serverHash) return false;
+    if (!Array.isArray(changes) || !changes.length) return false;
+
+    // No baseline means there is nothing to apply a change to. Caching just the
+    // one device named in the notification would make a list of one look
+    // authoritative, which is how a recipient's other devices stop being
+    // written to.
+    const cached = this._dcGet(cacheKey);
+    if (!cached || !cached.length) return false;
+
+    const next = new Set(cached);
+    for (const { tag, deviceId } of changes) {
+      if (!Number.isFinite(deviceId)) return false;
+      if (tag === 'add')         next.add(deviceId);
+      else if (tag === 'remove') next.delete(deviceId);
+      else return false;   // 'update' and anything unknown: do not guess
+    }
+
+    const ids  = [...next].sort((a, b) => a - b);
+    const jids = ids.map(d => makeDeviceJid(user, d, server));
+
+    let ours;
+    try {
+      // Lazily required: MessageSender requires this file, so taking it at the
+      // top would close the cycle before either module finishes loading.
+      const { computePhash } = require('./messages/MessageSender');
+      ours = computePhash(jids);
+    } catch (_) {
+      return false;
+    }
+
+    if (ours !== String(serverHash)) {
+      _whaDbg('[DBG] DEV_HASH mismatch for ' + cacheKey + ' ours=' + ours +
+        ' server=' + serverHash + ' — dropping cache');
+      this._dcDel([cacheKey]);
+      return false;
+    }
+
+    this._dcSet(cacheKey, ids);
+    _whaDbg('[DBG] DEV_HASH verified for ' + cacheKey + ' ids=[' + ids.join(',') +
+      '] hash=' + ours);
+    return true;
+  }
+
   clearCache(phones) {
     if (!phones || phones.length === 0) {
       this._dcFlush();
@@ -1187,10 +1268,13 @@ class DeviceManager {
   }
 
   // ─── Build participants node ───────────────────────────────────────────────
-  static buildParticipantsNode(encryptedList, mediaSubtype) {
+  static buildParticipantsNode(encryptedList, mediaSubtype, decryptFail) {
     const toNodes = encryptedList.map(({ jid, type, ciphertext }) => {
       const encAttrs = { type, v: '2' };
       if (mediaSubtype) encAttrs.mediatype = mediaSubtype;
+      // What the recipient shows if this payload will not decrypt — see
+      // resolveDecryptFail() in MessageSender.
+      if (decryptFail) encAttrs['decrypt-fail'] = decryptFail;
       // Always encode the jid as a binary JID object (JID_PAIR / AD_JID) so the
       // server can route the per-device enc payload to the correct Signal session.
       // Raw UTF-8 strings are silently dropped for @lid recipients.

package/lib/PlayStore.js

@@ -1,8 +1,7 @@
 'use strict';
 
-// Fetching the WhatsApp APK from Google Play, the way Cobalt's PlayStoreUtils
-// does it, so the Android token material can be refreshed without anyone having
-// to find an APK by hand.
+// Fetching the WhatsApp APK from Google Play, so the Android token material can
+// be refreshed without anyone having to find an APK by hand.
 //
 // The route, in three hops:
 //
@@ -252,7 +251,7 @@ async function acquire(packageName, versionCode, headers) {
       }, headers),
       body
     });
-  } catch (_) { /* best effort, as in Cobalt */ }
+  } catch (_) { /* best effort */ }
 }
 
 // { baseUrl, splits: [{name, url}], cookies: {name: value} }

package/lib/Registration.js

@@ -16,9 +16,9 @@ const { dbg: _whaDbg, warn: _whaWarn } = require('./logger');
 // ---------- Request envelope ----------
 //
 // The registration server reads which platform is calling out of the
-// User-Agent. There is no form field for it — neither this library nor Cobalt
-// sends one — so a request whose User-Agent does not name a platform it knows is
-// refused with {"param":"platform","reason":"bad_param"} on every endpoint. The
+// User-Agent. There is no form field for it — none is sent — so a request whose
+// User-Agent does not name a platform it knows is refused with
+// {"param":"platform","reason":"bad_param"} on every endpoint. The
 // giveaway is that /client_log is refused the same way, and its body carries no
 // device fields at all: nothing about the platform is in the body to begin with.
 //
@@ -26,10 +26,9 @@ const { dbg: _whaDbg, warn: _whaWarn } = require('./logger');
 // was refused everywhere. iOS has always sent the full form and has always
 // worked, which is why only one of the two platforms was broken.
 //
-// The three extra Android headers come from Cobalt's AndroidClientRegistration,
-// which records them as observed on a live native Android registration. Its iOS
-// counterpart documents that the native iOS client omits all three, so the iOS
-// envelope stays exactly as it was.
+// The three extra Android headers were observed on a live native Android
+// registration. The native iOS client omits all three, so the iOS envelope
+// stays exactly as it was.
 // The platform token in the User-Agent. The Business builds name themselves
 // differently — `SMBA` on Android, `SMB iOS` on iOS — and the registration
 // server reads the platform out of exactly this string.
@@ -628,12 +627,48 @@ function parsePhone(phoneNumber) {
 // Cached per variant: the consumer and Business builds ship on their own
 // schedules, and announcing one's version as the other is a version the server
 // has no record of for that platform.
+//
+// The entries expire. Without that the first answer of a process is its last:
+// a session that reconnects for weeks would keep announcing whatever the store
+// happened to say the morning it started, which is the same stale-version
+// problem the refresh exists to solve. Six hours is short enough that a release
+// is picked up the day it lands and long enough that a connection flapping
+// every few seconds never reaches the network for it.
+const VERSION_CACHE_TTL_MS = 6 * 60 * 60 * 1000;
+
 const _cachedIosVersion     = {};
 const _cachedAndroidVersion = {};
 
+function _cachedVersion(cache, key) {
+  const entry = cache[key];
+  if (!entry) return null;
+  if (Date.now() - entry.at > VERSION_CACHE_TTL_MS) {
+    delete cache[key];
+    return null;
+  }
+  return entry.value;
+}
+
+function _cacheVersion(cache, key, value) {
+  if (value) cache[key] = { value, at: Date.now() };
+  return value;
+}
+
+/**
+ * Drop the memoised lookups so the next call goes to the network.
+ *
+ * Ordinary callers are served by the TTL above; this exists for tests and for
+ * anything that needs a definite answer right now.
+ */
+function clearVersionCache() {
+  for (const k of Object.keys(_cachedIosVersion))     delete _cachedIosVersion[k];
+  for (const k of Object.keys(_cachedAndroidVersion)) delete _cachedAndroidVersion[k];
+}
+
 async function fetchIosVersion(business) {
   const key = business ? 'business' : 'personal';
-  if (_cachedIosVersion[key]) return _cachedIosVersion[key];
+  const hit = _cachedVersion(_cachedIosVersion, key);
+  if (hit) return hit;
   const bundleId = business ? IOS_BUSINESS_BUNDLE_ID : IOS_BUNDLE_ID;
   return new Promise((resolve) => {
     const req = https.get(
@@ -647,7 +682,7 @@ async function fetchIosVersion(business) {
             const json = JSON.parse(Buffer.concat(chunks).toString('utf8'));
             let ver = (json.results && json.results[0] && json.results[0].version) || IOS_VERSION_FALLBACK;
             if (!ver.startsWith('2.')) ver = '2.' + ver;
-            _cachedIosVersion[key] = ver;
+            _cacheVersion(_cachedIosVersion, key, ver);
             resolve(ver);
           } catch (_) {
             resolve(IOS_VERSION_FALLBACK);
@@ -665,7 +700,8 @@ async function fetchIosVersion(business) {
 // Falls back to ANDROID_VERSION_FALLBACK on any error.
 async function fetchAndroidVersion(business) {
   const key = business ? 'business' : 'personal';
-  if (_cachedAndroidVersion[key]) return _cachedAndroidVersion[key];
+  const hit = _cachedVersion(_cachedAndroidVersion, key);
+  if (hit) return hit;
   const packageName = business ? WHATSAPP_BUSINESS_PACKAGE : WHATSAPP_PACKAGE;
   try {
     const axios = require('axios');
@@ -698,15 +734,13 @@ async function fetchAndroidVersion(business) {
     // In Play Store JSON the current stable version appears first, before beta/history entries.
     const primary = html.match(/"(2\.\d+\.\d+\.\d+)"/);
     if (primary) {
-      _cachedAndroidVersion[key] = primary[1];
-      return primary[1];
+      return _cacheVersion(_cachedAndroidVersion, key, primary[1]);
     }
 
     // Secondary: unquoted version adjacent to "WhatsApp" text (catches alternate HTML structures).
     const secondary = html.match(/WhatsApp[^<"]{0,200}?(2\.\d+\.\d+\.\d+)/);
     if (secondary) {
-      _cachedAndroidVersion[key] = secondary[1];
-      return secondary[1];
+      return _cacheVersion(_cachedAndroidVersion, key, secondary[1]);
     }
 
     // Last resort: the highest 4-part version anywhere on the page. Play has
@@ -716,8 +750,7 @@ async function fetchAndroidVersion(business) {
     if (all && all.length) {
       const newest = all.sort(compareVersions).pop();
       _whaDbg('[DBG] ANDROID_VERSION scraped from an unrecognised page layout: ' + newest);
-      _cachedAndroidVersion[key] = newest;
-      return newest;
+      return _cacheVersion(_cachedAndroidVersion, key, newest);
     }
 
     _whaWarn('could not read the current WhatsApp version off the Play Store page — ' +
@@ -746,8 +779,8 @@ function compareVersions(a, b) {
 // Return the appropriate WhatsApp version for the active device.
 // If WA_VERSION is set in the environment, that value is always used.
 //
-// On Android the APK the token material came from decides it, the way Cobalt
-// announces the versionName of the APK it downloaded. The token is signed over
+// On Android the APK the token material came from decides it: the versionName
+// of the APK that was downloaded. The token is signed over
 // that build's classes.dex, so a version read from anywhere else describes a
 // different build than the one the token proves — which the server sees as a
 // token that does not belong to the client sending it. The live lookup stays as
@@ -1092,7 +1125,7 @@ function buildForm(pairs, extraPairs) {
 }
 
 // ---------- access_session_id ----------
-// Cobalt's newAccessSessionId(): 16 random bytes → URL-safe base64 without
+// 16 random bytes → URL-safe base64 without
 // padding (a 22-char token). Generated once per store/session and reused on
 // every attested endpoint, matching the native client.
 
@@ -1106,13 +1139,11 @@ function getAccessSessionId(store) {
   return store._accessSessionId;
 }
 
-// ---------- /code verification-code parameters (per platform, mirrors Cobalt) ----------
+// ---------- /code verification-code parameters (per platform) ----------
 // Returns the alternating name/value form fields the native client emits on a
 // /code request. Android sends the long device-fingerprint list; iOS sends the
-// short list. Values match AndroidClientRegistration / IosClientRegistration;
-// sim_mcc/sim_mnc/mcc/mnc keep whalibmob's real per-country values (better than
-// Cobalt's "000" placeholder), and advertising_id / backup_token come from the
-// store.
+// short list. sim_mcc/sim_mnc/mcc/mnc carry real per-country values rather than
+// a "000" placeholder, and advertising_id / backup_token come from the store.
 
 // How long the server said to wait, in seconds, or null when it did not say.
 //
@@ -1293,8 +1324,8 @@ async function buildPayload(store, waVersion, useToken, extraPairs) {
     ? store.fdid.toLowerCase()
     : store.fdid.toUpperCase();
 
-  // Device-attestation fields shipped on every attested endpoint (Cobalt
-  // attestationFields). Empty by default (NONE fallback); populated when a
+  // Device-attestation fields shipped on every attested endpoint.
+  // Empty by default (NONE fallback); populated when a
   // Frida attestation server is configured via WA_FRIDA_HOST. The Play
   // Integrity nonce is a stable per-session value derived from the store.
   const nonceB64 = attestation.toBase64Url(
@@ -2137,7 +2168,7 @@ async function verifyCode(store, code, opts) {
   throw new Error(`Verification failed: ${reason || JSON.stringify(result)}`);
 }
 
-module.exports = { checkIfRegistered, checkNumberStatus, requestSmsCode, verifyCode, fetchIosVersion, fetchAndroidVersion, fetchWaVersion, currentVersionFor, refreshSessionVersion, compareVersions, parsePhone, getCountryMeta, assertRegistrationKeys, parseSocksProxy, socksProxyUrl };
+module.exports = { checkIfRegistered, checkNumberStatus, requestSmsCode, verifyCode, fetchIosVersion, fetchAndroidVersion, fetchWaVersion, currentVersionFor, refreshSessionVersion, clearVersionCache, tryLoadAndroidMaterial, compareVersions, parsePhone, getCountryMeta, assertRegistrationKeys, parseSocksProxy, socksProxyUrl };
 
 // The HTTP reader, exposed for tests. Not part of the public API.
 module.exports._http = { readHttpResponse, parseHttpResponse, decodeChunkedBody };

package/lib/messages/MessageSender.js

@@ -124,6 +124,35 @@ function _getCurve() {
 // Build ADVSignedDeviceIdentity for our primary iOS device.
 // Returns Buffer of encoded proto WITH accountSignatureKey included.
 // Result is cached in store.advIdentity so we only build it once per registration.
+// What the recipient's client should do when one of our payloads will not
+// decrypt for them.
+//
+// The attribute rides on the <enc> node and is read on the other side, not by
+// the server. Absent, a failure draws the "Waiting for this message" placeholder
+// in their chat. `hide` draws nothing at all.
+//
+// That placeholder is right for a real message — the person can see something
+// arrived and ask for it again. It is nonsense for the three kinds below, which
+// are invisible operations on a message that is already there: a reaction that
+// will not decrypt is a heart that never appears, not a message to wait for, and
+// a failed revoke or edit would leave a ghost bubble referring to nothing.
+//
+// The rule is the reference clients' rule, narrowed to what this library sends:
+//
+//   reaction   sendReaction()                   → stanza type 'reaction'
+//   edit       editMessage()                    → edit bit '1'
+//   revoke     deleteMessage(forEveryone: true) → edit bit '7' or '8'
+//
+// Everything else gets nothing, which is the same as saying "show it".
+function resolveDecryptFail(mediaType, options) {
+  if (mediaType === 'reaction') return 'hide';
+  // Any edit bit: 1 is an edit, 7 and 8 are the two revoke forms. The reference
+  // client keys off the presence of the attribute rather than its value, and so
+  // does this.
+  if (options && options.edit) return 'hide';
+  return null;
+}
+
 function _buildOrGetAdvIdentity(store) {
   // Only ever return an identity the server actually issued.
   //
@@ -909,6 +938,7 @@ class MessageSender {
     const ownPhone       = String(this._store.phoneNumber);
     const ownMainJid     = `${ownPhone}@s.whatsapp.net`;
     const mediaSubtype   = options._mediaSubtype || null;
+    const decryptFail    = resolveDecryptFail(mediaType, options);
 
     // For primary iOS devices (registered via SMS), advIdentity is never set
     // because the server only sends device-identity for linked secondary devices.
@@ -1040,7 +1070,8 @@ class MessageSender {
       // Always use <participants><to jid=...><enc> structure — required by MD protocol.
       // Old iOS non-MD used direct <enc> in <message>, but the WhatsApp server now
       // enforces the MD participants wrapper even for single-device sends.
-      const participantsNode = DeviceManager.buildParticipantsNode(encryptedList, mediaSubtype);
+      const participantsNode = DeviceManager.buildParticipantsNode(
+        encryptedList, mediaSubtype, decryptFail);
       msgContent = [...devIdNodes, participantsNode];
     }
 
@@ -1159,6 +1190,7 @@ class MessageSender {
     const ownPhone     = String(this._store.phoneNumber);
     const ownJid       = `${ownPhone}@s.whatsapp.net`;
     const mediaSubtype = options._mediaSubtype || null;
+    const decryptFail  = resolveDecryptFail(mediaType, options);
 
     const isStatus = isStatusBroadcast(groupJid);
 
@@ -1405,10 +1437,17 @@ class MessageSender {
       // participant nodes as on the skmsg, so an image sent to a group carries
       // mediatype on both. Passing null here left the SKDM <enc> nodes
       // unlabelled.
-      msgContent.push(DeviceManager.buildParticipantsNode(skdmEncrypted, mediaSubtype));
+      msgContent.push(DeviceManager.buildParticipantsNode(
+        skdmEncrypted, mediaSubtype, decryptFail));
     }
     const skmsgAttrs = { type: 'skmsg', v: '2' };
     if (mediaSubtype) skmsgAttrs.mediatype = mediaSubtype;
+    // On the skmsg too, and that is where it matters most in a group: the
+    // participant nodes carry the sender-key distribution, but the reaction
+    // itself travels in here. The two reference clients disagree — one sets it
+    // on both, the other only on the participant nodes — and the one that sets
+    // both is the one whose reasoning holds up.
+    if (decryptFail) skmsgAttrs['decrypt-fail'] = decryptFail;
     msgContent.push(new BinaryNode('enc', skmsgAttrs, Buffer.isBuffer(skmsgCiphertext) ? skmsgCiphertext : Buffer.from(skmsgCiphertext)));
 
     // Same reporting token a direct message carries. A poll posted to a group

package/lib/signal/SignalStore.js

@@ -41,7 +41,7 @@ const DEBOUNCE_MS = 300;
 // ─── Pre-key files ────────────────────────────────────────────────────────────
 //
 // One-time pre-keys do not live in the snapshot above. They get a file each,
-// named the way Baileys names them:
+// named one per id:
 //
 //   <base>/40756469325/40756469325.pre-key-1.json
 //   ...
@@ -60,8 +60,8 @@ const DEBOUNCE_MS = 300;
 // must — and a session still sitting in the old flat layout, where every
 // number shares one directory, does not collide with its neighbours either.
 //
-// A pre-key on disk is byte-for-byte what Baileys writes: BufferJSON, the raw
-// 32-byte public key with no type prefix.
+// A pre-key on disk is BufferJSON: the raw 32-byte public key with no type
+// prefix.
 //
 //   {"private":{"type":"Buffer","data":"…"},"public":{"type":"Buffer","data":"…"}}
 //
@@ -162,7 +162,7 @@ class SignalStore {
     this._pkTimer          = null;
     this._pkWriting        = false;
 
-    // The two counters Baileys keeps in creds. They live here instead because a
+    // The two pre-key counters. They live here rather than in creds because a
     // number's mobile and companion halves have a .signal.json each and must
     // never share a pre-key id space.
     //

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "whalibmob",
-  "version": "5.17.0",
+  "version": "5.19.0",
   "description": "WhatsApp library for interaction with WhatsApp Mobile API and web ",
   "author": "Kunboruto20",
   "main": "index.js",