الرئيسية      أرشيف المقالات       المنتدى        المكتبة       إتصل بنا
  القائمة الرئيسية
  Language
  تسجيل الدخول
اسم المستخدم :

كلمة المرور :

تذكرني



هل نسيت كلمة المرور ؟

اشترك الآن !
  بحث
  أقسام المقالات
  آخر المشاركات
  كتب جديدة
 
  زوار هذه الصفحة
اليوم 37
أمس 19
الإجمالي 28060
  الموقع

دلفي -  أفكار لجعل برامجك أصعب للكسر
بواسطة عروة عيسى في 2005/2/20 (8126 قراءة)
دلفي

أفكار لجعل برامجك أصعب للكسر

لا يمكن منع كسر البرامج بالنهاية , فحسب معلوماتي أن كبار شركات العالم لم تستطع تحقيق هذا الهدف .... ! , لذلك تبدو عبارة "جعل البرامج أصعب للكسر" أفضل من عبارة "حماية البرامج من الكسر" . فإذا كنا نصمم منتج برمجي ونريد تحقيق أولوية في مجال تأمين المنتج وزيادة حماية البرنامج من الهندسة العكسية والتعديل على الملف التنفيذي النهائي "بلغة الآلة" لجعلة يعمل متجاوزا أي من خيارات الحماية التي تم تزويد البرنامج بها . فهناك جملة من الأمور التي يمكن التفكير فيها , قد تكون مربكة وصعبة على المطور , ولكنها تصعب عمل المختصين في كسر البرامج أيضا , فإذا كانت الأولوية بهذه النقطة يمكن الاستفادة من بعض هذه الأفكار .
هذا قد لايكون كافي لحماية البرنامج , ولكنه مفيد في تصغير شريحة القادرين على القيام بهذا العمل و إستبعاد الهواة اللذين يكسرون البرامج من أجل اللهو والمتعة أو ضعيفي الخبرة في هذه العملية. باعتبار ان المحترفين مركزين وقتهم بكسر منتجات الشركات الكبرى .



بداية أود أن أنوه إلى نقطة أنه حتى البرامج المفتوحة المصدر , أو البرامج التي يمكن تنصيب إصدارات منها مجانا و التي لن تغوي الكراكرز بسهلوة , حتى هذه البرامج يمكن تحقيق الأرباح والفائدة منها . ويكمن السر في ذلك من الدعم الفني المتواصل , أو تقديم خدمات أخرى مكملة , أو جذب الزبون للتبرع أو لشراء نسخة مرخصة بجعلة يشعر بالأمان والاستقرار في حقة للحصول على آخر التحديثات والتطويرات مجانا بالاعتماد على النسخة المرخصة من المنتج . 
يمكن أيضا توفير إصدارة ميسرة من المنتج تكون بمثابة دعاية للمنتج ومن ناحية أخرى فرصة للمستخدم ليجرب المنتج بشكل مبسط ويعرف مزاياه العامة ومستواه ويمكن إظهار الخيارات الكاملة التي تكون موجودة في النسخة المدفوعة ولكن جعلها معطلة و لاتعمل (مجرد مظهر) وذلك لتذكير المستخدم بأنها موجودة بالنسخة الكاملة وتشويقة لشراء المنتج إذا بدء باستثمار النسخة المبسطة منه . 
على سبيل المثال تأمين نسخة مجانية ولنفترض لمشروع إدارة متجر , عندما يفتتح الكثيرمن الناس عملا سوف يبحثون على برامج له , وستكون البرامج المجانية فرصة مناسبة للبدء لإن العمل مازال صغير وفي بدايته والتكاليف كبيرة عند الإنطلاق , . يبدأ المستخدم بإدخال بياناته واستخدام البرنامج المجاني وهو يرى الخيارات التي يمكن أن يكون عليها البرنامج لو انه يدفع مبلغ من المال . بعد فترة يكبر العمل وتزيد الأرباح ويشعر المستخدم بحاجته للخيارات الكاملة للبرنامج والخدمات المتقدمة للمحاسبة والإحصائيات وغير ذلك . وبعد أن أدخل بياناته طوال الفترة الماضية على البرنامج وألف استخدامه واعتاد عليه هل سيفكر في برنامج جديد بالكامل ؟ أم أن الخيار الأمثل سيكون دفعه مبلغ صغير من المال مقابل توسيع ماهو موجود أصلا إلى المزايا الكاملة والإصدارات الأحدث .
يمكن حقن النسخة المجانية من المنتج ببعض الإزعاجات الصغيرة , مثل عرض انها نسخة مجانية في نافذة بدء المنتج وفي تقارير الطباعة وغير ذلك , التي تحفز الزبون أكثر للحصول على النسخة الكاملة .

غير ذلك يمكن اعتماد أسلوب التحديثات المستمرة للمنتج من الانترنت التي لاتعمل الا بوجود ترخيص للمنتج .

وبجميع الاحوال إذا كان تأمين المنتج ضد الكسر هو أولوية قصوى فهذه التدوينة تحوي بعض الأفكار التي يمكن أن تكون مفيدة , علما أنها ليست نصائح لقواعد كتابة برنامج صحيح بل بالعكس تماما فهي تعتمد على الإبتعاد عن الصيغ القياسية والتقليدية لقواعد كتابة البرنامج التي سوف يفترضها الكراكر قبل أن يبدأ بعملة .



-لا تستخدم أسماء ذات معنى للتوابع والإجرائيات الخاصة بالأمن إذا كنت مهتم بالحماية .
مثال : 

function RegistrationOKBoolean;



أعرف أن الأسماء التي تحمل معاني مفيدة جدا أثناء تطوير برنامج من أجل فهم البرنامج وتنقيحة لاحقا , ولكن إذا كنت مهتما بجعل برنامجك أصعب للكسر لا أنصحك أبدا بإستخدام أسماء توابع تدل على عملها , لإن ذلك سيجعل الهاكر يعرف الموقع الصحيح الذي عليه التركيز فيه عندما يفتح البرنامج في محرر ستعشري (يعرض كود الأسمبلي) , لإن اسماء التوابع الاستاتيكية سوف تخزن بشكل نصي ويمكن معرفة مكان كودها النهائي المترجم ضمن الشفرة الثنائية النهاية للملف التنفيذي . وهذا يعتبر نصف العمل بالنسبة للكراكر

-لا تضع رسالة نصية بعد كود التحقق .
كالتي تخبر أن كلمة المرور غير صحيحة , أو أن فترة الصلاحية أنتهت . 
لإنها ستخزن بشكل نصي في الملف التنفيذي النهائي ويمكن البحث عنها وتحريرها ومعرفة مكان كود التحقق منها , الهدف من ذلك هو أن لايعرف الكراكر كيف يجد كود التحقق ,
بالتأكيد لن يقوم الهاكر بتفحص 500 كيلوبايت مثلا من شفرة لغة التجميع Assimply لكي يعرف أين يوجد الجزء الخاص من الكود الذي يجب علية تعديلة لكسر كلمة مرورك . ولكنة سيجرب أولا إدخال كلمة عشوائية لكي يعرف ماهي رسالة-إعلام عدم سماحية كلمة المرور , ويترقب الرسالة الناتجة , والتي تكون مخزنة بصيغة نصية في الملف التنفيذي ويسهل العثور عليها , ثم يبحث عنها في شفرة الآلة لملفك التنفيذي , وبالتأكيد هذا هو الجزء من الشفرة الذي يحوي شرط سماحية كلمة المرور والخطوة الثانية ستكون البحث تعليمات القفز المشروطة التي تؤول إليها كل تعليمة IF وهذا يعني تحديد الجزء الأهم من الكود الذي يجب معالجته لإيقاف السحر ..
لذلك لا تسمح لة بتحديد موقع العمل بسهولة , تجنب كتابة هذا النوع من الرسائل , أو إفصلة بعيدا عن الجزء الخاص بإختبار كلمة المرور , ويفضل أن تشفرة بطريقة ما.

-جمع السلاسل النصية في مكان واحد , وشفرها هناك ولو بطريقة بسيطة
, واستدعيها عن طريق نسب المتحولات بدلا من الاستدعاء الثابت (static) , لإنها تظهر كما هي في كود الأسمبلي النهائي , وتدل كل منها على الجزء من الكود الذي يعمل عليه هذا البلوك . أما عملية النسب الديناميكية في زمن التشغيل فلن يستطيع الاستفادة منها في تحديد الكود , ولن يجدها بسهولة إذا شفرتها , فأبسط أنواع التشفير تشكل معضلة في هذه الحالة .

-لا تستخدم أسماء ملفات ذات معنى .
لاداعي ليكون ملف الترخيص اسمه License.Dat , لماذا لايكون graphics.dll مثلا
لنفس السبب السابق , لا تجعل الكاركر يتوقع أي ملف يجب أن يبدأ بة أولا , وحاول تضليلة بتشتيت الإجراءات في عدة ملفات بدلا من تجميعها في ملف واحد .

إعادة فحص التحقق مرار وتكرارا ضمن البرنامج 
بحيث تعتمد خدمات البرنامج في عملها على بعضها البعض , وتعيد التاكد من أن تسجيل الدخول كان صحيحا في كل مرة يتم طلب خدمة أو نافذة أو إجرائية جديدة , ويمكن جعل كل منها تعتمد مبدأ مختلف في عملها , الكراكر سوف يفترض أنه سيعالج مقطع كود بسيط في بداية البرنامج وبعدها سيعمل البرنامج بشكل كامل بلا مشاكل , وليس من السهل أن يعالج عشرات المواضع من الكود كل منها أسلوي مختلف في تفحص إذا ما كان المستخدم قد سجل دخول صحيح .
يفضل أن يتم وسم التوابع بInLine لكي تنسخ إلى كل الأماكن التي تستدعيها , ويجب تعديلها كلها بهذه الحالة , بدلا من التوابع التقليدية التي تخزن في مكان واحد وتستدعي منه عن طريق المؤشرات وبالتالي اذا عدلها الكراكر مرة واحدة سيكفي للتعدل في كل البرنامج الذي يستدعيها .

-استخدم روتينات تحقق من الصحة مختلفة في كل مرة 
قم بتعديل شفرتك بحيث تستدعي روتينات تحقق من الصحة مختلفة في كل مرة ,
بإمكانك مثلا تصميم عدة إجراءات تحقق من الصحة , ويتم إستدعاء أحدها بخوارزمية عشوائية في كل مرة ... 
هذه العشوائية مفيدة جدا , لإنه لو تم تعديل كود فإن كود آخر سيبقى يعمل في فترات مختلفة وفي أجزاء مختلفة من البرنامج وبالتالي الكسر ليس شغال بطريقة صحيحة . 
تذكر دائما أن الطرق القياسية والهندسية في العمل سهلة الإكتشاف والتدمير ....

-أستخدم أدوات تشفير الملفات .
لا يكفي أن لانجعل أسماء ملفاتنا تدل عليها , بل يجب تشفير الملفات ما أمكن , ويمكن ذلك ببساطة بإستخدام أدوات خاصة (العديد منها مجاني مع الشفرة ) وهذا يعني أن الملف الثنائي لن يكون بصيغة قابلة للقراءة من قبل الكراكر ولن يستطيع فهم مقاطعه القياسية أو البحث عن السلاسل النصية أو غيرها . وبالتأكيد يفضل أن لاتضع كود التشفير وفك التشفير في نفس المكان.

-استخدم فترات الإنتظار العشوائية .
لا تحذر المستخدم مباشرة بعد إنتهاء فترة صلاحية برنامجة , أنتظر لفترة ربما ليوم أو يومين , الكراكرز يكرهون ذلك . لإنهم يحبون أجزاء الشفرة التي تستجيب مباشرة من أجل الأخطاء وبالتالي بإمكانهم تصميم حلقات كسر سريعة تنجز ذلك في فترة صغيرة .. .
بإمكانك مثلا تشغيل مؤقت في وحدة برمجية مختلفة وفي جزء مختلف من البرنامج بوضع زمن عشوائي له يأخذ قيمة بين 0.1 و 2 ثانية ليعرض رسالة أن المعلومت غير صحيحة . المؤقت سوف يستخدم thread مختلف ويخزن الكود في مكان بعيد .

-أضف شفرات checksums خاصة في أنحاء البرنامج.
مثل شفرات التعرف على حجوم ملفات برنامجك ومنع البرنامج من العمل بشكل صحيح عند حدوث أي تغيير في حجوم الملفات , أو كود التطابق CRC أو غير ذلك . لإن معظم حالات كسر البرامج يحدث معها تغيير بالزيادة أو النقصان على حجم البرنامج المكسور ويتغير حساب checksum فإذا كنت تراقب الملف التنفيذي للبرنامج فستستطيع منعه من العمل إذا تعرض الملف للتعديل.

-رقع الملف التنفيذي لبرنامجك بلغة الآلة ..
قم بتعلم بعض الأفكار حول تعديل البرنامج التنفيذي النهائي بلغة الآلة (كما يفعل الكراكر عمليا) وغير من التنسيق القياسي للملف التنفيذي بعض الشيء , لإنه يوجد برامج هندسة عكسية جاهزة تستطيع التعرف على الكود القياسي الذي تنتجه لغات البرمجة , مثلا لغة الدلفي تنتج كود منظم بلغة الآلة , وتضعه كل مرة بنفس الترتيب وبنفس الطريقة فتستطيع البرامج العكسية مباشرة قراءة الكود بسهولة ومعرفة كل المكونات الموجودة والرسائل النصية والموارد كالصور والأيقونات وغير ذلك والسلاسل المحرفية , وتحديد الإجرائيات الموجودة ومكانها وحتى أن بعضها تتوقع الكود الموجود ضمنها من تحليل شفرة الاسمبلي الموجودة .. 
عندما تغير ولو بشكل بسيط في البرنامج سوف تفرمل عمل هذه البرامج المساعدة التي تقوم بمعظم العمل عن الكراكرز .

-لا تفصل إجراء التحقق من الصحة لوحدة بشكل مستقل,
لا داعي لجعلة محددا وواضحا , حيث يسهل العثور علية وفهمة وبالتالي منع عملة ,
لذلك أنصحك بكتابة تعليمات التحقق من الصحة في منطقة شعبية من البرنامج , أظن أن ذلك مفيد أكثر ..!

-استخدم كلمات تسجيل الدخول متعلقة بظروف مختلفة 
مثلا فإن كلمة المرور سوف يفك تشفيرها بناء على التاريخ , أو رقم الهارد , أو حجم الملف التنفيذي , وهذا أفضل ألف مرة من الكلمات المخزنة سلفا .

-بإمكانك إستخدام توجيهات المترجم 
مفيد لإنه سيعالجها في زمن التنفيذ 

{$IFDEF trial
 ... 
no action here ... 
 {
$ELSE
 ... 
advanced functionality for registered user ... 
 {
$ENDIF}



- استخدم النسب الديناميكي للأحداث
عندما نضع زر على فورم , ونضغط عليه مرتين لكتابة الكود الخاص بالحدث OnClick فإن ذلك سيخزن بالملف التنفيذي النهائي بناء على اسم الزر واسم الحدث onClick كأسماء نصية واضحة . 
سيقوم الكراكر بجمع المعلومات عن ملفك التنفيذي بأدوات تجسس على الموارد form spy tools وهي تعطي معلومات تفصيلية لما يوجد داخل برنامجك من نوافذ ومكونات وتفاصيل عن معلوماته واسماء الأحداث التي ترتبط بكل منها (بالتي ترتبط بشكل ساكن static أي أنها محددة مسبقا منذ التصميم وليس اثناء التنفيذ RunTime)
وهذا سيبدو مشابها لضغط بالزر الأيمن على الشكل وأختيار إظهارة بشكل نصي من بيئة دلفي , وستظهر لنا معلومات مثل :

object RegButtonTButton 
    Left 
200 
    Top 
176 
    Width 
97 
    Height 
25 
    Caption 
'Register' 
    
TabOrder 
    OnClick 
RegButtonClick 
  end


الزر الذي عنوانة Register حيث بإمكانك أن ترى حجمة وموقعة , وسترى أيضا إسم آخر مع العبارة OnClick ,,, هذا الإسم يخبرنا ما هو إسم الروتين المتولد عند النقر على الزر (الجزء المهم من الطريقة) ,وبالتالي يمكن معرفة عنوان حدث عند النقر لزر تسجيل الدخول Rigister .. وكما أوردنا سابقا سيتم نسب الروتين إلى معالج الحدث عند نقر المستخدم على الزر بواسطة الإسم المرفق مع OnClick وهو RegButtonClick .. 
وبالتالي الكلمة RegButtonClick ستكون مخزنة بشكل نصي في الملف التنفيذي وسيسهل العثور عليها بأي محرر ست عشري .! وعندما جربت ذلك على محرر ست عشري عثرت عليها بكل بساطة وكان الناتج :

000A4990 ____ ____ ____ BC57 4A00 0E52 6567 4275 ______.WJ..RegBu 
000A49A0 7474 6F6E 436C 6963 6B__ ____ ____ ____ ttonClick_______



وإذا نظرنا إلى الأرقام التي قبل الإسم , سنجد البايت (0E) والذي يحدد طول ال" RegButtonClick " (14 محرف) . وقبل ذلك يوجد العنوان 004ABC57 .

يمكنك تفادي الطريقة الستاتيكية في نسب الاحداث للمكونات , والقيام بعملية النسب في زمن التشغيل في مكان ما من الكود , ومع استخدام اسماء إجرائيات غير قياسية يصعب اكتشافها .

RegButton.OnClick := RButtonClick;



هذه بعض الأفكار الاولية التي تمكنت من الوصول اليها والتفكير فيها الآن حول هذا الموضوع 
وبالنهاية يمكن تلخيصها بأن نفهم طريقة عمل الكراكرز , ونعاكس أساليبة 
ونخرج عن القياسية بعض الشيء لإن السر يكمن في قدرته على فهم هيكلية برنامجك عن طريق الأدوات المرفقة التي يستخدمها مثل المحررات الست عشرية وبرامج الترجمة العكسية وبرامج التجسس على الموارد وغير ذلك.

عروة عيسى

التقييم: 0.00 (0 أصوات)
**** تحضير للطباعة أرسل هذه المقالة
أضف هذه المقالة إلى المواقع التالية
إضافة إلى Blinklist إضافة إلى del.icio.us إضافة إلى Digg إضافة إلى Fark إضافة إلى Furl إضافة إلى Newsvine إضافة إلى Reddit إضافة إلى Simpy إضافة إلى Spurl إضافة إلى Yahoo مرجع إلى Balatarin مرجع إلى Faceboom مرجع إلى Twitter مرجع إلى Scripstyle مرجع إلى Stumble مرجع إلى Technorati مرجع إلى Mixx مرجع إلى Myspace مرجع إلى Designfloat _NW_BOOKMARK_TO_GOOGLEPLUS _NW_BOOKMARK_TO_GOOGLEREADER _NW_BOOKMARK_TO_GOOGLEBOOKMARKS
التعليقات تخص صاحبها ولا تخص ادارة الموقع
الكاتب الموضوع




عروة نت 2003-2016 . بالاعتماد على زوبس