Printable View
درود خدمت دوستان عزیز
سوالی داشتم از محضرتون
بر فرض اینکه ما برنامه ای با یک یا چند تا از الگوریتمهای رمز نگاری ساختیم
حالا چطور از میزان امنیتش اطلاع پیدا کنیم ؟
که مقاومت برنامه ما در مقابل کرکر ها چقدر است ؟
آیاموقع ساخت حفره ای ناخواسته درون برنامه به جای گذاشتیم یا نه !
و سوالاتی از این دست .
که بعد از عرضه محصول ، با شکست موجه نشیم
بهتر نیست کمی هم در باره شکستن این الگوریتمها ( بخصوص با توجه به امکانات داخل ایران) بحث بشه ؟
عرض ادب و احترام
رمزنگاری و رعایت نکات ایمنی در هنگام نوشتن برنامه 2 بحث جداگانه هستند.
راستش زیاد حوصله توضیح دادن ندارم، اما هر چه بیشتر برای امنیت برنامه ات تلاش کنی، ضریب اطمینان بالاتری را بدست خواهی آورد.
درود
برای مثال عرض میکنم ، اگر فایل اجرایی برنامه خود را بیتهایش را هر کدام n شیفت تغییر بدیم ، استحکام فایل ما چه اندازه خواهد بود ؟
1- اونوقت انتظار نداری که چنین فایلی اجرا هم بشه، نه؟
2- چقدر زمان برد تا چنین فکری به سرت بزنه؟ همین قدر زمان خواهد برد تا این الگوریتم لو بره! :evil2:
درود
1-نه دوست عزیز ، منظورم فایل اصلی برنامه نبود !
2- گرامی ، مثال زدم !!!
منظورم این بود که چقدر و چطور از شکته نشدن قفل برنامه خود اطمینان حاصل کنیم
عرض ادب و احترام :flower:
یافتن روش بکار برده شده توسط شما و Decrypt کردن فایلهایی که این چنین Encrypt شده باشند برای یک Cracker حرفه ای بیش از 5 دقیقه زمان نمی برد.نقل قول:
اگر فایل اجرایی برنامه خود را بیتهایش را هر کدام n شیفت تغییر بدیم ، استحکام فایل ما چه اندازه خواهد بود ؟
به نظر من علاوه بر تمام الگوریتم های Encryption، خوب است که فایل یا نرم افزارتون رو یه جوری وابسته به سخت افزار کنید. اینطوری تلاش 5 دقیقه ای Cracker بدون در اختیار داشتن اون سخت افزار بی نتیجه است. مثلا استفاده از قفل سخت افزاری در کد نرم افزارتون و قرار دادن Dataی مورد نیازی از نرم افزارتون داخل قفل، کار Cracker را سخت تر می کنه و زمان موردنیاز جهت شکستن برنامه شما را بیشتر می کنه.نقل قول:
برای یک Cracker حرفه ای بیش از 5 دقیقه زمان نمی برد.
البته سخت تر تر کردن کار Cracker بسته به نحوه کدنویسی شما برای استفاده از قفل سخت افزاری داره، که هر قفل سخت افزاری بسته به امکاناتی که برای شما فراهم کرده روشهای متفاوتی برای استفاده داره.
بارها و بارها چه در این انجمن و چه در جاهای دیگر دیدم که دوستان به دلیل سخت افزاری بودن قفل امنیت اون رو بالاتر میدونند. همه قفل های سخت افزاری برای اجرا در سیستم عامل ویندوز نیاز به Device Driver دارند و همه اونها توسط DeviceIoControl کنترل می شوند. یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند. نهایتا بحث مطرح شده این دوستمون ممکنه که کاملا درست نباشه اما یک نکته امنیتی برای پیاده سازی در داخلش هست و اون اینکه در این روش کار فقط برای زمانی که قفل اصلی در اختیار Cracker نباشه سخت میشه و در صورتی که قفل رو به همراه برنامه به Cracker بدهند تفاوتی نخواهد داشت. Cracker ها معمولا علاقه شدیدی به SDK قفل های سخت افزاری دارند ، چون با این روش به راحتی میشه کار جایگزینی Replacement قفل رو با نرم افزار انجام داد. بهترین قفل دنیا هم اگر در عمل فقط با یک دستور شرطی بررسی شود ، با بدترین قفل دنیا از نظر کارآیی برابری می کند.نقل قول:
نوشته شده توسط zoncpp
کاملا درسته، نوشته من هم :نقل قول:
بهترین قفل دنیا هم اگر در عمل فقط با یک دستور شرطی بررسی شود ، با بدترین قفل دنیا از نظر کارآیی برابری می کند.
اینو تائید می کنه.نقل قول:
البته سخت تر تر کردن کار Cracker بسته به نحوه کدنویسی شما برای استفاده از قفل سخت افزاری داره
و بهترین قفل سخت افزاری هم به این دلیل بهترینه که کار شبیه سازی اون سخت تر و الگوریتم های پیچیده Encryption برای انتقال اطلاعات داره
اولا که رمزنگاری ابزاری برای انتقال اطلاعات نیست و دوم اینکه اساسا" میزان پیچیدگی الگوریتم رمزنگاری ( بگذریم از مفهوم پیچیدگی ...) نقش خاصی در میزان امنیتی قفل نداره .نقل قول:
الگوریتم های پیچیده Encryption برای انتقال اطلاعات داره
بحث جالب شد.نقل قول:
نوشته شده توسط greenway
.نقل قول:
یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند
این فکر قبلا کار می کرد ولی امروزه از سیستم های رمزنگاری پیچیده ایی استفاده می کنند که شما حتی با دستکاری در ISR ها و Interrupt Dispatching با دیوار مانند RSA با کلید 1024bit می خورید.
این برای cracker های ناشی و تازه کار هست. امروزه دیگر کسی چندان با خود قفل و شبیه سازی اون کاری ندارند به چند دلیل که برخی را در انتها می گویم. بیشتر با خود برنامه کار می کنند چرا که هم ساده تر است و هم این که مطمئن تر.نقل قول:
اینکه در این روش کار فقط برای زمانی که قفل اصلی در اختیار Cracker نباشه سخت میشه
1: قفل های سخت افزاری در مقیاس نرم افزار های بزرگ کاربرد خود را از دست داده اند و امروزه بسیاری نرم افزار ها از یک سیستم به عنوان تایید کننده لیسانس در شبکه استفاده می کنند و تمام قفل ها با اون سرور در ارتباط قرار می گیرند
2: به علت برخی محدودیت ها که برای قفل سخت افزاری است مانند :
- طراحی
- ساخت
- نیروی کار ماهر
برای تولید یک قفل می باشد بیشتر به سمت گزینه 1 رفتند.
رمز نگاری Data باعث میشه دادۀ دریافت شده با دادۀ ارسال شده یکی نبوده و هیچ کدام همان دادۀ خام مورد نظر نباشه. بنابراین بدست آوردن مقادیر قفل و کپی کردن ان با رمزنگاری و Encryption داده ها در هنگام انتقال سخت می شهنقل قول:
نوشته شده توسط Inprise
دوست عزیز بهتر است ابتدا کمی اصول رمزنگاری را مطالعه کنید و سپس پست بدید. اینجا کسی دشمنی ندارد فقط چون اشتباه فهمیده اید بهتر است دوباره در مفاهیم درک کرده خود تجدید نظر کنید. :چشمک:نقل قول:
نوشته شده توسط zoncpp
متاسفانه هر کدام از ما زمان کوتاهی برای این بحث ها داریم ( حداقل من که وضعم اینطور است ) . از نظر اطمینان که مسلما قفل شبیه سازی شده برای کرک یک برنامه بسیار زیباتر از برنامه Patch شده عمل می کند. در این روش که شاید بتوانیم آن را Zero Byte Patching بگذاریم هیچ دستکاری در برنامه اصلی نمی شود و شما حتما بهتر از من می دانید که معماری ویندوز اساسا لایه بندی شده است . یکی DeviceIoControl را در لایه Application و در Import Table تغییر مسیر می دهد ، دیگری با تغییر مسیر در یک KMD و تغییر در SDT و آن دیگری با جایگزین کردن Driver و مشابه سازی Dispatch Table و آن یکی دیگر هم با Global Hooking در NTDLL.DLL ... و چنانچه دیتای رد و بدل شده از بالا به پایین و یا بر عکس کد شده هم باشد به تعداد محدود معنی داری خلاصه شده و مابقی بی معنی ( فقط برای وجود قفل به صورت زمان بندی شده ) هستند. در نهایت این پیاده سازی استفاده کننده یک قفل آن چنانی است که به چه نحوی قفل را در برنامه کارگذاری کند. ( اگر چه هر کدام راهی دارند ولی با توجه به سلیقه و محدوده اطلاعات می تواند برخی از کرکرها را از سوژه اصلی دور نگه دارد ) . بعد از همه اینها ، قفل های سخت افزاری کمی اینگونه قابلیت ها را دارند که قیمت های آنها هم برای محافظت نرم افزارهای ما نامناسب است. اما در مورد برنامه های بزرگ و صنعتی دنیا کاملا با شما موافقم . کسی را می شناختم که در حال پیاده سازی یک VM بر روی یک Dedicated Server بود که نه تنها درستی License در شبکه بررسی شود ، بلکه اجرای فایل اجرایی نیز وابسته به اتصال به شبکه باشد. ( برنامه هیچ وقت در سطح تجاری نوشته نشد )نقل قول:
نوشته شده توسط Best Programmer
سلام دوستاننقل قول:
نوشته شده توسط greenway
اول اینکه بنده هیچ تعصبی روی قفل های سخت افزاری ندارم. اما با توجه به روشی که دوستمون توضیح دادند برای شکستن قفل سخت افزاری با روش گفته شده نیاز به اطلاعات درایورهای سخت افزاری است ولی همه این رو میدونند که بسیاری از کرکرها حتی اطلاعات اولیه برنامه نویسی هم ندارند چه رسد به نوشتن درایور. بنابراین همیشه باید دقت بفرمایید در استفاده قفل های نرم افزاری و سخت افزاری روشهایی وجود دارد که امنیت نرم افزار را بالا میبرد. همچنین کرکرها معمولا به طور مستقیم سراغ خود نرم افزار میروند پس روش شما برای چک کردن قفل بسیار مهم است...
با تشکر از همه دوستان
مطالب نوشته مفید بود، ودر ادامه باید بگم که هر نوع قفلی شکسته میشه چه قفلهای سخت افزاری یا نرم افزاری ، فقط می توان با سخت تر کردن روتینهای چک عمل شکستن را به تاخیر انداخت و همانطور که دوستان گفته اند تمام قفلهایی که تحت سیستم عامل ویندوز کار می کنند به نوعی (مستقیم یا غیر مستقیم) از درایورهای ویندوز برای ارسال/دریافت داده استفاده می کنند ، با این حال مثلا قفلی مانند Hasp برای Program کردن آن نیاز به یک PC Card دارد و تا این کارت نباشه program قفل غیر ممکنه (البته exe هایی که از این قفل استفاده میکنند میشه Debug کرد یا ....) که تنهاقیمت آن چیزی حدود 600000 تومان است که به صرفه نیست ... اما اگر قفلی وجود داشته باشد که درایور مخصوص خود به همراه الگوریتمای encoded کاملی داشته باشه و در سطح LOW level و بدون وابستگی به هیچ DLL یا API , ویا حتی بدون استفاده از DDK مایکروسافت و.. نوشته شده باشد ودارای ابزار باشد که Debug یا Trace نباشد و سر آخر اینکه قیمت مناسبی هم داشته باشد ....
خوب دیگه اصلا محشره ه ه ه ه ه !!!!!!!.
خوب .. در زمینه رمز گشایی تو ایران کم کار نشده!!
اگر شما با الگوریتم های رمز نگاری نظیر RSA و AES و DES و .. آشنایی داشته باشید .. یا حتی مثلاً همین Stream cipher که عین نقل و نبات داره تو دستگاههای مخابرات استفاده می شه .. می بینید که چند برابر بیشتر از آنچه برای اجرای الگوریتم گفته شده .. برای طرز صحیح انتخاب کلید و راههای جلوگیری از شکسته شدن اون رمزها گفته شده .. اگر اصول گفته شده برای انتخاب کلید و طول کلید رعایت شده باشه .. درصد کمی می تونید اطمینان حاصل کنید .. ولی با امتحان الگوریتمتون و تست های آماری بر روی cipher text اتون می تونید توانایی رمزتونو تشخیص بدید..
یکی از مسائلی که مطرحه اینه که هر چقدر فراوانی حروفتون به توزیع یکنواخت نزدیکتر باشه رمز قوی تره .. که این مبحث می ره تو شاخه آنتروپی .. مسائل np-complete هم میره تو قضیه زمان چند جمله ای و این حرفا
دیگه جونم براتون بگه که از لحاظ تست های باینری هم بخواین تا دلتون بخواد آزمون آماری براش هست
اما راهی که عملاً مراکز مهم انجام می دن اینه که یک نمونه از رمزی رو که خودشون ارائه دادن رو برای همگان می ذارن یه مسابقه می ذارن با یه جایزه توپ که ایرادای رمزشون پیدا شه به طور عملی
گفتم بگم شاید کمکی کنه .. راستی این رمزنگاری هم هم پیاده سازی نرم افزاری دارن هم سخت افزاری ولی اینو بدونین که Timing Attack ها حسابی جواب می دن ..