امنیت در نرم افزار و برنامه نویسی (قسمت سوم)
Decompiler به لحاظ "تئوریک" یعنی ابزاری برای تبدیل یک برنامهء باینری اجرائی یا یک کتابخانه یا درایور به سورس کد اصلی ؛ قبل از ورود به بحث لازمه یک طبقه بندی از موجودیتهائی که ممکنه ذیل عنوان Decompiler مطرح بشن داشته باشیم :
• - برنامه های اجرائی باینری : برنامه هائی که عموما" با زبانهای سطح بالائی نظیر VC یا دلفی نوشته میشن و به کدهای "مخصوص" به ویندوز/معماری ماشین ( مثلا" Win32/IA32 یعنی ویندوز 32 بیتی روی اینتل 32 بیتی ) ترجمه میشن .
- کتابخانه های اشتراکی : بسته های نرم افزاری که عموما با زبانهای سطح بالا برای کاربری در سایر برنامه ها تولید میشن و وابسته به سیستم عامل و معماری سخت افزاری هستند .
- برنامه های تفسیری : برنامه هائی که قبل از هر بار اجرا باید توسط یک مفسیر ترجمه بشن . به عنوان مثال برنامه های VB6 که بصورت PCode منتشر میشن و هر بار قبل از اجرا توسط VB runtime تفسیر میشن .
- برنامه های مبتنی بر زمان اجرا : برنامه هائی که برای اجرا نیاز به بستر از پیش فراهم شده ای برای روند اجرا دارند . مانند برنامه های دات نت و جاوا .
- درایور ها : کدهای سطح کرنلی که مختص سیستم عامل و معماری سخت افزاری هستند و عموما با زبانهای سطح پائین تولید میشن .
هیچ Decompiler ای برای گروهای اول و دوم و پنجم ارائه نشده ، نمیشه ، نخواهد شد . یعنی دریافت سورس کد کامل نرم افزارهای اجرائی از نسخه باینری اونها مطلقا" غیر ممکنه . این عدم امکان فنی نیست که در آینده با پیشرفت دانش امکان پذیر بشه ؛ یک نفی منطقی است . یعنی منطقا" امکان باز-تولید سورس کد کامل یک برنامه تولید شده با محیطهائی مثل Delphi یا VC وجود نداشته ، نداره ، نخواهد داشت .
سوال : پس نرم افزارهای متعددی که تحت عنوان Decompiler منتشر میشن چی ؟
جواب : با توجه به تعریف Decompiler ، جواب داده شد .
سوال : آیا اصولا" وجود Decompiler لازمه ؟
جواب : برای اهداف مثبت و خیرخواهانه خیر . حتی برای اهداف غیر خیرخواهانه نیز وجود Decompiler یک لازمه نیست . هیچ کسی از وجود ابزاری که بتونه برنامهء او رو به سورس قابل قبولی مبدل کنه خوشحال نخواهد شد ؛ این ابزار کمکی به توسعه نرم افزار نمیکنه و سود اقتصادی ، پیشرفت علمی و افزایش قابلیتهای صنعت نرم افزار رو بیشتر نخواهد کرد . حتی برای اهداف مخرب هم ، وجود چنین ابزاری لازم نیست چون بسیاری از کسانی که در این مسیر فعالیت میکنند برای تخریب امنیت یک نرم افزار نیازی به دست رسی به سورس اون ندارند . کشف نقاط ضعف امنیتی یا عبور از حفاظهای نرم افزار عموما" در محیطهائی اتفاق می افته که سورس وجود نداره و تمام فرآیند تخریب از طریق مهندسی معکوس یا Reverse Engineering انجام میگیرد .
• - بررسی و Trace و بازبینی روند اجرا ی برنامه هائی که با محیطهائی نظیر دات نت و جاوا تولید میشوند ، به مراتب دشوار تر از برنامه هائی است که با محیطهائی نظیر دلفی و VC تولید میشوند؛ چرا که وجود Runtime های بزرگی مانند JRE یا CLR باعث میشه پیچیدگی فراخوانی ها ، مدیریت حافظه ، مدیریت ریسمان ها و پردازه ها و غیرهم به مراتب از برنامه های اصطلاحا" Native ( مانند خروجی های VC ) بیشتر باشه . پس فی المثل درک جزئیات فنی یک الگوریتم ، وقتی با دات نت نوشته شده باشه و به خوبی با Framework مخلوط باشه واقعا" دشوار تر از درک جزئیات فنی الگوریتمی که با Delphi کامپایل شده .
- عبور یا تخریب حفاظهای نرم افزارهائی که با زبانهای نظیر جاوا و دات نت نوشته میشن به مراتب آسون تر از برنامه هائی است که با امثال دلفی و VC تولید میشن . چرا که اگر از درک جزئیات یک الگوریتم بگذریم ، وابستگی کامل این برنامه ها به یک لایهء میانی به نام زمان اجرا و عدم وابستگی به عناصر زیر ساختی سستم عامل و پردازنده و سخت افزار و همچنین امکانات بیشتر نفوذگران نرم افزار در تغییر محتویات این برنامه ها باعث میشن از این دیدگاه ، برنامه های Native وضع بهتری داشته باشند .
• ( میگذریم از این حقیقت که برای یک حرفه ای ، اهمیت خاصی نداره که یک برنامه با دلفی کامپایل شده یا Managed CPP )
منبع:www.barnamenevise.ir
/س
• - برنامه های اجرائی باینری : برنامه هائی که عموما" با زبانهای سطح بالائی نظیر VC یا دلفی نوشته میشن و به کدهای "مخصوص" به ویندوز/معماری ماشین ( مثلا" Win32/IA32 یعنی ویندوز 32 بیتی روی اینتل 32 بیتی ) ترجمه میشن .
- کتابخانه های اشتراکی : بسته های نرم افزاری که عموما با زبانهای سطح بالا برای کاربری در سایر برنامه ها تولید میشن و وابسته به سیستم عامل و معماری سخت افزاری هستند .
- برنامه های تفسیری : برنامه هائی که قبل از هر بار اجرا باید توسط یک مفسیر ترجمه بشن . به عنوان مثال برنامه های VB6 که بصورت PCode منتشر میشن و هر بار قبل از اجرا توسط VB runtime تفسیر میشن .
- برنامه های مبتنی بر زمان اجرا : برنامه هائی که برای اجرا نیاز به بستر از پیش فراهم شده ای برای روند اجرا دارند . مانند برنامه های دات نت و جاوا .
- درایور ها : کدهای سطح کرنلی که مختص سیستم عامل و معماری سخت افزاری هستند و عموما با زبانهای سطح پائین تولید میشن .
سوال : آیا معنای تئوریک Decompiler برای همه این گروهها محقق شده ؟ میشه ؟ خواهد شد ؟
هیچ Decompiler ای برای گروهای اول و دوم و پنجم ارائه نشده ، نمیشه ، نخواهد شد . یعنی دریافت سورس کد کامل نرم افزارهای اجرائی از نسخه باینری اونها مطلقا" غیر ممکنه . این عدم امکان فنی نیست که در آینده با پیشرفت دانش امکان پذیر بشه ؛ یک نفی منطقی است . یعنی منطقا" امکان باز-تولید سورس کد کامل یک برنامه تولید شده با محیطهائی مثل Delphi یا VC وجود نداشته ، نداره ، نخواهد داشت .
سوال : پس نرم افزارهای متعددی که تحت عنوان Decompiler منتشر میشن چی ؟
جواب : با توجه به تعریف Decompiler ، جواب داده شد .
سوال : در مورد گروه های سوم و چهارم چی ؟
سوال : آیا اصولا" وجود Decompiler لازمه ؟
جواب : برای اهداف مثبت و خیرخواهانه خیر . حتی برای اهداف غیر خیرخواهانه نیز وجود Decompiler یک لازمه نیست . هیچ کسی از وجود ابزاری که بتونه برنامهء او رو به سورس قابل قبولی مبدل کنه خوشحال نخواهد شد ؛ این ابزار کمکی به توسعه نرم افزار نمیکنه و سود اقتصادی ، پیشرفت علمی و افزایش قابلیتهای صنعت نرم افزار رو بیشتر نخواهد کرد . حتی برای اهداف مخرب هم ، وجود چنین ابزاری لازم نیست چون بسیاری از کسانی که در این مسیر فعالیت میکنند برای تخریب امنیت یک نرم افزار نیازی به دست رسی به سورس اون ندارند . کشف نقاط ضعف امنیتی یا عبور از حفاظهای نرم افزار عموما" در محیطهائی اتفاق می افته که سورس وجود نداره و تمام فرآیند تخریب از طریق مهندسی معکوس یا Reverse Engineering انجام میگیرد .
سوال : برنامه هائی که با جاوا و دات نت نوشته میشن چقدر امن هستند ؟
• - بررسی و Trace و بازبینی روند اجرا ی برنامه هائی که با محیطهائی نظیر دات نت و جاوا تولید میشوند ، به مراتب دشوار تر از برنامه هائی است که با محیطهائی نظیر دلفی و VC تولید میشوند؛ چرا که وجود Runtime های بزرگی مانند JRE یا CLR باعث میشه پیچیدگی فراخوانی ها ، مدیریت حافظه ، مدیریت ریسمان ها و پردازه ها و غیرهم به مراتب از برنامه های اصطلاحا" Native ( مانند خروجی های VC ) بیشتر باشه . پس فی المثل درک جزئیات فنی یک الگوریتم ، وقتی با دات نت نوشته شده باشه و به خوبی با Framework مخلوط باشه واقعا" دشوار تر از درک جزئیات فنی الگوریتمی که با Delphi کامپایل شده .
- عبور یا تخریب حفاظهای نرم افزارهائی که با زبانهای نظیر جاوا و دات نت نوشته میشن به مراتب آسون تر از برنامه هائی است که با امثال دلفی و VC تولید میشن . چرا که اگر از درک جزئیات یک الگوریتم بگذریم ، وابستگی کامل این برنامه ها به یک لایهء میانی به نام زمان اجرا و عدم وابستگی به عناصر زیر ساختی سستم عامل و پردازنده و سخت افزار و همچنین امکانات بیشتر نفوذگران نرم افزار در تغییر محتویات این برنامه ها باعث میشن از این دیدگاه ، برنامه های Native وضع بهتری داشته باشند .
• ( میگذریم از این حقیقت که برای یک حرفه ای ، اهمیت خاصی نداره که یک برنامه با دلفی کامپایل شده یا Managed CPP )
سوال : روشهای حفاظتی که برای مقابله با Decompiler ها مورد استفاده قرار میگیره چقدر قابل اعتمادند ؟
منبع:www.barnamenevise.ir
/س