يتطلب التمهيد الذي تم التحقق منه التحقق بشكل مشفر من جميع التعليمات البرمجية والبيانات القابلة للتنفيذ والتي تعد جزءًا من إصدار Android الذي يتم تشغيله قبل استخدامه. يتضمن ذلك النواة (المحملة من قسم boot )، وشجرة الجهاز (المحملة من قسم dtbo )، وقسم system ، وقسم vendor ، وما إلى ذلك.
عادةً ما يتم التحقق من الأقسام الصغيرة، مثل boot و dtbo ، التي تتم قراءتها مرة واحدة فقط، عن طريق تحميل محتوياتها بالكامل في الذاكرة ثم حساب التجزئة الخاصة بها. ثم تتم مقارنة قيمة التجزئة المحسوبة بقيمة التجزئة المتوقعة . إذا كانت القيمة غير متطابقة، فلن يتم تحميل Android. لمزيد من التفاصيل، راجع تدفق التمهيد .
قد تستخدم الأقسام الأكبر حجمًا التي لا يمكن احتواؤها في الذاكرة (مثل أنظمة الملفات) شجرة تجزئة حيث يكون التحقق عبارة عن عملية مستمرة تحدث أثناء تحميل البيانات في الذاكرة. في هذه الحالة، يتم حساب التجزئة الجذرية لشجرة التجزئة أثناء وقت التشغيل ويتم فحصها مقابل قيمة التجزئة الجذرية المتوقعة . يتضمن Android برنامج تشغيل dm-verity للتحقق من الأقسام الأكبر حجمًا. إذا لم يتطابق تجزئة الجذر المحسوب في وقت ما مع قيمة تجزئة الجذر المتوقعة ، فلن يتم استخدام البيانات ويدخل Android في حالة خطأ. لمزيد من التفاصيل، راجع تلف dm-verity .
عادةً ما يتم تخزين التجزئات المتوقعة إما في نهاية أو بداية كل قسم تم التحقق منه، في قسم مخصص، أو كليهما. والأهم من ذلك، أن هذه التجزئات يتم توقيعها (إما بشكل مباشر أو غير مباشر) بواسطة جذر الثقة. على سبيل المثال، يدعم تطبيق AVB كلا الطريقتين، راجع Android Verified Boot للحصول على التفاصيل.
حماية التراجع
حتى مع وجود عملية تحديث آمنة تمامًا، من الممكن لاستغلال نواة Android غير المستمرة تثبيت إصدار أقدم وأكثر عرضة للخطر من Android يدويًا، وإعادة التشغيل في الإصدار الضعيف، ثم استخدام إصدار Android هذا لتثبيت استغلال مستمر. ومن هناك يمتلك المهاجم الجهاز بشكل دائم ويمكنه فعل أي شيء، بما في ذلك تعطيل التحديثات.
تسمى الحماية ضد هذه الفئة من الهجمات بالحماية من التراجع . عادةً ما يتم تطبيق حماية التراجع عن طريق استخدام التخزين الواضح للتلاعب لتسجيل أحدث إصدار من Android ورفض تشغيل Android إذا كان أقل من الإصدار المسجل. عادةً ما يتم تعقب الإصدارات على أساس كل قسم.
لمزيد من التفاصيل حول كيفية تعامل AVB مع عمليات الحماية من التراجع، راجع AVB README .
معالجة أخطاء التحقق
يمكن أن يفشل التحقق إما في وقت التمهيد (على سبيل المثال، إذا كانت التجزئة المحسوبة على قسم boot لا تتطابق مع التجزئة المتوقعة) أو في وقت التشغيل (على سبيل المثال، إذا واجه dm-verity خطأ في التحقق على قسم system ). إذا فشلت عملية التحقق في وقت التمهيد، فلن يتمكن الجهاز من التمهيد وسيحتاج المستخدم النهائي إلى اتباع الخطوات اللازمة لاسترداد الجهاز.
إذا فشل التحقق في وقت التشغيل، فسيكون التدفق أكثر تعقيدًا بعض الشيء. إذا كان الجهاز يستخدم dm-verity، فيجب تكوينه في وضع restart . في وضع restart ، في حالة حدوث خطأ في التحقق، تتم إعادة تشغيل الجهاز على الفور مع تعيين علامة محددة للإشارة إلى السبب. يجب أن يلاحظ محمل الإقلاع هذه العلامة ويقوم بتبديل dm-verity لاستخدام وضع خطأ الإدخال/الإخراج ( eio ) والبقاء في هذا الوضع حتى يتم تثبيت تحديث جديد.
عند التشغيل في وضع eio ، يعرض الجهاز شاشة خطأ لإعلام المستخدم باكتشاف تلف وأن الجهاز قد لا يعمل بشكل صحيح. تظهر الشاشة حتى يرفضها المستخدم. في وضع eio ، لن يقوم برنامج تشغيل dm-verity بإعادة تشغيل الجهاز في حالة مواجهة خطأ في التحقق، وبدلاً من ذلك يتم إرجاع خطأ EIO ويحتاج التطبيق إلى التعامل مع الخطأ.
والقصد من ذلك هو تشغيل مُحدِّث النظام (بحيث يمكن تثبيت نظام تشغيل جديد بدون أخطاء تلف) أو يمكن للمستخدم الحصول على أكبر قدر ممكن من بياناته من الجهاز قدر الإمكان. بمجرد تثبيت نظام التشغيل الجديد، يلاحظ برنامج تحميل التشغيل نظام التشغيل المثبت حديثًا ويعود إلى وضع restart .