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

سلام؛

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

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

• - هر آنچه بین نرم افزار و حافظه اتفاق می افتد . آدرس دهی متغیرها و توابع ، جایگزینی مقادیر ، تخصیص حافظه و آزاد سازی ، محل دستورات زبان ماشین در حافظه ، داده های در حال ارسال به پردازنده و ...
  
  - وضعیت لحظه به لحظهء پردازنده ؛ محتویات رجیسترها و ...
  
  - هر آنچه بین نرم افزار و کتابخانه هائی که از آن تغذیه میکند واقع میگردد . فراخوانی توابع ، کلاسها یا اشیاء ؛ آدرس کتابخانه ها و توابع مربوطه در حافظه و ...

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

انواع دیباگر ها :: از دید لایهء کاربرد :

• - Application Mode
  - Kernel Mode

دیباگرهای Application Mode فقط به Ring3 و فضای User Mode سیستم عامل دسترسی دارند و امکان Resolve آدرسها فقط در این محدوده برایشان موجود است اما دیباگرهای Kernel Mode یا اصطلاحا" Kernel Debugger ها امکان دسترسی به فضای آدرسی Ring0 یا Kernel Space را نیز دارند و در صورت وجود Symbol file های ، امکان Resolve آدرسها در فضای کرنل نیز برایشان وجود دارد .

از دید نوع عملکرد :

• - Source code Level
  - Assembler Level

دیباگرهای Source Code Level با استفاده از سورس کد برنامه ، وظایف مذکور رو کنترل و بررسی میکنند و عموما" هنگام توسعهء یک نرم افزار ، به خطا یابی یا ایجاد روندهای کنترل خطای منطقی کمک بسیاری میکنند اما دیباگرهای Assembler Level بدون استفاده یا نیاز به سورس کد و صرفا" با داشتن نسخهء باینری ، وظایفشون رو انجام میدن . امکان کنترل کد ، در سطح Assembler وجود دارد یعنی فرضا" میتوانید روی دستوری مانند Call یا Test یا Mov برنامه مورد نظر یک BreakPoint بگذارید .

دیباگرها اولین وسیله مورد استفاده نفوذگران نرم افزاری است فلذا روتین های آنتی دیباگ همیشه یکی از عناوین مطرح در روشها و ابزارهای حفاظت از نرم افزار هستند . این روتینها عموما" از این روشها برای شناسائی دیباگر استفاده میکنند :

• - استفاده از مشخصات فردی دیباگر : نام پرسه ، مشخصات ثبت شده در رجیستری ، مولفه های هدر و ...
  - بررسی حافظه مجازی اختصاص یافته به برنامه و تست وجود دیباگر ( Hook آدرس یا Hook آدرس ِ آدرس ِ توابع دیباگ ویندوز و بررسی وجود پوینتر به آنها یا عدم وجود آن )
  - بررسی پردازنده ( مخصوص روتین های Ring0 )

برای تمامی این Trick ها و روشهائی که از هر کدام منشعب میشود ، نیز ، بالتبع روشهای متقابلی وجود دارد ؛ در مجموع چیزی به عنوان متوقف کردن قطعی همه دیباگر ها منطقا" غیر ممکن است ؛ بهترین روتینهای موجود که هر کدوم با مدتها تحقیق و بررسی ارائه شده اند در کمترین زمان ممکن by Pass شدن . استفاده از روتین های آنتی دیباگ برای حفاظت از نرم افزار روش مناسبی برای کند تر کردن فعالیت نفوذگران تازه کار تر است ، نه چیزی بیشتر .

بجای لیست کردن دیباگرها و توضیحات غیر مفید در مورد هر کدوم ، توصیه های شخصی ام رو مینویسم که صرفا" نشان دهندهء دیدگاه خودم است نه چیز دیگر .

- Windbg : دیباگر مایکروسافت . رابط کاربری نسبتا" خوبی داره و به خوبی با Windows Symbol files متصل میشه . مطمئنا" داشتنش برای کسانی که به هر دلیل به دیباگر نیاز دارند یک ضرورته .

- Ollydbg : قدرتمند ترین دیباگر Assembler Level و Application Mode موجود . اسکریپتهای متعددی برای خودکار سازی بسیاری از وظایف توسط افراد مختلف براش نوشته شده . زندگی بدون Olly برای نفوذگران نرم افزاری قطعا" غیر ممکنه . Olly توسط BCB6 توسعه داده شده/میشه .

- SoftICE : قدرتمند ترین دیباگر Kernel Mode که بصورت همزمان Source Level و Assembler Level نیز هست . بجای تکیه بر رابط کاربری ، دستورات پیچیده ای داره که انعطاف بیشتری به روند دیباگ میده . غیر حرفه ای ها نمیتونن رابطهء خوبی باهاش برقرار کنن . نسخ متعددی داره که هر کدوم رو باید تو یه فضای خاص استفاده کرد . بعدا" ممکنه یه تاپیک مجزا براش ایجاد بشه . Visual SoftICE به عنوان آخرین نسخه ارائه شده ، همراه با DriverStudio ی DevPartnet ارائه میشه و امکانات بصری خوبی به نسخه های سنتی SICE اضافه کرده .

- kd : یا Kernel Debugger ، دیباگر استاندارد DDK ویندوز یا Driver development Kit است . یک Kernel Mode درایور که هم بصورت Assembler Level و هم بصورت Source Level کار میکنه . با SICE قابل مقایسه نیست اما چون سازگاری خوبی با Windows Symbol Files داره ، برای دیباگ درایورها فوق العاده مفیده .

دیباگرهای دیگری هم وجود دارن که هر کدوم ممکنه نسبت به موارد فوق مزایا یا نقائصی داشته باشن ؛ لیکن تجربه نشون میده OllyDBG برای اغلب کاربردها ، SICE برای حرفه ای ها و kd نهایتا" برای توسعه گران Ring0 ، همه نیازها رو برطرف میکنند . این مطلب در ادامه به معرفی ویژگیهای Disassembler ها و Decompiler ها خواهد پرداخت . این مطلب قراره الفبای این حوزه رو به کسانی که باهاش غریبه هستن یاد بده ، نه چیزی بیشتر .

روز خوش

:)

Disassembler ابزار برای تبدیل کدهای زبان ماشین ، به معادل اسمبلی آنهاست . زبان اسمبلی به عنوان یک زبان سطح پائین ، به ازای یک دستور یا اصطلاحا" Instruction به یک دستور زبان ماشین تبدیل خواهد شد فلذا بازگردوندن کد باینری به معادل اسمبلی اون کار چنان دشواری نیست .

سوال : یک برنامه اجرائی ( PE ) تحت ویندوز داریم که با MASM ( یا Macro Assembler ) نوشته شده است . با یک Disassembler آن را به کدهای اسمبلی تبدیل میکنیم . آیا خروجی لزوما" با کد اسمبلی اولیه یکسان خواهد بود ؟

جواب : لزوما" خیر . Disassembler های امروزی عموما" به اندازه کافی هوشمند و خوب هستند اما نمیشه انتظار داشت "هوش" داشته باشند . این ابزارها با استفاده از Knowledge Base ای که برای کامپایلرهای مختلف داخلشون تعبیه شده ، کدهای باینری رو به معادل اسمبلی تبدیل میکنند اما تضمینی وجود نداره توسعه گر اصلی برنامه ، نیز دقیقا" همین کدها رو نوشته باشه . میزان خطای Disassembler ها رابطه مستقیمی با میزان پیچیدگی و سطح بالا بودن زبان داره . یعنی Disasembler با دریافت ورودی که با MASM یا GCC تولید شده خطای کمتری خواهد داشت نسبت به زمانی که قراره فایل باینری تولید شده توسط دلفی یا VC رو بررسی کنه ؛ خصوصا " اگر کتابخانه های مفصلی مثل VCL و MFC هم استفاده شده باشه ؛ لیکن در مجموع میشه تا حدود زیادی به خروجی Disassembler های امروزی برای درک منطق و روند فعالیت برنامه اعتماد کرد.

سوال : Disassembler چه کاربردهائی دارد ؟
جواب : فرض کنید قرار روتین مقایسهء سریال نامبر یک Protection کودکانه رو بررسی کنید . دیباگر بهتون کمک خواهد کرد تا بتونید نقل و انتقال مقادیر بین متغیرها و محل انجام مقایسه رو پیدا کنید ؛ و Disassembler کمک خواهد کرد با مشاهدهء دقیق و تک تک دستورات ، انتخابهای خوبی برای عبور از اون حفاظ یا تولید یک Patch و دستکاری نسخهء باینری برنامه داشته باشید . برای یک نفوذگر نرم افزاری حرفه ای ، مطالعهء خروجی Disassembler از یک روال حفاظتی ، معادل مطالعهء سورس کده !

Disassembler های معتبر و قابل اتکاء تحت ویندوز یعنی IDA Pro و WinDasm و PView ، دارای امکانات دیگری هم هستند :

• - آنالیز کد و ایجاد ارتباطات بصری بین اجزاء و روتینهای مختلف برنامه ؛ نمایش توالی اجرا توابع و کاربری از اشیاء و ...
  - آنالیز کد باینری و تشخیص توابع داخلی بکار برده شده توسط کامپایلرها و ارائه کامنت های مفید
  - ارائه کردن امکانات یک دیباگر در کنار Disassembler
  - و ...

در مجموع ، Disassembler به عنوان دومین ابزار مهم در حوزهء امنیت نرم افزار ، یکی از عناصر لا ینفک یک روند حرفه ای آنالیز و بررسی باینری است . IDA Pro توسط یک تیم توسعه گر هماهنگ و قدرتمند قدرتمند ترین Disassembler موجود در محیط ویندوز است . ( یک نسخهء مبتنی بر لینوکس هم داره ، لیکن انتظارات نسخهء ویندوزی رو نمیشه ازش داشت ) این محصول با Borland C توسعه داده میشه و یک دورهء فشردهء آموزشی اون توسط خود شرکت توسعه گر ، به مدت چهار روز ، برای هر نفر ، چیزی حدود هزار و پانصد دلار هزینه در بر خواهد داشت . WinDasm دیگه تحت توسعه نیست و نسخه های جدیدتری نخواهد داشت . آخرین نسخه رسمی 8.9 است که دو نسخه 9 و 10 هم توسط افرادی که براش Patch هائی نوشتن منتشر شدن . WinDasm مدتها به عنوان ابزار شمارهء یک استفاده شده ( خصوصا با توجه به گرون قیمت بودن IDA ) و بسیاری از مقالات و راهنماهای موجود مبتنی بر اون نوشته شده اند . IDA Pro با داشتن آنالایزر قدرتمند و امکان شناسائی کتابخانه های مختلف ، داشتن پلاگینها متعدد و قابلیتهای بی شمار ( که بی اغراق امکان نداره حتی بشه در غالب یک کتاب در مورد همشون حرف زد ) بهترین گزینهء موجوده هر چند تسلط به اون حتی برای کسانیکه دانش بالائی دارند واقعا" دشوار و پر هزینه خواهد بود .

موفق باشید
:)

سلام
اینجاها رو متوجه نمیشم:

نقل قول:

---

سوال : یک برنامه اجرائی ( PE ) تحت ویندوز داریم که با MASM ( یا Microsoft Assembly ) نوشته شده است . با یک Disassembler آن را به کدهای اسمبلی تبدیل میکنیم . آیا خروجی لزوما" با کد اسمبلی اولیه یکسان خواهد بود ؟

---

این رو میدونیم که هر ماشین کد دقیقا یک دستور معادل اسمبلی داره و هر دستور اسمبلی دقیقا یک ماشین کد معادل. فکر می کنم نتیجه منطقی این یک به یک بودن مجموعه دستورات اسمبلی و ماشین کد -گذشته از دستوراتی مثل NOP- این باشه که برای هر مجموعه دستور ماشین کد فقط و فقط بشه یک مجموعه دستورالعمل اسمبلی پیدا کرد.
البته تا اونجایی که به ذهن من میرسه، تنها یک حالت وجود داره که احتمال به هم ریختن دستورات اسمبلی تولید شده توسط Disassembler وجود داره و اون هم وجود داده ها مابین دستوراته که ممکنه در صورت سوء تعبیر موجب به هم ریختگی دستورات بشه.
حالت دیگه ای غیر این وجود داره؟

نقل قول:

---

این ابزارها با استفاده از Knowledge Base ای که برای کامپایلرهای مختلف داخلشون تعبیه شده ، کدهای باینری رو به معادل اسمبلی تبدیل میکنند

---

مگه ما الان در سطح اسمبلی/ماشین کد نیستیم؟ پس به کامپایلر چی کار داریم؟

نقل قول:

---

فکر می کنم نتیجه منطقی این یک به یک بودن مجموعه دستورات اسمبلی و ماشین کد

---

هر دستور زبان اسمبلی لزوما" به یک دستور زبان ماشین ترجمه میشه ؛ لیکن هر خط کد زبان ماشین رو بسته به شرایط ممکنه بشه به موارد مختلفی تعبیر کرد . پس این ارتباط چندان یک به یک نیست .

نقل قول:

---

مگه ما الان در سطح اسمبلی/ماشین کد نیستیم؟ پس به کامپایلر چی کار داریم؟

---

با توجه به توضیح فوق الذکر ؛ Disassembler باید بدونه کامپایلر چطور کار میکنه ، تا برای یک دستور زبان ماشین "مناسب" ترین معادل اسمبلی رو پیدا کنه . IDA که مخفف Intractive Disassembler هست نه تنها این ویژگی رو داره ؛ بلکه به تو اجازه میده بصورت کاملا" محاوره ای ازش بخای دستورات رو به Assembly تبدیل کنه تا تشخیص هوشمندانه تو یا اطلاعات جانبی که داری بتونه بهش کمک کنه حدس های بهتری بزنه .

نقل قول:

---

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

---

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

دستور mov al, 0x61 یا انتقال عدد 97 به al روی IA32 میتونه چنین معادلی داشته باشه : B061 یا باینری : 101100000110001 ؛ اما این ترجمه زمانی درست انجام میشه که Disassembler بفهمه باید B061 رو اولا" تو بخش کد و دوما" به عنوان کد ماشین در نظر بگیره ؛ دوما" Instruction Set مورد نظر یعنی مثلا" IA32 رو به دقت و با در نظر گرفتن همهء جزئیات پیاده سازی کرده باشه ؛ از اونجائیکه هنوز انسانها برنامهء کامل و بدون نقصی تولید نکرده اند ؛ Disassembler ها هم در اثر پیچیدگیهای نرم افزار ، تفاوت خروجی کامپایلرها مختلف و تفاوتهای جزئی برخی از Binary Encoding های Assembler ها ( مثلا" MASM که مایکروسافت ازش استفاده میکنه و BASM که بورلند ازش استفاده میکنه و تفاوتهاشون ) ایضا" نقائص موجود در پیاده سازی IS باعث میشه Disassembler نتونه همیشه همه چیز رو درست تشخیص بده . به عنوان مثال 10110000 01100001 همواره معادل یک دستور ماشین نیست ؛ فقط به شرطی که در محل مناسب قرار بگیره یک دستور ماشینه در حالیکه داخل برنامه اجرائی وجود داره . برای دیدن این تفاوتها دو تا فایل اجرائی ، یکی ساده و یکی بزرگ و پیچیده رو به هر دوی IDA Pro و WinDasm بده و خروجی ها رو تماشا کن .

نقل قول:

---

اما این ترجمه زمانی درست انجام میشه که Disassembler بفهمه باید B061 رو اولا" تو بخش کد و دوما" به عنوان کد ماشین در نظر بگیره ؛

---

= (تقریبا)

نقل قول:

---

البته تا اونجایی که به ذهن من میرسه، تنها یک حالت وجود داره که احتمال به هم ریختن دستورات اسمبلی تولید شده توسط Disassembler وجود داره و اون هم وجود داده ها مابین دستوراته که ممکنه در صورت سوء تعبیر موجب به هم ریختگی دستورات بشه.

---

thanx

با ولع زیاد منتظر بقیه مطالب هستم

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:

نقل قول:

---

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

---

این در صورتیه که فرض کنیم ماشین مجازی که قراره به عنوان بستر برای برنامه های دسته چهارم مورد استفاده قرار بگیره هم، به عنوان قسمتی از روند Decompile/Trace مورد بررسی قرار بگیره؛ با قبول این فرض، دیگه برنامه های دسته سوم و چهارم نیز فرق زیادی با هم نخواهند داشت.
حقیر فکر می کنم کسی که قراره نرم افزارهای مهندسی معکوس برای این دو دسته از برنامه ها تولید کنه، احتمالا به جای اینکه از دیدگاه CPU به این برنامه ها نیگاه کنه، احتمالا خودش رو به جای VM یا مفسر مربوطه میذاره. ونیز مجددا فکر می کنم به همین دلیله که امکان رسیدن به سورس واسه این دسته از برنامه ها سهل الوصول تره.

نقل قول:

---

کسی که قراره نرم افزارهای مهندسی معکوس برای این دو دسته از برنامه ها تولید کنه، احتمالا به جای اینکه از دیدگاه CPU به این برنامه ها نیگاه کنه، احتمالا خودش رو به جای VM یا مفسر مربوطه میذاره. ونیز مجددا به همین دلیله که امکان رسیدن به سورس واسه این دسته از برنامه ها سهل الوصول تره

---

نرم افزار مهندسی معکوس ؟ این چگونه نرم افزاری ست ؟

-

تفاوت برنامه های VB و دات نت ( به عنوان مثال ) اینه که با اجرای یک برنامه VB کنترل برنامه در اختیار یک محیط Native است اما برنامه های دات نت ( فارغ از JIT ) بصورت مدیریت شده اجرا میشن ، که باعث میشه حجم عظیمی از توابع ، متغیرها و اشیاء بدون قواعد آزاد محیطی مثل IA و مبتنی بر قوانین CLR اجرا میشن که این ، روند ردیابی رو به مراتب دشوار تر میکنه .

نقل قول:

---

ونیز مجددا به همین دلیله که امکان رسیدن به سورس واسه این دسته از برنامه ها سهل الوصول تره.

---

این دو مقوله با هم مرتبط نیستند . برنامه های دات نت به IL و برنامه های جاوا به ByteCode تبدیل میشن ؛ مقوله دسترسی به سورس کد به این مربوطه ؛ پیچیدگی تحلیل ، به Framework و نقش Runtime مربوط است .

با تشکر از مقالات مفید شما :flower:
لطفا در مورد نحوه عملکرد دیباگر ها منبعی معرفی کنید.
ممنون :)

نقل قول:

---

نرم افزار مهندسی معکوس ؟ این چگونه نرم افزاری ست ؟

---

یه اصطلاح "من در آوردی" برای دیکامپایلر و دی اسمبلر.

--

نقل قول:

---

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

---

فرض کنیم که دی کامپایلر رو با توسیع تعریف بالا این شکلی تعریف کنیم: ابزاری است که برای یک برنامه مقصد مقصد (فارغ از زبان آن)، کد مبدئی تولید می کند که در صورت ترجمه (با یک کامپایلر مشخص)، کد حاصله با کد مقصد یکسان خواهد بود.

با این تعریف فکر می کنم دی کامپایل کردن، حداقل در سطح تئوری همیشه ناممکن نباشه. مخصوصا اگه زبان مقصد زبانی باشه که قراره روی یک پردازنده (حقیقی یا مجازی) با مجموعه دستورالعملهای سطح بالاتر استفاده بشه؛ و این اتفاقیه که به نظر می رسه داره تو محیط جاوا، دات نت (در سطح IL) و وی بی میافته.

نقل قول:

---

لطفا در مورد نحوه عملکرد دیباگر ها منبعی معرفی کنید

---

بعدا" یک تاپیک مستقل برای دیباگرها خواهیم داشت .

نقل قول:

---

با این تعریف فکر می کنم دی کامپایل کردن، حداقل در سطح تئوری همیشه ناممکن نباشه. مخصوصا اگه زبان مقصد زبانی باشه که قراره روی یک پردازنده (حقیقی یا مجازی) با مجموعه دستورالعملهای سطح بالاتر استفاده بشه؛ و این اتفاقیه که به نظر می رسه داره تو محیط جاوا، دات نت (در سطح IL) و وی بی میافته

---

مسئله Decompilation همیشه با دو مشکل مواجهه . یکی پیاده سازی "زبان" و دیگری درک "منطق" . یک کامپایلر برای تولید خروجی لزوما" نباید منطق یک برنامه رو درک کنه ؛ اما یک Decompiler باید بتونه روند صحیح عمل بازگشت رو تشخیص بده ، که این بدون داشتن درک نسبی نسبت به منطق برنامه عموما" امکان پذیر نیست . اما تفاوتی که من برای توضیحات مربوط به اون 5 دسته قائل شدم با این "مشکلات" ارتباطی نداشتند . یعنی یک Decompiler برای Delphi و یکی برای دات نت هر دو تا حدودی با هر دو مشکل مواجه هستند . ( در واقع دلیل اینکه نوشتم خروجی دیکامپایلر لزوما" سورس کد اولیه نیست وجود همین دو مسئله است ) دلیل تمایز دیکامپایل برنامه های Native و امثال دات نت و جاوا در یک کلمه خلاصه میشه : جزئیات پیاده سازی کامپایلر . جاوا و دات نت هر دو روی بسترهائی قرار دارند که اصطلاحا" Open Standard هستند . یعنی بسیاری از جزئیات پیکره بندی اونها برای توسعه گران ثالث منتشر شده . جاوا نسخه های سورس آزاد هم داره و دات نت به عنوان یک استاندارد صنعتی ثبت و مشخصات جزئی و فنی CLR منتشر شده . اما دلفی ؟ VC ؟ و امثالهم ؟

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

:wise1:

:flower: :موفق:

با عرض سلام خدمت دوستان عزیز مخصوصا Inprise محترم که مطالب ذیقیمتی رو در اختیار ما قرار دادند . من خیلی خوشحالم که چنین قسمت مهمی در این سایت وجود دارد .
در زمینه امنیت نرم افزاری چند روزی است به همراه دوستان در انجمن Visual Basic مشغول بحث و تبادل نظر هستیم . در این زمینه به این نتیجه رسیدیم که نوعی از حفاظت نرم افزاری موجود است که تنها با Decompilation از بین میرود . مثلا اگر دقت کرده باشید بعضی از نرم افزارها در اولین اجرا در یک کادر به شما یک شماره ارایه کرده و در یک TextBox دیگر از شما یک شماره دیگر می خواهند . برای قرار دادن شماره مطلوب در کنار برنامه یک برنامه دیگر(کرک) قرار دارد که با وارد کردن شماره نمایش داده شده در کادر قبلی شماره مطلوب را در اختیار شما می گذارد . مثلا نرم افزار گرافیکی 3dsmax در اولین اجرا از شما در قبال ارائه یک عدد ، یک عدد دیگر می خواهد . برای بدست آوردن عدد مطلوب برنامه ای به نام Keygen که یک (Crack) است . قرار داده شده که شماره مورد نظر را در اختیار شما می گذارد . با توجه به اینکه 3dsmax با VC ساخته شده است . به چه صورت الگوریتمهای رمز و Encryption ; Decompile شده اند . :oops:
خیلی خوشحال می شویم که نظرات خود را در مورد این بحث با مراجعه به لینک زیر بفرمایید :
http://www.barnamenevis.org/vi...c&start=20
:oops:
با کمال تشکر .

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

خیلی ممنون :)

نقل قول:

---

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

---

بهترین دیباگری که وجود داره همین SI است ! شما برای کار با آن به نظر من به محیط گرافیکی نیازی ندارید ! کافی است دستورات آنرا فرا بگیرید :)
موفق باشید

دوست عزیز فکر کنم خودم میفهمم که اگر دستوراتش رو یاد بگیرم میتونم باهاش کار کنم !! سوالم چیز دیگه ای بود که امیدوارم اساتید کمک کنن :)

نقل قول:

---

نوشته شده توسط Sharif_edu

دوست عزیز فکر کنم خودم میفهمم که اگر دستوراتش رو یاد بگیرم میتونم باهاش کار کنم !! سوالم چیز دیگه ای بود که امیدوارم اساتید کمک کنن :)

---

Hi ,
Have you ever used VISUAL SOFTICE?

Download the latest version of SoftIce and you can use it.
It's compeletly Graphical.

I think the latest version is
Softice Driver Suite 3.2

Regards,
Unreal

SoftICE Driver Suite is a suite of the core device driver tools that accelerate the development and debugging of Windows device drivers. SoftICE now with full Windows XP support enables developers to complete remote debugging. The suite provides a full-featured solution for basic driver development and debugging. Driver developers will be able to build drivers for Windows 2000, Windows NT, Windows 95/98, and Windows XP, and use SoftICE on the target platform for full-featured, interactive debugging.

نقل قول:

---

در این زمینه به این نتیجه رسیدیم که نوعی از حفاظت نرم افزاری موجود است که تنها با Decompilation از بین میرود

---

احتمالا" داری تلاش میکنی نحوهء عملکرد Machine ID و روش Cr@ck اون رو بفهمی ؛ بسیاری از روشهای حفاظتی با استفاده از پارامترهای مختلف ، یک عدد یکتای وابسته به ماشین ، برای هر سیستم تولید میکنند و مبتنی بر اون عدد یکتا و با استفاده از الگوریتم به خصوصی ، کد صحیح ورودی رو تولید میکنند ؛ عموما" وقتی داری از یک Key Generator استفاده میکنی در واقع با یک سیستم مبتنی بر Machine ID روبرو هستی ؛ برای Cr@ck روشهائی از این دست لازم نیست به سورس کد ! دسترسی داشته باشی یا نرم افزار رو Decompile ! کنی ؛ صرفا" کافیه نحوهء تولید Machine ID ( که عموما" زیاد پیچیده نیست ) رو بفهمی و با استفاده از الگوریتم تولید کد صحیح ( مطالعهء باینری و Disassemble باینری اغلب کافیه ) یک KeyGen بنویسی .

عموم روشهای حفاظتی تجاری این روزها مبتنی بر روشهائی از این دست هستند و همونطور که میبینی عبور از اونها چنانکه باید دشوار نیست ؛ معرفی جزئیات روشهای متداول حفاظتی میمونه برای وقتی مناسبتر .

نقل قول:

---

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

---

اصولا" هیچ دیباگر سطح کرنلی نمیتونه از عناصر رابط کاربری ویندوز استفاده کنه ؛ هر چند که kd و SICE تنها بازیگران این عرصه هستند اما اگر روزی گزینهء دیگری هم وجود داشته باشه یقینا" چیزی توی همین مایه هاست ؛ چرا اینطوریه ؟ جوابش رو وقتی بحث دربارهء SoftICE شروع شد میگیری ؛

توضیح : اگر واقعا" نمیتونی از محیط SICE استفاده کنی و اصرار داری یک رابط کاربری بصری داشته باشی میتونی از نسخهء Dual Machine این محصول استفاده کنی ؛ Visual SoftICE کلیهء امکانات SICE استاندارد رو داره به همراه یک رابط کاربری اما محیط کنترل با محیط دیباگ باید از روی دو ماشین مختلف باشند ؛ یعنی از Visual SoftICE روی یک سیستم نمیشه استفاده کرد ؛ به شخصه وقتی درگیری به خصوصی با سخت افزار یا عنصر سخت افزاری خاصی ندارم ، و قراره کدی رو بررسی کنم از Visual SoftICE و VMware استفاده میکنم ؛ کافیه یک پورت پارالل مجازی روی ماشین مجازی ات تعریف کنی و از طریق کنسول مدیریت VSICE روی سیستم Host به دیباگر SICE روی سیستم Target متصل بشی ، هر چند به دلائلی کماکان استفاده از SICE نسخهء Signle Machine قابل توصیه است ؛ باز هم توضیحات فنی اش میمونه برای وقت ی بهتر .

شب خوش :wise2:

از Debugger ها بیشتر بگید خواهشا
مثلا برای Debug کردن Yahoo Messanger و دستیابی به یه سری String چه باید کرد

نقل قول:

---

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

---

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

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

نقل قول:

---

و در هر سه مورد ، هدف بررسی عملکرد نرم افزار از طریق نزدیک شدن به "سورس اولیه" است ، نه تولید سورس کدی که بتونه همون کار رو انجام بده

---

نقل قول:

---

مهم اینه که بفهمی برنامه مورد نظر دقیقا" چطور نوشته شده ، نه اینکه کدی تولید بشه که بتونه مثل اون برنامه کار کنه .

---

خوب اون طوری که من می دونم (که بر اساس گفته های شما رد میشه) :
1)با باینری ما دقیقا برنامه رو در دست داریم.
2)باینری دقیقا میگه که برنامه از نرم افزارها و سخت افزار چه طور استفاده میکنه.
3)تفسیر باینری سخت و وقت گیر ودر مورد پروژه های بزرگ میشه گفت غیر ممکنه.
4)داشتن سورس اولیه بسیار مهمه چون تفسیرش راحتره.(اصلا تفسیر نمیخاد!).
5)تفسیر سورس اولیه راحته چون با یک زبان سطح بالا یا میانه نوشته شده.

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

نقل قول:

---

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

---

False .

اگر به تایتل بخش نگاه کنی نوشته "امنیت نرم افزار" و توضیحاتی که طی دو جواب قبلی دادم به وضوح مشخص میکنه که :

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

- تولید کد مشابه ، ارزشی نداره ، چون میشه فعل A رو به هزار و یک روش انجام داد ، و تو میتونی انواع مختلفی از یک تابع رو به زبان اسمبلی و به اشکال مختلف بنویسی که یک کار رو انجام بده ، اما احتمالا" تعداد معدودی از اونها ممکنه نقیصه امنیتی داشته باشند ، یا اجازه دسترسی های غیر مجاز رو فراهم کنند یا امکان فراخوانی توابع و روتینهای غریبه یا عبور از حفاظهای امنیتی رو ایجاد کنند ، فلذا داشتن صد کد مختلف که دقیقا" یک کار رو میکنند ، برای یک نفوذگر نرم افزاری ، که در حال بررسی یک کد باینری با عملکردی مشابه است مطلقا" ارزش و فایده نداره .

- تو نرم افزار رو بررسی میکنی که دقیقا از خطاها یا نواقص منطقی اون با خبر بشی و بتونی به نحو احسن ، رفتار مورد نظرت رو انجام بدی ؛ تولید کدی که بتونه مثل نرم افزار مورد نظر تو کار بکنه ، کمکی به تو نخواهد کرد ، چون اون فقط داره مثل برنامهء مورد نظرت کار میکنه ، شاید حتی 99 درصد جزئیات پیاده سازی اش هم مشابه نرم افزار مورد نظر تو باشه اما مثلا" یک فراخوانی Sprintf متفاوت که "خروجی" مشابهی ایجاد میکنه میتونه برای نرم افزار اصلی یک نقیصه به حساب بیاد در حالیکه ممکنه نرم افزار دوم که به روشی مصنوعی تولید شده حاوی این نکته نباشه .

- در یک کلام ، هدف باز تولید ، چیزی که "مانند" هدف باشه ، نیست . موضوعیت این مبحث ، نزدیک شدن به "خود" هدف است ، همانطور که پیاده سازی شده ، نه آنطوری که ما فکر میکنیم ممکنه پیاده سازی شده باشه .

موفق باشی

خوب ببینید وقتی یک هکر میتونه با یک دیباگر کد یک برنامه رو برسی کنه و شیوه ی عمل برنامه رو
پیدا کنه یک برنامه هم میتونه این کار رو انجام بده . مشکل هکر اینه که در انبوهی از کدهای سطح
پایین که تفسیرشون با ذهن انسان کند و بسیار وقت بر و در نتیجه در بسیاری از موارد امکان ناپذیر
به نظر میرسه گیر میکنه که این نوع مشکلات برای نرم افزار وجود نداره .
ببینید منظور من از اینکه میگم برنامه ی ما مثل برنامه ی اصلی کار کنه این نیست که مثلا اگه برنامه ی
اصلی یه فرم داره که روش یک edit هست که باید توش یه ID وارد کنیم برنامه ی ما هم همینطور باشه
بلکه نه تنها باید همینطور باشه بلکه اگر برنامه ی اصلی به صورت Run time از منبع X برای تولید فرم و
ادیت استفاده میکنه برنامه ی ما هم همین کار رو انجام بده.
در واقع هر عملیات همون طور شبیه سازی بشه که در برنامه ی اصلی انجام میشه.
منظور من از شبیه بودن برنامه ی ما و برنامه ی اصلی شبیه بودن در عملکرد سطح پایین بوده علاوه بر
عملکرد سطوح بالا.
خوب منتظر راهنمایی های شما هستم.

نقل قول:

---

نوشته شده توسط Inprise

احتمالا" داری تلاش میکنی نحوهء عملکرد Machine ID و روش Cr@ck اون رو بفهمی ؛ بسیاری از روشهای حفاظتی با استفاده از پارامترهای مختلف ، یک عدد یکتای وابسته به ماشین ، برای هر سیستم تولید میکنند و مبتنی بر اون عدد یکتا و با استفاده از الگوریتم به خصوصی ، کد صحیح ورودی رو تولید میکنند ؛ عموما" وقتی داری از یک Key Generator استفاده میکنی در واقع با یک سیستم مبتنی بر Machine ID روبرو هستی ؛ برای Cr@ck روشهائی از این دست لازم نیست به سورس کد ! دسترسی داشته باشی یا نرم افزار رو Decompile ! کنی ؛ صرفا" کافیه نحوهء تولید Machine ID ( که عموما" زیاد پیچیده نیست ) رو بفهمی و با استفاده از الگوریتم تولید کد صحیح ( مطالعهء باینری و Disassemble باینری اغلب کافیه ) یک KeyGen بنویسی .

توضیح : اگر واقعا" نمیتونی از محیط SICE استفاده کنی و اصرار داری یک رابط کاربری بصری داشته باشی میتونی از نسخهء Dual Machine این محصول استفاده کنی ؛ Visual SoftICE کلیهء امکانات SICE استاندارد رو داره به همراه یک رابط کاربری اما محیط کنترل با محیط دیباگ باید از روی دو ماشین مختلف باشند ؛ یعنی از Visual SoftICE روی یک سیستم نمیشه استفاده کرد ؛
شب خوش :wise2:

---

سلام
به مورد بالا Remote Debugging میگن.
ضمنا معمولا برنامه هایی که با اکتیویشن کی فعال میشن یا میشه فرمول بدست آوردن کدشون رو بدست آورد یا فرمول MachineID شون رو یا اینکه در صورت امکان قسمت تست کلید ورودی رو غیر فعال کرد (patch کردن). اینکار میتونه به سادگی گذاشتن چند تا nop یا یک jmp باشه یا خیلی سخت تر و مشکلتر مثل غیر فعال کردن کدهای آنتی دیباگ، بازکردن کد اجرایی فشرده شده و...
در مورد دیکمپایل کردن کدهای ماشین به اسمبلی هم همونطور که فرمودید الزاما به کد اولیه نمیرسیم. مثلا قدیما در توربو پاسکال تحت داس چون این کامپایلر نمیتونست برای سی پی یو های ۳۲ بیتی (386 به بالا) کد خروجی بده مجبور بودیم برای نوشتن کد زیر :

mov eax,ebx

از کد زیر استفاده کنیم :

db 66h
mov ax,bx

حقه جالبی بود. در واقع 66h پیشوند Instruction های 32 بیتی در زبان ماشین بود. از نظر اسمبلر داخلی توربو پاسکال این یک کد ۱۶ بیتی است اما از نظر برنامه در حال اجرا یک کد ۳۲ بیتی خواهد بود.

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

ممنون علی

با سلام به آقای اینپرایز عزیز و معذرت به خاطر دوری طولانی مدت. و ممنون از این بحثی که آغاز شده.
در زیر به چند روش اولیه برای antidebugging اشاره میکنم.
1 :تابع isdebuggerpresent: (kernel32.dll)
این تابع مشخص میکند که آیا پروسه ما تحت یک دیباگر صورت میگیرد یا خیر.
مقدار بازگشتی : اگز جواب بله باشد <>0 در غیر اینصورت =0 میباشد.
(فقط با دیباگر های سطح ring3 عمل میکند)
.586p

.model flat

extrn GetProcAddress:PROC

extrn GetModuleHandleA:PROC

extrn MessageBoxA:PROC

extrn ExitProcess:PROC

.data

szTitle db "IsDebuggerPresent Demonstration",0

msg1 db "Application Level Debugger Found",0

msg2 db "Application Level Debugger NOT Found",0

msg3 db "Error: Couldn't get IsDebuggerPresent.",10

db "We're probably under Win95",0

@IsDebuggerPresent db "IsDebuggerPresent",0

K32 db "KERNEL32",0

.code

antidebug1:

push offset K32 ; Obtain KERNEL32 base address

call GetModuleHandleA

or eax,eax ; Check for fails

jz error

push offset @IsDebuggerPresent ; Now search for the existence

push eax ; of IsDebuggerPresent. If

call GetProcAddress ; GetProcAddress returns an

or eax,eax ; error, we assume we're in

jz error ; Win95

call eax ; Call IsDebuggerPresent

or eax,eax ; If it's not 0, we're being

jnz debugger_found ; debugged

debugger_not_found:

push 0 ; Show "Debugger not found"

push offset szTitle

push offset msg2

push 0

call MessageBoxA

jmp exit

error:

push 00001010h ; Show "Error! We're in Win95"

push offset szTitle

push offset msg3

push 0

call MessageBoxA

jmp exit

debugger_found:

push 00001010h ; Show "Debugger found!"

push offset szTitle

push offset msg1

push 0

call MessageBoxA

exit:

push 00000000h ; Exit program

call ExitProcess

end antidebug1


2: توقف application level debugger با SEH :
در ابتدا FS را ذخیره میکنیم .
push dword ptr fs:[0]
و اکنون زمان ان است که شی را وادار کنیم به handler ما اشاره کند.
push offset SEH_Handler

mov fs:[0],esp
برای برگرداندن SEH این دوشتور را انجام دهید.
pop dword ptr fs:[0]
مثال :
(نحوه کامپایل : tasm32 /m3 /ml sehtest,,;

tlink32 /Tpe /aa sehtest,sehtest,,import32.lib
)

.386p

.model flat ; Good good... 32 bit r0x0r

extrn MessageBoxA:PROC ; Defined APIs

extrn ExitProcess:PROC

.data

szTitle db "Structured Exception Handler example",0

szMessage db "Intercepted General Protection Fault!",0

.code

start:

call setupSEH ; The call pushes the offset

; past it in the stack rigth?

; So we will use that :)

exceptionhandler:

mov esp,[esp+8] ; Error gives us old ESP

; in [ESP+8]

push 00000000h ; Parameters for MessageBoxA

push offset szTitle

push offset szMessage

push 00000000h

call MessageBoxA

push 00000000h

call ExitProcess ; Exit Application

setupSEH:

push dword ptr fs:[0] ; Push original SEH handler

mov fs:[0],esp ; And put the new one (located

; after the first call)

mov ebx,0BFF70000h ; Try to write in kernel (will

mov eax,012345678h ; generate an exception)

xchg eax,[ebx]

end start
.386p

.model flat ; Good good... 32 bit r0x0r

extrn MessageBoxA:PROC ; Defined APIs

extrn ExitProcess:PROC

.data

szTitle db "Structured Exception Handler example",0

szMessage db "Intercepted General Protection Fault!",0

.code

start:

call setupSEH ; The call pushes the offset

; past it in the stack rigth?

; So we will use that :)

exceptionhandler:

mov esp,[esp+8] ; Error gives us old ESP

; in [ESP+8]

push 00000000h ; Parameters for MessageBoxA

push offset szTitle

push offset szMessage

push 00000000h

call MessageBoxA

push 00000000h

call ExitProcess ; Exit Application

setupSEH:

push dword ptr fs:[0] ; Push original SEH handler

mov fs:[0],esp ; And put the new one (located

; after the first call)

mov ebx,0BFF70000h ; Try to write in kernel (will

mov eax,012345678h ; generate an exception)

xchg eax,[ebx]

end start
(بازم در مقابل SI نمی تواند عمل کند)

3: شناسایی SI :در win9x
سرویس vmm به نام get_ddb . (00010146 h) :
mov eax, Device_ID

mov edi, Device_Name

int 20h ; VMMCall Get_DDB

dd 00010146h

mov [DDB], ecx
این تابع مشخص میکند که ایا vxd برای وسیله مورد نظر نصب شده است. در صورت نسب بودن یک ddb برای ان بر میگرداند.
Device_ID : device identifier (این پارامتر برای توابع مبتنی بر نام صفر قرار بگیرد)
Device_Name: An eight-character device name that is padded with blank

characters. This parameter is only required if Device_ID is zero. The

device name is case-sensitive.

خوب ممکنه براتون شگفت انگیز باشه که این کد کار میکنه. فیلد Device_ID . vxd ی که SI نصب میکند همیشه ثابت است و میتوانیم از این موضوع برای شناساییSi بهره ببریم.
این مقدار 202h است.
mov eax,00000202h

VxDCall VMM_Get_DDB

xchg eax,ecx

jecxz NotSoftICE

jmp DetectedSoftICE

4: شناسایی SI :در win9x روش 2

وقفه 2fh :
INT 2F - MS Windows - GET DEVICE API ENTRY POINT
AX = 1684h
BX = virtual device (VxD) ID (see #1921)
ES:DI = 0000h:0000h
Return: ES:DI -> VxD API entry point, or 0:0 if the VxD does not support an API
Note: some Windows enhanced-mode virtual devices provide services that
applications can access. For example, the Virtual Display Device
(VDD) provides an API used in turn by WINOLDAP.
بنابراین شما در bxکافی است 202h قرار دهید تا وجود si را ثابت کنید.

4: شناسایی SI : عمومی

استفاده از تابع : createfile
.586p

.model flat

extrn CreateFileA:PROC

extrn CloseHandle:PROC

extrn MessageBoxA:PROC

extrn ExitProcess:PROC

.data

szTitle db "SoftICE detection",0

szMessage db "SoftICE for Win9x : "

answ1 db "not found!",10

db "SoftICE for WinNT : "

answ2 db "not found!",10

db "(c) 1999 Billy Belcebu/iKX",0

nfnd db "found! ",10

SICE9X db ".SICE",0

SICENT db ".NTICE",0

.code

DetectSoftICE:

push 00000000h ; Check for the presence of

push 00000080h ; SoftICE for Win9x envirome-

push 00000003h ; nts...

push 00000000h

push 00000001h

push 0C0000000h

push offset SICE9X

call CreateFileA

inc eax

jz NoSICE9X

dec eax

push eax ; Close opened file

call CloseHandle

lea edi,answ1 ; SoftICE found!

call PutFound

NoSICE9X:

push 00000000h ; And now try to open SoftICE

push 00000080h ; for WinNT...

push 00000003h

push 00000000h

push 00000001h

push 0C0000000h

push offset SICENT

call CreateFileA

inc eax

jz NoSICENT

dec eax

push eax ; Close file handle

call CloseHandle

lea edi,answ2 ; SoftICE for WinNT found!

call PutFound

NoSICENT:

push 00h ; Show a MessageBox with the

push offset szTitle ; results

push offset szMessage

push 00h

call MessageBoxA

push 00h ; Terminate program

call ExitProcess

PutFound:

mov ecx,0Bh ; Change "not found" by

lea esi,nfnd ; "found"; address of where

rep movsb ; to do the change is in EDI

ret

end DetectSoftICE

سلام
جای یه توضیح کلی و اساسی در مورد لودرها جدا" خالیه

با سلام خدمت Inprise عزیز و کلیه دوستان
من برنامه نویس دات نت هستم ، حدود 3 سالی هست با یکی از دوستانم در حال توسعه سیستم مالی هستیم که تازه الان آماده ارائه شده و برای تامین امنیت کد دات نت ام اقدام به مطالعه مطالب این تاپیک و تاپیکهای مشابه کردم .
متاسفانه از صحبتهای شما این برداشت را میکنم که برای کدهای دات نت هیچگونه امنیتی نمیتوانم بر قرار کنم ، یعنی اگر هر کاری هم بکنم برنامه قابل Decompile شدن هست و نتیجه اینکه میشود با حذف بخشهای چک کردن قفل و موارد مشابه مجدد کامپایل شود .

آیا برای برنامه های دات نت راهی وجود دارد که حداقل این پروسه سخت یا حتی غیر ممکن شود ؟

با توجه بهDecompile شدن اینگونه برنامه ها اگر کسی نسبت به کد برنامه اش حساس باشد توصیه میکنید با Delphi کد بنویسد ؟

و یک سوال دیگر اینکه چرا کلیه کدهای مقابل با دیباگ ، دامپ و ... به زبان دلفی است ؟

اگر اول کمی جستجو میکردید حتما" جواب میگرفتید. !!!!

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

نقل قول:

---

نوشته شده توسط bad_boy_2007

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

---

Xenocode != Xeno
دوست عزیز "هر سخن جایی و هر نکته مکانی دارد"
حداقل برای سواتون یه تاپیک جدید باز میکردید
بحث این تاپیک آموزشی هست نه پاسخ به سوالات
تاپیک های امضا بنده هم بی جواب مونده و کسی نیست جوابشون رو بده درسته که من الان همین جا بپرسم ؟؟

در این مورد حق با شماست ، ببخشید اگه تو تاپیک اشتباهی سوالم رو مطرح کدم . :چشمک:

نقل قول:

---

نوشته شده توسط 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:

---

سلام:

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

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

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


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

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


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

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

نقل قول:

---

نوشته شده توسط 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:

---

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

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

نقل قول:

---

نوشته شده توسط typeman9

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

---

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