كيف احمى برامجى؟

اخي الفاضل لقد ارفقت لك الاداه

activeLock 1.8-and2.1

ومعهم مثالين

ارجو ان تقرا الموضوعين ستجد ما يفيدك

http://204.157.36.16/index.php?showtopic=70729 راجع هذا الموضوع, هناك مشاركة للاخ hichamchak ارفق فيها ملف فيه شفرة لبرنامج يقوم بارجاع معلومات كثيرة من الاجهزة المضمنة والمتصلة بالحاسب يمكنك الاستفادة منها في الحصول على معلومات خاصة فقط بكل جهاز يعمل عليه البرنامج.

لكن في النهاية اقرا الموضوع فهو يحوي على معلومات مفيدة بشان الحماية. بخصوص الاداة التي تكلم عنها الاخ يمكنك تحميلها من الموضوع التالي:

http://204.157.36.16/index.php?showtopic=8...39entry452639

لكني باي حال ساقوم بتحميلها واختبار فعاليتها في حماية البرامج من القرصنة, بقرصنتها وقرصنة البرنامج نفسه!

Xacker كتب:

http://204.157.36.16/index.php?showtopic=70729 راجع هذا الموضوع, هناك مشاركة للاخ hichamchak ارفق فيها ملف فيه شفرة لبرنامج يقوم بارجاع معلومات كثيرة من الاجهزة المضمنة والمتصلة بالحاسب يمكنك الاستفادة منها في الحصول على معلومات خاصة فقط بكل جهاز يعمل عليه البرنامج.

لكن في النهاية اقرا الموضوع فهو يحوي على معلومات مفيدة بشان الحماية. بخصوص الاداة التي تكلم عنها الاخ يمكنك تحميلها من الموضوع التالي:

http://204.157.36.16/index.php?showtopic=8...39entry452639

لكني باي حال ساقوم بتحميلها واختبار فعاليتها في حماية البرامج من القرصنة, بقرصنتها وقرصنة البرنامج نفسه!

←

تقديري للحماية هو: صفر ! (for extremely newbies)

يمكن تجاوز حماية تعطيل الخيارات في البرنامج بسهولة مطلقة النظير.

لم اتمكن من التحقق من قدرته على حماية البرنامج ضد تغيير الوقت وما شابه.. لكن قمت بالاطلاع على الـ keygen المزود من قبل الشركة نفسها.. واستطيع التاكيد ان الاجرائيات التي رايتها الخاصة بتوليد السيريال وفقا للحماية المخصصة لا تبشر ببيع نسخة واحدة من البرنامج!

اتمنى لو يقوم احدكم باخذ القليل من وقته لمحاولة (تحسين) استخدام الحماية المزودة من قبل الاداة لنرى ما فعاليتها في وجه القرصنة!

في المرفقات ملف باتش للتاكيد على ان البرنامج بالفعل تم تفعيل خصائصه.

patch.zip

شكرااااااااااااااااا علي مجهودك علي اي حال

وياريت توضح لنا نقاط الضعف

واي الادوات التي تم عليها التجربة

انا لم استطيع تحميل الباتش الذي ارفقتة نظرا لاني من صعوبة التحميل في المنتدي

ونقاط الضعف بالتفصيل

لعنا نتوصل لحماية فعلية لبرامجنا العربية او علي الاقل تعطيل كسر الحماية لمده معينة

واري من وجهة نظري ان الموضوع يخص الجميع فعلنا المشاركة حتي لو بابداء الرايء

وعلي اي اخي xacker

لنا لا اختلف معك في شيء نحن فريق واحد يجيب ان نتكاتف ومسالة الحماية ليست بالامر السهل

واطلب من الاخوه الاعضاء المشاركة لان مسألة حماية البرامج موضوع معقد للغاية

واشكركم جمعيا

الضعف في حماية تلك الاداة يرتكز على نقطة هامة جدا, المشكلة في حماية التطبيقات البرمجية هي سلسلة الثقة trust chain بين التطبيق والنظام, فالمبرمج عندما يكتب برنامجك يتوقع ان يقوم البرنامج بالعمل الفلاني (ولنقل التحقق من الحماية) ناسيا انه على طول سلسلة الثقة تلك هناك حلقات ضعيفة لا يمكن التخلص منها لان النظام نفسه مبني عليها!

لتوضيح ما اقصده دعني اعطي مثال ما, لديك شبكة فيها عدة اجهزة, ملقم (مخدم server) وعدة عملاء, على الشبكة عندما يطلب احد العملاء خدمة استخدام الطابعة من المخدم فانه يرسل اليه طلبا يحوي هذا الطلب على نوع الخدمة المطلوبة وعنوان او اسم العميل الذي يحتاج الى هذه الخدمة اضافة الى معلومات اخرى لسنا في صدد الحديث عنها.. هذا الطلب عندما يستلمه المخدم فانه لا يقوم بالتحقق منه.. هو لا يحتاج الى ان يتحقق منه, "هذا مجرد طلب خدمة طابعة من العميل X".. "هل احتاج الى التحقق من الطلب؟ لا .. لماذا اريد ذلك بالاصل!".. "حسنا, الطابعة جاهزة, يمكنك استخدام الطابعة ايها العميل".. "X: شكرا!".. "المخدم: اه بما انه شكرني فهو بالطبع X .. لا اعلم لم كنت قلقا الى هذه الدرجة p:"

ضمن هذه الحلقة السابقة هناك نقطة ضعف, اولا المخدم لم يتحقق من كون الخدمة مرسلة من قبل X الا عندما وصلته رسالة الشكر.. افترض على اساسها ان الطلب حقيقي وانه قام بعمله وارسل الاوكيه ورد عليه العميل X

في الشبكات وجدت بعض النفوس الضعيفة (التي اوجه لها تحية حارة, Xero if you ever learnt arabic :P) طريقة لتمويه الطلب.. فاوجدوا ما يسمى هجوم Man-in-the-Middle والذي يقوم به المهاجم باعتراض طلب يجري عبر شبكة, يوجه هذا الطلب الى تطبيق قام هو بكتابته, يقوم هذا التطبيق باخذ معلومات ما ضرورية للمهاجم, من ثم يقوم باعادة ارسال الطلب مرة اخرى الى وجهته الصحيحة.. عندما يعود الطرف الثاني بالرد فالتطبيق يستلم الحزمة مرة اخرى.. يفلتر الرد, ثم يرسله مرة اخرى الى مرسل الطلب.. المهاجم يستطيع في هذه الحالة ان يقوم بتمويه الطلب, فيقوم بتحويل بعض الطلبات الى طلبات اخرى! او قد يقوم بتمويه هويته ليظهر نفسه على انه مخدم او عميل! فهو يظهر لكل طرف كما يريد!

نعود الى موضوعنا الاساسي, التطبيق عندما يقوم بالوصول الى الاجرائية التي تقوم بالتحقق من الحماية فانها تقوم بطلب بعض الدوال وتقوم بتنفيذ الكود الموجود لديها.. التطبيق يفترض سلفا انه عندما يقوم بطلب MessageBox او rtcMsgBox (في تطبيقات الفيجوال) فانه يقوم بطلب هذه الدالة من النظام نفسه.. ويفترض ان النظام قام بعرض البيانات التي يريدها كما طلب ويفترض ان النظام اعاد التحكم اليه مع رسالة "done!"

التطبيق لا يتحقق مما اذا قام احدهم باعتراض هذا الطلب وتغييره قبل ارساله الى النظام.

التطبيق لا يقوم بالتحقق مما اذا قام احدهم بتعديل بعض بياناته لتنفيذ اجزاء اضافية او اجزاء اخرى من الكود (CRC? yeah sure!).

النظام يفترض ان الطلب المرسل اليه مرسل من قبل التطبيق نفسه وانه لم يتم اعتراضه.

النظام لا يقوم بالتحقق ممن ارسل الطلب, هو فقط يعلم ان X ارسل الطلب وانه قام بتنفيذ الطلب كما وصلته التعليمات وانه ابلغ X بانه قام بتنفيذ ما طلب.

هنا تكمن الحلقة الضعيفة ولو كنت تريد الحقيقة, هناك الكثير من المناطق العرضة للهجوم.. ليس في الحمايات التي تقومون بكتابتها.. وانما في سلسلة الثقة بين التطبيق -> المستخدم (المهاجم لو اردت) -> النظام

(بالمناسبة, في الصورة السابقة خطا بسيط فلا حاجة لـ pop var_real / pop var_fake .. لكن عندما انتبهت اليها كان الاوان قد فات على تعديل الصورة :P)

لذلك الحماية الجيدة هي الحماية التي تقوم بالغاء نقاط الضعف تلك في سلسلة الثقة... واي حماية ستكون :-s

Xacker