اطمینان از امنیت ! [بایگانی]

Marine

پنج شنبه 05 آذر 1383, 00:34 صبح

درود خدمت دوستان عزیز

سوالی داشتم از محضرتون

بر فرض اینکه ما برنامه ای با یک یا چند تا از الگوریتمهای رمز نگاری ساختیم

حالا چطور از میزان امنیتش اطلاع پیدا کنیم ؟
که مقاومت برنامه ما در مقابل کرکر ها چقدر است ؟

آیاموقع ساخت حفره ای ناخواسته درون برنامه به جای گذاشتیم یا نه !

و سوالاتی از این دست .

که بعد از عرضه محصول ، با شکست موجه نشیم

بهتر نیست کمی هم در باره شکستن این الگوریتمها ( بخصوص با توجه به امکانات داخل ایران) بحث بشه ؟

عرض ادب و احترام

مهدی کرامتی

پنج شنبه 05 آذر 1383, 01:16 صبح

رمزنگاری و رعایت نکات ایمنی در هنگام نوشتن برنامه 2 بحث جداگانه هستند.

راستش زیاد حوصله توضیح دادن ندارم، اما هر چه بیشتر برای امنیت برنامه ات تلاش کنی، ضریب اطمینان بالاتری را بدست خواهی آورد.

Marine

پنج شنبه 05 آذر 1383, 01:49 صبح

درود

برای مثال عرض میکنم ، اگر فایل اجرایی برنامه خود را بیتهایش را هر کدام n شیفت تغییر بدیم ، استحکام فایل ما چه اندازه خواهد بود ؟

مهدی کرامتی

پنج شنبه 05 آذر 1383, 07:05 صبح

1- اونوقت انتظار نداری که چنین فایلی اجرا هم بشه، نه؟

2- چقدر زمان برد تا چنین فکری به سرت بزنه؟ همین قدر زمان خواهد برد تا این الگوریتم لو بره! :evil2:

Marine

جمعه 06 آذر 1383, 01:58 صبح

درود

1-نه دوست عزیز ، منظورم فایل اصلی برنامه نبود !

2- گرامی ، مثال زدم !!!
منظورم این بود که چقدر و چطور از شکته نشدن قفل برنامه خود اطمینان حاصل کنیم

عرض ادب و احترام :flower:

مهدی کرامتی

جمعه 06 آذر 1383, 10:53 صبح

اگر فایل اجرایی برنامه خود را بیتهایش را هر کدام n شیفت تغییر بدیم ، استحکام فایل ما چه اندازه خواهد بود ؟
یافتن روش بکار برده شده توسط شما و Decrypt کردن فایلهایی که این چنین Encrypt شده باشند برای یک Cracker حرفه ای بیش از 5 دقیقه زمان نمی برد.

zoncpp

دوشنبه 07 اسفند 1385, 16:11 عصر

برای یک Cracker حرفه ای بیش از 5 دقیقه زمان نمی برد.

به نظر من علاوه بر تمام الگوریتم های Encryption، خوب است که فایل یا نرم افزارتون رو یه جوری وابسته به سخت افزار کنید. اینطوری تلاش 5 دقیقه ای Cracker بدون در اختیار داشتن اون سخت افزار بی نتیجه است. مثلا استفاده از قفل سخت افزاری در کد نرم افزارتون و قرار دادن Dataی مورد نیازی از نرم افزارتون داخل قفل، کار Cracker را سخت تر می کنه و زمان موردنیاز جهت شکستن برنامه شما را بیشتر می کنه.
البته سخت تر تر کردن کار Cracker بسته به نحوه کدنویسی شما برای استفاده از قفل سخت افزاری داره، که هر قفل سخت افزاری بسته به امکاناتی که برای شما فراهم کرده روشهای متفاوتی برای استفاده داره.

greenway

سه شنبه 08 اسفند 1385, 10:29 صبح

به نظر من علاوه بر تمام الگوریتم های Encryption، خوب است که فایل یا نرم افزارتون رو یه جوری وابسته به سخت افزار کنید. اینطوری تلاش 5 دقیقه ای Cracker بدون در اختیار داشتن اون سخت افزار بی نتیجه است. مثلا استفاده از قفل سخت افزاری در کد نرم افزارتون و قرار دادن Dataی مورد نیازی از نرم افزارتون داخل قفل، کار Cracker را سخت تر می کنه و زمان موردنیاز جهت شکستن برنامه شما را بیشتر می کنه.
البته سخت تر تر کردن کار Cracker بسته به نحوه کدنویسی شما برای استفاده از قفل سخت افزاری داره، که هر قفل سخت افزاری بسته به امکاناتی که برای شما فراهم کرده روشهای متفاوتی برای استفاده داره.

بارها و بارها چه در این انجمن و چه در جاهای دیگر دیدم که دوستان به دلیل سخت افزاری بودن قفل امنیت اون رو بالاتر میدونند. همه قفل های سخت افزاری برای اجرا در سیستم عامل ویندوز نیاز به Device Driver دارند و همه اونها توسط DeviceIoControl کنترل می شوند. یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند. نهایتا بحث مطرح شده این دوستمون ممکنه که کاملا درست نباشه اما یک نکته امنیتی برای پیاده سازی در داخلش هست و اون اینکه در این روش کار فقط برای زمانی که قفل اصلی در اختیار Cracker نباشه سخت میشه و در صورتی که قفل رو به همراه برنامه به Cracker بدهند تفاوتی نخواهد داشت. Cracker ها معمولا علاقه شدیدی به SDK قفل های سخت افزاری دارند ،‌ چون با این روش به راحتی میشه کار جایگزینی Replacement قفل رو با نرم افزار انجام داد. بهترین قفل دنیا هم اگر در عمل فقط با یک دستور شرطی بررسی شود ، با بدترین قفل دنیا از نظر کارآیی برابری می کند.

zoncpp

سه شنبه 08 اسفند 1385, 11:31 صبح

بهترین قفل دنیا هم اگر در عمل فقط با یک دستور شرطی بررسی شود ، با بدترین قفل دنیا از نظر کارآیی برابری می کند.

کاملا درسته، نوشته من هم :

البته سخت تر تر کردن کار Cracker بسته به نحوه کدنویسی شما برای استفاده از قفل سخت افزاری داره
اینو تائید می کنه.
و بهترین قفل سخت افزاری هم به این دلیل بهترینه که کار شبیه سازی اون سخت تر و الگوریتم های پیچیده Encryption برای انتقال اطلاعات داره

Inprise

سه شنبه 08 اسفند 1385, 11:37 صبح

الگوریتم های پیچیده Encryption برای انتقال اطلاعات داره

اولا که رمزنگاری ابزاری برای انتقال اطلاعات نیست و دوم اینکه اساسا" میزان پیچیدگی الگوریتم رمزنگاری ( بگذریم از مفهوم پیچیدگی ...) نقش خاصی در میزان امنیتی قفل نداره .

Best Programmer

سه شنبه 08 اسفند 1385, 11:40 صبح

بارها و بارها چه در این انجمن و چه در جاهای دیگر دیدم که دوستان به دلیل سخت افزاری بودن قفل امنیت اون رو بالاتر میدونند. همه قفل های سخت افزاری برای اجرا در سیستم عامل ویندوز نیاز به Device Driver دارند و همه اونها توسط DeviceIoControl کنترل می شوند. یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند. نهایتا بحث مطرح شده این دوستمون ممکنه که کاملا درست نباشه اما یک نکته امنیتی برای پیاده سازی در داخلش هست و اون اینکه در این روش کار فقط برای زمانی که قفل اصلی در اختیار Cracker نباشه سخت میشه و در صورتی که قفل رو به همراه برنامه به Cracker بدهند تفاوتی نخواهد داشت. Cracker ها معمولا علاقه شدیدی به SDK قفل های سخت افزاری دارند ،‌ چون با این روش به راحتی میشه کار جایگزینی Replacement قفل رو با نرم افزار انجام داد. بهترین قفل دنیا هم اگر در عمل فقط با یک دستور شرطی بررسی شود ، با بدترین قفل دنیا از نظر کارآیی برابری می کند.

بحث جالب شد.

یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند.
این فکر قبلا کار می کرد ولی امروزه از سیستم های رمزنگاری پیچیده ایی استفاده می کنند که شما حتی با دستکاری در ISR ها و Interrupt Dispatching با دیوار مانند RSA با کلید 1024bit می خورید.

اینکه در این روش کار فقط برای زمانی که قفل اصلی در اختیار Cracker نباشه سخت میشه
این برای cracker های ناشی و تازه کار هست. امروزه دیگر کسی چندان با خود قفل و شبیه سازی اون کاری ندارند به چند دلیل که برخی را در انتها می گویم. بیشتر با خود برنامه کار می کنند چرا که هم ساده تر است و هم این که مطمئن تر.

1: قفل های سخت افزاری در مقیاس نرم افزار های بزرگ کاربرد خود را از دست داده اند و امروزه بسیاری نرم افزار ها از یک سیستم به عنوان تایید کننده لیسانس در شبکه استفاده می کنند و تمام قفل ها با اون سرور در ارتباط قرار می گیرند
2: به علت برخی محدودیت ها که برای قفل سخت افزاری است مانند :
طراحی ساخت نیروی کار ماهر

برای تولید یک قفل می باشد بیشتر به سمت گزینه 1 رفتند.

zoncpp

سه شنبه 08 اسفند 1385, 12:43 عصر

اولا که رمزنگاری ابزاری برای انتقال اطلاعات نیست و دوم اینکه اساسا" میزان پیچیدگی الگوریتم رمزنگاری ( بگذریم از مفهوم پیچیدگی ...) نقش خاصی در میزان امنیتی قفل نداره .

رمز نگاری Data باعث میشه دادۀ دریافت شده با دادۀ ارسال شده یکی نبوده و هیچ کدام همان دادۀ خام مورد نظر نباشه. بنابراین بدست آوردن مقادیر قفل و کپی کردن ان با رمزنگاری و Encryption داده ها در هنگام انتقال سخت می شه

Best Programmer

سه شنبه 08 اسفند 1385, 12:51 عصر

رمز نگاری Data باعث میشه دادۀ دریافت شده با دادۀ ارسال شده یکی نبوده و هیچ کدام همان دادۀ خام مورد نظر نباشه. بنابراین بدست آوردن مقادیر قفل و کپی کردن ان با رمزنگاری و Encryption داده ها در هنگام انتقال سخت می شه

دوست عزیز بهتر است ابتدا کمی اصول رمزنگاری را مطالعه کنید و سپس پست بدید. اینجا کسی دشمنی ندارد فقط چون اشتباه فهمیده اید بهتر است دوباره در مفاهیم درک کرده خود تجدید نظر کنید. :چشمک:

greenway

سه شنبه 08 اسفند 1385, 20:12 عصر

بحث جالب شد.
.
این فکر قبلا کار می کرد ولی امروزه از سیستم های رمزنگاری پیچیده ایی استفاده می کنند که شما حتی با دستکاری در ISR ها و Interrupt Dispatching با دیوار مانند RSA با کلید 1024bit می خورید.

این برای cracker های ناشی و تازه کار هست. امروزه دیگر کسی چندان با خود قفل و شبیه سازی اون کاری ندارند به چند دلیل که برخی را در انتها می گویم. بیشتر با خود برنامه کار می کنند چرا که هم ساده تر است و هم این که مطمئن تر.

1: قفل های سخت افزاری در مقیاس نرم افزار های بزرگ کاربرد خود را از دست داده اند و امروزه بسیاری نرم افزار ها از یک سیستم به عنوان تایید کننده لیسانس در شبکه استفاده می کنند و تمام قفل ها با اون سرور در ارتباط قرار می گیرند

متاسفانه هر کدام از ما زمان کوتاهی برای این بحث ها داریم ( حداقل من که وضعم اینطور است ) . از نظر اطمینان که مسلما قفل شبیه سازی شده برای کرک یک برنامه بسیار زیباتر از برنامه Patch شده عمل می کند. در این روش که شاید بتوانیم آن را Zero Byte Patching بگذاریم هیچ دستکاری در برنامه اصلی نمی شود و شما حتما بهتر از من می دانید که معماری ویندوز اساسا لایه بندی شده است . یکی DeviceIoControl را در لایه Application و در Import Table تغییر مسیر می دهد ، دیگری با تغییر مسیر در یک KMD و تغییر در SDT و آن دیگری با جایگزین کردن Driver و مشابه سازی Dispatch Table و آن یکی دیگر هم با Global Hooking در NTDLL.DLL ... و چنانچه دیتای رد و بدل شده از بالا به پایین و یا بر عکس کد شده هم باشد به تعداد محدود معنی داری خلاصه شده و مابقی بی معنی ( فقط برای وجود قفل به صورت زمان بندی شده ) هستند. در نهایت این پیاده سازی استفاده کننده یک قفل آن چنانی است که به چه نحوی قفل را در برنامه کارگذاری کند. ( اگر چه هر کدام راهی دارند ولی با توجه به سلیقه و محدوده اطلاعات می تواند برخی از کرکرها را از سوژه اصلی دور نگه دارد ) . بعد از همه اینها ، قفل های سخت افزاری کمی اینگونه قابلیت ها را دارند که قیمت های آنها هم برای محافظت نرم افزارهای ما نامناسب است. اما در مورد برنامه های بزرگ و صنعتی دنیا کاملا با شما موافقم . کسی را می شناختم که در حال پیاده سازی یک VM بر روی یک Dedicated Server بود که نه تنها درستی License در شبکه بررسی شود ، بلکه اجرای فایل اجرایی نیز وابسته به اتصال به شبکه باشد. ( برنامه هیچ وقت در سطح تجاری نوشته نشد )

ab.mahmoodi

پنج شنبه 10 اسفند 1385, 10:05 صبح

همه قفل های سخت افزاری برای اجرا در سیستم عامل ویندوز نیاز به Device Driver دارند و همه اونها توسط DeviceIoControl کنترل می شوند. یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند.

سلام دوستان
اول اینکه بنده هیچ تعصبی روی قفل های سخت افزاری ندارم. اما با توجه به روشی که دوستمون توضیح دادند برای شکستن قفل سخت افزاری با روش گفته شده نیاز به اطلاعات درایورهای سخت افزاری است ولی همه این رو میدونند که بسیاری از کرکرها حتی اطلاعات اولیه برنامه نویسی هم ندارند چه رسد به نوشتن درایور. بنابراین همیشه باید دقت بفرمایید در استفاده قفل های نرم افزاری و سخت افزاری روشهایی وجود دارد که امنیت نرم افزار را بالا میبرد. همچنین کرکرها معمولا به طور مستقیم سراغ خود نرم افزار میروند پس روش شما برای چک کردن قفل بسیار مهم است...

bigboy_user

دوشنبه 14 اسفند 1385, 17:43 عصر

با تشکر از همه دوستان
مطالب نوشته مفید بود، ودر ادامه باید بگم که هر نوع قفلی شکسته میشه چه قفلهای سخت افزاری یا نرم افزاری ، فقط می توان با سخت تر کردن روتینهای چک عمل شکستن را به تاخیر انداخت و همانطور که دوستان گفته اند تمام قفلهایی که تحت سیستم عامل ویندوز کار می کنند به نوعی (مستقیم یا غیر مستقیم) از درایورهای ویندوز برای ارسال/دریافت داده استفاده می کنند ، با این حال مثلا قفلی مانند Hasp برای Program کردن آن نیاز به یک PC Card دارد و تا این کارت نباشه program قفل غیر ممکنه (البته exe هایی که از این قفل استفاده میکنند میشه Debug کرد یا ....) که تنهاقیمت آن چیزی حدود 600000 تومان است که به صرفه نیست ... اما اگر قفلی وجود داشته باشد که درایور مخصوص خود به همراه الگوریتمای encoded کاملی داشته باشه و در سطح LOW level و بدون وابستگی به هیچ DLL یا API , ویا حتی بدون استفاده از DDK مایکروسافت و.. نوشته شده باشد ودارای ابزار باشد که Debug یا Trace نباشد و سر آخر اینکه قیمت مناسبی هم داشته باشد ....
خوب دیگه اصلا محشره ه ه ه ه ه !!!!!!!.

Devilprogramer

دوشنبه 10 اردیبهشت 1386, 17:48 عصر

خوب .. در زمینه رمز گشایی تو ایران کم کار نشده!!
اگر شما با الگوریتم های رمز نگاری نظیر RSA و AES و DES و .. آشنایی داشته باشید .. یا حتی مثلاً همین Stream cipher که عین نقل و نبات داره تو دستگاههای مخابرات استفاده می شه .. می بینید که چند برابر بیشتر از آنچه برای اجرای الگوریتم گفته شده .. برای طرز صحیح انتخاب کلید و راههای جلوگیری از شکسته شدن اون رمزها گفته شده .. اگر اصول گفته شده برای انتخاب کلید و طول کلید رعایت شده باشه .. درصد کمی می تونید اطمینان حاصل کنید .. ولی با امتحان الگوریتمتون و تست های آماری بر روی cipher text اتون می تونید توانایی رمزتونو تشخیص بدید..
یکی از مسائلی که مطرحه اینه که هر چقدر فراوانی حروفتون به توزیع یکنواخت نزدیکتر باشه رمز قوی تره .. که این مبحث می ره تو شاخه آنتروپی .. مسائل np-complete هم میره تو قضیه زمان چند جمله ای و این حرفا
دیگه جونم براتون بگه که از لحاظ تست های باینری هم بخواین تا دلتون بخواد آزمون آماری براش هست
اما راهی که عملاً مراکز مهم انجام می دن اینه که یک نمونه از رمزی رو که خودشون ارائه دادن رو برای همگان می ذارن یه مسابقه می ذارن با یه جایزه توپ که ایرادای رمزشون پیدا شه به طور عملی

گفتم بگم شاید کمکی کنه .. راستی این رمزنگاری هم هم پیاده سازی نرم افزاری دارن هم سخت افزاری ولی اینو بدونین که Timing Attack ها حسابی جواب می دن ..