حافظه در لحظه نمونه‌برداری چه چیزی نشان می‌دهد؟
Volatility 3 چارچوب تحلیل نمونه حافظه فرار است. تحلیلگر تصویر حافظه را در یک ماشین بررسی جداگانه باز می‌کند و از افزونه‌های متناسب با سیستم‌عامل برای استخراج ساختارهای زمان اجرا استفاده می‌کند. سؤال نمونه این راهنما چنین است. در زمان تهیه تصویر ویندوز، کدام فرایندها دیده می‌شدند و رابطه والد و فرزند درباره یک اجرای غیرمنتظره چه می‌گوید؟ این سؤال به شواهد قابل مشاهده محدود است. برای پاسخ درباره رفتار پیشین دستگاه، باید خط زمانی را با داده‌های دیگری مانند گزارش اجرا و رخدادهای میزبان کامل کرد.
فرض کنید کاربری از باز شدن پنجره‌ای ناشناس پس از اجرای یک برنامه داخلی خبر داده است. تیم پاسخ یک نمونه حافظه مجاز از دستگاه آزمایشی با رفتار مشابه در اختیار دارد. پیش از تحلیل، نام ابزار نمونه‌برداری، زمان آغاز و پایان، سیستم‌عامل مورد انتظار، اندازه فایل و هش نسخه دریافتی را ثبت کنید. نمونه‌برداری ممکن است مدتی طول بکشد و خود دستگاه در این فاصله تغییر کند. بنابراین تصویر را نمایی از وضعیت جمع‌آوری‌شده بدانید و از ادعای دقت زمانی بیشتر از شواهد پرهیز کنید.
محیط تحلیل مستقل
پروژه نسخه سوم را بازنویسی چارچوب قبلی معرفی می‌کند. انتخاب افزونه و روش تأمین نمادها در نسخه سوم با عادت‌های رایج نسخه دوم تفاوت دارد. برای اجرای قابل تکرار، نسخه بسته، نسخه Python و سیستم‌عامل میز تحلیل را ثبت کنید. مستندات نصب با pip و استفاده از محیط مجازی برای جداسازی وابستگی‌ها را توضیح می‌دهند. انتشار پایدار و شاخه توسعه نیز مسیرهای متفاوت‌اند. در پرونده عملیاتی بهتر است نسخه‌ای که تیم با نمونه مرجع آزموده به‌صورت مشخص انتخاب شود.
در محیط آزمایش، ابزار را در یک محیط مجازی نصب و فهرست گزینه‌ها را بررسی کنید. فرمان‌های زیر شکل متداول اجرای نمونه ویندوز را نشان می‌دهند. مسیر lab-windows.raw در این مثال باید با مسیر واقعی نسخه کاری حافظه جایگزین شود. پیش از اجرا مطمئن شوید حساب تحلیلگر حق خواندن نمونه را دارد ولی پردازش‌های دیگر به همان پوشه دسترسی نامحدود ندارند. حافظه می‌تواند حاوی متن برنامه‌ها، کلید نشست و داده‌های شخصی باشد و باید همانند یک منبع حساس نگهداری شود.
python3 -m venv lab-vol
. lab-vol/bin/activate
python -m pip install volatility3
vol -h
vol -f lab-windows.raw windows.info
vol -f lab-windows.raw windows.pslist
vol -f lab-windows.raw windows.pstree
در نصب آزمایشی، نسخه نصب‌شده را پس از راه‌اندازی یادداشت کنید و برای بازسازی همان محیط در آینده نسخه را ثابت نگه دارید. راهنمای افزونه را جداگانه با vol و نام افزونه و گزینه راهنما بخوانید. افزونه‌هایی که در یک نسخه دیده می‌شوند ممکن است گزینه یا نام متفاوتی در نسخه دیگر داشته باشند. این روش از وارد کردن مستقیم فرمانی که از یک آموزش قدیمی گرفته شده و برای محیط شما مناسب نیست جلوگیری می‌کند.
از بایت خام تا ساختار قابل تفسیر
مستندات Volatility حافظه را به صورت لایه‌ها مدل می‌کند. در ساده‌ترین تصور، یک لایه داده از نشانی مشخص بایت می‌خواند. لایه دیگر می‌تواند نشانی مجازی مورد استفاده برنامه یا هسته را به محل متناظر در لایه پایین‌تر تبدیل کند. تحلیلگر با دانستن همین تفاوت می‌تواند خطای خواندن یک نشانی را بهتر تفسیر کند. خطا ممکن است حاصل نبود صفحه در نمونه، ناسازگاری لایه یا محدودیت قالب ورودی باشد و لزوماً به معنای خراب بودن کل فایل نیست.
برای تبدیل بایت‌ها به یک شیء معنی‌دار، چارچوب به اطلاعاتی درباره نوع و چیدمان ساختارها نیاز دارد. جدول نماد یا symbol table همین زمینه را تأمین می‌کند. برای مثال، موقعیت یک فیلد در ساختار فرایند می‌تواند میان ساخت‌های سیستم‌عامل فرق کند. اگر تحلیلگر جدول نامناسب را به اجبار بپذیرد، چند مقدار ظاهراً خوانا ممکن است اعتماد کاذب ایجاد کنند. پشتیبانی از یک خانواده سیستم‌عامل به این معنا نیست که هر ساخت و هر قالب نمونه با هر مجموعه نماد کار خواهد کرد.
اطلاعات لایه‌ها، نمادها و اشیای لازم برای تحلیل در Context گرد هم می‌آیند. Automagic برای یافتن بخش‌هایی از تنظیمات و برآورده کردن پیش‌نیازها کمک می‌کند. این خودکارسازی کار دستی را کاهش می‌دهد، اما اگر پیش‌نیازی تأمین نشود، خواندن متن خطا و تشخیص اینکه مشکل از لایه است یا نماد همچنان ضروری است. در گزارش فنی بهتر است مشخص کنید افزونه روی کدام نمونه، با کدام نسخه و با چه مجموعه نمادی به نتیجه رسیده است.
نمادها و اجرای بدون شبکه
README رسمی بسته‌های نماد برای Windows، Linux و macOS معرفی می‌کند. برای Windows، نمادهای یافت‌نشده در شرایط مناسب قابل جست‌وجو، دریافت، تولید و ذخیره در کش هستند. برای Linux و macOS ممکن است تولید جدول متناسب با ساخت سیستم از طریق ابزاری مانند dwarf2json لازم باشد. بسته عمومی Linux نمی‌تواند همه ترکیب‌های هسته کامپایل‌شده را پوشش دهد. در نتیجه، یکسان بودن نام توزیع روی نمونه و روی میز تحلیل برای انتخاب نماد کافی نیست.
در آزمایشگاه جدا از شبکه، ابتدا روی یک نمونه مجاز بررسی کنید کدام نمادها واقعاً لازم‌اند و از کدام منشأ دریافت می‌شوند. فایل‌های نماد و هش‌های منتشرشده را از مسیر کنترل‌شده وارد محیط کنید و محل آن‌ها را ثابت نگه دارید. اجرای اول پس از افزودن نمادهای متعدد ممکن است برای ساخت کش زمان بیشتری بخواهد. این تأخیر را با هنگ کردن ابزار اشتباه نگیرید. زمان اجرای اول و اجرای بعدی را با همان نمونه مقایسه کنید تا حد معمول محیط خودتان را بشناسید.
آغاز بررسی با یک سؤال کوچک
در نمونه ویندوز، پروژه استفاده از windows.info را به عنوان گام نخست پیشنهاد می‌کند. هدف این است که ببینید چارچوب می‌تواند مشخصات مورد نیاز سیستم را از نمونه به دست آورد. نتیجه را با اطلاعات ثبت‌شده در زمان جمع‌آوری مقایسه کنید. اگر انتظار Windows داشته‌اید اما ابزار نمی‌تواند لایه لازم را پیدا کند، بلافاصله سراغ نتیجه‌گیری امنیتی نروید. اندازه فایل، نوع snapshot ماشین مجازی، وابستگی‌های همراه و کامل بودن صادرات را بررسی کنید. اشتباه در ورودی و ناسازگاری نماد دو مسئله جدا هستند.
پس از موفقیت گام اول، فهرست فرایندها را با windows.pslist بگیرید و ساختار والد و فرزند را با windows.pstree بخوانید. یک فرایند با نام آشنا می‌تواند از مسیر غیرمنتظره یا با والد نامعمول اجرا شده باشد. در مقابل، نام ناشناس نیز ممکن است بخشی از نرم‌افزار مجاز سازمان باشد. در این مرحله سؤال مناسب این است که «چه رابطه‌ای ارزش بررسی بیشتر دارد؟» نه اینکه صرف مشاهده یک نام را نشانه قطعی آلودگی بدانیم.
خواندن یک درخت نمونه
برای تمرین کنترل‌شده، در ماشین آزمایش یک برنامه والد شناخته‌شده اجرا کنید که برنامه فرزند کوتاه‌عمر یا بلندعمر ایجاد کند. نام، زمان و شناسه‌هایی که سیستم عامل نشان می‌دهد در یادداشت آزمایش ثبت شوند. سپس نمونه حافظه تهیه کنید و بررسی کنید کدام رابطه در خروجی باقی مانده است. اگر فرزند پیش از جمع‌آوری پایان یافته، نبود آن در فهرست فعال نتیجه غیرمنتظره‌ای نیست. این تمرین تفاوت میان «در زمان مشاهده فعال بود» و «هیچ‌گاه اجرا نشده» را ملموس می‌کند.
شناسه فرایند را به تنهایی شناسه پایدار تاریخی نگیرید. سیستم‌عامل می‌تواند پس از پایان یک فرایند همان عدد را دوباره استفاده کند. درختی که از یک نمونه استخراج شده باید همراه زمان ایجاد، نام تصویر، زمینه اجرای برنامه و سایر آثار مرتبط خوانده شود. اگر والد دیگر در فهرست فعال دیده نمی‌شود، ثبت رابطه ناقص می‌تواند ناشی از زمان نمونه‌برداری باشد. برای پیوند دادن یک شناسه به رخداد قدیمی‌تر، زمان و منبع خارجی مستقل اهمیت دارد.
بررسی فرضیه با شواهد متفاوت
فرض کنید پنجره ناشناس هم‌زمان با یک فرایند فرزند تازه دیده شده است. این هم‌زمانی آغاز بررسی است. ابتدا اطلاعات ثبت‌شده در حافظه را با رویدادهای اجرای برنامه روی میزبان و فایل‌های مرتبط روی دیسک مقایسه کنید. اگر ساعت این منابع متفاوت تنظیم شده، تبدیل زمان را مستند کنید. یک اختلاف چند دقیقه‌ای ممکن است ترتیب وقایع را جابه‌جا کند. شواهد مستقل زمانی ارزش دارد که واقعاً از مسیری جدا آمده باشد، نه اینکه دو گزارش فقط نتیجه همان افزونه را با قالب دیگر نمایش دهند.
می‌توانید خروجی افزونه‌ها را در پرونده حفظ کنید و برای هر نتیجه یک یادداشت تفسیری بنویسید. در یادداشت نام و نسخه افزونه، فرمان، هش نمونه، زمان اجرا و محدودیت شناخته‌شده را قرار دهید. از ثبت مستقیم محتوای حساس حافظه در سامانه تیکت عمومی خودداری کنید. برای بررسی همکار، شناسه یافته و مسیر دسترسی کنترل‌شده به شواهد معمولاً کافی است. اگر نمایش نمونه لازم است، تنها بخش مرتبط را با توضیح منشأ و حدود تفسیر آن تحویل دهید.
وقتی افزونه نتیجه ندارد
خروجی خالی با خطای برآورده نشدن پیش‌نیاز یکسان نیست. ابتدا کد خروج و پیام تشخیصی را بخوانید و مطمئن شوید افزونه واقعاً اجرا شده است. سپس بررسی کنید نام افزونه برای سیستم‌عامل نمونه درست است و فیلتر بیش‌ازحد محدود به آن داده نشده است. اگر افزونه شرایط لازم را داشته ولی ردیفی برنگردانده، در گزارش بنویسید «این افزونه در این نمونه موردی نشان نداد». این جمله دامنه مشاهده را حفظ می‌کند و امکان بررسی با روش دوم را باز می‌گذارد.
اگر چند افزونه پایه همگی از نبود لایه یا نماد شکایت دارند، تعمیر محیط تحلیل مقدم بر آزمودن فهرست بیشتری از افزونه‌هاست. یک نمونه مرجع با ساخت شناخته‌شده را روی همان محیط اجرا کنید. موفقیت نمونه مرجع و شکست نمونه پرونده، مسئله را به ورودی یا نماد خاص نزدیک می‌کند. شکست هر دو نمونه احتمال مشکل نصب، دسترسی یا مسیر نماد را بالا می‌برد. چنین آزمایشی هزینه جست‌وجوی بی‌هدف میان گزینه‌های خط فرمان را کاهش می‌دهد.
تحویل نتیجه به تیم رخداد
گزارش پایانی باید درخواست نخست را پاسخ دهد. فهرست همه فرایندها را به عنوان یافته اصلی تحویل ندهید. رابطه‌ای را که مشاهده شده، شاهدی که آن را پشتیبانی می‌کند و بررسی تکمیلی مورد نیاز را مشخص کنید. اگر داده فقط از یک حافظه گرفته شده، گستره زمانی ادعا را به همان جمع‌آوری محدود کنید. وقتی شواهد خارجی نیز استفاده شده‌اند، برای هر کدام منشأ، زمان و اختلاف احتمالی ساعت را جدا بنویسید تا بازبین بتواند استدلال را دنبال کند.
آخرین آزمون، تکرار مستقل روی نسخه کاری با همان هش است. همکار باید بتواند محیط و نمادها را آماده کند، همان افزونه‌ها را اجرا کند و ردیف‌های مورد استناد را دوباره بیابد. اختلاف نتایج ممکن است از نسخه افزونه، نماد تازه یا تنظیم خروجی ناشی شود. با ثبت این تفاوت‌ها، نتیجه از یک تصویر صفحه به تحلیلی قابل بازبینی تبدیل می‌شود. Volatility 3 در چنین فرایندی امکان خواندن وضعیت زمان اجرا را می‌دهد و ارزش آن با دقت سؤال، کیفیت نمونه و روش تأیید یافته‌ها تعیین می‌شود.
