- بواسطة x32x01 ||
org 100h في Assembly - إيه هو وفايدته؟ 
أمر org 100h في لغة التجميع (Assembly) بيستخدم علشان نحدد مكان بداية الكود في الذاكرة.القيمة 100h بالهيكس تمثل 256 بالنظام العشري - وده العنوان التقليدي اللي بيبتدي منه كود ملفات الـ .COM في نظام DOS بعد ما يتحمّل البرنامج.
لو حبينا نبسط الصورة: الذاكرة زي رفوف مكتبة - كل رف ليه رقم. أمر org 100h بيقول للمجمّع (assembler): "البرنامج إبتداءًا هنا - من الرف رقم 256." لما الكومبايلر يجهّز الملف، عشان لما ينزل في الذاكرة، العناوين الداخلية تبقى مظبوطة ويبقى الكود ينفّذ من المكان الصح.
مثال مبسّط خطوة بخطوة 
نفترض إن عندنا جزء كود صغير بالأسيمبلي: Code:
org 100h
MOV AX, 100h
MOV BX, 200h
ADD AX, 50h
INC AX- org 100h → يحدّد أن العنوان الابتدائي للكود هو 0x100 (يعني 256).
- MOV AX, 100h → ينقل القيمة 0x100 إلى السجل AX.
- MOV BX, 200h → ينقل القيمة 0x200 إلى السجل BX.
- ADD AX, 50h → يضيف 0x50 إلى AX (256 + 80 = 336).
- INC AX → يزيد AX بواحد (يبقى 337).
طيب.. هل الكود ده خطر؟ وإزاي ممكن هاكر يستغله؟ 
لو خدنا الكود لوحده - هو مش خطر، مجرد عمليات حسابية. لكن في عالم الاختراق، السياق هو اللي يهم. لو الهاكر قدر يوصل لتشغيل أي أكواد في برنامج حساس (باستغلال ثغرة RCE أو تحميل ملف .COM خبيث)، ممكن يستخدم تعليمات Assembly شبيهة كجزء من سلسلة أوامر أكبر لتحقيق أهداف ضارة. شوية سيناريوهات:سيناريوهات استغلال محتملة
- تغيير مؤشرات حساسة: لو الكود يغيّر عناوين أو offsets اللي البرنامج يعتمد عليها، ممكن يخرب بيانات أو يغيّر سلوك البرنامج.
- التحويل لتنفيذ أوامر نظامية: جزء Assembly بسيط ممكن يتطور لسلسلة تعليمات بتستدعي دوال نظامية (مثل استدعاء syscall أو INT 21h في DOS) لتنفيذ أوامر ضارة.
- جزء من Payload: الكود ممكن يكون جزء من payload أكبر ينفّذ بعد استغلال ثغرة بما يتيح سرقة بيانات أو رفع صلاحيات.
أمثلة عملية لأسلحة الهاكر
- تحميل ملف .COM ملوّث على سيرفر قديم يعمل DOS أو محاكاة DOS، وتشغيله من دون تحقق.
- استغلال ثغرة تسمح بكتابة قيم في الذاكرة (memory corruption) ثم قفز التنفيذ (EIP/RIP) إلى كود جاهز يبدأ من عنوان محدد (مثلاً 0x100 في بيئة معينة).
إيه الأضرار اللي ممكن تحصل؟ 
- تلف البيانات: التغييرات على السجلات أو الذاكرة ممكن تؤدي لمسح أو تلف قواعد البيانات أو ملفات النظام.
- تشغيل أوامر ضارة: مثل حذف ملفات، تشفير بيانات (ransomware)، أو فتح أبواب خلفية (backdoors).
- الرفع غير المرغوب في الصلاحيات: تنفيذ كود في وضع أعلى ممكن يتيح للهاكر سلطات أكبر على النظام.
إزاي تحمي نفسك وتقلّل المخاطر؟ 
لو إنت مطور أو مسؤول نظام، شوف شوية إجراءات وقائية عملية:التحكم في مصادر الكود والتحميل
- ما تسمحش بتحميل أو تشغيل ملفات تنفيذية من مصادر غير موثوقة.
- فعّل فحص المحتوى (content scanning) وقيود الرفع (upload restrictions) على التطبيقات.
الحد من إمكانية تنفيذ الأكواد العشوائية
- طبّق ممارسات Least Privilege: المستخدمين والعمليات يكون لهم أقل صلاحيات لازمة.
- عزل البيئات: شغّل العمليات الحساسة في حاويات أو VMs مع شبكات معزولة.
تحديث وصيانة الأنظمة
- حدّث أنظمة التشغيل والمكتبات دوريًا لتقليل احتمال وجود ثغرات استغلال.
- إغلاق واجهات قديمة (legacy services) خصوصًا اللي بتعمل محاكاة DOS أو بتدعم تشغيل ملفات .COM.
المراقبة والكشف المبكر
- فعل logging لرصد محاولات تحميل أو تنفيذ ملفات مش معروفة.
- استخدم أنظمة كشف التسلل (IDS/IPS) وفحص سلوك التطبيقات.
التكويد الآمن وفحص المدخلات
- لو تطبيقك يتعامل مع ملفات تنفيذية أو معطيات ثنائية، اعمل فحص (validation) صارم قبل قبول أي تحميل أو تنفيذ.
- تجنّب قبول مدخلات تمكن المهاجم من التحكم بعناوين الذاكرة أو سجلات المعالج.
خلاصة سريعة 
- org 100h مجرد توجيه للمجمّع يحدد عنوان بداية الكود (0x100).
- التعليمات التجميعية البسيطة لوحدها ليست ضارة، لكن في سياق خاطئ ومع فرصة تنفيذ عشوائي، قد تدخل ضمن سلسلة استغلال.
- أفضل وقاية: التحكم في مصادر الملفات، تحديث الأنظمة، تقييد الصلاحيات، ومراقبة السلوك.
التعديل الأخير: