Как Android перестал доверять пользователю?
Знакомая картина ты решил, что стандартная прошивка это скучно, зашел в Настройки для разработчиков, нервно тыкнул по переключателю OEM unlocking, а потом, затаив дыхание, вбил в консоли ту самую заветную команду fastboot oem unlock ( ну или fastboot flashing unlock, если у тебя свежий аппарат). И при каждом включении тебя теперь встречает мерзкая надпись на английском Your device software can't be checked for corruption или что-то в духе Orange State. Телефон как будто кричит тебе Чувак, я тебе не доверяю Ты залез куда не просили, и теперь я не ручаюсь за твою безопасность.Многие думают, что это просто пугалка от производителя, чтобы мы не ставили кастомные прошивки. Но на самом деле за этой надписью стоит одна из самых сложных и крутых систем защиты Android Verified Boot (AVB). Давайте разберемся, как мы дошли до жизни такой.
1) Эпоха дикого запада.Когда андроид был дырявым.
Чтобы понять, зачем нужен AVB, надо вспомнить, как всё начиналось. Времена Android 2.3 или 4.0 были золотым веком для энтузиастов и сущим адом для безопасности. Система была устроена по принципу верю всем. Процессор просто брал код из памяти и запускал его. Хочешь подменить системный шрифт? Легко. Хочешь вшить в ядро скрипт, который будет воровать СМС от банка и пересылать их на сервер в Люксембурге? Никаких проблем! Если вирус получал Root-права (а тогда это делалось одной кнопкой в кривых апках), он мог переписать системные разделы так, что его не видел ни один антивирус. Смартфон превращался в зомби, который внешне работал нормально, но внутри уже давно не принадлежал хозяину.
2) Рождение AVB: Цепочка доверия.
В Google быстро смекнули: систему нужно научить проверять саму себя на вшивость. Так появилась концепция Verified Boot (Проверенная загрузка). Работает это как строгая иерархия в армии. Представьте цепочку Первый офицер (Boot ROM) это крошечный код, зашитый намертво в железо процессора (на заводе Qualcomm или MediaTek). Его нельзя изменить даже молитвами. Когда ты жмешь кнопку питания, он первым делом проверяет цифровую подпись Загрузчика (Bootloader). Если подпись совпала, Загрузчик просыпается и проверяет подпись следующего звена Ядра системы. Ядро проверяет всё остальное драйверы, системные приложения и библиотеки. Это и есть Chain of Trust. Если в этой цепочке хотя бы одно звено гнилое (кто-то изменил хотя бы один байт в коде), проверка не проходит. И вот тут-то и вылезает та самая бесячая надпись Orange State. Вводя команду oem unlock, ты буквально говоришь процессору Слышь, забей на проверку подписей, я сам себе режиссер. Процессор подчиняется, но при каждом включении снимает с себя ответственность, напоминая, что теперь безопасность это только твои проблемы.
3) Как проверить 10 Гб за долю секунды.
Первые версии защиты (dm-verity) были довольно тяжелыми. Представь телефону нужно при каждом включении прочитать 10 ГБ системных данных и посчитать их контрольную сумму. Это убило бы любой аккумулятор и заставило бы тебя ждать загрузки по 10 минут. Инженеры выкрутились гениально, внедрив в AVB 2.0 так называемое дерево хэшей. Вся система разбита на маленькие блоки данных. От каждого блока берется отпечаток. Эти отпечатки группируются и снова хэшируются, пока в самом верху не останется один единственный Корневой хэш. Вся эта структура вместе с цифровой подписью производителя хранится в специальном разделе, который называется VBMeta. Смартфону достаточно проверить одну маленькую подпись этого раздела. Если она совпадает с ключом, зашитым в железо всё ок, загружаемся. Но если ты в процессе работы системы (даже будучи рутом) попытаешься подменить хотя бы одну иконку, механизм dm-verity мгновенно это заметит, потому что хэш блока изменится. Итог кирпич или вечный ребут (Bootloop), потому что доверие подорвано.
4) Anti-Rollback Билет в один конец.
Еще одна вещь, от которой полыхают стулья у любителей старых прошивок это защита от отката. Допустим, в Android 13 нашли критическую дыру, через которую можно взломать телефон. Google выпускает патч безопасности. Злоумышленник крадет твой телефон и пытается прошить его на Android 12, где эта дыра еще открыта. Тут в игру вступает AVB с Anti-Rollback. Внутри процессора есть специальные предохранители (eFuses) это физические ячейки памяти, которые можно прожечь но нельзя восстановить. Когда ты обновляешься, система прожигает новую версию. Если ты попытаешься залить прошивку старее той, что записана в процессоре, AVB скажет Версия 12 меньше версии 13. Загрузка запрещена. Именно поэтому откатиться на старую версию, где было лучше на современных телефонах часто просто невозможно.
Итог:
Надпись после разблокировки загрузчика это честный договор. Ты получаешь свободу ставить любые прошивки, но теряешь гарантию, что твой аппарат это всё еще защищенная крепость. В мире, где в смартфоне лежат Данные AVB это невидимый ангел-хранитель, который следит, чтобы код в твоем телефоне оставался именно таким, каким его задумал производитель.
1) https://source.android.com/docs/security/features/verifiedbo...
2) https://source.android.com/docs/security/features/verifiedbo...
3) https://source.android.com/docs/security/features/verifiedbo...
4) https://github.com/ARM-software/u-boot/blob/master/doc/READM... 5) https://github.com/CarbonROM/android_external_avb
6)https://source.android.com/docs/security/features/verifiedbo...
