پس Dynamic Analysis نمیتونه درباره مسیری که اجرا نشده با همان قطعیت مسیر اجراشده اطلاعات بده

به همین دلیل معمولا این دو روش کنار هم ارزش بیشتری دارن

Static Analysis
+
Dynamic Analysis

Static

کمک میکنه بفهمیم چه مسیر ها و وابستگی‌ هایی ممکنه وجود داشته باشن

Dynamic
کمک میکنه بفهمیم در یک

اجرای مشخص واقعا چه اتفاقی افتاده

ابزارها

برای Dynamic Binary Analysis و Taint Tracking ابزارها و Framework های مختلفی وجود دارن

Intel Pin
DynamoRIO
Triton
angr
PANDA

ولی نباید فکر کنیم همه این ابزارها دقیقا یک کار رو انجام میدن مدل Instrumentation و قابلیت‌ های هرکدوم متفاوته

مثلا:
Triton

برای Dynamic Binary Analysis امکاناتی مثل Taint Analysis و Symbolic Execution داره

ارتباط با Fuzzing

اینجا داستان جالب‌ تر میشه

ما قبلا داشتیم

Fuzzer
↓
Interesting Input
↓
Crash

حالا میتونیم از Dynamic Taint Analysis برای بررسی مسیر داده استفاده کنیم

مثلا:

Interesting Input
↓
Tainted Data
↓
Parser
↓
Variable
↓
Memory Operation
↓
Crash

پس فقط نمیگیم برنامه Crash کرد
بلکه میتونیم بررسی کنیم داده‌ای که از Input وارد شده در طول اجرای برنامه چه مسیر هایی رو طی کرده و کجا در ایجاد مشکل نقش داشته

Static + Dynamic

یک Workflow منطقی برای تحلیل میتونه این شکلی باشه

Fuzzing
↓
Crash
↓
Crash Triage
↓
Static Analysis
↓
Find Source / Sink
↓
Dynamic Analysis
↓
Trace Data
↓
Root Cause

اینجا کم‌ کم از یک Crash ساده میرسیم به درک بهتر مسیر ایجاد Bug



Dynamic Taint Analysis
یعنی داده یا وابستگی داده‌ ای مشخص رو هنگام اجرای واقعی برنامه دنبال کنیم

مفاهیم اصلی:

Source
↓
Taint
↓
Propagation
↓
Register / Memory
↓
Control Flow
↓
Sink

و نکته مهم اینه که Static Analysis و Dynamic Analysis رقیب هم نیستن

Static
بیشتر جواب این سوال رو میده

چه مسیر هایی ممکنه وجود داشته باشه؟



Dynamic
بیشتر جواب این سوال رو میده

در این اجرای مشخص واقعا چه مسیری طی شد؟

وقتی این دو رو کنار Fuzzing و Crash Analysis بذاریم

میتونیم از

Crash

بریم به

Input
↓
Data Flow
↓
Instruction
↓
Memory Operation
↓
Crash
↓
Root Cause


و این دقیقا همون جاییه که تحلیل یک Crash از یک اتفاق ساده تبدیل میشه به فهمیدن علت واقعی Bug

@reverseengine