Image Loading
در برابر Manual Mapping
Windows Loader
چه کاری انجام میده و چرا تفاوت روش های بارگذاری برای تحلیل Memory مهمه؟
تا اینجا با ساختار PE مفهوم
حالا میرسیم به یکی از موضوعات مهم در مهندسی معکوس ویندوز:
تفاوت بین بارگذاری معمول یک فایل اجرایی و قرار گرفتن یک Image در حافظه به روشی متفاوت از مسیر عادی Loader
بارگذاری معمولی PE چطوری انجام میشه؟
وقتی Windows یک فایل اجرایی رو اجرا میکنه یا یک DLL رو به‌صورت معمول بارگذاری میکنه بخش های مختلف سیستم عامل در مدیریت این فرایند نقش دارن
نمای ساده شده:
PE File
|
v
Windows Loader
|
├── بررسی ساختار PE
├── آماده‌سازی Image
├── مدیریت وابستگی‌ها
├── پردازش Relocation در صورت نیاز
├── آماده‌سازی Importها
└── تکمیل مراحل لازم برای بارگذاری
|
v
Image in Memory
این نمودار ساده شده است
جزئیات واقعی به نوع Image وضعیت Process و مسیر بارگذاری بستگی دارن
نکته مهم اینه که بارگذاری PE فقط کپی کردن چند Byte از فایل به RAM نیست ساختار فایل باید برای استفاده در فضای آدرس مجازی آماده بشه و مراحل لازم برای وابستگی‌ها دسترسی حافظه و مقداردهی اولیه انجام بشن
Windows Loader
چه چیزهایی رو مدیریت میکنه؟
چند مورد مهم:
سکشن ها: بخش‌های مختلف Image در فضای آدرس مجازی نگاشت میشن
Relocation:
در صورت نیاز آدرس‌های وابسته به محل بارگذاری اصلاح میشن
Import
ها:
وابستگی های مورد نیاز برنامه مدیریت و آدرس توابع موردنیاز مشخص میشن
Memory Protection:
محدوده های مختلف حافظه Permission های متناسب با کاربردشون میگیرن
Initialization:
مراحل لازم برای آماده شدن Module برای استفاده انجام میشن
البته تمام مسئولیت ها در یک تابع واحد جمع نشده Windows Loadr Memory Manager و اجزای دیگه‌ی سیستم عامل در این فرایند نقش دارن
Manual Mapping
اصطلاح
به‌صورت مفهومی:
PE File
|
v
Custom Loading Logic
|
├── آماده‌سازی بخش‌های Image
├── مدیریت آدرس‌ها
├── رسیدگی به وابستگی‌ها
└── آماده‌سازی ساختار حافظه
|
v
Memory Region
این نمودار مفهوم کلی رو نشون میده نه یک پیاده‌سازی کامل جزئیات به نوع PE و روش مورد استفاده وابسته‌ان
Manual Mapping
به‌خودی‌خود مترادف بدافزار نیست بعضی ابزارهای تخصصی Runtime ها و محیط های آزمایشی ممکنه از روش‌های بارگذاری غیرمعمول استفاده کنن با این حال این مفهوم در تحلیل بعضی تکنیک‌های مخرب هم اهمیت داره
نکته مهم اینه که آماده کردن یک PE در حافظه به تنهایی به معنی کامل شدن تمام مراحل بارگذاری معمول ویندوز نیست مدیریت وابستگی‌ها Relocation ، Initialization و سایر جزئیات ممکنه به شکل متفاوتی انجام بشن یا نیازمند پیاده‌سازی جداگانه باشن
تفاوت اصلی از دید تحلیلگر چیه؟
فرض کنید دو Process داریم
در اولی یک DLL به شکل معمول بارگذاری شده:
Process A
|
└── Loaded Module
|
├── Module Information
├── Image Layout
└── Memory Permissions
در دومی یک ناحیه از حافظه وجود داره که محتوای اون شبیه یک Image اجراییه اما ارتباط واضحی با یک Module معمولی و قابل شناسایی نداره:
Process B
|
└── Memory Region
|
├── PE-like Structure
├── Memory Permissions
└── Unusual Module Relationship
این تفاوت میتونه برای بررسی بیشتر مهم باشه اما به‌تنهایی چیزی رو ثابت نمیکنه
برای مثال ممکنه یک ابزار تخصصی از روش بارگذاری متفاوتی استفاده کرده باشه یا اطلاعات Memory Dump برای شناسایی دقیق Module کافی نباشه
چرا فهرست Module ها همیشه کل داستان نیست؟
در ویندوز ابزارهای مختلفی وجود دارن که Module های یک Process رو نمایش میدن با این حال فهرست Module ها و تمام Memory های یک Process دو مفهوم متفاوت هستن
به این مدل توجه کنید:
Process Virtual Address Space
│
├── Executable Image
├── Loaded DLLs
├── Heap Allocations
├── Thread Stacks
├── Memory-Mapped Files
└── Other Memory Regions
هرکدوم از این بخش ها کاربرد متفاوتی دارن
در برابر Manual Mapping
Windows Loader
چه کاری انجام میده و چرا تفاوت روش های بارگذاری برای تحلیل Memory مهمه؟
تا اینجا با ساختار PE مفهوم
ImageBase جدول IAT و تفاوت Raw Offset با RVA آشنا شدیمحالا میرسیم به یکی از موضوعات مهم در مهندسی معکوس ویندوز:
تفاوت بین بارگذاری معمول یک فایل اجرایی و قرار گرفتن یک Image در حافظه به روشی متفاوت از مسیر عادی Loader
بارگذاری معمولی PE چطوری انجام میشه؟
وقتی Windows یک فایل اجرایی رو اجرا میکنه یا یک DLL رو به‌صورت معمول بارگذاری میکنه بخش های مختلف سیستم عامل در مدیریت این فرایند نقش دارن
نمای ساده شده:
PE File
|
v
Windows Loader
|
├── بررسی ساختار PE
├── آماده‌سازی Image
├── مدیریت وابستگی‌ها
├── پردازش Relocation در صورت نیاز
├── آماده‌سازی Importها
└── تکمیل مراحل لازم برای بارگذاری
|
v
Image in Memory
این نمودار ساده شده است
جزئیات واقعی به نوع Image وضعیت Process و مسیر بارگذاری بستگی دارن
نکته مهم اینه که بارگذاری PE فقط کپی کردن چند Byte از فایل به RAM نیست ساختار فایل باید برای استفاده در فضای آدرس مجازی آماده بشه و مراحل لازم برای وابستگی‌ها دسترسی حافظه و مقداردهی اولیه انجام بشن
Windows Loader
چه چیزهایی رو مدیریت میکنه؟
چند مورد مهم:
سکشن ها: بخش‌های مختلف Image در فضای آدرس مجازی نگاشت میشن
Relocation:
در صورت نیاز آدرس‌های وابسته به محل بارگذاری اصلاح میشن
Import
ها:
وابستگی های مورد نیاز برنامه مدیریت و آدرس توابع موردنیاز مشخص میشن
Memory Protection:
محدوده های مختلف حافظه Permission های متناسب با کاربردشون میگیرن
Initialization:
مراحل لازم برای آماده شدن Module برای استفاده انجام میشن
البته تمام مسئولیت ها در یک تابع واحد جمع نشده Windows Loadr Memory Manager و اجزای دیگه‌ی سیستم عامل در این فرایند نقش دارن
Manual Mapping
اصطلاح
Manual Mapping به روشی اشاره میکنه که در اون یک PE به‌جای اینکه تمام مسیر معمول بارگذاری Module رو طی کنه با منطق سفارشی در حافظه آماده میشهبهصورت مفهومی:
PE File
|
v
Custom Loading Logic
|
├── آماده‌سازی بخش‌های Image
├── مدیریت آدرس‌ها
├── رسیدگی به وابستگی‌ها
└── آماده‌سازی ساختار حافظه
|
v
Memory Region
این نمودار مفهوم کلی رو نشون میده نه یک پیاده‌سازی کامل جزئیات به نوع PE و روش مورد استفاده وابسته‌ان
Manual Mapping
به‌خودی‌خود مترادف بدافزار نیست بعضی ابزارهای تخصصی Runtime ها و محیط های آزمایشی ممکنه از روش‌های بارگذاری غیرمعمول استفاده کنن با این حال این مفهوم در تحلیل بعضی تکنیک‌های مخرب هم اهمیت داره
نکته مهم اینه که آماده کردن یک PE در حافظه به تنهایی به معنی کامل شدن تمام مراحل بارگذاری معمول ویندوز نیست مدیریت وابستگی‌ها Relocation ، Initialization و سایر جزئیات ممکنه به شکل متفاوتی انجام بشن یا نیازمند پیاده‌سازی جداگانه باشن
تفاوت اصلی از دید تحلیلگر چیه؟
فرض کنید دو Process داریم
در اولی یک DLL به شکل معمول بارگذاری شده:
Process A
|
└── Loaded Module
|
├── Module Information
├── Image Layout
└── Memory Permissions
در دومی یک ناحیه از حافظه وجود داره که محتوای اون شبیه یک Image اجراییه اما ارتباط واضحی با یک Module معمولی و قابل شناسایی نداره:
Process B
|
└── Memory Region
|
├── PE-like Structure
├── Memory Permissions
└── Unusual Module Relationship
این تفاوت میتونه برای بررسی بیشتر مهم باشه اما به‌تنهایی چیزی رو ثابت نمیکنه
برای مثال ممکنه یک ابزار تخصصی از روش بارگذاری متفاوتی استفاده کرده باشه یا اطلاعات Memory Dump برای شناسایی دقیق Module کافی نباشه
چرا فهرست Module ها همیشه کل داستان نیست؟
در ویندوز ابزارهای مختلفی وجود دارن که Module های یک Process رو نمایش میدن با این حال فهرست Module ها و تمام Memory های یک Process دو مفهوم متفاوت هستن
به این مدل توجه کنید:
Process Virtual Address Space
│
├── Executable Image
├── Loaded DLLs
├── Heap Allocations
├── Thread Stacks
├── Memory-Mapped Files
└── Other Memory Regions
هرکدوم از این بخش ها کاربرد متفاوتی دارن
بنابراین:
برای رسیدن به نتیجه باید ساختار حافظه منشا Region و رفتار Process رو کنار هم بررسی کنیم
تحلیلگر چه شواهدی رو بررسی میکنه؟
در بررسی یک Region غیرمعمول این دسته اطلاعات میتونن مفید باشن:
هیچکدوم از این موارد به‌تنهایی حکم قطعی نیستن ارزش اصلی زمانی ایجاد میشه که چند شاهد مستقل با هم تطبیق داده بشن
ارتباطش با EDR و Memory Forensics
از دید دفاعی یک سؤال مهم اینه:
آیا میشه با بررسی صرفا فهرست Module ها تمام رفتارهای مرتبط با اجرای کد رو شناخت؟ نه
فهرست Module ها فقط یک نمای محدود از وضعیت Process ارائه میده برای بررسی دقیق‌تر ممکنه به اطلاعاتی از این جنس نیاز باشه:
Process
|
├── Module Inventory
├── Virtual Memory Map
├── Memory Protection
├── Thread Information
├── Call Stack
└── Event Timeline
|
v
Behavior Analysis
این رویکرد کمک میکنه تفاوت بین رفتار طبیعی برنامه و فعالیت غیرمعمول بهتر بررسی بشه
یک نکته هم مهمه:
همه‌ی EDR ها به یک اندازه به این اطلاعات دسترسی ندارن یا همه‌ی اون‌ها رو به یک شکل تحلیل نمیکنن نتیجه به قابلیت محصول تنظیمات و Telemetry موجود بستگی داره
تمرین مفهومی:
دو وضعیت زیر رو مقایسه کنید
وضعیت اول:
Region Type: Image
Module: Known DLL
Protection: RX
وضعیت دوم:
Region Type: Private
Module: No obvious association
Protection: RX
صرفا از روی این اطلاعات نمیشه گفت وضعیت دوم مخربه اما در وضعیت دوم ممکنه لازم باشه اطلاعات بیشتری جمع‌آوری کنید
برای هر دو وضعیت این سؤال‌ها رو مطرح کن:
آیا ساختار حافظه با نوع Region سازگاره؟
آیا Thread ها و Call Stack اطلاعات مرتبطی ارائه میکنن؟
آیا رویداد های قبل و بعد از ایجاد Region توضیح قابل قبولی دارن؟
سه مفهوم رو از هم جدا نگه دارید:
Normal Image Loading:
بارگذاری از مسیر معمول ویندوز و مدیریت مراحل مرتبط با آن
Manual Mapping:
آماده‌سازی یک Image در حافظه با منطق بارگذاری متفاوت از مسیر معمول
Memory Forensics:
بررسی ساختار و وضعیت حافظه برای فهمیدن اتفاقاتی که داخل Process افتادن
این سه مفهوم به هم مرتبطن اما یکی نیستن
@reverseengine
اگر یک Region در فهرست Module ها دیده نشد نمیتونیم نتیجه بگیریم که حتما مخربه یا هیچ ارتباطی با یک فایل اجرایی نداره.
برای رسیدن به نتیجه باید ساختار حافظه منشا Region و رفتار Process رو کنار هم بررسی کنیم
تحلیلگر چه شواهدی رو بررسی میکنه؟
در بررسی یک Region غیرمعمول این دسته اطلاعات میتونن مفید باشن:
هیچکدوم از این موارد به‌تنهایی حکم قطعی نیستن ارزش اصلی زمانی ایجاد میشه که چند شاهد مستقل با هم تطبیق داده بشن
ارتباطش با EDR و Memory Forensics
از دید دفاعی یک سؤال مهم اینه:
آیا میشه با بررسی صرفا فهرست Module ها تمام رفتارهای مرتبط با اجرای کد رو شناخت؟ نه
فهرست Module ها فقط یک نمای محدود از وضعیت Process ارائه میده برای بررسی دقیق‌تر ممکنه به اطلاعاتی از این جنس نیاز باشه:
Process
|
├── Module Inventory
├── Virtual Memory Map
├── Memory Protection
├── Thread Information
├── Call Stack
└── Event Timeline
|
v
Behavior Analysis
این رویکرد کمک میکنه تفاوت بین رفتار طبیعی برنامه و فعالیت غیرمعمول بهتر بررسی بشه
یک نکته هم مهمه:
همه‌ی EDR ها به یک اندازه به این اطلاعات دسترسی ندارن یا همه‌ی اون‌ها رو به یک شکل تحلیل نمیکنن نتیجه به قابلیت محصول تنظیمات و Telemetry موجود بستگی داره
تمرین مفهومی:
دو وضعیت زیر رو مقایسه کنید
وضعیت اول:
Region Type: Image
Module: Known DLL
Protection: RX
وضعیت دوم:
Region Type: Private
Module: No obvious association
Protection: RX
صرفا از روی این اطلاعات نمیشه گفت وضعیت دوم مخربه اما در وضعیت دوم ممکنه لازم باشه اطلاعات بیشتری جمع‌آوری کنید
برای هر دو وضعیت این سؤال‌ها رو مطرح کن:
آیا ساختار حافظه با نوع Region سازگاره؟
آیا Thread ها و Call Stack اطلاعات مرتبطی ارائه میکنن؟
آیا رویداد های قبل و بعد از ایجاد Region توضیح قابل قبولی دارن؟
سه مفهوم رو از هم جدا نگه دارید:
Normal Image Loading:
بارگذاری از مسیر معمول ویندوز و مدیریت مراحل مرتبط با آن
Manual Mapping:
آماده‌سازی یک Image در حافظه با منطق بارگذاری متفاوت از مسیر معمول
Memory Forensics:
بررسی ساختار و وضعیت حافظه برای فهمیدن اتفاقاتی که داخل Process افتادن
این سه مفهوم به هم مرتبطن اما یکی نیستن
@reverseengine
ReverseEngineering
Image Loading در برابر Manual Mapping Windows Loader چه کاری انجام میده و چرا تفاوت روش های بارگذاری برای تحلیل Memory مهمه؟ تا اینجا با ساختار PE مفهوم ImageBase جدول IAT و تفاوت Raw Offset با RVA آشنا شدیم حالا میرسیم به یکی از موضوعات مهم در مهندسی…
Image Loading
vs. Manual Mapping
What does Windows Loader do and why are the differences in loading methods important for memory analysis?
So far, we have learned about the PE structure, the concept of the ImageBase table, and the difference between Raw Offset and RVA
Now we come to one of the important topics in Windows reverse engineering:
The difference between normal loading of an executable file and placing an Image in memory in a different way from the normal Loader path
How is normal PE loading done?
When Windows runs an executable file or loads a DLL normally, various parts of the operating system play a role in managing this process
Simplified view:
PE File
|
v
Windows Loader
|
├── Examine the PE structure
├── Prepare the Image
├── Manage dependencies
├── Process relocation if necessary
├── Prepare imports
└── Complete the steps required for loading
|
v
Image in Memory
This diagram is simplified
The actual details depend on the Image type, Process state, and loading path
The important thing is that PE loading is not just copying a few bytes from the file to RAM. The file structure must be prepared for use in the virtual address space, and the necessary steps for dependencies, memory access, and initialization must be performed
What does the Windows Loader handle?
Some important things:
Sections: Different parts of the image are mapped to the virtual address space
Relocation:
If necessary, the addresses dependent on the loading location are modified
Imports:
The dependencies required by the management program and the addresses of the required functions are specified
Memory Protection:
Different memory areas receive permissions appropriate to their use
Initialization:
The steps necessary to prepare the module for use are performed
Of course, not all responsibilities are collected in a single function. The Windows Loader Memory Manager and other operating system components play a role in this process
Manual Mapping
The term Manual Mapping refers to a method in which a PE is prepared in memory with custom logic instead of going through the entire usual module loading path
Conceptually:
PE File
|
v
Custom Loading Logic
|
├── Preparing Image Sections
├── Address Management
├── Handling Dependencies
└── Preparing the Memory Structure
|
v
Memory Region
This diagram shows the general concept, not a complete implementation, details the type of PE and the method used by the dependencies
Manual Mapping
It is not synonymous with malware in itself. Some specialized tools, runtimes and test environments may use unusual loading methods. However, this concept is also important in analyzing some malicious techniques
The important point is that preparing a PE in memory alone does not mean that all the usual Windows loading steps have been completed. Dependency management, relocation, initialization and other details may be done differently or require separate implementations
What is the main difference from the analyst's point of view?
Suppose we have two processes
In the first, a DLL is loaded in the usual way:
Process A
|
└── Loaded Module
|
├── Module Information
├── Image Layout
└── Memory Permissions
In the second, there is a region of memory whose content resembles an executable image but has no clear relationship to a regular and identifiable module:
Process B
|
└── Memory Region
|
├── PE-like Structure
├── Memory Permissions
└── Unusual Module Relationship
This difference can be important for further investigation, but it does not prove anything by itself
For example, a specialized tool may have used a different loading method, or the Memory Dump information may not be enough to accurately identify the Module
Why is the Module List not always the whole story?
In Windows, there are various tools that display the Modules of a Process, however, the Module List and the Total Memory of a Process are two different concepts
Pay attention to this model:
vs. Manual Mapping
What does Windows Loader do and why are the differences in loading methods important for memory analysis?
So far, we have learned about the PE structure, the concept of the ImageBase table, and the difference between Raw Offset and RVA
Now we come to one of the important topics in Windows reverse engineering:
The difference between normal loading of an executable file and placing an Image in memory in a different way from the normal Loader path
How is normal PE loading done?
When Windows runs an executable file or loads a DLL normally, various parts of the operating system play a role in managing this process
Simplified view:
PE File
|
v
Windows Loader
|
├── Examine the PE structure
├── Prepare the Image
├── Manage dependencies
├── Process relocation if necessary
├── Prepare imports
└── Complete the steps required for loading
|
v
Image in Memory
This diagram is simplified
The actual details depend on the Image type, Process state, and loading path
The important thing is that PE loading is not just copying a few bytes from the file to RAM. The file structure must be prepared for use in the virtual address space, and the necessary steps for dependencies, memory access, and initialization must be performed
What does the Windows Loader handle?
Some important things:
Sections: Different parts of the image are mapped to the virtual address space
Relocation:
If necessary, the addresses dependent on the loading location are modified
Imports:
The dependencies required by the management program and the addresses of the required functions are specified
Memory Protection:
Different memory areas receive permissions appropriate to their use
Initialization:
The steps necessary to prepare the module for use are performed
Of course, not all responsibilities are collected in a single function. The Windows Loader Memory Manager and other operating system components play a role in this process
Manual Mapping
The term Manual Mapping refers to a method in which a PE is prepared in memory with custom logic instead of going through the entire usual module loading path
Conceptually:
PE File
|
v
Custom Loading Logic
|
├── Preparing Image Sections
├── Address Management
├── Handling Dependencies
└── Preparing the Memory Structure
|
v
Memory Region
This diagram shows the general concept, not a complete implementation, details the type of PE and the method used by the dependencies
Manual Mapping
It is not synonymous with malware in itself. Some specialized tools, runtimes and test environments may use unusual loading methods. However, this concept is also important in analyzing some malicious techniques
The important point is that preparing a PE in memory alone does not mean that all the usual Windows loading steps have been completed. Dependency management, relocation, initialization and other details may be done differently or require separate implementations
What is the main difference from the analyst's point of view?
Suppose we have two processes
In the first, a DLL is loaded in the usual way:
Process A
|
└── Loaded Module
|
├── Module Information
├── Image Layout
└── Memory Permissions
In the second, there is a region of memory whose content resembles an executable image but has no clear relationship to a regular and identifiable module:
Process B
|
└── Memory Region
|
├── PE-like Structure
├── Memory Permissions
└── Unusual Module Relationship
This difference can be important for further investigation, but it does not prove anything by itself
For example, a specialized tool may have used a different loading method, or the Memory Dump information may not be enough to accurately identify the Module
Why is the Module List not always the whole story?
In Windows, there are various tools that display the Modules of a Process, however, the Module List and the Total Memory of a Process are two different concepts
Pay attention to this model:
ReverseEngineering
Image Loading در برابر Manual Mapping Windows Loader چه کاری انجام میده و چرا تفاوت روش های بارگذاری برای تحلیل Memory مهمه؟ تا اینجا با ساختار PE مفهوم ImageBase جدول IAT و تفاوت Raw Offset با RVA آشنا شدیم حالا میرسیم به یکی از موضوعات مهم در مهندسی…
Process Virtual Address Space
│
├── Executable Image
├── Loaded DLLs
├── Heap Allocations
├── Thread Stacks
├── Memory-Mapped Files
└── Other Memory Regions
Each of these sections has a different purpose
│
├── Executable Image
├── Loaded DLLs
├── Heap Allocations
├── Thread Stacks
├── Memory-Mapped Files
└── Other Memory Regions
Each of these sections has a different purpose
Consider this:
If a memory region does not appear in the list of loaded modules, should we conclude that it is necessarily malicious or unrelated to any executable file?
To reach a conclusion, we must examine the memory structure, the origin of the region, and the process's behavior in conjunction with one another.
What evidence does an analyst examine?
When investigating an unusual memory region, the following types of information can be useful:
None of these factors, taken in isolation, constitute definitive proof; the real value lies in how they are correlated with one another.
Relevance to EDR and Memory Forensics
From a defensive perspective, a key question arises:
Is it possible to identify all behaviors associated with code execution solely by examining the list of loaded modules? No.
The module list provides only a limited view of the process's state. A more thorough investigation may require data such as:
Process
|
├── Module Inventory
├── Virtual Memory Map
├── Memory Protection
├── Thread Information
├── Call Stack
└── Event Timeline
|
v
Behavioral Analysis
This facilitates a better distinction between the application's normal behavior and anomalous activity.
An important caveat:
Not all EDR (Endpoint Detection and Response) solutions have equal access to this information, nor do they all analyze it in the same way; the outcome depends on the quality of the product and the available telemetry.
Conceptual Exercise:
Compare the following two scenarios:
Scenario 1:
Region Type: Image
Module: Known DLL
Protection: RX (Read/Execute)
Scenario 2:
Region Type: Private
Module: No clear association
Protection: RX (Read/Execute)
Based solely on this information, one cannot definitively label the second scenario as malicious; however, it may warrant further data collection.
For both scenarios, ask the following question:
Is the memory structure consistent with the region type? Do the threads and the call stack provide relevant information?
Are there events occurring before and after the creation of a memory region?
Keep these three concepts distinct:
Standard Image Loading:
Loading via the conventional Windows path and managing the associated steps.
Manual Mapping:
Preparing an image in memory using loading logic that differs from the standard path.
Memory Forensics:
Examining the structure and state of memory to understand the events that took place within a process.
While related, these three concepts are not the same.
@reverseengine
If a memory region does not appear in the list of loaded modules, should we conclude that it is necessarily malicious or unrelated to any executable file?
To reach a conclusion, we must examine the memory structure, the origin of the region, and the process's behavior in conjunction with one another.
What evidence does an analyst examine?
When investigating an unusual memory region, the following types of information can be useful:
None of these factors, taken in isolation, constitute definitive proof; the real value lies in how they are correlated with one another.
Relevance to EDR and Memory Forensics
From a defensive perspective, a key question arises:
Is it possible to identify all behaviors associated with code execution solely by examining the list of loaded modules? No.
The module list provides only a limited view of the process's state. A more thorough investigation may require data such as:
Process
|
├── Module Inventory
├── Virtual Memory Map
├── Memory Protection
├── Thread Information
├── Call Stack
└── Event Timeline
|
v
Behavioral Analysis
This facilitates a better distinction between the application's normal behavior and anomalous activity.
An important caveat:
Not all EDR (Endpoint Detection and Response) solutions have equal access to this information, nor do they all analyze it in the same way; the outcome depends on the quality of the product and the available telemetry.
Conceptual Exercise:
Compare the following two scenarios:
Scenario 1:
Region Type: Image
Module: Known DLL
Protection: RX (Read/Execute)
Scenario 2:
Region Type: Private
Module: No clear association
Protection: RX (Read/Execute)
Based solely on this information, one cannot definitively label the second scenario as malicious; however, it may warrant further data collection.
For both scenarios, ask the following question:
Is the memory structure consistent with the region type? Do the threads and the call stack provide relevant information?
Are there events occurring before and after the creation of a memory region?
Keep these three concepts distinct:
Standard Image Loading:
Loading via the conventional Windows path and managing the associated steps.
Manual Mapping:
Preparing an image in memory using loading logic that differs from the standard path.
Memory Forensics:
Examining the structure and state of memory to understand the events that took place within a process.
While related, these three concepts are not the same.
@reverseengine
Writing a Hyper-V Bridge for Fuzzing
https://www.alex-ionescu.com/writing-a-hyper-v-bridge-for-fuzzing-part-1-wdf
@reverseengine
https://www.alex-ionescu.com/writing-a-hyper-v-bridge-for-fuzzing-part-1-wdf
@reverseengine
REA Is Impressive. But Reverse Engineering Was Never the New Part
https://crizantlai.medium.com/rea-is-impressive-but-reverse-engineering-was-never-the-new-part-ae5b26b958a1
https://crizantlai.medium.com/rea-is-impressive-but-reverse-engineering-was-never-the-new-part-ae5b26b958a1
How Dangerous Is REA (Reverse Engineer Anything) for Your App?
https://21zerixpm.medium.com/how-dangerous-is-rea-reverse-engineer-anything-for-your-app-2fce588968f1
@reverseengine
https://21zerixpm.medium.com/how-dangerous-is-rea-reverse-engineer-anything-for-your-app-2fce588968f1
@reverseengine
Medium
How Dangerous Is REA (Reverse Engineer Anything) for Your App?
An iOS developer’s look at the AI tool that took over GitHub Trending, and what it means for your app and your business.
Someone Used AI to Reverse-Engineer PS5 Security in Weeks: What Is REA?
https://pub.towardsai.net/someone-used-ai-to-reverse-engineer-ps5-security-in-weeks-what-is-rea-11aed6dd106e
https://pub.towardsai.net/someone-used-ai-to-reverse-engineer-ps5-security-in-weeks-what-is-rea-11aed6dd106e
Medium
Someone Used AI to Reverse-Engineer PS5 Security in Weeks: What Is REA?
A viral tweet, a trending GitHub repo and the honest line between what AI actually did and what it didn’t
Reverse Engineer Anything v6.5.0
A tool for reverse engineering that allows AI agents to analyze applications and binary files without access to the source code
https://github.com/morluto/rea
@reverseengine
A tool for reverse engineering that allows AI agents to analyze applications and binary files without access to the source code
https://github.com/morluto/rea
@reverseengine
GitHub
GitHub - morluto/rea: Reverse engineer anything with agents, from app behavior down to native binaries.
Reverse engineer anything with agents, from app behavior down to native binaries. - morluto/rea