KILLER CODE
رفتن به کانال در Telegram
اطلاعاتی وجود ندارد
مشترکین
-224 ساعت
-187 روز
+25330 روز
آرشیو پست ها
مشروع CallStackSpoofer الموجود على GitHub هو أداة متخصصة في التلاعب بالـ Call Stack الخاص بالتطبيقات أثناء تشغيلها وهو جزء مهم جدًا لأي هكر سواء وايت هات أو بلاك هات وخصوصًا عندما نتكلم عن الهجمات المتقدمة زي APT الهجمات دي تعتمد على البقاء مختفيًا أطول فترة ممكنة داخل النظام والابتعاد عن أعين الـ EDR أو أنظمة كشف التهديدات الحديثة الفكرة الرئيسية للأداة هي أنها بتوفر إمكانية تعديل وإخفاء مسارات الاستدعاء Call Stack بحيث تجعل تتبع النشاط الضار أو تحليل البرامج الضارة أصعب بكتير على المحللين الأمنيين أو الأنظمة الدفاعية ولو حبينا نبسط ده فالأداة بتشتغل على التلاعب بمسارات الأكواد اللي بتشتغل داخل النظام بحيث لو حد حاول يحلل الأداة أو العملية الخبيثة اللي شغالة مش هيقدر يكتشف مكانها بسهولة
الأداة بتشتغل بشكل أساسي من خلال استغلال قدرة البرامج على التحكم في مسار التشغيل runtime execution flow وده من خلال تقنيات زي الـ ROP Ret2Libc أو أي تقنيات مشابهة الهدف الأساسي هنا هو إنه يكون عندك قدرة إنك تبني كود خبيث ومش يظهر في أي تحليل إنه خبيث يعني لو حد بيراقب النظام مش هيشوف النشاط ده في الـ Logs أو في الأدوات اللي بتحلل المسارات
لو بنتكلم عن بلاك هات هكر وفايدة الأداة بالنسبة لهم فهي هتكون أداة قوية جدًا عشان يدمجها في أي حملة اختراق متقدمة على سبيل المثال لو هنتكلم عن استغلال الثغرات Exploits اللي بتحتاج تحكم كامل في النظام الأداة دي ممكن تساعد في جعل التحليل الجنائي شبه مستحيل لأن مسارات الاستدعاء Call Stack كلها متغيرة ولو حد حاول يعمل Debugging أو حتى يقرأ معلومات من الـ Memory مش هيلاقي حاجة واضحة الفكرة هنا إنك بتخلق مستوى من الغموض حول العملية اللي شغالة كأنك بتمحي بصمتك
من ناحية الأفكار اللي ممكن يضيفها البلاك هات على المشروع ممكن مثلًا يدمج تقنيات زي الـ Process Hollowing أو الـ DLL Injection مع الأداة بحيث تشتغل بشكل غير مباشر في النظام يعني بدل ما يكون فيه عملية وحدة مسؤولة عن كل حاجة الأداة ممكن تشتغل كجزء صغير داخل كذا عملية منفصلة وده هيزود التمويه أكتر كمان يمكن استخدام الأداة لتطبيق هجمات متقدمة زي الـ Thread Hijacking اللي بتسمح لك تسيطر على ثريد شغال بالفعل وتعدل مساره بدون ما النظام يحس
لما نتكلم عن هجمات APT Advanced Persistent Threat فاستخدام الأداة بيكون محورى لإنها بتديك قدرة إنك تفضل داخل النظام لفترة طويلة بدون كشفك يعني ممكن تستخدمها في جمع البيانات الحساسة زي كلمات المرور أو بيانات الشبكة لفترة طويلة بدون ما أي حد يلاحظ ولو عايز تطورها أكتر ممكن تضيف لها قدرة تحليل تلقائي للسيرفرات اللي بتهاجمها بحيث تتعرف الأداة تلقائيًا على البرامج اللي شغالة فيها وتعدل Call Stack الخاص بها بناءً على طبيعة البرنامج المستهدف
أي حد بيستخدم الأداة سواء في الاختراق أو الحماية محتاج يكون فاهم كويس جدًا إن تقنيات زي دي بتخلي التحليل العكسي عملية صعبة لكن مش مستحيلة لأن في تقنيات حديثة زي الـ AI-Based Threat Detection اللي بتشتغل على تحليل السلوك Behavior Analysis مش مجرد تحليل الأكواد والـ Call Stack وده بيخلي الحاجة لتطوير الأداة بشكل مستمر أمر مهم عشان تفضل خطوة قدام أنظمة الحماية
رابط المشروع على جيت هوب
لمزيد من المعلومات عن الموضوع
#Udemy | Red Teaming | Exploit Development with Assembly and C |MSAC+
Info: https://www.udemy.com/course/shellcode/
@Hide01 📰
@RedBlueHit 💀👀
@RedBlueTM 🔒
مصدر المعلومات :
https://stackoverflow.com/questions/30190132/what-is-the-shadow-space-in-x64-assembly
https://en.m.wikipedia.org/wiki/X86_calling_conventions
https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170
https://stackoverflow.com/questions/74223182/how-to-know-number-of-parameters-in-x86-64-assemblewindows
https://cs61.seas.harvard.edu/site/2018/Asm2/
https://devblogs.microsoft.com/oldnewthing/20160623-00/?p=93735
https://sonictk.github.io/asm_tutorial/
https://www.ired.team/miscellaneous-reversing-forensics/windows-kernel-internals/linux-x64-calling-convention-stack-frame
الكود ده بيتكلم عن دالة مكتوبة بلغة الاسمبلي في بيئة 64 بت وبتوضح ازاي تتعامل مع Parameters وقت استدعاء الدوال طبقاً لتواغبقك الاستدعاء المستخدمة في الأنظمة الحديثة زي ويندوز أو لينكس حيث يتم التعامل مع أول أربع Parameters للدالة باستخدام الريجيسترات RCX وRDX وR8 وR9 و قتها بيتم وضع باقي Parameters على الستاك وقت تنفيذ التعليمات بحيث يتم تحديد موقع كل Parameter عن طريق Offset بالنسبة للبوينتر RSP اللي هو مؤشر الستاك في وقت الاستدعاء ويظهر الكود بشكل واضح أن الـ Parameters الإضافية بتتواجد على الستاك مع وجود منطقة محجوزة تُسمى Shadow Space وهي عبارة عن مساحة مخصصة قبل تخزين الـParameters على الستاك ودي بتكون جزء من تنظيم الميموري اللي بيفرضه الويندوز API
الكود بيبدأ بتسمية الدالة "AsmFunc11Parms PROC" اللي هدفها الأساسي هو التعامل مع 11 Parameter حيث أول أربع Parameters بتكون موجودة في الريجيسترات المذكورة سابقاً بينما Parameters الخامسة والسادسة وما بعدها بتكون موجودة على الستاك عند Offsets محددة من RSP فمثلاً Parameter الخامسة موجودة عند Offset RSP+40 وParameter السادسة عند RSP+48 وبكده يتم الوصول للقيم دي من تعليمات زي MOV اللي بتقوم بنقل الداتا من الميموري إلى الريجيستر RAX بهدف استخدامها جوه الدالة
تعليمة MOV زي "MOV RAX, qword ptr [RSP + 40]" بتوضح بشكل صريح إن النظام بيقوم بتحميل القيمة الموجودة عند الإزاحة المحددة من الستاك إلى الريجيستر RAX وده بيديك القدرة على التعامل مع القيم مباشرة داخل الكود والدالة بتنتهي بتعليمة RET اللي بتعيد التحكم للكود اللي استدعى الدالة وده بيظهر أهمية تنظيم الذاكرة خلال عملية تنفيذ الكود
عشان نفهم أهمية الكود نركز على نقاط أساسية مثل كيفية استغلال توزيع المعلمات على الستاك خاصة في استدعاءات النظام Syscalls أو الدوال الخاصة بـAPI اللي بتحتاج معلمات كتير ده لأن أي خلل في ترتيب المعلمات أو تحديد مكانها بشكل خاطئ هيؤدي لنتائج غير متوقعة زي الكراش أو تنفيذ أوامر غير صحيحة كمان في سيناريوهات زي Buffer Overflow اللي بيتم فيها حقن تعليمات ضارة أو بيانات معينة في الستاك لفهم كيفية تخطي الحمايات أو السيطرة على مسار التنفيذ هنا بيظهر أهمية معرفة تفاصيل زي توزيع Parameters و Offsets الدقيقة
في تقنيات زي ROP اللي هي Return Oriented Programming اللي بتُستخدم لتجاوز الحمايات زي DEP أو ASLR لازم تبقى فاهم كويس جداً كيفية التعامل مع الريجيسترات والستاك لأنك حرفياً بتعيد ترتيب التعليمات اللي موجودة في البرنامج عشان تنفذ أوامر معينة وبتحتاج تتحكم في Parameters بدقة لإنجاح الـ EXPLOITده كمان فهمك للـShadow Space اللي هو جزء مهم من تنظيم الذاكرة بيساعدك تبني استغلالات أكتر تعقيداً خاصة إنه بيتم استخدامه بشكل أساسي لتخزين مؤقت للمعلمات الموجودة في الريجيسترات أثناء تنفيذ الدالة
لو حبينا نتكلم عن السيناريوهات العملية أكتر هنلاقي إن كتابة المالوير اللي بيتعامل مع استدعاءات النظام بشكل مباشر بيحتاج الفهم العميق للتوزيع ده لأن استدعاء أي دالة في النواة Kernel مثلاً بيستلزم تمرير Parameters بشكل صحيح سواء في الريجيسترات أو الستاك بالإضافة إن التعامل مع استدعاءات معقدة زي ZwQuerySystemInformation اللي بتحتاج كمية كبيرة من Parameters بيتطلب منك تحضير الستاك بشكل صحيح عشان التنفيذ يتم بدون مشاكل
اتفاقية الاستدعاء بتختلف حسب البيئة فلو بنتكلم عن linux environment بنلاقي إن التوزيع بيكون مشابه لكن مع تغييرات طفيفة في ترتيب الريجيسترات أو Offsets ولو دخلنا في بيئات متقدمة زي Visual Studio ممكن تلاقي حاجات مختلفة زي fastcall أو stdcall ودي بتغير كيفية تمرير الـ Parameters بين الريجيسترات والستاك وهنا تظهر الحاجة لفهم التفاصيل الدقيقة دي عند بناء برامج منخفضة المستوى أو استغلالات متقدمة
الكود ده مش مجرد مثال على التعامل مع المعلمات لكنه بيوضح أهمية معرفة التفاصيل الدقيقة في تنظيم الذاكرة أثناء تنفيذ التعليمات وبيبرز أهمية فهم المعمارية دي لأي هاكر أو مطور مالوير محترف لأنك كل ما عرفت أكتر عن العمليات اللي بتحصل في الخلفية كل ما قدرت تبني استغلالات أو أدوات أكتر تعقيداً وكفاءة
