سلام!
توی قسمت قبلی تونستیم بعد کلی زمان صرف‌کردن حافظه فلش رو dump کنیم و بعد انجام یه سری بررسی‌ها در نهایت RootFS سیستم رو ازش استخراج کنیم. تو این قسمت قراره ابتدا یه مقدار این فایل سیستم رو بررسی کنیم و ببینیم چه اطلاعات به‌دردبخوری رو میتونیم ازش دربیاریم و بعد از اون با کمک ابزار Buildroot یک ایمیج مشابه اون چیزی که روی دستگاه در حال اجرا هست رو ایجاد کنیم تا بتونیم برای قسمت بعدی مقاله که ایجاد یک firmware modification kit هست ازش استفاده کنیم. پس بدون اتلاف وقت میریم سراغ اصل مطلب!
اولین نکته‌ای که در تحلیل فایل سیستم متوجه میشیم این هستش که توسعه‌دهندگان برنامه این دستگاه هم از ابزار Buildroot برای ایجاد ایمیج استفاده کردند و این دقیقاً دلیلی هستش که ما هم برای ایجاد ایمیج کاستوم خودمون از این ابزار استفاده خواهیم کرد؛ بنابراین اگر فایل یا فایل‌هایی مرتبط با مراحل ایجاد ایمیج با بیلدروت روی این فایل سیستم قرار داشته باشه میتونه کمک زیادی به ما کنه پس با دستور زیر سعی می‌کنیم تمامی این فایل‌ها رو پیدا کنیم.
1 2 3 | # at the root of the extracted squashfs filesystem $ find . -print | grep -I buildroot |
و درست پس از اجرای این دستور متوجه میشیم فایل تنظیمات بیلدروت روی این فایل سیستم ذخیره شده و این دقیقاً اون چیزی بود که دنبالش بودیم.
محتوای این فایل اطلاعات بسیار مهمی از روند ایجاد ایمیج در اختیار ما قرار میده:
- استفاده از معماری MIPS و مجموعه دستورات 32 بیتی
- استفاده از زنجیره ابزار تولیدی توسط بیلدروت برای ایجاد فایل‌های اجرایی باینری
- نصب و به‌کارگیری پکیج‌های نرم‌افزاری زیر:
- uClibc version 0.9.31
- kernel version 2.6.36
- gcc version 4.3.5
- libssl version 0.9.8
- استفاده از پسوردهایی با رمزگذاری مبتنی بر SHA512
- استفاده از Busybox به‌عنوان init process و default shell در سیستم
- نصب تعدادی از پکیج‌های کاستوم شرکت Gemtek
- نصب یک پکیج با عنوان fwupgrade (این پکیج میتونه بعداً که ایمیج کاستوم خودمون رو تولید کردیم برای آپدیت فریمور کارخونه با فریمور تولیدی ما مورداستفاده قرار بگیره)
- نصب پکیج‌های libcrypt و openssl
بررسی فرایند Login
قسمت بعدی که بررسی خواهیم کرد فرایند لاگین سیستم هست. این فرایند نسبت به لاگین معمولی سیستم‌ها قدری متفاوت هست به این معنا که پس از دریافت نام کاربری به‌جای درخواست پسورد یک چالش (challenge) برای کاربر ارسال میشه و یک پاسخ از کاربر درخواست میشه. مشکلی که وجود داره اینه که ما نمیدونیم این چالش رو چطور باید حل کنیم و چه پاسخی رو باید ارسال کنیم؛ بنابراین به نظر میاد که این روند لاگین به‌نوعی مخصوص این شرکت شخصی‌سازی‌شده تا افراد متفرقه نتونن وارد سیستم بشن. راهکار چیه؟ اینکه مراحل لاگین رو به‌صورت قدم‌به‌قدم بررسی کنیم و ببینیم کدوم قسمت از یه برنامه کاستوم استفاده میشه. میدونیم در سیستم‌هایی که از Busybox به‌عنوان init process استفاده میشه بعد از بوت شدن سیستم، دستورات موجود در فایل /etc/inittab اجرا میشن پس قدم اول بررسی این فایل هست.
تصویر فوق بخشی از این فایل هست. در دو خط انتهایی مشخصاً برنامه getty برای ایجاد ترمینال روی درگاه سریال اجرا شده که خب از اونجا که این برنامه هم شناخته شده هستش میتونیم با یه بررسی ساده تو اینترنت متوجه بشیم که اجرای این برنامه در مرحله لاگین سبب اجرای یک برنامه دیگه با عنوان login میشه؛ بنابراین تلاش می‌کنیم تا این برنامه رو توی فایل سیستم پیدا کنیم.
خب همونطور که حدس می‌زدیم این برنامه توی فایل سیستم وجود داره و در واقع یک لینک هستش به یک برنامه دیگه با عنوان shell_auth که برنامه شناخته شده‌ای نیست و احتمالاً همون برنامه کاستوم شده فرایند لاگین هستش. باتوجه‌به اینکه این برنامه بعد از بیلد شدن strip شده بنابراین از فایل باینری‌اش اطلاعات خاصی کسب نخواهیم کرد پس بهتره دنبال راهی برای دورزدن این برنامه باشیم!
در ادامه بررسی فایل inittab خط زیر توجهمون رو به خودش جلب میکنه:
1 | ::sysinit:/etc/init.d/rcS |
ظاهراً این خط یک اسکریپت رو پس از بوت سیستم اجرا میکنه پس میریم و این اسکریپت رو بررسی می‌کنیم.
این دایرکتوری شامل یک سری از اسکریپت‌ها هستش که اسکریپت مدنظر ما یعنی rcS هم در بین اونهاست و باتوجه‌به کد این اسکریپت ظاهراً کاری که انجام میده اینه که اسکریپت‌های موجود تو این دایرکتوری رو به ترتیب نامگذاریشون اجرا میکنه و به نحوی با این کار رفتاری مشابه system در اجرای یونیت‌های مختلف رو شبیه‌سازی میکنه.
اسکریپت‌های موجود در این دایرکتوری چون با دسترسی root اجرا میشن از اهمیت ویژه‌ای برخوردار هستند و حتی میتونن برای اهداف نامناسب مورداستفاده قرار بگیرند؛ ولی چیزی که در اینجا برای ما اهمیت داره اسکریپتی هست که برای فرایند لاگین بتونه بهمون کمک کنه. پس شروع می‌کنیم و تک‌تک این اسکریپت‌ها رو مورد بررسی قرار میدیم و در نهایت در اسکریپت S99gemtek.sh اتفاقی که منتظرش بودیم رخ میده. 🙂
این تصویر بخشی از کد این اسکریپت هستش که نشون میده ظاهراً این مودم یک حالت کارخونه رو هم پشتیبانی میکنه که خب میشه حدس زد تو این حالت یک سری اختیارات فراتر از معمول برای کاربر فراهم میشه. از طرفی درصورتی‌که یه سری شرایط (که نمیدونیم چیه و مهم هم نیست!) برقرار باشه یک آی‌پی و اگر اون شرایط برقرار نباشه یه آی‌پی دیگه رو به‌عنوان آی‌پی پیش‌فرض تعریف میکنه. در ادامه این اسکریپت یک بخش دیگه هم مرتبط با این حالت کارخونه داریم:
اینجا یک حلقه if بزرگ هستش که درصورتی‌که متغیر FACTORY مقداری بزرگ‌تر یا مساوی یک داشته باشه بسته به نوع پردازنده یه سری کارا رو انجام میده که چون برامون اهمیتی نداشت ازشون عبور می‌کنیم. توجه کنید که این متغیر هم از جمله متغیرهایی هست که در بوت لودر مقداردهی میشن و در زمان اجرای کرنل بهش داده میشه. در انتهای این حلقه می‌بینیم که یک daemon مربوط به telnet با اجرای برنامه shell قرار داره. خب پس قطعات پازل تکمیل شد! این برد در حالت کارخونه یک آی‌پی محلی (که یکی از اون دوتا آی‌پی تصویر قبل هست) برای خودش تعریف میکنه و یک سرویس telnet رو هم اجرا میکنه که از طریق اون برنامه shell اجرا میشه. باتوجه‌به اینکه در این فرایند خبری از برنامه login هم نیست پس احتمالاً بتونیم بدون نیاز به پسورد به این shell دسترسی پیدا کنیم. برای امتحان‌کردن این فرضیه اول باید متغیر مدنظرمون یعنی FACTORY رو در بوت لودر با یه مقدار بزرگ‌تر یا مساوی یک مقداردهی کنیم و بعدش هم اجازه بدیم تا کرنل بوت بشه و ببینیم آیا وارد FACTORY mode خواهیم شد یا نه!
خب کافیه مشابه روندی که در قسمت اول دیدیم وارد رابط کاربری بوت لودر بشیم و متغیر خودمون رو تعریف کنیم. توجه کنید که اگر این متغیر رو ذخیره نکنید در بوت بعدی ریست میشه و عملاً تغییر مقداری که اعمال کردین از بین خواهد رفت. بعد ذخیره‌کردن به‌صورت نرم‌افزاری یا سخت‌افزاری برد رو ریست می‌کنیم و منتظر میمونیم تا کرنل لود و اجرا بشه. با بررسی لاگ‌های تولیدی متوجه میشیم همونطور که انتظار داشتیم وارد FACTORY mode شدیم.
تو این مرحله باید با اتصال بین pc و برد از طریق یک کابل اترنت و انجام تنظیمات به‌اصطلاح یک شبکه محلی بین مودم و سیستم ایجاد کنیم. برای این کار باتوجه‌به اینکه آی‌پی مودم در رنج آی‌پی‌های کلاس C قرار میگیره میتونیم یک آی‌پی دلخواه که در همون subnet قرار داشته باشه به‌صورت دستی به اینترفیس enp3s0 (یا هر اسمی که تو سیستم شما داره) اختصاص بدیم. در نهایت میتونیم با دستور telnet به برد متصل بشیم و با دسترسی root با shell کار کنیم. به عبارتی تونستیم بدون نیاز به دونستن پسورد و حل چالش فرایند login دسترسی root به شل برد به دست بیاریم!
این قسمت هم به پایان رسید و امیدوارم براتون مفید واقع شده باشه. تو قسمت بعدی میریم سراغ Buildroot و با کمک اطلاعاتی که به دست آوردیم سعی می‌کنیم ایمیج مشابه با ایمیج کارخونه رو تولید کنیم. باهامون همراه باشید که دنیا رو جای بهتری برای زندگی کنیم!
واقعا عالی
عالی بود! منتظز قسمت بعدی هستم.