https://virgool.ir/feed/@MrHippovfa2026-11-11 09:07:44https://files.virgool.ir/upload/users/4767666/avatar/IJJ0Od.pnghttps://virgool.ir/@MrHippovhttps://virgool.ir/@MrHippov/تحلیل-یک-باینری-محافظت-شده-با-چندین-لایه-packer-ti4khwvd1j26📖مقدمهاگر تازه وارد دنیای مهندسی معکوس شده باشید، احتمالاً اسمCrackMe  رو زیاد شنیدید . CrackMe ها برنامه‌های کوچیکی هستن که مخصوص تمرین Reverse Engineering ساخته می‌شن. معمولاً از کاربر یه پسورد یا سریال می‌خوان و هدف تحلیل‌گر اینه که بدون دسترسی به سورس کد، بفهمه برنامه چطوری اون پسورد رو بررسی می‌کنه یا اصلاً رمز درست چیه.البته همه CrackMeها شبیه هم نیستن. بعضی‌ها خیلی ساده‌ان و فقط برای یاد گرفتن مفاهیم اولیه طراحی شدن، اما بعضی دیگه عمداً از تکنیک‌هایی مثل Packer، Obfuscation، Virtual Machine Protection و Anti-Analysis استفاده می‌کنن تا تحلیل کردنشون سخت‌تر بشه. البته این تکنیک‌ها قرار نیست مهندسی معکوس رو غیرممکن کنن؛ فقط سعی می‌کنن زمان و زحمت بیشتری از تحلیل‌گر بگیرن.CrackMeای که بررسی می‌کنیم دقیقاً از همین دسته است. وقتی برای اولین بار فایل رو ببینید، احتمالاً فکر می‌کنید با یه باینری طرفید که تحلیل کردنش حسابی دردسر داره. چندین لایه محافظتی روی فایل قرار گرفته، اما همون‌طور که جلوتر می‌بینیم، اگر مرحله‌به‌مرحله مسیر اجرای برنامه رو دنبال کنیم، می‌شه به منطق اصلیش رسید.توی این Write-up هدفمون فقط پیدا کردن پسورد نیست. بیشتر می‌خوایم ببینیم یه Reverse Engineer موقع برخورد با همچین باینری‌ای چطور فکر می‌کنه و قدم‌به‌قدم جلو می‌ره؛ از بررسی ساختار PE و Importها گرفته تا تحلیل Entry Point، دنبال کردن Control Flow و در نهایت رسیدن به تابع اعتبارسنجی رمز عبور.در این مقاله قصد داریم روند تحلیل این CrackMe را از مرحله شناسایی فایل تا استخراج منطق اعتبارسنجی رمز عبور بررسی کنیم.این فایل با چندین Packer تجاری محافظت شده است که فرایند Static Analysis را به‌طور قابل توجهی دشوارتر می‌کنه.📂تحلیل PEPE-Bearاول از همه فایل رو با PE-Bear  بررسی می‌کنیم. همون نگاه اول یه چیز جلب توجه می‌کنه؛ وجود سکشن‌های اختصاصی مثل .enigma0، .enigma1، .themida، .vmp0 و .vmp1. این اسم‌ها معمولاً بی‌دلیل داخل یه فایل دیده نمی‌شن و نشون میدن که باینری با چندین لایه محافظتی و Obfuscation محافظت شده.در واقع همین سکشن‌ها اولین سرنخ رو به ما می‌دن که قرار نیست با یه CrackMe معمولی طرف باشیم و احتمالاً برای رسیدن به منطق اصلی برنامه باید از چندین لایه محافظتی عبور کنیم.DIE (Detect It Easy)اطلاعات بیشتری در اختیار ما قرار میده و نتیجه PE Analysis  رو تایید میکنه.📦تحلیل Import هابعد از بررسی ساختار فایل، یه نگاهی هم به Import Table  میندازیم . Import ها معمولاً می‌تونن سرنخ خوبی از کارهایی که برنامه انجام می‌ده بهمون بدن.اینجا می‌بینیم که برنامه بیشتر از توابع استاندارد CRT برای گرفتن ورودی، مقایسه رشته‌ها و نمایش خروجی استفاده می‌کنه. نکته جالب اینه که هیچ API غیرمعمول یا مرتبط با رمزنگاری بین Importها دیده نمی‌شه. یعنی حداقل در نگاه اول، خبری از توابع آماده برای Encrypt یا Decrypt کردن داده‌ها نیست.این موضوع یه سرنخ مهم به ما میده. احتمالاً منطق بررسی پسورد داخل خود برنامه پیاده‌سازی شده و قرار نیست با یه تابع آماده یا کتابخونه رمزنگاری طرف باشیم. پس برای فهمیدن نحوه اعتبارسنجی رمز عبور، باید مسیر اجرای برنامه رو دنبال کنیم و به تابع اصلی اعتبارسنجی برسیم.__________________________________________________________________________________________________I/O Functions:▸ fgets  —  Reading input▸ puts  —  Displaying output▸ __stdio_common_vfprintf  —  Formatted output▸ __acrt_iob_func  —  File stream access▸ fflush  —  Flushing output bufferString Functions:▸ strcmp  —  String comparison▸ strlen  —  String length▸ strncpy_s  —  Safe string copyConsole Functions:▸ _getch  —  Reading single character without echo🔎تحلیل رشته هابعد از اینکه یه دید کلی از ساختار فایل پیدا کردیم، نوبت می‌رسه به بررسی رشته‌های (Strings)داخل برنامه. معمولاً این مرحله یکی از سریع‌ترین راه‌هاست که می‌تونه سرنخ‌های خوبی بهمون بده. خیلی وقت‌ها اسم تابع‌ها، پیام‌های خطا، پیام موفقیت، آدرس‌ها یا حتی بخشی از پسورد به صورت Plaintext داخل فایل وجود داره و فقط با یه نگاه به رشته‌ها میشه اطلاعات جالبی به دست آورد.برای این کار هم از  Strings خود IDA استفاده کردیم و هم از  FLOSS. دلیل استفاده از FLOSS اینه که فقط رشته‌های معمولی رو بررسی نمی‌کنه؛ اگر برنامه رشته‌ها رو موقع اجرا Decode کنه یا از Stack String استفاده کرده باشه، FLOSS شانس خوبی برای پیدا کردنشون داره.اما اینجا نتیجه یه مقدار ناامیدکننده بود! نه داخل IDA رشته مهمی پیدا شد و نه  FLOSS تونست Stack String یا رشته Decode شده‌ای استخراج کنه. یعنی خبری از پسورد، پیام مخفی یا هر چیز جالبی که بشه مستقیم ازش استفاده کرد نبود.این معمولاً یه نشونه خوبه که برنامه داره یه چیزی رو از ما مخفی می‌کنه. احتمال داره رشته‌ها موقع اجرا ساخته بشن، رمزگذاری شده باشن یا اصلاً منطق اصلی برنامه داخل لایه‌های محافظتی و VM پنهان شده باشه. در هر صورت، از این مرحله چیزی دستمون رو نگرفت.پس اینجا دیگه وقتشه از تحلیل رشته‌ها فاصله بگیریم و مسیر اجرای برنامه رو دنبال کنیم. چون اگر اطلاعات مهمی وجود داشته باشه، احتمالاً فقط موقع اجرا خودشون رو نشون میدن، نه داخل فایل.🚀تحلیل Entry Pointبعد از اینکه ساختار فایل، Import ها و Stringها رو بررسی کردیم، نوبت می‌رسه به Entry Point  برنامه.Entry Point  اولین جاییه که بعد از اجرای فایل، سیستم‌عامل کنترل برنامه رو به اون میده. اما توی برنامه‌های محافظت‌شده معمولاً این آدرس، نقطه شروع واقعی برنامه نیست. بیشتر وقت‌ها فقط کارهایی مثل آماده کردن محیط اجرا، مقداردهی اولیه، اجرای تکنیک‌های Anti-Analysis و در صورت استفاده از Packerها، عملیات Unpacking رو انجام می‌ده.توی این نمونه، Entry Point روی آدرس 0x140001C10  قرار داره. با بررسی کد این قسمت مشخص می‌شه که هنوز خبری از منطق اصلی برنامه یا تابع بررسی رمز عبور نیست. بیشتر دستوراتی که اینجا می‌بینیم مربوط به مراحل اولیه اجرای برنامه هستن و صرفاً مقدمات اجرای بخش اصلی رو فراهم می‌کنن.پس به جای اینکه وقت زیادی روی این قسمت بذاریم، جریان اجرای برنامه     (ControlFLow)رو دنبال می‌کنیم. با بررسی Callها و Cross-Referenceها مشخص می‌شه که Entry Point فقط کنترل رو به چند تابع دیگه منتقل می‌کنه که مسئول Initialization و آماده‌سازی برنامه هستن.بنابراین مسیر اجرا رو ادامه میدیم تا در نهایت به تابع main  برسیم؛ جایی که منطق اصلی برنامه قرار داره و فرآیند اعتبارسنجی رمز عبور از اونجا شروع می‌شه.🟢تابع ()main1 وجود یک حلقه با میلیون‌ها تکرار، زمان تحلیل و دیباگ را به‌صورت مصنوعی افزایش می‌دهد و یکی از تکنیک‌های متداول Anti-Analysis محسوب می‌شود.protected function  2 ها در سکشن های مختلف کال شدن.password_validation  3 در ->0x1400013f0 .__________________________________________________________________________________________________پس از دنبال کردن مسیر اعتبارسنجی رمز عبور، مشاهده می‌شود که برنامه یک آرایه از بایت‌ها را در حافظه مقداردهی می‌کند.یک بافر 15 بایتی داریم:که با یک اسکریپت پایتون میتونم رشته مورد نظر و پیدا کنیم.که در نهایت ”Password = “rootaccess1337در داخل برنامه از  custom-VM هم استفاده شده است که به نظر می‌رسد هدف اصلی این VM محافظت از منطق اعتبارسنجی و افزایش هزینه تحلیل بوده است.__________________________________________________________________________________________________🧩 تکنیک‌های ضدتحلیل (Anti-Analysis) به‌کاررفتهاستفاده از چندین پکر تجاری: استفاده هم‌زمان از Enigma، Themida، VMProtect و WinLicense برای محافظت از فایل و دشوار کردن مهندسی معکوس.بخش‌های بزرگ داده‌های بی‌مصرف (Junk): افزودن بیش از ۸ مگابایت داده‌های اضافی و بی‌استفاده برای افزایش حجم فایل و سخت‌تر کردن تحلیل.حلقه‌های اتلاف زمان: اجرای یک حلقه با ۳٫۵ میلیون تکرار برای کند کردن فرایند تحلیل و دیباگ.ماشین مجازی سفارشی (Custom VM): استفاده از یک مفسر Bytecode اختصاصی برای اجرای منطق اعتبارسنجی و پنهان کردن کد واقعی.محافظت با Stack Cookie: استفاده از Stack Canary برای تشخیص و جلوگیری از حملات سرریز پشته (Stack Buffer Overflow).فراخوانی‌های غیرمستقیم: استفاده از اشاره‌گرهای تابع (Function Pointers) و جدول‌های Dispatch برای پنهان کردن مسیر واقعی اجرای برنامه و دشوار کردن تحلیل جریان کنترل (Control Flow).🏁در آخر💡درس‌های کلیدیدر این برنامه از چندین لایه Pack و Obfuscation استفاده شده بود، اما این تکنیک‌ها تنها هزینه و زمان مهندسی معکوس را افزایش می‌دهند و جایگزین طراحی صحیح نرم‌افزار نیستند.حتی در حضور چندین لایه محافظتی، منطق اصلی برنامه همچنان قابل بازیابی است؛ مشروط بر اینکه تحلیل‌گر بتواند جریان اجرای برنامه را به‌درستی دنبال کند.هدف اصلی بسیاری از تکنیک‌های محافظتی، غیرممکن کردن مهندسی معکوس نیست؛ بلکه افزایش زمان، هزینه و پیچیدگی تحلیل است. Mr. HippovMr. HippovFri, 07 Aug 2026 19:30:36 +0330