[تمرين] حللني ان استطعت 4

[overlap]

اتباعا لفكرة قسم التحديات، اضع امامكم بنفس المبدأ تحدي برمجي...
تمرين "حللني ان استطعت 4" هو عبارة عن تطبيق يقوم بانجاز مهمة بسيطة.

المطلوب:
- تحليله و فهم ما يقوم به.
- تحديد لغة البرمجة التي كتب بها و الأدوات التي تم استعمالها.
- ان امكن، بناء تطبيق مماثل و قريب جدا من حجم التطبيق الأصلي.

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

https://www.solidfiles.com/v/4YBYGZ86gqZ6d

[siddigss]

شكرا على تمارينك المستمرة، انشغلت قليلا الأيام الماضية.

- تحليله و فهم ما يقوم به.

يبدو أن البرنامج يقوم بالتالي

CreateEventA(NULL, TRUE, FALSE, "at4re");
while(true);

 

- تحديد لغة البرمجة التي كتب بها و الأدوات التي تم استعمالها.

لم أعرف بعد، يبدو أن البرنامج قد جرد من أي دليل، فلا أقسام إضافية أو نصوص (strings) تعطي تلميحات إلى ال compiler، كذلك يبدو أنه تم تغيير قيم ال Major Linker Version و ال Minor Linker Version في ال Optional Header إلى 0.

تعديل: يبدو أني تعجلت في كتابة التالي... فالاصطلاح محدد مسبقا للدالة في kernelbase.dll ولا يمكننا تغييره، أليس كذلك؟
لست متأكداً إذا كان هذا يفيد ولكن بالنظر لاستدعاء الدالة CreateEventA فاستدعاؤها يتبع ال Microsoft x64 convension  ولكني لست متأكدا إذا كانت جميع ال compilers تتبع نفس الاصطلاح عند بناء البرامج ل Windows x64 أو إذا كان من الممكن تغيير اصطلاح الاستدعاء كما في x86.

[siddigss]

مرفق نسخة 32-bit من البرنامج بنفس حجم البرماج الأصلي.

#include <Windows.h>

int main() {
    CreateEventA(NULL, TRUE, FALSE, "at4re");
    while (true);
    return 0;
}

ال compiler المستعمل هو Visual Studio. أوامر ال linker التي ساعدت على تقليص حجم الملف من 9KB إلى 656 Bytes

/MANIFEST:NO /LTCG /DYNAMICBASE:NO [names, this is parameter not part of the options] /ENTRY:"main" /SUBSYSTEM:WINDOWS /WX:NO /NOLOGO /ALIGN:16 /ASSEMBLYDEBUG:DISABLE /NODEFAULTLIB /DEBUG:NONE /EMITPOGOPHASEINFO

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

لإنقاص الحجم إلى 592 Bytes قمت يدوياً بالتالي.
وجدت أن ال DOS Header ينتهي عن 0x40 وال NT Headers تبدأ عند 0xB8، وما بينهما توجد الرسالة "This program cannot be run in DOS mode" وأشياء أخرى لم أهتم بها. يمكننا بدء ال NT Headers من 0x80، فنزيل الرسالة التي ذكرناها وأكثير منها قليلا. بعد فعل هذا علينا تعديل البايت رقم 0x3c لتكون قيمته 0x80. ثم نفتح هذه السنخة المعدلة في CFF Explorer ومن هنا يتوجب علينا إصلاح عناوين الأقسام والاستيرادات. كتابة العملية متعبة وكن ملخصها كالتالي:
استعملت برنامج CFF Explorer
1- في ال optional header نعدل
AddressOfEntryPoint
BaseOfCode
SizeOfHeaders

2- في ال Data Directories نعدل
Import Directory RVA
Exception Directory RVA (لا يبدو مهما)
Import Address Table Directory RVA

3- في ال section Headers نعدل
Raw Address لكل قسم
Virtual Address لكل قسم

ثم يتوجب علينا إصلاح عناوين الدوال المستوردة، بشكل عام في هذا البرنامج الصغير في قسم .rdata غير أي بايتين على الشكل

xx 02

طريقة التعديل على جميع ما سبق ببساطة طرح حجم ما حذفناه، وهو 0x78. على سبيل المثال إذا كانت قيمة إحدى القيم 0x220 فبعد الطرح تصبح 0x1A8، وبالنسبة للبايتين كمثال

78 20 to 00 20

ملاحظة: أثناء عملية تعديلي حذفت 8 بايتات أخرى لأتبع محاذاة البرنامج (0x10)، يمكنك من البداية أن تبدأ ال NT Headers من 0x88 لتجنب هذا واتباع نفس الخطوات.

[overlap]

رائع جدا اخي...
انت على الطريق الصحيح...

مرفق نسخة 32-bit من البرنامج بنفس حجم البرماج الأصلي.

التطبيق الأصلي 64 بت...
جرب اخي طريقنك في بناء تطبيق 64 بت و حاول الوصول الى نفس حجم التطبيق الأصلي...

من الغريب أن الأمر EMITPOGOPHASEINFO غير موجود على الموقع، وجدته هنا

بسبب انها غير موثقة...
 

لإنقاص الحجم إلى 592 Bytes قمت يدوياً بالتالي.

لترقية الحوار اكثر  لم المس التطبيق يدويا و لا برمجيا اعتمدت على Compiler/Linker فقط

ال compiler المستعمل هو Visual Studio

هل تقصد cl.exe  او ml64.exe)  Hint) 

[siddigss]

كتبت مختصر العملية اليدوية وحذفت بعض استنتاجاتي غير الصحيحة كما يبدو لي الآن.

جرب اخي طريقنك في بناء تطبيق 64 بت و حاول الوصول الى نفس حجم التطبيق الأصلي...

مرفق نسخة 64 بت بنفس الحجم الأصلي.

لترقية الحوار اكثر  لم المس التطبيق يدويا و لا برمجيا اعتمدت على Compiler/Linker فقط

بدون اللمس أقصى ما استطعت فعله الآن هو 640 بايت، وذلك باستعمال

/MERGE:".pdata=.rdata" /STUB:stub.exe

حيث stub.exe ما هو إلا

0000000000000000  4D 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00  MZ..............  
0000000000000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  
0000000000000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  
0000000000000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  

لم أستطع إزالة ال unwind tables الخاصة بال exceptions باستعمال MSVC.
 

هل تقصد cl.exe  او ml64.exe)  Hint) 

شكرا على التلميح! قصدت ال compiler الذي استعملته أنا

[overlap]

مرفق نسخة 64 بت بنفس الحجم الأصلي.

عمل جيد...
 

بدون اللمس أقصى ما استطعت فعله الآن هو 640 بايت، وذلك باستعمال

التطبيق الأصلي مبني بــ ML64 و يحتوي هو ايضا على نفس الــ Stub المعدل...
عند بنائه بنفس الاعدادات السابقة التي اتبعتها سوف ينقص حجمه...
اوامره:

extern CreateEventA:proc
includelib kernel32.lib

.const
    EventName db 'at4re', 0

.code
start proc
    xor        r8d, r8d
    lea        r9, offset EventName
    xor        ecx, ecx
    lea        edx, qword ptr [r8+1]
    call    CreateEventA
    
$InfiniteLoop:
    jmp    short $InfiniteLoop
    
start endp
end

 

لم أستطع إزالة ال unwind tables الخاصة بال exceptions باستعمال MSVC.

ML64  لا يهتم باضافتها و منه يزيد صغر حجم التطبيق النهائي...

بالمناسبة، الظاهر انك تستعمل اصدار Visual Studio 2017 ؟

[siddigss]

التطبيق الأصلي مبني بــ ML64 و يحتوي هو ايضا على نفس الــ Stub المعدل...

حاولت فعل هذا بعد تلميحك، ولكن أقصى ما وصلت له هو 640 بايت، ويبدو أن الفرق بين تطبيقك وتطبيقي هو القسم .idata. يرفض ml64 أن يدمجه مع أي قسم آخر! إذا أدمج القسم فالمفترض أن الحجم سينقص 40 بايت أن 600 بايت، ولكن إن كان فهمي صحيحا فشرط المحاذاة ALIGN:16 يجبر ال linker على إضافة 8 بايتات أخرى أي 608 بايت. هذه الزيادة بمقدار 16 بايت عن برنامجك بعد المقارنة تبين أن سببها استعمالي للأمر

mov r9, offset EventName

وطوله 10 بايتات بينما أنت استعملت

lea r9, offset EventName

بطول 7 بايتات. ويبدو أن هذا الفرق الطفيف جُعِل 16 بايت من قبل ال linker بسبب شرط المحاذاة، وبالفعل بعد تغيير الأمر نقص حجم البرنامج 16 بايت أي 624 بايت.
 

ML64  لا يهتم باضافتها و منه يزيد صغر حجم التطبيق النهائي...

فعلا! بالمناسبة، هل قمت بتصفير ال rich signature وكذلك ال linker versions في ال optional headers بشكل يدوي؟

بالمناسبة، الظاهر انك تستعمل اصدار Visual Studio 2017 ؟

بالفعل، هذا ما أستخدمه، استنتجت هذا بسبب مشكلة ال exceptions الذي ذكرتها بالأعلى ؟

[overlap]

بايت عن برنامجك بعد المقارنة تبين أن سببها استعمالي للأمر

في المرفقات مثالين يعطينا نفس النتيجة (حجم البناء) سواء قبل او بعد تغيير الأمر lea الى mov التي يجعلها الكومبايلر movabs

فعلا! بالمناسبة، هل قمت بتصفير ال rich signature وكذلك ال linker versions في ال optional headers بشكل يدوي؟

نعم، تصفيرها يجعل بعض ادوات الكشف تفشل...
لكن كما تعلم اخي ان هذا لا يؤثر على حجم الملف الناتج لانه مجرد تصفير لقيم بايتات موجودة....

Visual Studio 2017

الكومبايلر و اللينكر المستعملان في بناء التمرين يخصان اصدار Visual Studio 2010
الفرق في الحجم تأثر بصفة مباشرة في اختيار (Compiler/Linker) من اصدار 2017 الى اصدار 2010 لانه حسب ما قرأته في مشاركاتك كل البراميترات التي مررتها هي نفسها التي استعملتها انا...