REA: هندسة عكسية لسلوك التطبيقات والملفات الثنائية الأصلية عبر agent

لمن يصلح

يناسب REA من يحتاج إلى الهندسة العكسية داخل الـ agent: المطورين والمشرفين الذين يريدون فهم سلوك تطبيق ما، أو فحص الملفات الثنائية الأصلية وتطبيقات JavaScript وElectron وتجميعات .NET والمواقع الإلكترونية؛ ويناسب أيضًا من يصونون تطبيقات سطح مكتب Electron أو خدمات .NET ويريدون معرفة ما تفعله اعتمادية طرف ثالث أو إصدار قديم فعليًا. يوصل REA أدوات الفحص هذه بالـ agent لديك، ويمكن استخدام الأدوات نفسها مباشرة في الطرفية أيضًا، ويُجرى التحليل محليًا. معيار الحكم بسيط: إذا كان السؤال الذي يتعين عليك الإجابة عنه هو «ماذا يفعل هذا البرنامج أو الملف فعليًا؟» وكانت الإجابة مخبأة في الملفات الثنائية أو مخارج الحزم أو سلوك التشغيل، فمن المفيد تثبيته وتجربته. الحالات غير المناسبة: أن يكون الهدف ملفًا أو تطبيقًا لا تملك صلاحية فحصه؛ أو أن تعجز بيئتك عن تثبيت إصدار Node.js المطلوب؛ أو أن تبحث عن خدمة فحص سحابية خالصة لا تلامس ملفات جهازك.

أول تجربة في 3 دقائق

المسار الرئيسي الموصى به واحد فقط: استخدام أمر setup الرسمي لتسجيل خادم MCP الخاص بـ REA وتثبيت التعليمات المرافقة، ثم إعادة تشغيل الـ agent.

npx rea-agents setup

المتطلبات الأساسية: تثبيت Node.js 22.x (22.19 فأعلى) أو 24.x (24.11 فأعلى) أو 26+ مع npm محليًا. نفّذ الأمر أعلاه في الطرفية؛ فهو يسجّل خادم MCP ويثبّت تعليمات الاستخدام المطابقة. إذا لم ينجح الاتصال، فتحقق أولًا من مطابقة إصدار Node.js للمتطلبات أعلاه.

بعد إعادة التشغيل، نفّذ استدعاءً منخفض الخطورة للتأكد من الاتصال: اطلب من الـ agent فحصًا ساكنًا لملف JavaScript محلي. وضّح طبيعة الإجراء قبل تنفيذه — توضح الوثائق الرسمية أن الفحص الساكن لـ JavaScript و.NET يقرأ الملفات المقدمة فقط ولا يشغّل التطبيق، أي أن هذه الخطوة لن تُطلق البرنامج الهدف. مؤشرات النجاح القابلة للرصد: اكتمال أمر setup وقدرة الـ agent بعد إعادة التشغيل على إظهار نتيجة فحص الملف، ما يعني أن أدوات REA أصبحت متاحة داخل الـ agent. لا تسرد الوثائق الرسمية أسماء كل أداة ومعاملاتها، والمعتمد هو قائمة الأدوات التي يسجّلها الـ agent بعد إعادة التشغيل. وبالإضافة إلى الطلب من الـ agent، يمكنك استخدام الأدوات نفسها مباشرة في الطرفية، وهو الاستخدام الثانوي الموضح في الوثائق الرسمية.

حالات الاستخدام

الحالة الأولى: فهم ملف JavaScript دون تشغيله. السيناريو: وصلك ملف JS معبأ أو مموّه وتريد معرفة ما يفعله قبل أن تقرر تشغيله. الطريقة: مرّر مسار الملف إلى الـ agent ودعه يحلّله بقدرة الفحص الساكن لـ JavaScript في REA. النتيجة المتوقعة: يقرأ الـ agent الملف ويقدّم استنتاجاته دون تشغيل هذا الكود مطلقًا؛ وينطبق الأمر نفسه على تجميعات .NET، فالفحص الساكن لها يقرأ الملفات فقط؛ ويمكن أن تؤيّد الاستنتاجات الساكنة والملاحظات أثناء التشغيل بعضها بعضًا.

الحالة الثانية: التقاط سلوك الهدف أثناء التشغيل. السيناريو: لا يكشف التحليل الساكن شيئًا وتحتاج إلى ملاحظة كيف يعمل البرنامج فعليًا. يجب قبل التنفيذ التأكد من الآثار الجانبية: توضح الوثائق الرسمية أن عملية runtime capture تُشغّل الهدف المختار أو تتفاعل معه بصلاحيات المستخدم، وأن كل دليل runtime يصف آثاره بنفسه؛ بعد تأكيد الهدف وأثره، اطلب من الـ agent تنفيذ الالتقاط. إذا كان الهدف يتضمن بيانات مستخدمين حقيقية أو بيئة إنتاج، فتحقق من الخطوات أولًا على نسخة معزولة. النتيجة المتوقعة: يعيد الـ agent معلومات عن سلوك الهدف أثناء التشغيل؛ وما سيُغيَّر تحديدًا مرجعه الدليل runtime المعني.

حدود الاستخدام

ميّز بين القراءة والكتابة: الفحص الساكن لـ JavaScript و.NET يقرأ الملفات فقط ولا يشغّل أي تطبيق؛ أما runtime capture فإجراء ذو أثر فعلي يُشغّل الهدف أو يتفاعل معه بصلاحيات المستخدم. لا تذكر رسميًا لمسار موحد للتراجع، فلا تفترض أن أي خطوة قابلة للتراجع.

أما موقع التحليل، فتوضح الوثائق الرسمية أن REA يحلّل الأهداف محليًا؛ وهذا يصف مكان حدوث التحليل فقط ولا يشكّل استنتاجًا أمنيًا، وهذا الدليل بدوره لا يصدر حكمًا مستقلًا على تدفقات البيانات أو حدود الخصوصية. مكان حفظ مخارج التحليل محليًا وطريقة تنظيفها غير موضحين في الصفحة الرسمية، وهما بندان غير مؤكدين.

معلومات لا تذكرها الصفحة الرسمية ويلزمك التحقق منها قبل التنفيذ: أسماء كل أداة فحص ومعاملاتها، أنظمة التشغيل وعملاء الـ agent المدعومة، والحاجة من عدمها إلى بيانات اعتماد حساب، وبنود كل دليل runtime على حدة. قد تتغير متطلبات الإصدار مع تطور المشروع، وقبل تنفيذ setup تكون الصفحة الرسمية بلحظتها هي المرجع.