REA أداة الهندسة العكسية بالذكاء الاصطناعي لتحليل التطبيقات دون Source Code
هل سبق أن استخدمت تطبيقًا وأعجبتك إحدى ميزاته، ثم تمنيت معرفة كيفية تنفيذها برمجيًا؟ أو ربما واجهت برنامجًا لا تملك شيفرته المصدرية، لكنك تحتاج إلى فهم طريقة عمله وتحليل الملفات التي يتكون منها؟
عادةً ما تتطلب هذه المهام خبرة في الهندسة العكسية، واستخدام أدوات متخصصة لفك الشيفرة وتحليل الملفات التنفيذية وتتبع طريقة عمل البرامج. لكن ماذا لو استطعت ربط هذه الأدوات بمساعد برمجي يعتمد على الذكاء الاصطناعي، ثم تطلب منه التحقيق في ميزة محددة وتقديم أدلة على استنتاجاته؟
هذه هي الفكرة التي يعمل عليها مشروع REA، اختصارًا لـ Reverse Engineer Anything، وهو مشروع مفتوح المصدر يربط أدوات الهندسة العكسية بمساعدات البرمجة المدعومة بالذكاء الاصطناعي، من خلال بروتوكول MCP.
بدلًا من التنقل يدويًا بين عشرات الأدوات والملفات، يمكنك طرح سؤال على مساعدك البرمجي، مثل كيفية عمل خاصية البحث داخل تطبيق معين، ليستخدم الأدوات المتاحة لفحص الملفات وتتبع العلاقات بينها، ثم يعرض ما توصل إليه والأدلة التي تدعم النتيجة.
واللافت أن REA لا يقتصر على نوع واحد من البرامج؛ إذ يدعم مجموعة من أهداف التحليل تشمل الملفات التنفيذية الأصلية، وتطبيقات Android، ومشروعات JavaScript وElectron، وتجميعات .NET ومواقع الويب، مع اختلاف المتطلبات بحسب نوع الهدف.
في هذا المقال، سنتعرف على المشروع وطريقة عمله، وأبرز استخداماته، وكيفية تثبيته وربطه بأدوات مثل Claude Code وCodex وCursor.
رابط المشروع الرسمي: REA على GitHub
ما هو REA Reverse Engineer Anything؟
REA هو إطار عمل للتحليل والهندسة العكسية، يجمع بين أدوات الفحص التقليدية ووكلاء الذكاء الاصطناعي في بيئة واحدة.
في الهندسة العكسية التقليدية، قد تحتاج إلى فتح الملف التنفيذي داخل أداة مثل Ghidra، أو استخدام محلل متخصص لتفكيك ملفات APK، أو فحص ملفات JavaScript لمعرفة العلاقات بين الوحدات البرمجية. وبعد ذلك، عليك قراءة النتائج وتفسيرها وربطها بسلوك البرنامج.
أما REA، فيضيف طبقة تساعد وكيل الذكاء الاصطناعي على استخدام هذه الأدوات ضمن مسار تحقيق منظم. تستطيع تحديد التطبيق أو الملف المراد تحليله، ثم طلب تفسير وظيفة معينة أو تتبع جزء من سلوك البرنامج.
على سبيل المثال، يمكنك أن تطلب من المساعد البحث عن الطريقة التي يحفظ بها تطبيق ملاحظات ملف CSV، مع توضيح الأدلة التي تؤيد الإجابة. يستطيع REA فحص مكونات التطبيق وتحديد الوحدات المرتبطة بوظيفة التصدير، ثم يستخدم المساعد هذه النتائج لبناء تفسير قابل للمراجعة.
الفكرة ليست أن الذكاء الاصطناعي يعرف محتويات البرنامج مسبقًا، بل أنه يحصل على أدوات تساعده على فحص البرنامج وجمع أدلة يمكن الاستناد إليها.
كيف يعمل REA مع MCP؟
يعتمد المشروع على MCP، وهو اختصار لـ Model Context Protocol، وهو بروتوكول يتيح لمساعدات الذكاء الاصطناعي الاتصال بأدوات وخدمات خارجية وفق واجهة محددة.
في هذا المشروع، يعمل REA كخادم MCP محلي يتيح للمساعد البرمجي استدعاء أدوات التحليل المناسبة لنوع البرنامج الذي تريد فحصه.
تسير العملية بصورة عامة عبر المراحل التالية:
- تحديد الهدف: توفر مسار التطبيق أو الملف أو مجلد البرنامج الذي ترغب في تحليله.
- اختيار أداة التحليل: يستخدم REA الأدوات المناسبة بحسب نوع الملفات والبيئة المتاحة.
- جمع الأدلة: يستخرج المعلومات المتعلقة بالبنية والوظائف والعلاقات بين المكونات.
- تفسير النتائج: يستخدم مساعد البرمجة المعلومات المستخرجة للإجابة عن سؤالك أو اقتراح خطوات إضافية للتحقيق.
- التحقق والمتابعة: يمكنك طلب توضيح الأدلة، أو فحص جزء آخر من البرنامج، أو اختبار فرضية ظهرت خلال التحليل.
ويتيح هذا النهج التعامل مع الهندسة العكسية عبر أسئلة باللغة الطبيعية، دون التخلي عن الأدوات التقنية التي يحتاج إليها التحليل الفعلي.
ومن المهم التمييز بين MCP نفسه وREA؛ فالأول بروتوكول للتواصل مع الأدوات، بينما يوفر REA مجموعة أدوات التحليل ومسارات العمل التي يستفيد منها المساعد.
ما أنواع التطبيقات والملفات التي يستطيع REA تحليلها؟
إحدى نقاط القوة في المشروع هي تنوع أنواع الملفات والبرامج التي يدعمها. لكن بعض هذه الأنواع يحتاج إلى أدوات إضافية، كما أن مستوى التفاصيل المتاح يختلف من نوع إلى آخر.
1. تحليل الملفات التنفيذية Native Binaries
يدعم REA تحليل الملفات التنفيذية الأصلية، وهي الملفات التي تحتوي على تعليمات مترجمة لمعالج الجهاز بدلًا من الشيفرة المصدرية الأصلية.
يمكن أن يشمل التحليل عرض تعليمات Assembly، واستخراج السلاسل النصية والرموز والمراجع، واستعراض استدعاءات الدوال، وتوليد تمثيل شبه برمجي Pseudocode عند توفر المحرك المناسب.
ويتيح ذلك للمطور فهم بعض جوانب البرنامج حتى عندما لا تكون الشيفرة الأصلية متاحة.
لكن هذا النوع من التحليل يعتمد على الأدوات المستخدمة وطبيعة الملف؛ فوجود الترجمة إلى تعليمات منخفضة المستوى لا يعني إمكانية استعادة الشيفرة الأصلية أو أسماء المتغيرات والتعليقات كما كانت في المشروع الأول.
ولإجراء تحليل أصلي متقدم، يمكن استخدام أدوات مثل Ghidra أو Hopper أو IDA، وفق إعدادات البيئة والدعم المتاح.
2. تحليل تطبيقات Android وملفات APK
إذا كنت مطور Android وتريد فهم بنية تطبيق لا تملك مشروعه الأصلي، فإن دعم ملفات APK من الميزات المهمة في REA.
يساعد المشروع على استخراج معلومات من ملف APK، مثل بيانات Manifest، والفئات البرمجية، والطرائق التي أمكن فكها، وبعض المراجع والعلاقات بين أجزاء التطبيق.
وبحسب نوع الملف والأدوات المتاحة، يمكن الاستفادة من هذه المعلومات في فهم الصلاحيات المعلنة، ومكونات التطبيق، والمسارات البرمجية المرتبطة بوظيفة محددة.
ويعتمد تحليل ملفات APK على أداة JADX مع توفر Java Development Kit مناسب في بيئة التشغيل.
كما يقدم المشروع أدوات منفصلة للتعامل مع أجهزة Android عند توفر ADB، بما في ذلك استعراض الأجهزة والحزم والعمليات وسجلات التشغيل ولقطات الشاشة ونقل بعض الملفات.
وهذا يوسع نطاق الاستخدام من تحليل ملف ثابت إلى جمع معلومات تشغيلية من جهاز تملك صلاحية الوصول إليه.
3. تحليل JavaScript وElectron
تُستخدم JavaScript في تطبيقات الويب، بينما تعتمد تطبيقات Electron على تقنيات الويب لبناء برامج سطح المكتب.
يستطيع REA تحليل مجلدات تطبيقات JavaScript وElectron المستخرجة، أو بعض حزم ASAR، بهدف التعرف على الوحدات البرمجية والاستيرادات والعلاقات بين المكونات وحدود التكامل الخاصة بـ Electron.
وقد يساعد ذلك على فهم كيفية توزيع الوظائف داخل التطبيق، وتحديد الملفات التي ترتبط بميزة معينة، ومعرفة الطريقة التي تتواصل بها بعض الأجزاء.
وتعد هذه الميزة مفيدة عند دراسة تطبيق قديم لم يعد مشروعه الأصلي متاحًا، أو عند محاولة فهم برنامج مبني على Electron قبل إنشاء بديل له.
ومن مزايا هذا النوع من التحليل أنه لا يحتاج إلى محرك متخصص لفك الملفات التنفيذية الأصلية؛ إذ يمكن إجراء الفحص الثابت لملفات JavaScript دون تشغيل التطبيق نفسه.
ومع ذلك، لا يمكن افتراض أن أسماء الوحدات أو العلاقات المستخرجة ستكشف جميع التفاصيل، خصوصًا عندما تكون الشيفرة مصغرة أو محولة أو معقدة البنية.
4. تحليل تجميعات .NET
يدعم المشروع أيضًا تحليل ملفات .NET Assemblies، مع استخراج معلومات عن البيانات الوصفية والتعليمات الوسيطة المعروفة باسم CIL وبعض الاعتماديات الأصلية المعلنة.
وهذا يتيح فحص جوانب من البرامج المبنية على تقنيات .NET دون الحاجة إلى تشغيلها فعليًا.
وقد يفيد المطور الذي يعمل على صيانة تطبيق قديم ويريد معرفة المكونات التي يعتمد عليها، أو فهم طريقة تنفيذ وظيفة محددة، أو مقارنة بعض المعلومات المتعلقة بإصدارات البناء.
وبحسب وثائق المشروع، فإن الفحص الثابت لهذا النوع لا يحتاج إلى محرك تحليل ملفات أصلية مثل Ghidra.
لكن النتائج تظل مرتبطة بالمعلومات المتبقية داخل التجميعة، ولا تعني استعادة مشروع Visual Studio كاملًا كما كان قبل البناء.
5. تحليل مواقع الويب
لا يقتصر REA على التطبيقات التي تعمل على أجهزة الكمبيوتر أو الهواتف، بل يشمل مسارات للتحقيق في مواقع الويب.
يمكن أن يساعد ذلك على فهم سلوك بعض أجزاء الموقع، واستكشاف الوظائف التي ينفذها المتصفح، ومقارنة ما يظهر للمستخدم بما يمكن جمعه من أدلة أثناء الفحص.
وتختلف طبيعة هذا التحليل عن فك شيفرة تطبيق أصلي؛ فموقع الويب قد يجمع بين شيفرة الواجهة المتاحة للمتصفح وخدمات خلفية لا يمكن الوصول إليها من دون صلاحيات مناسبة.
لذلك لا يعني تحليل الموقع إمكانية اكتشاف الشيفرة المصدرية للخادم أو البيانات التي يحتفظ بها، وإنما فحص الأجزاء المتاحة والظواهر التي يمكن ملاحظتها باستخدام الأدوات المحددة.
ويمكن مراجعة الأدلة الإرشادية في الموقع الرسمي للمشروع لمعرفة المتطلبات الخاصة بكل نوع من أنواع التحليل.
إظهار الأدلة والقيود بدلًا من الاكتفاء بالتخمين
من المشكلات المعروفة عند استخدام نماذج الذكاء الاصطناعي في فهم البرامج أنها قد تقدم تفسيرًا مقنعًا لغويًا، لكنه غير صحيح تقنيًا أو لا تدعمه أدلة كافية.
يحاول REA التعامل مع هذه المشكلة من خلال تنظيم نتائج التحليل حول الملاحظات والأدلة والقيود والمعلومات غير المحسومة.
فعندما يسألك المساعد عن وظيفة معينة، لا ينبغي أن يكون الهدف الحصول على إجابة عامة فقط؛ بل معرفة الملفات أو الدوال أو الاستدعاءات التي تدعم هذا الاستنتاج، والأجزاء التي لم يتمكن النظام من فحصها.
على سبيل المثال، إذا أظهرت الأدلة أن إحدى الدوال تقرأ ملف إعدادات، فقد يكون من المعقول استنتاج أن الدالة تشارك في تحميل الإعدادات. لكن ذلك لا يثبت بالضرورة أنها المسؤولة الوحيدة عن إعدادات التطبيق بأكمله.
وتزداد أهمية هذا النهج في الملفات التنفيذية التي لا تحتوي على معلومات رمزية كافية، أو في التطبيقات التي تعتمد على مكتبات خارجية، أو عندما تكون بعض تفاصيل التشغيل غير متاحة.
ولهذا السبب، من الأفضل اعتبار REA مساعدًا لجمع الأدلة وتنظيمها وتفسيرها، وليس بديلًا عن المراجعة التقنية أو التحقق من الاستنتاجات.
هل يعمل REA محليًا؟ وماذا عن الخصوصية؟
وفق وثائق المشروع، يُجرى التحليل محليًا على الجهاز، وتُعاد النتائج عبر واجهة الأوامر أو MCP بدلًا من الاعتماد على رفع الملفات إلى خادم REA لتنفيذ عملية الفحص.
وهذه نقطة مهمة للمطورين الذين يحتاجون إلى دراسة تطبيقاتهم أو ملفاتهم الداخلية دون إرسال الملفات الأصلية إلى خدمة تحليل خارجية.
لكن هناك تفصيلًا يجب الانتباه إليه: التحليل المحلي لا يعني بالضرورة أن جميع المعلومات تظل داخل الجهاز في كل المراحل.
فعندما تستخدم REA مع مساعد برمجي متصل بمزود نموذج ذكاء اصطناعي، يمكن أن تُرسل نتائج التحليل التي يعيدها REA إلى ذلك المساعد لكي يفسرها. ولذلك يعتمد التعامل مع هذه النتائج على إعدادات الأداة وسياسة البيانات الخاصة بمزود النموذج أيضًا.
ومن الأفضل مراجعة طبيعة النتائج التي تتم مشاركتها وسياسات الخصوصية قبل تحليل ملفات سرية أو تطبيقات تحتوي على معلومات حساسة.
كذلك ينبغي عدم اختبار برامج الغير أو تجاوز وسائل الحماية الخاصة بها إلا عندما تكون مخولًا بذلك، مع احترام حقوق الملكية الفكرية والقوانين المعمول بها.
تعليقات
إرسال تعليق