ReverseEngineering

Leaf Functions:

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

🌑 بدون استفاده از استک 🌕 فقط جمع میکنه و برمیگرده 🌑No stack usage 🌕Just collect and return

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

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

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

Nested Function Calls:

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

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

How Hackers Crack Every Software: How it's done

How Hackers Crack Every Software: How it's done

💉 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

6 Diagnostic notes — timestamp inconsistencies, empty module paths, etc 7 Mitigation — use Sysmon rules + YARA + process hardening + EDR tuning

From Creation to Detection: The Complete Map for Identifying Process Hollowing, Doppelgänging, and Their Dark Allies When a process “wears the mask of legitimacy,” your real job isn’t to figure out how it was made — it’s to discover when and how the masks slip off. This post summarizes techniques and checklists every reverse engineer and defender should know. 1) Setting up a Safe Lab Environment for Practice (Must be Isolated) Use a separate VM, isolated from production networks, with snapshots enabled. Use segregated networks: one for analysis (internal), and one for limited internet updates or none. Use tools like VirtualBox/VMware, REMnux, Cuckoo sandbox for analysis. Always use benign or educational samples (with payloads like just a MessageBox or harmless behavior). Real samples should only be analyzed in read-only mode and in a controlled environment. 2) Quick Checklist for Real-time Identification (Runtime Indicators) Module mismatch: Hash of the file on disk differs from the loaded module in memory. RWX pages: Presence of memory pages with Read-Write-Execute permissions in processes where they shouldn’t exist. Unmapped PE header: Process runs a PE file but the PE header in memory is unmapped or modified. EntryPoint inconsistency: Entry point (EP) in memory differs from the EP in the file on disk. Suspended + APC activity: Process created with CREATE_SUSPENDED and before resume, the APC queue contains code to execute (Early Bird injection). Parent-child oddities: Unusual parent/child process chains (e.g., a system service suddenly spawning explorer.exe), or inconsistent creation timestamps. 3) Practical Tools and Commands for Hunting (Executable in Lab) A PE-sieve (Memory Scanner) Scan a PID and dump suspicious sections: pe-sieve64.exe /pid <PID> /dump_mode 3 Look for replaced sections or unlinked headers. B Volatility (Memory Forensics) List processes: volatility -f mem.raw --profile=Win10x64_19041 pslist Find suspicious pages and extract shellcode: volatility -f mem.raw --profile=Win10x64_19041 malfind Check APC queues or thread contexts (plugins vary by Volatility version). C Process Hacker / Process Explorer Examine loaded modules, file paths; if module path is empty or shows <unknown>, it’s suspicious. Check Threads and APC queues for unusual activity. D. PE-sieve + hollows_hunter hollows_hunter is great for detecting hollowed processes; compare its output with pe-sieve. 4) YARA and Sysmon Rules for Behavioral Hunting Sample YARA rule (for detecting suspicious patterns in memory/dumps): rule suspicious_rwx_code { meta: author = "channel_dark_lab" description = "Detects potential RWX memory containing suspicious patterns (heuristic)" strings: $xor_stub = { 31 C0 31 DB 31 C9 31 D2 } // common xor zeroing stub (example heuristic) $jmp = { FF 25 ?? ?? ?? ?? } // indirect jmp dword ptr [...] condition: uint16(0) == 0x5A4D and // PE signature (if scanning dumps) any of ($xor_stub, $jmp) } Sysmon snippets (key events to log): Log ProcessCreate and CommandLine. Log CreateRemoteThread and WriteProcessMemory activities (enable respective Event IDs). Log ImageLoad and check for mismatches between module path and image hash. Example Sysmon EventFiltering snippet: <!-- detect suspicious CreateRemoteThread-like sequences --> <ProcessCreate onmatch="include"> <CommandLine condition="contains">notepad.exe</CommandLine> </ProcessCreate> <ImageLoaded onmatch="include"> <Image condition="contains">.dll</Image> </ImageLoaded> 5) Step-by-Step Analysis Workflow of a “Hollowed Process” Sample 1 How was the sample created? (In lab, using a benign PoC) 2 Take snapshots of before/after states(process list, modules, entry point) 3 Run pe-sieve → review replaced sections / unmapped headers report. Display outputs. 4 Dump from memory → open dump in IDA/x64dbg → go to EP → observe shellcode (without exploit details) 5 Use Volatility malfind → show RWX pages and offsets.

"از ساخت تا شکار: نقشهٔ کامل برای تشخیص Process Hollowing، Doppelgänging و همکارانِ تاریک" وقتی یک پردازش «لباسِ قانون» می‌پوشد، کار واقعی تو نیست که بفهمی چطور ساخته شده — کار تو اینه که بفهمی چه‌وقت و چگونه ماسک‌ها از جا می‌افتند. این پست خلاصهٔ تکنیک‌ها و چک‌لیست‌هایی هست که هر مهندس معکوس و مدافع باید بلد باشه. 1) آماده‌سازی لَب امن برای تمرین (حتماً ایزوله) از VM جدا، بدون دسترسی به شبکه تولیدی، با snapshots فعال استفاده کن دو شبکه مجزا: one for analysis (internal) ، one for internet-limited updates (or none). از ابزارهایی مثل: VirtualBox/VMware, REMnux/Cuckoo (برای sandboxing) استفاده کن همیشه از نمونه‌های benign یا نمونه‌های آموزشی (که payloadش فقط MessageBox یا benign behavior داره) استفاده کن؛ نمونه‌های واقعی باید فقط به‌صورت read-only و در محیط کنترل‌شده آنالیز شوند. 2) چک‌لیست سریع برای شناسایی در لحظه (Runtime indicators) Module mismatch: هش فایلِ فایل روی دیسک با محتوای module در حافظه یکی نیست RWX pages: وجود صفحات حافظه با پرمیشن RWX در پروسس‌هایی که نباید داشته باشند Unmapped PE header: Process دارد از PE اجرا می‌شود ولی هدر PE در حافظه unmapped یا تغییر کرده است. EntryPoint inconsistency: نقطهٔ ورود (EP) حافظه با EP فایل روی دیسک فرق دارد. Suspended + APC activity: پروسه با CREATE_SUSPENDED ساخته شده و قبل از resume صف APC حاوی code اجراست (Early Bird). Parent-child oddities: زنجیرهٔ والد/فرزند غیرمنطقی (مثلاً یک سرویس سیستمی که ناگهانی child‌اش explorer است) یا تاریخ/زمان ایجاد ناهمگون. 3) ابزارها و دستورات عملی برای شکار (قابل اجرا در لَب) A PE-sieve (برای اسکن در‌حافظه) # اسکن یک PID و گرفتن dump pe-sieve64.exe /pid <PID> /dump_mode 3 # دنبال replaced sections یا unlinked headers باش B Volatility (for memory forensics) # لیست پروسس‌ها volatility -f mem.raw --profile=Win10x64_19041 pslist # پیدا کردن صفحات مشکوک و شکستن shellcode volatility -f mem.raw --profile=Win10x64_19041 malfind # بررسی APC queue یا thread context (پروفایل و پلاگین‌ها بسته به نسخه‌ی volatility فرق دارد) C Process Hacker / Process Explorer نگاه کن به ماژول‌های لودشده، مسیر فایل، و اگر module path خالی یا <> وجود دارد، مشکوک است چک کن بخش Threads و APC queue برای activity عجیب D PE-sieve + hollows_hunter hollows_hunter برای detection of hollowed processes عالیه؛ output رو با pe-sieve مقایسه کن 4) قواعد YARA و Sysmon برای شکار رفتارها نمونهٔ Rule سادهٔ YARA (فقط برای تشخیص الگوهای مشکوک در حافظه / dump) > این rule یک rule نمونه است و برای محیط خودت باید آن را فاین‌تیون کنی. rule suspicious_rwx_code { meta: author = "channel_dark_lab" description = "Detects potential RWX memory containing suspicious patterns (heuristic)" strings: $xor_stub = { 31 C0 31 DB 31 C9 31 D2 } // common xor zeroing stub (example heuristic) $jmp = { FF 25 ?? ?? ?? ?? } // indirect jmp dword ptr [...] condition: uint16(0) == 0x5A4D and // PE signature (if scanning dumps) any of ($xor_stub, $jmp) } Sysmon snippets (رویدادهای کلیدی) لاگ کردن ProcessCreate و CommandLine لاگ کردن CreateRemoteThread / WriteProcessMemory activities (Event IDs مربوطه را فعال کن) لاگ کردن ImageLoad و بررسی mismatch بین module path و image hash. نمونهٔ خط Rule برای Sysmon (بخش EventFiltering): <!-- detect suspicious CreateRemoteThread-like sequences --> <ProcessCreate onmatch="include"> <CommandLine condition="contains">notepad.exe</CommandLine> </ProcessCreate> <ImageLoaded onmatch="include"> <Image condition="contains">.dll</Image> </ImageLoaded> 5) تحلیل مرحله‌ایِ یک نمونهٔ "Hollowed process" (Workflow for a post) 1 چطوری نمونه تهیه شد؟ (در لَب، با PoC benign) 2 Snapshot از وضعیت قبل/بعد (Process list, modules, EP). 3 pe-sieve run → گزارش replaced section / unmapped header. نمایش خروجی 4 Dump from memory → باز کردن dump در IDA/x64dbg → رفتن به EP → مشاهدهٔ shellcode (بدون جزئیات exploit). 5 Volatility malfind → نمایش صفحات RWX و offsets. 6 نکات تشخیصی — timestamp inconsistency, module path empty، و غیره 7Mitigation — Sysmon rule + Yara + process hardening + EDR tuning.

🛡 استفاده از Timing Checks برای شناسایی دیباگر یکی از روش‌های ساده اما مؤثر برای فهمیدن این که برنامه تحت دیباگ اجرا میشه یا نه، چک کردن زمان اجرای بخش‌های مشخصی از کد هست. ایده اینه که وقتی دیباگر در حال بررسی برنامه‌ست، به دلیل توقف‌های مکرر (Breakpoints) و اجرای مرحله‌به‌مرحله (Step-by-step)، اجرای کد به‌طور قابل‌توجهی کندتر میشه 1️⃣ ایده اصلی برنامه یک بازه زمانی رو اندازه‌گیری می‌کنه و اگر زمان بیشتر از حد انتظار باشه → یعنی احتمالاً دیباگر فعال بوده 2️⃣ روش پیاده‌سازی دو روش رایج وجود داره: APIهای سیستم‌عامل مثل GetTickCount, QueryPerformanceCounter در ویندوز دستورات CPU مثل RDTSC که زمان CPU cycle رو می‌ده مثال اسمبلی (x86)

rdtsc ; Read Time-Stamp Counter mov ebx, eax ; Save start time ; ---- Target code ---- nop nop nop ; --------------------- rdtsc sub eax, ebx ; Calculate elapsed cycles cmp eax, 100 ; If cycles > threshold jg DebuggerFound

مثال C (Windows API)

#include <windows.h> #include <stdio.h> int main() { DWORD start = GetTickCount(); Sleep(10); // Simulate some work DWORD end = GetTickCount(); if ((end - start) > 20) { printf("Debugger detected!\n"); } else { printf("No debugger detected.\n"); } return 0; }

🛡 Using Timing Checks to Detect a Debugger One of the simplest yet effective techniques to determine if a program is running under a debugger is measuring execution time for specific parts of the code. The idea: when a debugger is attached, due to frequent pauses (breakpoints) and step-by-step execution, the program runs noticeably slower. 1️⃣ Core Idea The program measures a time window, and if the execution takes longer than expected → it likely means a debugger is active. 2️⃣ Implementation Methods Two common approaches exist: OS APIs such as GetTickCount, QueryPerformanceCounter (on Windows) CPU instructions like RDTSC which return the CPU cycle count Assembly Example (x86)

rdtsc ; Read Time-Stamp Counter mov ebx, eax ; Save start time ; ---- Target code ---- nop nop nop ; --------------------- rdtsc sub eax, ebx ; Calculate elapsed cycles cmp eax, 100 ; If cycles > threshold jg DebuggerFound

C Example (Windows API)

#include <windows.h> #include <stdio.h> int main() { DWORD start = GetTickCount(); Sleep(10); // Simulate some work DWORD end = GetTickCount(); if ((end - start) > 20) { printf("Debugger detected!\n"); } else { printf("No debugger detected.\n"); } return 0; }