whalibmob 5.5.75 → 5.5.77

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.75",
+  "version": "5.5.77",
   "description": "WhatsApp library for interaction with WhatsApp Mobile API no web",
   "author": "Kunboruto50",
   "main": "index.js",