التوثيق
/
وصفات عملية
/

تشخيص أخطاء التشغيل في VM

تشخيص أخطاء التشغيل في VM

يطلق كودك المشوَّش بـ VM خطأً أثناء التشغيل - وقد يكون RangeError: Invalid array length، لكن قائمة التحقق نفسها تنطبق على الأخطاء غير المتوقعة الأخرى التي لا تظهر إلا بعد التشويش. اتبع الخطوات أدناه بالترتيب. فالخطوة الأولى تلتقط السبب الأكثر شيوعًا بفارق كبير، أما البقية فتحصر الخلل البرمجي الحقيقي.

الخطوة 1 - طابِق بيئة التشغيل مع الخيار target

السبب الأكثر شيوعًا على الإطلاق لخطأ Invalid array length وما يشبهه هو عدم التطابق بين الخيار target والبيئة التي يعمل فيها الكود فعليًا، مقترنًا بـ vmSelfDefending: true.

البيئات التي يحدث فيها ذلك:

  • Node.js (تشغيل الحزمة المشوَّشة مباشرةً عبر node)
  • Headless Chrome / Chromium وPhantomJS
  • Puppeteer وPlaywright وCypress وSelenium / ChromeDriver وNightmare
  • jsdom وغيره من محاكاة DOM من جهة الخادم
  • أي بيئة اعتُرضت فيها دوال المتصفح الأصلية المدمجة أو استُبدلت

إذا كانت بيئة تشغيلك ضمن تلك القائمة، فالخطأ هو الحماية تعمل كما صُمِّمت، لا خللًا برمجيًا. اختر الحل الذي يطابق حالتك:

  • التشغيل في Node.js عن قصد (سكربت من جهة الخادم أو أداة سطر أوامر أو عملية Electron الرئيسية): اضبط target: 'node' عند التشويش. عندها تعاير طبقة الدفاع الذاتي نفسها لـ Node بدلًا من المتصفح.
  • تشغيل اختبارات آلية / اختبارات E2E على بناء مشوَّش (Cypress أو Playwright أو Puppeteer أو Selenium): أنتج بناء اختبار منفصلًا بـ vmSelfDefending: false. فهذا الخيار مصمم لتعطيل الأتمتة، ولا يمكن استثناء أدوات بعينها منه. انظر الدفاع الذاتي لـ VM للاطلاع على القائمة الكاملة للبيئات غير المتوافقة.
  • التشغيل في متصفح حقيقي مع استمرار ظهور الخطأ: تأكد من عدم وجود إضافة أو سكربت في أدوات المطورين أو صفحة غلاف تعترض الدوال الأصلية المدمجة (Array وFunction.prototype وJSON وغيرها). أعد إنتاج المشكلة في ملف تعريف نظيف قبل اعتبارها خللًا برمجيًا.

الخطوة 2 - احصر المشكلة في دالة واحدة

إذا لم تحل الخطوة 1 المشكلة، فالخطأ موجود في جزء بعينه من الكود المحوَّل. انتقل إلى vmTargetFunctionsMode: 'comment' وأضف /* javascript-obfuscator:vm */ إلى دالة واحدة في كل مرة حتى يظهر الخطأ من جديد. فالدالة التي أشّرت عليها حين عاد الخطأ هي المسؤولة - وهي المثال الأدنى لإعادة الإنتاج الذي سترسله إلى الدعم.

الخطوة 3 - أرسل تقرير خلل

بعد أن تتأكد أن الأمر ليس عدم تطابق بين target والدفاع الذاتي، وبعد أن تحصر المشكلة في دالة، راسلنا على support@obfuscator.io. وكلما أدرجت المزيد مما يلي، أسرعنا في الإصلاح:

  • تتبّع المكدس الكامل للخطأ، كما يظهر تمامًا في الطرفية - لا إعادة صياغة له.
  • خيارات المشوِّش بصيغة JSON. انسخ كائن الخيارات الذي استخدمته بالكامل (أو اسم الإعداد المسبق مع أي تجاوزات). فالتفاعلات الخفية بين الخيارات شائعة، ولذلك نحتاج إلى المجموعة الدقيقة.
  • إصدار المشوِّش - ويظهر في الركن السفلي الأيسر من المحرر.
  • البيئة - المتصفح وإصداره، وإصدار Node.js، ونظام التشغيل، وأي شيء غير معتاد في بيئة التشغيل (الإضافات وحزم التوافق والدوال المدمجة المخصصة).
  • أدنى مثال لإعادة الإنتاج - ويُفضَّل أن يكون الدالة المفردة من الخطوة 2، مع موضع الاستدعاء اللازم لإطلاق الخطأ.
  • الكود المصدري الأصلي (قبل التشويش)، متى أمكن. فالناتج المشوَّش مبهم من جانبنا نحن أيضًا، وبدون المُدخل نكون بصدد هندسة عكسية لبايت كودنا نفسه.