چگونه برنامه هایمان را در برابر کرک ها مقاوم تر سازیم ؟
1 – از اسامی با معنی مانند زیر استفاده نکنید :
function RegistrationOK: Boolean;
هر چقدر هم که کدی را که در این روال نوشته باشید متبحرانه و هوشمند باشد Cracker ها آن را در کمتر از 20 ثانیه در هم خواهند کوبید !!! خواه این را باور کنید یا نه .
راه دیگر اینست که در این روال کدهای برنامه را هم قرار دهید . ( یعنی بخشی از برنامه که ربطی هم به قفل ندارد ) در این حالت اگر Cracker این روال را غیر فعال کند برنامه هم درست کار نخواهد کرد .
2 – از پیغامهای nagscreens یا “Gotcha” استفاده نکنید :
این از اولین چیزهایی است که یک Cracker چک می کند . آنها هیچوقت برای تجزیه و تحلیل 300K برنامه شما وقت نخواهند گذاشت . بلکه به دنبال nag screens یا " مهلت استفاده مجانی تمام شده است " (Your evaluation time has expired!) خواهند گشت و از آنجا شروع به کار می کنند . ( در ادامه درباره این روش بیشتر بحث خواهیم کرد ) .
در بسیاری موارد آنها موفق می شوند که این صفحه را از resource فایل اجرایی بر خواهند داشت و برنامه بدون اینکه صفحات شما رانشان بدهد بدرستی کار خواهد کرد . اگر واقعاً به وجود اینچنین صفحاتی نیاز دارید آنها را در زمان اجرا و به طور دینامِک بسازید . و پیغام های مبنی بر اینکه برنامه رجیستر نشده است را در بخش معرفی (About) قرار دهید . بعضی از برنامه نویسان اعتقاد دارند که نمایش صفحات nag کاربران را از برنامه متنفر می کند و ... ( تو ایران از این خبرها نیست )
3 – از اسامی با معنی برای فایلها استفاده نکنید :
مانند License.dat . چرا ؟ شماره 1 را دوباره بخوانید .
4 – از روشهای نامتقارن رمزگذاری استفاده کنید :
تنها استقاده از اسامی غیر معمول در اسامی فایلها کافی نیست . بلکه ترکیب با این روش می تواند مدتها آنها را سر کار بگذارد !!!
5 – از تاخیر بلند استفاده کنید (Long Delay) :
بلافاصله به کاربر پیغام رجیستر ندهید و تا مدتی ( مثلاً یک یا دو روز ) آن را به تاخیر بیاندازید . ( Cracker ها از این موضوع نقرت دارند )
6 – از تاخیر کوتاه استفاده کنید : (Short Delay ) :
بعد از وارد کردن کلمه رمز یا هر روتین چک کننده یک یا دو ثانیه صبر کنید تا جلوی حمله های brute force گرفته شود . ساده است ولی عالی کار می کند . ( یا اینکه اگر کلمه رمز درست نبود مکث کنید )
7 – از checksum هم در dll و هم در exe استفاده کنید :
این روش چندان هم مطمئن نیست ولی کار Cracker را سخت تر می کند .
8 – برنامه تان را " خود ترمیمی " بنویسید :
این همان چیزی است که در تصحیح خطای مودم ها و هارد دیسکها استفاده می شود . این تکنولوژی قدمت زیادی دارد ولی کسی از آن در برنامه ها استفاده نمی کند ؟ فایده این روش در این است که اگر Cracker با یک decompiler کار کند لیستی را خواهد دید که دیگر معتبر نبوده و اجرا نمی شود .
9 – برای برنامه خودتان patch بنویسید :
کد خود را تغییر بدهید تا هر بار روش چک کردن و روالهایش تغییر کند .
10 – شماره های سریال را در جاهای غیر متعارف نگهداری کنید :
مثلاً در property یک فیلد بانک اطلاعاتی . حتما شنیده اید که : به آنها یک نام dll بدهید و در شاخه سیستم ویندوز نگهداری کنید . آنقدر گفته و شنیده شده که دیگر ارزشی ندارد .
11 – شماره های سریال را در چند جا نگهداری کنید :
( و تنها اگر اولی معتبر بود دومی را چک کنید )
12 – از کلمات معروف استفاده نکنید :
مانند این : متاسفانه .... (Sorry . But ) این هم جزو اولین چیزهایی است که چک می شود . کلمات را دینامیکی بسازید و یا آنها را به رمز درآورید .
13 – Cracker را غرق کنید :
با استفاده از فراخوانی (call) های ساختگی و رشته هایی که خوب رمز شده اند . دام افکنی لذت بخش است !!!
14 – از کلمات کیدی (reserve word) استفاده کنید :
وقتی رشته یا رمزی را کد می کنید سعی کنید مانند کلمات کلیدی در بیاید مانند : “73AF” یا GetWindowText . این باعث می شود که DisAssembler ها به اشتباه بیافتند .
15 – از حالت غیر فعال (disable) استفاده نکنید :
اگر در حالت نمایشی برنامه شما اطلاعات را ذخیره نمی کند گذاشتن یک منوی خاکستری برای آن کافی نیست . بلکه کد هم نباید در فایل exe شما موجود باشد . برای این منظور از روش ساده زیر می توانید استفاده کنید :
{$IFDEF trial}
... کاری انجام ندهید
{$ELSE}
... کارهای لازم برای کاربران اصلی و یا نسخه کامل
{$ENDIF}
16 – چند نسخه از برنامه تان ایجاد کنید :
{$IFDEF Anticrack_Method36}
.. روش تست قفل شماره 36
{$ENDIF}
با استفاده از روش فوق می توانید به سادگی چند نسخه از برنامه تان ایجاد کنید و هر روش را بسادگی فعال / غیر فعال کنید ( با استفاده از DEFINE کردن هر کدام از روشها در ابتدای برنامه قبل از کامپایل ) و این باعث می شود که crack یکی از نسخه های برنامه تان برای دیگری کار نکند و Cracker باید تمام نسخه ها را download و جداگانه crack کند یا اینکه اگر کاربر برنامه را از جایی متفاوت با cracker دریافت کند برنامه شما crack نخواهد شد !!! . و شما می توانید یک نسخه ویژه برای کاربران مجاز داشته باشید که کد رجیستر آن برای نسخه آزمایشی کار نخواهد کرد .
17 – برنامه تان را بسرعت به روز کنید (Update) :
این باعث می شود که کد برنامه تان تغییر کند و یک crack ساده برای نسخه بعدی شما کار نکند . و همینطور برنامه تان را در یک سایت عمومی برای دانلود نگذارید . این باعث می شود که کنترل بیشتری بر روی برنامه تان داشته باشید که از کجا دریافت می شود و همینطور سایر افراد نمی توانند نسخه قبلی برنامه تان را که crack روی آن کار می کند پیدا کنند . بله می توانند برنامه شما را نیز به همراه crack آن ارائه کنند ولی این باعث می شود که هارد دیسک آنها بسرعت پر شود .
18 – کدهای رجیستر موقت بسازید :
وقتی کاربری ادعای پرداخت پول کرد این کد را که تنها 15 تا 30 روز کار خواهد کرد برای او بفرستید . و تنها پس از اینکه مطمئن شدید پول به حسابتان واریز شده است کد اصلی و بدون محدودیت خود او را به او بدهید . بدین صورت Cracker ها هم به اشتباه می افتند . آنها گمان خواهند کرد که این کد اصلی است و آنرا در سایت خود قرار خواهند داد در حالیکه اینطور نیست و آنها بین دوستان خود احمق جلوه خواهند کرد . این موضوع به خصوص برای beta-tester ها مفید است .
19 – از متد قوی برای کد کردن استفاده کنید :
استفاده از یک xor ساده کافی نیست . از متدی استفاده کنید که به راحتی برگشت پذیر نباشد . ( اگر بتوانید متد برگشت ناپذیری را پیدا کنید چه بهتر و در ضمن متد برگشت ناپذیر به روش یا روشهایی گفته می شود که با داشتن حاصل عملیات و تمام متغیرها نتوان به عدد اولیه رسید . به عنوان مثال عبارت ax+b برگشت پذیر است زیرا با داشتن جواب 5 و مقادیر a=2 و b=1 می توان به مقدار x که همان 2 خواهد بود رسید ) و هر دو روش کد گذاری و از کد درآوردن را در برنامه تان نگذارید .
20 – چند نظر درباره قفلهای وابسته به سخت افزار :
بعضی از روشهای قفل گذاری شامل دریافت اطلاعاتی از سخت افزار کاربر مانند شماره سریال هارد دیسک یا checksum بایوس یا ... است . وقتی این عدد یکبار محاسبه شد آن را در جایی ذخیره کنید و سپس برنامه تان را اجرا کنید یا موارد غیر فعال را فعال کنید . یا اینکه می توانید این اطلاعات را کد گذاری کرده و به کاربر بگویید آنها را برای شما بفرستد . سپس کد فعال سازی را ساخته و برای کاربر ارسال کنید .
در ظاهر همه چیز خوب به نظر می رسد هر چند اگر مطالب قبلی را خوانده باشید می دانید که بهترین روش نیست ولی یک مشگل بزرگ در این روش نیاز به ارتباط دو طرفه بین شما و کاربران نهایی است که در مورد پروژه های بزرگ اصلا روش کارآمدی نیست .
هر بار که کاربر هارد دیسک خود را عوض می کند یا تغییری در سخت افزار خود می دهد و یا حتی هنگامیکه کامپیوتر جدیدی می خرد باید کد فعال سازی جدیدی از شما در خواست کند و اگر برنامه را چند ماه قبل خریده باشد ممکن است مدام در email خود نامه هایی با مضمون " چرا برنامه تان کار نمی کند؟ " را دریافت کنید که منجر به عدم اطمینان کاربرانتان خواهد شد . پس پیش از استفاده از این روش در مورد این موارد خوب قکر کنید . ( این روش برای برنامه های ایرانی به نظر من بهترین روش است بخصوص اگر از شماره سریال هارد استفاده شود همانطور که من هم 2 سالی هست که از این روش استفاده می کنم و برای مورد آخر نیز می توانید این موضوع را در بخش about برنامه تان ذکر کنید ) .
21 – و در نهایت وقت زیادی برای قفل گذاری برنامه هایتان نگذارید :
به راستی قفل ها چقدر ارزش دارند ؟ آیا بهتر نیست زمانی را که برای بهبود قفل خود صرف می کنید برای افزایش کارآیی برنامه تان بگذارید ؟ مشگل شکسته شدن قفل برنامه تان چه ارزشی خواهد داشت وقتی کسی از آن استفاده نکند ؟ یا بدرد کسی نخورد ؟ فکر نکنید کار شما بهترین در دنیا است