حول اللوردات الموقعة للهواتف MTK او Qualcomm او UNISOC

[DZ-Developer]

السلام عليكم..
معلومة ممكن يكون كتير منكم عارفها، وهي مهمة لأي فني سوفتوير سواء كان متخصص أو مبتدئ.
وهي إن ملفات الـ DA أو اللودرات من أول ما بدأ موضوع الـ secure boot بيتم توقيعها وتخصيصها للمعالج. بمعنى، لو معاك جهاز VIVO بمعالج مثلاً MSM8937، فكل الأجهزة اللي بنفس المعالج من نفس الشركة، اللي هي VIVO، هتشتغل عادي على نفس اللودر.
مثال تاني، لو عندك جهاز ريلمي بمعالج MT6789، لو لقيت أي جهاز منهم مدعوم على أي أداة، هتدخل على موقع Kimovil وتطلع القائمة اللي
بتحمل نفس المعالج وتنفذ معاها عادي على حسب المعالج من الأداة اللي موجود فيها الموديل المُحدد..
في حالة تانية وهي إنه ممكن يكون فيه أكثر من إصدار للمعالج نفسه، وأداة كيميرا هي اللي تقدر تظهر لك الموضوع ده لمعالجات ميديا-تك. يعني هتدخل على gsmarena وتلاقي الجهاز مكتوب MT6762 أو MT6765G أو MT6762H، وهتلاقي الأدوات تعرفت على المعالج إنه MT6765، لكن أداة كيميرا بتحلل الـ SW version وHW version وعندهم قاعدة بيانات ممتازة بتطلع المعالج بالظبط مثلاً MT6771C/MT6771C/V وهكذا.
فالنقطة دي هتساعدك إنك تطلع كل الأجهزة اللي بنفس المعالج صح .. لما تبحث على Kimovil، لأنه بيتطلب المعالج الصح بنفس الـ revision. فالمعلومة دي ممكن تختصر عليك كتير لو لقيت جهاز معين في قائمة أداة وفي وأجهزة تانية بنفس المعالجات غير موجودة، تقدر تجرب على باقي الأجهزة المتاحة اللي بتحمل نفس الـ SoC.
الموضوع يشمل كل المعالجات سواء MT-K، QLM، أو UNISOC.
الاستثناء الوحيد هو شركة سامسونج وAlcatel (TCL).… لانه بيتم توقيع ملفاتهم حسب الجهاز أو إصدار الحماية أو الـ bit revision. يعني مثلاً لودر A042F BIT 3 مش هيبوت معاك جهاز A042F BIT 4، مثال آخر لودر T505N BIT 4 مش هيبوت معاك جهاز T505N BIT 5، لكن يقدر يبوت معاك كل الحمايات الأقل، لأن مع كل حماية بيتم إضافة مفتاح توقيع جديد للتحقق مع الاحتفاظ بالمفاتيح القديمة..
طبعاً، دا بشكل عام لو ميديا-تك وبنستخدم PL AUTH مثلاً، لكن مش مُطبق في حالة وجود exploit مُعين زي ثغرة البوتروم مثلاً، لأنه في الحالة دي كله بيتبع نهج الشركة المصنعة للمعالج وليس الـ OEM نفسها. علشان كده هنعمل اعتبار إن الموضوع بخصوص سامسونج ثابت على القاعدة اللي فوق بالنسبة لأجهزة كوالكوم اللي مفيش لها أي ثغرة خاصة بالمعالج وأي أداة بتدعهم بتكون حصلت على لودرات من كومبونيشن JDM أو DEBUG EMERGENCY مخصصة للجهاز والإصدار.. وقاموا بإضافتها بخلاف Exynos و MT-K اللي ليهم ثغرات خاصة بالمعالج بتخلي الشغل مُختلف شوية..
الموضوع ليه اشتراطات أُخرىٰ وتعقيدات كتير… لكن أتمنى أكون شرحته بشكل واضح ومُبسط.

تم بواسطة المبدع محمد مفضل سالم

 

[DZ-Developer]

بنشوف كتير من لودرات الكوالكوم بتكون داخل الفلاشة بالشكل التالي :
- prog_emmc_firehose_8976_lite
- prog_emmc_firehose_8976_ddr
- prog_ufs_firehose_8996_lite
- prog_ufs_firehose_sdm845_ddr
- prog_firehose_ddr_fwupdate
ممكن يجي على بالك تساؤل إيه الفرق بينهم: باختصار شديد..
ddr vs lite : ddr has ddr init (faster memory), lite: only sram
بمعنى إن الـ DDR بيؤدي وظائف أكتر من الـ Lite، وفيه أوامر غير مُفعلة في التاني، وبيكون أشمل واستخداماته أوسع. لكن نتفكر إنَّ الملفات دي أصلاً مُوجهة لمراكز الخدمة الرئيسية للشركات وللـ after sales، يعني مش مُوجهة للـ end user ولا لينا كـ third party technicians.
نأتي إلى الصيغة:
- MBN & ELF
- ELF (Executable and Linkable Format)
- MBN (Modem Binary or Multi Boot Image)
ملفات MBN 32 بت، الصيغة القديمة، لو فتحتها بـ HXD هتلاقيها بادئة بالشكل ده:
#define MBN_HEAD_CODEWORD 0x844bdcd1 /* little-endian */
أما ملفات MBN as ELF و ELF binaries بتبدأ بالشكل ده:
0x464C457F - header for ".ELF"
وأخيرًا، ملفات Firehose FW Update، طبعًا أغلبنا عارف خيار Update FFU اللي موجود داخل سورس eMMCDL، وإنه مش متاح في كل اللودرات. لو حاولت تنفذه أو توظفه عن طريق اللودر العادي، الموضوع بيفشل.
الملفات دي بتجي ومُفعّل فيها بس أوامر IC Firmware Update وPatch. تم استغلالها مؤخرًا للتعامل مع أجهزة أوبو وريلمي كوالكوم الحديثة، والكتابة والفورمات عن طريق أمر الـPatch بدل من الأوامر الجاهزة اللي بتكون مفعلة في اللودرات الطبيعية. ولأن القراءة مش مسموحة باللودر، المطورين فكروا واستخرجوا الأدرسات الخاصة من الـRaw Program. زي قطاع misc و frp، أي جهاز عارفين إنه أكيد متاح له فلاشه وداخلها التقسيمة والعناوين لكل قطاع، وبتكون غالباً ثابته لنفس الـ vendor والمعالج للقطاعات الأولية اللي قبل ملف SUPER/SYSTEM, فتم استخدامها للفورمات وFRP. العملية بتكون بطيئة لأن الـPatch بيكون عن طريق SRAM وليس DRAM - DDR.
- ممكن تكون معلومة غير مُهمة بالمرّة، لكن من باب العلم بالشيء، يعني يُفضل تكون عارف استخدامات الملفات اللي بتشوفها قدامك بشكل مُتكرر.

طبعًا بنتكلم عن الرام، أول ما تشوف كلمة DDR المفروض على طول تجي على بالك الرام، سواء كانت داخلية أو خارجية dram/sram، منفصلة أو مُدمجة، لأنها الأساس في التعامل في أوضاع البوت، سواء SPD أو Unidoc أو MT-K.
وهي اللي بيتم نقل بيانات اللودر عن خلالها والكتابة والقراءة بيها.

ملخص:

ما الفرق بين DDR وLite في Qualcomm Firehose؟
الاختلافات بين DDR وLite في Qualcomm Firehose
في سياق برمجة Qualcomm Firehose، تشير DDR وLite إلى نوعين مختلفين من ملفات Firehose المستخدمة في عمليات الفلاش والاستعادة على أجهزة Qualcomm.
DDR (Double Data Rate):
الوظائف: ملفات DDR عادةً ما تكون أكثر شمولاً، ومصممة للتعامل مع مجموعة واسعة من العمليات، بما في ذلك المهام المعقدة مثل فلاش البرامج الثابتة بالكامل، وإدارة الأقسام، وعمليات الذاكرة الواسعة.
حالات الاستخدام: تُستخدم هذه الملفات في السيناريوهات التي تتطلب استعادة النظام بالكامل أو الفلاش، مثل إصلاح جهاز تالف أو استعادته إلى إعدادات المصنع.
Lite:
الوظائف: ملفات Lite هي نسخ مبسطة تركز على مهام محددة، وغالبًا ما تكون ذات وظائف محدودة مقارنةً بنظيراتها DDR. عادةً ما تكون أصغر حجمًا وقد لا تدعم جميع الميزات المتاحة في ملفات DDR.
حالات الاستخدام: تُعتبر الملفات Lite مناسبة للعمليات البسيطة، مثل فلاش أقسام معينة أو إجراء تحديثات سريعة دون الحاجة إلى استعادة النظام بالكامل.
في ملخص: يكمن الفرق الرئيسي في نطاق الوظائف والتعقيد: ملفات DDR أكثر قوة وتنوعًا، بينما ملفات Lite مبسطة لمهام محددة. هذا التمييز مهم للمطورين والفنيين عند اختيار ملف Firehose المناسب لاحتياجاتهم.