VulnFanatic-NG

بحث الثغرات بمساعدة LLM لـ Binary Ninja.

يضيف VulnFanatic-NG لوحة جانبية تفحص الثنائي الحالي وتطلب من LLM — نموذج مستضاف محليًا متوافق مع OpenAI افتراضيًا، أو Anthropic Claude أو Google Gemini أو Azure OpenAI (انظر محركات LLM الخلفية) — لتقرير ما إذا كان الكود المشبوه ضعيفًا فعلًا. يعمل بشكل أساسي على مخرجات المُفكِّك (HLIL)، ويعود إلى لغة التجميع عند الحاجة، ويبلغ فقط بالمشكلات المؤكدة مع مراجع قابلة للنقر تعيد إلى الكود.

---

كيف يعمل

تعمل عملية الفحص في مراحل يصل عددها إلى ثلاث (المرحلة 3 اختيارية وتعتمد على الإنترنت حصريًا):

المرحلة 1 — استدعاءات الدوال الخطرة

يجد مواقع استدعاء الدوال الخطرة المعرّفة في rules/phase1_rules.json — strcpy، memcpy، sprintf/سلاسل التنسيق، system، alloca، scanf، واجهات برمجة الأوامر/التنفيذ، خوارزميات RNG ضعيفة، عائلة free/delete (استخدام بعد التحرير / تحرير مزدوج)، قراءات مدخلات غير موثوقة في مخازن ثابتة (recv/read/fread/ReadFile)، حقن SQL (sqlite3_exec/mysql_query/PQexec)، تعطيل التحقق من شهادة TLS (SSL_CTX_set_verify/curl)، SSRF، وإدارة امتيازات غير سليمة (setuid/setresgid)، وعائلة memset/bzero، و مقارنات بطول يتحكم فيه المهاجم (memcmp/strncmp → تجاوز المصادقة)، عبر C/C++ وWin32 وRust FFI (بأقصى جهد ممكن). التغطية تشمل المتغيرات المحصّنة _chk (FORTIFY) ومتغيرات Annex-K _s. دوال الإخراج المنسّق المحدودة (snprintf وما يشابهها) لها قاعدة افتراضية آمنة خاصة بها حتى لا يُبلَّغ عن وسيط حجم صحيح على أنه تجاوز. تُكتشف مواقع الاستدعاء بثلاث طرق: استدعاءات مباشرة للرموز المسماة؛ استدعاءات تُوجَّه عبر thunks مُمرِّرة / PLT stubs (يُستعاد المستدعون الحقيقيون، لذا لا يُفوَّت استيراد لا يُوصَل إليه إلا عبر stub)؛ و— ما لم يكن vulnfanatic.scanIndirectCalls معطّلًا — استدعاءات غير مباشرة تُرسَل عبر مؤشر دالة أو vtable حُلّت بواسطة Binary Ninja إلى دالة خطيرة. لكل موقع استدعاء، يبني سياقًا بين الإجراءات متمحورًا حول المُفكِّك، محدودًا بحد أقصى للتوكنات (افتراضيًا 100k):

• تعبير الاستدعاء ووسائطه،
• النموذج الأولي المُعلن للدالة المُستدعاة (من معلومات الأنواع في Binary Ninja، وإلا من جدول مدمج) حتى يربط النموذج الوسائط بالمعاملات بشكل صحيح — المتغيرات المحصّنة __*_chk والمتغيرات ذات التحقق من الحدود *_s تأخذ وسائط إضافية في البداية، مما يغيّر موضع التنسيق/الحجم/الوجهة،
• نوع وحجم كل وسيط استدعاء بالبايت (سعات المخازن)، المشتق من نوع تعبير HLIL للوسيط بحيث يُحل حقل بنية مثل s->buf إلى الحجم الحقيقي لمصفوفة الحقل بدلًا من حجم مؤشر s؛ تعريفات البنيات في قسم الأنواع تحمل أيضًا أحجامًا بالبايت لكل حقل،
• القيمة / النطاق الفعلي لكل وسيط الذي حُلّ بواسطة تحليل نشر الثوابت وتحليل مجموعة القيم في Binary Ninja (مثلًا، طول مُثبَت أنه ثابت 0x40 أو محصور في [0, 0xff])، ويستخدمه النموذج كحقيقة قاطعة عند مقارنة الحجم بسعة المخزن بدلًا من التخمين،
• تخطيط إطار المكدس للدالة المستدعية (إزاحات المتغيرات وأحجامها بالبايت) عندما تحتوي على مخزن ثابت الحجم، حتى يمكن الحكم على تجاوز المكدس مقارنةً بالمتغيرات المجاورة وعنوان العودة المحفوظ (vulnfanatic.includeStackLayout)،
• قيود المسار (شروط if/الحلقة/switch التي تحرس الاستدعاء)،
• ملخص تدفق بيانات الوسائط — أين يُعرَّف كل وسيط استدعاء وأين يُستخدم داخل الدالة،
• حل المعاملات عبر المستدعين — عندما يكون وسيط خطير معاملًا للدالة المستدعية، يبلّغ السياق بما يمرره كل مستدعٍ فعلًا له (مثلًا، "كل المستدعين يمررون نصًا حرفيًا")، حتى لا يُظن خطأً أن معامل تنسيق/حجم ثابت دائمًا هو شيء يتحكم فيه المهاجم،
• النص الكامل المُفكَّك للدالة المستدعية،
• تعريفات أنواع البيانات (struct/union/enum) للأنواع المُشار إليها عبر سلسلة الاستدعاء ومتغيرات الوسائط، حتى يعرف النموذج الأحجام الحقيقية للمخازن/الحقول وعروض الأعداد الصحيحة،
• النصوص المُفكَّكة للدوال التي تنتج أو تستهلك متغيرات وسائط الاستدعاء (المتتبَّعة عبر تعريف/استخدام HLIL)، وهذا ما يجعل الاستدلال على استخدام بعد التحرير / التحرير المزدوج والأحجام الملوثة ممكنًا،
• مسارات الاستدعاء من نقاط الدخول / الدوال المُصدَّرة وصولًا إلى الاستدعاء،
• النص المُفكَّك لكل دالة على طول تلك المسارات (الأقرب إلى الاستدعاء الخطير أولًا)، مع تعليق على كل منها بموقع الاستدعاء والشروط التي تحرس القفزة التالية،
• نصوص الدوال الأخرى التي تستدعيها دوال المسار (مثلًا، بالنسبة إلى MAIN→ABCD→strcpy، أيضًا الدوال التي يستدعيها MAIN وABCD في أماكن أخرى)، لأنها قد تحتوي على فحوصات الحدود/التحقق التي تُحكِم القيمة الخطرة (vulnfanatic.includeCallPathSiblings، تُمتلأ طالما تسمح الميزانية)، و
• تلميحات المصدر الملوث (دوال إدخال مثل recv/read/getenv تُستدعى في نفس الدالة).

يُرسل هذا السياق مع موجه خاص بالقاعدة إلى النموذج، الذي يعيد حكمًا منظمًا. يتم تجاهل غير المشكلات. وقد ضُبطت الموجّهات لنموذج كود محلي قوي (مثل Qwen2.5-Coder) وتطلب منه تحليل التدفق بالكامل وإخراج JSON فقط.

الاستدلال، والمسودة، والثقة

يُطلب من النموذج تفضيل الاسترجاع — الإبلاغ عن المشكلات المحتملة وذات الصلة بالأمان والتعبير عن عدم اليقين عبر Confidence بدلًا من تجاهل أي شيء لا يستطيع إثباته تمامًا. يعرض عمله في مسودة تقتبس حرفيًا مقتطفات الكود التي اعتمد عليها (مصدر الإدخال، كل حارس، الحجم/الطول، النوع ذي الصلة، والمغسلة)، ويُخزَّن ذلك في النتيجة حتى يمكنك مراجعة الاستدلال.

تحمل كل نتيجة Confidence (عالية/متوسطة/منخفضة): عالية = السلسلة كاملة ظاهرة في السياق؛ متوسطة = محتملة، مع استنتاج رابط أو رابطين؛ منخفضة = خيط يستحق مراجعة يدوية. هذا هو المقياس الرئيسي (تقدير النموذج لشدة الخطورة هو حقل ثانوي). اضبط vulnfanatic.minConfidence لتجاهل أي شيء يقل عن حد معيّن.

ضبط الدقة مقابل الاسترجاع

افتراضيًا يفضّل VulnFanatic-NG الاسترجاع (اكتشاف المشكلات الحقيقية). إذا حصلت على عدد كبير جدًا من النتائج الإيجابية الخاطئة، فشدّد باستخدام أيٍّ من:

• vulnfanatic.validationPass (افتراضيًا معطّل) — يشغّل تمريرة LLM ثانية تتحقق مرة أخرى من كل مشكلة تم الإبلاغ عنها مقابل نفس السياق (التحقق من مقتطفات المسودة وإعادة تتبع التدفق) ويمكنها تصحيح الحكم أو الثقة. يضاعف استدعاءات LLM للمرشحين المبلَّغ عنهم.
  • نموذج تحقق منفصل (موصى به عند استخدام تمريرة التحقق). اضبط vulnfanatic.validatorModel (بالإضافة إلى validatorProvider / validatorBaseUrl / validatorApiKey) لتشغيل التمريرة الثانية على نموذج مختلف. الرأي الثاني أكثر فائدة بكثير من نموذج مستقل — فهو يشارك نقاطًا عمياء أقل ومن غير المرجح كثيرًا أن يصدّق الحكم الأول تلقائيًا (تميل النماذج إلى تفضيل إجاباتها الخاصة). النمط الجيد هو تسلسل متتالٍ: نموذج سريع بصفته المحلل (استرجاع واسع) وأقوى نموذج لديك بصفته المدقّق، الذي يعمل فقط على المرشحين المبلَّغ عنهم. اترك نموذج المدقّق فارغًا للتحقق باستخدام نموذج المحلل. يجب أن يكون المدقّق بقدرة المحلل على الأقل — فالنموذج الأضعف يضيف في الغالب رفضًا خاطئًا. كل شيء ما عدا المزوّد/عنوان URL الأساسي/المفتاح/ النموذج موروث من إعدادات اتصال المحلل؛ والمفتاح الفارغ للمدقّق يعيد استخدام مفتاح المحلل؛ وإذا كانت نقطة نهاية المدقّق غير قابلة للوصول، يُحتفظ بالحكم الأول (لا تُفقد النتيجة أبدًا بسبب انقطاع المدقّق).
• vulnfanatic.minConfidence (افتراضيًا low) — ارفعه إلى medium/high للإبلاغ فقط عن النتائج الأقوى.
• vulnfanatic.skipConstantArgCalls (افتراضيًا معطّل) — يتخطى مواقع استدعاءات فئة التجاوز التي تكون جميع وسائطها ثوابت وقت الترجمة.

السرعة. معظم زمن الانتظار لكل استدعاء هو الاستدلال المكتوب، لذا يتحكم vulnfanatic.verdictReasoning في مقدار ما يكتبه النموذج:

• concise (افتراضيًا) — مبرر موجز من 1–3 جمل، دون اقتباس كود. أسرع بكثير من full مع خسارة قليلة في الدقة؛ يمكنك أيضًا خفض vulnfanatic.maxResponseTokens.
• full — المسودة المفصلة مع المقتطفات المقتبسة (الأكثر قابلية للتدقيق، والأبطأ).
• none — الحكم فقط. الأسرع؛ اقرنه بنهاية خلفية تدعم الاستدلال (vulnfanatic.reasoningEffort) حتى يقوم تفكير النموذج الداخلي بالعمل. على نموذج محلي عادي، يفقد none الدقة (لا يوجد سلسلة أفكار على الإطلاق).

ميزات دعم الدقة التي تعمل دائمًا (تُعلم النموذج دون إخفاء النتائج):