[{"content":"مقدمة منذ الطفولة، يمتلك الإنسان فضولاً فطرياً لمعرفة \u0026ldquo;كيف تعمل الأشياء؟\u0026rdquo;. هذا الفضول هو ما يدفع الطفل لكسر لعبته المفضلة ليرى المحرك الصغير بداخلها. في عالم التكنولوجيا المتقدم، يتحول هذا الفضول إلى تخصص هندسي دقيق وحاسم يُعرف باسم الهندسة العكسية (Reverse Engineering).\nقد لا يكون أغلب مستخدمي الحاسوب قد سمعوا بالهندسة العكسية من قبل، ربما لأنها غير شائعة كثيراً بعكس ما هو الحال مع عالم الاختراق \u0026ldquo;الهاكينج\u0026rdquo;، أو ربما لأنهم يعرفونها بمصطلحها الآخر ألا وهو \u0026ldquo;الكراكينج\u0026rdquo; (Cracking).\nويختلف الكثيرون في تعريف الهندسة العكسية، لكن باختصار يمكننا القول:\nالهندسة العكسية: هي عملية تحليل شيء ما لفهم آلية عمله.\nوبالتالي تُقسم الهندسة العكسية إلى قسمين رئيسيين:\nهندسة عكسية للبرمجيات: Reverse Code Engineering (RCE) هندسة عكسية للعتاد (الهاردوير): Hardware Reverse Engineering (HRE) ونحن في هذه الورشة بصدد التحدث والتعمق في الـ RCE.\nما الحاجة إلى الهندسة العكسية أصلاً؟ يختلف هذا باختلاف المهندس العكسي وأهدافه:\n1. منظور المبرمج (المطور) إذا كنت أنت كاتب البرنامج، فغالباً ستود تنقيح برنامجك (Debugging) بغرض اكتشاف الأخطاء أو مسبباتها. وبعد اكتشاف الأخطاء وتصحيحها، قد ترغب في معرفة مدى قوة حماية البرنامج، أي مدى قابليته للكسر على أيدي الكراكرز (Crackers). فتقوم أنت في هذه الحالة، بهندسة برنامجك عكسياً بغرض حمايته من الكسر.\n2. منظور الكراكر (Cracker) تختلف دوافع الكراكرز إلى تعلم الهندسة العكسية حسب الأشخاص أو الفرق:\nالتحدي: اتخاذها كأداة لتحدي الحمايات وطرق التمويه. المعرفة للجميع: مشاركة الآخرين بما توصلوا إليه من تقنيات. كسر الاحتكار: إعانة المستخدمين للحصول على برامج باهظة الثمن. التخريب: اتخاذها كأداة للتخريب على خلفية مادية (ككسر برنامج شركة منافسة) أو أسباب أخرى. 🚁 لتبسيط المفهوم: سيناريو الطائرة المسيرة لا يوجد مثال أوضح من عالم الأسلحة لتبسيط هذا المفهوم المعقد.\nتخيل هذا السيناريو: سقطت طائرة استطلاع بدون طيار (Drone) متطورة جداً في أراضيك، وهي سليمة نسبياً. هذه الطائرة هي عبارة عن \u0026ldquo;صندوق أسود\u0026rdquo; (Blackbox) بالنسبة لك؛ أنت ترى النتيجة النهائية (طائرة تطير، تتجسس، وتتخفى)، لكنك لا تملك الخرائط الهندسية، أو كود البرمجيات الذي يدير محركاتها، أو نظام اتصالاتها المشفر.\nشكل (1): التعامل مع التكنولوجيا المجهولة كصندوق أسود.\nفي هذا السيناريو، الهدف من الهندسة العكسية ليس تدمير الطائرة، بل فهمها حتى تتمكن من:\nبناء أنظمة دفاعية مضادة لها. استنساخ التكنولوجيا لصالحك. إيجاد نقاط ضعف لتعطيلها مستقبلاً. ما هي الهندسة العكسية بشكل دقيق؟ الهندسة العكسية هي عملية تحليل نظام ما (ميكانيكي، إلكتروني، أو برمجي) لتحديد مكوناته والعلاقات فيما بينها، واستخدام هذا التحليل لإعادة إنشاء تمثيل للنظام يوضح كيفية عمله (مثل المخططات أو الكود المصدر).\nفي سياق البرمجيات (وهي الأكثر شيوعاً اليوم)، أنت تبدأ بملف تنفيذي جاهز للتشغيل (.exe أو ELF) ولا تملك الكود المصدر (Source Code) الذي كتبه المبرمجون (مثل C/C++). هدفك هو: تحويل هذا الملف الثنائي المعقد (Machine Code) إلى لغة يفهمها البشر لفهم آلية عمل الكود بشكل مفصل (Functionality).\n⚙️ مراحل الهندسة العكسية سواء كان الهدف سلاحاً ميكانيكياً كالبندقية، أو إلكترونياً كالبرمجيات الخبيثة، تمر العملية بأربع مراحل أساسية:\n1. الاستطلاع والملاحظة (Reconnaissance) قبل لمس أي شيء، يتم رصد سلوك الهدف:\nفي الأسلحة: كيف يتم تذخيرها؟ ما هو معدل إطلاق النار؟ ما نوع الذخيرة؟ في البرمجيات: يتم تشغيل البرنامج ومراقبة سلوكه (اتصالاته بالشبكة، الملفات التي ينشئها، وكيفية استهلاكه للذاكرة). 2. التفكيك (Disassembly) في الأسلحة: فك البندقية قطعة قطعة، مسماراً بمسمار، لفهم الآلية الميكانيكية للزناد وبيت النار. في البرمجيات: استخدام أدوات تسمى المُجمّعات (Disassemblers) لتحويل كود الآلة (0 و 1) إلى لغة التجميع (Assembly Language)، وهي لغة منخفضة المستوى تصف بدقة العمليات التي ينفذها المعالج. 3. التحليل والفهم (Analysis) هنا يبدأ العمل الذهني الشاق، حيث يتم ربط القطع المفككة ببعضها لفهم المنطق العام:\nفي الأسلحة: فهم أن الشكل المعين لقطعة التلقيم هو ما يسمح بالرماية الآلية. شكل (2): تحليل الميكانيكية للعتاد والأجزاء الصلبة.\nفي البرمجيات: محاولة تتبع مسار البيانات (Control Flow) داخل الأكواد للوصول إلى \u0026ldquo;الخوارزمية\u0026rdquo; الأساسية، مثل العثور على خوارزمية التشفير. شكل (3): تحليل تدفق الكود والمنطق البرمجي.\n4. إعادة البناء (Decompilation) الوصول إلى أعلى مستوى من الفهم، حيث يتم تحويل لغة التجميع إلى لغة برمجة عالية المستوى (مثل C) باستخدام المُفككات (Decompilers)، مما يسمح بفهم المنطق البرمجي بشكل أقرب للغة البشر.\nخاتمة الهندسة العكسية ليست مجرد معرفة بكيفية استخدام أدوات مثل الـ Disassemblers والـ Debuggers، بل هي عقلية (Mindset). إنها تتطلب صبراً هائلاً، وقدرة على حل الألغاز المعقدة، ومعرفة عميقة جداً بكيفية عمل أجهزة الكمبيوتر، وأنظمة التشغيل، والمعالجات.\nمن خلال فهم كيفية \u0026ldquo;تفكيك\u0026rdquo; التكنولوجيا، يكتسب المهندس العكسي القدرة على بناء تكنولوجيا أفضل وأكثر أماناً، تماماً مثلما يتعلم صانع الدروع دراسة \u0026ldquo;القذائف\u0026rdquo;.\n","permalink":"https://outofsrvc.github.io/ar/workshop/introduction-to-re/","summary":"\u003ch2 id=\"مقدمة\"\u003eمقدمة\u003c/h2\u003e\n\u003cp\u003eمنذ الطفولة، يمتلك الإنسان فضولاً فطرياً لمعرفة \u003cem\u003e\u0026ldquo;كيف تعمل الأشياء؟\u0026rdquo;\u003c/em\u003e. هذا الفضول هو ما يدفع الطفل لكسر لعبته المفضلة ليرى المحرك الصغير بداخلها. في عالم التكنولوجيا المتقدم، يتحول هذا الفضول إلى تخصص هندسي دقيق وحاسم يُعرف باسم الهندسة العكسية (Reverse Engineering).\u003c/p\u003e\n\u003cp\u003eقد لا يكون أغلب مستخدمي الحاسوب قد سمعوا بالهندسة العكسية من قبل، ربما لأنها غير شائعة كثيراً بعكس ما هو الحال مع عالم الاختراق \u0026ldquo;الهاكينج\u0026rdquo;، أو ربما لأنهم يعرفونها بمصطلحها الآخر ألا وهو \u0026ldquo;الكراكينج\u0026rdquo; (Cracking).\u003c/p\u003e","title":"Introduction to Reverse Engineering"},{"content":"بسم الله الرحمن الرحيم.\nفي هذا المقال سنتعرف على العلوم الأساسية التي يجب تعلمها للبدء في عالم الهندسة العكسية. لقد قمت باستخلاص هذه المعرفة من عدة مراجع عالمية، وصغتها في شروحات وسلاسل عربية نشرتها على \u0026ldquo;شبكة شل العربية\u0026rdquo;، وسأرفقها لكم هنا مع المراجع الأصلية في نهاية كل جزئية.\nبدايةً، لكل علم أساسيات لا يمكن التغاضي عنها، وتعلمها واجب لأنها ستكون نقطة الانطلاق في رحلة التمكين التي نسعى إليها بإذن الله.\nكُلُّ عِلْمٍ يَقُومُ عَلَى أَرْكَانٍ.. وَأَرْكَانُ عَصْرِنَا هِيَ تِلْكَ الَّتِي تَقْبَعُ تَحْتَ قَلْعَةِ الـ 0 والـ 1.\n1. البرمجة (Programming) لتكون مطوراً أو باحثاً في هذا المجال، يجب أن تمتلك خلفية قوية في البرمجة تمكنك من فهم كيفية سير الكود (Control Flow).\nوبما أننا في الهندسة العكسية سنتعامل مع البرمجيات كمستوى متوسط قريب من العتاد (Middle-Level)، يجب أن تكون لدينا خبرة بلغة C/C++، والتي تكلمت عنها في سلسلة مطولة وقمت بشرح أدق تفاصيلها.\n🔗 سلسلة البرمجة بلغة C على شبكة شل\nشكل (1): مقتطف من دروس البرمجة بلغة C.\n📚 المرجع الأساسي: C Programming Language (K\u0026amp;R) 2. معمارية الحاسب (Computer Architecture) بالتأكيد لا يمكننا أن نفكك أي شيء في الحياة دون أن نفهم تصميمه وكيفية عمله. كالميكانيكي الذي يعمل على صيانة السيارات، يجب أن يكون على علم كامل بكيفية تشغيل السيارة من لحظة التشغيل (Power-on) إلى لحظة الإيقاف (Power-off).\nولذلك قمت بإعداد سلسلة تشرح كيفية عمل الحاسب بشكل تفصيلي لتكوين هذا الفهم العميق.\n🔗 سلسلة معمارية الحاسب على شبكة شل\nشكل (2): مقتطف من دروس معمارية الحاسب.\n📚 المرجع الأساسي: Modern Computer Architecture and Organization 3. أنظمة التشغيل (OS Concepts) نظراً لتعاملنا المباشر مع البرمجيات، يجب أن نعلم كيف يتفاعل نظام التشغيل مع العمليات (Processes)، وكيفية تنظيمه لها، وما هو دور المعالج والذاكرة في ذلك. وقد أعددت سلسلة شرحت فيها أهم الأمور التي يتوجب علينا الإلمام بها في هذا الصدد.\n🔗 سلسلة مفاهيم أنظمة التشغيل على شبكة شل\nشكل (3): مقتطف من دروس أنظمة التشغيل.\n📚 المرجع الأساسي: Operating System Concepts 4. الشبكات (Networking) في ظل وجود الإنترنت، أصبح من المهم جداً أن ندرك ونعلم كيف تسير الأمور داخل الشبكات، وكيف تتواصل البرمجيات (خاصة الخبيثة منها) مع العالم الخارجي.\nهذه السلسلة الرائعة من إعداد أخي ومعلمي Storm.\n🔗 سلسلة أساسيات الشبكات على شبكة شل\nشكل (4): مقتطف من دروس الشبكات للأخ Storm.\n5. البرمجة منخفضة المستوى (Low-Level) أهم أمر في الهندسة العكسية هو تعلم وفهم أكواد التجميع (Assembly). لماذا؟ لأنه عند عكس أي برنامج، نحن نتعامل مع كود تنفيذي بلغة الآلة (Machine Code)، أي أنه يكون متمثلاً بالأصفار والواحدات (نظام ثنائي Binary System).\nولكن هذا الكود يمكننا تفكيكه (Disassemble) كي يظهر بلغة مقروءة وهي Assembly. ولذلك قمت بإعداد سلسلة متكاملة تخص لغة x86 Assembly.\n🔗 سلسلة لغة x86 Assembly على شبكة شل\nشكل (5): مقتطف من دروس لغة التجميع x86.\n📚 المرجع الأساسي: Assembly Language for x86 Processors خاتمة لأكون صادقاً معك، بعد الانتهاء من دراسة هذه الأمور، لن أقول لك أنك ستكون قد بنيت أساساً قوياً بنسبة 100%.\nالعلم بحر واسع، وكلما شربنا منه لا نرتوي. ولكن، إن شاء الله، بإنهاء هذه السلاسل ستكون قد أتممت 90% من المعرفة التأسيسية التي تتوجب عليك للبدء بقوة في هذا المجال.\n","permalink":"https://outofsrvc.github.io/ar/workshop/fundamentals-of-re/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eفي هذا المقال سنتعرف على العلوم الأساسية التي يجب تعلمها للبدء في عالم الهندسة العكسية. لقد قمت باستخلاص هذه المعرفة من عدة مراجع عالمية، وصغتها في شروحات وسلاسل عربية نشرتها على \u0026ldquo;شبكة شل العربية\u0026rdquo;، وسأرفقها لكم هنا مع المراجع الأصلية في نهاية كل جزئية.\u003c/p\u003e\n\u003cp\u003eبدايةً، لكل علم أساسيات لا يمكن التغاضي عنها، وتعلمها واجب لأنها ستكون نقطة الانطلاق في رحلة التمكين التي نسعى إليها بإذن الله.\u003c/p\u003e","title":"Fundamentals of Reverse Engineering"},{"content":"بسم الله الرحمن الرحيم.\nهل تساءلت سابقاً كيف تعمل البرامج داخل الأنظمة؟ أو هل خطرت لك فكرة: ما الفرق بين المستخدم العادي والمطور من حيث فهمه للأنظمة التي يتعامل معها؟\nبإذن الله في هذا المقال سنوضح تنسيق الملفات التنفيذية في ويندوز ونتكلم عن بعض الأمور الهامة التي لا يجب أن نجهلها في معمارية نظام ويندوز.\nقبل البدء، إن لم يكن لديك علم كافي بأنظمة التشغيل أنصحك بمراجعة السلسلة التالية: 🔗 سلسلة أنظمة التشغيل على شبكة شل\nتنسيق الملفات (PE file format) تنسيق ملفات PE (Portable Executable) هو التنسيق الأصلي لملفات win32 مثل (dll, exe). يعتبر فهم هذا التنسيق حجر أساس لتحليل ملفات أنظمة Windows.\nيشتق تنسيق PE بعض مواصفاته من Unix COFF (Common Object File Format)، وهو أحد تنسيقات ملفات الكائنات (object files) الذي خلفه لاحقاً تنسيق ELF (Executable and Linkable Format).\nشو يعني Portable Executable؟ يعني أن التنسيق شامل ومنتشر على منصة win32 بحيث يتعرف عليه محمل الملفات (PE Loader) بأي منصة تعمل بنظام win32 بغض النظر عن نوع المعالج.\nما هي هيكلية هذا التنسيق؟ هذا التنسيق يُعرف بشكل أساسي من PE Header: هو المكون الأساسي الذي يعرّف ملفات PE بشكل جوهري. يتكون من عدة طبقات متتالية تؤدي وظائف محددة لضمان تحميل الملف وتشغيله بشكل صحيح في بيئة windows.\nيتكون PE Header من عدة أجزاء تحدد هويته وسلوكه:\n1. رأس الدوس (Dos Header) هو أول 64 بايت من الملف وبيحتوي على المعلومات اللازمة لمعرفة أن هذا الملف بتنسيق PE:\ne_magic: الرقم السحري \u0026ldquo;magic number\u0026rdquo; الذي يشير إلى الحرفين MZ أو 4d 5a بالهيكس.. نسبة للمهندس \u0026ldquo;Mark Zbikowski\u0026rdquo; وهما اللذان يحددان أن الملف بتنسيق PE. شكل (1): الرقم السحري.\ne_lfanew: يقع عند الإزاحة 0x3c جوا الـ DOS Header وهو عبارة عن عنوان يشير إلى مكان بدأ PE Header (الـ NT Header الجديد). 2. بقايا الدوس (DOS Stub) عبارة عن بقايا للـ DOS Header يأتي بعد الـ 64 بايت الأولى لرأس الـ DOS وهو منطقة ذاكرة تكون غالباً مليئة بالأصفار أو تحتوي على رسالة خطأ بسيطة تشير إلى أن هذا البرنامج لا يمكن تشغيله في وضع DOS (إلي كانت معماريتها 16-bit).\nشكل (2): صورة توضح شكل الـ DOS Stub.\n3. رأس النظام (NT Header / PE Header) يتم تعريفه برمجياً كـ بنية IMAGE_NT_HEADER.\nشكل (3): صورة توضح برمجة البنية.\nويتكون من ثلاثة أجزاء:\nالتوقيع (signature): يتكون من البايتات السحرية PE\\0\\0 أو بالهيكس 50 45 00 00 للتعريف بتنسيق الملف. شكل (4): صورة توضح التوقيع.\nرأس الملف (File Header أو COFF Header): يصف الخصائص الأساسية للملف مثل: Machine: نوع المعالج. NumberOfSections: عدد الأقسام الموجودة في الملف. Characteristics: سمات الملف (مثل هل هو Exe أو DLL). شكل (5): صورة توضح رأس الملف.\nالرأس الاختياري (Optional Header): على الرغم من تسميته إلا أنه إلزامي لملفات PE ويحتوي على متغيرات بالغة الأهمية: AddressOfEntryPoint: نقطة دخول البرنامج. ImageBase: العنوان المفضل لتحميل الملف في الذاكرة. DataDirectory: قائمة مكونة من 16 عنصر بتشير إلى جداول هامة مثل جدول التصدير \u0026ldquo;export table\u0026rdquo; والاستيراد \u0026ldquo;import table\u0026rdquo;. شكل (6): صورة توضح الرأس الاختياري.\n4. جدول الأقسام (Section Table / Headers) مثل الخريطة توضح كيفية تقسيم البيانات وتوزيعها في الذاكرة، يأتي هذا الجدول مباشرة بعد الـ Headers وقبل البيانات الفعلية للأقسام. يتكون جدول الأقسام من مصفوفة تسمى IMAGE_SECTION_HEADER حيث أن كل عنصر في هذه المصفوفة يصف قسم معين بالملف. وتبلغ مساحة كل عنصر في هذا الجدول 0x28 بايت.\nويحتوي كل إدخال بالجدول على تفاصيل مهمة:\nName: اسم القسم (مثل .text او .data). VirtualSize: الحجم الفعلي للقسم عند تحميله بالذاكرة. VirtualAddress: العنوان الذي سيتم وضع القسم فيه في الذاكرة الافتراضية. SizeOfRawData: حجم القرص على الهارد ديسك. Characteristics: سمات القسم (مثل قابل للقراءة أو الكتابة أو التنفيذ). 5. الأقسام (Sections) بتجي بعد الـ section table. ما هي هذه الأقسام؟\n.text: بيحتوي على كود البرنامج القابل للتنفيذ. .rdata: بيحتوي على البيانات القابلة للقراءة فقط (مثل Strings و Constants). أحياناً يتم تقسيم الـ rdata إلى قسمين وغالباً نرى ذلك في ملفات الـ DLL: .idata: ويكون للـ imports directory. .edata: ويكون للـ exports directory وهذا قسم مهم في ملفات dll لربط Functions المصدر بأسماء أو أرقام تعريفية. .data: بيحتوي على البيانات والمتغيرات التي تم تهيئتها. .rsrc: بيحتوي على الموارد كالصور والأيقونات الخاصة بالبرنامج. شكل (7): صورة توضح الأقسام.\nما هو الفرق بين ملفات Exe vs DLL؟ ملفات Exe: تتطلب وجود دالة تسمى Main يقوم الـ OS Loader باستدعاء هذه الدالة عندما تكون العملية الجديدة جاهزة. وهذه الملفات تعمل بشكل مستقل؛ حيث يقوم النظام بإنشاء عملية جديدة ومساحة افتراضية مخصصة لها. ملفات DLL: غالباً تحتوي على دالة تسمى DllMain يتم تنفيذ الكود بشكل مباشر بمجرد تحميل مكتبة dll المناسبة في الذاكرة. ولا يمكنها العمل بشكل مستقل بل يجب تحميلها داخل مساحة افتراضية لعنوان موجود مسبقاً. لماذا؟ لأن العملية قد تحتاج إلى functions توفرها ه‍ذه المكتبة. أي باختصار: بينما يمثل ملف exe البرنامج الذي يبدأ العملية، يمثل ملف الـ dll المكتبة التي تمد هذه العملية بالدوال.\nمعمارية نظام ويندوز (Windows Internals) ونعود لنتساءل ما الذي يميز المطور في الأنظمة عن المستخدم؟ ببساطة معرفة أمور النظام الداخلية التي لا تهم المستخدم العادي التي يطلق عليها Windows Internals.\nالـ windows internals هي عبارة عن الـ Concepts الي لازم تكون بتعرف تتعامل معها بنظام ويندوز، أي حدا رح يتعلم موضوع low-level أو يبرمج شي low-level لازم يكون عنده خبرة بهي النقاط:\n1. العمليات (Processes) بتعني أي برنامج هو قيد التنفيذ. العمليات الها ستراكشر بالـكيرنال اسمو KProcess (والتي يُطلق عليها بالمصطلح العام Process Control Block - PCB) الـكيرنال بيستخدموا مشان يتحكم بالـ operations تبع هي البروسيس.\nبالـميموري الوضع مختلف، بيكون في شي اسمه EProcess structure وهو غير الـ KProcess; الـ EProcess بتحتوي ع كتير معلومات أهمها:\nProcess id: رقم العملية. exe name: اسم ملف التنفيذ المرتبطة فيه هي العملية. dll files: ملفات الـ dll المرتبطين بهي العملية. PCB: ستراكشر الـكيرنال المرتبط بهي العملية. شكل (8): صورة توضح ارتباط العمليات ببعضهم البعض.\nهدول الـ EProcesses موجودين بالـ kernel memory على شكل double-linked يعني كل بروسيس الها forward link و back link. وطبعاً في كتير برامج بتوصل لهي الـ EProcess متل Process Explorer.\nشكل (9): صورة توضح عرض من داخل البرنامج.\n2. الخيوط (Threads) باختصار هي الشي الي ويندوز بيقوم بتنفيذو. أما بالنسبة للـ Process: هي بتحتوي بداخلها threads. البروسيس ما هي الي بتشغل الكود بل لازم تحتوي على الأقل على one thread ليشغل الكود على المعالج، بس ما بيمشي الحال انو الثريد تشتغل لحالها إذا ما كانت موجودة داخل بروسيس.\nالثريد الها 3 حالات ممكن تكون فيها:\nRunning: يعني شغالة أو قيد التنفيذ. Ready: جاهزة منتظرة البروسيسور ليشغلها. Blocked/Suspended: توقفت أو انحظرت خلينا نقول جراء مقاطعة (interrupt). شكل (10): صورة توضح حالات الخيوط.\nبما أن البروسيس ممكن تحتوي على أكتر من thread. هل بيكونوا معزولين عن بعض؟ لا هني بيعملوا shared للميموري يعني الـ threads بيتشاركوا الـ resources والـ address spaces (متل .data section و .code section). بس بيضل لكل thread الها stack و registers خاصين فيها.\nشكل (11): صورة توضح مشاركة الذاكرة بين الخيوط.\n3. الذاكرة الافتراضية (virtual memory / virtual address space) أي exe.file رح نشغلو رح يكون اله بروسيس وهي البروسيس الها address space خاص فيها. الـ address space بياخد range من 00000000 إلى ffffffff وبيقسم هاد الرنج لقسمين كل قسم 2Gb: قسم للـ user mode وقسم للـ kernel mode.\nشكل (12): صورة توضح المقارنة بين الجزء المادي والافتراضي من الذاكرة.\nالـ user mode الرانج تبعو: من 00000000 إلى 7fffffff والـ kernel mode: من 80000000 إلى ffffffff (مع العلم أن هاد الكلام بنظام الـ 32bit). 4. العناوين الافتراضية والفيزيائية (virtual address VS physical address) كل برنامج اله بروسيس وكل بروسيس الها ذاكرة افتراضية. ومتل ما منعرف انو كل exe file اله section بالذاكرة. فـ لو عنا تطبيقين حطو .text و .data بعناوين عشوائية وشاء القدر انو تتشابه عناوين الـ .data، هل معنى هاد الشي انو رح يكون قسم الـ .data متشارك؟\nلا، لأن الـ addresses الأساسية للبرامج موجودة بالرام الي هي الـ physical memory، والـ addresses الي عم نتعامل معها حالياً هي افتراضية virtually. فـ لما البروسيس يصير بدا تقرا داتا بصير شي اسمو virtual-to-physical نظام التشغيل بيعمل handle للموضوع وبيوصل كل section بـ address معين بالـ RAM.\nلازم نعرف: الـ virtual address ما بتمثل موقع فعلي بالـرام؛ فـ بدل هالشي النظام بيحتفظ بـ pages لكل process (حتى يتم ترجمة العناوين الـ virtual لعناوين physical). وبنفس الوقت هاد الحكي مطبق على الثريدز وهي العملية اسمها virtual-to-physical translation.\nبـ ويندوز عملوا حركة مشان ما كل بروسيس تحمل مقاطع خاصة الها من الرام. فعملوا ملفات بلواحق dll لهيك أي عملية لازم تعمل load لـ ntdll.dll و kernel32.dll وهدول عبارة عن مكاتب أو بالأصح (dynamic link library) يعني مكاتب ربط بيتم فيهن ربط أكتر من بروسيس الهن نفس الـ address. وأول بروسيس بتعمل mapping أو تقسيم لهي الـ dll بعناوين مشتركة بين كل الـ processes.\n5. التزامن (Synchronization) باختصار بيمنع انو يحصل simultaneous access (يعني كذا برنامج أو ثريد يستعملوا نفس الـملف أو نفس الـميموري بنفس الوقت). فـ عملوا شي اسمه mutex أو كمان بينقال له lock: هو عبارة عن object منستعملوا بالبرمجة عموماً بيمنع حصول simultaneous access.\nمثال يوضح الأمور شوي: لو عنا عمليتين مختلفتين وعلى فرض بدهم يعملوا write بالميموري بنفس الوقت شو بصير ؟ تخيل الميموري مسؤول عنها police officer، هاد الضابط ما بيخلي حدا يفوت يعمل write إلا ليكون معه الـ mutex. يعني بتجي عملية معها الـ mutex object بتكتب بالميموري وبتترك الـ mutex، بتجي العملية التانية بتاخد هاد الـ mutex وبتكتب بالميموري.\n6. الخدمات (Services) الـسيرفس بتسمحلنا نشغل long running executable apps. رح تضل شغالة بالـ background بتشتغل بـ session خاصة بالويندوز اسم الـ session هو svchost.exe (وهو عبارة عن host للـ services، هي الـسيرفايسس بتكون مجدولة وبينعملها run من windows service manager بدون تدخل اليوزر فيها).\n7. الريجستري (Registry) عبارة عن database بيتخزن فيها إعدادات نظام ويندوز والبرامج المتواجدة فيه. الـ registry بتحتوي على عنصرين أساسيين:\nKeys: هو عبارة عن الـ folders. Values: عبارة عن الـ files. بالـ registry في شي اسمه root keys أو HKEYs وهدول أهم المسارات الي منتعامل معهم:\nHKEY_CURRENT_USER HKEY_LOCAL_MACHINE HKEY_USERS HKEY_CLASSES_ROOT طيب شو الشغلات المهمة الموجودة بالريجستري ؟\nقائمة البرامج والـسيرفايسس المنزلة على الـسيستم. الإعدادات تبع البرامج والـسيرفايسس. البرامج الي بتشتغل auto run after boot. الـ file associations (يعني اليوزر إذا بدو يفتح صفحة .html بيفتحها على chrome أو firefox مثلاً). منشوف الـ history تبع الـ usb devices والـ network adapter settings. الملف الي بيكون فيه الـ functions تبع الريجستري اسمه advapi32.dll وكل الدوال الي الها علاقة بالريجستري بتبدأ بـ Reg. 8. ثوابت البرمجة في ويندوز (windows coding conventions) بعض الثوابت بالـ Windows API، هي الثوابت بتسهل عليك قراءة الـ docs تبع مايكروسوفت أو توقع مثلاً شو بتعمل بعض function من اسمها. windows data types:\nByte -\u0026gt; 1Byte Word -\u0026gt; 2Bytes DWord -\u0026gt; 4Bytes QWord -\u0026gt; 8Bytes مايكروسوفت بتعتمد على الـ prefix naming بالتسمية \u0026ldquo;prefix يعني القبلية\u0026rdquo; بتعرفنا انو مثلاً شو نوع الداتا تايب تبع متغير أو هيكلية معينة. وكل function فينا نستعلم عنها بـ MSDN - MicroSoft Developer Network وبآخر كل دالة منلاقي ملف الـ dll المتواجدة فيه هي الدالة.\n9. المقابض (Handles) الـ هاندل متل الـ بوينتر تقريباً\u0026hellip; الفرق انو البوينتر ممكن نعمل عليه عمليات رياضية بس الـ هاندل ما منقدر (يعني بس مناخد هاد المقبض ومنخزنه ومنستعمله متل ما هو بوقت لاحق).\nعلى سبيل المثال: بدنا نعمل call لـ func اسمها CreateWindowEx، هي الـدالة بس انعملها Call بتعمل Create لـ window وبترجع handle لهي الويندو. ولو بدي أعمل أي عملية على هي الويندو متل مثلاً ضيف أو أتحكم بـ زر أو أي شي لازم أعمل reference لهي الويندو عن طريق الـ handle.\n10. دوال الشبكات (Network Functions in the API) مايكروسوفت بتوفر 2 API للـ Networking:\nlow-level API: هاد بيتعامل مع الـ sockets اسمه winsock. الـ socket عبارة عن handle بالـ endpoint للـ network communications. مثال: في لعبة الأكواب الي بيتواصلوا فيها: شكل (13): صورة توضح مبدأ المرسل والمستقبل.\nكل كوب هو عبارة عن سوكيت؛ كوب للسماع وكوب للكلام. فالسوكيت منعاملها كـ file: منقدر نعمل فيه write or read.\nhigh-level API: اسمه wininet بيسمح للمبرمجين انهم يستعملوا بروتوكولات الـ high-level متل http, ftp. طبعاً هي المكتبة بتكون مواكبة للـ standards الخاصة بالبروتوكولات.. متل http، وفي كتير ملفات dll خاصة بال high-level متل: winhttp.dll, dnsapi.dll, urlmon.dll. 11. واجهة برمجة التطبيقات الأصلية (the native api) لما منعمل Call لـ function من الـ win32api الـ function هي ما بتعمل الشي الي نحنا طلبناه مباشرة. بل بتحتاج تتواصل مع الـكيرنال مشان تقدر توصل للهاردوير. فالـ userapps بتستعمل win32api من ملفات متل kernel32.dll وهي الملفات بتعمل Call لملف اسمو ntdll.dll: هو المسؤول عن الـ interactions بين الـ user mode والـ kernel mode.\nالـ native api بتخلي الـ apps يتواصلوا مباشرة مع الـ ntdll.dll.\nالمراجع Practical Malware Analysis Windows Internals Malware Development for Ethical Hackers ","permalink":"https://outofsrvc.github.io/ar/workshop/windows-architecture-and-pe/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eهل تساءلت سابقاً كيف تعمل البرامج داخل الأنظمة؟ أو هل خطرت لك فكرة: ما الفرق بين المستخدم العادي والمطور من حيث فهمه للأنظمة التي يتعامل معها؟\u003c/p\u003e\n\u003cp\u003eبإذن الله في هذا المقال سنوضح تنسيق الملفات التنفيذية في ويندوز ونتكلم عن بعض الأمور الهامة التي لا يجب أن نجهلها في معمارية نظام ويندوز.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eقبل البدء، إن لم يكن لديك علم كافي بأنظمة التشغيل أنصحك بمراجعة السلسلة التالية:\n🔗 \u003ca href=\"https://sh3ll.cloud/xf2/threads/4230/\"\u003eسلسلة أنظمة التشغيل على شبكة شل\u003c/a\u003e\u003c/p\u003e","title":"Windows Architecture \u0026 PE Format"},{"content":"بسم الله الرحمن الرحيم.\nدائماً في بداية رحلة أي شخص عند التعامل مع لغة Assembly، يشعر بصعوبة كونها لغة Low-Level على عكس اللغات الأخرى كـ C أو Python. سنحاول في هذا المقال تبسيط أكواد الأسمبلي لكي نتمكن من فهمها بشكل أكبر إن شاء الله.\nفكرة المقال هي أننا سنكتب كوداً بسيطاً بلغة C ونقوم بعمل Compile له ليصبح x86 Assembly، ثم نشرح الخطوات التي تحدث لنتمكن من تحليل الـ Control Flow.\nقبل البدء، إن لم يكن لديك علم كافي بـ لغة C و Assembly أنصحك بمراجعة السلاسل التالية: 🔗 سلسلة لغة C على شبكة شل 🔗 سلسلة لفة Asm على شبكة شل\n1. Global vs Local Variables Global Variables بداية نقوم بكتابة هذا الكود البسيط بلغة C:\nint x = 1; int y = 2; void main() { x = x + y; printf(\u0026#34;Total = %d\\n\u0026#34;, x); } ونقوم بعمل compile بالأمر التالي:\ngcc -S -masm=intel -m32 -O0 filename.c -o filename.s وعندما نقوم بفتح الملف الذي لاحقته .s يظهر التالي:\nx86 Assembly:\n00401003 mov eax, dword_40CF60 00401008 add eax, dword_40C000 0040100E mov dword_40CF60, eax ; [1] تخزين النتيجة 00401013 mov ecx, dword_40CF60 00401019 push ecx 0040101A push offset aTotalD ; \u0026#34;total = %d\\n\u0026#34; 0040101F call printf الـ global variables في الأسمبلي تكون عبارة عن عناوين ذاكرة (Memory Addresses) مثل: dword_40CF60.\nLocal Variables بالنسبة للـ Local Variables، فتكون عبارة عن إزاحة (Offset) معين عن الـ ebp أو الـ esp أو أي ريجستر آخر (مثل: dword ptr [ebp-4]). عندما نقوم باستخدام disassembler مثل IDA Pro (والذي سنشرحه بالتفصيل في قادم المقالات بإذن الله)، ستظهر المتغيرات المحلية بوضوح.\nvoid main() { int x = 1; int y = 2; x = x+y; printf(\u0026#34;Total = %d\\n\u0026#34;, x); } x86 Assembly:\n00401006 mov dword ptr [ebp-4], 1 ; [1] 0040100D mov dword ptr [ebp-8], 2 ; [2] 00401014 mov eax, [ebp-4] 00401017 add eax, [ebp-8] 0040101A mov [ebp-4], eax 0040101D mov ecx, [ebp-4] 00401020 push ecx 00401021 push offset aTotalD ; \u0026#34;Total = %d\\n\u0026#34; 00401026 call printf عندما نقوم باستخدام disassembler كـ ida والي بقادم المقالات رح نشرح عنه باذن الله هيك بيظهر الـ local variables.\n00401006 mov [ebp+var_4], 1 ; [1] 0040100D mov [ebp+var_8], 2 ; [2] 00401014 mov eax, [ebp+var_4] 00401017 add eax, [ebp+var_8] 0040101A mov [ebp+var_4], eax 0040101D mov ecx, [ebp+var_4] 00401020 push ecx 00401021 push offset aTotalD ; \u0026#34;Total = %d\\n\u0026#34; 00401026 call printf 2. If Statement int x = 1; int y = 2; if(x == y) { printf(\u0026#34;x equals y.\\n\u0026#34;); } else { printf(\u0026#34;x is not equal to y.\\n\u0026#34;); } x86 Assembly:\n00401006 mov [ebp+var_8], 1 0040100D mov [ebp+var_4], 2 00401014 mov eax, [ebp+var_8] 00401017 cmp eax, [ebp+var_4] ; [1] تعليمة المقارنة 0040101A jnz short loc_40102B ; [2] قفز مشروط إلى else 0040101C push offset aXEqualsY_ ; \u0026#34;x equals y.\\n\u0026#34; 00401021 call printf 00401026 add esp, 4 00401029 jmp short loc_401038 ; [3] قفز غير مشروط لتخطي else 0040102B loc_40102B: ; قسم else 0040102B push offset aXIsNotEqualToY ; \u0026#34;x is not equal to y.\\n\u0026#34; 00401030 call printf أول شيء سنواجهه هو تعليمة CMP، تليها قفزة مشروطة (jnz). إذا تحقق شرط القفزة المشروطة، ينتقل التنفيذ إلى كتلة else. أما إذا لم يتحقق، فيستمر الكود في المسار الطبيعي (fall-through) وهو كتلة if الأساسية، ثم ينفذ قفزة غير مشروطة لتجاوز كتلة else.\n3. For Loop int i; for(i = 0; i \u0026lt; 100; i++) { printf(\u0026#34;i equals %d\\n\u0026#34;, i); } x86 Assembly:\n00401004 mov [ebp+var_4], 0 ; [1] التهيئة (i=0) 0040100B jmp short loc_401016 ; [2] قفز للمقارنة 0040100D loc_40100D: ; منطقة التحديث (Update) 0040100D mov eax, [ebp+var_4] ; [3] 00401010 add eax, 1 ; زيادة العداد 00401013 mov [ebp+var_4], eax ; [4] 00401016 loc_401016: ; منطقة المقارنة (Condition) 00401016 cmp [ebp+var_4], 64h ; [5] 64h = 100 0040101A jge short loc_40102F ; [6] قفز مشروط للخروج من الحلقة 0040101C mov ecx, [ebp+var_4] ; محتوى الحلقة 0040101F push ecx 00401020 push offset aID ; \u0026#34;i equals %d\\n\u0026#34; 00401025 call printf 0040102A add esp, 8 0040102D jmp short loc_40100D ; [7] العودة للتحديث يتم التهيئة بمتغير محلي داخل الـ for. نرى قفزاً غير مشروط يأخذنا للمقارنة CMP. بعدها قفز مشروط للخروج. إذا لم يتم الخروج، تُنفذ التعليمات داخل الـ for. في النهاية، قفز غير مشروط يأخذنا لمكان التحديث (increment أو decrement). تتكرر العملية حتى يتحقق شرط الخروج. شكل (1): مقتطف من برنامج IDA Pro.\n4. While Loop int status = 0; int result = 0; while(status == 0) { result = performAction(); status = checkResult(result); } x86 Assembly:\n00401036 mov [ebp+var_4], 0 0040103D mov [ebp+var_8], 0 00401044 loc_401044: ; بداية الحلقة 00401044 cmp [ebp+var_4], 0 ; المقارنة 00401048 jnz short loc_401063 ; [1] قفز مشروط للخروج 0040104A call performAction 0040104F mov [ebp+var_8], eax 00401052 mov eax, [ebp+var_8] 00401055 push eax 00401056 call checkResult 0040105B add esp, 4 0040105E mov [ebp+var_4], eax ; تحديث الحالة 00401061 jmp short loc_401044 ; [2] العودة لبداية الحلقة شبيهاً بالـ for ولكن أسهل بعض الشيء. البداية تكون بمقارنة CMP يليها قفز مشروط للخروج من الـ while. إذا لم ينفذ القفز، يُنفذ الكود داخل الحلقة، وفي نهايته قفز غير مشروط لإعادة الدورة. وهكذا حتى يتحقق شرط الـ CMP ويقفز خارجها وينتهي الـ loop.\n5. Switch Statement ممكن أن يتم تجميع الـ Switch بطريقتين بناءً على المجمع (Compiler):\nالطريقة الأولى: If Style تكون مشابهة تقريباً للـ if المتسلسلة. نرى عدد مقارنات مساوٍ لعدد الحالات، وبعد كل مقارنة قفز مشروط لتنفيذ الأمر. وفي النهاية قفز غير مشروط للـ default.\nswitch(i) { case 1: printf(\u0026#34;i = %d\u0026#34;, i+1); break; case 2: printf(\u0026#34;i = %d\u0026#34;, i+2); break; case 3: printf(\u0026#34;i = %d\u0026#34;, i+3); break; default: break; } x86 Assembly:\n00401013 cmp [ebp+var_8], 1 00401017 jz short loc_401027 ; [1] Case 1 00401019 cmp [ebp+var_8], 2 0040101D jz short loc_40103D ; Case 2 0040101F cmp [ebp+var_8], 3 00401023 jz short loc_401053 ; Case 3 00401025 jmp short loc_401067 ; [2] Default 00401027 loc_401027: ; تنفيذ Case 1 00401027 mov ecx, [ebp+var_4] ; [3] 0040102A add ecx, 1 ; ... (بقية التعليمات) ... شكل (2): مقتطف من برنامج IDA Pro.\nالطريقة الثانية: Jump Table switch(i) { case 1: printf(\u0026#34;i = %d\u0026#34;, i+1); break; case 2: printf(\u0026#34;i = %d\u0026#34;, i+2); break; case 3: printf(\u0026#34;i = %d\u0026#34;, i+3); break; case 4: printf(\u0026#34;i = %d\u0026#34;, i+3); break; default: break; } x86 Assembly:\n00401016 sub ecx, 1 ; طرح 1 لأن الكومبايلر يبدأ من 0 00401019 mov [ebp+var_8], ecx 0040101C cmp [ebp+var_8], 3 ; مقارنة بالحد الأقصى 00401020 ja short loc_401082 ; إذا تجاوز الحد، اذهب للـ default 00401022 mov edx, [ebp+var_8] 00401025 jmp ds:off_401088[edx*4] ; [1] القفز المباشر عبر الجدول ; --- العناوين المستهدفة --- 0040102C loc_40102C: ; ... 00401042 loc_401042: ; ... 00401082 loc_401082: ; النهاية (Default/Exit) 00401082 xor eax, eax 00401087 retn ; --- جدول القفز --- 00401088 off_401088: ; [2] 00401088 dd offset loc_40102C 0040108C dd offset loc_401042 00401090 dd offset loc_401058 00401094 dd offset loc_40106E طريقة جدول القفز تعتمد على طرح قيمة للحصول على index يبدأ من الصفر، ثم مقارنة مع عدد الحالات (cases)، وإذا كان ضمن النطاق يتم القفز مباشرة باستخدام الجدول بناءً على المعادلة [edx*4]. واذا لم يكن ضمن النطاق ينفذ فورا الـ default.\nشكل (3): مقتطف من برنامج IDA Pro.\n6. Arrays int b[5] = {123, 87, 487, 7, 978}; void main() { int i; int a[5]; for(i = 0; i \u0026lt; 5; i++) { a[i] = i; b[i] = i; } } x86 Assembly:\n00401021 mov edx, [ebp+var_18] 00401024 mov [ebp+ecx*4+var_14], edx ; [1] Local Array 00401028 mov eax, [ebp+var_18] 0040102B mov ecx, [ebp+var_18] 0040102E mov dword_40A000[ecx*4], eax ; [2] Global Array الـ Memory Address الخاص بالمصفوفة يعتمد على تعريفها (Global أم Local). ويرافقها دائماً Register يعمل كـ Index مضروب بحجم عناصرها. (مثلاً: مصفوفة Integers يكون الـ Index مضروباً بـ 4 [ecx * 4]). مع الانتباه إلى أن فهارس المصفوفة (index) تبدأ من 0، أي أن العنصر الأخير يقع عند الفهرس n-1.\n7. Structs \u0026amp; Linked Lists Struct struct my_structure { ; [1] int x[5]; char y; double z; }; struct my_structure *gms; ; [2] void main() { gms = (struct my_structure *) malloc(sizeof(struct my_structure)); test(gms); } x86 Assembly:\n00401053 push 20h ; حجم الـ Struct (32 bytes) 00401055 call malloc 0040105A add esp, 4 0040105D mov dword_40EA30, eax ; تخزين العنوان الأساسي 00401062 mov eax, dword_40EA30 00401067 push eax ; [1] تمرير المؤشر للدالة 00401068 call sub_401000 يتم تعريف الـ struct كـ متغير ويتم إضافة القيم الي جواه على حسب المتغيرات التي يحتويها وحسب استدعاء الدالة. عند تعريف الـ struct وحجز مساحة له بـ malloc، يعطينا العنوان الأساسي (Base Address) الذي هو بداية الـ struct.\nLinked List struct node { int x; struct node * next; }; typedef struct node pnode; void main() { pnode * curr, * head; int i; head = NULL; for(i=1; i\u0026lt;=10; i++) { ; [1] بناء الـ Nodes curr = (pnode *)malloc(sizeof(pnode)); curr-\u0026gt;x = i; curr-\u0026gt;next = head; head = curr; } curr = head; while(curr) { ; [2] التنقل بين الـ Nodes printf(\u0026#34;%d\\n\u0026#34;, curr-\u0026gt;x); curr = curr-\u0026gt;next; } } x86 Assembly:\n0040107E mov [esp+18h+var_18], 8 ; حجم الـ Node 00401085 call malloc 0040108A mov [ebp+var_4], eax ; eax يحمل عنوان الـ Node الجديد 0040108D mov edx, [ebp+var_4] 00401090 mov eax, [ebp+var_C] 00401093 mov [edx], eax ; [1] curr-\u0026gt;x = i 00401095 mov edx, [ebp+var_4] 00401098 mov eax, [ebp+var_8] 0040109B mov [edx+4], eax ; [2] curr-\u0026gt;next = head 0040109E mov eax, [ebp+var_4] 004010A1 mov [ebp+var_8], eax ; head = curr الفرق الجوهري بين الـ struct العادي والـ Linked List في الأسمبلي هو كثرة عمليات mov التي تدل على تكوين الروابط (Links) بين الـ Nodes كما يظهر في الأسطر المعلمة بـ [1] و [2].\n","permalink":"https://outofsrvc.github.io/ar/workshop/c-constructs-in-assembly/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eدائماً في بداية رحلة أي شخص عند التعامل مع لغة Assembly، يشعر بصعوبة كونها لغة Low-Level على عكس اللغات الأخرى كـ C أو Python. سنحاول في هذا المقال تبسيط أكواد الأسمبلي لكي نتمكن من فهمها بشكل أكبر إن شاء الله.\u003c/p\u003e\n\u003cp\u003eفكرة المقال هي أننا سنكتب كوداً بسيطاً بلغة C ونقوم بعمل Compile له ليصبح x86 Assembly، ثم نشرح الخطوات التي تحدث لنتمكن من تحليل الـ Control Flow.\u003c/p\u003e","title":"Recognizing C Code Constructs in Assembly"},{"content":"بسم الله الرحمن الرحيم.\nعندما نقوم بالتعامل مع البرمجيات الخبيثة (Malware) ويتطلب منا الأمر فحصها، يجب أن نعلم كيفية تفكير المهاجم والخطوات التي يسعى إليها. لذلك، في هذا المقال سنناقش إن شاء الله التسلسل الهجومي أو ما يعرف بـ Attack Lifecycle، وسنشرح بعض المصطلحات الأساسية في تطوير البرمجيات الخبيثة.\nتقسم دورة الهجوم إلى ثلاث مراحل رئيسية:\nشكل (1): توضيح دورة حياة الهجمات.\nالمرحلة الأولى: الوصول الأولي (Stage 1: Initial Access) هذه المرحلة تركز على كسر خطوط الدفاع الأولى والوصول إلى داخل النظام.\nالاستطلاع (Reconnaissance): تبدأ العملية بجمع المعلومات عن الهدف. يشمل ذلك البحث عن عناوين الـ IP، فحص المنافذ المفتوحة، أو حتى جمع معلومات عن الموظفين لاستخدامها في الهندسة الاجتماعية (Social Engineering). الاستغلال (Exploitation): بعد العثور على نقطة ضعف (ثغرة في نظام، خدمة غير محدثة، أو حتى موظف يمكن خداعه)، يقوم المهاجم باستخدام أداة أو كود معين لاستغلال هذه الثغرة. التسلل والاختراق (Infiltration): هي لحظة النجاح في الاستغلال وتخطي الجدار الأمني، حيث يحصل المهاجم على موطئ قدم أولي (Initial Foothold) داخل الشبكة. المرحلة الثانية: التثبيت والاستكشاف الداخلي (Stage 2: Entrenchment \u0026amp; Discovery) بعد دخول المهاجم، يحتاج إلى فهم بيئته الجديدة وضمان عدم طرده منها.\nالاستطلاع الداخلي (Internal Reconnaissance): المهاجم الآن داخل الشبكة، ويبدأ بالبحث حوله ليرى ما هي الأجهزة المتاحة، ما هي الصلاحيات التي يملكها، وأين توجد البيانات الحساسة (مثل قواعد البيانات أو خوادم الإدارة). التثبيت (Entrenchment): هذه الخطوة حاسمة؛ المهاجم لا يريد أن يفقد الوصول إذا قام مدير النظام بإعادة تشغيل السيرفر أو ترقيع الثغرة الأولى. لذلك، يقوم بإنشاء أبواب خلفية (Backdoors) أو زرع برمجيات خبيثة لضمان بقائه. ملاحظة: هذه هي النقطة التي يكون فيها الـ Reverse Engineering وتحليل الشيفرات الخبيثة في غاية الأهمية لفهم كيف يختبئ المهاجم وكيف يحافظ على صلاحياته في النظام.\nالمرحلة الثالثة: تنفيذ الهدف النهائي (Stage 3: Objective Execution) هنا يبدأ المهاجم في جني ثمار اختراقه وتنفيذ العملية التي جاء من أجلها.\nالتحكم والسيطرة (Command \u0026amp; Control - C2): تقوم البرمجيات الخبيثة التي تم زرعها بالاتصال بخوادم خارجية يسيطر عليها المهاجم. من خلال هذه القناة، يتلقى المهاجم الأوامر ويرسلها إلى النظام المخترق بشكل مستمر ومخفي. تهريب البيانات (Exfiltration): تجميع البيانات الحساسة (أرقام بطاقات ائتمان، أسرار تجارية، كلمات مرور) ونقلها خلسة إلى خارج شبكة الضحية. إخفاء الأثر (Purge): الخطوة الأخيرة وتتمثل في مسح السجلات (Logs)، وحذف الأدوات التي استخدمها المهاجم لإخفاء أي دليل على وجوده. في بعض الحالات، قد تشمل هذه المرحلة تدمير النظام (مثل تشفير الملفات في هجمات الفدية Ransomware أو مسحها عبر برمجيات Wiper). خلاصة: أصبحت لدينا الآن نظرة عن منهجية كل هجوم يتم عبر الإنترنت. ونحن كمهندسين عكسيين ومحللي برمجيات خبيثة، يتركز عملنا بشكل أساسي على المرحلة الثانية (Stage 2) و المرحلة الثالثة (Stage 3).\nمصطلحات أساسية في تطوير البرمجيات الخبيثة (Malware Terminology) الخطوات السابقة لها مصطلحات تقنية خاصة يجب علينا معرفتها لتسهيل عملية التحليل:\n1. الضغط (Compression / Packing) عبارة عن دمج الملفات المضغوطة بواسطة Packer مع كود فك الضغط في ملف تنفيذي واحد. الفكرة هي أن الملف عندما يصل إلى جهاز الضحية، يكون فعلياً عبارة عن غلاف (Wrapper Program) وظيفته الأساسية فك ضغط الملف الخبيث الحقيقي وتنفيذه في الذاكرة لتجنب برامج الحماية.\nشكل (2): توضيح كيف يتم ضغط وفك ضغط الملفات.\n2. التشويش (Obfuscation) فعل متعمد لإنشاء كود يصعب على البشر (والمحللين) فهمه أو قراءته بسهولة.\nتظهر النصوص (Strings) البسيطة مشفرة بخوارزميات مثل Base64 أو XOR. يتم إدراج دوال (Functions) لا فائدة منها لتشتيت الانتباه (Junk Code). في لغة الأسمبلي، قد ترى تعليمات NOP (No Operation) بكثرة والتي لا تؤدي أي وظيفة. استخدام تعليمات push بشكل متكرر كتقنية لإخفاء بناء الـ Strings في الذاكرة. شكل (3): كود يوضح كيف يتم التمويه.\nوهذا مثال توضيحي لكيفية تصميم كود مشوش بلغة C:\nشكل (4): توضيح كيف يتم التلاعب بالكود.\n3. الاستمرارية (Persistence) يسعى مطور البرمجيات الخبيثة إلى جعل الـ Malware يعمل على الجهاز ويستمر لأطول فترة ممكنة، حتى بعد إعادة التشغيل.\nالملفات الخاصة (Special Files): يتم وضع البرمجية في مسارات النظام المخفية أو التي لا يتفقدها المستخدم العادي غالباً، مثل مجلد %APPDATA%. بعض هذه المسارات تمتلك صلاحيات وصول أعمق للنظام. تقنيات متقدمة: يمكنك البحث والقراءة أكثر عن استخدام الـ Shared Files، والوصول عبر الـ Namespaces، أو استخدام الـ Alternative Data Streams (ADS) في نظام ملفات NTFS. 4. تصعيد الصلاحيات (Privilege Escalation) استغلال ثغرة في تصميم أو إعدادات النظام (Configuration) للوصول المتقدم لموارد النظام (Resources) بصلاحيات مدير (Admin) أو جذر (Root).\nالتقنيات الشائعة:\nDLL Hijacking DLL Injection Buffer Overflow Stack Overflow Heap Spray ROP (Return-Oriented Programming) UAC Bypasses 5. تجنب الكشف وتخطي الدفاعات (Defense Evasion) يعني إدخال البرمجية الخبيثة على مراحل وتجميعها داخل النظام على فترات متفاوتة لتجنب إثارة الشبهات.\nالتقنيات الشائعة:\n(Killing AV) (Deleting itself after run) (Time bombs / Time stomping) DLL Side-Loading Process Hollowing Code Injection ","permalink":"https://outofsrvc.github.io/ar/workshop/cyber-attack-lifecycle/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eعندما نقوم بالتعامل مع البرمجيات الخبيثة (Malware) ويتطلب منا الأمر فحصها، يجب أن نعلم كيفية تفكير المهاجم والخطوات التي يسعى إليها. لذلك، في هذا المقال سنناقش إن شاء الله التسلسل الهجومي أو ما يعرف بـ Attack Lifecycle، وسنشرح بعض المصطلحات الأساسية في تطوير البرمجيات الخبيثة.\u003c/p\u003e\n\u003cp\u003eتقسم دورة الهجوم إلى ثلاث مراحل رئيسية:\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"Attack Lifecycle\" decoding=\"async\" loading=\"lazy\" src=\"/assets/img/workshop/lifecycle/lifecycle.png\"\u003e\n\u003cem\u003eشكل (1): توضيح دورة حياة الهجمات.\u003c/em\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"المرحلة-الأولى-الوصول-الأولي-stage-1-initial-access\"\u003eالمرحلة الأولى: الوصول الأولي (Stage 1: Initial Access)\u003c/h2\u003e\n\u003cp\u003eهذه المرحلة تركز على كسر خطوط الدفاع الأولى والوصول إلى داخل النظام.\u003c/p\u003e","title":"Cyber Attack Lifecycle"},{"content":"بسم الله الرحمن الرحيم.\nدائماً عندما نريد تحليل أي ملف، نقوم بالخطوات التالية سواء كان الهدف من التحليل هو اكتشاف ما إذا كان الملف سليماً أم يحتوي على برمجيات خبيثة (Malware)، أو حتى إن كنا نريد كسر حمايته (Cracking):\nThe 4 Stages of Analysis التحليل الثابت الأساسي (Basic Static Analysis): هذا التحليل لا يتطلب خبرة تقنية عميقة، بل يعتمد بشكل كلي على أدوات تعمل بشكل تلقائي (مثل VirusTotal). يكشف لك هذا التحليل عن مؤشرات (Indicators) تبين ما إذا كان هذا الملف فايروساً أم لا.\nالقاعدة: هذا التحليل يتم بدون تشغيل البرنامج (Without running the executable).\nالتحليل الديناميكي الأساسي (Basic Dynamic Analysis): مشابه لما سبقه، ولكن الفرق أنك هنا بحاجة إلى بيئة وهمية (Virtualization).\nالقاعدة: هذه الخطوة تتطلب تشغيل البرنامج (Running the executable) لترى آلية عمله وسلوكه الفعلي (Behavior).\nالتحليل الثابت المتقدم (Advanced Static Analysis): هذه المرحلة يتوجب أن يكون لديك خبرة كافية للتعامل مع برامج التفكيك (Disassemblers) كـ IDA Pro و Ghidra. نلخص هذه المرحلة بأنك سوف تحلل أكواد الأسمبلي (Assembly) وتفهم آلية عملها، أي الهيكلية التي يمشي بها البرنامج.\nالتحليل الديناميكي المتقدم (Advanced Dynamic Analysis): هذه المرحلة تتطلب خبرة تقنية لأنك سوف تتعامل مع المنقح (Debugger). لنشبهه بالـ Disassembler، ولكن الفرق بينهما هو أن الـ Debugger يسمح لك بأن تنفذ الكود وتمشي فيه سطراً بسطر في الذاكرة الحية، بينما الـ Disassembler لا ينفذ الكود (وهو أساس التحليل الثابت). من أفضل الـ Debuggers هو x64dbg.\nBasic Reconnaissance (الاستطلاع الأساسي) في هذا المقال، سنناقش أول خطوتين من عملية التحليل، وما يعرف بالاستطلاع الأساسي: وهو جمع معلومات ومؤشرات أولية سريعة حول الملف قبل الغوص في التحليل العميق. وكما قلنا، هذه الخطوة لا تحتاج إلى خبرة تقنية معقدة، فهي عبارة عن استخدام أدوات بسيطة. سأذكر كل أداة، هدف استخدامها، وصورة لواجهتها.\n1. Helpful Websites VirusTotal: للتحقق من البصمة الرقمية للملف (Hashing) ومعرفة ما إذا كانت شركات مكافحة الفيروسات قد صنفته كخبيث. شكل (1): واجهة موقع virustotal.\nHybrid-Analysis: خدمة توفر تشغيلاً تلقائياً للملف وتقدم تقريراً سريعاً عن سلوكه (سجل الملفات، العمليات، والشبكة). شكل (2): واجهة موقع hybrid-analysis.\nCyberChef: أداة لفك التشفير وتحليل البيانات (مثل Base64, XOR). شكل (3): واجهة موقع CyberChef.\n2. Information Gathering: Static Detect It Easy (DIE): لمعرفة نوع الملف ونوع المترجم (Compiler) وهل هو ملف مضغوط بـ Packer أم لا. من أهم المؤشرات في هذا البرنامج هو الـ Entropy. شكل (4): واجهة تطبيق DIE.\nFLOSS: أداة قادرة على استخراج النصوص التي يحاول المبرمج تشفيرها داخل الكود (Obfuscated Strings). شكل (5): أمر تنفيذ برنامج FLOSS.\nPE-Bear: يستخدم لتحليل ترويسات الملف (PE Headers) واستكشاف الموارد (Resources) ومعرفة المكتبات (DLLs) والدوال التي يستدعيها البرنامج مثل CreateProcessA. شكل (6): واجهة تطبيق PE-Bear.\n3. Information Gathering: Dynamic Process Monitor (ProcMon): يقوم بمراقبة نشاط الملفات وسجل النظام (Registry) وحركة الشبكة في الوقت الفعلي. شكل (7): واجهة تطبيق ProcMon.\nProcess Explorer (ProcExp): يستخدم لمراقبة العمليات النشطة حالياً في النظام واكتشاف أي عمليات مشبوهة. شكل (8): واجهة تطبيق ProcExp.\n4. Network Monitoring FakeNet-NG: يستخدم لمحاكاة خدمات الإنترنت محلياً، مما يسمح للمحلل برؤية طلبات الشبكة (مثل HTTP, GET) دون الحاجة لاتصال حقيقي بالإنترنت لتجنب الخطر. شكل (9): صورة للملف الذي يتم انشاءه بواسطة عمل run للتطبيق بلاحقة .pcap الذي يتم فتحه على wireshark.\nWireshark: أداة لالتقاط وتحليل حركة الشبكة (Network Sniffing) لمعرفة ما إذا كان الملف يحاول التواصل مع خوادم خارجية للتحكم والسيطرة. شكل (10): واجهة تطبيق WireShark.\n","permalink":"https://outofsrvc.github.io/ar/workshop/basic-reconnaissance/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eدائماً عندما نريد تحليل أي ملف، نقوم بالخطوات التالية سواء كان الهدف من التحليل هو اكتشاف ما إذا كان الملف سليماً أم يحتوي على برمجيات خبيثة (Malware)، أو حتى إن كنا نريد كسر حمايته (Cracking):\u003c/p\u003e\n\u003ch2 id=\"the-4-stages-of-analysis\"\u003eThe 4 Stages of Analysis\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eالتحليل الثابت الأساسي (Basic Static Analysis):\nهذا التحليل لا يتطلب خبرة تقنية عميقة، بل يعتمد بشكل كلي على أدوات تعمل بشكل تلقائي (مثل VirusTotal). يكشف لك هذا التحليل عن مؤشرات (Indicators) تبين ما إذا كان هذا الملف فايروساً أم لا.\u003c/p\u003e","title":"Basic Reconnaissance"},{"content":"بسم الله الرحمن الرحيم.\nبعد الانتهاء من التحليل الأساسي (Basic Analysis)، ننتقل إلى التحليل العميق (Advanced Analysis). في هذا المقال سنناقش أهم برامج الـ Disassemblers والـ Debuggers المستخدمة لتحليل الملفات بشرح بسيط وسريع. وعند التطبيق العملي، سنتعرف على هذه الأدوات بشكل أفضل وأعمق.\nبرامج التفكيك (Disassemblers) تُستخدم هذه الأدوات لقراءة البرنامج دون تشغيله (Static Analysis)، وهي تشبه قراءة الخريطة لتحديد الاتجاهات وتضاريس المنطقة قبل بداية الرحلة.\nIDA Free (سنستخدمها في الورشة) شكل (1): واجهة تطبيق IDA Freeware.\nGhidra فلسفة استعمال الأداتين سوياً: IDA (الرادار): واجهته هي الأفضل والأسرع في التنقل بين الدوال والمخططات البيانية (Graph View). هي الأداة التي نبدأ بها لنفهم \u0026ldquo;أين\u0026rdquo; نذهب وما هو الهيكل العام للبرنامج. Ghidra (التعمق): نسخة IDA المجانية لها قيود، مثل عدم دعم بعض المعماريات كـ ARM، وعدم وجود Decompiler (محول الكود إلى لغة C) لبعض الملفات. على عكس Ghidra الذي يوفر هذه الميزات القوية وبشكل مجاني تماماً (Open Source). Visual Modes (أنماط العرض) Graph Mode: يعرض تدفق التحكم (Control Flow) كمخطط بياني يسهل تتبع القفزات والقرارات البرمجية (If/Else, Loops). Text Mode: يعرض كود الأسمبلي بشكل متسلسل وتقليدي من الأعلى للأسفل. الوظائف المتقدمة (Advanced Functions) تسمح للمحلل بالانتقال إلى مراجع الكود Xrefs (Cross-References) لمعرفة أين يتم استدعاء نصوص أو دوال معينة، وتتبع المسار العكسي وصولاً إلى نقطة البداية (Start Function أو Main).\n⌨️ IDA Command CheatSheet IDA-Cheatsheet\nCommand (الاختصار) Action (الإجراء) X Jump to Xref (الانتقال إلى المراجع) G Jump to address (الانتقال إلى عنوان ذاكرة محدد) SHIFT + ; أو : Enter comment (إضافة تعليق على الكود) المنقحات (Debuggers) x64dbg (سنستخدمها في الورشة) شكل (2): واجهة تطبيق x64dbg.\nتُستخدم هذه الأدوات لإجراء تحليل أعمق عبر تشغيل البرنامج فعلياً في بيئة محكومة لمراقبة سلوكه المخفي، والذي قد لا يظهر غالباً في الـ Disassembler بسبب تقنيات التشويش (Obfuscation).\nالتحكم في التنفيذ (التلاعب بالمنطق) تتيح هذه الأدوات للمحلل \u0026ldquo;التلاعب\u0026rdquo; بمسار البرنامج في الذاكرة الحية. مثل تغيير قيم المسجلات (Registers) أو الأعلام (Flags) لتجاوز شروط معينة (Branch Statements) والوصول إلى أكواد مخفية أو تخطي شاشات التحقق من التفعيل (Cracking).\n⌨️ x64dbg Command CheatSheet Command (الاختصار) Action (الإجراء) ; Enter comment (إضافة تعليق) F2 Toggle Breakpoint (وضع/إزالة نقطة توقف) F7 Step Into (الدخول داخل الدالة) F8 Step Over (تخطي الدالة والانتقال للسطر التالي) F9 Run (تشغيل البرنامج حتى نقطة التوقف التالية) Space Edit Instruction (تعديل تعليمة الأسمبلي في الذاكرة) Keyboard Layout for IDA Free \u0026amp; x64dbg شكل (3): خريطة للمفاتيح التي سنحتاج التعامل معها دائماً أثناء التحليل.\n","permalink":"https://outofsrvc.github.io/ar/workshop/re-toolkit/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eبعد الانتهاء من التحليل الأساسي (Basic Analysis)، ننتقل إلى التحليل العميق (Advanced Analysis). في هذا المقال سنناقش أهم برامج الـ Disassemblers والـ Debuggers المستخدمة لتحليل الملفات بشرح بسيط وسريع. وعند التطبيق العملي، سنتعرف على هذه الأدوات بشكل أفضل وأعمق.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"برامج-التفكيك-disassemblers\"\u003eبرامج التفكيك (Disassemblers)\u003c/h2\u003e\n\u003cp\u003eتُستخدم هذه الأدوات لقراءة البرنامج دون تشغيله (Static Analysis)، وهي تشبه قراءة الخريطة لتحديد الاتجاهات وتضاريس المنطقة قبل بداية الرحلة.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://hex-rays.com/ida-free/\"\u003eIDA Free\u003c/a\u003e (سنستخدمها في الورشة)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cimg alt=\"IDA Free\" decoding=\"async\" loading=\"lazy\" src=\"/assets/img/workshop/re-tools/ida.gif\"\u003e\n\u003cem\u003eشكل (1): واجهة تطبيق IDA Freeware.\u003c/em\u003e\u003c/p\u003e","title":"RE Toolkit: Disassemblers \u0026 Debuggers"},{"content":"بسم الله الرحمن الرحيم.\nالمهندس العكسي لا يرى الكود كأوامر برمجية معقدة فحسب، بل يراه كـ \u0026ldquo;صندوق أسود\u0026rdquo; (Black Box) له مدخلات (Inputs) ومخرجات (Outputs). لذلك، سنناقش في هذا المقال كيف يتم بناء عقلية المهندس العكسي وكيفية استنتاج المنطق البرمجي المخفي.\nالسيناريو: الباب الإلكتروني (The Scenario) تخيل أننا أمام باب إلكتروني مغلق. هذا الباب لا يُفتح إلا إذا أدخلت \u0026ldquo;حرفاً\u0026rdquo; واحداً صحيحاً من لوحة المفاتيح. لدينا فقط لوحة المفاتيح وشاشة صغيرة تعرض رسالة واحدة عند كل محاولة إدخال.\nالتجربة (The Experiment) قمنا بإدخال 3 أحرف مختلفة لمراقبة سلوك الباب، وكانت النتيجة على الشاشة كالتالي:\nإدخال A \u0026ndash;\u0026gt; النتيجة: 66 إدخال B \u0026ndash;\u0026gt; النتيجة: 67 إدخال C \u0026ndash;\u0026gt; النتيجة: 68 بعدها، ظهرت رسالة توضح أن الباب يفتح فقط إذا ظهر الرقم 89.\nمنهجية التفكير (The Thought Process) هنا يبدأ عقل المهندس العكسي بطرح ثلاثة أسئلة محورية:\n(Static Analysis): ما هي الخوارزمية (Algorithm) التي يعمل بها هذا الباب بناءً على المدخلات والمخرجات؟ (Extracting the Flag): ما هو الحرف الدقيق الذي يجب إدخاله للوصول إلى النتيجة المطلوبة لفتح الباب؟ (Dynamic Analysis \u0026amp; Patching): إذا قمنا بفك لوحة المفاتيح ووجدنا سلكاً برمجياً مكتوباً عليه \u0026ldquo;إذا كانت النتيجة 89 أرسل إشارة لفتح الباب\u0026rdquo;. وقررنا قطع هذا السلك ووصله ببطارية ليعطي إشارة دائمة بالفتح.. ماذا نسمي هذه العملية؟ الحل والتحليل (The Solution) 1. فهم الخوارزمية (Algorithm Analysis) بمجرد النظر إلى النتائج، نلاحظ وجود نمط ثابت ومطرد. في علوم الحاسوب، لكل حرف قيمة رقمية تمثله تُعرف بـ (ASCII Code).\nالحرف A قيمته الحقيقية في الحاسوب هي 65. الحرف B قيمته الحقيقية هي 66. الحرف C قيمته الحقيقية هي 67. الاستنتاج: الخوارزمية التي يعمل بها الباب هي (Input + 1). البرنامج يأخذ قيمة الحرف المدخل (ASCII) ويزيد عليها الرقم 1.\n2. استخراج العلم (Finding the Flag) الهدف هو الوصول للرقم 89. بتطبيق العملية الرياضية العكسية للخوارزمية التي اكتشفناها: 89 - 1 = 88\nبالبحث في جدول الـ ASCII، نجد أن الرقم 88 يمثل الحرف X إذن الحل لفتح الباب بالطريقة الشرعية هو: إدخال الX.\n3. التعديل البرمجي (Patching) المهمة الثالثة تشرح مفهوماً جوهرياً في الهندسة العكسية وهو Patching (الترقيع أو التعديل).\nبدلاً من البحث عن الحرف X (الذي يمثل كلمة السر الشرعية)، قمنا بتعديل \u0026ldquo;سلوك\u0026rdquo; البرنامج (قطعنا الأسلاك) ليتجاهل الفحص وعملية المقارنة تماماً.\nفي بيئة التنقيح الحقيقية (x64dbg)، هذا الإجراء يشبه تماماً تغيير تعليمة القفز JZ (اقفز إذا كان الناتج متطابقاً/صفراً) إلى تعليمة قفز إجباري JMP (اقفز دائماً). هذا التعديل البسيط يجعل الباب يُفتح دائماً في كل مرة، سواء كانت كلمة السر المُدخلة صحيحة أم خاطئة!\n","permalink":"https://outofsrvc.github.io/ar/workshop/thinking-lab/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eالمهندس العكسي لا يرى الكود كأوامر برمجية معقدة فحسب، بل يراه كـ \u0026ldquo;صندوق أسود\u0026rdquo; (Black Box) له مدخلات (Inputs) ومخرجات (Outputs). لذلك، سنناقش في هذا المقال كيف يتم بناء عقلية المهندس العكسي وكيفية استنتاج المنطق البرمجي المخفي.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"السيناريو-الباب-الإلكتروني-the-scenario\"\u003eالسيناريو: الباب الإلكتروني (The Scenario)\u003c/h2\u003e\n\u003cp\u003eتخيل أننا أمام باب إلكتروني مغلق. هذا الباب لا يُفتح إلا إذا أدخلت \u0026ldquo;حرفاً\u0026rdquo; واحداً صحيحاً من لوحة المفاتيح. لدينا فقط لوحة المفاتيح وشاشة صغيرة تعرض رسالة واحدة عند كل محاولة إدخال.\u003c/p\u003e","title":"The Reverse Engineer's Mindset"},{"content":"بسم الله الرحمن الرحيم.\nفي هذا المقال، سوف نقوم بحل تحدي (Lab) بسيط يعتمد بشكل كامل على التحليل الثابت (Static Analysis). الهدف هنا هو تطبيق المفاهيم التي تعلمناها سابقاً لفك تشفير العلم (Flag) المخفي داخل البرنامج.\nتجهيز بيئة العمل: يمكنك تحميل الملف التنفيذي الخاص بهذا اللاب من الرابط التالي 5t4t1c_cr4ckm3 في مستودع الدورة كلمة فك الضغط: p01nt\nلفتح هذه الملف يجب عليك ان تفتحه داخل VM مع اني انا الذي صممت هذا الملف ولكن لا تثق بالمجتمع السيبراني أبدا نقوم بعمل run للملف بالامر التالي\nشكل (1)\n1. الاستطلاع الأولي (Initial Triage) بدايةً، نقوم بفتح البرنامج باستخدام أداة Detect It Easy (DIE) لنتعرف على معمارية البرنامج، لغة البرمجة، وهل هو مضغوط (Packed) أم لا.\nشكل (2)\nكما نرى في الصورة، البرنامج يعمل بمعمارية 32-bit، تمت برمجته بلغة C وتم تجميعه بواسطة مترجم GCC. ونوع الملف هو تنفيذي لبيئة ويندوز (PE32)، ولا يوجد أي مؤشر على استخدام أداة ضغط (Packer).\nننتقل بعدها إلى تطبيق PE-Bear لنلقي نظرة سريعة على أقسام الترويسة (Headers). بعد التأكد من أن البرنامج من نوع EXE، نركز على قسم النصوص (Strings) والواردات (Imports) بهدف العثور على أي مؤشر واضح للـ Flag.\nشكل (3)\nبعد البحث، نكتشف أن الـ Flag غير موجود كنص صريح (Plaintext)، مما يعني أنه تم تطبيق عملية إخفاء أو تشفير (Obfuscation) عليه.\n2. التحليل داخل IDA Pro الآن، نقوم بفتح الملف التنفيذي داخل برنامج IDA Pro للبدء في تحليل الكود. سيتعرف البرنامج تلقائياً على معمارية الملف ويقوم بتفكيكه.\nشكل (4)\nاستخراج النصوص (Strings) نبدأ بالبحث عن أي رسائل تفاعلية تساعدنا في تحديد مكان منطق التحقق (Verification Logic). نضغط على الاختصار Shift + F12 لفتح نافذة النصوص (Strings Window)، ونبحث عن الجملة التي تظهر عند إدخال حل صحيح (أو رسالة الخطأ).\nشكل (5)\nنقوم بالنقر المزدوج على الجملة المطلوبة، ليأخذنا IDA إلى مكان تخزين هذا النص في قسم البيانات (.rdata أو .data).\nشكل (6)\nتتبع المراجع (Cross-References) لمعرفة أين يتم استخدام هذا النص في الكود، ننقر عليه، ثم نضغط على الاختصار X (أو ننقر نقراً مزدوجاً على التعليق الجانبي المؤدي للدالة). سيتم نقلنا مباشرة إلى الدالة التي تستدعي هذه الرسالة.\nالآن نحن في الـ Visual Mode. تذكر أنه يمكنك التنقل بين وضع المخطط البياني (Graph View) ووضع النص المتسلسل (Text View) بالضغط على زر Space. في حالتنا، نريد البقاء في الـ Graph View لتتبع مسار البرنامج والشروط (Branches) بوضوح.\n3. تحليل خوارزمية التحقق (Algorithm Analysis) نقوم بتكبير المخطط البياني للتركيز على كتلة الأوامر (Basic Block) التي تسبق رسالة النجاح لنحاول فهم المنطق البرمجي.\nشكل (7)\nنقوم بالنقر على الدالة مرتين\nأ) التحقق من الطول (Length Check) إذا ركزنا على تعليمة المقارنة cmp، نلاحظ أنه يسبقها استدعاء لدالة strlen (والتي تقوم بحساب طول النص المُدخل). يتم مقارنة الناتج مع القيمة 0Bh (وهي تعادل الرقم 11 بالنظام العشري).\nشكل (8)\nالاستنتاج الأول: الـ Flag الصحيح يجب أن يتكون من 11 محرفاً (Characters). ب) حلقة التشفير (Encryption Loop) نتتبع مسار البرنامج لنصل إلى حلقة التكرار (Loop) التالية:\nشكل (9)\nنلاحظ بوضوح وجود تعليمة xor تُنفذ باستخدام القيمة الثابتة 5Ah (أو 0x5A).\nشكل (10)\nالاستنتاج الثاني: الـ Flag مكون من 11 محرفاً، وتم تشفيره بعملية XOR بسيطة باستخدام المفتاح 0x5A. ج) استخراج القيم المشفرة لمعرفة المحارف الأصلية، يجب أن نرى ما الذي تتم مقارنته داخل اللوب. نلاحظ وجود تعليمة cmp تقارن بين مسجلين: eax و edx.\nالمسجل edx يحمل المحارف التي أدخلها المستخدم. المسجل eax يحمل محارف الـ Flag المشفرة التي يجلبها البرنامج من الذاكرة (تحديداً من العنوان byte_407070). ننقر نقرة واحدة على العنوان byte_407070 ونضغط على زر المراجع X.\nتظهر لنا نافذة المراجع. ندقق في عمود النوع (Type) ونختار المرجع الذي يحمل الحرف w (والذي يرمز إلى Write، أي المكان الذي يتم فيه كتابة/تخزين هذه القيم في الذاكرة)، ثم نضغط OK.\nشكل (11)\nالآن تظهر لنا سلسلة القيم المشفرة المخزنة في الذاكرة (كمصفوفة من البايتات)، ويقوم IDA مشكوراً بإظهار التعليقات المرافقة لها. اكتملت المعادلة الآن!\nشكل (12)\n4. كتابة سكريبت فك التشفير (Decryption Script) لدينا الآن مصفوفة من 11 محرفاً مشفراً، ومفتاح التشفير هو 0x5A. بما أن خوارزمية XOR قابلة للانعكاس (أي أن تشفير النص المشفر بنفس المفتاح يعطينا النص الأصلي)، سنقوم بكتابة سكريبت بسيط بلغة Python لفك التشفير واستخراج الـ Flag.\n# مصفوفة القيم المشفرة التي استخرجناها من IDA encrypted_hex = [0x29, 0x2e, 0x6a, 0x28, 0x37, 0x1a, 0x29, 0x32, 0x69, 0x36, 0x36] # مفتاح التشفير (XOR Key) key = 0x5A # فك التشفير عبر Loop يأخذ كل محرف (بايت)، يطبق عليه XOR مع المفتاح، ثم يحوله إلى نص flag = \u0026#34;\u0026#34;.join([chr(b ^ key) for b in encrypted_hex]) print(f\u0026#34;The Flag is: {flag}\u0026#34;) عند تنفيذ هذا الكود، ستكون المخرجات كالتالي:\nThe Flag is: st0rm@sh3ll\n5. التجربة والتأكيد (Verification) للتأكد من صحة الحل، نقوم بتشغيل البرنامج وإدخال الـ Flag الذي حصلنا عليه:\nشكل (13)\nتظهر لنا رسالة النجاح. لقد قمنا بتحليل الملف ثابتًا، وفهمنا الخوارزمية، وقمنا بفك التشفير بنجاح!\n","permalink":"https://outofsrvc.github.io/ar/workshop/static-lab/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eفي هذا المقال، سوف نقوم بحل تحدي (Lab) بسيط يعتمد بشكل كامل على التحليل الثابت (Static Analysis). الهدف هنا هو تطبيق المفاهيم التي تعلمناها سابقاً لفك تشفير العلم (Flag) المخفي داخل البرنامج.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eتجهيز بيئة العمل: يمكنك تحميل الملف التنفيذي الخاص بهذا اللاب من الرابط التالي \u003ca href=\"/assets/binaries/5t4t1c_cr4ckm3.7z\"\u003e5t4t1c_cr4ckm3\u003c/a\u003e في مستودع الدورة كلمة فك الضغط: \u003cstrong\u003ep01nt\u003c/strong\u003e\u003c/p\u003e\u003c/blockquote\u003e\n\u003chr\u003e\n\u003cblockquote\u003e\n\u003cp\u003eلفتح هذه الملف يجب عليك ان تفتحه داخل \u003cstrong\u003eVM\u003c/strong\u003e مع اني انا الذي صممت هذا الملف ولكن لا تثق بالمجتمع السيبراني أبدا نقوم بعمل run للملف بالامر التالي\u003c/p\u003e","title":"Static Lab"},{"content":"بسم الله الرحمن الرحيم.\nفي هذا المقال، سوف نقوم بحل تحدي (Lab) بسيط يعتمد بشكل كامل على التحليل الديناميكي (Dynamic Analysis) باستخدام المنقح x64dbg. سنتعلم كيف نتخطى آليات اكتشاف المنقح (Anti-Debugging) وكيف نقوم بتعديل مسار البرنامج (Patching) ليقبل أي مفتاح ندخله.\nتجهيز بيئة العمل: يمكنك تحميل الملف التنفيذي الخاص بهذا اللاب من الرابط التالي dyn4m1c_cr4ckm3 في مستودع الدورة كلمة فك الضغط: p01nt\n1. الاستطلاع والملاحظة (Reconnaissance) بدايةً، نفتح موجه الأوامر (CMD) ونقوم بتشغيل البرنامج لنرى ما هي مخرجاته الأولية.\nشكل (1)\nنلاحظ أن البرنامج يتطلب إدخال مفتاح (Arguments) ليعمل.\nعند فتح قسم النصوص (Strings) باستخدام أداة PE-Bear، نلاحظ وجود رسالة مثيرة للاهتمام تشير إلى اكتشاف منقح (Debugger Detected).\nشكل (2)\nهذا يعني بوضوح أن هناك دالة حماية داخل الكود تقوم بفحص ما إذا كان البرنامج يعمل تحت بيئة تنقيح أم لا. بالبحث في دوال الاستيراد (Imports)، نجد الدالة التالية:\nشكل (3)\nدالة IsDebuggerPresent هي واجهة برمجية (API) في ويندوز مسؤولة عن اكتشاف ما إذا كان البرنامج يعمل داخل Debugger. سنأخذ هذه المعلومة كأول نقطة ارتكاز لنا.\n2. تجهيز بيئة التنقيح (x64dbg Setup) الآن، نقوم بفتح البرنامج داخل x64dbg. بما أن البرنامج يتطلب تمرير مفتاح (Argument) عند التشغيل، يجب أن نخبر المنقح بذلك:\nمن القائمة العلوية، نضغط على File -\u0026gt; Change Command Line. نضيف بعد مسار البرنامج كلمة اختبارية، مثلاً test_key. شكل (4)\nنضغط OK، ثم نضغط على الاختصار Ctrl + F2 لإعادة تشغيل البرنامج (Restart) وتطبيق الأمر السابق. نضغط الآن على المفتاح F9 (Run) لنجعل البرنامج ينفذ التعليمات الأولية للنظام حتى يتوقف عند نقطة الإدخال الرئيسية للبرنامج (Entry Point)، حيث سيظهر لنا اسم البرنامج في التعليقات.\nشكل (5)\n3. تخطي حماية المنقح (Bypassing Anti-Debugging) نريد الآن إيجاد المكان الذي يتحقق فيه البرنامج من وجود المنقح لنقوم بتعطيله.\nنضغط Right-Click (كليك يمين) داخل مربع عرض الأكواد (CPU Window). شكل (6)\nنختار: Search for -\u0026gt; Current Module -\u0026gt; String References.\nفي نافذة النصوص التي ستظهر، نبحث عن رسالة Debugger detected وننقر عليها نقراً مزدوجاً للانتقال إلى مكانها في الكود.\nشكل (7)\nإذا نظرنا إلى الأسطر التي تسبق هذه الرسالة، سنرى أنه يتم استدعاء دالة IsDebuggerPresent، وبعدها مباشرة يقوم البرنامج بعمل test للنتيجة ليكتشف هل نحن نعمل على Debugger أم لا، يليه قفز شرطي (je - Jump if Equal).\nعملية الترقيع (Patching): الآن سنتلاعب بهذا القفز الشرطي لنعكس المنطق تماماً.\nننقر نقرة واحدة على تعليمة je، ثم نضغط على زر Space (مسطرة) لفتح نافذة التعديل (Edit Instruction). شكل (8)\nنقوم بتغيير التعليمة من je (اقفز إذا كان مساوياً) إلى jne (اقفز إذا لم يكن مساوياً). شكل (9)\nنتأكد من ظهور رسالة Instruction encoded successfully في الأسفل، مما يعني أن التعديل قد تم بنجاح في الذاكرة. بهذا نكون قد أعمينا البرنامج، ولن يكتشف أننا نقوم بتحليله!\n4. تحليل دالة التحقق والتعديل النهائي (The Core Logic) نعود الآن إلى نافذة النصوص (String References) مرة أخرى. هذه المرة، نبحث عن رسالة النجاح (Success Message) وننتقل إليها.\nشكل (10)\nبالنظر إلى الكود الذي يسبق رسالة النجاح، نلاحظ استدعاء لدالة strcmp (وهي الدالة البرمجية الشهيرة التي تقوم بمقارنة نصين ببعضهما: المفتاح الأصلي والمفتاح الذي أدخلناه).\nشكل (11)\nننقر على تعليمة الـ call الخاصة بـ strcmp ونضغط F2 لوضع نقطة توقف (Breakpoint) عندها (سيتحول لون العنوان إلى الأحمر).\nنضغط الآن على F9 (Run) مرة أو أكثر حتى يصل تنفيذ البرنامج إلى نقطة التوقف هذه. ملاحظة: البرنامج سيتخطى فحص الـ Debugger بنجاح بفضل التعديل الذي قمنا به سابقاً، ويمكنك رؤية ذلك في نافذة الـ CMD المرافقة لـ x64dbg.\nشكل (12)\nكشف المفتاح (Leaking the Key) قبل تنفيذ الاستدعاء لدالة strcmp مباشرة، إذا نظرنا إلى نافذة المسجلات (Registers) أو الـ Stack، سنرى أنه تم تمرير قيمتين للدالة:\nالمفتاح التجريبي الذي أدخلناه (test_key). المفتاح الأصلي الصحيح المخزن في الذاكرة! شكل (13)\nتعديل منطق القفز (Forcing Success) نضغط الآن F8 (Step Over) لتنفيذ دالة المقارنة وتخطيها. مباشرة بعد دالة المقارنة، سنجد تعليمة test eax, eax تليها تعليمة قفز شرطي jne (والتي ستقفز إلى رسالة الفشل لأن مفتاحنا خاطئ).\nشكل (14)\nسنقوم بعمل Patch آخر هنا: ننقر على jne ونضغط Space، ثم نغيرها إلى je. نضغط F8 للمتابعة. نلاحظ أن علم التصفير (Zero Flag - ZF) يساوي الصفر، وبسبب تغييرنا للتعليمة إلى je، فإن البرنامج لن ينفذ قفزة الفشل، بل سيستمر في المسار الطبيعي (fall-through) وصولاً إلى رسالة النجاح.\nشكل (15)\nنستمر بالضغط على F8 حتى نصل إلى استدعاء دالة memset أو نهاية الإجراء.\nشكل (16)\nإذا ألقينا نظرة على نافذة الـ CMD الآن:\nشكل (17)\nنحن الآن طبقنا مفهوم الـ Patching بنجاح، لأن البرنامج أعطانا رسالة \u0026ldquo;النجاح\u0026rdquo; بالرغم من أن المفتاح الذي أدخلناه (test_key) كان خاطئاً!\n5. تأكيد المفتاح الأصلي إذا أردنا التأكد من عملنا بشكل سليم بدون Patching، يمكننا أخذ المفتاح الأصلي الذي اكتشفناه في الذاكرة أثناء التحليل قبل استدعاء strcmp، ونقوم بتشغيل البرنامج من الـ CMD بشكل طبيعي وتمرير هذا المفتاح له.\nشكل (18)\nتهانينا! لقد قمت للتو بهندسة برنامج عكسياً، تخطيت حماية المنقح، عدلت المنطق البرمجي، واستخرجت المفتاح السري بنجاح.\n","permalink":"https://outofsrvc.github.io/ar/workshop/dynamic-lab/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eفي هذا المقال، سوف نقوم بحل تحدي (Lab) بسيط يعتمد بشكل كامل على التحليل الديناميكي (Dynamic Analysis) باستخدام المنقح x64dbg. سنتعلم كيف نتخطى آليات اكتشاف المنقح (Anti-Debugging) وكيف نقوم بتعديل مسار البرنامج (Patching) ليقبل أي مفتاح ندخله.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eتجهيز بيئة العمل: يمكنك تحميل الملف التنفيذي الخاص بهذا اللاب من الرابط التالي \u003ca href=\"/assets/binaries/dyn4m1c_cr4ckm3.7z\"\u003edyn4m1c_cr4ckm3\u003c/a\u003e في مستودع الدورة كلمة فك الضغط: \u003cstrong\u003ep01nt\u003c/strong\u003e\u003c/p\u003e\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"1-الاستطلاع-والملاحظة-reconnaissance\"\u003e1. الاستطلاع والملاحظة (Reconnaissance)\u003c/h2\u003e\n\u003cp\u003eبدايةً، نفتح موجه الأوامر (CMD) ونقوم بتشغيل البرنامج لنرى ما هي مخرجاته الأولية.\u003c/p\u003e","title":"Dynamic Lab"},{"content":"بسم الله والصلاة والسلام على رسول الله، وعلى آله وصحبه ومن والاه.\nالحمد لله رب العالمين الذي بفضله وتوفيقه تم الانتهاء من ورشة Entry P01NT. أسأل الله أن يكتب لكم العلم النافع والعمل الصالح بها، وأن تكون خير بداية لكم.\nماذا بعد الورشة؟ (The Road Ahead) الهندسة العكسية ليست مجرد قراءة مقالات، بل هي ممارسة، تجربة، وبناء ذاكرة عضلية (Muscle Memory) في التعامل مع الأدوات وتحليل الأكواد. لذلك، قمت بتجهيز خارطة طريق بسيطة لكم:\n1. الممارسة عبر (Crackmes) توجه إلى منصة crackmes.one، وهي مكتبة ضخمة للبرامج المصممة خصيصاً للتدرب على الهندسة العكسية. ابدأ بتطبيق ما تعلمته بشكل متدرج:\nبناء الأساس: قم بحل 10 تحديات بسيطة (مستوى 1 - 2) لترسيخ استخدامك لـ IDA و x64dbg. فهم الخوارزميات: قم بحل 10 تحديات متوسطة (مستوى 2 - 4) للتدرب على خوارزميات التشفير والتحقق. تخطي الحمايات: قم بحل 10 تحديات متقدمة (مستوى 4 - 6) لاختبار قدرتك على التعامل مع تقنيات إخفاء الكود واكتشاف المنقحات (Anti-Debugging). 2. التحديات الاحترافية ومنهجية (Just-in-Time Learning) بعد تجاوزك لمرحلة الـ Crackmes، حان الوقت للانتقال إلى تحديات تحاكي البرمجيات الخبيثة الواقعية، وأهمها تحديات Flare-On.\nفي هذه المرحلة، ستصطدم حتماً بتقنيات وأساليب لم تسمع بها من قبل. هنا يجب عليك ألا تحبط، بل استخدم منهجية التعلم في الوقت المناسب (Just-in-Time Learning). لقد تحدثت عن هذه المنهجية بالتفصيل في هذا المقال: كيف تتعلم الهندسة العكسية بتقنية Just-in-Time.\nخلاصة المنهجية: لا تحاول تعلم كل شيء نظرياً مسبقاً. ابدأ بالتحليل، وعندما تواجه تقنية تجهلها، توقف، ابحث عنها وادرسها، ثم عُد لتطبيقها فوراً لتفكيك التحدي.\nما هو القادم؟ (What\u0026rsquo;s Next?) إن شاء الله، أعمل حالياً على التحضير لورشة قادمة مخصصة لدراسة وحل تحديات Flare-On. سأبدأ معكم من النسخة الأقدم Flare-On 2014 لنتدرج في الصعوبة خطوة بخطوة، ولنبني معاً ملفاً احترافياً (Portfolio) قوياً في هذا المجال. الأمر يتطلب بعض الوقت للتجهيز وإعداد بيئة المختبر، فترقبوا ذلك قريباً!\nونِهايةً، لا تنسوني ووالديّ وإخواننا المستضعفين في سائر البلاد من صالح دعائكم.\nوالسلام عليكم ورحمة الله تعالى وبركاته.\n","permalink":"https://outofsrvc.github.io/ar/workshop/after-that/","summary":"\u003cp\u003eبسم الله والصلاة والسلام على رسول الله، وعلى آله وصحبه ومن والاه.\u003c/p\u003e\n\u003cp\u003eالحمد لله رب العالمين الذي بفضله وتوفيقه تم الانتهاء من ورشة \u003cstrong\u003eEntry P01NT\u003c/strong\u003e. أسأل الله أن يكتب لكم العلم النافع والعمل الصالح بها، وأن تكون خير بداية لكم.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ماذا-بعد-الورشة-the-road-ahead\"\u003eماذا بعد الورشة؟ (The Road Ahead)\u003c/h2\u003e\n\u003cp\u003eالهندسة العكسية ليست مجرد قراءة مقالات، بل هي ممارسة، تجربة، وبناء ذاكرة عضلية (Muscle Memory) في التعامل مع الأدوات وتحليل الأكواد. لذلك، قمت بتجهيز خارطة طريق بسيطة لكم:\u003c/p\u003e","title":"After That"},{"content":"بسم الله الرحمن الرحيم.\nفي هذا المقال، سوف نحل التحدي الأول من تحديات Flare-On (2015). سنعتمد كما هو معتاد على منهجية التعلم بالممارسة (Learning-by-Doing) ونهج التعلم في الوقت المناسب (Just-in-Time Learning).\n1. تحميل التحدي وتشغيله أولاً، نقوم بتحميل التحدي من الموقع الرسمي: flare-on.com\nكلمة سر الملفات: flare.\nبدايةً، نقوم بتشغيل الملف الظاهر أمامنا:\nشكل (1): تشغيل الملف لأول مرة\nنقوم بنسخ المسار المحدد الذي سنضع فيه ملف التحدي:\nشكل (2): نسخ مسار ملف التحدي\nيظهر ملف التحدي باسم: i_am_happy_you_are_to_playing_the_flareon_challenge.\nنقوم بفحص الملف بأداة Detect It Easy (DIE):\nشكل (3): معلومات الملف كما تظهرها أداة DIE\nكما يظهر في الصورة، الملف من نوع PE32 ولغة البرمجة هي x86 Assembly.\n2. أول تشغيل وملاحظة السلوك جميل، لنقم بتشغيل البرنامج:\nشكل (4): تشغيل البرنامج\nحسناً، إنه ملف Console (DOS) وليس بواجهة رسومية. لنجرب أن نكتب أي شيء:\nعندما نقوم بكتابة أي شيء، يتم إغلاق نافذة الـ CMD فوراً. السبب: البرنامج ينفذ بسرعة كبيرة ويُغلق في نفس اللحظة.\nلذلك، نقوم بفتح الـ CMD بأنفسنا، ننتقل إلى مسار البرنامج، ونقوم بتشغيله فقط عبر كتابة اسم البرنامج، ثم نعيد تجربة كتابة أي شيء:\nشكل (5): تشغيل البرنامج من نافذة CMD\nتظهر رسالة خطأ: you are failure.\n3. استعراض النصوص (Strings) رائع، معناها أن البرنامج يحتوي حتى الآن على نصّين (Strings):\nEnter the password you are failure وبالتأكيد هناك نص ثالث يدل على أن كلمة السر التي أدخلناها صحيحة.\nلنفتح الملف بأداة IDA Pro ونقوم بتحليل ساكن (Static Analysis) له:\nشكل (6): فتح الملف داخل IDA Pro\nنقوم بفتح نافذة النصوص (Strings) بالضغط على SHIFT + F12:\nشكل (7): نافذة النصوص (Strings Window)\nهنا ظهرت جميع النصوص التي يحتوي عليها البرنامج. لندقق في النص الذي يدل على أن الكلمة صحيحة: you are success.\n4. تتبع المراجع (Xrefs) نقوم بالنقر نقراً مزدوجاً على نص Enter the password، فينقلنا IDA إلى الواجهة التالية:\nشكل (8): موقع نص Enter the password في التفكيك\nكما ظاهر أمامنا، نرى نصّي الصحة والخطأ، ويبدو أن هناك مصفوفة (Array) وكما هو متوقع تكون هي كلمة السر. ولكن نلاحظ أن IDA لا يتعرف على كامل المحارف — لذلك غالباً يوجد تشفير بسيط.\nالآن، نقوم بالنقر على النص aYouAreSuccess:\nشكل (9): النص aYouAreSuccess\nثم نضغط على X لتظهر لنا نافذة المراجع المتقاطعة (Xrefs):\nشكل (10): نافذة الـ Xrefs\nنضغط OK، فيرسلنا IDA إلى الدالة: loc_40104D:\nشكل (11): دالة التحقق loc_40104D\n5. تحليل الخوارزمية كما هو واضح، يتم نقل المصفوفة التي يدخلها المستخدم — byte_402158 — إلى المسجل al، ثم يُطبَّق عليها عملية تشفير XOR بسيطة مع الرقم 0x7D، ويتم مقارنة الناتج مع المصفوفة التي ظهرت معنا سابقاً: byte_402140.\nنقوم بالنقر مرتين على المصفوفة byte_402140:\nشكل (12): بيانات المصفوفة byte_402140\nنقوم بنسخ بيانات المصفوفة بالكامل، ونستعين بأي نموذج ذكاء اصطناعي لإجراء عملية XOR بقيمة 0x7D مع بيانات المصفوفة، فيظهر لدينا نص واضح:\nbunny_sl0pe@flare-on.com\nنقوم بتجربته:\nشكل (13): التحقق من صحة كلمة السر\nوهكذا نكون تمكنا من حل التحدي بالكامل، ونستمر إن شاء الله.\n","permalink":"https://outofsrvc.github.io/ar/posts/flare-on15-1/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eفي هذا المقال، سوف نحل التحدي الأول من تحديات \u003cstrong\u003eFlare-On (2015)\u003c/strong\u003e. سنعتمد كما هو معتاد على منهجية التعلم بالممارسة (Learning-by-Doing) ونهج التعلم في الوقت المناسب (Just-in-Time Learning).\u003c/p\u003e\n\u003ch2 id=\"1-تحميل-التحدي-وتشغيله\"\u003e1. تحميل التحدي وتشغيله\u003c/h2\u003e\n\u003cp\u003eأولاً، نقوم بتحميل التحدي من الموقع الرسمي: \u003ca href=\"https://flare-on.com/\"\u003eflare-on.com\u003c/a\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eكلمة سر الملفات: \u003cstrong\u003eflare\u003c/strong\u003e.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eبدايةً، نقوم بتشغيل الملف الظاهر أمامنا:\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"تشغيل الملف لأول مرة\" decoding=\"async\" loading=\"lazy\" src=\"/assets/img/flareon15/run1.png\"\u003e\n\u003cem\u003eشكل (1): تشغيل الملف لأول مرة\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eنقوم بنسخ المسار المحدد الذي سنضع فيه ملف التحدي:\u003c/p\u003e","title":"Flare-On 2015: حل التحدي الأول"},{"content":"بسم الله الرحمن الرحيم.\nفي هذا المقال، سوف نحل التحدي الأول من تحديات Flare-On (2014). سنعتمد في هذا الحل — وفي غالبية التحديات القادمة — على منهجية التعلم في الوقت المناسب (Just-in-Time Learning) أو ما يُعرف بالتعلم بالممارسة (Learning-by-Doing).\nلماذا بدأنا بتحديات Flare-On؟ لأن هذه التحديات مبنية على تقنيات واقعية من العالم الحقيقي (Real-World)، وليست مجرد تحديات CTF مصطنعة تُقدَّم عادةً في المسابقات.\nملاحظة مهمة: تحديات الـ CTF هي فقط جسرٌ بين التعلم النظري والتطبيق العملي، ولا تدل بأي شكل من الأشكال على أنك شخص قوي في المجال. الخبرة الحقيقية تُكتسب من التعامل مع البرامج الواقعية (Real-World) — سواء كانت برمجيات خبيثة (Malware) أو ألعاباً أو برامج نقوم بهندستها عكسياً.\nأي اقتراح لتطوير هذه المقالات، أو أي خطأ، أو أي استفسار، فالتواصل معي متاح دائماً إن شاء الله.\nإن أحسنت فمن الله، وإن أسأت فمن نفسي والشيطان.\n1. تحميل التحدي والفحص الأولي أولاً، نقوم بتحميل التحدي من الموقع الرسمي: flare-on.com\nكلمة سر الملفات: إما flare أو infected.\nبدايةً، نقوم بفحص البرنامج بأداة Detect It Easy (DIE) لنعرف معلومات عنه، فنحصل على المعلومات التالية:\nشكل (1): معلومات الملف كما تظهرها أداة DIE\nكما هو واضح، إنه برنامج بصيغة PE32 ومكتوب بلغة C#.\n2. أساسيات مهمة عن برامج .NET قبل البدء بالحل، من الضروري أن نعرف بعض المعلومات عن برامج .NET، لأنها تختلف تماماً عن برامج C/C++.\nبرامج C/C++ عند كتابة برامج بلغة C/C++، نستخدم مترجماً (Compiler) مثل GCC. يمر البرنامج بمرحلتين بشكل مختصر:\nالترجمة المباشرة (Ahead-of-Time Compilation): يأخذ المترجم الكود المصدري (Source Code) ويحوّله مباشرة إلى كود الآلة (Machine Code). الربط (Linking): يتم دمج المكتبات الخارجية مع الكود ليصبح ملفاً تنفيذياً (.exe). برامج C# (.NET) بينما تمر برامج C#/.NET بعملية مختلفة يمكننا تسميتها البرمجة المُدارة (Managed Code): لا تُترجم برامج .NET مباشرة إلى لغة الآلة، بل تمر بمرحلتين وتعمل داخل بيئة تشغيل تُسمى CLR - Common Language Runtime.\nالمرحلة الأولى: وقت الترجمة (Compile Time)\nعند عمل Build لبرنامج C#، لا يتم تحويله إلى لغة آلة مباشرة، بل يحدث التالي:\nيقوم مترجم .NET (مثل Roslyn) بتحويل الكود إلى وسيطة تُسمى IL - Intermediate Language، وهي لغة تشبه لغة التجميع (Assembly) لكنها غير مرتبطة بمعمارية معالجة (CPU Architecture) معينة. يتم تجميع هذا الكود الوسيط مع البيانات الوصفية (Metadata) داخل ملف Assembly بامتداد .dll أو .exe. يمكن أخذ هذا الملف نفسه وتشغيله على لينكس وويندوز وماك. المرحلة الثانية: وقت التشغيل (Runtime)\nعند فتح البرنامج، يتدخل الـ CLR (محرك تشغيل .NET):\nيقرأ الـ CLR ملف الـ Assembly الذي يحتوي على الـ IL. يستخدم مترجماً يُسمى JIT - Just-in-Time Compiler. يقوم الـ JIT بتحويل الـ IL إلى لغة الآلة الأصلية (Native) في نفس لحظة تشغيل البرنامج، ويحوّل فقط الأجزاء التي يحتاجها البرنامج في تلك اللحظة. 3. تشغيل البرنامج وملاحظة السلوك نقوم بتشغيل البرنامج (Run) لنلاحظ سلوكه:\nشكل (2): الواجهة الأولية للبرنامج\nكما هو واضح في الصورة، توجد شخصية مكتوب فوقها \u0026ldquo;Let\u0026rsquo;s start with something easy!\u0026quot;، وأسفلها زر Decode. عند الضغط عليه، تتغير الصورة وتظهر بالشكل التالي:\nشكل (3): الواجهة بعد الضغط على زر Decode\nكما هو مبين، تظهر الفروق بوضوح في الصورة. المطلوب منا هنا هو معرفة النص المشفر الظاهر في الصورة.\n4. التفكيك باستخدام ILSpy كما أوضحنا أعلاه كيفية ترجمة برامج .NET، فإن هذا يسهل علينا الكثير من الأمور، مثل العمل على مُفكِّك (Decompiler) مع التأكد من أن الكود الذي يُخرجه هو نفسه الكود الأصلي. لذلك سنستخدم مُفكِّك ILSpy للتعامل مع هذا البرنامج.\nشكل (4): فتح البرنامج داخل ILSpy\nبما أن أمامنا نافذة (Form)، سنركز على الموارد (Resources) الموجودة داخلها:\nشكل (5): الموارد الموجودة داخل الـ Form\nكما هو واضح، يوجد ثلاثة ملفات، وأحدها مشبوه لأنه يحمل اللاحقة .encode، وهذا شيء يتعلق بالتشفير.\nالآن، ننتقل إلى المنطق الأساسي (Core Logic) الذي يحتوي على خوارزمية التشفير، ولذلك نبحث في كود الـ Form:\nشكل (6): استعراض كود الـ Form\nيظهر لنا الكود التالي:\nشكل (7): الكود الذي يظهر في نافذة ILSpy\nدالة btnDecode_Click: هذا النمط هو كود زر Decode (ماذا يحدث عند الضغط عليه):\nأولاً، تُستبدل الصورة بصورة اسمها bob_roge. يُعرّف مصفوفة بايتات اسمها dat_secret — وهي نفسها الموجودة في الـ Resources — وغالباً ما تكون هذه المصفوفة هي النص الأصلي الذي يتم تشفيره. تُطبَّق خوارزمية التشفير. هنا نلاحظ استخدام ما يُسمى بالتمويه (Obfuscation). سنركز فقط على المتغير text والخوارزمية المرتبطة به:\nشكل (8): الخوارزمية في الكود بعد إزالة التمويه\nتتألف الخوارزمية من تبديل الأنصاف (Nipple Swap) وعملية XOR:\nNipple Swap: مثلاً، إذا كان لدينا البايت 0011 1100، بعد تطبيق عملية التبديل عليه يصبح 1100 0011؛ أي أنه يقوم بتبديل النصف الأيمن بالنصف الأيسر. بعد التبديل، يقوم بعملية XOR مع القيمة 0x29. وما تبقى من الكود نتجاهله.\n5. كتابة سكريبت الحل (Solver) الآن، نقوم بتصدير ملف dat_secret من الـ Resources:\nشكل (9): تصدير ملف dat_secret\nسنطلب من أي نموذج ذكاء اصطناعي كتابة سكريبت بايثون (Solver) لفك تشفير ملف dat_secret:\ndef decode_dat_secret(file_path): try: with open(file_path, \u0026#39;rb\u0026#39;) as f: dat_secret = f.read() except FileNotFoundError: print(\u0026#34;لم يتم العثور على الملف. تأكد من أن ملف \u0026#39;dat_secret\u0026#39; موجود في نفس المسار.\u0026#34;) return None text = [] for b in dat_secret: # (b \u0026gt;\u0026gt; 4) يجلب الجزء العلوي (High Nibble) # ((b \u0026lt;\u0026lt; 4) \u0026amp; 0xF0) يجلب الجزء السفلي (Low Nibble) ويرفعه للأعلى dec_val = ((b \u0026gt;\u0026gt; 4) | ((b \u0026lt;\u0026lt; 4) \u0026amp; 0xF0)) ^ 0x29 if dec_val == 0x00: # توقف عند المحرف الفارغ (Null Terminator) break text.append(chr(dec_val)) return \u0026#34;\u0026#34;.join(text) if __name__ == \u0026#34;__main__\u0026#34;: file_name = \u0026#34;dat_secret\u0026#34; # ضع مسار الملف هنا result = decode_dat_secret(file_name) print(\u0026#34;--- النص بعد فك التشفير ---\u0026#34;) print(result) يجب التأكد من أن ملف البايثون في نفس مسار ملف dat_secret.\nنقوم بتشغيل سكريبت البايثون:\nشكل (10): النص بعد فك التشفير\nوبهذا نكون قد أنهينا حل التحدي بنجاح، ونستمر إن شاء الله.\n","permalink":"https://outofsrvc.github.io/ar/posts/flare-on-14-1/","summary":"\u003cp\u003eبسم الله الرحمن الرحيم.\u003c/p\u003e\n\u003cp\u003eفي هذا المقال، سوف نحل التحدي الأول من تحديات \u003cstrong\u003eFlare-On (2014)\u003c/strong\u003e. سنعتمد في هذا الحل — وفي غالبية التحديات القادمة — على منهجية التعلم في الوقت المناسب (Just-in-Time Learning) أو ما يُعرف بالتعلم بالممارسة (Learning-by-Doing).\u003c/p\u003e\n\u003ch2 id=\"لماذا-بدأنا-بتحديات-flare-on\"\u003eلماذا بدأنا بتحديات Flare-On؟\u003c/h2\u003e\n\u003cp\u003eلأن هذه التحديات مبنية على تقنيات واقعية من العالم الحقيقي (Real-World)، وليست مجرد تحديات CTF مصطنعة تُقدَّم عادةً في المسابقات.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eملاحظة مهمة:\u003c/strong\u003e تحديات الـ CTF هي فقط جسرٌ بين التعلم النظري والتطبيق العملي، ولا تدل بأي شكل من الأشكال على أنك شخص قوي في المجال. الخبرة الحقيقية تُكتسب من التعامل مع البرامج الواقعية (Real-World) — سواء كانت برمجيات خبيثة (Malware) أو ألعاباً أو برامج نقوم بهندستها عكسياً.\u003c/p\u003e","title":"Flare-On 2014: حل التحدي الأول"},{"content":"أنا P01NT (@outofsrvc)، باحث تقني ومختص في الهندسة العكسية وتحليل البرمجيات الخبيثة والأنظمة منخفضة المستوى (Low-Level Systems).\nأركز على تفكيك الملفات التنفيذية (PE Format)، تحليل التشفير للبرمجيات الخبيثة، ودراسة سلوك الأنظمة. أنشأت ورشة Entry P01NT لتبسيط مفاهيم الهندسة العكسية وتفكيك التجميع (Disassembly). كما قمت بنشر العديد من المقالات التقنية التي تجاوزت 10,000+ مشاهدة على شبكة شل العربية (Arab Shell Network).\nهذه المدونة هي المكان الذي أُدوّن فيه ما أتعلّمه: مقالات تقنية، تحليلات، وورشة تعليمية كاملة.\nورشة Entry-P01NT الجزء الأكبر من هذا الموقع هو ورشة Entry-P01NT — مبادرة تعليمية مفتوحة المصدر تهدف إلى تبسيط الهندسة العكسية وتحليل البرمجيات الخبيثة باللغة العربية، وتقليل الفجوة بين المعرفة النظرية والتطبيق العملي.\nبُنيت الورشة لتكون الجسر الذي يعبر بك من المعرفة السطحية بالبرمجة إلى الفهم العميق لكيفية عمل الأنظمة، وكيف تتحدث البرمجيات مع العتاد ونظام التشغيل بلغة الآلة. أهدافها باختصار:\nكسر حاجز الخوف من لغة التجميع (Assembly) وأدوات التحليل المعقدة. توفير بيئة تطبيقية (Labs) للتعلم من خلال التجربة والخطأ. بناء عقلية \u0026ldquo;المهندس العكسي\u0026rdquo; الذي لا يكتفي بمعرفة كيف يعمل البرنامج، بل لماذا يعمل بهذا الشكل. صمّمتُ الورشة كخلاصة لرحلتي في التعلم، لتكون المرجع الذي تمنيت وجوده عندما بدأت.\nالتواصل والمساهمة مستودع الورشة مفتوح للجميع على GitHub، ويسعدني استقبال مقترحاتكم وتصحيحاتكم.\nGitHub: @outofsrvc Twitter/X: @outofsrvc Telegram: @outofsrvce \u0026ldquo;الكود لا يكذب، الوثائق قد تكذب\u0026rdquo; — مجهول\n","permalink":"https://outofsrvc.github.io/ar/about/","summary":"\u003cp\u003eأنا \u003cstrong\u003eP01NT\u003c/strong\u003e (\u003ca href=\"https://github.com/outofsrvc\"\u003e@outofsrvc\u003c/a\u003e)، باحث تقني ومختص في الهندسة العكسية وتحليل البرمجيات الخبيثة والأنظمة منخفضة المستوى (Low-Level Systems).\u003c/p\u003e\n\u003cp\u003eأركز على تفكيك الملفات التنفيذية (PE Format)، تحليل التشفير للبرمجيات الخبيثة، ودراسة سلوك الأنظمة. أنشأت ورشة \u003cstrong\u003eEntry P01NT\u003c/strong\u003e لتبسيط مفاهيم الهندسة العكسية وتفكيك التجميع (Disassembly). كما قمت بنشر العديد من المقالات التقنية التي تجاوزت \u003cstrong\u003e10,000+ مشاهدة\u003c/strong\u003e على \u003ca href=\"https://sh3ll.cloud/xf2/members/4161/\"\u003e\u003cstrong\u003eشبكة شل العربية (Arab Shell Network)\u003c/strong\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eهذه المدونة هي المكان الذي أُدوّن فيه ما أتعلّمه: مقالات تقنية، تحليلات، وورشة تعليمية كاملة.\u003c/p\u003e","title":"عني"}]