دروس في مباديء الهندسة العكسية Reverse Engineering
الدرس الثالث
Basic Nag Removal +Basic Aesthetic Patching
رابط الدرس الأولرابط الدرس الثانيهذا الدرس من أصعب الدروس ويحتاج إلي تركيز شديد فستجد به العديد من المطلحات الهامة جدا التي يجب فهمها وهذا الموضوع يعتبر مدخل رئيسي إلي ال Pakers و ال Protectors
بعض البرامج عند بداية تشغيلها في بداية تشغيلها تقوم بإظهار رسالة تطلب منك التسجيل أو تطلب منك الإنتظار لثوان قبل أن تبدأ في تشغيل البرامج وبعضها يكون الرسالة في نهاية البرنامج عند غلقه هذه الرسائل تسمي nag screens
ال nags سواء ظهرت في بداية أو نهاية البرنامج فمن الطبيعي أنها قبل أن تظهر يكون هناك سؤال هل البرنامج مسجل أم لا وبناءا علي الإجابة يتم تحديد ظهور ال nag من عدمه
في هذا الدرس سنري كيفية التخلص من ال nags
سنقوم في البداية بالدراسة علي برنامج صغير صمم لهذا الغرض Register Me
وبعدها سنقوم بالدراسة علي برنامج حقيقي
حمل هذا الملف
http://www.4shared.com/file/21327757...egisterMe.htmlوبالطبع سنستخدم OllyDBG النسخة الأصلية غير مضاف إليها أي إضافات
http://www.4shared.com/file/21327727...__OllyDbg.htmlقم بتشغيل Register Me و لا حظ ما يحدث
إضغط ok
قم بغلق البرنامج
إذن هناك nag في بداية التشغيل وفي نهاية التشغيل
الآن قم بفتح Register Me بإستخدام OllyDBG وتابع
F8
F8
F8
F8
من الواضح و إذا نظرنا لما بعد القفز سنجد أن هذا الأمر هو الذي سيحدد ظهور الناج سكرين من عدمه و إذا نظرت إلي Z-FLAG ستجد أنه يساوي صفر أي أنه لن يتم القفز وبالتالي ستظهر الناج ونحن نعلم من الدرس الأول كيفية عبور هذه المشكلة بأكثر من طريقة و سنقوم بتغيير ال Z-FLAG من 0 إلي 1
F8 و إستمر حتي تظهر شاشة البرنامج الرئيسية إغقلها و إستمر F8 حتي تظهر ال nag الثانية والآن قم بغلقها و إستمر F8 حتي تظهر كلمة Terminated في OLLY
واضح أننا تخلصنا فقط من ال nag الأولي ومازالت الثانية موجودة لكن لا يوجد أمر قفز حتي نقوم بتغييره
الأن أعد تشغيل البرنامج مرة أخري في Olly و إستمر F8 حتي أمر القفز JE
قبل التعرف علي طرق التخلص من ال nags تابع معي
The
Portable Executable - PE
هو أنواع الملفات التي تستخدم بواسطة نظام الويندوز بإصداراته المختلفة وتشمل .exe, .dll, .ocx, .sys, .scr
هذه الملفات تحوي المعلومات اللازمة والتي سيستخدمها نظام التشغيل في إدارة البرنامج بما فيها ال dll و إستدعاءال Windows API من النظام لإستخدامها بواسطة البرنامج بالطبع هذا ببساطة شديدة إقرأمن فضلك التعريف بالكامل بالإنجليزية لتفهم بالضبط هذا المصطلح
A PE file consists of a number of
headers and
sections, which together tell the
dynamic linker how to map the file into memory. Because an executable image consists of several different regions which require different memory protections, the start of each section must be aligned to a page boundary. For instance, typically the
.text section (which holds program code) is mapped execute/readonly, and the
.data section (holding global variables) is mapped no-execute/readwrite. However, to avoid wasting space the different sections are not page aligned on disk. Part of the job of the dynamic linker is to map each section individually and assign the correct permissions to the resulting regions, according to the instructions found in the headers.
One section of note is the
import address table (IAT). The IAT is used as a lookup table when the application is calling a
Windows API function. Because a compiled PE DLL/EXE cannot know in advance where the other DLLs it depends upon are located in memory, an indirect jump is required. As the dynamic linker loads modules and joins them together, it writes jump instructions into the IAT slots which point to the actual location of the destination function. Though this adds an extra jump over the cost of an intra-module call, the performance hit is mostly negligible and easily worth the flexibility of dynamic libraries. If the compiler knows ahead of time that a call will be inter-module (via a dllimport attribute) it can produce more optimised code that simply results in an indirect call opcode.
An
application programming interface (API) is a source code interface that a computer system or program library provides to support requests for services to be made of it by a computer program. An API differs from an application binary interface in that it is specified in terms of a programming language that can be compiled when an application is built, rather than an explicit low level description of how data is laid out in memory.
The software that provides the functionality described by an API is said to be an
implementation of the API. The API itself is abstract, in that it specifies an interface and does not get involved with implementation details.
لاحظ أن ال Data Structure للملف PE الموجودة بالديسك هي نفسها التي يتم تحميلها بالذاكرة عند تشغيل البرنامج أي أنك إذا أردت الوصول لعنوان ما ستجده في الملف يالديسك وستجده بالذاكرة مع ملاحظة إختلاف Offset
PE Data Structure
ما يهمنا في هذه المرحلة هو التعرف علي شكل المصطلحات و سنري عمليا كل مصطلح خاصة عند التعامل مع Packers & Protectors
لا حظ الجدول السابق و الهيكل الذي يتكون منه ال PE ال PE Header موجود في ال Imagebase و الذي هو العنوانن الذي يبدأ فيه البرنامج يالتحميل في الذاكرة
A module is a piece of code+data+resources+other misc stuff that is loaded into memory.
The offset that the module is loaded from is called the image base. The module is loaded into memory from the image base until imagebase + module size.
حيث ال PE header = imagebase + 1000
آخر مصظلح هو EP أو Entry Point وهو بتبسيط شديد جدا نقطة بداية البرنامج أي أول نقظة يبدأ البرنامج فيها بالتعامل مع النظام
نعود إلي Register Me
في حالة Register Me فإن ال PE header = 40000 +1000
PE Header
C0 00 00 00 هي بداية Pe File header وهي نفسها 004000C0
ومهم جدا أن تفهم هذه النقطة وهي أن 004000C0 = C0000000
من فضلك إقرأ هذا المقال
http://en.wikipedia.org/wiki/EndiannessRVA :Relative Virtual Address
إفترض أن لدينا برنامج يبدأ تحميل عند العنوان 400000 و إذا كانت RVA = 4000 فإن ال EP لهذا البرنامج ستكون عند العنوان 404000
الآن لنذهب إلي العنوان 004000C0
الجمعة يناير 25, 2008 3:18 am