ReverseEngineering

پچ چند فانکشن و بایپس چندمرحله‌ ای چالش: نرم‌افزاری که چند تا چک مختلف داره مثلا سریال محدودیت زمانی و یک چک چند لایه‌ ای دیگه هدف حذف یا بی‌ اثر کردن همه چک‌ ها با کمترین تغییر ممکن ابزارها: IDA یا Ghidra برای مشاهده فانکشن‌ها و cross-reference ها x64dbg برای دیباگ و trace چند مرحله‌ای Hex Editor یا پلاگین پچ مثلا IDA patch برای اعمال تغییرات (اختیاری) Python برای اتومات کردن پچ‌ های تکراری روش کار: 1 فهرست کامل چک‌ها تهیه بشه با جستجوی رشته ها cross-reference ها و بررسی فانکشن ها 2 ترتیب اجرای چک‌ ها مشخص بشه با اجرای برنامه و trace در x64dbg 3 برای هر چک کمترین و کم‌ ریسک‌ ترین تغییر طراحی بشه تغییر شرط یا مقدار بازگشتی 4 پچ‌ها مرحله‌ای اعمال شن و بعد از هر پچ برنامه اجرا و تست شه 5 مسیرهای گزارش یا لاگ که اثرات پچ ها رو افشا میکنن بررسی و در صورت نیاز بی‌ اثر بشن تمرین عملی: برنامه‌ای با دو یا سه تا چک مختلف انتخاب کنید تمام فانکشن‌های مربوط به چک در IDA/Ghidra فهرستشون کنید breakpoint x64db روی هر چک قرار بگیره و به ترتیب اجرا بررسی بشه یکی‌یکی پچ‌ ها رو اعمال کنید بعدش از هر پچ تست کلی انجام بدید در اخر نسخه بکاپ جدید با نسخه پچ‌ شده مقایسش کنید نکات عملی و احتیاط: همیشه قبل از هر تغییر نسخه بکاپ جدا داشته باشید حذف یا تغییر یک چک ممکنه رفتار چک‌ های دیگه رو تغییر بده بعد از هر پچ حتما تست کنید تغییرات حداقلی احتمال شکستن منطق برنامه رو کاهش میدن اگر نیاز به پچ‌های شبیه به هم داشتید از اسکریپت برای جلوگیری از خطا استفاده کنید اگر باینری checksum یا signature داخلی داشت مکانیزمش رو اول شناسایی کنید  و بعد درستش کنید یا تغییرها رو طوری اعمال کنید که checksum رو مخفی نکنه Multi-Function Patching & Multi-Stage Bypass Challenge: An application that has multiple different checks a serial check a time limit and another multi-layered check The goal is to remove or neutralize all checks with the minimum possible changes Tools: IDA or Ghidra to view functions and cross-references x64dbg for multi-stage debugging and tracing Hex Editor or patch plugin (IDA patch) to apply changes (optional) Python to automate repetitive patches Method 1 Enumerate all checks build a complete list by searching for strings following cross-references, and inspecting functions 2 Determine execution order run the program and trace it in x64dbg to see the order in which checks execute 3 Design the smallest lowest-risk change for each check change a conditional or a return value 4 Apply patches in stages after each patch, run and test the program 5 Inspect reporting/log paths that might reveal your patches and neutralize them if necessary Practical Exercise Pick a program that implements two or three different checks List all check-related functions in IDA/Ghidra Place breakpoints in x64dbg on each check and examine them in order Apply patches one by one after each patch perform a full test At the end compare the backed-up original with the patched binary Practical Notes & Precautions Always keep a separate backup of the original binary before any change Removing or modifying one check can change the behavior of other checks test after every patch Make minimal changes to reduce the chance of breaking program logic If you need to apply similar patches repeatedly use a script to avoid mistakes If the binary uses an internal checksum or signature identify that mechanism first and then fix it properly or apply your changes so they don’t invalidate the checksum

Akira Ransomware Attack Analysis with SEO Poisoning and Trapping Victims with a Search 🤝

تحلیل حمله باج افزار akira با SEO poisoning و به دام انداختن قربانی با یک سرچ🤝 https://thedfirreport.com/2025/08/05/from-bing-search-to-ransomware-bumblebee-and-adaptixc2-deliver-akira/ @FUZZ0x

Scanning for Post-Quantum Cryptographic Support https://www.anvilsecure.com/blog/scanning-for-post-quantum-cryptographic-support.html @reverseengine

LockBit attack analysis using cobalt strike and socks

تحلیل حمله LockBit با استفاده از cobalt strike و socks https://thedfirreport.com/2025/01/27/cobalt-strike-and-a-pair-of-socks-lead-to-lockbit-ransomware/ @FUZZ0x

LockBit attack analysis using cobalt strike and socks

پچ کردن و بایپس نرم‌افزار یک برنامه ساده با چک سریال یا محدودیت زمانی وجود داره هدف دور زدن چک بدون دسترسی به کد اصلیه ابزارها: IDA یا Ghidra برای بررسی باینری و پیدا کردن فانکشن‌ها x64dbg برای اجرای برنامه و مشاهده مسیر اجرای کد Hex Editor برای اعمال تغییرات مستقیم در باینری روش کار: 1 شناسایی فانکشن چک و بررسی مسیر اجراش 2 اجرای برنامه در x64dbg و دنبال کردن مسیر اجرای چک 3 تغییر یک دستور شرطی یا مقدار ثابت برای bypass کردن چک 4 تست برنامه بعد از تغییر برای اطمینان از عملکرد صحیح تمرین عملی: دانلود یک CrackMe ساده با check serial شناسایی فانکشن چک در IDA یا Ghidra trace کردن مسیر اجرای چک در x64dbg اعمال patch با Hex Editor مثلا تغییر je→ jmp اجرای برنامه و بررسی bypass شدن چک نکات مهم: همیشه قبل از تغییر از برنامه backup داشته باشید کمترین تغییر ممکن اعمال بشه تا برنامه سالم بمونه مسیر اجرای کد به دقت بررسی بشه تا bypass صحیح انجام بشه Software Patching & Bypass A simple program with a serial check or time restriction can be bypassed without access to the original source code Tools: IDA / Ghidra – to analyze the binary and locate functions x64dbg – to run the program and trace execution Hex Editor - to make direct changes in the binary Method : 1 Identify the check function and examine its execution path 2 Run the program in x64dbg and trace the serial/time check logic 3 Modify a conditional instruction or constant to bypass the check 4 Test the modified program to ensure it still works correctly Practical Exercise : 1 Download a simple CrackMe with a serial check 2 Locate the check function in IDA or Ghidra 3 Trace the execution path of the check in x64dbg 4 Apply a patch in a Hex Editor change je jmp 5 Run the program to verify the check is bypassed Key Notes : Always backup the original binary before patching Make minimal changes to preserve program stability Carefully analyze the execution path to ensure the bypass works correctly

💣 "Bypassing EDR Hooks with Reverse Engineering" 📌 چرا این بمبه؟ چون EDRها (مثل CrowdStrike SentinelOne ) برای شناسایی فعالیت مشکوک روی APIهای حساس (مثل CreateRemoteProcess, NtWriteVirtualMemory, NtOpenProcess) Inline Hook میزنن این یعنی وقتی تو بدافزارت از این APIها استفاده کنی اول میری تو کد EDR → بعد تازه سیستم‌کال اصلی 🔎 ساختار : فکر میکنی وقتی OpenProcess صدا میزنی واقعا داری مستقیماً با Windows حرف میزنی؟ نه! اول میری تو تور EDR و اونجاست که همه چی لو میره 2 توضیح ساده: EDR با Inline Hook اولین چند بایت تابع رو با یه jmp به خودش عوض میکنه مثال (شکل ساده): ; اصل تابع NtOpenProcess

mov eax, 23h mov edx, offset args syscall ret

بعد از Hook شدن 👇 jmp EDR_Handler بقیه کد بازنویسی شده 3 ترفند : مهندس معکوس با بررسی DLL (مثلا ntdll.dll) متوجه Hook میشه راه بایپس: مستقیما با syscall کار کنه یا ntdll clean copy لود کنه 4 نمونه کد (C + Inline ASM) :

__asm { mov eax, 0x23 ; NtOpenProcess syscall number mov edx, args syscall }

👉 اینجا دیگه EDR هیچی نمی‌فهمه چون Hook فقط رو API سطح بالا بوده 🚨 Why EDR Hooking is a Problem EDRs (CrowdStrike, SentinelOne, Defender ATP, etc...) need visibility into sensitive APIs : CreateRemoteThread NtWriteVirtualMemory NtOpenProcess NtCreateSection They inline-hook these APIs : The first few bytes of the function (in ntdll.dll) are overwritten with a jmp into the EDR’s handler This means: whenever your malware (or tool) calls OpenProcess, you first land inside EDR code, not Windows So you think you’re talking to Windows → actually you’re talking to CrowdStrike first 🔎 Reverse Engineering View Disassembling hooked functions reveals this: Before hook clean ntdll :

mov eax, 23h ; syscall number NtOpenProcess mov edx, offset args syscall ret

After hook (with EDR) :

jmp EDR_Handler ; patched jump by EDR ; original bytes are gone

⚡ Why bypassing hooks works Inline hooks live in user-mode DLLs (ntdll.dll, kernel32.dll) But the actual system call still exists in the kernel If you: 1 Call the syscall directly syscall instruction 2 Or load a clean, unhooked ntdll.dll (from disk or from a suspended process) → You skip the EDR trampoline and go straight to the kernel 🧑‍💻 Minimal Example (C + Inline ASM)

__asm { mov eax, 0x23 ; NtOpenProcess syscall number mov edx, args ; pointer to arguments struct syscall ; direct transition to kernel }

👉 EDR hook is bypassed, because it only patched ntdll!NtOpenProcess, not the raw syscall 🎯 Why this is a bomb It exposes a fundamental design weakness in user-mode monitoring Reverse engineers can detect hooks by scanning DLLs (memcmp with clean disk copy) Attackers can patch back the original bytes or just issue syscalls directly EDR vendors try to move detection deeper kernel callbacks ETW hypervisor tricks but inline hooks are still everywhere

Win32 Memory Map

https://x.com/chessMan786/status/1965867272607834228

IDA Pro 9.2 Beta3 +Keygen  Win x64  Linux x64  Mac x64, Arm   Download (2.4GB)   Link1   Link2   Link3 magnet:?xt=urn:btih:ce86306a417dd64fab8d26a4983a58412008a9e&dn=IDA9.2

تا حالا باینری باز کردی که هیچی توش نبوده باشه جز یه مشت بایت الکی؟ بعد وقتی اجراش کردی وسط RAM یهو کد اصلی ظاهر شد؟ 😈 این همون Self-Modifying Code هست 2 توضیح ساده: بعضی بدافزارها کل خودشون رو رمزگذاری میکنن وقتی اجرا میشن یه Loader کوچیک بخش اصلی رو تو حافظه Decrypt میکنه نتیجه → فایل روی دیسک چیزی نشون نمیده ولی وسط RAM همه‌ چی اتفاق میوفته 3 نمونه عملی (ساده):

start: lea esi, [encrypted_data] lea edi, [decrypted_data] mov ecx, size decrypt_loop: xor byte [esi], 0xAA movsb loop decrypt_loop jmp decrypted_data

 👉 اینجا Payload اصلی فقط بعد از XOR توی RAM زنده میشه 4 بخش جذاب: مهندس معکوس باید وسط اجرا با Memory Dump یا Breakpoint هوشمند اون لحظه‌ای که کد اصلی ظاهر میشه رو شکار کنه ابزارهایی مثل Scylla یا x64dbg Dump اینجا هستن 👀 به طور خلاصه: برای همینه که بدافزار نویسا عاشقشن ولی مهندسان معکوس ازش متنفرن 🌀 Self-Modifying Code (SMC) Ever opened a binary and found nothing but junk bytes or meaningless data? But once you run it… suddenly the real code magically appears in RAM? 😈 That’s self-modifying code 1️⃣ What’s going on? Malware (or a protector/packer) encrypts its main code On disk → the file looks useless At runtime → a tiny loader decrypts the hidden payload directly into memory Result → nothing suspicious in the file, everything happens inside RAM 2️⃣ Simple example (Assembly)

start: lea esi, [encrypted_data] ; source (encrypted) lea edi, [decrypted_data] ; destination (RAM buffer) mov ecx, size ; number of bytes decrypt_loop: xor byte [esi], 0xAA ; decrypt (XOR key) movsb ; move to buffer loop decrypt_loop jmp decrypted_data ; jump into the decrypted code

👉 Here, the payload only exists after XOR — in memory, never on disk 3️⃣ Why it’s painful for reverse engineers Static analysis tools (IDA, Ghidra) only see junk The real logic only appears after runtime decryption The analyst has to catch the moment the code is unpacked 4️⃣ How REs fight back Use breakpoints at decryption loops Pause execution right after unpacking finishes Dump the real memory image with tools like: 🔹 x64dbg (Dump Memory feature) 🔹 Scylla / ScyllaHide 🔹 OllyDump / Process Hacker 💡 In short: Self-modifying code = nothing on disk, everything in RAM That’s why it’s loved by malware authors and hated by reverse engineers

APK Repacking Tutorial is available now ! Repacking, hooking with frida, using Jadx-gui and apktool, and a general concept for repacking protected apks Watch the playlist 👇 https://youtube.com/playlist?list=PLMhLyvuk51v5Y8_8Ga9PV16Bnv7jYNfcd