حماية التراجع عن Android Oreo مطلوبة على الهواتف التي يتم تشغيلها باستخدام Android Pie

أندرويد باي (أندرويد 9) لقد بدأ البث المباشر اليوم لـ Google Pixel وGoogle Pixel 2 و حتى ال الهاتف الأساسي. نحن نتعلم قدر الإمكان عن الإصدار من المقابلات (Google Pixel 3 سيكون لديه التنقل بالإيماءات فقط!)، ال إسقاط رمز AOSPوأخيرًا مستند تعريف التوافق (CDD). نشرنا عن أ ميزة جديدة للتطبيقات "الثقيلة". في وقت سابق من اليوم، ولكننا اكتشفنا الآن أن Google قد غيرت صياغتها بشأن الميزة المقدمة في Android Oreo: حماية التراجع. أصبحت هذه الميزة ممكنة من خلال Android تم التحقق من التمهيد 2.0 (المعروف أيضًا باسم التمهيد المعتمد)، ومع ذلك، لم يُطلب من مصنعي المعدات الأصلية تطبيق AVB 2.0 في إصدار Oreo. الآن، تفرض Google أن تدعم جميع الأجهزة التي يتم تشغيلها باستخدام Android Pie عملية التحقق من التمهيد، وبالتالي الحماية من التراجع.

الحماية من التراجع في Android Oreo

جوهر الميزة هو أنها ستمنع هاتفك من التشغيل إذا اكتشف أن الجهاز قد تم تخفيضه إلى إصدار سابق إلى إصدار سابق غير معتمد من البرنامج الذي تم اعتباره غير آمن بسبب الأمان وهن. التفسير الأكثر تقنية قليلاً هو أن بنية بيانات VBMeta، التي تحتوي على التجزئة لقسم التمهيد و تستخدم البيانات التعريفية لشجرة التجزئة لأقسام النظام والبائعين فهرس التراجع لرفض الصور التي لها تراجع أقدم فِهرِس.

هذه الميزة موجودة على أجهزة مثل Google Pixel 2 وRazer Phone وOnePlus 6 ولكنها غير موجودة في العديد من الأجهزة الأخرى مثل Samsung Galaxy S9 (على الرغم من أن Samsung تقدم نموذجًا خاصًا بها من حماية التراجع في نوكس.) الآن، تجعل Google هذه الميزة إلزامية لأي جهاز يتم تشغيله باستخدام Android Pie.

تم التحقق من التمهيد في Android Pie

وفقًا للصياغة المحدثة في قسم "تكامل الجهاز" في مستند تعريف التوافق، يجب أن تدعم الأجهزة التي تعمل بنظام Android 9 التمهيد الذي تم التحقق منه.

9.10. سلامة الجهاز

تضمن المتطلبات التالية وجود شفافية فيما يتعلق بحالة سلامة الجهاز. تطبيقات الجهاز:

• [C-0-1] يجب أن يُبلغ بشكل صحيح من خلال طريقة System API PersistentDataBlockManager.getFlashLockState() عما إذا كانت حالة أداة تحميل التشغيل الخاصة بها تسمح بوميض صورة النظام. يتم حجز حالة FLASH_LOCK_UNKNOWN لتطبيقات الأجهزة التي يتم ترقيتها من إصدار سابق من Android حيث لم تكن طريقة واجهة برمجة تطبيقات النظام الجديدة هذه موجودة.
• [C-0-2] يجب أن يدعم التمهيد الذي تم التحقق منه لسلامة الجهاز.

إذا تم تشغيل تطبيقات الجهاز بالفعل دون دعم التمهيد المعتمد على إصدار سابق من Android ولا يمكنهم إضافة دعم لهذه الميزة من خلال تحديث برنامج النظام، فقد يتم إعفاؤهم من متطلبات.

...

• [C-1-10] يجب تنفيذ الحماية من التراجع للأقسام التي يستخدمها Android (مثل التمهيد وأقسام النظام) واستخدم التخزين الواضح لتخزين البيانات التعريفية المستخدمة لتحديد الحد الأدنى المسموح به لنظام التشغيل إصدار.
• يجب تنفيذ الحماية من التراجع لأي مكون به برامج ثابتة ثابتة (مثل المودم والكاميرا) و يجب استخدام التخزين الواضح لتخزين البيانات التعريفية المستخدمة لتحديد الحد الأدنى المسموح به إصدار.

كما ترون في المجموعتين الأخيرتين من النقاط، هناك تحذير واحد يجب ملاحظته. الحماية من التراجع مطلوبة للأقسام التي يستخدمها Android (التمهيد، النظام، البائع، وما إلى ذلك) ولكن ليس للأقسام ذات البرامج الثابتة المستمرة (المودم، الكاميرا، وما إلى ذلك). المجموعة السابقة من الأقسام هي المكان الذي يتم فيه اكتشاف معظم الثغرات الأمنية وتصحيحها، لذا من الجيد أن نرى أن حماية هذه الأقسام أمر إلزامي. ومع ذلك، فقد كانت هناك عمليات استغلال تستهدف الأقسام ذات البرامج الثابتة الثابتة أيضًا، لذلك نحن غير متأكدين من سبب عدم قيام Google بفرض الحماية من التراجع عليها.

عضو كبير في XDA com.npjohnson، وهو عضو في فريق LineageOS، يتوقع أن يتطلب الأمر حماية التراجع على الأقسام ذات البرامج الثابتة المستمرة تتطلب روابط Bootloader الثانوية (SBL) وEXtensible Bootloader (XBL) حيث تم تثبيت هذه الأقسام مسبقًا في التمهيد عملية. سيكون من المكلف لمصنعي المعدات الأصلية الأصغر حجمًا تنفيذ وحدات XBL المخصصة لتتناسب مع أجهزة المودم المخصصة والأقسام الثابتة الأخرى، لذلك ربما لا تجعل Google هذا مطلبًا لتسهل على صانعي الأجهزة تلبية أحدث المتطلبات في CDD.

كيفية التحقق مما إذا كان هاتفك يدعم AVB 2.0

يوجد أمران من أوامر ADB shell يمكنك استخدامهما للتحقق مما إذا كان هاتفك يدعم AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

أو

adb shell
getprop | grep "avb"

إذا كان إخراج الأمر الأول هو "android.software.verified_boot"، فإن AVB 2.0 يكون مدعومًا. إذا كان مخرج الأمر الثاني يظهر "[ro.boot.avb_version]" و"[ro.boot.vbmeta.avb_version]" ويسرد رقم إصدار لكل منهما، فهذا يعني أنه مدعوم.

تم التحقق من التمهيد والتطوير المخصص

لا يؤثر Android Verified Boot فعليًا على معظم مستخدمي ROM المخصصين على الرغم من أنه يضيف طبقة إضافية من الأمان يتعين عليك التغلب عليها في بعض الحالات. على سبيل المثال، وميض صورة النظام العامة يتطلب تعطيل AVB. تعديل أقسام معينة مثل البائع على OnePlus 6 يتطلب تعطيل AVB أيضًا، كما تعلمت مؤخرا. وفق com.npjohnson، فإن تطبيق AVB 2.0 بشكل صحيح يجعل من الممكن لصور التمهيد المخصصة أن تعمل مع أداة تحميل التشغيل المقفلة. سنرى كيف يؤثر تضمين AVB 2.0 على الأجهزة التي يتم شحنها باستخدام Android Pie على المشهد، ولكننا نأمل ألا يؤدي ذلك إلى مواقف مثل الخوف من الطوب الأخير في مجتمع Xiaomi Redmi Note 5 Pro. يعد الإصدار الإلزامي AVB 2.0 مجرد طريقة أخرى لـ Google للقيام بذلك تحسين أمان منصة Androidولكن التغيير الأكبر، في رأينا، هو إعادة العمل باتفاقيات OEM لإصدار تصحيحات أمنية منتظمة.