whalibmob 5.5.43 → 5.5.44

package/.env.example

@@ -0,0 +1,49 @@
+# ─────────────────────────────────────────────────────────────────────────────
+# whalibmob — Device Emulation Configuration
+# Copy this file to .env in your project root and set the values you need.
+# All variables are optional; defaults emulate an iPhone 15 Pro running iOS 17.
+# ─────────────────────────────────────────────────────────────────────────────
+
+# Operating system to emulate.  Accepted values: ios | android
+# Default: ios
+# WA_OS=android
+
+# Named device profile.
+#
+# iOS profiles (WA_OS=ios):
+#   iphone_15_pro, iphone_15, iphone_14_pro, iphone_14, iphone_13_pro,
+#   iphone_13, iphone_12_pro, iphone_12, iphone_11_pro, iphone_11,
+#   iphone_se3, iphone_xs
+#
+# Android profiles (WA_OS=android):
+#   pixel_8_pro, pixel_8, pixel_7, pixel_7a,
+#   samsung_s24_ultra, samsung_s24, samsung_s23_ultra, samsung_s23, samsung_a55,
+#   oneplus_12, oneplus_11, xiaomi_14, xiaomi_13, oppo_find_x7, realme_gt5
+#
+# Default: iphone_15_pro  (or pixel_8_pro when WA_OS=android)
+# WA_DEVICE=pixel_8_pro
+
+# ── Custom device overrides (applied on top of the selected profile) ─────────
+# Use these to fine-tune any field without creating a new profile.
+
+# WA_DEVICE_MODEL=SM-S928B
+# WA_DEVICE_MANUFACTURER=samsung
+# WA_DEVICE_OS_VERSION=14
+# WA_DEVICE_BUILD=UP1A.231005.007
+# WA_DEVICE_MODEL_ID=samsung-sm-s928b
+
+# ── Version & token overrides ─────────────────────────────────────────────────
+
+# Pin the WhatsApp version string instead of fetching the latest from the store.
+# Format: 2.x.x.x  (four-part)
+# WA_VERSION=2.24.13.80
+
+# Override the static token used in registration token computation.
+# Only needed if WhatsApp rotates the bundled token.
+# WA_STATIC_TOKEN=Y29Cs6AVNR2bj5PBeKSYFd1nAKuvNQ3h
+
+# ── Proxy / Tor ───────────────────────────────────────────────────────────────
+
+# Route registration HTTP traffic through a SOCKS5 proxy or Tor.
+# TOR_PROXY=socks5://127.0.0.1:9050
+# SOCKS_PROXY=socks5://user:pass@proxy.example.com:1080

package/lib/DeviceManager.js

@@ -59,29 +59,6 @@ function phoneFromJid(jid) {
   return user;
 }
 
-// ─── JID object → string (device-preserving) ─────────────────────────────────
-//
-// The WA binary decoder produces AD_JID objects with shape:
-//   { user: 'N', agent: A, device: D, server: 's.whatsapp.net' }
-// The built-in toString() on these objects returns "N@server" — dropping the
-// device number.  Always use jidObjToStr() when stringifying a JID that may
-// have come from the binary decoder (e.g. response node attrs.jid).
-//
-// This is the root cause of the multi-device fanout bug: fetchBundles was
-// calling String(jidRaw) and getting the same "N@s.whatsapp.net" key for all
-// four response bundles (device 0, 13, 14, 15), causing the Map to overwrite
-// itself three times and return count=1 instead of count=4.
-//
-function jidObjToStr(jidRaw) {
-  if (typeof jidRaw === 'string') return jidRaw;
-  if (!jidRaw) return '';
-  const user   = String(jidRaw.user   || '');
-  const server = String(jidRaw.server || 's.whatsapp.net');
-  const device = parseInt(jidRaw.device, 10) || 0;
-  if (device > 0) return `${user}:${device}@${server}`;
-  return `${user}@${server}`;
-}
-
 // ─── Bundle parsing ───────────────────────────────────────────────────────────
 
 function findChild(node, desc) {
@@ -376,11 +353,8 @@ class DeviceManager {
       if (!userNode || userNode.description !== 'user') continue;
       const jidRaw = userNode.attrs && userNode.attrs.jid;
       if (!jidRaw) continue;
-      // Use jidObjToStr (NOT String()) so the device number is preserved from
-      // the binary-decoded AD_JID object.  String() / toString() only returns
-      // "user@server", losing the ":device" part — which caused all 4 per-device
-      // bundles to overwrite each other in the Map, producing count=1.
-      const jidStr = jidObjToStr(jidRaw);
+      // Always normalise to a string key so Map lookups are consistent
+      const jidStr = String(jidRaw);
       _whaDbg('[DBG] FETCH_BUNDLES_USER jid=' + jidStr +
         ' childTags=' + (Array.isArray(userNode.content)
           ? userNode.content.map(c => c && c.description).filter(Boolean).join(',')
@@ -715,66 +689,31 @@ class DeviceManager {
     }
 
     if (allowPkmsg && fetchJids.length > 0) {
-      // ── parseAndInjectE2ESessions pattern (Baileys-equivalent) ─────────────
-      //
-      // The WA server responds to bundle-fetch IQs for LID device JIDs
-      // (e.g. 112713111982325:13@lid) only for device 0 — device-specific
-      // @lid JIDs are silently ignored and the server returns a single bundle
-      // for the primary device only.
-      //
-      // SOLUTION: fetch bundles using PN (phone number) AD_JID format instead
-      // — the server responds to "40756469325:13@s.whatsapp.net" correctly and
-      // returns all four device bundles.  We then build the Signal sessions
-      // keyed by the corresponding LID device JID ("112713111982325:13@lid")
-      // so that MessageSender finds them when encrypting for the @lid routing
-      // address.  This is the same principle as Baileys' parseAndInjectE2ESessions:
-      // separate "where to fetch the bundle from" and "what JID to key the session under".
-      //
-      const pnForLid = this._client._lidToPn && this._client._lidToPn.get(lidUser);
-
-      let bundleFetchJids;
-      if (pnForLid) {
-        // Build PN AD_JID fetch list matching each LID device JID by device number.
-        bundleFetchJids = fetchJids.map(lidDevJid => {
-          const { device } = stripUser(lidDevJid);
-          return makeDeviceJid(pnForLid, device);
-        });
-        _whaDbg('[DBG] LID_PN_FETCH pn=' + pnForLid +
-          ' jids=[' + bundleFetchJids.join(',') + ']\n');
-      } else {
-        // No PN known — fall back to LID JIDs (may only return device 0)
-        bundleFetchJids = fetchJids;
-        _whaDbg('[DBG] LID_FALLBACK_FETCH no-pn jids=[' + fetchJids.join(',') + ']\n');
-      }
-
-      const bundles = await this.fetchBundles(bundleFetchJids);
-
-      for (const [bundleJid, bundle] of bundles) {
-        // Determine the LID session JID for this device.
-        // If we fetched by PN, bundleJid is "40756469325:13@s.whatsapp.net"
-        // → extract device number → build "112713111982325:13@lid"
-        // If we fetched by LID, bundleJid is "112713111982325@s.whatsapp.net"
-        // → strip server → append @lid
-        let lidDevJid;
-        if (pnForLid) {
-          const { device } = stripUser(bundleJid);
-          lidDevJid = makeDeviceJid(lidUser, device, 'lid');
-        } else {
-          const jidBase = bundleJid.replace(/@(?:s\.whatsapp\.net|lid)$/, '');
-          lidDevJid = jidBase + '@lid';
-        }
-
+      const bundles = await this.fetchBundles(fetchJids);
+      for (const [jid, bundle] of bundles) {
         try {
-          // Build (or overwrite) the Signal session keyed by the LID device JID.
-          // The session address is (user, device) — @server suffix is stripped
-          // internally — so "112713111982325:13@lid" and "112713111982325:13@s.whatsapp.net"
-          // resolve to the same Signal address.  We always push @lid form so the
-          // participants node is consistent with the outer message routing address.
-          await signalProto.buildSessionFromBundle(lidDevJid, bundle);
-          readyJids.push(lidDevJid);
-          _whaDbg('[DBG] LID_SESSION_BUILT bundle=' + bundleJid + ' → participant=' + lidDevJid);
+          await signalProto.buildSessionFromBundle(jid, bundle);
+          // ── CRITICAL: remap bundle JID back to @lid format ────────────────────
+          // fetchBundles always returns JIDs in @s.whatsapp.net format (because the
+          // WA server uses its own AD_JID / JID_PAIR encoding in responses).
+          // But the outer <message to="lidUser@lid"> requires ALL participant <to>
+          // 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"
+          const jidBase = jid.replace(/@(?:s\.whatsapp\.net|lid)$/, '');
+          const lidJidForDevice = jidBase + '@lid';
+          readyJids.push(lidJidForDevice);
+          _whaDbg('[DBG] LID_SESSION_BUILT jid=' + jid + ' → participant=' + lidJidForDevice);
         } catch (e) {
-          _whaDbg('[DBG] LID_SESSION_ERR jid=' + lidDevJid + ' err=' + e.message);
+          _whaDbg('[DBG] LID_SESSION_ERR jid=' + jid + ' err=' + e.message);
         }
       }
     }

package/package.json

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