Post🧩 WINDOWS INTERNALS FIELD NOTES #01

🧩 WINDOWS INTERNALS FIELD NOTES #01 اException Handling فقط برای Crash کردن برنامه نیست وقتی یک برنامه در Windows با یک Exception مواجه می‌ شود، اولین چیزی که معمولاً به ذهنمان می‌رسد این است: «خب، برنامه خطا داد.» اما از دید یک Reverse Engineer، سؤال مهم‌تر این است: بعد از رخ دادن Exception، چه چیزی تصمیم میگیرد Execution کجا ادامه پیدا کند؟ اینجا Exception Handling وارد ماجرا می‌شود. فرض کن برنامه این دستور را اجرا می‌کند: int *ptr = NULL; *ptr = 1337; طبیعتاً CPU نمی‌تواند این Memory Access را انجام دهد و یک Exception ایجاد می‌شود. اما داستان همان‌جا تمام نمیشود. اWindows Exception را دریافت میکند و وارد یک مسیر مشخص برای پیدا کردن Handler مناسب میشود. به زبان ساده: Instruction ↓ Exception ↓ Windows Exception Dispatcher ↓ Exception Handler ↓ Handle / Continue / Terminate و همین مسیر ساده، یک نکته مهم دارد: اException می‌تواند روی مسیر اجرای برنامه تأثیر بگذارد. First-Chance و Second-Chance Exception در Debugging با این دو مفهوم زیاد برخورد می‌کنید. First-Chance Exception اولین مرحله‌ای است که Exception به Debugger و سپس مکانیزم Exception Handling ارائه میشود. اگر برنامه Handler مناسبی داشته باشد، ممکن است Exception مدیریت شود و Execution ادامه پیدا کند. اگر نه، Exception دوباره در مسیر Handling بررسی می‌شود. در نهایت اگر هیچ Handler مناسبی پیدا نشود: Second-Chance Exception یعنی دیگر جایی برای Handle کردن Exception باقی نمانده و معمولاً Process به پایان میرسد. برای همین وقتی در x64dbg یا WinDbg با Exception مواجه میشوید، نباید فوراً فرض کنید: «برنامه Crash کرد.» باید بپرسید: این Exception چرا ایجاد شد؟ چه کسی آن را Handle می‌کند؟ و Execution بعد از آن کجا ادامه پیدا می‌کند؟ اینجا موضوع برای Security جالب میشود یک Exception Handler می‌تواند صرفاً برای مدیریت خطا استفاده شود. اما اگر کسی عمداً Exception ایجاد کند و از Handler برای تغییر مسیر Execution استفاده کند چه؟ آن‌ وقت Exception Handling دیگر فقط یک مکانیزم Error Handling نیست. می‌تواند تبدیل شود به یک Control-Flow Primitive. در Malware و بعضی تکنیک‌ های Anti-Analysis، این رفتار می‌تواند برای سخت‌تر کردن تحلیل برنامه استفاده شود. اAnalyst ممکن است یک مسیر Execution را دنبال کند، اما بخشی از Control Flow از طریق Exception اتفاق بیفتد. Normal Flow ↓ Instruction ↓ Exception ↓ Handler ↓ Modified Context ↓ Different Execution Flow و این دقیقاً جایی است که باید نگاه Reverse Engineer از «چه خطایی رخ داده؟» به «این Exception چه نقشی در Control Flow دارد؟» تغییر کند. 🎯 چیزی که باید از این قسمت یاد بگیری هر Exception را Crash در نظر نگیر. وقتی در یک Binary رفتار غیرعادی دیدی، این چند سؤال را از خودت بپرس: اException از کجا Trigger شد؟ اException Code چیست؟ چه Handlerای آن را دریافت می‌کند؟ اHandler چه تغییری در Execution ایجاد می‌کند؟ آیا Instruction Pointer بعد از Handler تغییر می‌کند؟ آیا Exception بخشی از Logic برنامه است یا صرفاً Error Handling؟ @TryHackBox #WindowsInternals #ReverseEngineering #MalwareAnalysis #x64dbg #CyberSecurity