إنشاء EXE

العزلة الذاتية هي وقت رائع لبدء شيء يستغرق الكثير من الوقت والجهد. لذلك قررت أن أفعل ما كنت أرغب فيه دائمًا - كتابة المترجم الخاص بي.



الآن هو قادر على ترجمة Hello World ، لكن في هذه المقالة لا أريد أن أتحدث عن التحليل والهيكل الداخلي للمترجم ، ولكن عن جزء مهم مثل تجميع بايت بايت لملف exe.

بداية

تريد سبويلر؟ سيكون برنامجنا 2048 بايت.



عادة ، العمل مع ملفات exe هو دراسة أو تعديل هيكلها. يتم تشكيل الملفات القابلة للتنفيذ نفسها من قبل المترجمين ، وهذه العملية تبدو سحرية بعض الشيء للمطورين.



لكن الآن سنحاول إصلاحه!



لبناء برنامجنا ، نحتاج إلى أي محرر HEX (أنا شخصياً استخدمت HxD).



للبدء ، لنأخذ الرمز الكاذب:





يشير أول سطرين إلى الوظائف المستوردة من مكتبات WinAPI . تعرض وظيفة MessageBoxA مربع حوار مع النص الخاص بنا ، وتقوم ExitProcess بإعلام النظام بنهاية البرنامج.

ليس من المنطقي النظر في الوظيفة الرئيسية بشكل منفصل ، لأنها تستخدم الوظائف الموضحة أعلاه.

رأس DOS

أولاً ، نحتاج إلى إنشاء DOS Header الصحيح ، هذا هو رأس برامج DOS ويجب ألا يؤثر على إطلاق exe تحت Windows.



لقد لاحظت حقولًا أكثر أو أقل أهمية ، والباقي مليء بالأصفار.





الأهم من ذلك ، أن هذا الرأس يحتوي على حقل e_magic ، مما يعني أن هذا ملف قابل للتنفيذ ، و e_lfanew ، مما يشير إلى إزاحة رأس PE من بداية الملف (في ملفنا ، هذه الإزاحة هي 0x80 = 128 بايت).



رائع ، الآن بعد أن عرفنا بنية DOS Header ، دعنا نكتبها في ملفنا.

, , .



, (Offset) .



, 0x00000000, 64 (0x40 16- ), 0x00000040 ..

تم ، تمت كتابة أول 64 بايت. أنت الآن بحاجة إلى إضافة 64 أخرى ، وهذا ما يسمى DOS Stub (Stub). عند التشغيل من نظام DOS ، يجب إخطار المستخدم بأن البرنامج غير مصمم للتشغيل في هذا الوضع.



لكن بشكل عام ، هذا برنامج DOS صغير يطبع سطرًا ويخرج من البرنامج.

دعنا نكتب Stub إلى ملف وننظر فيه بمزيد من التفصيل.





والآن نفس الرمز ، ولكن في شكل مفكك





إنه يعمل على النحو التالي: أولاً ، يقوم كعب الروتين بطباعة سطر يشير إلى أنه لا يمكن بدء تشغيل البرنامج ، ثم يخرج من البرنامج برمز 1. والذي يختلف عن الإنهاء العادي (الرمز 0).



قد يختلف كود كعب الروتين قليلاً (من مترجم إلى مترجم) لقد قارنت gcc و delphi ، لكن المعنى العام هو نفسه.



من المضحك أيضًا أن ينتهي السطر الأساسي بـ \ x0D \ x0D \ x0A $. غالبًا ما يكون سبب هذا السلوك هو أن c ++ يفتح الملف في وضع النص افتراضيًا. نتيجة لذلك ، يتم استبدال الحرف \ x0A بالتسلسل \ x0D \ x0A. نتيجة لذلك ، نحصل على 3 بايت: 2 بايت من حرف الإرجاع (0x0D) والذي لا معنى له ، وواحد لتغذية السطر (0x0A). في الوضع الثنائي (std :: ios :: binary) ، لا يحدث هذا الاستبدال.



للتحقق من كتابة القيم بشكل صحيح ، سأستخدم Far مع المكون الإضافي ImpEx:

رأس NT

بعد 128 (0x80) بايت ، وصلنا إلى رأس NT (IMAGE_NT_HEADERS64) ، والذي يحتوي أيضًا على رأس PE (IMAGE_OPTIONAL_HEADER64). على الرغم من أن الاسم IMAGE_OPTIONAL_HEADER64 مطلوب ، ولكنه مختلف لبنيات x64 و x86.





دعونا نرى ما يتم تخزينه في هذا الهيكل:





الآن بعد أن نظرنا إلى ما يتكون منه رأس NT ، سنكتبه أيضًا في ملف عن طريق القياس مع الآخرين في 0x80.





نتيجة لذلك ، نحصل على هذا النوع من رؤوس IMAGE_FILE_HEADER و IMAGE_OPTIONAL_HEADER64 و IMAGE_DATA_DIRECTORY:















بعد ذلك ، نصف جميع أقسام تطبيقنا وفقًا للبنية IMAGE_SECTION_HEADER







في حالتنا ، سيكون لدينا 3 أقسام.



لماذا يبدأ Virtual Address (VA) من 1000 ، وليس من الصفر ، لا أعرف ، لكن كل المترجمين الذين أعتبرهم يفعلون ذلك. نتيجة لذلك ، 1000 + 3 أقسام * 1000 (SectionAlignment) = 4000 ، والتي كتبناها في SizeOfImage. هذا هو الحجم الإجمالي لبرنامجنا في الذاكرة الافتراضية. ربما تستخدم لتخصيص مساحة البرنامج في الذاكرة.

 Name	| RAW Addr	| RAW Size	| VA	| VA Size | Attr
--------+---------------+---------------+-------+---------+--------
.text	| 200		| 200		| 1000	| 3D	  |   CER
.rdata	| 400		| 200		| 2000	| 13	  | I   R
.idata	| 600		| 200		| 3000	| B8	  | I   R

فك تشفير السمات:



I - بيانات مهيأة ، بيانات مهيأة

U - بيانات غير مهيأة ، ليست بيانات مهيأة

C - كود ، يحتوي على كود قابل للتنفيذ

E - تنفيذ ، يسمح بتنفيذ

R - قراءة الكود ، يسمح بقراءة البيانات من القسم

W - الكتابة ، يسمح لكتابة البيانات إلى القسم



.text (.code) - يخزن الكود القابل للتنفيذ (البرنامج نفسه) ، سمات CE

.rdata (.rodata) - يخزن بيانات للقراءة فقط ، مثل الثوابت والسلاسل وما إلى ذلك ، سمات IR

. البيانات التي يمكن قراءتها وكتابتها ، مثل المتغيرات الثابتة أو العامة. سمات IRW

.bss - يخزن البيانات غير المهيأة مثل المتغيرات الثابتة أو العامة. بالإضافة إلى ذلك ، عادةً ما يحتوي هذا القسم على حجم RAW صفر وحجم VA غير صفري ، لذلك لا يشغل مساحة في الملف. سمات URW

.idata - قسم يحتوي على وظائف مستوردة من مكتبات أخرى. سمات IR



نقطة مهمة ، يجب أن تتبع الأقسام بعضها البعض. علاوة على ذلك ، سواء في الملف أو في الذاكرة. على الأقل عندما غيرت ترتيبهم بشكل تعسفي ، توقف البرنامج عن العمل.



الآن بعد أن عرفنا الأقسام التي سيحتويها برنامجنا ، سنكتبها في ملفنا. هنا تنتهي الإزاحة عند 8 وسيبدأ التسجيل من منتصف الملف.





سيكون عنوان الإدخال التالي 00000200 الذي يتوافق مع حقل SizeOfHeaders في رأس PE. إذا أضفنا قسمًا آخر ، وهذا زائد 40 بايت ، فلن تتناسب رؤوسنا مع 512 (0x200) بايت وسيتعين علينا استخدام 512 + 40 = 552 بايت محاذاتها بواسطة FileAlignment ، أي 1024 (0x400) بايت. وكل ما تبقى من 0x228 (552) إلى العنوان 0x400 يجب أن يتم ملؤه بشيء ما ، أفضل بالطبع بالأصفار.



دعنا نلقي نظرة على الشكل الذي تبدو عليه كتلة الأقسام في Far:







بعد ذلك ، سنكتب الأقسام نفسها في ملفنا ، ولكن هناك فارق بسيط واحد.



كما ترون من مثال SizeOfHeaders ، لا يمكننا فقط كتابة العنوان والانتقال إلى القسم التالي. نظرًا لأنه لتسجيل عنوان ، نحتاج إلى معرفة المدة التي ستستغرقها جميع العناوين معًا. نتيجة لذلك ، نحتاج إما إلى حساب مقدار المساحة المطلوبة مسبقًا ، أو كتابة قيم فارغة (صفرية) ، وبعد كتابة جميع الرؤوس ، نعود ونكتب حجمها الفعلي.



لذلك ، يتم تجميع البرامج في عدة مسارات. على سبيل المثال ، يأتي قسم .rdata بعد قسم .text ، بينما لا يمكننا العثور على العنوان الظاهري للمتغير في .rdata ، لأنه إذا كان قسم النص ينمو بأكثر من 0x1000 (SectionAlignment) بايت ، فسيشغل عناوين 0x2000 من النطاق. وبناءً على ذلك ، لن يكون قسم .rdata موجودًا على 0x2000 ، ولكن على 0x3000. وسنحتاج إلى العودة وإعادة حساب عناوين جميع المتغيرات في قسم النص الذي يسبق .rdata.



لكن في هذه الحالة ، لقد قمت بالفعل بحساب كل شيء ، لذلك سنقوم على الفور بتدوين كتل الكود.

قسم النص

على وجه التحديد بالنسبة لهذا البرنامج ، تعتبر الأسطر الثلاثة الأولى ، تمامًا مثل الثلاثة الأخيرة ، اختيارية.

لن يتم تنفيذ الثلاثة الأخيرة حتى ، لأن البرنامج سينتهي عند وظيفة الاستدعاء الثانية.



لكن دعنا نقول هذا ، إذا لم تكن الوظيفة الرئيسية ، بل وظيفة فرعية ، فيجب أن يتم ذلك بهذه الطريقة.



لكن الثلاثة الأولى في هذه الحالة ، على الرغم من أنها ليست مطلوبة ، مرغوبة. على سبيل المثال ، إذا لم نستخدم MessageBoxA ، ولكننا printf ، فبدون هذه الأسطر سنحصل على خطأ.



وفقًا لاتفاقية الاستدعاء لأنظمة MSDN 64 بت ، يتم تمرير المعلمات الأربعة الأولى في السجلات RCX و RDX و R8 و R9. إذا كانت مناسبة هناك ولم تكن ، على سبيل المثال ، رقم فاصلة عائمة. ويتم تمرير الباقي عبر المكدس.



من الناحية النظرية ، إذا مررنا وسيطين إلى دالة ، فيجب علينا تمريرهما عبر السجلات ونحتفظ بمكانين في المكدس من أجلهما ، حتى تتمكن الوظيفة ، إذا لزم الأمر ، من دفع السجلات إلى المكدس. كما يجب ألا نتوقع إعادة هذه السجلات إلينا في حالتها الأصلية.



لذا فإن المشكلة في وظيفة printf هي أنه إذا مررنا وسيطة واحدة فقط إليها ، فستظل تكتب فوق جميع الأماكن الأربعة في المكدس ، على الرغم من أنه يبدو أنه يجب الكتابة فوق واحد فقط ، بعدد الوسائط.



لذلك ، إذا كنت لا تريد أن يتصرف البرنامج بشكل غريب ، فاحجز دائمًا 8 بايت على الأقل * 4 وسيطات = 32 (0x20) بايت إذا قمت بتمرير وسيطة واحدة على الأقل إلى الوظيفة.



ضع في اعتبارك كتلة من التعليمات البرمجية مع استدعاءات الوظائف

MessageBoxA(0, 'Hello World!', 'MyApp', 64)
ExitProcess(0)

نمرر الوسيطات



أولاً : rcx = 0

rdx = العنوان المطلق للسلسلة في الذاكرة ImageBase + Sections [". Rdata"]. VirtualAddress + إزاحة السلسلة من بداية القسم ، تتم قراءة السلسلة على أنها بايت صفر

r8 = مشابه للسلسلة السابقة

r9 = 64 (0x40) MB_ICONINFORMATION ، رمز المعلومات



وبعد ذلك هناك استدعاء لوظيفة MessageBoxA ، والتي لا يكون كل شيء بهذه البساطة. النقطة المهمة هي أن المترجمين يحاولون استخدام أقصر الأوامر الممكنة. كلما كان حجم التعليمات أصغر ، كلما تناسبت هذه التعليمات مع ذاكرة التخزين المؤقت للمعالج ، على التوالي ، سيكون هناك عدد أقل من ذاكرة التخزين المؤقت المفقودة ، والحمولات الزائدة ، وزيادة سرعة البرنامج. لمزيد من المعلومات حول الأوامر والأعمال الداخلية للمعالج ، ارجع إلى أدلة مطوري برامج Intel 64 و IA-32.



يمكننا استدعاء الوظيفة على العنوان الكامل ، لكن هذا قد يستغرق على الأقل (رمز تشغيل واحد + 8 عنوان = 9 بايت) ، ومع عنوان نسبي ، يستغرق أمر الاستدعاء 6 بايت فقط.



دعونا نلقي نظرة فاحصة على هذا السحر: rip + 0x203E ليس أكثر من استدعاء دالة على العنوان المحدد بواسطة الإزاحة الخاصة بنا.



نظرت إلى الأمام قليلاً واكتشفت عناوين التعويضات التي نحتاجها. بالنسبة لـ MessageBoxA ، فهي 0x3068 وبالنسبة إلى ExitProcess فهي 0x3098.



حان الوقت لتحويل السحر إلى علم. في كل مرة يصل فيها كود التشغيل إلى المعالج ، فإنه يحسب طوله ويضيفه إلى عنوان التعليمات الحالي (RIP). لذلك ، عندما نستخدم RIP داخل تعليمات ، يشير هذا العنوان إلى نهاية التعليمات الحالية / بداية التعليمة التالية.

بالنسبة للمكالمة الأولى ، سيشير الإزاحة إلى نهاية أمر الاتصال ، هذا هو 002A. لا تنس أنه في الذاكرة سيكون هذا العنوان في أقسام الإزاحة [". نص"]. VirtualAddress ، أي 0x1000. لذلك ، سيكون RIP لمكالمتنا هو 102 أ. العنوان الذي نحتاجه لـ MessageBoxA هو 0x3068. ضع في اعتبارك 0x3068 - 0x102A = 0x203E . بالنسبة إلى العنوان الثاني ، كل شيء هو نفسه 0x1000 + 0x0037 = 0x1037 ، 0x3098 - 0x1037 = 0x2061 .



هذه هي الإزاحات التي رأيناها في أوامر المجمّع.

0024	call QWORD PTR [rip + 0x203E]
002A	mov rcx, 0x0
0031	call QWORD PTR [rip + 0x2061]
0037	add rsp, 0x20

لنكتب قسم النص إلى ملفنا ، ونضيف الأصفار إلى العنوان 0x400:

قسم البيانات

ربما يكون هذا هو أبسط قسم. سنضع هنا سطرين فقط ، ونضيف الأصفار إلى 512 بايت.

قسم البيانات

حسنًا ، إليك القسم الأخير ، الذي يصف الوظائف المستوردة من المكتبات.



أول ما ينتظرنا هو الهيكل الجديد IMAGE_IMPORT_DESCRIPTOR







أولاً ، نحتاج إلى إضافة مكتبتين مستوردتين. اعد الاتصال:

func MessageBoxA(u32 handle, PChar text, PChar caption, u32 type) i32 ['user32.dll']
func ExitProcess(u32 code) ['kernel32.dll']

نستخدم مكتبتين ، ولنقول إننا انتهينا من إدراجهما. الهيكل الأخير مليء بالأصفار.

 INT	| Time	 | Forward  | Name   | IAT
--------+--------+----------+--------+--------
0x3058	| 0x0    | 0x0      | 0x303C | 0x3068
0x3088	| 0x0    | 0x0      | 0x3048 | 0x3098
0x0000	| 0x0    | 0x0      | 0x0000 | 0x0000

لنقم الآن بإضافة أسماء المكتبات نفسها:







بعد ذلك ، دعنا نصف مكتبة user32:





يشير حقل الاسم الخاص بالمكتبة الأولى إلى 0x303C إذا نظرنا إلى مستوى أعلى قليلاً ، فسنرى أنه في العنوان 0x063C توجد مكتبة "user32.dll \ 0".



تلميح ، تذكر أن قسم .idata يتوافق مع إزاحة الملف 0x0600 وإزاحة الذاكرة 0x3000. بالنسبة للمكتبة الأولى ، INT هو 3058 ، مما يعني أنه في الملف سيتم إزاحته 0x0658. في هذا العنوان ، نرى الإدخال 0x3078 والصفر الثاني. مما يدل على نهاية القائمة. 3078 يشير إلى 0x0678 هذه هي سلسلة RAW



"00 00 4D 65 73 73 61 67 65 42 6F 78 41 00 00 00"



أول 2 بايت لا تهمنا وتساوي الصفر. ثم هناك خط باسم الدالة ينتهي بصفر. أي يمكننا تمثيلها كـ "\ 0 \ 0MessageBoxA \ 0".



في هذه الحالة ، يشير IAT إلى بنية مشابهة لجدول IAT ، ولكن سيتم تحميل عناوين الوظائف فقط فيه عند بدء تشغيل البرنامج. على سبيل المثال ، الإدخال الأول 0x3068 في الذاكرة سيكون له قيمة أخرى غير 0x0668 في الملف. سيكون هناك عنوان وظيفة MessageBoxA التي تم تحميلها بواسطة النظام الذي سنشير إليه من خلال استدعاء المكالمة في كود البرنامج.



والجزء الأخير من اللغز ، النواة 32. ولا تنس إضافة أصفار إلى SectionAlignment.





نتحقق من أن Far كان قادرًا على تحديد الوظائف التي قمنا باستيرادها بشكل صحيح:







رائعة! كان كل شيء على ما يرام ، والآن أصبح ملفنا جاهزًا للتشغيل.

Drumroll ...

الاخير

مبروك ، لقد فعلناها!



يشغل الملف 2 كيلوبايت = رؤوس 512 بايت + 3 أقسام بحجم 512 بايت.



الرقم 512 (0x200) ليس أكثر من FileAlignment الذي حددناه في رأس برنامجنا.



بالإضافة إلى ذلك:

إذا كنت تريد التعمق أكثر ، يمكنك استبدال النقش "Hello World!" لشيء آخر ، فقط لا تنس تغيير عنوان السطر في كود البرنامج (قسم. نص). العنوان الموجود في الذاكرة هو 0x00402000 ، ولكن سيكون للملف ترتيب بايت عكسي 00 20 40 00.



أو أن المهمة أكثر تعقيدًا. قم بإضافة مكالمة MessageBox أخرى إلى الرمز. للقيام بذلك ، سيتعين عليك نسخ المكالمة السابقة وإعادة حساب العنوان النسبي فيها (0x3068 - RIP).

خاتمة

تبين أن المقالة مجعدة إلى حد ما ، وستتكون بالطبع من 3 أجزاء منفصلة: العناوين ، البرنامج ، جدول الاستيراد.



إذا قام شخص ما بتجميع exe ، فإن عملي لم يكن عبثًا.



أفكر في إنشاء ملف ELF بطريقة مماثلة قريبًا ، فهل ستكون هذه المقالة ممتعة؟)



الروابط:

• Intel 64 و IA-32 معماريات دليل
  
  أوامر مطوري البرامج ودليل هندسة المعالج.
  
  
• PE (قابل للتنفيذ المحمول): On Stranger Tides
  
  مقال ممتاز عن بنية ملف exe.
• مستودع وثائق Microsoft
  
  هنا يمكنك العثور على أي معلومات حول الرؤوس والهياكل والأنواع ووصفها