Tutorial 1: Overview of PE file format
خودآموز 1 : مروری بر فرمت فایل پی (معماری فایلهای مربوط به نرم افزارها و درایورها و بازیها و کتابخانه های ویندوز و اجزای کنترل پنل و محافظ صفحه نمایش (اسکرین سیور) و اکتیو ایکس )
This is the complete rewrite of the old PE tutorial no1 which I considered the worst tutorial I have ever written. So I decided to replace it with this new one.
این یک بازنویسی کامل از خودآموز قدیمی شماره ی 1 فایلهای پی می باشد که من (ایکزیلیون ) انرا بعنوان بدترین خوداموزی که تا بحال نوشته ام در نظر گرفتم .
بنابراین من تصمیم گرفتم انرا با این خوداموز جدید جایگزین کنم .
+
)
توضیح مترجم : هویت این جناب ایکزیلیون Iczelion ، معلوم نیست و احتمالا ایشان یک هکر کلاه سفید فرانسوی یا ژاپنی می باشد .
طبق داده های جدید معلوم شد ایشان یک هکر کلاه سفید ژاپنی می باشند .
ایشان جزو اولین کسانی است که نهضت احیای زبان برنامه نویسی اسمبلی را در اوایل دهه ی 90 میلادی بنیانگذاری نمود و در سایت رسمی اش صدها نرم افزار ویندوزی که بطور کامل توسط زبان اسمبلی نوشته شده بودند و دهها فایل آموزشی را آپلود کرده بود .
سایت ایشان یک سایت بسیار بزرگ و فاخر و یک مرجع آموزشی بسیار ارزشمند بود و عملا سایر سایتهای مربوط به زبان اسمبلی را نیز به کاربر معرفی می کرد و من حتی از طریق سایت ایشان با اسمبلر روسسم آشنا شدم .
منابع آموزشی ایشان ابتدا توسط خودش برای اسمبلر مسم و سپس توسط دیگران برای اسمبلر نسم و بعد روسسم و سپس برای فلت اسمبلر بازنویسی شدند .
(به دلایل نامعلوم امکان تایپ لغات انگلیسی در لابلای متون فارسی مقدور نمی باشد )
متاسفانه سایت رسمی ایشان توسط دولت ایران فیلتر شد و حتی توسط دشمنان آزادی کاربر( مایکروسافت و شرکای اش ) و دشمنان زبان اسمبلی نیز بطور کامل از وب حذف گردید .
بدبختانه هم شرکت مایکروسافت و شرکای تجاری اش و هم افراد و شرکتها و سایتهای مختلف به بهانه های مختلف اقدام به نابودی این سایت نمودند
( خدا همه ی اینها را لعنت کند )
سایت ایشان با نام " افق اسمبلی " عملا بزرگترین مرجع اموزش برنامه نویسی با زبان اسمبلی تحت ویندوز ، بود و من دقیقا از طریق همین سایت توانستم روش برنامه نویسی با زبان اسمبلی تحت ویندوز را یاد بگیرم .
متاسفانه امروزه هیچ اثری از سایت ایشان یافت نمی شود و عملا زحمات ایشان برباد رفت .
لعنت خدا بر دشمنان آزادی
بسیاری از خودآموزهای زبان اسمبلی ابتدا توسط ایشان تهیه و تدوین شدند و بعدها توسط سایر افراد بازنشر شدند
من ( وحید محمدی مدیر وبلاگ وحیدمی ) در جهت احیای زبانهای اسمبلی و ماشین و جبران زحمات این شخص و قدردانی از زحمات و تلاشهای انساندوستانه ی این انسان شریف ، و اهدای آزادی به کاربران و نابودی انحصار و استبداد نرم افزاری ، قصد دارم به کوری چشم مایکروسافت و سایر دشمنان زبان اسمبلی ، این زبان و البته زبان ماشین را در وب فارسی احیا و تدریس نمایم
این مجموعه ی آموزشی مربوط به فرمت فایلهای اجرایی ویندوز نیز جزو کارهای خاص جناب ایکزیلیون می باشد .
ایکزیلیون همانطور که گفتم احتمالا یک هکر کلاه سفید مقیم فرانسه می باشد .
البته سالهاست که هیچ کار جدیدی از ایشان در وب یافت نشده است
(
ادامه ی ترجمه:
PE stands for Portable Executable.
پی مخفف عبارت "فایل اجرایی قابل حمل " می باشد
(قابل حمل روی تمام نسخه های ویندوز و تمام پردازنده های سازگار با ویندوز شامل اینتل و سایر پردازنده ها )
It's the native file format of Win32.
آن فرمت فایل بومی ویندوز 32 بیتی می باشد
Its specification is derived somewhat from the Unix Coff (common object file format).
خصوصیات اش از یونیکس کاف مشتق شده است (کاف مخفف عبارت فرمت فایل هدف مشترک می باشد )
(توضیح مترجم: تمام سیستم عاملهای امروزی اعم از داس و فری داس و ویندوز و لینوکس و اندروید و بی اس دی یونیکس و نت بی اس دی و فری بی اس دی و اوپن بی اس دی و مک او اس و آی او اس و ....... همگی فرزندان سیستم عامل مولتیکس می باشند . این کاف نیز از مولتیکس به یونیکس و از یونیکس به ویندوز به ارث رسیده است )
ادامه ی ترجمه:
The meaning of "portable executable" is that the file format is universal across win32 platform: the PE loader of every win32 platform recognizes and uses this file format even when Windows is running on CPU platforms other than Intel.
معنای عبارت قابل حمل اینست که فرمت فایل ، پلتفرم وین 32 سرتاسر جهانی است : بارکننده ی فایل پی، از هر پلفترم وین32 این فرمت فایل را تشخیص می دهد و بکار می برد حتی هنگامیکه ویندوز در حال اجرای روی پلفترمهای پردازنده ی غیر از اینتل باشد .
It doesn't mean your PE executables would be able to port to other CPU platforms without change.
این حرف بدین معنا نیست که فایلهای اجرایی تان می تواند به سایر پلتفرمهای پردازنده ، بدون هیچگونه تغییر ؛ پورت شود .
(توضیح مترجم : با کمک زبان ماشین (هگز ادیتور) و تغییر دادن برخی از کدهای هگز ، می توان نرم افزارهای ویندوزی و حتی خود سیستم عامل ویندوز را بر روی انواع پردازنده ها پورت نمود . کافیست بجای کد هگز مربوط به پردازنده ی اینتل ، کدهای هگز مربوط به سایر پردازنده ها را رونویسی نماییم و به سبک این پردازنده ها آدرسدهی نماییم . البته اینکار دشواریهای فراوان دارد . مثلا باید یاد بگیریم که هرپردازنده ، بایتهای نرم افزار را به چه شکلی می چیند و ردیف می کند . بعنوان مثال پردازنده ی موتورولا ترتیب بایتها را به شکل مستقیم و ساده می چیند لذا سرعت اجرای نرم افزارهای این پردازنده از سرعت اجرای نرم افزارهای پردازنده ی اینتل بیشتر است زیرا همه چیز در پردازنده ی اینتل بصورت معکوس است اما در موتورولا همه چیز بصورت مستقیم است .
در مورد پردازنده ی پاورپی سی که معمولا در سوپرکامپیوترها بکار می رود باید بگویم که این پردازنده تعداد بسیار زیادی رجیستر دارد و عملا محدودیتهای اینتل را ندارد و فرزند پردازنده ی موتورولا می باشد یعنی بایتها را بصورت مستقیم می خواند و اجرا می کند لذا سرعت و قدرت و انعطاف پذیری و مانوردهی پردازنده ی پاورپی سی بسیار بسیار بیشتر از پردازنده ی اینتل می باشد . لذا بهترین گزینه برای بکارگیری در سوپرکامپیوترها می باشد و مهمترین مطلب اینست که باید با معماری و شیوه های آدرسدهی و زبان اسمبلی این پردازنده ها نیز کاملا آشنا باشیم که این نیز کاری بسیار دشوار و وقتگیر ولی ارزشمند است . ) .
Every win32 executable (except VxDs and 16-bit Dlls) uses PE file format.
هر فایل اجرایی وین32 (به استثنای فایلهای وی ایکس دی و دی ال ال های 16 بیتی ) ، فرمت فایل پی را بکار می برد .
Even NT's kernel mode drivers use PE file format.
حتی درایورهای مدل کرنل ویندوز ان تی نیز فرمت فایل پی را بکار می برند .
(توضیح مترجم: منظور از درایورهای مدل کرنل یعنی درایورهایی که از دسترس برنامه نویس خارج می باشند و به هسته ی مرکزی سیستم عامل تعلق دارند و عملا هسته ی مرکزی ویندوز را تشکیل می دهند . این درایورها معمولا پسوند سیز یا دی ال ال دارند . عملا هیچ برنامه نویس حتی برنامه نویسان زبانهای سطح پایین جرات نمی کنند با اینگونه درایورها زیاد سروکله بزنند چون ممکن است اتفاقات ناگوار برای ویندوز رخ دهد.
تنها ابزاری که با کمک ان می توانستیم این نوع درایورها را دیباگ نماییم سافت آیس بود که با حیله ی مایکروسافت ، عملا امکان نصب و اجرای این نرم افزار قدرتمند بر روی ویندوزهای 98 به بالا وجود ندارد مگه با حیله و کلک (کرک) !! ) .
Thus studying the PE file format gives you valuable insights into the structure of Windows.
همچنین مطالعه ی فرمت فایل پی ، به شما چشم باطن (دیده ی بصیرت یا چشم سوم ) برای مشاهده ی اندرون ساختمان ویندوز را هدیه می دهد .
(یعنی اگر بر ساختمان فایلهای پی مسلط شوید بر کل سیستم عامل ویندوز مسلط می شوید و از تمام اسرار ویندوز اگاه می شوید و حتی می توانید از روی ویندوز یک سیستم عامل مشابه اما جدید و سفارشی برای خودتان یا برای مردم بسازید و از ویندوز برای همیشه بی نیاز شوید . مثل سیستم عامل ری اکت او اس . )
Let's jump into the general outline of PE file format without further ado.
اجازه دهید به درون شالوده ی کلی فرمت فایل پی بدون گفتار اضافی پرش کنیم .
|
DOS MZ header |
|
DOS stub |
|
PE header |
|
Section table |
|
Section 1 |
|
Section 2 |
|
Section ... |
|
Section n |
The above picture is the general layout of a PE file.
تصویر بالا آرایش کلی یک فایل پی می باشد .
All PE files (even 32-bit DLLs) must start with a simple DOS MZ header.
تمام فایلهای پی ( حتی دی ال ال های 32 بیتی ) باید با یک هدر ساده ی داس شروع شوند .
ام زد یعنی مارک زبیکوسکی . ایشان یکی از معماران اصلی سیستم عامل ام اس داس بود .
We usually aren't interested in this structure much.
ما معمولا زیاد به این ساختار علاقه مند نشده ایم (چندان از آن خوشمان نیامده است ) .
It's provided in the case when the program is run from DOS, so DOS can recognize it as a valid executable and can thus run the DOS stub which is stored next to the MZ header.
این ساختار برای مواردی فراهم شده که برنامه بخواهد از طریق سیستم عامل داس اجرا شود ، بنابراین سیستم عامل داس می تواند انرا بعنوان یک فایل اجرایی معتبر ، تشخیص دهد و همچنین می تواند اجرا کند ریشه ی داس را که ( این ریشه ی داس ) در نزدیک هدر ام زد ( هدر داس ) انباشته شده است .
The DOS stub is actually a valid EXE that is executed in case the operating system doesn't know about PE file format.
ریشه ی داس حقیقتا یک فایل اجرایی معتبر است که اجرا شده است در موردی که سیستم عامل ( داس ) چیزی در مورد فرمت فایل پی نمی داند .
It can simply display a string like "This program requires Windows" or it can be a full-blown DOS program depending on the intent of the programmer.
این برنامه به سادگی می تواند یک رشته کاراکتر مانند این را که می گوید " این برنامه به ویندوز نیاز دارد " را نمایش دهد یا او می تواند بسته به مرام ( قصد یا هدف ) برنامه نویس ، یک برنامه ی متورم داس باشد.
We are also not very interested in DOS stub: it's usually provided by the assembler/compiler. In most case, it simply uses int 21h, service 9 to print a string saying "This program cannot run in DOS mode".
ما همچنین خیلی علاقه مند نیستیم به ریشه ی داس : او معمولا بوسیله ی اسمبلر یا کامپایلر فراهم ( تولید ) می شود .
در بیشتر موارد ، او به سادگی وقفه ی اینت 21 اچ ، سرویس 9 را برای چاپ یک رشته ی کاراکتر که می گوید " این برنامه نمی تواند در مدل داس اجرا شود " بکار می برد .
After the DOS stub comes the PE header.
بعد از ریشه ی داس ، نوبت به پی هدر می رسد .
The PE header is a general term for the PE-related structure named IMAGE_NT_HEADERS.
هدر پی یک اصطلاح عمومی برای ساختار وابسته به فایل پی می باشد که نام این ساختار اینست :
IMAGE_NT_HEADERS.
This structure contains many essential fields that are used by the PE loader.
این ساختار فیلدهای اصلی فراوانی
را شامل می شود که توسط پی لودر بکار گرفته شده اند .
We will be quite familiar with it as you know more about PE file format.
ما چنانچه شما چیزهای بیشتری درباره ی فرمت فایل پی بدانید کاملا با این ساختار آشنا خواهیم شد .
In the case the program is executed in the operating system that knows about PE file format, the PE loader can find the starting offset of the PE header from the DOS MZ header.
در موردیکه برنامه اجرا شده است در سیستم عاملی که فرمت فایل پی را می شناسد ، پی لودر می تواند پیدا کند آفست شروع هدر پی را از داس ام زد هدر .
( مترجم : آفست یعنی آدرس یک کد هگز نسبت به نقطه ی شروع . به عبارت دیگر فرق بین آدرس و آفست در اینست که آدرس می تواند از هر جایی شروع شود ولی آفست فاصله ی یک کد با نقطه شروع می باشد .
در اینجا و در این مکان از معماری نرم افزار ، آفست ، فاصله ی پی هدر از داس هدر می باشد . درواقع آفست نوعی خاص از ادرس است که فاصله ی معینی از یک نقطه ی شروع دارد و یک مقدار معینی از کدها را در بر می گیرد . در حالیکه آدرس یک چیز مستقل است و ربطی به نقطه ی شروع ندارد و کاملا سیار است و در هر جایی می تواند بکار رود . به همین جهت در برنامه نویسی با زبان ماشین خصوصا در ویندوز ، ما به ادرسها بیشتر توجه می کنیم و به ندرت با افست سروکار داریم . چون سیستم آدرسدهی در ویندوز یک سیستم هوشمند و پویا می باشد و هیچ مکان خاص یا فاصله ی خاصی را در برنمی گیرد . )
Thus it can skip the DOS stub and go directly to the PE header which is the real file header.
از این رو ، او می تواند ریشه ی داس را دور بزند و مستقیما به پی هدر برود که فایل هدر واقعی می باشد .
( مترجم : منظور از پی هدر همان فایل هدر می باشد ) .
The real content of the PE file is divided into blocks called sections.
محتوای واقعی فایل پی ( نرم افزار ویندوزی ) به بلوکهایی که سکشن نامیده شده اند تقسیم شده است .
(سکشن یعنی فصل - باند - بخش - قسمت - بلوک )
A section is nothing more than a block of data with common attributes such as code/data, read/write etc.
یک سکشن چیزی بیشتر از یک بلوک از داده های حاوی صفات مشترک نیست : صفاتی از قبیل : کد / داده ، خواندن / نوشتن و غیره .
( طبق این تعریف : سکشن یعنی دسته ای از داده ها که دارای صفات مشترک می باشند ) .
You can think of a PE file as a logical disk.
شما می توانید یک فایل پی ( نرم افزار قابل حمل ) را بعنوان یک دیسک منطقی تصور نمایید .
The PE header is the boot sector and the sections are files in the disk.
با این تصور ، پی هدر در نقش سکتور بوت و سکشن ها در نقش فایلهای روی این دیسک (خیالی) ظاهر می شوند.
The files can have different attributes such as read-only, system, hidden, archive and so on.
فایلها می توانند صفات متفاوت از قبیل فقط -خواندنی ، سیستمی ، مخفی ، آرشیوی و غیره داشته باشند .
I want to make it clear from this point onwards that the grouping of data into a section is done on the common attribute basis: not on logical basis.
من می خواهم این مفهوم را آسانتر نمایم از این نقطه به بعد که گروهبندی داده به درون یک سکشن ، براساس صفات مشترک بنیان شده است : نه براساس اصول منطقی .
( یعنی براساس عقل و منطق گروهبندی نشده اند و صرفا براساس برخی صفات مشترک گروهبندی شده اند ) .
It doesn't matter how the code/data are used , if the data/code in the PE file have the same attribute, they can be lumped together in a section.
مهم نیست که کد یا داده چگونه بکار می روند ، اگر کد یا داده در فایل پی ، صفات مشترک داشته باشند ، آنوقت اینها می توانند با یکدیگر قلنبه و فشرده شوند در درون یک سکشن .
(توضیح مترجم : چیزی شبیه به سکشن فلت که توسط فلت اسمبلر ساخته می شود !!! البته فلت اسمبلر هرگز کد و داده را با هم مخلوط نمی کند و مرز بین این دو را مشخص می نماید و صرفا انها را به یکدیگر می چسباند تا حجم فایل خروجی کاهش یابد و امنیت بیشتر شود . بنابراین فلت اسمبلر هرگز سکشنها را درهم نمی تند و قلنبه نمی کند . اما نتواید اسمبلر اینکار کثیف را انجام می دهد و کد و داده را با هم مخلوط می کند و یک معجون کثیف و غیرقابل فهم تولید می کند .)
You should not think of a section as "data", "code" or some other logical concepts: sections can contain both code and data provided that they have the same attribute. If you have a block of data that you want to be read-only, you can put that data in the section that is marked as read-only.
شما نباید یک سکشن را بعنوان داده یا کد یا برخی مفاهیم منطقی تصور نمایید .
سکشن ها می توانند شامل هردوی کد و داده که صفات مشترک دارند باشند .
اگر شما یک بلوک از داده را دارید که می خواهید صفت فقط خواندنی داشته باشد ، شما می توانید این داده ها را در یک سکشن که بصورت فقط خواندنی علامت خورده باشد قرار دهید .
(توضیح مترجم: صفت فقط -خواندنی امنیت داده ها را افزایش می دهد و مانع از الودگی نرم افزار می شود اما از انطرف، آزادی کاربران و توسعه دهندگان را نابود می کند . بنابراین من چندان با این پیشنهاد موافق نیستم . بهرحال هدف از رمزگشایی معماری نرم افزارها اینست که به آزادی برسیم . لذا هرگز نرم افزارهای خودم را در حالت فقط خواندنی قرار نمی دهم تا عملا زبان ماشین توسعه یابد و توسط سایر افراد بعنوان زبان برنامه نویسی اصلی بکار رود . تنها راه احیای زبانهای سطح پایین یعنی ماشین و اسمبلی اینست که اجازه دهیم سایر کاربران از سرتاسر جهان نرم افزارهایی را که ما با کمک این زبانها ساخته ایم را آزادانه بازنویسی و اصلاح نمایند و اینطوری باعث ترویج غیرمستقیم زبانهای سطح پایین ( ماشین و اسمبلی ) بشویم . اینطوری زحمت ما کمتر می شود و خیالمان بابت توسعه ی سریع این دو زبان راحت می شود . لذا نباید جلوی آزادی کاربران را بگیریم . )
When the PE loader maps the sections into memory, it examines the attributes of the sections and gives the memory block occupied by the sections the indicated attributes.
هنگامیکه پی لودر (بارگزار فایل پی ) سکشن ها را به درون حافظه ی رم ترسیم می نماید ، او صفات سکشن ها را آزمایش می نماید و ارائه می دهد بلوکهای حافظه که مشغول شده اند بوسیله ی سکشنهایی که این صفات را نمایش داده اند .
(توضیح مترجم : شخصا از اینهمه حرف تعریف در زبان انگلیسی متنفرم . هر دو کلمه یکبار از حرف تعریف استفاده می کنند طوریکه اصلا نمی توان مثل ادم ، متن را به درستی ترجمه کرد . )
If we view the PE file format as a logical disk, the PE header as the boot sector and the sections as files, we still don't have enough information to find out where the files reside on the disk, ie. we haven't discussed the directory equivalent of the PE file format.
اگر ما ببینیم فرمت فایل پی را همچون یک دیسک منطقی ، پی هدر را همچون بوت سکتور و سکشنها را همچون فایلهای روی دیسک ، ما هنوز هم اطلاعات کافی برای یافتن جاییکه فایلها مقیم هستند روی دیسک ، در دست نداریم . یعنی ، ما معادل فهرست فرمت فایل پی را مطرح نکرده ایم
Immediately following the PE header is the section table which is an array of structures.
بلافاصله بعد از پی هدر ، به جدول سکشن می رسیم که یک آرایه از ساختارها می باشد .
(توضیح مترجم : منظور از پی هدر ، همان فایل هدر می باشد ) .
Each structure contains the information about each section in the PE file such as its attribute, the file offset, virtual offset.
هر ساختار در جدول سکشن ، شامل اطلاعاتی درباره ی هر سکشن در فایل پی می باشد از قبیل صفات اش ، آفست فایل ، آفست مجازی .
If there are 5 sections in the PE file, there will be exactly 5 members in this structure array.
اگر 5 سکشن در فایل پی وجود داشته باشند ، در جدول سکشن عینا 5 عضو در این آرایه ی ساختار وجود خواهد داشت .
( توضیح مترجم : ببینید در 99 درصد موارد ، نرم افزارهای ویندوز بیش از یک سکشن دارند لذا جدول سکشن در این موارد بیش از یک هدر سکشن خواهد بود و مثلا برای سکشن کد یک هدر جدا و برای سکشن داده نیز یک هدر جدا خواهیم داشت ولی تعداد عناصر درون هر هدر سکشن همیشه ثابت است و ربطی به تعداد سکشن های درون نرم افزار ندارد .
این را گفتم که یک وقت دچار تردید و اشتباه نشوید . زیرا تعداد اعضای هر هدر سکشن همیشه ثابت است و هرگز کم یا زیاد نمی شود و هیچ ربطی به تعداد سکشنها ندارد
آن چیزی که دقیقا با تعداد سکشنها ربط دارد تعداد هدرهای سکشن می باشد نه جدولهای سکشن . چون ما فقط یک جدول سکشن داریم که حاوی یک یا چند هدر سکشن می باشد
اگر بعنوان مثال ، یک فایل اجرایی ، 5 سکشن داشته باشد 5 هدر سکشن دارد که این هدرهای سکشن همگی زیرمجموعه ی یک جدول سکشن خواهند بود .
در مورد سکشن فلت به دلیل اینکه فقط یک سکشن داریم جدول سکشن تحت عنوان هدر سکشن نیز نامیده می شود
لازم به ذکر است که مطالب این فایل در زمانی نوشته شده بود که هنوز هیچکس از امکان تولید سکشن فلت و یکپارچه خبر نداشت یا اگر خبر داشت اهمیت نمی داد .
البته از روی نوشته های قبلی نویسنده می توان فهمید که او از سکشن یکپارچه ( و به قول خودش قلنبه ) متنفر است و دوست دارد سکشنها از هم جدا باشند که این طرز فکر کاملا غلط و خطرناک است و باعث افزایش نفوذ ویروسها و بدافزارها به ساختمان نرم افزار می شود . لذا من با این عقاید نویسنده مخالف هستم ومعتقدم که نرم افزار هرگز نباید بیش از یک سکشن داشته باشد و باید فقط یک سکشن داشته باشد که این یک سکشن نیز باید یک سکشن همه منظوره باشد . )
We can then view the section table as the root directory of the logical disk.
ما آنگاه می توانیم مشاهده نماییم جدول سکشن را همچون دایرکتوری روت دیسک منطقی ( شبیه به یونیکس ) .
Each member of the array is equvalent to the each directory entry in the root directory.
هر عضو از آرایه با هر ورودی دایرکتوری در دایرکتوری روت ، معادل می باشد .
( توضیح مترجم :
روت = ریشه
روت یعنی ریشه ی سیستم عامل . این لغت از یونیکس پیدا شده است و گویا نویسنده ی این مقاله دوست دارد ویندوز نیز همچون یونیکس یک سیستم عامل درختی باشد که دایرکتوری روت ، ریشه ی این درخت باشد و سکشنها شاخه های درخت !!!
اما این اصلا با ذات و ماهیت داس و ویندوز سازگار نیست زیرا داس و ویندوز از لحاظ معماری تفاوتهای بسیار زیادی با یونیکس و لینوکس دارند
(
That's all about the physical layout of the PE file format.
این تمام آرایش فیزیکی فرمت فایل پی می باشد .
I'll summarize the major steps in loading a PE file into memory below:
من مراحل بزرگ بارگیری یک فایل پی به درون حافظه ی رم را به شکل زیر خلاصه می نمایم :
When the PE file is run, the PE loader examines the DOS MZ header for the offset of the PE header. If found, it skips to the PE header.
1- هنگامیکه فایل پی درحال اجرا می باشد ، پی لودر ، هدر داس را برای یافتن آفست پی هدر ، آزمایش می نماید
اگر این آفست پیدا شد ، پی لودر داس هدر را به سمت پی هدر دور می زند .
( توضیح : آفست پی هدر یعنی فاصله ی دقیق بین پی هدر و هدر داس و درواقع آفست یعنی آدرس جایی که پی هدر قرار دارد . )
The PE loader checks if the PE header is valid. If so, it goes to the end of the PE header.
2- پی لودر بررسی می کند ببیند آیا پی هدر معتبر است یا نه . اگر دید که پی هدر معتبر است ، او به بخش پایانی پی هدر حرکت می نماید .
Immediately following the PE header is the section table. The PE header reads information about the sections and maps those sections into memory using file mapping. It also gives each section the attributes as specified in the section table.
بلافاصله بعد از پی هدر به جدول سکشن می رسیم . پی هدر می خواند اطللاعات سکشنها را و ترسیم می کند سکشنها را به درون حافظه ی رم با بکارگیری تکنیک نقشه کشی فایل .
او همچنین به هر سکشن صفاتی را که قبلا در جدول سکشن تعیین شده است را ارائه می نماید .
After the PE file is mapped into memory, the PE loader concerns itself with the logical parts of the PE file, such as the import table.
بعد از انکه فایل پی به درون حافظه ی رم ترسیم شد ، پی لودر مرتبط می کند خودش را با بخشهای منطقی فایل پی ، از قبیل جدول ورودی .
The above steps are oversimplification and are based on my own observation. There may be some inaccuracies but it should give you the clear picture of the process.
مراحل بالا ساده می باشند و مبتنی شده اند براساس ملاحظات و مشاهدات خودم . آنجا ممکن است برخی اشتباهات وجود داشته باشد اما آن باید به شما یک تصویر شفاف از کل جریان را بدهد .
تشریح ( و تصحیح محتویات ) فایل متنی آموزشی قدیمی درباره ی فرمت فایل پی .
پایان ترجمه
+
$Id: pe.txt,v 1.9 1999/03/20 23:55:09 LUEVELSMEYER Exp $
( توضیح مترجم :
این فایل که با نامی نامانوس در بالا همراه با تاریخ و ساعت دقیق ، ذکر شده است تحت نام کلی زیر در دسترس می باشد :
pe.txt
در این فایل متنی ساده عملا مراحل برنامه نویسی دستی با زبان ماشین بصورت گام به گام برای ویندوز ان تی توضیح داده شده است که حدس می زنم روی ویندوزهای مبتنی بر ویندوز ان تی یعنی ویندوزهای ایکس پی به بالا ( مثلا ویندوزهای ویستا و 7 و 8 و 10 ) بتوان این آموزش را عملا پیاده سازی کرد .
در این فایل متنی ساده بصورت دستی و با روشی جالب مراحل ساخت دستی یک فایل چند سکشنی را توضیح می دهد .
این فایل متنی ساده هیچ مشابهی در سرتاسر وب ندارد و تنها فایلی است که به صورت گام به گام روش برنامه نویسی دستی با زبان ماشین را برای نرم افزارهای چند سکشنی به شکل بسیار دقیق و علمی و صحیح و با ذکر یک مثال کاربردی ، توضیح داده و عملا اجرا می کند .
من در آینده ی نزدیک محتویات این فایل متنی ساده را ترجمه خواهم کرد .
عملا این فایل متنی ساده را از سالها قبل می شناختم ولی تاکنون انرا اجرا نکرده ام .
خیلی دوست دارم طبق روش این فایل ، بتوانم با دست و در هگز ادیتور یک نرم افزار ویندوزی چند سکشنی بسازم و اجرا نمایم .
+
سایر مباحث مربوط به معماری فایلهای ویندوز را به مرور زمان ترجمه می نمایم .
خصوصا مباحث مربوط به سکشن ورودی و خروجی !!!
این دو سکشن بسیار بسیار پیچیده و دشوار می باشند و ترجمه کردن شان واقعا کار دشواری برای من که فقط یک تایپیست ساده هستم ، خواهد بود اما به امید خدای متعال تمامی فایلهای مربوط به معماری نرم افزارهای ویندوزی را ترجمه خواهم کرد و در اختیار کاربران قرار خواهم داد . انشاا...
در مورد سکشن فلت نیز سعی می کنم پس از پایان ترجمه ی این چند فایل مرجع ، اقدام به نوشتن مطلب در وبلاگ نمایم .
عنوان پست بعدی وبلاگ وحیدمی، این می باشد:
pe.txt
این فایل متنی ساده دقیقا همان چیزی است که هم من و هم شما به دنبالش می گردیم . به امید خدا در اولین فرصت این فایل ارزشمند را ترجمه و دستورالعملهایش را عملا روی ویندوز 10 آزمایش خواهم کرد .
اگر این آزمایش جواب دهد من به آرزوی دیرینه ام یعنی برنامه نویسی حرفه ای با زبان ماشین( هگز ادیتور) تحت ویندوز، خواهم رسید .
نکته ی جالب ماجرا اینجاست که در این فایل روش برنامه نویسی کاملا دستی را توضیح داده و عملا ما نیازی به هیچ اسمبلر یا کامپایلر نداریم و تمام اجزای نرم افزار ویندوزی را از اول تا به آخر بایت به بایت و با دست می سازیم و اجرا می کنیم و هیچ نیازی به اسمبلرها و کامپایلرها نداریم .
اگر می خواهید تمام مطالبی که جناب ایکزیلیون درباب معماری نرم افزارهای ویندوز نوشته است را همراه با این فایل متنی ساده و ارزشمند یکجا ببینید مطالعه ی این فایل مرجع را به شما توصیه و پیشنهاد می نمایم :
petute.chm
متاسفانه امکان آپلود و دانلود این فایل بدلیل باگهای جدید و عجیب آپلود سنتر بیان ، فراهم نشد .
مدتی است که امکان آپلود هیچنوع فایلی از طریق صندوق بیان (فضای اختصاصی ) امکان پذیر نیست و مدام با پیامهای خطای عجیب مواجه می شوم و حتی در صورت آپلود ، فایل بصورت ناقص و معیوب آپلود می شود که عملا به هیچ دردی نمی خورد .
لذا تصمیم گرفتم که از این به بعد تمام فایلهایم را از طریق پیکوفایل ، آپلود نمایم و سپس لینک دانلود را در وبلاگهایم قرار بدهم .
اما شما می توانید این فایل ارزشمند را در پکیج Masm32.zip در مسیر زیر پیدا کنید :
D:\masm32\tutorial\petute
توجه داشته باشید که اسمبلر Masm32 را باید حتما روی ریشه ی درایو نصب کنید . دقیقا به شکلی که در بالا می بینید .
شما می توانید اسمبلر Masm32 را از سایت رسمی اش و یا از وبلاگهای من دانلود نمایید .
لینک دانلود اسمبلر Masm32 از سایت رسمی :
http://masm32.masmcode.com/masm32/masm32v11r.zip
نکته ی مهم: من محتویات درون این فایل مرجع را مستقیما به درون برنامه ی وردپد کپی کردم . لذا اگر هرگونه چیز عجیب یا غریب در محتوای اصلی و ترجمه مشاهده می کنید به این دلیل است .
عملا قالب این فایل بهم ریخته است .
+++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++
نویسنده ی اصلی مقاله ی بالا :
Iczelion
هکر کلاه سفید ژاپنی و نویسنده ی بیشترین و کاملترین خودآموزهای زبان اسمبلی در دنیا
مترجم : وحید محمدی - وبلاگ وحیدمی
+
بروزرسانی :
آدرسهای منفرد باقیمانده از ایکزیلیون:
Iczelion's Win32 Assembly Tutorial 1: The Basic (interq.or.jp)
Iczelion's Win32 Assembly Tutorial 3: A Simple Window (interq.or.jp)
http://www.interq.or.jp/chubu/r6/masm32/tute/tute003.html
تاریخ بروزرسانی :
جمعه 12 آذر 1400 شمسی
https://forum.tuts4you.com/topic/10603-iczelions-win32-assembly-tutorials/