نمایش نتایج 1 تا 17 از 17

نام تاپیک: اطمینان از امنیت !

  1. #1

    اطمینان از امنیت !

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

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

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

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

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

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

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


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

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

  2. #2
    بنیان گذار Barnamenevis آواتار مهدی کرامتی
    تاریخ عضویت
    اسفند 1381
    محل زندگی
    کرج، گلشهر
    سن
    48
    پست
    6,379
    رمزنگاری و رعایت نکات ایمنی در هنگام نوشتن برنامه 2 بحث جداگانه هستند.

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

  3. #3
    درود

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

  4. #4
    بنیان گذار Barnamenevis آواتار مهدی کرامتی
    تاریخ عضویت
    اسفند 1381
    محل زندگی
    کرج، گلشهر
    سن
    48
    پست
    6,379
    1- اونوقت انتظار نداری که چنین فایلی اجرا هم بشه، نه؟

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

  5. #5
    درود

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

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


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

  6. #6
    بنیان گذار Barnamenevis آواتار مهدی کرامتی
    تاریخ عضویت
    اسفند 1381
    محل زندگی
    کرج، گلشهر
    سن
    48
    پست
    6,379
    اگر فایل اجرایی برنامه خود را بیتهایش را هر کدام n شیفت تغییر بدیم ، استحکام فایل ما چه اندازه خواهد بود ؟
    یافتن روش بکار برده شده توسط شما و Decrypt کردن فایلهایی که این چنین Encrypt شده باشند برای یک Cracker حرفه ای بیش از 5 دقیقه زمان نمی برد.

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

  8. #8
    کاربر دائمی
    تاریخ عضویت
    آذر 1385
    محل زندگی
    Tehran
    پست
    109
    نقل قول نوشته شده توسط zoncpp مشاهده تاپیک
    به نظر من علاوه بر تمام الگوریتم های Encryption، خوب است که فایل یا نرم افزارتون رو یه جوری وابسته به سخت افزار کنید. اینطوری تلاش 5 دقیقه ای Cracker بدون در اختیار داشتن اون سخت افزار بی نتیجه است. مثلا استفاده از قفل سخت افزاری در کد نرم افزارتون و قرار دادن Dataی مورد نیازی از نرم افزارتون داخل قفل، کار Cracker را سخت تر می کنه و زمان موردنیاز جهت شکستن برنامه شما را بیشتر می کنه.
    البته سخت تر تر کردن کار Cracker بسته به نحوه کدنویسی شما برای استفاده از قفل سخت افزاری داره، که هر قفل سخت افزاری بسته به امکاناتی که برای شما فراهم کرده روشهای متفاوتی برای استفاده داره.
    بارها و بارها چه در این انجمن و چه در جاهای دیگر دیدم که دوستان به دلیل سخت افزاری بودن قفل امنیت اون رو بالاتر میدونند. همه قفل های سخت افزاری برای اجرا در سیستم عامل ویندوز نیاز به Device Driver دارند و همه اونها توسط DeviceIoControl کنترل می شوند. یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند. نهایتا بحث مطرح شده این دوستمون ممکنه که کاملا درست نباشه اما یک نکته امنیتی برای پیاده سازی در داخلش هست و اون اینکه در این روش کار فقط برای زمانی که قفل اصلی در اختیار Cracker نباشه سخت میشه و در صورتی که قفل رو به همراه برنامه به Cracker بدهند تفاوتی نخواهد داشت. Cracker ها معمولا علاقه شدیدی به SDK قفل های سخت افزاری دارند ،‌ چون با این روش به راحتی میشه کار جایگزینی Replacement قفل رو با نرم افزار انجام داد. بهترین قفل دنیا هم اگر در عمل فقط با یک دستور شرطی بررسی شود ، با بدترین قفل دنیا از نظر کارآیی برابری می کند.

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

  10. #10
    الگوریتم های پیچیده Encryption برای انتقال اطلاعات داره
    اولا که رمزنگاری ابزاری برای انتقال اطلاعات نیست و دوم اینکه اساسا" میزان پیچیدگی الگوریتم رمزنگاری ( بگذریم از مفهوم پیچیدگی ...) نقش خاصی در میزان امنیتی قفل نداره .
    UNIX is simple. It just takes a genius to understand its simplicity
    -- Dennis Ritchie

  11. #11
    نقل قول نوشته شده توسط greenway مشاهده تاپیک
    بارها و بارها چه در این انجمن و چه در جاهای دیگر دیدم که دوستان به دلیل سخت افزاری بودن قفل امنیت اون رو بالاتر میدونند. همه قفل های سخت افزاری برای اجرا در سیستم عامل ویندوز نیاز به Device Driver دارند و همه اونها توسط DeviceIoControl کنترل می شوند. یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند. نهایتا بحث مطرح شده این دوستمون ممکنه که کاملا درست نباشه اما یک نکته امنیتی برای پیاده سازی در داخلش هست و اون اینکه در این روش کار فقط برای زمانی که قفل اصلی در اختیار Cracker نباشه سخت میشه و در صورتی که قفل رو به همراه برنامه به Cracker بدهند تفاوتی نخواهد داشت. Cracker ها معمولا علاقه شدیدی به SDK قفل های سخت افزاری دارند ،‌ چون با این روش به راحتی میشه کار جایگزینی Replacement قفل رو با نرم افزار انجام داد. بهترین قفل دنیا هم اگر در عمل فقط با یک دستور شرطی بررسی شود ، با بدترین قفل دنیا از نظر کارآیی برابری می کند.
    بحث جالب شد.
    یعنی اینکه با شبیه سازی IOCTL ها در یک Driver غیر واقعی همه این قفل های سخت افزاری قابل دور زدن هستند
    .
    این فکر قبلا کار می کرد ولی امروزه از سیستم های رمزنگاری پیچیده ایی استفاده می کنند که شما حتی با دستکاری در ISR ها و Interrupt Dispatching با دیوار مانند RSA با کلید 1024bit می خورید.
    اینکه در این روش کار فقط برای زمانی که قفل اصلی در اختیار Cracker نباشه سخت میشه
    این برای cracker های ناشی و تازه کار هست. امروزه دیگر کسی چندان با خود قفل و شبیه سازی اون کاری ندارند به چند دلیل که برخی را در انتها می گویم. بیشتر با خود برنامه کار می کنند چرا که هم ساده تر است و هم این که مطمئن تر.

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

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

  12. #12
    نقل قول نوشته شده توسط Inprise مشاهده تاپیک
    اولا که رمزنگاری ابزاری برای انتقال اطلاعات نیست و دوم اینکه اساسا" میزان پیچیدگی الگوریتم رمزنگاری ( بگذریم از مفهوم پیچیدگی ...) نقش خاصی در میزان امنیتی قفل نداره .
    رمز نگاری Data باعث میشه دادۀ دریافت شده با دادۀ ارسال شده یکی نبوده و هیچ کدام همان دادۀ خام مورد نظر نباشه. بنابراین بدست آوردن مقادیر قفل و کپی کردن ان با رمزنگاری و Encryption داده ها در هنگام انتقال سخت می شه

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

  14. #14
    کاربر دائمی
    تاریخ عضویت
    آذر 1385
    محل زندگی
    Tehran
    پست
    109
    نقل قول نوشته شده توسط Best Programmer مشاهده تاپیک
    بحث جالب شد.
    .
    این فکر قبلا کار می کرد ولی امروزه از سیستم های رمزنگاری پیچیده ایی استفاده می کنند که شما حتی با دستکاری در 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 در شبکه بررسی شود ، بلکه اجرای فایل اجرایی نیز وابسته به اتصال به شبکه باشد. ( برنامه هیچ وقت در سطح تجاری نوشته نشد )

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

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

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

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

قوانین ایجاد تاپیک در تالار

  • شما نمی توانید تاپیک جدید ایجاد کنید
  • شما نمی توانید به تاپیک ها پاسخ دهید
  • شما نمی توانید ضمیمه ارسال کنید
  • شما نمی توانید پاسخ هایتان را ویرایش کنید
  •