از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
بوت را تأیید کنید
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
بوت تأیید شده نیاز به تأیید رمزنگاری تمام کدهای اجرایی و دادههایی دارد که بخشی از نسخه Android در حال بوت شدن هستند قبل از استفاده. این شامل هسته (بارگیری شده از پارتیشن boot
)، درخت دستگاه (بارگیری شده از پارتیشن dtbo
)، پارتیشن system
، پارتیشن vendor
و غیره است.
پارتیشنهای کوچکی مانند boot
و dtbo
که فقط یک بار خوانده میشوند، معمولاً با بارگیری کل محتویات در حافظه و سپس محاسبه هش آن تأیید میشوند. سپس این مقدار هش محاسبه شده با مقدار هش مورد انتظار مقایسه می شود. اگر مقدار مطابقت نداشته باشد، Android بارگیری نمیشود. برای جزئیات بیشتر، Boot Flow را ببینید.
پارتیشنهای بزرگتر که در حافظه قرار نمیگیرند (مانند سیستمهای فایل) ممکن است از درخت هش استفاده کنند که در آن تأیید یک فرآیند پیوسته است که با بارگیری دادهها در حافظه انجام میشود. در این حالت، هش ریشه درخت هش در طول زمان اجرا محاسبه میشود و با مقدار هش ریشه مورد انتظار بررسی میشود. اندروید شامل درایور dm-verity برای تایید پارتیشن های بزرگتر است. اگر در نقطهای هش ریشه محاسبهشده با مقدار هش ریشه مورد انتظار مطابقت نداشته باشد، از دادهها استفاده نمیشود و اندروید وارد حالت خطا میشود. برای جزئیات بیشتر، فساد dm-verity را ببینید.
هش های مورد انتظار معمولاً در انتهای یا ابتدای هر پارتیشن تأیید شده، در یک پارتیشن اختصاصی یا هر دو ذخیره می شوند. مهمتر از همه، این هش ها (به طور مستقیم یا غیر مستقیم) توسط ریشه اعتماد امضا می شوند. به عنوان مثال، پیاده سازی AVB از هر دو رویکرد پشتیبانی می کند، برای جزئیات بیشتر به Android Verified Boot مراجعه کنید.
حفاظت برگشتی
حتی با یک فرآیند بهروزرسانی کاملاً ایمن، این امکان وجود دارد که یک اکسپلویت هسته اندرویدی غیردائم به صورت دستی نسخه قدیمیتر و آسیبپذیرتر اندروید را نصب کند، در نسخه آسیبپذیر راهاندازی مجدد شود و سپس از آن نسخه اندروید برای نصب یک اکسپلویت دائمی استفاده کند. از آنجا مهاجم به طور دائم مالک دستگاه است و می تواند هر کاری انجام دهد، از جمله غیرفعال کردن به روز رسانی ها.
حفاظت در برابر این دسته از حملات ، محافظت برگشتی نامیده می شود. محافظت برگشتی معمولاً با استفاده از فضای ذخیرهسازی آشکار برای ضبط جدیدترین نسخه اندروید و امتناع از بوت کردن اندروید در صورتی که پایینتر از نسخه ضبط شده باشد، اجرا میشود. نسخه ها معمولاً بر اساس هر پارتیشن ردیابی می شوند.
برای جزئیات بیشتر در مورد نحوه عملکرد AVB از محافظت های برگشتی، به AVB README مراجعه کنید.
رسیدگی به خطاهای تأیید
راستیآزمایی میتواند در زمان راهاندازی (مثلاً اگر هش محاسبهشده در پارتیشن boot
با هش مورد انتظار مطابقت نداشته باشد) یا در زمان اجرا (مانند اگر dm-verity با خطای تأیید در پارتیشن system
مواجه شود) با شکست مواجه شود. اگر تأیید در زمان بوت انجام نشود، دستگاه نمی تواند بوت شود و کاربر نهایی باید مراحل بازیابی دستگاه را طی کند.
اگر تأیید در زمان اجرا با شکست مواجه شود، جریان کمی پیچیدهتر است. اگر دستگاه از dm-verity استفاده می کند، باید در حالت restart
پیکربندی شود. در حالت restart
، اگر با خطای تأیید مواجه شد، دستگاه بلافاصله با یک پرچم مشخص برای نشان دادن دلیل راه اندازی مجدد می شود. بوت لودر باید متوجه این پرچم شود و dm-verity را برای استفاده از حالت خطای ورودی/خروجی ( eio
) روی آن تغییر دهد و تا زمانی که بهروزرسانی جدید نصب نشود، در این حالت بماند.
هنگام بوت شدن در حالت eio
، دستگاه صفحه خطایی را نشان می دهد که به کاربر اطلاع می دهد که خرابی شناسایی شده است و ممکن است دستگاه به درستی کار نکند. صفحه نمایش داده می شود تا زمانی که کاربر آن را رد کند. در حالت eio
درایور dm-verity دستگاه را مجددا راه اندازی نمی کند اگر با خطای تأیید مواجه شود، در عوض یک خطای EIO برگردانده می شود و برنامه باید با خطا مقابله کند.
هدف این است که یا بهروزرسانیکننده سیستم اجرا شود (بنابراین سیستمعامل جدیدی بدون خطاهای خراب نصب شود) یا کاربر بتواند تا حد امکان اطلاعات خود را از دستگاه دریافت کند. هنگامی که سیستم عامل جدید نصب شد، بوت لودر متوجه سیستم عامل تازه نصب شده می شود و به حالت restart
برمی گردد.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Verify Boot\n\nVerified Boot requires cryptographically verifying all executable code and data\nthat is part of the Android version being booted before it is used. This includes\nthe kernel (loaded from the `boot` partition), the device tree (loaded\nfrom the `dtbo` partition), `system` partition,\n`vendor` partition, and so on.\n\n\nSmall partitions, such as `boot` and `dtbo`, that are read\nonly once are typically verified by loading the entire contents into memory and\nthen calculating its hash. This calculated hash value is then compared to the\n*expected hash value* . If the value doesn't match, Android won't load.\nFor more details, see [Boot Flow](/docs/security/features/verifiedboot/boot-flow).\n\n\nLarger partitions that won't fit into memory (such as, file systems) may use\na hash tree where verification is a continuous process happening as data is\nloaded into memory. In this case, the root hash of the hash tree is calculated\nduring run time and is checked against the *expected root hash value* .\nAndroid includes the [dm-verity\ndriver](/docs/security/features/verifiedboot/dm-verity) to verify larger partitions. If at some point the calculated root\nhash doesn't match the *expected root hash value* , the data isn't used\nand Android enters an error state. For more details, see\n[dm-verity\ncorruption](/docs/security/features/verifiedboot/boot-flow#dm-verity-corruption).\n\n\nThe *expected hashes* are typically stored at either the end or beginning\nof each verified partition, in a dedicated partition, or both. Crucially, these\nhashes are signed (either directly or indirectly) by the root of trust. As an\nexample, the AVB implementation supports both approaches, see\n[Android Verified Boot](/docs/security/features/verifiedboot/avb) for details.\n\nRollback protection\n-------------------\n\n\nEven with a completely secure update process, it's possible for a non-persistent\nAndroid kernel exploit to manually install an older, more vulnerable version of\nAndroid, reboot into the vulnerable version, and then use that Android version to\ninstall a persistent exploit. From there the attacker permanently owns the device\nand can do anything, including disabling updates.\n\n\nThe protection against this class of attacks is called *Rollback\nProtection*. Rollback protection is typically implemented by using\ntamper-evident storage to record the most recent version of the Android and\nrefusing to boot Android if it's lower than the recorded version. Versions\nare typically tracked on a per-partition basis.\n\n\nFor more details on how AVB handles rollback protections, see the AVB\n[README](https://android.googlesource.com/platform/external/avb/+/android16-release/README.md#Rollback-Protection).\n\nHandle verification errors\n--------------------------\n\n\nVerification can fail either at boot time (such as, if the calculated hash on\n`boot` partition doesn't match the expected hash) or at run time\n(such as, if dm-verity encounters a verification error on the\n`system` partition). If verification fails at boot time, the device\ncan't boot and the end user needs to go through steps to recover the device.\n\n\nIf verification fails at run-time the flow is a bit more complicated. If the\ndevice uses dm-verity, it should be configured in `restart` mode. In\n`restart` mode, if a verification error is encountered, the device is\nimmediately restarted with a specific flag set to indicate the reason. The boot\nloader should notice this flag and switch dm-verity over to use I/O Error\n(`eio`) mode and stay in this mode until a new update has been\ninstalled.\n\n\nWhen booting in `eio` mode, the device shows an error screen\ninforming the user that corruption has been detected and the device might not\nfunction correctly. The screen shows until the user dismisses it. In\n`eio` mode the dm-verity driver won't restart the device if a\nverification error is encountered, instead an EIO error is returned and the\napp needs to deal with the error.\n\n\nThe intent is that either the system updater will run (so a new OS without\ncorruption errors can be installed) or the user can get as much of their data\noff the device as possible. Once the new OS has been installed, the boot loader\nnotices the newly installed OS and switches back to `restart` mode."]]