whalibmob 5.5.73 → 5.5.77

package/lib/DeviceManager.js

@@ -44,12 +44,18 @@ function jidStrToObj(jidStr) {
   if (server === 's.whatsapp.net' && device > 0) {
     return { user, agent: 0, device, server, toString() { return self; } };
   }
-  // @lid multi-device (e.g. "112713111982325:2@lid"): JID_PAIR with user="112713111982325:2"
-  // so the server receives the colon-device in the user string, not stripped.
-  // Without this, ":2@lid" is encoded as device-0 "@lid" and the server
-  // returns the wrong bundle (or ignores device 2 entirely).
+  // @lid multi-device (e.g. "112713111982325:2@lid"): AD_JID with the domain in
+  // the agent byte — 1 for lid, matching Baileys' writeJid, which emits AD_JID
+  // with domainType whenever a device is present.
+  //
+  // This previously packed the device into the user string as a JID_PAIR
+  // ("112713111982325:2"), a workaround from when the encoder could not express
+  // a LID agent at all and would otherwise have flattened the JID to device 0.
+  // The server does not recognise that shape: a prekey IQ addressed with it got
+  // no reply whatsoever and timed out, so no session was ever built for the
+  // contact's linked devices and sends failed with NO_OPEN_SESSION.
   if (server === 'lid' && device > 0) {
-    return { user: raw, server, toString() { return self; } };
+    return { user, agent: 1, device, server, toString() { return self; } };
   }
   // JID_PAIR: used for @lid device-0, @g.us, and primary (device-0) @s.whatsapp.net
   return { user, server, toString() { return self; } };
@@ -749,8 +755,37 @@ class DeviceManager {
     }
 
     if (allowPkmsg && fetchJids.length > 0) {
-      const bundles = await this.fetchBundles(fetchJids);
-      for (const [jid, bundle] of bundles) {
+      // Ask for the bundles by phone JID. The encrypt IQ is not answered at all
+      // when its <user> entries are @lid — it just times out — while the same
+      // request in phone form comes back in full. Translate through the known
+      // LID→PN mapping, keeping a link back so each bundle is installed under
+      // the LID address the participants node will use.
+      const pnForLid = this._client._lidToPn && this._client._lidToPn.get(lidUser);
+      const wireToLid = new Map();
+      let wireJids = fetchJids;
+      if (pnForLid) {
+        wireJids = fetchJids.map(j => {
+          const at    = j.indexOf('@');
+          const base  = at >= 0 ? j.slice(0, at) : j;
+          const colon = base.indexOf(':');
+          const dev   = colon >= 0 ? (parseInt(base.slice(colon + 1), 10) || 0) : 0;
+          const wire  = makeDeviceJid(pnForLid, dev, 's.whatsapp.net');
+          wireToLid.set(wire, j);
+          return wire;
+        });
+        _whaDbg('[DBG] LID_BUNDLE_VIA_PN lid=' + lidUser + ' pn=' + pnForLid +
+          ' jids=[' + wireJids.join(',') + ']\n');
+      } else {
+        _whaDbg('[DBG] LID_BUNDLE_NO_PN lid=' + lidUser + ' — requesting by LID\n');
+      }
+
+      const bundles = await this.fetchBundles(wireJids);
+      for (const [wireJid, bundle] of bundles) {
+        // Install under the @lid address: that is what the outgoing
+        // participants node — and therefore the encrypt step — looks the
+        // session up by. Stored under the phone user it is a different Signal
+        // address and would never be found.
+        const jid = wireToLid.get(wireJid) || wireJid;
         try {
           await signalProto.buildSessionFromBundle(jid, bundle);
           // ── CRITICAL: remap bundle JID back to @lid format ────────────────────
@@ -760,14 +795,13 @@ class DeviceManager {
           // nodes to also use @lid format — mixing @s.whatsapp.net participants with
           // a @lid routing address causes the server to close the connection.
           //
-          // The Signal session address is keyed only by (user, device) — the @server
-          // suffix is stripped by jidToAddress() — so the session is reachable via
-          // either @lid or @s.whatsapp.net.  We push the @lid form so the participants
-          // node is consistent with the routing.
-          //
-          // Mapping: strip @s.whatsapp.net / @lid suffix from jid, re-append @lid
-          // e.g. "112713111982325@s.whatsapp.net"   → "112713111982325@lid"
-          //      "112713111982325:2@s.whatsapp.net" → "112713111982325:2@lid"
+          // A Signal address is (user, device) with the @server stripped — but
+          // the user of a LID and the user of a phone JID are different strings,
+          // so a session is NOT reachable under both. That assumption is what
+          // left sends failing: bundles fetched in phone form were stored under
+          // the phone user while the participants node looked them up by LID.
+          // The session is installed under the @lid address above; this only
+          // normalises the JID pushed into readyJids.
           const jidBase = jid.replace(/@(?:s\.whatsapp\.net|lid)$/, '');
           const lidJidForDevice = jidBase + '@lid';
           readyJids.push(lidJidForDevice);

package/lib/messages/MessageSender.js

@@ -42,12 +42,12 @@ function phoneFromJid(jid) {
   return colon >= 0 ? user.slice(0, colon) : user;
 }
 
-// ─── Feature 2: ADVSignedDeviceIdentity builder ──────────────────────────────
+// ─── ADVSignedDeviceIdentity ─────────────────────────────────────────────────
 //
-// whalibmob receives device-identity from the server in the
-// pair-success IQ.  For primary iOS devices registered via SMS there is no
-// pairing IQ — so we construct the ADVSignedDeviceIdentity ourselves from our
-// own identity key pair, matching exactly what a real iOS primary device does.
+// Received from the server in the pair-success IQ when a companion device is
+// linked. A primary device registered over SMS never gets one and must not
+// invent one — see _buildOrGetAdvIdentity. The encoders below remain for
+// working with a real identity when the server does supply it.
 //
 // ADVDeviceIdentityDetails (protobuf):
 //   field 1 (rawId,      uint32): registration ID
@@ -110,33 +110,26 @@ function _getCurve() {
 // Returns Buffer of encoded proto WITH accountSignatureKey included.
 // Result is cached in store.advIdentity so we only build it once per registration.
 function _buildOrGetAdvIdentity(store) {
-  if (store.advIdentity && store.advIdentity.length > 0) return store.advIdentity;
-
-  try {
-    const curve   = _getCurve();
-    const pubRaw  = Buffer.from(store.identityKeyPair.public,  'base64');
-    const privRaw = Buffer.from(store.identityKeyPair.private, 'base64');
-    const pub32   = pubRaw.length === 33 ? pubRaw.slice(1) : pubRaw;
-    const priv32  = privRaw.length === 32 ? privRaw : privRaw.slice(0, 32);
-
-    const ts      = Math.floor(Date.now() / 1000);
-    const regId   = store.registrationId || 0;
-    const details = _encodeADVDetails(regId, ts, 0);
-
-    const acctMsg = Buffer.concat([WA_ADV_ACCOUNT_SIG_PREFIX, details, pub32]);
-    const acctSig = Buffer.from(curve.sign(priv32, acctMsg));
-
-    const devMsg  = Buffer.concat([WA_ADV_DEVICE_SIG_PREFIX, details, pub32, pub32]);
-    const devSig  = Buffer.from(curve.sign(priv32, devMsg));
-
-    const adv     = _encodeADVSignedIdentity(details, pub32, acctSig, devSig);
-    store.advIdentity = adv;
-    _whaDbg('[DBG] ADV_BUILT from primary iOS keys (' + adv.length + 'b)\n');
-    return adv;
-  } catch (e) {
-    _whaDbg('[DBG] ADV_BUILD_ERR: ' + e.message);
-    return null;
+  // Only ever return an identity the server actually issued.
+  //
+  // ADVSignedDeviceIdentity is minted during companion pairing: it proves a
+  // linked device's identity key was authorised by the primary, and its
+  // accountSignature is made with the primary's key. This client registers
+  // over SMS as the primary, so no pairing IQ ever runs and there is nothing
+  // to attach — which is what the comment above allowPkmsg already says
+  // primaries do.
+  //
+  // This used to fabricate one by self-signing with our own identity key when
+  // the store had none. That identity cannot validate: nothing authorised it.
+  // Attaching it to every pkmsg is a plausible cause of the server rejecting
+  // sends with ack 479 while still delivering messages to us, and it
+  // contradicted the documented behaviour a few lines up. If a real
+  // device-identity is ever received on <success> it is stored and used here;
+  // otherwise the node is simply omitted.
+  if (store && store.advIdentity && store.advIdentity.length > 0) {
+    return store.advIdentity;
   }
+  return null;
 }
 
 function makeJid(input, server) {
@@ -716,14 +709,27 @@ class MessageSender {
     // For LID-migrated accounts, the message `to` field AND Signal participants
     // must use the LID JID.  Phone-JID messages are silently accepted by the
     // server but never delivered to the recipient's LID-registered device.
-    const lidUser      = this._client._pnToLid && this._client._pnToLid.get(recipientPhone);
-    const routingToJid = lidUser ? `${lidUser}@lid` : toJid;
+    //
+    // WA_DM_ROUTE overrides the choice for diagnosis, because both routes have
+    // been observed failing in different ways and only a live account can tell
+    // them apart:
+    //   pn   — always address the phone JID (how this worked before LID JIDs
+    //          started being decoded at all)
+    //   lid  — always address the LID when one is known (the default below)
+    //   auto — same as lid; the default
+    const routeMode  = (process.env.WA_DM_ROUTE || 'auto').toLowerCase();
+    const lidUser    = this._client._pnToLid && this._client._pnToLid.get(recipientPhone);
+    const useLidRoute = lidUser && routeMode !== 'pn';
+    const routingToJid = useLidRoute ? `${lidUser}@lid` : toJid;
 
     _whaDbg('[DBG] DM_ROUTE phone=' + recipientPhone +
-      ' routing=' + routingToJid + (lidUser ? ' (LID)' : ' (PN)'));
+      ' routing=' + routingToJid + (useLidRoute ? ' (LID)' : ' (PN)') +
+      ' mode=' + routeMode);
 
     let otherJids;
-    if (lidUser) {
+    // Follow the same address family as the routing JID — the participants and
+    // the `to` must agree, so WA_DM_ROUTE=pn has to switch both.
+    if (useLidRoute) {
       // Fetch bundle + build Signal session for the LID JID.
       // skipUsync=true: we already know the LID from _pnToLid — skip a second
       // 15 s usync round-trip and go straight to bundle fetch (device 0 primary).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "whalibmob",
-  "version": "5.5.73",
+  "version": "5.5.77",
   "description": "WhatsApp library for interaction with WhatsApp Mobile API no web",
   "author": "Kunboruto50",
   "main": "index.js",