درس اول : Debugger - Disassembler - Decompiler

[typeman9]

Decompiler به لحاظ "تئوریک" یعنی ابزاری برای تبدیل یک برنامهء باینری اجرائی یا یک کتابخانه یا درایور به سورس کد اصلی ؛ قبل از ورود به بحث لازمه یک طبقه بندی از موجودیتهائی که ممکنه ذیل عنوان Decompiler مطرح بشن داشته باشیم :

• - برنامه های اجرائی باینری : برنامه هائی که عموما" با زبانهای سطح بالائی نظیر VC یا دلفی نوشته میشن و به کدهای "مخصوص" به ویندوز/معماری ماشین ( مثلا" Win32/IA32 یعنی ویندوز 32 بیتی روی اینتل 32 بیتی ) ترجمه میشن .
  
  - کتابخانه های اشتراکی : بسته های نرم افزاری که عموما با زبانهای سطح بالا برای کاربری در سایر برنامه ها تولید میشن و وابسته به سیستم عامل و معماری سخت افزاری هستند .
  
  - برنامه های تفسیری : برنامه هائی که قبل از هر بار اجرا باید توسط یک مفسیر ترجمه بشن . به عنوان مثال برنامه های VB6 که بصورت PCode منتشر میشن و هر بار قبل از اجرا توسط VB runtime تفسیر میشن .
  
  - برنامه های مبتنی بر زمان اجرا : برنامه هائی که برای اجرا نیاز به بستر از پیش فراهم شده ای برای روند اجرا دارند . مانند برنامه های دات نت و جاوا .
  
  - درایور ها : کدهای سطح کرنلی که مختص سیستم عامل و معماری سخت افزاری هستند و عموما با زبانهای سطح پائین تولید میشن .

سوال : آیا معنای تئوریک Decompiler برای همه این گروهها محقق شده ؟ میشه ؟ خواهد شد ؟
جواب : خیر .

هیچ Decompiler ای برای گروهای اول و دوم و پنجم ارائه نشده ، نمیشه ، نخواهد شد . یعنی دریافت سورس کد کامل نرم افزارهای اجرائی از نسخه باینری اونها مطلقا" غیر ممکنه . این عدم امکان فنی نیست که در آینده با پیشرفت دانش امکان پذیر بشه ؛ یک نفی منطقی است . یعنی منطقا" امکان باز-تولید سورس کد کامل یک برنامه تولید شده با محیطهائی مثل Delphi یا VC وجود نداشته ، نداره ، نخواهد داشت .

سوال : پس نرم افزارهای متعددی که تحت عنوان Decompiler منتشر میشن چی ؟
جواب : با توجه به تعریف Decompiler ، جواب داده شد .

سوال : در مورد گروه های سوم و چهارم چی ؟
جواب : برای این دو گروه Decompiler وجود داشته و داره ؛ با یک توضیح کوچک . برنامه هائی هستند که میتونن از برنامهء اجرائی VB ( به عنوان نماینده گروه سوم ) یک سورس کامل قابل کامپایل تولید کنند ، اما ، این سورس ، لزوما" قرار نیست همان سورسی باشد که توسعه گران نرم افزار تولید کرده اند ؛ برای دات نت ( نمایندهء گروه چهارم ) نیز Decompiler های متعددی وجود داره ؛ اما هیچکدام قول نمیدهند خروجی آنها لزوما" همان سورس کدی باشد که برنامه از آن تولید شده .

سوال : آیا اصولا" وجود Decompiler لازمه ؟
جواب : برای اهداف مثبت و خیرخواهانه خیر . حتی برای اهداف غیر خیرخواهانه نیز وجود Decompiler یک لازمه نیست . هیچ کسی از وجود ابزاری که بتونه برنامهء او رو به سورس قابل قبولی مبدل کنه خوشحال نخواهد شد ؛ این ابزار کمکی به توسعه نرم افزار نمیکنه و سود اقتصادی ، پیشرفت علمی و افزایش قابلیتهای صنعت نرم افزار رو بیشتر نخواهد کرد . حتی برای اهداف مخرب هم ، وجود چنین ابزاری لازم نیست چون بسیاری از کسانی که در این مسیر فعالیت میکنند برای تخریب امنیت یک نرم افزار نیازی به دست رسی به سورس اون ندارند . کشف نقاط ضعف امنیتی یا عبور از حفاظهای نرم افزار عموما" در محیطهائی اتفاق می افته که سورس وجود نداره و تمام فرآیند تخریب از طریق مهندسی معکوس یا Reverse Engineering انجام میگیرد .

سوال : برنامه هائی که با جاوا و دات نت نوشته میشن چقدر امن هستند ؟
جواب : چون نقطهء صفری وجود نداره ، میزانی قابل ارائه نیست ؛ اما در مقام مقایسه :

• - بررسی و Trace و بازبینی روند اجرا ی برنامه هائی که با محیطهائی نظیر دات نت و جاوا تولید میشوند ، به مراتب دشوار تر از برنامه هائی است که با محیطهائی نظیر دلفی و VC تولید میشوند؛ چرا که وجود Runtime های بزرگی مانند JRE یا CLR باعث میشه پیچیدگی فراخوانی ها ، مدیریت حافظه ، مدیریت ریسمان ها و پردازه ها و غیرهم به مراتب از برنامه های اصطلاحا" Native ( مانند خروجی های VC ) بیشتر باشه . پس فی المثل درک جزئیات فنی یک الگوریتم ، وقتی با دات نت نوشته شده باشه و به خوبی با Framework مخلوط باشه واقعا" دشوار تر از درک جزئیات فنی الگوریتمی که با Delphi کامپایل شده .
  
  - عبور یا تخریب حفاظهای نرم افزارهائی که با زبانهای نظیر جاوا و دات نت نوشته میشن به مراتب آسون تر از برنامه هائی است که با امثال دلفی و VC تولید میشن . چرا که اگر از درک جزئیات یک الگوریتم بگذریم ، وابستگی کامل این برنامه ها به یک لایهء میانی به نام زمان اجرا و عدم وابستگی به عناصر زیر ساختی سستم عامل و پردازنده و سخت افزار و همچنین امکانات بیشتر نفوذگران نرم افزار در تغییر محتویات این برنامه ها باعث میشن از این دیدگاه ، برنامه های Native وضع بهتری داشته باشند .

• ( میگذریم از این حقیقت که برای یک حرفه ای ، اهمیت خاصی نداره که یک برنامه با دلفی کامپایل شده یا Managed CPP )

سوال : روشهای حفاظتی که برای مقابله با Decompiler ها مورد استفاده قرار میگیره چقدر قابل اعتمادند ؟
جواب : برای امثال دات نت و جاوا ، تقریبا" هیچ . برای سایر محیطها ، Decompiler دشمن خطرناکی به حساب نمیاد . فی المثل برنامه ای با عنوان DeDe با Delphi Decompiler مدعی است که یک Decompiler برای دلفی است ؛ اما در واقع تو فقط میتونی یک سری اطلاعات دریافت کنی ؛ و نه سورس کد کامل . ممکنه در برخی موارد این اطلاعات بتونه به یک نفوذگر نرم افزاری کمک خاصی بکنه ؛ اما من حیث مجموع ، اینگونه برنامه ها تهدید خطرناکی به حساب نمیان . بگذریم از این واقعیت که یک نفوذگر نرم افزاری برای حذف روتین حفاظتی نرم افزار یا جستجوی یک سرویس برای نقاط ضعف متداول ، نیازی به یک Decompiler نداره . تمام وقایع تلخی که سالهاست شاهدش هستیم داره تحت شرایطی می افته که هیچ Decompiler ضعیفی هم وجود نداره !

موفق و سر بلند باشید

:wise1:

سلام:

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

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

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


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

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


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

ضمنا ابزارهای مهندسی معکوس همیشه موجب شدند که نرم افزارهای اولیه بهتر و بهتر شوند . همین ما هکرها هستیم که باگهای نرم افزارهای سنگین و بی ارزش را کشف می کنیم .