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

اتبع هذه الخطوات بالترتيب. تستبعد كل خطوة منها سببًا شائعًا قبل أن تقضي وقتًا في حصر الكود الفاشل.

1. استبعاد الدفاعات المتقدمة

خطأ لا معنى له بالنسبة إلى كودك، وأكثره شيوعًا RangeError: Invalid array length، يعني عادةً أن بناء الإنتاج يعمل في مكان يجب ألا تعمل فيه بناءات الإنتاج. يعطّل VM Self Defending وVM Debug Protection الكود عمدًا في مشغّلات الاختبار وأدوات الأتمتة الأخرى، والمتصفحات دون واجهة، وNode.js أو jsdom عند تشغيل بناء مخصّص للمتصفح، والمتصفحات التي تكون فيها DevTools مفتوحة. تحقّق قبل أي شيء آخر من المكان الذي يعمل فيه الكود الفاشل.

استبعد أولًا الدفاعات المتقدمة (VM Self Defending وVM Debug Protection وVM Domain Lock): أعد إنتاج العطل باستخدام بناء اختبار يطبّق التجاوزات الواردة في الاختبار وCI. فإذا عمل بناء الاختبار، فالدفاعات تتفاعل مع أدواتك أو بيئتك ولا تعطّل كودك.

2. التحقق من توافق بيئة التشغيل وحصر الدالة الفاشلة

تحقّق من أن target وخط البناء وأي تصريحات للبيئة تطابق المكان الذي يعمل فيه الكود فعليًا.

إذا أبلغ البناء عن تحذيرات تغطية مثل VMNoFunctionsToVirtualize، فانظر تشويش VM لمعرفة ما تغطيه حماية VM.

اختصر الحالة الفاشلة إلى أصغر دالة وموضع استدعاء لا يزالان يُعيدان إنتاجها. استخدم وضع التعليقات لتضييق نطاق الدوال التي تُحوَّل إلى الآلة الافتراضية.

إذا كنت تستخدم vmBytecodeArrayEncoding مع vmBytecodeArrayEncodingKeyGetter، فيجب أن تعيد دالة جلب المفتاح المفتاحَ المستخدم وقت البناء بالضبط. وتحتاج دالة الجلب المتزامنة إلى أن يكون المفتاح مضبوطًا قبل تشغيل الكود المشوَّش. أما دالة الجلب التي تعيد Promise فتتطلب الخيار vmAsyncExecutor. وإذا غاب أيٌّ من ذلك، فلن يمكن فك ترميز البايت كود.

توافق بيئة التشغيل · مفتاح Bytecode Array Encoding

3. أرسل تقريرًا عن الخطأ

راسل support@obfuscator.io. كلما أرفقت المزيد مما يلي، أسرعنا في الإصلاح:

• تتبّع المكدس الكامل للخطأ، تمامًا كما يظهر في وحدة التحكم، لا إعادة صياغة له.
• خيارات المشوِّش بصيغة JSON. انسخ كائن الخيارات الذي استخدمته بالكامل (أو اسم الإعداد المسبق مع أي تجاوزات). التفاعلات الدقيقة بين الخيارات شائعة، لذا نحتاج إلى المجموعة الدقيقة.
• تحذيرات البناء، إن وُجدت: قيم type وmessage وfunctionName لكل منها.
• إصدار المشوِّش، ويظهر في محدد الإصدار في لوحة التحكم أسفل المحرر. أما لاستدعاءات API المباشرة، فهو الحقل version في رسالة result أو chunk_end. ومع حزمة javascript-obfuscator، يظهر في رسالة التقدم (Obfuscating with VM protection (vX.Y.Z)...)، التي يطبعها CLI وتمرّرها obfuscatePro إلى دالة الاستدعاء onProgress الخاصة بها.
• البيئة: المتصفح وإصداره، وإصدار Node.js، ونظام التشغيل، وأي شيء غير معتاد في بيئة التشغيل (الإضافات، وpolyfills، والكائنات المدمجة المخصصة).
• إعادة إنتاج مصغّرة: يُفضَّل أن تكون الدالة الواحدة من القسم 2، مع أي موضع استدعاء يلزم لإطلاق الخطأ.
• المصدر الأصلي (قبل التشويش) متى أمكن. فالناتج المشوَّش مبهم من جهتنا أيضًا؛ ومن دون المدخلات سنضطر إلى الهندسة العكسية للبايت كود الخاص بنا.

إذا كان المصدر مملوكًا لجهة خاصة، فاذكر ذلك في رسالتك، إذ يمكننا توقيع اتفاقية عدم إفصاح قبل أن تشاركه. لا يمكننا تشخيص أخطاء VM بشكل موثوق دون رؤية نمط المدخلات الذي أنتج البايت كود المعطوب، لذا فإن هذه الخطوة الإضافية تستحق العناء.