این 33 درصد آخری توی نظر سنجی که مطالب پایه و پیشرفته ترکیبی میخواستن !👋
همه چی خوبه؟

‏📌 معرفی ابزار در حوزهٔ تحلیل بدافزار


‏🧩 در این پست، مجموعه‌ای از ابزارهای اوپن‌سورس و آفلاین را می‌بینی که برای آنالیز استاتیک و دینامیک بدافزار استفاده می‌شوند.

‏1️⃣ floss (FLARE)
‏ابزاری برای Deobfuscation و استخراج رشته‌های پنهان و زمان‌اجرا (runtime strings) از باینری‌ها.
🔗 https://github.com/mandiant/flare-floss

‏2️⃣ LIEF
‏کتابخانه و ابزار تحلیلی برای parse و بررسی ساختار PE/ELF/Mach-O، شامل metadata، sections و virtual addresses.
🔗 https://github.com/lief-project/LIEF

‏3️⃣ pefile (Python)
‏ماژول پایتون برای خواندن دقیق هدرهای PE، imports، resources و entropy — کمک به شناسایی packerها و ساختار فایل.
🔗 https://github.com/erocarrera/pefile

‏4️⃣ radare2
‏فریم‌ورک قدرتمند باینری آنالیز و دیس‌اسمبل (Disassembly) با محیط تعاملی برای کاوش آفست‌ها و بررسی بایت‌کد.
🔗 https://github.com/radareorg/radare2

‏5️⃣ rizin + Cutter
‏جایگزین مدرن radare2 — شامل موتور تحلیل Rizin و رابط گرافیکی Cutter GUI برای آنالیز استاتیک و دیباگ تعاملی.
🔗 https://github.com/rizinorg/rizin

🔗 https://github.com/rizinorg/cutter

‏6️⃣ ssdeep
‏ابزار تولید fuzzy-hash برای سنجش شباهت بین فایل‌ها و شناسایی خانواده‌های مشابه بدافزار.
🔗 https://github.com/ssdeep-project/ssdeep

‏7️⃣ Cuckoo Sandbox
‏پلتفرم اجرای ایزوله برای آنالیز دینامیک (Dynamic Analysis) و ثبت رفتار runtime شامل فایل، رجیستری و ارتباطات شبکه.
🔗 https://github.com/cuckoosandbox/cuckoo

‏8️⃣ Binwalk
‏ابزار قدرتمند برای کشف و استخراج فایل‌های جاسازی‌شده (Embedded Files) در firmware یا داده‌های فشرده.
🔗 https://github.com/ReFirmLabs/binwalk

‏9️⃣ strings / xxd / hexdump
‏ابزارهای پایه‌ای خط فرمان برای استخراج رشته‌ها، مشاهده هگزدامپ و یافتن IOCs متنی در فایل‌های باینری.
🔗 strings (binutils): https://sourceware.org/binutils/docs/binutils/strings.html

@ExploitChi

‏#محقق_امنیت #تحلیل_بدافزار #امنیت_سایبری #reverseengineering #threathunting #forensics #infosec #malwareanalysis #blueTeam #redTeam

دوستان فردا در ادامه رشته پست های تحلیل رفتار آنتی ویروس به real-time protection و روش های دور زدن آن خواهیم پرداخت

🔔ابزار — Dittobytes

🌐 [https://github.com/tijme/dittobytes]

🚀 معرفی Dittobytes — کامپایلر متامورفیک برای تولید Shellcode / BOF (Cross-Platform)

ابزار Dittobytes یک metamorphic cross-compiler مبتنی بر LLVM است که سورس‌های C/C++ را به‌صورت Position-Independent Code (PIC) برای چند پلتفرم (Windows / Linux / macOS) و معماری‌ها (x64, ARM64) می‌سازد. هر بیلد خروجیِ باینری متفاوت و هم‌معنایی تولید می‌کند — مناسب برای تولید shellcode، BOF و payloadهای مستقل از CRT.

📚 ویژگی‌های کلیدی:
• متامورفیک‌سازی دستورالعمل‌ها — هر بار با جایگزینی تصادفی (instruction substitution) ساختار باینری تغییر می‌کند.
•جابجایی یا Shuffle دستورالعمل‌ها — در نواحی‌ای که dependency وجود ندارد، ترتیب دستورالعمل‌ها جابه‌جا می‌شود.
•درج Inline کردن مقادیر ثابت — مقدارها به‌جای قرارگیری در .rodata در خود کد جای می‌گیرند.
• خروجی PIC (Position Independent Code) — بدون نیاز به لینک با libc/CRT کلاسیک؛ مناسب برای لود در حافظه.
• چندین فرمت خروجی — .raw (تنها بخش .text / shellcode)، .obj (قابل استفاده به‌عنوان BOF)، .exe (PIC-based executable).
• کراس پلتفرم و چندمعماری — قادر به ساخت برای Windows/Linux/macOS و x64/ARM64.
• خروجی مناسب برای BOF/Beacon — .objهای تولیدی کم‌وابستگی و قابل استفاده در چارچوب‌هایی مثل Cobalt Strike / Mythic / Sliver.

🔍 اثرات امنیتی / تشخیصی :

هش‌ فایل‌ها ثابت نمی‌مانند — هر build fingerprint متفاوتی دارد.

بخش‌های قابل پیش‌بینی حذف می‌شوند — Import table، string section و .rodata کم‌تر یا حذف می‌شوند.

امضای شناخته‌شدهٔ ابزارهای رایج ندارند — خروجی‌ها از الگوهای مشخص Donut / sRDI / Cobalt Strike فاصله می‌گیرند.

مناسب برای اجرا در حافظه — با VirtualAlloc یا mmap قابل لود و اجرا (به‌دلیل PIC بودن).

🎯 کاربردهای معمول در حوزهٔ تحقیق و توسعه (MalDev / Red Team ):

تولید shellcode متامورفیک برای loaderهای اختصاصی.

ساخت BOFهای کم‌حجم .

حذف fingerprintهای toolchain مرسوم .

تست و ارزیابی مکانیسم‌های تشخیصی.



🔗 لینک پروژه:
https://github.com/tijme/dittobytes

@ExploitChi
#Dittobytes #Metamorphic #Shellcode #BOF #MalDev #RedTeam #Compiler #LLVM #PIC #CrossPlatform

👁 مقالات زیر همگی به روش های بای پس و نوع کارکرد amsi اشاره دارند:

https://www.r-tec.net/r-tec-blog-bypass-amsi-in-2025.html

https://s3cur3th1ssh1t.github.io/Powershell-and-the-.NET-AMSI-Interface/

https://s3cur3th1ssh1t.github.io/Bypass_AMSI_by_manual_modification/

به پست های اول کانال که درباره نحوه بای پس این مکانیزم هست هم سربزنید.
@ExploitChi
#AMSI_bypass #amsi_bypass #amsi #redteam

“That bypass was literally one byte away from failing 😅💻
Just for fun — 1K subs special!”

@ExploitChi

#Bitdefender_Bypass #Av_Evasion #redteam #purpleteam #evasion #cybersecurity

🧾 ابزار Strings — ابزارِ ساده اما ضروری برای استخراج رشته‌ها از باینری‌ها
هدف: بررسی سریع implant یا باینری برای پیدا کردن «سوتی» یا نشانه‌هایی مثل URL، مسیرها، نام DLL و...


🔍 این ابزار چی کار می‌کند؟

ابزار Strings توالی‌های کاراکتری (ASCII یا Unicode/wide) را از فایل‌های باینری بیرون می‌کشد — URLها، پیام‌های خطا، مسیرها، نام DLL، و گاهی IPها یا دستورات مورد استفاده داخل بدافزار. برای تحلیل‌گر یا توسعه‌دهنده بدافزار، گرفتن سرنخ از رشته‌ها یکی از اولین قدم‌هاست.


⚙️ نمونه اجرای دستورات

strings -n 5 suspect.exe | less
# windows Sysinternals Strings:
strings.exe -n 5 suspect.exe > suspect_strings.txt

سوئیچ n 5 یعنی فقط رشته‌های با طول >= 5 نمایش داده شوند تا نویز کمتر شود.


🧠 چه اطلاعاتی مفید هستند؟

• آدرس‌های URL / دامنه / IP که احتمالاً برای C2 یا دانلود استفاده شده‌اند.
• نام توابع/کتابخانه‌ها (مثلاً GDI32.DLL, CreateFile).
• پیام‌های خطا یا متن‌های عملکردی — اغلب بهترین سرنخ‌ها را می‌دهند.
• مسیرها، نام فایل‌ها، registry keyها یا mutex nameها که می‌توانند به IOC تبدیل شوند.

- در فرآیند توسعه: حذف، جایگزینی یا obfuscation این رشته‌ها را انجام دهید.


⚠️ هشدارها — چه چیزی را نباید اشتباه گرفت؟

• خروجی strings بدون Context است — یک توالی شبیه متن ممکن است در واقع داده یا دستورالعمل باشد.
• رشته‌های کوتاه یا عجیب‌وغریب معمولاً نویز هستند — فیلتر کنید.
• فایل‌های packed / obfuscated معمولاً رشته‌ی کمی دارند — این خود می‌تواند علامت مشکوک باشد.
• هرگز ابزارها یا فایل‌های مشکوک را روی ماشین تولیدی اجرا نکنید — همیشه در VM ایزوله و بدون دسترسی اینترنت یا در شبکهٔ کنترل‌شده کار کنید، زیرا فایل‌ها ممکن است خطرناک باشند.


✅ نکتهٔ پایانی برای توسعه‌دهنده‌ها

قبل از انتشار implant یا build نهایی، خروجی strings را چک کنید تا رشته‌های حساس یا مواردی که امکان لو رفتن سرویس/آدرس را دارند حذف یا مخفی (obfuscate) شده باشند.

❤️ری اکشن هاتون انرژی میده❤️

🔗 لینک ابزار
@ExploitChi

#ابزار #تحلیل_بدافزار #Strings #Sysinternals #IOC #ReverseEngineering #MalwareAnalysis #malware_development

Static analysis

🔒 چک‌لیست عملی — تحلیل ایستاِ پایه (Static Analysis)
(مختصر، کاربردی، برای استفاده در تست‌های بدافزار و آنالیز باینری)

🧠 هدف:
پیدا کردن رفتار و ماهیت فایل مشکوک بدون اجرای آن — برای تحلیل‌گران بدافزار، SOC، ردتیم و بلو‌تیم ضروری است.

۱. محیط ایزوله بسازید
قبل از هرچیز، فایل را در محیط امن آزمایش کنید.
🔹 چرا؟ چون فایل ممکن است خطرناک باشد یا به اینترنت وصل شود.
🔧 ابزارها: VirtualBox / VMware Workstation

۲. محاسبه هش (Fingerprint)
برای هر فایل مشکوک هش تولید کنید (SHA256، SHA1، MD5).
🔹 چرا؟ برای جستجو در پایگاه‌ها و شناسایی فایل‌های مشابه.
🔧 ابزارها: sha256sum / CertUtil

۳. جستجوی هش در دیتابیس‌ها
هش را در سرویس‌های تحلیلی بررسی کنید.
🔹 چرا؟ شاید همین نمونه قبلاً تحلیل شده باشد.
🔧 ابزارها: VirusTotal / Hybrid Analysis / MetaDefender

۴. اسکن با چند آنتی‌ویروس
چند موتور AV مختلف را روی فایل اجرا کنید تا نتایج اولیه را بگیرید.
🔧 ابزارها: VirusTotal / OPSWAT MetaDefender

۵. استخراج رشته‌ها (Strings)
با دستور strings -n 5 رشته‌های قابل‌خواندن را استخراج کنید (URL، IP، مسیر، DLL...).
🔹 چرا؟ چون معمولاً اولین سرنخ‌ها از اینجا پیدا می‌شود.
🔧 ابزارها: Sysinternals Strings

۶. بررسی Imports / Exports
توابع و DLLهای استفاده‌شده را بررسی کنید.
🔹 چرا؟ از روی APIها می‌توان هدف و رفتار بدافزار را فهمید.
🔧 ابزارها: Dependency Walker / CFF Explorer / pefile (Python)

۷. تشخیص Packer / Obfuscator
آیا فایل فشرده یا رمزگذاری شده است؟
🔹 چرا؟ بدافزارها معمولاً برای پنهان‌سازی از Packerها استفاده می‌کنند.
🔧 ابزارها: Detect It Easy (DiE) / PEiD / UPX

۸. بررسی بخش‌های PE و Entropy
بخش‌های .text, .rdata, .rsrc را ببین؛ اگر entropy بالا بود، احتمالاً رمز یا pack شده است.
🔧 ابزارها: PEview / PE-bear

۹. ثبت و آرشیو نتایج
تمام خروجی‌ها، هش‌ها، اسکرین‌شات‌ها و گزارش‌ها را نگه دار تا در مستندسازی استفاده شود.
🔧 ابزارها: Wireshark / Flameshot / ShareX/ Notion


📚 چرا این چک‌لیست مهم است؟
✔️ تحلیل ایستا کمک می‌کند قبل از اجرای فایل، رفتار آن را پیش‌بینی کنید.
✔️ در شکار تهدید (Threat Hunting) سرنخ‌های دقیق از APIها و رشته‌ها به‌دست می‌آورید.
✔️ در گزارش‌نویسی فنی و آموزشی پایه‌ای‌ترین مهارت تحلیل بدافزار است.

@ExploitChi

#MalwareAnalysis #StaticAnalysis #CyberSecurity #ReverseEngineering #YARA #VirusTotal #PEAnalysis #RedTeam #BlueTeam #ThreatIntel

📌 راهنمای استفاده از API های ثبت وقایع در ویندوز در بدافزارهای keylogger,Victim monitoring , ....


⚙️Start with SetWindowsHookEx and continue with its suitable alternatives


📝 توضیحات:
رابط ویندوزی SetWindowsHookEx یک API از Win32 است که اجازه می‌دهد Hook‌هایی روی زنجیره‌ی پردازش پیام‌های ویندوز نصب کنیم — هم در سطح Thread و هم (در شرایط خاص) به‌صورت Global. این API در هر دو حوزه‌ی تحلیل بدافزار / تکنیک‌های Red Team کاربرد دارد. در این پست نکات کلیدی، تکنیک‌ها و هشدارهای عملی را مرور می‌کنیم.

🔍 نکات کلیدی
• کاربردها: گرفتن keystrokeها (WH_KEYBOARD_LL)، مانیتور ماوس (WH_MOUSE_LL)، مشاهده‌ی ایجاد/فعال‌شدن پنجره‌ها (WH_CBT)، فیلتر پیام‌ها (WH_GETMESSAGE).

• سطح دسترسی: نصب hook روی یک Thread نیاز به Admin ندارد؛ برای Global hook معمولاً نیاز به سطح بالاتر و حضور در همان session/desktop است.

• محدودیت ویندوز جدید: در Windows 10+، Global hooks بین sessionهای مختلف کار نمی‌کنند — باید در همان session باشید.

🧩 تکنیک‌های مرتبط (Red Team / Malware)
• تکنیک 1 Keylogging — استفاده از WH_KEYBOARD_LL برای ثبت کلیدها.
• تکنیک 2 DLL Injection via Global Hook — با نصب global hook، DLL در پروسه‌های دارای GUI لود می‌شود.
• تکنیک 3 Persistence — ذخیره‌سازی مکانیزم hook در رجیستری برای بارگذاری پس از reboot.
•تکنیک 4 UI Monitoring / Overlay Injection — پایش تغییرات UI یا تزریق overlay برای فیشینگ/credential capture.

🧭 زنجیره‌های مشکوک (Suspicious Chains)
الگوی کلاسیک DLL injection
• LoadLibrary → SetWindowsHookEx
رفتار keylogger
• SetWindowsHookEx(WH_KEYBOARD_LL) → GetAsyncKeyState
چرخه‌ی حیات hook (قابل رصد و لاگینگ)
• SetWindowsHookEx → UnhookWindowsHookEx

🛡 شناسایی توسط AV/EDR
• رفتار نصب hook (به‌خصوص WH_KEYBOARD_LL/WH_MOUSE_LL) معمولاً پرچم‌گذاری می‌شود.
• بارگذاری DLL غیرسیستمی در زمینه‌ی hook → نشانگر قوی DLL Injection
•معمولاً EDRها تابع user32!SetWindowsHookExW را مانیتور یا حتی inline-hook می‌کنند تا فعالیت ثبت شود.

• رفتار مشکوک: فرایند بدون UI که hook نصب کند یا بارگذاری DLL در فرآیندهایی که نباید.

🔧 معادل‌ها / جایگزین‌ها
• نسخهٔ undocumented: NtUserSetWindowsHookEx (سطح پایین‌تر).
• هوگ های جایگزین: WH_JOURNALRECORD / WH_JOURNALPLAYBACK، WH_CBT (مصارف خاص).
• روش‌های جایگزین اجرا/تزریق: APC Injection، QueueUserAPC، reflective/in-memory mapping (همه این موارد نیازمند بررسی دقیق هستند).

✅ پیشنهاد برای تیم‌های دفاع (Detection / Hardening)
• لاگ‌ کردن همه‌ی فراخوانی‌های SetWindowsHookEx و correlate با LoadLibrary/ProcessCreate.
• پیگیری ماژول‌های DLL لودشده و اعتبارسنجی دیجیتال آن‌ها.
• هشدار برای نصب hook توسط پروسه‌های بدون UI یا پروسه‌هایی که نباید input-capture کنند.
• آموزش تیم SOC برای شناسایی الگوهای زنجیره‌ای (IOC) ذکرشده.

@ExploitChi

#RedTeam #WindowsAPI #SetWindowsHookEx #Keylogging #EDR #MalwareAnalysis #Persistence #Security #ExploitChi #malwaredevelopement

PE Structure

🚀 ZigStrike

ابزار ZigStrike یک لودرِ شِل‌‌کُد قوی است که با زبان برنامه‌نویسی Zig نوشته شده. این برنامه چند روش مختلف برای «تزریق» (injection) کد در فرایندهای دیگر دارد و قابلیت‌هایی برای تشخیص و دورزدن محیط‌های سندباکس (محیط‌های آزمایشی/تحلیل) ارائه می‌دهد. از امکانات زمانِ کامپایل زبان Zig استفاده می‌کند تا حافظه و داده‌های شِل‌کُد را به‌شکل کارا تخصیص دهد. این پروژه نشان داده در دور زدن برخی راهکارهای امنیتی پیشرفته موفق بوده است. همچنین یک سازندهٔ payload سفارشی دارد که از طریق یک وب‌اپلیکیشن نوشته‌شده با Python، به کاربر اجازه می‌دهد payloadها را انتخاب و تولید کنند.


🛠 روش‌های تزریق (Injection):
• Local Thread :
اجرای شِل‌کُد در یک thread محلی.
• Local Mapping :
نگاشت شِل‌کُد داخل حافظهٔ یک پروسس محلی.
• Remote Mapping :
نگاشت شِل‌کُد داخل حافظهٔ پروسس هدف.
• Remote Thread hijacking :
استفاده/ربایش یک thread موجود در پروسس هدف برای اجرا.

🛡 محافظت ضد سندباکس:
• TPM Presence Check :
بررسی وجود TPM برای تشخیص محیط واقعی/آزمایشی.
• Domain Join Check :
بررسی عضویت دستگاه در دامنهٔ سازمانی.

📦 فرمت‌های خروجی:
• XLL (Excel Add-in)
• DLL

⚙️ قابلیت‌های پیشرفته:
• انکدینگ Base64 برای نمایش/انتقال شِل‌کُد
• پردازش رشته در زمانِ کامپایل (Compile-time)
• مدیریت محافظت حافظه (تغییر دسترسی صفحات حافظه)
• هدف‌گیری پروسس‌های خاص

هشدار: از تمامی ابزارهای آماده با دقت و در محیط آزمایشی استفاده شود و در صورتی اوپن سورس هست حد الامکان کد اون رو بررسی کنید. از backdoor ها غافل نشین.

Blog: https://kpmg.com/nl/en/home/insights/2024/12/zig-strike-the-ultimate-toolkit-for-payload-creation-and-evasion.html
@ExploitChi

#loader #injection #shellcode #payload #redteam #purpleteam

ZigStrike
@ExploitChi

🧠چرا همه فایل‌های exe با MZ شروع می‌شن

وقتی یه فایل PE رو تو Hex Editor باز می‌کنی، اولین چیزی که می‌بینی چیه؟
✅ عبارت آشنا:

MZ

و یه پیام جالب:

This program cannot be run in DOS mode.

📜 این در واقع بخش تاریخی و سازگار با سیستم عامل MS-DOS هست که بهش می‌گن:

🔸 DOS Stub

👴 در دهه ۸۰، فایل‌های اجرایی با فرمت MZ ساخته می‌شدن (اسمش از مهندس مایکروسافت Mark Zbikowski گرفته شده).
با ورود ویندوز، فرمت جدید PE اومد، اما برای حفظ سازگاری، مایکروسافت هنوز هم فایل‌های PE رو با MZ شروع می‌کنه!

این قسمت فقط یه کار می‌کنه:
اگه فایل PE رو توی سیستم DOS اجرا کنی، به‌جای کرش، این پیام رو نشون می‌ده:

"This program cannot be run in DOS mode."

💀 جالبه بدونی:

بعضی بدافزارها تو همین بخش shellcode یا payload قایم می‌کنن!

تحلیلگرهای باینری همیشه باید این بخش رو چک کنند.

پس دفعه بعد که فایل .exe رو باز کردی، حواست باشه اون رشته ASCII بی‌خطر... ممکنه فقط ظاهر قضیه باشه 😈
@ExploitChi

#PE #Malware #ReverseEngineering #RedTeam #WindowsInternals #HexEditor

🧩 ساختار ابتدایی فایل PE (Portable Executable) در نگاه Hex!

وقتی یه فایل اجرایی ویندوز (.exe / .dll) رو با Hex Editor باز می‌کنی، اولین چیزی که می‌بینی همین ساختار هست 👇

🔹‏ MZ → امضای DOS Header (IMAGE_DOS_HEADER)
🔹‏ e_magic → نشون میده فایل واقعاً PE هست (0x5A4D)
🔹 ‏ e_lfanew → آفستی که امضای PE از اونجا شروع میشه
🔹‏ PE\0\0 → Signature مخصوص فایل‌های ویندوز
🔹 بعدش IMAGE_FILE_HEADER → مشخص می‌کنه فایل 32 یا 64 بیتی هست و چند تا سکشن داره

📚 در این مثال:

Machine = 0x014C → یعنی x86 (32bit)

NumberOfSections = 0x0005 → فایل ۵ سکشن داره

اگر خوشتون اومد ری اکشن بدین تا ادامه فایل هم بررسی بشه 😎

#ReverseEngineering #MalwareAnalysis #PEFile #BinaryInternals
@ExploitChi 🔥

دید درست از تارگت ▪️ صبر ( کمین )▪️ ضربه‌ی ناگهانی
آسیب‌پذیری‌ها را نه با پیچیدگی، که با چشمان یک شکارچی کشف کن.

@ExploitChi

#hack #pentest #bug #Vulnerability #hunt #evasion

#MindSet #MalwareAnalysis #ReverseEngineering #RedTeam

@ExploitChi

🧩 انواع لینک کردن در exe فایل ها — چرا برای آنالیز بدافزار مهمه؟
‏Types of Linking

‏Static linking‏ — لینک ایستا

توضیح: کد کتابخانه‌ها هنگام کامپایل درون فایل اجرایی کپی می‌شود.

مشخصات فنی در تحلیل : نشانهٔ مشخصی در هدر PE ندارد؛ بخش‌های .text/.rdata بزرگ‌تر می‌شوند و اندازه فایل افزایش می‌یابد.

‏Normal Usage : برای ساخت single-executable یا اجرا در محیط‌هایی که کتابخانه نصب نیست.

در بدافزار: پنهان کردن و بهم ریختن Imports از دید solution های امنیتی مثل آنتی ویروس و همچنین می‌تواند آنالیز ایستا را سنگین و پراکنده کند.

شاخص‌ها: سایز غیرعادی، حضور استرینگ/کد کتابخانه‌ها در .text، انتروپی بالا.

‏ Runtime linking — بارگذاری در زمان اجرا (Explicit/Manual Load / Manual Mapping)

توضیح: بارگذاری یا resolve توابع فقط در زمان اجرا و در صورت نیاز انجام می‌شود. مثل lazy ها در Go

تکنیک‌ها: LoadLibrary + GetProcAddress، Manual Mapping (لود PE در حافظه بدون loader ویندوز)، API-hashing، فراخوانی syscalls مستقیم.

مشخصات فنی: Import Table ممکن است خالی یا ناکامل باشد — از هدر به‌راحتی قابل‌فهم نیست چه توابعی استفاده شده‌اند.

چرا استفاده می‌شود؟ اوبفوسکیشن، جلوگیری از تشخیص ایستا، اجرای fileless، و فرار از AV/Signature.

در بدافزار: بسیار رایج — ابزار اصلی برای دور زدن آنالیز و آنتی‌ویروس.

شاخص‌ها: رشته‌های هش‌شده، فراخوانی‌های مشکوک به LoadLibrary/GetProcAddress، فراخوانی‌های VirtualAlloc/Write/Protect، رفتارهای runtime قابل مشاهده با Procmon/API Monitor.

‏ Dynamic linking — لینک دینامیک «معمولی» (Import Table / IAT)

توضیح: هنگام بارگذاری برنامه، سیستم کتابخانه‌ها را resolve می‌کند و اطلاعات در Import Table ذخیره می‌شود.

مشخصات فنی: نام DLLها و توابع در هدر PE (IAT) مشخص است و آنالیز ایستا می‌تواند لیست توابع را بخواند.

‏Normal Usage : ساده، استاندارد و شفاف — بهترین حالت برای تحلیل ایستا و نوشتن rule/تخصیص امتیاز تشخیصی.

در بدافزار: بعضی خانواده‌ها از همین روش استفاده می‌کنند (یا فقط بخشی از آنها)، مخصوصاً وقتی پیچیدگی نمی‌خواهند.

شاخص‌ها: IAT واضح، نام توابع قابل‌خواندن، call graph قابل بازسازی.

🔍 کدام روش برای فرار از تشخیص استفاده می‌شود؟

Runtime linking (Manual Mapping, API hashing, delayed resolve).

داینامیک لینکینگ استاندارد استفاده نمیشود — چون همه‌چیز در IAT مشخص است.
‏Static linking می‌تواند آنالیز ایستا را گیج کند (سایز و کد بالا) اما به اندازهٔ روش‌های runtime مؤثر نیست.

@ExploitChi

#MalwareAnalysis #ReverseEngineering #RedTeam #Sysinternals #Security #CyberSecurity
#تحلیل_بدافزار #ردتیم #بلو_تیم #آنالیزبدافزار #امنیت_سایبری #تیم_قرمز

🔥 FLARE VM
محیط آماده برای آنالیز بدافزار در ویندوز

اگه می‌خوای سریع وارد فاز تحلیل بشی و وقت نصب ابزارها رو نداری، FLARE VM از تیم Mandiant یه گزینه فوق‌العاده‌ست! 🚀
فقط با یه اسکریپت، صدها ابزار تحلیل ایستا، پویا، مهندسی معکوس و حافظه روی ویندوزت نصب می‌شه.
مخصوص تحلیلگرهایی که دنبال سرعت و نظم در کار هستن.

⚙️ مناسب برای:
🔹 تحلیل بدافزار (Malware Analysis)
🔹 مهندسی معکوس (Reverse Engineering)
🔹 پاسخ به رخداد (Incident Response)
🔹 شکار تهدید (Threat Hunting)

📦 لینک گیت‌هاب پروژه:
👉 https://github.com/mandiant/flare-vm

⚠️ نکته مهم:
برای بررسی بدافزارهایی که خودت نوشتی، بهتره از ابزارهای آماده مثل FLARE VM استفاده نکنی،
مگر این‌که کد و نحوه عملکردش رو کامل بررسی کرده باشی. چون ممکنه رفتار تحلیل یا ابزارت signature بشه و لو بره و امنیتت تحت تاثیر قرار بگیره.

@ExploitChi

#امنیت_سایبری #آنالیز_بدافزار #مهندسی_معکوس #FLAREVM #Mandiant #MalwareAnalysis #ReverseEngineering #WindowsVM #MalwareLab

ساختار محیط آزمایشگاهی برای آنالیز و تحلیل بدافزار از دید منابع معتبر در این حوزه

علمی که از استاد دانا و کتاب راستین نیاموزی، همچون مالی است که از دزد گرفته باشی، نه نفع دارد و نه بقا

خلاصه که دنبال سرچشمه باشید و مرجع معتبر - سواد اصلی و ریشه ای تو کتابه نه دوره ممد آنالیز یا اسی هکر😂
اینام خوبه و کار رو راحت میکنه اما اصل کاری رو از دست ندین

@ExploitChi

#MalwareAnalysis #ReverseEngineering #RedTeam #Sysinternals #ExploitChi