چرا Ghidra؟
Ghidra یک چارچوب مهندسی معکوس چندسکویی است که disassembler، decompiler، graphing، scripting و تحلیل فرمت‌های مختلف executable را کنار هم می‌آورد. Release رسمی از مخزن NationalSecurityAgency منتشر می‌شود. برای تحلیل فایل‌های مشکوک بهتر است در محیط ایزوله و کنترل‌شده کار کنید.
دریافت امن
برای دانلود از دکمه «دانلود رسمی» همین صفحه استفاده کنید. IROSG فایل installer این نرم‌افزار را mirror نمی‌کند تا کاربر همیشه به نسخه و signature رسمی سازنده دسترسی داشته باشد.
استفاده مسئولانه
در ابزارهای تحلیل، اسکن و Penetration Testing، Scope و مجوز روشن بخشی از کار فنی است. تنظیمات و رفتار ابزار را ابتدا در Lab بررسی کنید و سپس در محیط Production به‌کار ببرید.
تحلیل ایستا چه چیزی به شما می‌دهد؟
Ghidra برای فهم ساختار و رفتار احتمالی برنامه از روی فایل اجرایی به کار می‌رود. می‌توان دستورهای ماشین، تابع‌ها، رشته‌ها، ارجاع‌ها و نمایش شبه‌کد را کنار هم دید. این کار برای بررسی برنامه‌ای که کد منبعش در دسترس نیست، تطبیق یک تغییر باینری یا تحلیل دفاعی فایل مشکوک مفید است. با این حال، خروجی decompiler همان کد منبع اصلی نیست. نام متغیرها، نوع‌ها و ساختارهای سطح بالا ممکن است تخمین باشند و باید با شواهد دستورها سنجیده شوند.
برای یادگیری، یک برنامه کوچک خودتان را با چند تابع و شرط بنویسید و نسخه دارای اطلاعات debug و نسخه بدون آن بسازید. هر دو را وارد Ghidra کنید و تفاوت نام‌ها و نوع‌ها را ببینید. سپس همان برنامه را با سطح بهینه‌سازی متفاوت بسازید. این آزمایش نشان می‌دهد یک منطق ثابت چگونه به شکل‌های باینری متفاوت تبدیل می‌شود. بدون چنین تجربه‌ای، ممکن است خروجی عجیب decompiler را اشتباهاً رفتار عجیب برنامه تصور کنید.
آماده‌سازی پروژه و ثبت منشأ فایل
پیش از import، نوع فایل، اندازه، hash و منبع دریافت را ثبت کنید. این مشخصات امکان می‌دهد تحلیل بعدی دقیقاً به همان نمونه نسبت داده شود. نام فایل به تنهایی شناسه قابل اعتماد نیست؛ دو فایل با نام مشابه می‌توانند محتوای متفاوت داشته باشند. نسخه اصلی را دست‌نخورده نگه دارید و روی کپی کار کنید. اگر فایل از یک دستگاه یا بسته بزرگ‌تر آمده، مسیر استخراج و ابزار استفاده‌شده را نیز ثبت کنید تا فرض‌های اولیه قابل بازبینی باشند.
برای فایل مشکوک، محیط تحلیل جدا و دسترسی محدود مناسب است. تحلیل ایستا نیاز به اجرای خود نمونه ندارد، ولی parserها و افزونه‌ها نیز نرم‌افزارند و باید از نسخه معتبر استفاده شوند. نمونه را روی میزکار روزمره با حساب‌های حساس نگه ندارید. اشتراک پوشه و clipboard میان محیط تحلیل و میزبان را با نیاز واقعی تنظیم کنید. این احتیاط به معنی فرض اجرای خودکار هر فایل نیست؛ هدف محدود کردن اثر اشتباه انسانی و ضعف احتمالی ابزار است.
انتخاب فرمت، پردازنده و آدرس پایه
برای فرمت‌های شناخته‌شده، loader می‌تواند اطلاعات بخش‌ها و معماری را استخراج کند. در firmware خام یا blob بدون header، ممکن است لازم باشد زبان پردازنده، endianness و آدرس پایه را خودتان تعیین کنید. انتخاب اشتباه می‌تواند تعداد زیادی دستور ظاهراً معتبر اما بی‌معنا بسازد. به نشانه‌هایی مانند جدول بردار، الگوی رشته‌ها، محل کد و ارجاع‌های معتبر توجه کنید. وجود چند دستور قابل decode به تنهایی اثبات معماری درست نیست.
آدرس پایه بر تفسیر اشاره‌گرها و پرش‌ها اثر دارد. اگر داده به نشانی‌هایی خارج از فضای واردشده اشاره می‌کند، ممکن است memory map ناقص باشد یا تصویر در آدرس دیگری بارگذاری شود. پیش از اصلاح دستی تعداد زیادی ارجاع، فرض بارگذاری را بررسی کنید. در firmware، بخش‌های حافظه، peripheralها و ناحیه‌های فقط خواندنی ممکن است نیاز به تعریف جدا داشته باشند. مستندات پردازنده و نقشه حافظه دستگاه برای این مرحله ارزش زیادی دارند.
تحلیل خودکار آغاز کار است
Auto analysis می‌تواند تابع‌ها، ارجاع‌ها و ساختارهای اولیه را شناسایی کند، اما نتیجه آن را قطعی ندانید. داده‌ای که به اشتباه کد تشخیص داده شده یا تابعی که مرزش درست پیدا نشده، تحلیل بعدی را منحرف می‌کند. از نقطه ورود و ارجاع‌های معتبر شروع کنید و بخش‌های مشکوک را با دستورها مقایسه کنید. در فایل بهینه‌شده، inline شدن تابع و حذف کد می‌تواند انتظار حاصل از کد منبع فرضی را تغییر دهد.
بهتر است ابتدا نقشه‌ای کلی بسازید: فایل چه نوعی است، چه کتابخانه‌هایی وارد می‌کند، چه رشته‌های معناداری دارد و مسیرهای اصلی اجرا کدام‌اند؟ سپس یک پرسش محدود انتخاب کنید، مثلاً «این فایل تنظیم را از کجا می‌خواند؟» دنبال کردن همه تابع‌ها از ابتدا معمولاً زمان زیادی می‌گیرد. تحلیل هدایت‌شده با پرسش مشخص کمک می‌کند هر یادداشت به یک نتیجه مرتبط باشد و میان انبوه جزئیات گم نشوید.
رشته‌ها و ارجاع‌ها سرنخ‌اند
رشته نام فایل، پیام خطا یا نشانی شبکه می‌تواند نقطه شروع خوبی باشد. از ارجاع به رشته به تابع مصرف‌کننده بروید و بررسی کنید داده در چه شرطی استفاده می‌شود. صرف وجود یک نشانی در فایل ثابت نمی‌کند برنامه حتماً به آن متصل می‌شود؛ ممکن است نمونه، پیام راهنما یا کد غیرفعال باشد. همچنین نبود رشته آشکار به معنی نبود رفتار نیست، زیرا داده می‌تواند ساخته، رمزگذاری یا در زمان اجرا دریافت شود.
ارجاع‌ها را در دو جهت ببینید: چه کسی این تابع را صدا می‌زند و این تابع به کجا می‌رود؟ این روش به تشخیص نقش تابع کمک می‌کند. یک تابع کمکی عمومی ممکن است ده‌ها بار استفاده شود و تمرکز بیش از حد روی آن هدف تحلیل را دور کند. نام‌گذاری توابع را بر اساس شواهد انجام دهید؛ نامی مانند خواندن تنظیم با اطمینان متوسط از نام قطعی و بی‌پایه بهتر است. در توضیح، دلیل و سطح اطمینان را ثبت کنید.
نوع داده بر شبه‌کد اثر می‌گذارد
تعیین درست نوع پارامتر، ساختار و مقدار بازگشتی می‌تواند خروجی decompiler را بسیار خواناتر کند. اگر یک اشاره‌گر به ساختار به عنوان عدد دیده شود، دسترسی به fieldها نامفهوم خواهد بود. با این حال، اعمال نوع اشتباه نیز ظاهر مرتب اما نتیجه غلط می‌سازد. اندازه دسترسی، offsetها و قرارداد فراخوانی را بررسی کنید. به جای حدس زدن کل ساختار در یک مرحله، fieldهای شناخته‌شده را تدریجی تعریف کنید و بخش نامعلوم را مشخص نگه دارید.
مثلاً اگر تابع چند بار از یک پایه مشترک با فاصله‌های ثابت می‌خواند، احتمال ساختار مطرح می‌شود، اما باید اندازه و کاربرد هر field بررسی شود. مقایسه با چند محل استفاده کمک می‌کند فرض تأیید یا رد شود. وقتی نوع تازه باعث تناقض در فراخواننده‌ها می‌شود، به فرض اولیه برگردید. هدف زیبا شدن شبه‌کد نیست؛ هدف مدلی است که با همه شواهد مرتبط سازگار باشد.
کنترل جریان و محدودیت بازسازی
نمودار تابع برای دیدن شاخه‌ها و حلقه‌ها مفید است، به‌ویژه وقتی چند مسیر خطا یا خروج وجود دارد. اما پرش غیرمستقیم، جدول dispatch و بهینه‌سازی می‌توانند بازسازی را دشوار کنند. در این حالت، مقدار ورودی پرش و محل ساخت آن را بررسی کنید. نتیجه «مسیر قابل دسترسی است» باید با شرط‌ها و محدودیت ورودی پشتیبانی شود. صرف وجود یک بلوک در نمودار، اجرای آن در سناریوی مورد نظر را ثابت نمی‌کند.
برای تحلیل دفاعی، فرق توان بالقوه و رفتار مشاهده‌شده را در گزارش حفظ کنید. می‌توانید بگویید کد شامل تابعی برای ایجاد فایل است، ولی برای ادعای اینکه در اجرای خاص فایل ساخته شده، شواهد زمان اجرا لازم است. تحلیل ایستا و پویا مکمل‌اند. اگر اجرای کنترل‌شده لازم شد، آن را در محیط جدا با هدف و محدودیت مشخص انجام دهید و نتایج را به همان hash نمونه وصل کنید.
اسکریپت و تحلیل تکرارپذیر
اسکریپت‌نویسی برای کارهای تکراری مانند استخراج فهرست تابع‌ها، رشته‌ها یا ارجاع‌های مشخص مفید است. پیش از اعمال تغییر گسترده به پروژه، اسکریپت را روی نمونه کوچک اجرا کنید و خروجی را بررسی کنید. API و محیط اسکریپت به نسخه ابزار وابسته‌اند؛ نسخه و وابستگی‌ها را همراه اسکریپت ثبت کنید. یک اسکریپت بدون مستندات که نام هزاران تابع را تغییر می‌دهد می‌تواند شواهد و یادداشت‌های انسانی را مخدوش کند.
برای تحلیل گروهی یا headless، ورودی، گزینه‌های تحلیل و محل خروجی باید ثابت و قابل بازسازی باشند. نتیجه چند فایل را بدون ثبت تفاوت تنظیمات مقایسه نکنید. اگر هدف یافتن تغییر میان دو نسخه است، ابتدا مطمئن شوید تفاوت compiler یا گزینه build عامل اصلی تغییر گسترده نیست. تطبیق تابع‌ها و امضاها ابزار کمک به تحلیل است و هر تطبیق باید در بخش حساس با شواهد بررسی شود.
گزارش نتیجه با درجه اطمینان
یک گزارش خوب پرسش، روش، شواهد و محدودیت را جدا بیان می‌کند. آدرس تابع یا offset، نام پروژه و hash نمونه را بدهید تا همکار بتواند نتیجه را بازبینی کند. اسکرین‌شات شبه‌کد بدون زمینه کافی نیست؛ ممکن است نوع یا نام‌گذاری آن حاصل فرض تحلیلگر باشد. برای ادعای مهم، دستورهای مرتبط یا مسیر ارجاع را نیز توضیح دهید. اطلاعات حساس نمونه را فقط به اندازه نیاز در گزارش وارد کنید.
وقتی تحلیل کامل نیست، بخش‌های ناشناخته را صریح بنویسید: معماری احتمالی، داده رمزگذاری‌شده، کد تولیدشونده یا مسیرهای بررسی‌نشده. این صداقت ارزش گزارش را کم نمی‌کند؛ جلوی تصمیم بیش از شواهد را می‌گیرد. Ghidra ابزار قدرتمندی برای ساخت مدل از باینری است، اما نتیجه نهایی به کیفیت فرض‌ها، اعتبارسنجی و ثبت استدلال وابسته است. یادگیری آن با نمونه‌های کوچک و معلوم، پایه بهتری برای بررسی فایل‌های پیچیده می‌سازد.
نگهداری پروژه تحلیل
پروژه Ghidra علاوه بر فایل ورودی، حاصل نام‌گذاری، نوع‌گذاری و یادداشت‌های شماست. از آن نسخه پشتیبان بگیرید و تغییرهای مهم را با شرح کوتاه ثبت کنید. اگر چند تحلیلگر روی یک نمونه کار می‌کنند، درباره روش نام‌گذاری و درجه اطمینان توافق داشته باشید تا یک حدس شخصی به عنوان واقعیت قطعی به نفر بعد منتقل نشود. قبل از ارتقای ابزار، سازگاری پروژه و افزونه‌ها را بررسی و یک کپی قابل بازگشت نگه دارید. باز شدن موفق پروژه تنها آزمون کافی نیست؛ چند تابع و یادداشت مهم را نیز بررسی کنید. این مراقبت باعث می‌شود ساعت‌های تحلیل به مجموعه‌ای قابل استفاده و قابل انتقال تبدیل شود، نه دانشی که فقط در ذهن تحلیلگر باقی مانده است.
