مرحبًا بك في دورة الهندسة العكسية. سنبني فيها المهارات التي تحتاجها لتحليل برامج Windows وفهم سلوكها، ثم استخدام أدوات مثل Ghidra وx64dbg وdnSpy ضمن مختبرات آمنة. لكن قبل قراءة أول بايت أو فتح أي ملف في المصحّح، توجد مهارة مهنية أساسية: التحقق من أن التحليل مصرّح به قانونيًا وأخلاقيًا.
هذه ليست خطوة شكلية. في الوظائف الأمنية والتحليلية، لا يكفي أن تستطيع اكتشاف منطق برنامج أو ثغرة؛ يجب أن تعرف متى تتوقف، ومن يملك صلاحية منح الإذن، وكيف تثبت أن ما فعلته بقي ضمن النطاق. بنهاية الدرس ستستطيع تصنيف سيناريوهات شائعة إلى: مصرّح، يحتاج توضيحًا، أو غير مصرّح، مع توثيق قرارك بصورة مهنية.
تنبيه مهم: هذا الدرس إطار عملي عام، وليس استشارة قانونية. تختلف القوانين وقابلية إنفاذ العقود والتراخيص باختلاف الدولة والسياق. عند وجود مشروع حقيقي، أو بيانات حساسة، أو شك معقول، توقّف واطلب تأكيدًا مكتوبًا من مالك النظام أو المختص القانوني.
ثلاث طبقات يجب أن تجتازها قبل التحليل
الهندسة العكسية ليست جيدة أو سيئة في ذاتها؛ يتحدد الحكم من خلال الهدف، والصلاحية، والطريقة، والأثر المتوقع. ومن المفيد فصل القرار إلى ثلاث طبقات:
| الطبقة | السؤال العملي | مثال على مشكلة |
|---|---|---|
| التصريح والصلاحية | هل يحق لك فعل ذلك على هذا الأصل تحديدًا؟ | فحص موقع شركة لم تمنحك تفويضًا |
| القانون والعقد | هل توجد قوانين أو تراخيص أو اتفاقيات تمنع هذا النشاط أو تقيده؟ | تفكيك برنامج تجاري رغم شروط ترخيص تمنع ذلك |
| الأخلاق وتقليل الضرر | هل تحمي الخصوصية والبيانات والخدمة والأطراف الأخرى؟ | استخراج بيانات مستخدمين لمجرد أنها ظهرت أثناء التحليل |
امتلاك نسخة من برنامج أو جهاز لا يعني تلقائيًا امتلاك حق تحليل كل جوانبه أو تجاوز حماياته أو توزيع ناتج التحليل. وبالمثل، القدرة التقنية ليست تصريحًا: أن تستطيع العثور على نقطة تحقق، أو تجاوزها، أو تشغيل عينة خبيثة لا يجعل ذلك مسموحًا خارج بيئة وتفويض واضحين.
اقرأ الإطار الرسمي التالي لفهم معنى النطاق و«حسن النية» في أبحاث الثغرات. هذا المصدر خاص بسياسات جهات حكومية أمريكية، لكنه يقدم نموذجًا عمليًا مفيدًا لا ينبغي تعميمه تلقائيًا على أي جهة أو برنامج مكافآت.
BOD 20-01: Develop and Publish a Vulnerability ...
تشرح CISA كيف تجعل سياسة الإفصاح عن الثغرات البحث مصرحًا به ضمن شروط محددة، ولماذا لا تكفي النية الحسنة وحدها من دون الالتزام بالنطاق وطريقة الإبلاغ.
ابدأ من قسم Background، واقرأ فكرة السياسة لفهم وظيفة سياسة الإفصاح. ثم انتقل إلى قسم VDP FAQ، تحت سؤال What does the directive mean by “good faith”?، واقرأ علامات حسن النية، مع الانتباه إلى أن اختبار نظام خارج النطاق عمدًا ليس بحثًا حسن النية. أخيرًا، في قسم Develop and Publish a Vulnerability Disclosure Policy، راجع عناصر التقرير في القائمة الفرعية، وبالأخص تعليمات الإبلاغ، ولاحظ أن السياسة تحدد الأصول والنشاطات المسموح بها.
التصريح ليس كلمة عامة
التصريح الجيد يجيب بدقة عن أربعة أمور:
- من أصدر الإذن، وهل يملك فعليًا سلطة على الأصل؟
- ما الأصل المشمول: اسم التطبيق، النطاق، عنوان الشبكة، الإصدار، أو ملف العينة.
- ما النشاط المسموح: تحليل ساكن فقط، تشغيل في مختبر، تصحيح أخطاء، اختبار مدخلات، إلخ.
- ما الحدود: وقت الاختبار، الحسابات المخصصة، البيانات المحظورة، الإجراءات الممنوعة، وطريقة الإبلاغ.
فمثلًا، رسالة تقول: «افحص أمن تطبيقنا» غير كافية إذا لم تحدد بيئة الاختبار والنطاق. لا تمنح هذه الرسالة عادةً صلاحية لمسح خوادم الإنتاج، أو اختبار نطاقات فرعية أخرى، أو الوصول إلى بيانات العملاء.
في المقابل، وجود سياسة إفصاح عن ثغرات (VDP) أو برنامج مكافآت قد يمنح إذنًا، لكن فقط ضمن ما تنص عليه السياسة. اقرأ دائمًا:
- الأصول أو النطاقات المسموح اختبارها.
- أنواع الاختبار المسموح بها والمحظورة.
- القيود على الإغراق، والهندسة الاجتماعية، والوصول إلى البيانات.
- متطلبات الإبلاغ والمهلة الزمنية للتواصل.
- نص الحماية أو الوعد بعدم اتخاذ إجراء قانوني عند الالتزام بالسياسة.
حسن النية ليس تصريحًا مفتوحًا. قد تكون نيتك تعليمية أو دفاعية، لكن اختبار أصل غير مشمول، أو توسيع نطاقك ذاتيًا، أو الاحتفاظ ببيانات حساسة، يخرجك عن الحدود المقبولة.
الملكية الفكرية، التراخيص، والخصوصية
تتعامل الهندسة العكسية مع طبقات مختلفة من الحقوق والمخاطر. لا تحتاج إلى حفظ قوانين كل دولة الآن، لكن تحتاج إلى التعرف على إشارات التوقف.
Ethical Considerations in Reverse Engineering: Navigating Legal Boundaries – reverse.ca
يقدم هذا المقال خريطة أولية للمسائل التي تظهر أثناء تفكيك البرامج: الملكية الفكرية، الخصوصية، البحث الدفاعي، والترخيص. استخدمه كإطار للتفكير، لا كبديل عن نص قانوني محلي أو اتفاق مكتوب.
في قسم What is Reverse Engineering, and Why is it Important?، اقرأ التعريف والسياق. ثم اقرأ قسم The Ethical Dimensions of Reverse Engineering مع التركيز على الملكية الفكرية والخصوصية والغرض الدفاعي. بعد ذلك انتقل إلى قسم Navigating the Legal Murkiness of Reverse Engineering واقرأ سبب اختلاف الحكم، ثم في فقرة Software Licensing Agreements اقرأ أثر الترخيص.
1. الملكية الفكرية
قد يحمي حق المؤلف الشفرة أو التعبير البرمجي، وقد تحمي براءة اختراع جانبًا وظيفيًا أو تقنيًا، وقد تكون تفاصيل أخرى أسرارًا تجارية. لذلك:
- تحليل برنامجك الخاص أو عينة تعليمية مخصصة للهندسة العكسية هو المسار الأكثر أمانًا للتعلم.
- تحليل برنامج بغرض التوافق أو البحث الدفاعي قد يكون مسموحًا في سياقات قانونية معينة، لكنه ليس حقًا عالميًا.
- نسخ منطق برنامج تجاري أو إعادة توزيع شفرته المفككة أو استخدام التحليل لإنشاء نسخة منافسة مطابقة قد يثير مشكلات كبيرة.
- وجود آلية حماية أو ترخيص في برنامج تجاري هو إشارة قوية للتوقف ومراجعة الترخيص، وليس دعوة إلى تجاوزها.
2. العقد والترخيص
قد تتضمن اتفاقية المستخدم النهائي، أو شروط متجر التطبيقات، أو عقد العمل، أو اتفاقية عدم الإفصاح قيودًا على التفكيك أو إزالة الحماية أو النشر. لا تفترض أن شراء النسخة يحل هذه المسألة.
عمليًا، عند فتح برنامج خارج المختبر، ابحث عن:
- ملف الترخيص أو شروط الاستخدام.
- سياسة الإفصاح عن الثغرات أو برنامج المكافآت، إن كان هدفك أمنيًا.
- إذن مكتوب من الجهة المالكة.
- تعليمات المؤسسة التي تعمل لديها وسياسة التعامل مع عينات وبرامج العملاء.
3. الخصوصية وتقليل الضرر
أثناء تحليل تطبيق قد تمر بيانات شخصية أو رموز دخول أو ملفات إعدادات أو سجلات حساسة. التصرف المهني هو:
- اجمع أقل قدر من البيانات اللازمة لإثبات الملاحظة.
- لا تنسخ البيانات الشخصية أو تشاركها أو تضعها في تقرير عام.
- اعمل داخل بيئة معزولة عند تشغيل عينات غير موثوقة.
- لا تغيّر بيانات إنتاج أو تجرّب مدخلات قد تعطل خدمة دون إذن صريح.
- وثّق الأثر بدليل كافٍ، لا بأكبر قدر ممكن من الاستخراج.
في الدروس اللاحقة سنبني آلة افتراضية معزولة، لكن قاعدة اليوم تسبق المختبر: العزل يقلل الخطر التقني، ولا يحوّل نشاطًا غير مصرّح به إلى نشاط مصرح به.
أداة قرار عملية: بوابات التصريح الست
قبل فتح Ghidra أو x64dbg أو Cheat Engine، مرّر السيناريو عبر البوابات التالية. إذا فشلت بوابة واحدة، لا تبدأ التحليل؛ اجمع التوضيح أو غيّر الهدف إلى عينة تدريبية.
البوابة 1: ما الأصل الذي سأحلله؟
حدد الأصل بدقة: ملف محدد، تطبيق وإصدار محددان، جهاز تملكه المؤسسة، عنوان ضمن نطاق، أو عينة تدريبية.
عبارة مثل «لعبة على الإنترنت» أو «برنامج شركة» ليست تعريفًا كافيًا. يجب أن تستطيع كتابة اسم الأصل ومصدره وبيئته في سطر واحد.
البوابة 2: ما مصدر الإذن؟
رتّب مصادر الإذن، من الأقوى إلى الأضعف:
- أصل تملكه أنت وكتبته أو أنشأته بنفسك.
- عينة تدريبية منشورة بوضوح للتحليل، مثل Crackme تعليمي أو برنامج مختبري.
- تكليف مكتوب من مالك الأصل أو من جهة مخوّلة تمثله.
- سياسة إفصاح أو برنامج مكافآت يذكر الأصل والنشاط ضمن النطاق.
- افتراض شخصي، أو تصريح شفهي غير موثق، أو العثور على الملف على الإنترنت. هذا ليس أساسًا كافيًا.
حتى في بيئة العمل، لا يكفي أن تكون موظفًا في الشركة. قد تكون صلاحيتك تخص نظامًا أو بيئة بعينها، بينما يظل نظام آخر أو بيانات العملاء خارج نطاق عملك.
البوابة 3: هل الفعل المحدد داخل النطاق؟
لا تقل: «لدي تصريح للاختبار»؛ اكتب الفعل الذي ستنفذه:
- فتح الملف وتحليله ساكنًا.
- تشغيله في آلة افتراضية معزولة.
- إرفاق مصحح أخطاء به.
- تعديل نسخة تدريبية محلية.
- إرسال مدخلات إلى خدمة.
- جمع بيانات أو سجلات.
قد يسمح التفويض بالتحليل الساكن فقط، لكنه لا يسمح بالتشغيل. وقد يسمح بفحص واجهة ويب، لكنه يمنع الاختبارات التي تؤثر في التوافر أو البيانات. لا توسع النطاق لأنك وجدت شيئًا «مثيرًا للاهتمام».
البوابة 4: هل توجد قيود تعاقدية أو قانونية واضحة؟
تحقق من الترخيص، والعقد، وسياسة الإفصاح، ومتطلبات الموقع الجغرافي أو القطاع المنظم. عند ظهور منع واضح، أو عدم وضوح مؤثر، التصنيف الصحيح هو: توقف واطلب توضيحًا.
البوابة 5: هل يمكن تقليل الضرر؟
خطط لأقل طريقة تحقق هدفك:
- ابدأ بالتحليل الساكن بدل التشغيل عندما يكفي ذلك.
- استخدم بيانات تجريبية وحسابات اختبار.
- لا تجمع بيانات إضافية لمجرد توفرها.
- لا تعطل حماية أو خدمة أو ترخيص خارج بيئة تعليمية مصرح بها.
- لا تنشر ملفًا أو مفتاحًا أو تفاصيل تمكن آخرين من الإضرار بالنظام.
البوابة 6: هل يمكنك إثبات القرار لاحقًا؟
احفظ دليل التصريح والنطاق قبل البدء: رابط سياسة، رسالة تفويض، ملف ترخيص، وصف العينة، وتاريخ المراجعة. هذا مهم عند إعداد تقرير وظيفي أو محفظة أعمال؛ فالتقرير الجيد يوضح لماذا كان العمل مشروعًا بقدر ما يوضح النتيجة التقنية.
تصنيف سيناريوهات متكررة
استخدم التصنيفات التالية بحذر؛ فهي أمثلة للتفكير وليست بديلًا عن مراجعة المصدر الفعلي للتصريح.
| السيناريو | القرار الأولي | السبب والخطوة التالية |
|---|---|---|
| تحليل ملف PE كتبته أنت أو مشروعًا تدريبيًا بنيته بنفسك | مصرّح غالبًا | احتفظ بسجل أن الملف من إنشائك، واعمل في المختبر. |
| تحليل Crackme منشور صراحة للتعلم | مصرّح غالبًا | اقرأ وصف العينة وترخيصها؛ لا تفترض أن كل ملف باسم Crackme مصرح. |
| تعديل نقطة تحقق في برنامج تجاري مدفوع لتجاوز الترخيص | غير مصرّح | الغرض يتضمن تجاوز حماية وترخيص؛ استخدم Crackme تدريبيًا بدلًا منه. |
| فحص تطبيق عميل بعد تلقي رسالة تفويض تحدد التطبيق والبيئة والفترة | مصرّح بشروط | راجع الأصول والأنشطة المحظورة وطريقة الإبلاغ قبل العمل. |
| تجربة ثغرة على نطاق فرعي غير مذكور في برنامج مكافآت | غير مصرّح حاليًا | لا تختبره؛ اطلب إضافة الأصل إلى النطاق أو بلّغ عن الملاحظة دون توسيع الاختبار. |
| شراء لعبة ثم تحليل ذاكرتها لتعديل لعبة فردية محلية | يحتاج مراجعة | الملكية لا تكفي وحدها؛ راجع الترخيص وسياسة التعديل. لا تنتقل إلى ألعاب متعددة اللاعبين أو خدمات متصلة. |
| فتح عينة برمجية خبيثة من مصدر عام وتشغيلها على جهازك الحقيقي | غير مقبول عمليًا | حتى لو كان هدفك دفاعيًا، توجد مخاطر قانونية وتشغيلية كبيرة؛ استخدم فقط عينات ومحاكيات تعليمية مصرح بها وبيئة معزولة. |
| العثور عرضًا على بيانات حساسة أثناء اختبار مصرح به | مصرّح بالإبلاغ، لا بالتوسع | وثّق الحد الأدنى اللازم، لا تشارك البيانات، وأبلغ عبر القناة المحددة. |
لاحظ الفرق بين «مصرّح بشروط» و**«يحتاج مراجعة»**. الأول يعني أن لديك إذنًا واضحًا، ولكن يجب الالتزام بقيوده. أما الثاني فيعني أنك لا تملك معلومات كافية بعد، ولذلك لا تبدأ.
مختبر قصير: بطاقة تصريح قبل التحليل
خصص من 8 إلى 10 دقائق لإنشاء ملف نصي باسم authorization-note.md في مجلد الدورة. استخدم هذا القالب لكل عينة أو مشروع لاحق:
اسم المشروع:
الأصل المحدد:
المالك أو الجهة المخولة:
مصدر الإذن:
تاريخ مراجعة الإذن:
الغرض الدفاعي أو التعليمي:
الأعمال المسموح بها:
الأعمال الممنوعة:
حدود البيانات والخصوصية:
بيئة العمل:
قناة الإبلاغ أو التوثيق:
قرار البدء: مصرح / يحتاج توضيح / غير مصرح
سبب القرار:
للتدريب، املأ البطاقة لثلاث حالات فقط:
- ملف بسيط ستنشئه بنفسك لاحقًا أثناء الدورة.
- Crackme تعليمي له وصف أو ترخيص واضح.
- برنامج تجاري حقيقي ترغب في تحليله بهدف تجاوز الحماية.
في الحالة الثالثة، يجب أن تقودك البطاقة إلى قرار غير مصرح أو يحتاج توضيحًا، لا إلى بدء التحليل. هذه العادة تحميك وتبني نمطًا مهنيًا مهمًا عند التقدم لوظائف التحليل الأمني أو تحليل البرمجيات الخبيثة.
الخلاصة
قبل أي هندسة عكسية، افصل بين القدرة التقنية والتصريح. القرار السليم يتطلب:
- أصلًا محددًا ومالكًا أو جهة مخولة واضحة.
- إذنًا قابلًا للإثبات، لا افتراضًا.
- نطاقًا يحدد الأصول والأفعال والحدود.
- مراجعة للترخيص والخصوصية والالتزامات ذات الصلة.
- أقل أسلوب ممكن ضررًا، مع توثيق القرار.
العينات التعليمية، والبرامج التي أنشأتها بنفسك، والتفويضات المكتوبة ذات النطاق الواضح هي أساس المختبرات الآمنة في هذه الدورة. أما البرامج التجارية والحسابات والخدمات والألعاب المتصلة وعينات البرمجيات الخبيثة غير المنضبطة، فلا تُعامل كتدريب تلقائيًا.
في الدرس التالي ستنتقل من قرار «هل يحق لي التحليل؟» إلى التجهيز التقني: إنشاء آلة Windows افتراضية معزولة وحفظ Snapshot تستطيع العودة إليه قبل تشغيل أي عينة تدريبية.
Can't find a good explanation? Sign up and we'll make it for you
Sign up