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

[Inprise]

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:

[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 دیکامپایلر دستی و واقعی نوشتم . بنابراین حرف شما وحی منزل نیست که ردخور نداشته باشد .

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

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


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

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


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

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

[typeman9]

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

[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:

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

[whitehat]

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

بهتر بود از تجربیات فعلی خود به صورت عملی می نوشتید ،تا جواب یک پست مربوط به ۱۵ سال پیش را بدهید،
تاپیک قفل و باز نشسته ! شد