ReverseEngineering

🛡️ Anti-Memory Dumping Techniques یکی از روش‌های محبوب تحلیل‌گرا Dump گرفتن از حافظه‌ی پروسه هست با این کار حتی اگر فایل اصلی روی دیسک رمزگذاری یا پک شده باشه نسخه‌ی در حال اجرا (Decrypt شده در RAM) رو میگیرن و آنالیز میکنن برای مقابله با این موضوع تکنیک‌های مختلفی وجود داره: 1️⃣ پاک‌کردن خودکار حافظه بعد از استفاده برخی بدافزارها یا نرم‌افزارهای حساس وقتی کدی رو از حالت رمز خارج کردن و اجرا کردن بلافاصله دوباره اون بخش رو پاک میکنن یا دوباره Encrypt میکنن به این میگن Just-In-Time Decryption 📌 مثال: فانکشن قبل از اجرا Decrypt میشه اجرا میشه بعد از اجرا دوباره Encrypt یا پاک میشه 2️⃣ استفاده از APIهای ویندوز برای تغییر دسترسی حافظه با توابعی مثل VirtualProtect میشه حافظه‌ی پروسه رو فقط در حالت Execute قرار داد (بدون Read) در این حالت ابزارهایی مثل ProcessDump نمیتونن راحت محتوا رو بخونن VirtualProtect(address, size, PAGE_EXECUTE, &oldProtect); 3️⃣ تشخیص وجود ابزارهای Dump برنامه میتونه چک کنه که ابزارهایی مثل ProcDump Scylla یا OllyDump در حال اجرا هستن یا نه این کار با APIهایی مثل CreateToolhelp32Snapshot و لیست کردن پروسه‌ها انجام میشه 4️⃣ استفاده از Anti-Attach / Handle Protection برخی نرم‌افزارها سعی می‌کنن مانع بشن که دیباگر یا ابزار خارجی بتونه به پروسه Attach بشه و Memory Dump بگیره مثلا با API زیر: SetInformationProcess(GetCurrentProcess(), ProcessDebugFlags, &flags, sizeof(flags)); 5️⃣ Fragmentation یا Fake Memory برنامه می‌تونه داده‌های حساس رو به چندین بخش در حافظه تقسیم کنه و بین اونها داده‌های تقلبی (Fake) قرار بده وقتی تحلیل‌گر Dump می‌گیره با کلی داده بی‌معنی و قاطی روبرو میشه و پیدا کردن بخش واقعی خیلی سخت میشه 6️⃣ استفاده از Driver سطح کرنل برخی حفاظت‌های خیلی پیشرفته در سطح Kernel Driver پیاده‌سازی میشن مثلا جلوی APIهای معمولی برای Dump گرفتن رو میگیرن یا دسترسی Read رو Hook میکنن 🛡️ Anti-Memory Dumping Techniques One of the most popular methods analysts use is dumping the process memory With this even if the original file on disk is encrypted or packed they can capture the running (decrypted in RAM) version and analyze it To counter this, various techniques exist: 1️⃣ Automatic Memory Wiping After Use Some malware or sensitive software once they decrypt and execute code immediately wipe that section again or re-encrypt it This is called Just-In-Time Decryption 📌 Example: Function is decrypted before execution Executed After execution it’s re-encrypted or wiped again 2️⃣ Using Windows APIs to Change Memory Access With APIs like VirtualProtect process memory can be set to Execute-only (no Read) In this case tools like ProcessDump cannot easily read the contents VirtualProtect(address, size, PAGE_EXECUTE, &oldProtect); 3️⃣ Detecting Dumping Tools The program can check if tools such as ProcDump Scylla or OllyDump are running This can be done with APIs like CreateToolhelp32Snapshot to list processes 4️⃣ Anti-Attach / Handle Protection Some software tries to prevent a debugger or external tool from attaching to the process and dumping memory For example, using the API below: SetInformationProcess(GetCurrentProcess(), ProcessDebugFlags, &flags, sizeof(flags)); 5️⃣ Fragmentation or Fake Memory The program can split sensitive data into multiple memory sections and insert fake (decoy) data between them When an analyst dumps memory they’re faced with lots of meaningless, mixed data making it very difficult to find the real part 6️⃣ Kernel-Level Driver Usage Some advanced protections are implemented at the kernel driver level For example, blocking standard APIs for dumping or hooking memory Read access

🔴 One of the features of IDA Pro is the ability to write scripts in this tool, with which you can automate your tasks. IDA Python SDK is usually used for scripting. But the problem is that for simple tasks, it requires repetitive and long coding. To solve this problem, Hex-Rays has introduced the IDA Domain API as an open source, which makes it easier to write scripts in Python for IDA. Currently, version v0.1.0 of this tool is available for IDA 9.1, which you can access from here. The word Domain refers to the field of reverse engineering. In this field, concepts such as functions, types, etc. are key concepts, and the Domain API makes it easier to use these concepts. In fact, the Domain API is built on the IDA Python SDK and provides a clean and focused abstraction layer. Its goal is not to replace the SDK, but to complement it. You can use both together: the simplicity of the Domain API for everyday tasks, and the full flexibility of the SDK for complex tasks. #ReverseEngineering #ReverseEngineering #IDAPro #SDK 🆔 @onhex_ir ➡️ ALL Link

🔴 یکی از قابلیتهای IDA Pro امکان اسکریپت نویسی در این ابزار هستش که باهاش میتونید، کارهاتون رو خودکار کنید. برای اسکریپت نویسی معمولا از IDA Python SDK استفاده میشه. اما مشکلی که داره اینه که برای کارهای ساده، نیاز به کدنویسی تکراری و طولانی هستش. شرکت Hex-Rays برای حل این مشکل IDA Domain API رو بصورت متن باز معرفی کرده که امکان اسکریپت نویسی در پایتون، برای IDA رو ساده تر میکنه. فعلا نسخه ی v0.1.0 این ابزار برای IDA 9.1 در دسترس هستش که میتونید از اینجا بهش دسترسی داشته باشید. کلمه ی Domain اشاره به حوزه ی مهندسی معکوس داره. در این حوزه مفاهیمی مانند توابع، انواع و ... جزء مفاهیم کلیدی هستن و Domain API استفاده از این مفاهیم رو ساده تر میکنه. در حقیقت Domain API روی IDA Python SDK ساخته شده و یک لایه‌ی انتزاعی تمیز و متمرکز ارائه میده. هدفش جایگزینی SDK نیست، بلکه مکملش هستش. میتونید هر دو رو کنار هم استفاده کنید: سادگی Domain API برای وظایف روزمره، و انعطاف کامل SDK برای کارهای پیچیده. #مهندسی_معکوس #ReverseEngineering #IDAPro #SDK 🆔 @onhex_ir ➡️ ALL Link

🔴 One of the features of IDA Pro is the ability to write scripts in this tool, with which you can automate your tasks. IDA Python SDK is usually used for scripting. But the problem is that for simple tasks, it requires repetitive and long coding. To solve this problem, Hex-Rays has introduced the IDA Domain API as an open source, which makes it easier to write scripts in Python for IDA. Currently, version v0.1.0 of this tool is available for IDA 9.1, which you can access from here. The word Domain refers to the field of reverse engineering. In this field, concepts such as functions, types, etc. are key concepts, and the Domain API makes it easier to use these concepts. In fact, the Domain API is built on the IDA Python SDK and provides a clean and focused abstraction layer. Its goal is not to replace the SDK, but to complement it. You can use both together: the simplicity of the Domain API for everyday tasks, and the full flexibility of the SDK for complex tasks. #ReverseEngineering #ReverseEngineering #IDAPro #SDK 🆔 @onhex_ir ➡️ ALL Link

تغییر کد در حین اجرا (Self-Modifying Code) وقتی کد وسط اجرا تغییر کنه، Single-Step باعث میشه دیباگر نسخه کش‌شده در حافظه رو نمایش بده و نه نسخه واقعی این تفاوت میتونه برای شناسایی دیباگر استفاده بشه استفاده از دستورهای غیرمستند (Undocumented Instructions) برخی دستورها مثل ICEBP (opcode: F1) برای دیباگرها مشکل‌ساز هستن در حالت عادی سیستم با این دستور رفتار خاصی نمیکنه ولی وقتی دیباگر فعال باشه باعث توقف آنی میشه وقفه‌های زمان‌بندی‌شده (Timed Exceptions) برنامه میتونه در یک حلقه عملیات زمان‌بر رو چک کنه اگر طولانی‌تر از حد مجاز بشه (به دلیل Single-Step) برنامه متوجه میشه که داره دیباگ میشه Self-Modifying Code When code is modified during execution Single-Step debugging can cause the debugger to display the cached version of the code in memory instead of the actual modified version This discrepancy can be used to detect the presence of a debugger Using Undocumented Instructions Some instructions such as ICEBP (opcode: F1) can cause issues for debuggers Under normal circumstances the system doesn’t show any special behavior for these instructions, but when a debugger is active executing them will trigger an immediate break Timed Exceptions A program can monitor the execution time of certain loops or operations If execution takes longer than a predefined threshold (due to Single-Step debugging) the program can detect that it’s being debugged

استفاده از API مخصوص دیباگرها در ویندوز اگر روی یک Thread فلگ Trap Flag (TF) فعال باشه یعنی دیباگر در حالت Single-Step قرار داره با تابع GetThreadContext میشه مقدار رجیستر EFLAGS/RFLAGS رو خوند و بررسی کرد:

CONTEXT ctx; ctx.ContextFlags = CONTEXT_FULL; GetThreadContext(GetCurrentThread(), &ctx); if (ctx.EFlags & 0x100) // Trap Flag فعال {     // دیباگر در حالت Single-Step }

Using Debugger-Specific APIs In Windows if the Trap Flag (TF) is enabled on a thread it means the debugger is in Single-Step mode By using the GetThreadContext function you can read the value of the EFLAGS/RFLAGS register and check it:

CONTEXT ctx; ctx.ContextFlags = CONTEXT_FULL; GetThreadContext(GetCurrentThread(), &ctx); if (ctx.EFlags & 0x100) // Trap Flag is enabled { // Debugger is in Single-Step mode }

🛡️ 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 script 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 script-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 script 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

استفاده از 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



مرجع اصلی برای یادگیری IDA Pro از پایه تا استفاده پیشرفته و اسکریپت‌نویسی The ultimate reference for learning IDA Pro from basics to advanced usage and scripting

🎯 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

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

mov rax, rdi

یعنی داره پارامتر اول رو توی خروجی میزاره That means it is putting the first parameter in the output

add rax, rsi

پارامتر دوم اضافه میشه The second parameter is added

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