سلام!
در قسمت قبل سخت‌افزار مودم رو مورد بررسی قرار دادیم و همچنین با مشخص‌کردن درگاه ارتباط سریال و بررسی لاگ‌های دریافتی تونستیم وارد رابط کاربری بوت لودر برد بشیم. تو این قسمت میخوایم با کمک دستوراتی که در رابط کاربری بوت لودر در اختیار ما قرار داره محتویات حافظه فلش این برد رو استخراج کنیم و به‌عنوان فایل فریمور ذخیره کنیم. در نهایت با کمک این فایل به دست اومده بتونیم RooFS این برد رو به دست بیاریم. خب به‌عنوان اولین قدم مجدداً دستوراتی که در رابط کاربری بوت لودر وجود دارند رو با هم بررسی کنیم.
از بین دستورات منوی فوق تنها دو دستور توضیحات جالبی دارند که احتمالاً میتونن برای هدفی که ما داریم؛ یعنی استخراج محتویات حافظه فلش مورداستفاده قرار بگیرند. اولین دستور md هست که طبق منو مقادیر حافظه رو نمایش میده. برای کسب اطلاعات بیشتر راجع به این دستور از help کمک می‌گیریم.
همونطور که در تصویر فوق مشخص هست دستور md صرفاً محتویات فعلی حافظه رو در اختیار ما قرار میده و امکان دریافت محتویات حافظه nand flash از این طریق وجود نداره ولی دستور nand و زیر دستور nand page میتونن به ازای شماره صفحات مختلف حافظه، محتویات اون صفحه رو در اختیار ما قرار بدن بنابراین ظاهراً دستور nand page همون دستوری هستش که دنبالش می‌گردیم!
مسئله‌ای که وجود داره اینه که نمیتونیم محتویات حافظه رو به‌صورت دستی و تک‌به‌تک به این روش استخراج کنیم و بعد هم داخل یه فایل ذخیره شون کنیم. بدیهی هستش که این کار بسیار زمان‌بر خواهد بود؛ بنابراین کاری که انجام میدیم استفاده از یک expect script هست که با زبان perl نوشته شده و به‌جای ما این کار رو انجام خواهد داد. البته باتوجه‌به سرعت نسبتاً پایین ارتباط سریال و حجم بالای حافظه فلش اجرای این اسکریپت چندین ساعت طول خواهد کشید و در نهایت ما یک فایل با سایز حدود 400 MB حاوی تمامی محتویات حافظه فلش خواهیم داشت. این اسکریپت رو میتونید از لینک زیر دریافت کنید. برای اجرای این اسکریپت میتونیم از دستور زیر در محیط لینوکس استفاده کنیم.
1 | ./serial-flash-dump.expect /dev/ttyUSB0 | tee eeprom.txt |
در نهایت یک فایل با نام eeprom.txt خواهیم داشت که شامل تمامی خروجی‌های کنسول در حین اجرای برنامه هستش. از اونجایی که این فایل شامل اطلاعات اضافی هست که جزئی از فریمور برنامه نیستند؛ بنابراین برای خالص‌سازی این فایل از یک اسکریپت دیگه کمک می‌گیریم تا این فایل متنی رو به فایل باینری مدنظر ما تبدیل کنه. این اسکریپت رو هم میتونید از این لینک دریافت کنید و با دستور زیر اجراش کنید.
1 | cat eeprom.txt | ./hexdump2bin.pl > eeprom.bin |
خب تبریک میگم تا این مرحله موفق شدیم حافظه فلش دستگاه رو به‌صورت کامل dump کنیم و فایل باینری مدنظر با حجم 128 MB معادل سایز حافظه فلش رو به دست بیاریم. مرحله بعدی کار ما بررسی این فایل باینری به دست اومده و تفکیک بخش‌های مختلفش هست. با کمک دستور binwalk میتونیم محتویات این فایل باینری رو آنالیز کنیم و بر اساس هدرهایی که در این فایل تشخیص داده میشه، بخش‌های مختلف این فایل رو مشخص کنیم.
از طرفی باتوجه‌به لاگ‌هایی که حین بوت شدن دستگاه دریافت کردیم میدونیم که این حافظه به چه بخش‌هایی تقسیم شده و هر بخش چه میزانی از حافظه رو اشغال کرده است.
نکته حائز اهمیت در این لاگ‌ها این هستش که از هرکدوم از بخش‌ها یک جفت وجود داره که دلیلش مربوط به آپگرید کردن فریمور دستگاه هستش. به عبارت دیگه زمانی که آپگریدی روی دستگاه انجام میشه فریمور جدید روی پارتیشن‌های قبلی بازنویسی نمیشن بلکه روی بخش‌های مجزایی از حافظه نوشته میشن و پس از ریبوت دستگاه این بخش‌های جدید اجرا میشن. هدف از این کار اینه که اگر بنا به هر دلیلی آپگرید دستگاه با مشکل مواجه شد و داده‌های دریافتی قادر به بوت شدن نبودند دستگاه حداقل فریمور قبلی خودش رو داشته باشه و بتونه از روی اون بوت بشه و مشکلی برای عملکردش پیش نیاد.
خب حالا برای جداسازی بخش‌های مختلف یک فایل باینری میتونیم از دستور معروف dd استفاده کنیم.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | dd if=eeprom.bin of=01-bootloader.bin bs=1024 skip=0 count=1024 dd if=eeprom.bin of=02-bootloader2.bin bs=1024 skip=1024 count=1024 dd if=eeprom.bin of=03-config.bin bs=1024 skip=2048 count=1024 dd if=eeprom.bin of=04-env1.bin bs=1024 skip=3072 count=2560 dd if=eeprom.bin of=05-env2.bin bs=1024 skip=5632 count=2560 dd if=eeprom.bin of=06-kernel.bin bs=1024 skip=8192 count=32768 dd if=eeprom.bin of=07-kernel2.bin bs=1024 skip=40960 count=32768 dd if=eeprom.bin of=08-storage1.bin bs=1024 skip=73728 count=28672 dd if=eeprom.bin of=09-storage2.bin bs=1024 skip=102400 count=28160 |
بخش‌های مختلف این فایل شامل موارد زیر هست:
- دو پارتیشن مخصوص بوت لودر U-Boot برای سیستم‌عامل و پردازنده
- یک پارتیشن برای تنظیمات دستگاه
- دو پارتیشن برای متغیرهای بوت لودر
- دو پارتیشن برای نگهداری کرنل شامل هدرهای بوت لودر، کرنل لینوکس و فایل سیستم از نوع squashfs
- دو پارتیشن برای نگهداری و ذخیره‌سازی داده‌ها از نوع UBIFS
از بین تمامی بخش‌های فوق، پارتیشن مربوط به کرنل و محتویاتش برامون اهمیت ویژه‌ای داره چرا که حاوی RootFS دستگاه هست ینی دقیقاً چیزی که ما دنبالش هستیم! بنابراین در ادامه این پارتیشن رو به‌صورت دقیق‌تر مورد بررسی قرار میدیم. اولین بخش این پارتیشن مربوط به هدر 64 بایتی بوت لودر یعنی U-Boot هست. با کمی بررسی متوجه میشیم که فرمت قرارگیری داده‌ها در این هدر به‌صورت زیر هستش:
در این مرحله با کمک اسکریپت kernelpart-split.sh بخش‌های مختلف این پارتیشن را از هم جدا می‌کنیم و قسمت مربوط به RootFS رو هم در یک فایل با نام root ذخیره می‌کنیم. مجدداً تبریک میگم چون ما تونستیم به هدفمان که استخراج RootFS از فایل باینری بود برسیم و الان تمامی فایل‌های اجرایی و سایر قسمت‌های نرم‌افزار این برد رو در اختیار داریم!
امیدوارم مطالب این بخش براتون مفید بوده باشه. تو قسمت بعدی ابتدا یه سری بررسی‌ها روی این RootFS به دست اومده انجام میدیم و تا حد ممکن اطلاعات موردنیازمان رو به دست میاریم. بعدش میریم سراغ Buildroot و سعی می‌کنیم با کمک اطلاعاتی که به دست آوردیم یک ایمیج ایجاد کنیم که بتونه جایگزین ایمیج اصلی دستگاه بشه و از طرفی هم یک زنجیره ابزار برای تولید باینری‌های جدید از روی سورس کد برامون تولید کنه. باهامون همراه باشید که کلی کار جالب در پیش داریم!
سلام ممنونم که مطلب منو رو گذاشتید در جواب دوستم جناب Zeus لینک اصلی این آموزش هک مودم را براتون میزارم که ماله یک مهندس معکوس ایتالیایی است خودتون ببینید و قضاوت کنید
https://github.com/digiampietro/hacking-gemtek
ممنون دوست عزیز
آقا دمت گرم مطلب خیلی خوب و جذابیه
با سلام ای کاش این تحقیق کار خودتون باشه !!!! اما ظاهرا شما از کار کامل یک مهندس ایتالیایی که داخل گیت هاب گذاشتند کپی و فقط ترجمه کردید قابل نقد شنیدن باشید سریع حذف نکنید ممنون میشم اگه غیر از اینه توضیح بدید لااقل منبع اصلی را معرفی کنید
سلام دوست عزیز
ممنون برای نقدتون، ممکنه لینک اون مهندس ایتالیایی رو زحمت بکشید بدید ؟
عالی
دم شما گرم اون مهندس معکوس کار ایتالیایی کارش عالی است کپی کاری کردید !!!!!!!!!!!!!!!!!!!!!!!!!!!
ضمنا این مودم رو بدون اینکه شما UART بزنید و مودم رو باز کنید میشه آنلاک دائم کرد
آنلاک همه ی مودم های TDD اپراتور ایرانسل به صورت ریموت برای اولین بار انجام می شود 💪
TK2510 | TK2510plus | B5142 | GP2101-plus | GP2101| TDi40-A1 | Z6000|Zw101
−−−−−−−−−−−−−−
سلام دوست عزیز
خوشحال میشم اگر این روش رو که میگید آموزشش رو قرار بدید 🙂
خیلی روشهای انلاک مثل هم هستن و این دلیل نمیشه که سریع بگیم کپی کاری انجام شده
البته اون لینکی که می فرمایید رو بفرستید خوشحال میشیم بررسی کنیم
راجع به این مساله توجه به چند نکته اهمیت داره:
اول اینکه در کار اون مهندس ایتالیایی بعد از استخراج roofs اجرای باینری ها روی یک شبیه ساز انجام میشه که ما در قسمت های بعدی اینکار رو روی سخت افزار اصلی انجام میدیم. از طرفی در کار ایشون به روزرسانی کرنل وجود نداره که ما اینکار رو هم خواهیم کرد و از آخرین نسخه کرنل برای اجرای باینری ها روی سخت افزار استفاده خواهیم کرد.
دوم اینکه چون این مطلب برداشتی از کار ایشون هست و ترجمه نیست لینک صفحه ایشون در قسمت آخر مطلب به عنوان مراجع مورد استفاده معرفی خواهد شد که در تمام دنیا این روند مرسوم هست.
سوم اینکه همانطور که زئوس عزیز گفتند و بنده هم در قسمت قبل از شما تقاضا کردم لطفا اگر میفرمایید روشی برای آنلاک نرم افزاری میشناسید با انتشار روش خود به توسعه این دانش کمک نمایید تا صحت گفته شما در جامعه مهندسین الکترونیک تایید شود.
با احترام