Как стать автором
Обновить

Как root-права и альтернативные прошивки делают ваш android смартфон уязвимым

Время на прочтение 54 мин
Количество просмотров 123K
Всего голосов 127: ↑123 и ↓4 +119
Комментарии 210

Комментарии 210

НЛО прилетело и опубликовало эту надпись здесь

Согласен, root может давать немало ништяков от которых сложно отказаться. Тут, каждому на вкус и цвет, но честно говоря, я лично самым полезным нахожу Afwall, а остальное вроде как и нерутовыми инструментами достигается

Это все так но один важный момент, если плохие руки до тебя дотянуться то может быть расклад что ты сам им все отдашь и рад будешь что жив остался.Вот приложение какое либо чтобы все стирало(без восстановления) на телефоне в случае опасности попадания данных не в те руки, вот это было бы полезно в некоторых случаях.
Я рассмотрел только технические аспекты возможной атаки. Понятное дело что терморектальный криптоанализ помогает владельцу вспомнить все свои пароли

Банковскими приложениями на телефонах лучше вообще не пользоваться, учитывая, какой у них список разрешений — они имеют доступ буквально ко всему.

Для пользования банковскими приложениями нужен отдельный телефон, с дефолтным набором невычищаемых приложух, но с последним принимаемым обновлением оси. Никаких медиафайлов, никаких контактов. Нормальное состояние аппарата - выключен, его полузаряженная батарея, флешки и симки (под каждый банк своя) хранятся отдельно

Это называется вот так.

лучше быть живым параноиком, чем мертвым оптимистом. Я уж не говорю о том, что в случае пересечения той же РФ или США границы - могут попросить показать телефон. Я очень не хотел бы, чтобы там нашли БК и всякие учетки на биткойн биржах.

Что мешает сохранить данные на пару зашифрованных флэшек или положить шифрованный же образ на арендованный сервер, а телефон обнулить или настроить на второй, специально для этого созданный аккаунт, в котором будут только котики и попса?

Например то, что много какой софт (даже не только банковский) на андроиде вы так забекапить не сможете без рута (на iOS чуть получше с этим), вычистить ВСЕ следы конкретных приложений — тоже не факт что обычный пользователь сможет, кроме как полным сбросом.
А второй аккаунт могут попросить показать.
Хотя… меня на контроле максимум просили включить (просто чтобы началась загрузка, проверка что девайс то чем кажется видимо) а не копались.
Но вот границу США у меня не было пока нужды пересекать.

А второй аккаунт могут попросить показать.

Какой аккаунт, гражданин начальник? Вот, всё здесь: котики, переписка с родителями и девушкой, а больше и нет ничего.

В этом и смысл, что граница пересекается с пустым телефоном или с аккаунтом, специально для этого заготовленным, а потом снова сброс, авторизация в основном аккаунте и восстановление всех данных.

Тут надо понимать, что когда в дом условного независимого разработчика постучится настоящая беда (нужны будут деньги на срочную операцию дочери и т.п.), он вас продаст «предприимчивым людям с большой дороги».
Потом, конечно, будет разоблачение, не все пользователи успеют попасться, но конкретным потерпевшим от этого легче не станет.

Всё равно root, таскер и прочее ПО работает с вашими данными и коммуникациями. Тут можно и без банковских приложений бед натворить. Свою карточку вы спрятали, а жене от вас придёт СМС: «Сбил человека, надо ему на Сбер перевести 20 тыс.», ваши же деньги мошенникам уйдут, просто «из другого кармана».
Свою карточку вы спрятали, а жене от вас придёт СМС

  1. Это не так работает.
  2. В телефоне для работы с банковскими приложениями не нужна записная книжка с личными контактами.
1. естественно, я не пытаюсь в комментарий уместить пособие по отъёму денег у населения, и в реальности оно немножко не так работает
2. к чему вы это написали?

Прошу прощения, помню давно при установке обновления через TWRP для того же Lineage OS мне приходится выводить пароль который я ввожу на экране блокировки.
Загрузчик заблокирован.
Что это, и почему это не защищает от опасного вами?
Телефон зашифрован, а значит что-то прошить можно только после ввода пароля, ну или полностью прошить чистой через компьютер прошивкой. Разве нет?

К сожалению, пароль в TWRP — это прикладная логика именно самого TWRP. Состояние заблокированного/разблокированного загрузчика к TWRP никакого отношения не имеет. Если у вас установлен TWRP, то в 99% случаев это значит что устройство имеет разблокированный загрузчик.

Это никак не защищает от описанного потому, что с разблокированным загрузчиком злоумышленнику нет смысла пытаться угадывать пароль TWRP — он просто загружает образ TWRP без пароля и шьёт в устройство что пожелает.

Часть статьи как раз описывает что когда мы обычно говорим что устройство «зашифровано», то на самом деле в нём зашифровано всего лишь две директории. Злоумышленник может установить нагрузку в ту часть системы, которая не шифруется FBE
Прямо иентересно, что там за тема с Перекрёстком. Рут позволяет накинуть баллов? :)

У меня рут стоит для вполне обычных приложений, для которых по какой-то причине нет штатного доступа: синхронизация времени по NTP, бэкапы данных приложений, блокировка рекламы, запись звонков.
Третий и самый сложный подход – продолжать использовать альтернативную сборку ОС, но заблокировать загрузчик используя user-settable root of trust. Это действительно сложный и затратный подход, достойный написания отдельной статьи, потому как требует самостоятельно делать сборку ОС и самостоятельно её подписывать.

Пишите обязательно. Рут использую как минимум для файрвола (очень удобно срезать рекламу в тех местах, где доступ в интернет не предполагается в принципе, например в оффлайн-играх). Риски, связанные с открытием загрузчика (и наличием рекавери, которое смотрит в мир голым задом), в принципе понимал с самого начала, и принимал как неизбежное зло. Так что возможность закрыть загрузчик обратно со своими ключами была бы кстати.

Спасибо! Надо сделать себе пометку в планы на будущее

То есть простого способа заблокировать загрузчик нет?
Почему в том же TWRP нет возможности пароль поставить, чтобы любой рандом не мог в него загрузиться?

Потому что любой рандом может загрузиться в свой образ TWRP, который пароль спрашивать не будет. И ему не будет важно, а что там за пароль в вашем TWRP.

Именно, просто условный злоумышленник делает fastboot boot unpasswored_twrp.img и игнорирует то TWRP которое установлено в рековери раздел

По статье не понял, почему full-device-encryption теперь не используется, потому как это было бы частичным решением (хотя конечно трояна в twrp...)

Что по поводу сделать подписанный загрузчик (и заблокировать систему), а уж он уже загружает кастомную систему не взирая на ее подпись?

Нет сделать круче, носить с собой дополнительное устройство, с которого будет производиться загрузка, т.е. включение выключенного смартфона должно производиться не с той версии twrp что записана на смартфоне, а со своего, гарантированно не испорченного, запускаемого в памяти телефона, а уже оно запрашивает пароль и расшифровывает раздел… можно заодно проверить на модификацию локальный загрузчик, чтобы отсигналить — 'тебя пытались взломать'

p.s. интересно, можно ли это сделать со второго смартфона? обычно установка модификаций android требует десктопный компьютер, хватит ли для этого usb otg и соответствующего кабеля?
FDE заставляет пользователя вводить лишний раз пароль при старте, усложняет процесс загрузки — сначала необходимо загрузить мини-образ системы с формой ввода пароля, а потом уже основную систему. Если я правильно понял, (сам я не застал устройств с FDE) то там также шифровался только userdata раздел, так что, в общем-то, выигрыша по безопасности в плане невозможности модифицировать boot и system FDE не даёт

Увы, большинство мер по доверенной загрузке и прочим очень низкоуровневым механизмам не относятся к коду самой системы напрямую, их реализует вендор просто ориентируясь на определённый интерфейс в системе с которым будет взаимодействовать. Сейчас эта мера — комплекс всех инструментов реализующих процесс verified boot. Накрутить что-то кастомное — очень сложно, и требует владения железом и драйверами к нему, т.е. фактически невозможно в нынешних условиях
Если у меня телефон просит пин код в самом старте загрузки — значит он с FDE?
Модель начала 2020 года, достаточно новый китаец.

Похоже на то. Значит их ещё могут и выпускать. Я сам никогда не сталкивался с FDE лично, а почти везде написано что в основном шифрование в андроиде это всегда FBE

А разве не на всех андроидах FDE есть?
При покупке нового смартфона всегда лез в настройки и что-то такое ставил. Даже пострадал 1 раз из-за этого. Телефон ребутнулся для установки обновлений, сам без пароля загрузится не смог и у меня будильник не сработал. Послидний такой redmi note 8t

Для устройства вышедшего на рынок с андроидом 7.0+ должно быть только FBE. Устройство которое обновилось до 7.0+ может иметь FDE

Навангую альтернативный вариант: а ещё это может быть ввод пин-кода сим-карты.
кстати да, но там пищется что пин от сим карты

но дата раздел зашифрован, доступа нет.

ты расшифруешь его сам, включив телефон когда тебе его вернут, а встроенный бекдор эти данные сольет.
Приведённый в примере пейлоад ждёт пока владелец введёт код разблокировки первый раз, после чего открывает удалённый шелл к устройству. После первой разблокировки устройства данные уже всегда остаются незашифрованными, вплоть до выключения смартфона, поэтому злоумышленник может стащить документы с устройства. Если после возврата устройства пользователь ни разу не будет вводить код разблокировки, то конечно ничего достать не получится
Правильно ли я понял, что с разблокированным загрузчиком:
1)если у меня включено FDE, то проверять хеши нужно только в случае если смартфон запрашивает пароль для включения(а не для разблокировки), а не при каждом риске попадания смартфона в чужие руки?
2)Склонировать образ смартфона, установить на другой и сбрутить пароль не получится?

Я не наблюдал сам за работой FDE, поэтому не могу быть уверен на 100% что именно он шифрует внутри. Из того что я прочитал, полагаю что он шифрует раздел userdata целиком, но system и boot также не трогаются, поэтому нам также стоит следить за хэшами в случае временного попадания устройства в чужие руки.


Второе — не получится, потому что шифрование завязано на ТЕЕ. Мы можем склонировать userdata раздел, но тогда брутфорсить нам полное пространство ключей — 2^128. Скорее уж получится локально пробовать подбирать пины, многие люди снижают энтропию на несколько порядков используя части даты рождения или телефонных номеров своих или близких родственников, может повезти

1)Т.е. можно провести атаку не выключая смартфон? Или вы невнимательно прочитали вопрос?
2)спасибо, так и думал, но хотел убедиться.

Хм, может я недопонял вопрос. Тот сценарий который я описал требует перезагрузки устройства, сначала в fastboot, потом в рековери, потом снова в систему. Без перезагрузок ничего сделать не получится, поэтому не выключая смартфон атаку не провести

Если переформулировать…
Если смартфон остался включённым(не требует пароля FDE при включении) значит ли это что атака не была проведена?
Это точно значит что смартфон не перезагружали, а атака не может быть проведена без перезагрузок. Получается да, если не требует ввода пароля и остался включённым, значит точно не пытались атаковать

Всё верно, FDE точно так же шифровал только /data. По поводу перебора, возвращаемся к самому первому включению.

Первое что делает устройство обнаружив пустой раздел /data - генерирует ключ шифрования (увы не помню про сложность/длину и искать не в настроении), которым и будет зашифрована /data, и соответственно "шифрует" пока ещё пустой раздел. Далее, как сказано в статье он заполняется данными. Для хранения ключ шифруется стандартным паролем "default_password", при сборке прошивки вендор может его сменить (не знаю ни единого случая его замены). При установке защиты на экран блокировки - ключ шифрования перешифровывается новыми данными. При этом нет необходимости перешифровывать весь раздел /data.

Спасибо за интерес к статье! Про механику шифрования раздела с данными и "default_password" - хорошее замечание, я не раскрыл этот момент в статье, потому что с точки зрения извлечения данных в сценарии когда у атакующего есть физический доступ это имеет значение только на телефоне без установленной блокировки экрана, а без установленной блокировки экрана злоумышленник и так сможет посмотреть всё что захочет.

А где хранится ключ шифрования?
Допустим я разгрохал телефон в хлам, должен ли я принести в сервис для восстановления информации что-то кроме чипа памяти и пароля от смартфона?
Судя по логике да, т.к. если достаточно только чипа памяти, то все короткие пароли(пин код) можно подобрать переборов.
И тогда возникает вопрос: а вообще можно вытащить информацию, если смартфон ремонту не подлежит?

TWRP можно же запаролить
но с разблокированным загрузчиком можно игнорировать запароленный twrp и загрузить свой — незапароленный.

Есть.
Yellow mode https://source.android.com/security/verifiedboot/boot-flow (заливается СВОЙ Root of trust, им все что надо подписывается, загрузчик лочится)
Но телефон должен нормально поддерживать VerifiedBoot. По сути только Pixel'ы.

Верно. Ещё часть ванплюсов. К сожалению, в настоящее время реализация механизма user settable root of trust является добровольной, а не обязательной для сертификации устройства со стороны Google для компаний производящих устройства под андроид, поэтому почти никто это не делает. Мне бы лично хотелось чтобы большинство устройств имели такую возможность. По сути, это сделало бы устройства на кастомных прошивках одинаково безопасными (и уж точно куда более приватными) по сравнению со стоковыми прошивками от производителя и не было бы необходимости писать эту статью

Третий и самый сложный подход – продолжать использовать альтернативную сборку ОС

Да, надеюсь увидеть статью. Даже имея рут права как класс, грамотно настроив их выдачу можно хорошо обезопасить себя. Но разблокированный загрузчик все портит. О успешном переводе его статуса в yellow слышал только на пикселях.

Спасибо. Для этого необходимо чтобы производитель реализовал поддержку avb_custom_key. К сожалению, это необязательная фича для сертификации и многие ей пренебрегают. Я знаю что такое есть в пикселях, и сам проверял что есть на OnePlus. Возможно кто-то ещё поддерживает, но я об этом не знаю

На, вы будете смеяться, Яндекс.Телефоне можно заблокировать загрузчик после установки LineageOS.

Ого, неожиданно. Правда вот яндексофоны в продаже найти не так просто

Но это не фича, это бага. Но не Яндекс её фиксить не собирается, не Гугл у них CTS и SafetyNet сертификацию отзываться и не думает. Зато запустить модем мы вам не дадим, юзайте кривой какой дали.

А при разблокировке и блокировке требует очищать данные?

Да, при штатном поведении в обоих случаях раздел userdata будет отформатирован.

Угу, только раньше можно было не позволить это сделать на части устройств, как сейчас - не подскажу

Было бы очень круто почитать статью про avb_custom_key и блокировку лоадера с установленным Magisk и т.д.
Еще интересно, позволит ли такой статус пройти SafetyNet CTS Profile проверку с hardware-based key attestation, которую сейчас невозможно обойти Magisk Hide. Как например сейчас на Pixel 3a.

С установленным magisk наверное не получится, потому что незачем и наличие рута при заблокированном загрузчике чревато окирпичиванием, или, по крайней мере, потерей данных, при неаккуратном изменении чего-то что нельзя менять. Однако можно заблокировать загрузчик на альтернативной сборке ОС, той же LineageOS, только надо не полениться собрать её в релизном варианте.


Я вот подумал что можно попробовать вытащить код magiskhide и попроьовать поиграться с ним, либо попробовать адаптировать стороннее решение по аппаратной аттестации. Так например свой аппаратный аттестатор сделан в GrapheneOS (там разработчики большие молодцы и очень заботятся о безопасности), свой аттестатор есть в huawei (им отключили гугл сервисы и приходится выкручиваться)

чревато окирпичиванием, или, по крайней мере, потерей данных, при неаккуратном изменении чего-то что нельзя менять

Разве не будет решением загрузиться в (подписанный) рекавери и прошить обратно штатный образ ОС, не трогая данные?

А как то по простому проверить можно на конкретном телефоне?
На HTC был когда-то, на Asus TF700.
Сколько всего наворочено в системе во имя безопасности и всё это оказывается безвольным против вирусов распространяемых через google play (ещё скажите что таких больше не существует?). А так же против практически любого легального приложения, запрашивающего обширный список прав, для более удобного сбора к приватной информации и отправки её на сервера. Причём приложения от самой google делают это активнее всех.

Отчасти поэтому и возникла вся движуха с root правами. Действительно, глупо отрицать что гугл не выжимает по максимуму пользовательских данных из устройств на своей ОС, однако суть статьи — просто показать что у альтернативных решений есть свои проблемы

Хорошо сказано.

Поэтому Android — это не Linux, как Вы написали в статье.

В GNU/Linux незашифрованный/разблокированный только раздел под загрузчик (если исходить из настроенной безопасности), например под GRUB (иначе, например, старенький BIOS не поймет как загружаться). Однако этот раздел легко захэшировать (не только файлы в тч и свободное пространство) и сверять хэш при загрузке. И если, что-то злостное дописать в раздел загрузчика, хэш не совпадет. После обновления GRUB/системы, просто вручную перехэшировать раздел и все.

С Android такое не прокатит по многим причинам, основная причина, что Транснациональной корпорации — такой бизнес не выгоден и понять их можно.
у альтернативных решений есть свои проблемы

И 'всюду' навязано мнение, что Root — это уязвимость/плохо/компрометация (Гугл с задачей по перестройке сознания масс справился хорошо).
Больше половины статьи — лишнее. Внедряем агента прямо в ядро. Запускаем через usermode_helper, из псевдо-файла (мы же ядро!).

Рассмотрим другую ситуацию. Телефон не разблокирован. Производитель забил на обновления. Баги копятся и множатся. Установив приложение из GooglePlay уже существует риск нарваться на малварь, которая поднимет себе права до root через эксплоит.

Кроме того открываются векторы атаки через RCE. Вплоть до 0-click RCE, когда от пользователя вообще ничего не зависит. И единственный способ этого недопустить — это альтернативная сборка с фиксами. Ну или смена всего телефона на новый.

Существует (теоретически) прекрасный способ избежать всех вышеописанных проблем. Сделать возможной установку пользовательских ключей. Примерно таким же образом, каким сейчас происходит разблокировка (заметим, ещё не создано ни одной малвари, которая способна была бы самостоятельно разблокировать телефон. Это почти невозможно. По целому ряду причин).

Именно полноценная установка, а не прописывание в vbmeta. С прожиганием альтернативы во фьюзы, и проверкой всей цепочки. Это всё ещё не даст пользователю доступ в TrustZone, а значит не угрожает DRM.

Осталось только заставить производителей реализвать такую возможность. Право на безопасные EOL обновления. (Типа права на ремонт.)

>> а моём стареньком смартфоне с android 9

что ж это за старенький смартфон такой? 9ка это конец 2018 года ЕМНИП. Т.е. смартфону должен быть год-полтора.

Спасибо! Я пока не достиг кунфу для внедрения в ядро, но может быть разберусь в этом в будущем. Читал что в начале 2010-х существовали зловреды которые внедряли свой модуль ядра и организовывали свою работу через него.


Согласен насчёт того что часто альтернативные сборки решаютв ситуациях когда вендор забросил девайс. Например Xiaomi mi4 вендор забросил, не соврать бы, на android 6, а LineageOS поддерживают его аж до 16 версии (android 9), и всё это силами энтузиастов.


Насколько я понимаю, user-settable root of trust даёт всё то же что и полноценная ОС с embedded root of trust. Ну, только желтую предупреждающую плашку показывает на 10 секунд при запуске. Есть какие-то подводные камни? Мне кажется главный головняк с «желтым» загрузчиком — это собирать обновления руками.


Наверное я употребил слово «старенький» с оглядкой на темпы выхода новых версий ОС. Девайс — Huawei honor 9, в 2018 году брал

Разница в том, что user-settable root of trust даёт только частичный контроль над разделами (vbmeta и дальше) и телефон можно сбросить до заводских из любого состояния, так как загрузчик по-прежнему будет подписан ключом производителя. Использование своего первого в цепочке ключа даёт полный контроль, но это должно быть предусмотрено аппаратно, сейчас он прошивается в read only на заводе, иначе вся эта схема не имела бы смысла.

Справедливо. Никакой свой код в первичном загрузчике и в том что работает в ARM TrustZone без embedded ключа запустить не получится, разумеется.


Тем не менее «желтого» состояния достаточно чтобы при физическом доступе нельзя было загрузить рековери образ или поменять что-либо в read-only разделах.

Достаточно — да, но имея возможность редактировать и загрузчик, можно вообще отключить или поменять команды записи разделов на свои, даже если он разблокирован. Плюс не будет жёлтого предупреждения 10 сек при каждой загрузке.
в TrustZone даже с ключом не получится. Код должен быть сверху подписан ещё и сертификатом производителя чипов. По-крайней мере у Qualcomm теперь так, с ~2017 года.
НЛО прилетело и опубликовало эту надпись здесь

На мой asus обновления безопасности пока прилетают, третий год после покупки идёт.

Мой с 9 андроидом уже более 2х лет используется. Причём телефон мог выйти до релиза 9, а затем обновиться.

Варианты с прожиганием фьюзов тоже есть. Ищите модель, у которой в подписях тестовые ключи (строки “General use test key” в сертификатах). Не имею свежей статистики, но точно видел такое в нескольких моделях BQ на MSM8937. Можно одним махом скачать какой-нибудь «сборник firehose загрузчиков под разные модели» (есть такие) и позаглядывать им в подписи на предмет всё того же “General use test key” (либо полного отсутствия подписей).

То есть можно одноразово прошить свои ключи после тестовых? Интересно.

Если уже что-то записано во фьюзы, то нельзя. Лет 5 назад еще были телефоны с невключенным SecureBoot и чистыми фьюзами под ключи. Сейчас таких практически нет.

Там фьюзы даны с запасом в чипе, для различных целей

Где test key — там не настраивали secure boot и фьюзы пустые (при сборке в любом случае всё подписывается, какой-то ключ должен быть, вот по умолчанию этот тестовый и генерируется, но во фьюзы он сам не попадёт, для этого нужно в явном виде сгенерировать и прошить образ fuseblower). Однако, как уже написал vm03, сейчас такого совсем мало (Qualcomm активно давил на лицензиантов чтобы те не забывали включать secure boot), но и с user-installable ROT, как пишут, вариантов немного. Хотя есть ещё не-Qualcomm платформы, где с secure boot бардак (UniSoC в Alcatel например), но то на любителя :)

что ж это за старенький смартфон такой? 9ка это конец 2018 года ЕМНИП. Т.е. смартфону должен быть год-полтора.
Ну вот у меня nexus 5 2013 года. К нему есть Lineage на базе 10(!) андроида. Не знаю, на сколько она ей там хорошо живется, не проверял. У меня стоит на базе 8го. Вполне нормально работает.
Ух, ну и мясо. Образ ramdisk с ядром — это vendor, или что-то ещё? В любом случае, на первый взгляд — не проблема прошивать его через fastboot, если паранойя шепчет.

Ramdisk лежит в boot разделе, рядом с ядром. Они загружаются самыми первыми и стартуют init — основной процесс загрузки системы (тот что с анимацией загрузки)

Производители телефона могли бы сделать возможность пользователю установить пароль на режим отладки в параметрах разработчика.
Разблокировал параметры разработчика, включил режим отладки — система просит установить пароль. Теперь при подключении устройства в режиме загрузки надо ввести пароль.
Таким образом пользователи могут получить рут и защищены от установки бэкдоров.

Если не ошибаюсь, сейчас для запуска режима отладки нужно вводить код разблокировки. Проблема в том что это тот же самый код разблокировки, которым открывается экран после того как смартфон вышел из режима сна. Если злоумышленник знает его, то и adb запустит.


Тут ключевая мысль всё таки в разблокированном загрузчике. При таком подходе заходить в режим отладки не обязательно чтобы подкинуть в систему проблем

Несколько критических замечаний по поводу статьи и позиции автора.

Начнём с того, что если у вас нет root прав на устройстве, то вы не являетесь его хозяином. Это нужно чётко понимать. Устраивает вас ошейник (а без root прав это именно ошейник и ничто иное) или нет — решать вам.

Посыл «современный смартфон защищён» является так называемой ложной альтернативой. Вам продают идею о защите от гипотетического злоумышленника и его возможных действий в будущем, уже сейчас осуществляя полный доступ к вашим данным и всем вашим действиям на устройстве (конечно же «для вашего блага»).

Ну и здравый смысл подсказывает, что в любой экстремальной ситуации не смартфон, а вы являетесь слабым звеном — вы сами отдадите и смартфон и любые пароли к нему.

И последнее: хранить критические данные на «пластмассовом обмылочке» который вы всегда и везде носите с собой — это не лучшая идея в принципе и если вы ещё этого не поняли, то вам нужно ещё немного поразмышлять на эту тему.

Я очень ценю и уважаю приватность и желаю чтобы большинство устройств могли обеспечить её на высочайшем уровне. Я очень люблю кастомные прошивки, довольно много их ковырял и подпиливал под себя, я считаю очень важным их существование и бесконечно благодарен сообществу, которое их развивает. Я как никто другой понимаю то о чем вы говорите, иначе этой статьи просто не появилось бы. Я согласен с вами, просто суть статьи немного не в этом.


Суть в том что в интернете полно статей которые рассказывают про root и альтернативные прошивки, но не рассказывают про обратную сторону их наличия на устройстве. Многие люди насмотревшись на громкие лозунги и красивые картинки с «мужчиной в масочке с усиками» с радостью освобождают свой смартфон, но с точки зренич довольно популярно модели угроз (физическое изъятие) делают его намного более уязвимым чем он был до освобождения. Посыл статьи — рассмотреть ситуацию со всех сторон и дать понимание о том что у освобождения есть минусы, о которых нужно помнить чтобы не создать себе лишних проблем

Тут трудно не согласиться — всё нужно делать с умом и понимая, что ты делаешь — в том числе и освобождать своё устройство.

Но если у тебя хватило понимания необходимости освобождения и квалификации, чтобы установить альтернативную прошивку — то уж возможные риски разблокировки загрузчика для тебя должны быть очевидны.
НЛО прилетело и опубликовало эту надпись здесь
Какая квалификация, говорите? :) Прикиньте какой процент из владельцев смартфонов сможет установить альтернативную прошивку. На мой взгляд это 0,0000000001% (да и то, похоже, я слишком оптимистичен) — так и представляю себе домохозяйку с инструкцией «… а теперь закройте ADB и запустите TWRP через USB». Смешно…
Ну это зависит от того, каким языком написана инструкция. Если предложение «запустите TWRP через USB» немного распространить, то всё будет понятно даже полному чайнику.
Я тут 7млрд умножил на ваш процент, получилось 0.007 человек.
Я тут 7млрд умножил на ваш процент, получилось 0.007 человек.

Положение вещей ещё хуже, чем я думал :)
НЛО прилетело и опубликовало эту надпись здесь
примерно 2,5 миллиона человек, которые смогли.

Тут народ сравнивает с 7-ю миллиардами — соотношение явно не в нашу пользу. :)
НЛО прилетело и опубликовало эту надпись здесь
если у вас нет root прав на устройстве, то вы не являетесь его хозяином

Смелое утверждение. Что именно подразумевается под «являться хозяином» и «не являться хозяином»? Каким образом предоставление устройства as is, без полного доступа к системе, лишает вас статуса его хозяина? Устройство поставляется как изделие с некими потребительскими свойствами, и root-доступ в их число не входит. Вы можете самостоятельно увеличить число потребительских свойств, но это уже ваше личное дело. Например, двигатель современного автомобиля не позволяет вам, как раньше на Жигулях, в гараже расточить цилиндры или внести ещё какие-нибудь подобные изменения в его низкоуровневую конструкцию, но это же не значит, что автомобиль вам не принадлежит?

Продолжая логику: если корпус устройства запаян и вы не можете его развинтить, то вы не являетесь его хозяином.
НЛО прилетело и опубликовало эту надпись здесь
Каким образом предоставление устройства as is, без полного доступа к системе, лишает вас статуса его хозяина?

То, что не я(владелец) решаю какое ПО запускать на моем компьютере(смартфон это ж тоже компьютер). А производитель решает, какое ПО я могу запустить.


Еще одна(пусть и немного кривая) аналогия из мира авто. Это как если бы производитель авто указывал мне, кого я могу везти и в своей машине и кому передать руль. Современные смартфоны это как машины на которых можно перевозить пассажиров только из одобренного производителям списка, а управлять машиной может только водитель с разрешением от производителя машины.

>под «являться хозяином» и «не являться хозяином»?
Как минимум знать что делает ваш телефон и возможность управлять им.
>но это же не значит, что автомобиль вам не принадлежит?
А теперь представьте, что при покупке в салоне вы обязаны подписать договор (иначе автомобиль вам просто не продадут) по условиям которого: а) автомобиль может уехать в любое место в любое время не спрашивая хозяина б) свойства автомобиля, количество кресел, наличие руля, кондиционеров и подлокотников может быть изменено производителем в любую секунду не уведомляя вас об этом в) производитель автомобиля и некие третьи лица получают полный 24/7 доступ ко всему, что происходит внутри автомобиля с помощью 10 установленных веб-камер и 20 микрофонов г) так же вы обязаны просматривать рекламу на лобовом стекле.
Именно это сейчас представляют из себя смартфоны без рута, если проводить аналогию с авто, а не стачивание гаек на цилиндрах. Да, у вас в руках есть некая болванка с набором функций компьютера, но по решению левой пятки гугла/эппла эта болванка через запушенный ими в фоне апдейт может превратиться в кирпич.

Например я в audi не могу добавить свежую карту - автомобиль её не принимает. т.к. "закончилась лицензия". Производитель "бесплатно" разрешил 5 обновлений и всё. Хотя законы РФ считают, что я собственник авто.

У меня по прочтению появилась папа вопросов:


  1. Пароль в twrp сможет предотвратить инъекцию?
  2. Может ли теоретически сам магиск предоставлять дополнительную защиту от инъекции чужого когда, как написано в статье?

Вообще было предельно понятно, что разблокировка позволяет делать с устройством практически все, если его можно взять в руки. Но тут что на что меняем, имхо рут и возможность удаления всякого говна от производителя гораздо лучше гипотетической потери аппарата с личными данными, ибо эти данные есть не на каждом аппарате, а вот приложения — везде

  1. К сожалению нет. Именно поэтому в официальную TWRP и не вводят эту функцию. Разблокированный загрузчик позволит просто проигнорировать запароленную TWRP и загрузить вместо неё свою, незапароленную через fastboot boot img.img
  2. Теоретически мы сможем также вырезать эти проверки из исходников magisk.

Думаю каждый решает сам для себя что важнее. Опять же, на пикселях и ванплюсах мы можем прописать свои ключи для проверки avb и эта атака работать не будет

Как минимум я сразу увижу, что TWRP перепрошили, когда мне вернут телефон.
Потому что вместо моего пароля там будет ничего или чужой пароль.
Соль в том, что как раз ничего с родным TWRP не будет сделано — запущенный через fastboot TWRP будет временный (в RAM), при перезагрузке он пропадёт.

Верно. Условному атакующему нет нужды прошивать свой TWRP, достаточно загрузиться с ним. Однако, как я упоминал в статье, зайдя в TWRP вы можете сравнить хэши важных системных разделов и таким образом понять что они были модифицированы

Хорошие описание безопасности андроида(не без неточностей для упрощения), но вот это резануло:


LineageOS, не включают в пакеты обновления ядро,

LineageOS всегда включает в себя ядро и обновляет его при каждом обновление. Это одна из причин почему LineageOS безопаснее стока в реальной эксплуатации, большинство мантейнеров оперативно закрывают уязвимости в ядре.


Ну и непонятно, зачем столько возьни(что-то пишем в system, патчим политики selinux и тд), если вы меняете boot. Добовляете свой код в ядро и ваш код выполнятется на уровне выше, чем весь андроид, делайте что хотите.


Ну и в целом ситуация когда безопасность современных смартфонов завязана на ключ производителя устройства и владельцем не контролируется мне очень не нравится, производитель может пихать в прошивку любую блотварь, а владелец устройства делать нечего не может, кроме как ставить дополнительное по.
На своём ноутбуке(и десктопе)(и таких пока вроде большинство) я могу добавить свои ключи для SecureBoot, и даже удалить все предустановленные ключи, оставив только свои.
На смартфонах удалить ключи производителя удалить нельзя негде, на очень редких можно добавить свой avb ключ(и то это будет yellow режим), смартфонов где можно сделать unlock становится все меньше. При этом на современных квалкомах, прошивку модема(которая работает с большими привелегиями, чем андроид) можно запустить только подписанную производителем.
Ну и кроме блотвари, производители умудряются делать такие дырищи в своих прошивках…
А всякое банковское ПО считает эти 5 лет необновленные с кучей известных и неизвестных дыр безопасными, а кастом с исправлениями всех известных уязвимостей настолько опасным, что отказываюися работать.

производитель может пихать в прошивку любую блотварь

Не «производитель может пихать в прошивку любую блотварь», а сама прошивка является одной большой «блотварью».

Спасибо за отзыв!


Я пока не настолько хорошо разбираюсь в android чтобы подпилить ядро под свои нужды, может быть получится в дальнейшем развить тему статьи в сторону модификации ядра, но пока могу только так. Разумеется, злоумышленнику выгоднее работать напрямую из ядра, так меньше торчит флагов компрометации в системе.


Ситуация с невозможностью контролировать устройства это действительно проблема, думаю, последний десяток лет уже. В андроиде всё особенно тяжело, т.к. даже на альтернативной сборке и со своими avb ключами остаётся целая куча пропиетарных компонентов от производителя без оторых устройство просто не сможет работать.


Насчёт поставки ядра с LineageOS — не знал. На мои устройства приходят обновления только system и vendor образов. Можете пожалуйста ткнуть меня в ссылку где это описано? Исправлю в тексте статьи

Я пока не настолько хорошо разбираюсь в android чтобы подпилить ядро под свои нужды

С учетом, что ядро "универсальнее", чем юзерспейс андроида, думаю найти готовую "вредоносную нагрузку" для ядра будет не сложнее.


На мои устройства приходят обновления только system и vendor образов

Берем свежие lineage-17.1-20210202-nightly-dumpling-signed.zip и lineage-17.1-20210204-nightly-sagit-signed.zip с download.lineageos.org и смотрим что там:


$ unzip -l lineage-17.1-20210204-nightly-sagit-signed.zip 
Archive:  lineage-17.1-20210204-nightly-sagit-signed.zip
signed by SignApk
  Length      Date    Time    Name
---------  ---------- -----   ----
      299  01-01-2009 00:00   META-INF/com/android/metadata
     5208  01-01-2009 00:00   compatibility.zip
552698230  01-01-2009 00:00   system.new.dat.br
        0  01-01-2009 00:00   system.patch.dat
131506390  01-01-2009 00:00   vendor.new.dat.br
        0  01-01-2009 00:00   vendor.patch.dat
  2093472  01-01-2009 00:00   META-INF/com/google/android/update-binary
     1630  01-01-2009 00:00   META-INF/com/google/android/updater-script
 15396864  01-01-2009 00:00   boot.img
     1028  01-01-2009 00:00   install/bin/backuptool.functions
     2233  01-01-2009 00:00   install/bin/backuptool.sh
     7632  01-01-2009 00:00   system.transfer.list
     1870  01-01-2009 00:00   vendor.transfer.list
     1342  01-01-2009 00:00   META-INF/com/android/otacert
---------                     -------
701716198                     14 files

unzip -l lineage-17.1-20210202-nightly-dumpling-signed.zip
Archive:  lineage-17.1-20210202-nightly-dumpling-signed.zip
signed by SignApk
...
 18523432  01-01-2009 00:00   boot.img
...

В обоих прошивках присутствует boot.img. Ну что бы убедится, что он не просто лежит, смотрим META-INF/com/google/android/updater-script и там есть:


package_extract_file("boot.img", "/dev/block/bootdevice/by-name/boot");

То есть boot вполне себе прошивается при установке этих zip.


Ну и вот исходники из которых ядро и рамдиск собирается при каждой сборке (вот именно прям из этих на github)


https://github.com/LineageOS/android_kernel_xiaomi_msm8998
https://github.com/LineageOS/android_device_xiaomi_msm8998-common/tree/lineage-17.1/rootdir


Тут конечно не все, что попадает в рамдиск, но если захотите поэксперементировать с собственным boot.img будет полезно.


остаётся целая куча пропиетарных компонентов

Меня сейчас больше даже не это (это тоже, но меньше, сейчас систему без блобов сложно найти) бесит, а то что производитель, а не я решает что можно запустить на купленном мной устройстве. Я например не могу запустить, пусть с блобами, но свою прошивку модема. Вот есть например Яндекс.Телефон, на поддержку которого Яндекс забил, и есть в нем бага в прошивке модема, которая приводит к зависанию модема при работе с Теле2. И вот на руках полностью рабочее железо, но пользоваться полноценно им нельзя. И нечего с этим не сделаешь, запустить "модем" можно только подписанный производителем.


PS: Не знаю не одного устройство на которое бы LineageOS собиралась бы без boot. И одно из обязательных требований для включения устройства в "официальные сборки" LineageOS, это сборка ядра из исходного кода https://github.com/LineageOS/charter/blob/master/device-support-requirements.md#kernel

О, значит мой косяк, спасибо большое за замечание. Исправлю как доберусь до компьютера

Безопасность системы соответствует безопасности самого слабого звена, чем является пользователь и SIM-карта.
Изоляция приложений обходится внедрением кода в сами приложения. Например, если в приложении есть логин или реклама от Фейсбука или Гугла, то вся активность пользователя сливается в аналитику. Сбор аналитики от Фейсбука даже нельзя отключить.
НЛО прилетело и опубликовало эту надпись здесь

Это самый простой вариант из возможных, но самый «не тру» для настоящих энтузиастов кастомного android. Если скомбинировать его со способами выключения предустановленных системных приложений описанных в недавней статье, то вполне может получиться неплохо.


У меня на одном из старых телефонов не только весь подобный хлам был установлен, но даже прошиты уникальные UUID устройства для трекинга для facebook, yandex и сбера. Прошиты прямо build.prop, прямо в /system, прямо на этапе сборки системы производителем. Из можно было увидеть через вызов getprop.


З.Ы. Дата для добровольно принудительного внедрения отечественного ПО выбрана таки знаменательна

НЛО прилетело и опубликовало эту надпись здесь
Если вы про оперативную память, то см. тут, отключённые таким образом приложения не будут запускаться и расходовать оперативную память.

Если вы про flash-память, то неясно, как вам поможет удаление предустановленных приложений. Они предустанавливаются в /system, а не в /data, от их удаления у вас места не прибавится (если только вы не хотите что-то своё напихать в /system, но не думаю, что вы этого хотите).
НЛО прилетело и опубликовало эту надпись здесь

С самого рожения андроида /system — отдельный readonly раздел. Собственно поэтому factory reset сводится к глупому форматированию /data, ни системные, ни тем более загрузочные файлы не страдают (и поэтому ресет не спасет от полученных через рут червей).

Существует раздел super. Под него зарезервировано какое-то место в хранилище, например 10 ГБ. В нём находятся system, vendor и product. И сколько бы там не удалял, место в userdata не прибавится, потому что под этот раздел тоже заранее выделено сколько-то ГБ из всей памяти. Я очень плохо объясняю, но существует разметка памяти, и под каждый раздел заранее выделено сколько-то памяти.
Это dynamic partitions. Насколько я понимаю, такой подход нужен для удобного изменения размеров разделов, но пока что он не так распространён. Тем не менее, даже при старом подходе объём занятого system никак не влияет на объём userdata
Это как на ПК, где у вас на физическом диске созданы два раздела. Если вы что-то удалите с первого раздела, то на втором места не прибавится (если только вы не ужмёте один раздел, присобачив высвобожденное место к другому, но я специально оговорился, что в Android вы таким вряд ли станете заниматься).
А, аналога hosts-файла в Виндовз, в Андроиде нет (не рутованном)? Я ни разу не программист, поэтому тапками не нужно, если что.)

Есть hosts, но в read-only разделе.

Хорошая статья с кучей технических подробностей, однако тема очевидная. Имея разблокированный загрузчик, всегда можно прошить кастомное рекавери, а через него zip с любым содержимым. Тем не менее, не думаю, что у пограничников или полицейских есть специалисты, способные сделать это, так что риск небольшой.
Лично я не представляю, как можно пользоваться телефоном без рут-прав, когда ты по сути не хозяин своему смартфону.


Вопрос к знатокам — можно ли настроить так, чтобы способ расшифровки телефона отличался от способа разблокировки? Ну например, при первом включении вводим сложный пароль, который не получится подобрать, а при разблокировке экрана простой графический ключ?

Лично я не представляю, как можно пользоваться телефоном без рут-прав, когда ты по сути не хозяин своему смартфону.

Мне например не нужны root права на андроиде в их "классическом понимании", то есть мне не нужны приложение android запущенные c uid 0. Но я хочу запускать на смартфоне, то что хочу я владелец, а не его производитель.


можно ли настроить так, чтобы способ расшифровки телефона отличался от способа разблокировки?

Стандартно пин(или пароль) для расшифровки и разблокировки экрана одинаковый, и не видел, что бы где-то было сделано по другому. Но технически это сделать очень легко (пару файлов по пять строк на вскидку поправить), поэтому подозреваю, что есть веские доводы почему это бесполезно.

Плюсану, хоть меня тут могут и закидать помидорами. Разумеется, это вопрос личных предпочтений, но для меня единственный инструмент работающий от рута, который я прям уважаю и никак не могу без него если всё-таки накатываю что-то на устройство это afwall, потому что это просто обёртка над iptables (хотя netguard тоже неплох если нужно обрубить доступ в сеть приложениям которым это явно не требуется для работы). Ещё раз, это ИМХО, но я могу для всех остальных задач использовать не требующие рута приложения

Спасибо! Тема действительно очевидная, но почему-то довольно непопулярная. Я хотел привлечь внимание к тому что пользуясь рутом или альтернативной сборкой ОС нужно помнить о дополнительных возможностях которые появляются у атакующего с физическим доступом. Предупрежден — значит вооружен

Тем не менее, не думаю, что у пограничников или полицейских есть специалисты, способные сделать это, так что риск небольшой.

Забыл добавить такую мысль — разблокировкой загрузчиков занимается ничтожно малая часть пользователей смартфонов, так что вряд-ли где-то будут проверять каждый смартфон на предмет такого доступа, даже если будет техническая возможность.

Вопрос к знатокам — можно ли настроить так, чтобы способ расшифровки телефона отличался от способа разблокировки? Ну например, при первом включении вводим сложный пароль, который не получится подобрать, а при разблокировке экрана простой графический ключ?

В LineageOS это делается одной командой в терминале (при наличии прав суперпользователя)

Для остальных прошивок есть github.com/nelenkov/cryptfs-password-manager

А команду подскажете?

vdc cryptfs changepw TYPEOFNEWPASSWORD OLDPASSWORD NEWPASSWORD

Where type of password can be:

password
pin
pattern


TYPEOFNEWPASSWORD — какую клавиатуру предоставлять при вводе пароля (полноценную, цифровую, либо графический ключ)
если выбрать pin, но задать пароль, содержащий не только цифры, то ввести его при загрузке вы не сможете :)
OLDPASSWORD — текущий пароль (обычно совпадает с паролем блокировки экрана)

перед этим следует, естественно, выполнить команду su
терминал сгодится любой, хоть встроенный в LOS, хоть из маркета

Спасибо!
А если стоит графический ключ, что вводить в OLDPASSWORD?
И нет ли риска сделать так, что потом не получится ввести этот пароль?

Можно попробовать утилиту, там в комментах народ отписывался, что смог подружить пароль при запуске и графический ключ для разблокировки.

К тому же, утилита имеет больше «защит от дурака», чем команда в терминале.
Вымораживает невозможность использовать ОС и устройство в тех рамках каких я хочу без танцев с бубном. Вот условно ноутбук. Я могу установить туда любой линукс или даже Windows XP, а то и хакинтош. Права итп у меня под контролем. Корпорации просто охренели, а производители железа им подмахивают. Как было раньше — есть независимые разработчики, они распространяют программы либо независимо, либо через какие-то сторы. Я покупаю отдельно операционку и могу купить любое железо. Сейчас же мне нужно уметь программировать на Андроид, чтобы что-то сделать в нем как я хочу. Так есть и вторая проблема — невозможность нормально обновить даже на новую версию операционки, без глубоких знаний.

Вот у меня есть древний Самсунг аж 2012 года i9260, на нем древний Андроид 4.1 что-ли. Он валялся у меня с 2015го. Неделю назад я расчехлил его и обнаружил, что не могу поставить на него даже актуальный 2gis — устанавливается что-то старое, без актуальных организаций. А куча приложений в сторе так вообще не отображается. Андроид видите-ли старый. Контроля над этой ситуацией у меня фактически нет. Я не профессионал какой-то. Телефон можно просто в мусор отправлять, потому-что на нем только мессенджеры актуальные запускаются, а из браузеров только китайский UCbrowser новый. C компьютерным железом это просто дикость бы была (ну кроме техники Apple).

Жду исков от Евросоюза.
Вот условно ноутбук. Я могу установить туда любой линукс или даже Windows XP, а то и хакинтош

Вроде было несколько ноутов (но и то это большая редкость), где можно запустить только ОС подписанную Microsoft и нет возможности управлять ключами SecureBoot. Но и то, я не слышал такого, что бы например на ноуте HP, можно было запустить только Windows от HP и никакую другую (даже на макбуках можно запускать и linux и windows). А на смартафонах это не то что норма, это поголовно сейчас, производитель, а не владелец решает, что можно запустить.

Упомянутые вами ноуты — это, видимо, серия Microsoft Surface. Там всё залочено по самые помидоры. Хотя, я проверил сейчас ArchWiki, на Surface Pro 3 и Surface Book 2 установка описана.
Что же касается макбуков, то после примерно 2015 года там всё нетривиально, если вообще возможно.
Были такие ноутбуки Sony Vaio, где еще во времена XP запустить ОС не из образа производителя было довольно затруднительно по сравнению с другими ноутбуками (почему уже не помню, кажется проблема была в каких-то специфических драйверах, которые скачать было нельзя, а без них ничего не работало).
даже если secureboot включен, ms подписывает загрузчики, если объяснишь зачем.

Боюсь чтобы выбраться из этой ситуации нам нужно куда больше популяризировать и развивать OpenHardware. В ближайшее время вряд ли что-то фундаментально изменится

свободы, которую android предоставляет пользователям, однако не все распоряжаются ей правильно


Власть машин пришла. Obey our iron will you filthy human.

Статья весьма познавательна в качестве обзора систем безопасности android, а за одно — и некоторые сведения про работу magisk. Автору огромный респект, хабр — торт!


При этом остаётся интересным момент — против чего именно все эти ухищрения со стороны Google? Во-первых, если данные остаются в расшифрованном виде после первой разблокировки — это же почти ни о чём (при изъятии устройства успеть его выключить?). Во-вторых — физический доступ к устройству не похож на типичный сценарий взлома для >99% пользователей, а тем, кому его стоит опасаться, всё равно нужно придерживаться правила "физический доступ к устройству означает его компрометирование".

Спасибо! Это много значит для меня. Хабр для меня всегда был ресурсом где люди делятся по настоящему интересными техническими статьями и любят погружаться в детали. Я постарался соответсвовать этому.


Данные действительно остаются расшифрованными всегда после первой разблокировки. Это может быть опасно если включён режим отладки и adb. В этом случае можно вытащить файлы из общего хранилища которое всегда доступно через adb shell. К слову, у наших коллег из iOS операционная система уничтожает ключи в памяти спустя некоторое время неактивности, а при вводе кода разблокировки расшифровка файловой системы будет произведена заново. Может быть и нам подобное завезут в грядущих обновлениях. Вообще, вход в систему нам защищает необходимость ввести код разблокировки, разблокировкой системы управляет сервис gatekeeper, который работает через аппаратный TEE, и запись флагов в RPMB. Gatekeeper ведёт счётчик неправильных последовательно введённых кодов разблокировки и увеличивает таймауты между попытками ввода, обмануть их ни через перезагрузки устройства, ни через брутфорс через рекавери не получится, всё реализовано очень надёжно. Я для интереса попробовал и не смог найти никаких подходов. Терморектальный криптоанализ в данном случае не рассматриваем.


Физический доступ действительно нечастый сценарий атаки на устройство, но данные статистики в статье на хакере которую я привёл пугают. Вполне возможно что через лет 10 досмотр смартфона на границе станет такой же стандартной процедурой, как досмотр багажа металлоискателем. То ли ещё будет.


Основной посыл статьи был не столько про реальность сценарий атаки, сколько про то что о пользе разблокировки загрузчика пишут много, а о минусах — мало. Хотелось разобрать ситуацию и с непопулярной точки зрения

Физический доступ действительно нечастый сценарий атаки на устройство, но данные статистики в статье на хакере которую я привёл пугают. Вполне возможно что через лет 10 досмотр смартфона на границе станет такой же стандартной процедурой, как досмотр багажа металлоискателем. То ли ещё будет.

Так в этом случае, как раз наоборот заблокированный загрузчик не дает возможность сделать точную копию критических данных.
Дабы положить эту копию в зашифрованный контейнер и потом добавить стеганографию, ну и например обозвать этот криптоконтейнер, как видеофайл «любимые кошечки». Или скопировать копию в облако.
А на телефоне минимальная копия с официальными контактами.
Нам нечего скрывать=).

А заблокированный загрузчик вынуждает все критические данные хранить на телефоне.

Очистка ключей после блокировки уже есть как минимум на Huawei и Samsung, у обоих зовётся SDP, принцип работы — один в один как в iOS (очищаемый симметричный ключ + ECDH ключ для файлов, создаваемых после блокировки). У Samsung вот описание есть: https://docs.samsungknox.com/admin/whitepaper/kpe/sensitive-data-protection.htm
Вот только вопрос — сколько приложений умеют этим пользоваться? В общем случае нельзя просто очищать "традиционный" CE-ключ (приложения, не готовые к такому, упадут), в API вводится отдельный тип хранилища, и общего стандарта, как понимаю, пока нет.

О, интересно, не знал о таком. Может потихоньку это переползёт и в основной андроид.

Самсунги вообще крепко заморачиваются с безопасностью, и для многих нововведений являются локомотивом. Я читал про то что они используют отдельные расширения ядра для защиты от модификации и в установщике magisk даже есть отдельные патчи именно под самсунги, как раз видимо для подобных случаев. Именно с подачи самсунга в android был введён SELinux, Google перетащили его в основную кодовую базу именно посмотрев на самсунг
Автор сообщает нам секрет им. Полишинеля: при попадании девайса в руки злоумышленника тот может приобрести полный контроль над устройством. И ставит якобы перед сложным выбором: пользоваться гарантированно небезопасным устройством, к которому имеют удаленный доступ все, кому не лень, либо возможно в том случае, когда Луна находится в Козероге владелец устройства представляет интерес для злоумышленников, и они получают физический доступ к его устройству, и они могут поставить бэкдор, и владелец этого не заметит, и он действительно хранит на своем устройстве интересующие злоумышленников данные… Дайте подумать… рут, конечно рут!
Информация интересная и полезная, но use case ИМХО надуман.

Спасибо. Ну, в некотором смысле наверное оно так. Все знают что разблокированный загрузчик несёт проблемы, но кейсов которые бы поясняли «на пальцах» что именно можно сделать в этом случае совсем немного

Мне представляется более интригующим кейс, что можно сделать с разблокированным загрузчиком удаленно, т.е. без целевой атаки на конкретный экземпляр устройства. А при физическом доступе злоумышленник может и сам рут поставить, и для чистоты эксперимента удалить его после своих черных дел — большинство пользователей и не заметит, что рут был.

Теоретически, разблокированный загрузчик даёт преимущества и удалённому злоумышленнику. Если тот сможет получить root локальным эксплоитом (такое бывает очень редко, но всё таки), то он сможет вносить в систему изменения не боясь вызвать срабатывание verified boot и окирпичивания устройства, но всё же максимум возможностей получает локальный атакующий с физическим доступом к устройству

Автору спасибо за статью, интересная тема, сам являюсь обладателем смартфона от компании xiaomi, с разблокированным загрузчиком и мода ос от xiaomi.eu. Давно интересовал вопрос безопасности такой сборки и как оказалось не зря, вектор атаки понятен и очевиден.


Однако хочу предложить ещё один вариант решения, в копилочку. У меня на устройстве после обновления ос штатным приложением всегда остаётся полный образ последнего обновления, в разделе юзердата, с проверенным мд5, так что теперь, если кто-то изымет у меня утройство, сразу после возврата, грузимся в тврп и шьем последнее обновление, и вуаля, после загрузки у нас чистая система и можно без опаски разблокировать телефон. (появляется вектор атаки на тврп и его модификации, чтобы он в конце дошивал мидлварь, но в такой связке может помочь пароль на тврп)


Естественно перед тем как отдать телефон погранцам, зажимаем кнопку выключения, чтобы телефон ушел в ребут и не получилось считать ключи из памяти. Ну и выключаем отладку usb и тд

в такой связке может помочь пароль на тврп

Как уже выше неоднократно отметили — не поможет, ибо банальный fastboot через USB загрузит любой кастомный тврп без всяких паролей

Сразу видно, то вы не внимательно читали мой комментарий, я предлагаю комплекс мер, то есть, если грузится тврп без пароля, то аппарат скомпрометирован, не включаем до прошивки нового тврп, если тврп с вашим паролем, то накатываем систему из образа с раздела юзердата.

Между прочим в моём TWRP установка пароля в принципе отсутствует. Не подскажете откуда её взять?


Хотя в любом случае по-моему проще просто перепрошивать тврп каждый раз, а то иначе полумеры какие-то.

Пароль не спасёт, судя по тому, что написано в комментариях выше: в режиме fastboot, как я понял, загрущчик грузится через USB сразу в ОЗУ. То есть Ваш TWRP с паролем не пострадает. Фактически, единственный вариант обнаружить вторжение — подсчёт кэша разделов и сравнение с эталонными. Ну это я так понял, сам всё это не проворачивал.

Спасибо! Похожий трюк с сохранением последней рабочей конфигурации делает, например, сам magisk. Только он так сохраняет лишь boot и dtb* разделы. При удалении — шьёт их на место чтобы всё было как на немодифицированной системе.


А ещё так делает сам андроид. Механизм который вы описываете очень похож на систему обновлений с A/B разделами, которая есть на большинстве современных устройств. Там разделы дублируются и обновление устанавливается только на один «слот» из двух, а второй остаётся неизменным, чтобы иметь возможность откатиться на него в случае если обновление поломает работу системы.


Теоретически, мы можем «откатиться» на резервный слот после того как устройство побывало у злоумышленников, однако злоумышленник может накатить нагрузку в оба слота сразу

Я может не правильно выразился, но в образе лежит полная система, 2.8гб в моем случае, мы ее накатываем после того как аппарат побывал у кого-то "не надежного" и попадаем в рабочую и чистую систему, следующее обновление затрет второй слот "скомпроментированной системы" в слоте B. (если были скомпрометированы оба слота)


У меня так после каждого обновления magisk исчезает)))

У меня так после каждого обновления magisk исчезает)))
Надо в промежутке между установкой обновления и перезагрузкой после этого, ставить Magisk в неактивный слот (делается из Magisk Manager).
Как вариант «борьбы» с возможной установкой бэкдоров. Делаем регулярные бэкапы всей системы (через TWRP), после попадания аппарата в чужие руки полное восстановление с предварительной очисткой всей системы. По времени — 10 минут.

Да, это реально сработает. Можно проверять что хэши разделов не изменились если есть подозрения на модификации. Сменились — накатываем бэкап. К сожалению, для этого нужно выработать привычку пересчитывать хэши всех важных разделов сразу после установки обновлений

Замечательная статья, спасибо. Познавательная и интересная.
Наверное дурацкий и все же философский вопрос вертится на языке, что же, в данном случае, хуже-то с точки зрения секьюрности: такие вот свежие современные, но рутованные смартфоны с LineageOS и разблокированными загрузчиками или что половина страны все еще ходит со смартами купленными в бородатых годах (интернет, ватсап, вконтакте и Сбер работают, фоточки в инстаграм выкладываются, да и ладно). Которые до сих пор на 4х — 8х стоковых, но уже определенно устаревших версиях Андроида без каких-либо даже призрачных шансов на очередные critical security update?

Спасибо большое!


Современные устройства, на мой взгляд, однозначно будут менее подвержены разным зловредам, т.к. получают регулярные обновления безопасности. В общем-то, я не призываю отказываться от LineageOS, это отличная альтернативна стоковой прошивке для тех кто хочет большей приватности. Статья про то, что пользуясь ей нужно помнить о появлении дополнительного рода угроз и стараться не допускать попадания устройства в чужие руки

Сейчас, когда в новых телефонах будут ставить предустановленные программы в России, согласно новому закону.
Вот будет там стоять сертификат от фсб, по аналогии с казахстаном, предустановленный.
И без рута хрен выпилишь.
Так что только рут, в новых телефонах, только полная зачистка.

Честно говоря, не слышал о том что по вышеупомянутому закону планируется устанавливать дополнительные корневые сертификаты, но не удивлюсь если им очень сильно захочется попытаться это сделать.


Я видел патч для сорцов андроида, который удаляет из системного хранилища некоторые корневые сертификаты китайского происхождения, автор уверяет что они используются для МИТМов. Уверен, что если кто-то подкинет эту идею нашим органам, то она им очень понравится и они постараются её претворить в жизнь

Спасибо за статью, правда в части Magisk интересно было бы услышать еще про модификацию zygote, т.е. механизмы работы xposed и magiskhide.

Я правильно понял, что даже после первого ввода пароля при включенном шифровании памяти и отключенном usb adb, разблокированным загрузчиком, установленными всевозможными рутами и пр. злоумышленник «прямо сейчас» не получает доступа к данным, если не взломает экран блокировки?

А то что дальше по статье, как я понимаю, фиксится достаточно просто: после получения телефона обратно, нужно не разблокируя перезагрузить в свой образ twrp через fastboot, зашить свой twrp, вдруг его тоже заменили. Затем загрузиться в него, зашить заново ту же ОС, что и стояла ранее (перезапишутся /system и /boot), поставить magisk и вроде как все…
Спасибо. Да, злоумышленник получает доступ только после того как владелец сам введёт код разблокировки устройства. Без этого никак — хранилище будет зашифровано до первого ввода кода.

А то что дальше по статье, как я понимаю, фиксится достаточно просто: после получения телефона обратно, нужно не разблокируя перезагрузить в свой образ twrp через fastboot, зашить свой twrp, вдруг его тоже заменили. Затем загрузиться в него, зашить заново ту же ОС, что и стояла ранее (перезапишутся /system и /boot)

Да, такой подход решает проблему, но требует ковыряния руками, что не каждому захочется делать. Как я упоминал, суть статьи не в том, чтобы не пользоваться альтернативными сборками ОС, а в том, чтобы не забывать что их использование несёт дополнительные риски, о которых необходимо помнить.
Да, злоумышленник получает доступ только после того как владелец сам введёт код разблокировки устройства. Без этого никак — хранилище будет зашифровано до первого ввода кода

Ну и замечательно. То есть выходит по факту не все так плохо.
Даже если хранилище расшифровано предстоит как-то поломать экран блокировки (причем не перезагружая телефон), чтобы добраться до данных.
Ломать экран ему нет необходимости. Пользователь сам введёт код разблокировки. Пока система грузится, зловредный процесс уже начинает работу, он ждёт расшифровки и когда она происходит предоставляет удалённый доступ. Если устройство, например имеет установленную систему до android 8 включительно, где шифрование хранилища ещё не было обязательным, и речь идёт именно о таком устройстве, то тогда злоумышленник сразу получает доступ к данным, не дожидаясь ввода кода разблокировки
Кстати обязательное шифрование это ещё один миф, оно совсем не обязательно для запуска даже 10-11 андроида.
Qin 2 Pro без аппаратного шифрования и последний стоковый AOSP со всеми защитами, кроме шифрования, прекрасно работает. Правда он userdebug, но 9-й от производителя — user (релизный) и тоже работает без шифрования.

Требования предъявляемые к прошивке - предъявляются только для версии андроида с которой устройство выходит на рынок. Для обновлений - требований нет

Спустя больше года, вспомнил вашу статью, решил перечитать. У вас написано, что при включенной отладке ADB в состоянии "после ввода пароля" нет сложности подключить к ПК и достать данные, но что по поводу защиты самого ADB от несанкционированного доступа?

При подключении к новому ПК телефон всегда запрашивает разрешение отладки с открытым ключом ПК, пока запрос не подтвержден и если его отклонить/проигнорировать, то девайс будет висеть в состоянии "не авторизован" без доступа к нему.

Это не всегда. к примеру на redmi note 4x такой защиты ещё небыло.

Привет. Спасибо за интерес к теме. В целом да, на современных устройствах adb будет требовать подтверждения взаимной аутентификации по ключам, но я бы сказал, что оставлять открытым adb - всё равно плохая идея. Думаю что это можно обыграть, по крайней мере в части случаев.

На ум сразу пришёл как минимум один сценарий. Допустим владельцу устройства устроили "маски-шоу". В подобных ситуациях изымаются для следствия абсолютно все личные устройства в которых физически может храниться информация - компьютеры, ноутбуки, планшеты, телефоны, и т.д. Ключи adb хранятся в домашней директории пользователя (~/.android/adbkey, ~/.android/adbkey.pub). Соответственно, если получить доступ к этим директориям на машине с которой подключались, то можно их закинуть на машину атакующего и устройство будет считать что adb shell запрашивает уже знакомый компьютер. А дальше вступают в работу стандартные инструменты для форензики.

Xiaomi Redmi Note 8T. До этой статьи я плевался из-за того, что телефон до ввода пароля разблокировки ничего не принимает и никаких уведомлений не показывает. Похоже, FBE и BFU-AFU в этом устройстве тоже организованы.

Получается организованы. Начиная с android 9 это обязательное требование для получения сертификации от гугла. Думаю что на всех современных устройствах это работает, и это хорошо.

В системе существует API DirectBoot, которое позволяет запускать приложения до расшифровки хранилища. Это нужно для будильников, звонилок, и т.д, но все обычные приложения до расшифровки файловой системы работать не могут
Во всей статье, главное условие — получение злоумышленником физического доступа к устройству и root.
Но есть одно «НО», если злоумышленник (на той же границе) получил телефон в руки, кто ему мешает установить root, да займет времени чуть больше, го если процесс налажен (а возможно и автоматизирован " спецами", ведь не сами же таможенники это придумали), то процесс установки рута может так же занять считанные минуты.
Мы рассматриваем гипотетический случай когда условный пограничник получил в руки заблокированный телефон, и не прибегает к насилию для того чтобы заставить его разблокировать. Установить root можно, но зачем? Это не поможет снять информацию на месте если владелец не станет разблокировать устройство, а вот подкинуть бэкдор — другое дело. Владелец разблокирует девайс самостоятельно, а бэкдор поможет изъять данные
НЛО прилетело и опубликовало эту надпись здесь

Спасибо большое за статью!
У меня есть два вопроса:
1) Что, если мы ломаем возможность корретной работы TWRP? Разработчик OrangeFox (форк TWRP) делал такую фичу. Но! У меня только черный экран был. ADB я не проверял. И OrangeFox имеет в себе возможность установки пароля. Но при условии, что TWRP спокойно грузится из-под Fastboot и ADB в сломанном варианте работать будет… То беда.
2) Что делать, если TWRP может быть загружено без разблокировки? Или по факту это не дает возможность взлома?


И спасибо за методы защиты. Единственное, что получается последним железным вариантом защиты это написания кастомного загрузчика (aboot), в который каждый раз при загрузке надо вводить пароль как на BIOS/UEFI?


И еще.


Третий и самый сложный подход – продолжать использовать альтернативную сборку ОС, но заблокировать загрузчик используя user-settable root of trust. Это действительно сложный и затратный подход, достойный написания отдельной статьи, потому как требует самостоятельно делать сборку ОС и самостоятельно её подписывать.


Я бы с удовольствием прочитал про это. И если б была возможность, я бы попробовал сделать это у себя. Жаль, что у меня это работать вероятно не будет… Бедный мой mido)


Еще раз спасибо за статью!


P. S. Прошивка CarbonROM, которую в данный момент времени я сопровождаю, не собирает userdebug. Только user.

Ого, спасибо большое за отзыв. Я пробовал CarbonROM. Отдельный респект за user-сборки!

1. Увы, разблокированный загрузчик даёт злоумышленнику возможность не полагаться на текущее установленное рековери. Он просто загружает и использует своё.
2. В теории может, если будет подписано приватным ключом зашитым в TEE либо в avb_custom_key, но это максимально маловероятно. К тому же, наличие заблокированного загрузчика не даст загрузить систему после внесённых изменений, aboot будет падать в «red state» и откажется загружаться.

Насколько я понимаю, повлиять на aboot мы не можем, он зашивается в девайс и его целостность проверяется при загрузке ключом из TEE, мы можем начинать устраивать какие-то махинации, но только с запуска ядра, aboot работает раньше.

По поводу user-settable root of trust. Это точно возможно на пикселях, ванплюсах, и, как подсказывают камрады в комментариях, яндексофонах, на остальных — маловероятно.

 В теории может, если будет подписано приватным ключом зашитым в TEE либо в avb_custom_key, но это максимально маловероятно

В природе встречались телефоны от Xiaomi приходящие из Китая с заблокированным загрузчиком и кастомной сборкой тврп вместо стокового рекавери (иногда там ещё был кривой мод китайской прошивки с недоруссификацией). Ну и в качестве исторической справки, сейчас наверное неактуально, какое то время назад рекавери интегрировалось или в ядро, или в /system ввиду отсутствия родного раздела под него (или невозможности записи в него, ввиду закрытого загрузчика)

написания кастомного загрузчика (aboot)

Нет практически не одного современного смартфона, где вы сможете запустить свой загрузчик, SecureBoot не даст. А так у того же квалкома, исходный код загрузчика открыт, можно править.


сложный и затратный подход, достойный написания отдельной статьи, потому как требует самостоятельно делать сборку ОС и самостоятельно её подписывать.

Подписать своим ключем нет нечего сложного(по сравнению со сборкой прошивки вцелом).
https://wiki.lineageos.org/signing_builds.html

Как минимум надо производить реверс для написания загрузчика. Дело, с моей точки зрения, дико сложное (я только отдельные моменты вычленял для написания кастомного инита для Z00ED/RD). Плюс есть только один шанс зашить загрузчик, потом если хана, то хана. На сколько мне известно. Может мои знания устарели.
Но я запускал вторичный загрузчик (lk2nd), который был написан энтузиастами из Postmarket OS.
github.com/msm8953-mainline
И оно даже загрузило бут, который используется прошивкой. Вопрос в чем. А нужно ли это вообще?
И как полноценная замена стокового загрузчика оно не работает. Один человек как-то раз зашил себе lk2nd в aboot, поднял ли он устройство — без понятия, я дальше историю сообщений не читал.

Как минимум надо производить реверс для написания загрузчика.

У квалкома код загрузчика открыт, на нем и основан lk2nd. Точнее lk2nd это загрузчик поправленный, что бы работать после загрузчика. Поэтому и получилось его запустить после "родного" разлоченого, а вот заменить его SecureBoot не даст. Раньше, до повального включения SecureBoot, энтузиасты запускали собствееноручно собранный aboot.


А нужно ли это вообще?

В таком виде нет, нужна возможность запускать свой код, в том числе и загрузчик.


Плюс есть только один шанс зашить загрузчик, потом если хана, то хана.

У квалкомов есть EDL режим в котором можно перепрошить флеш почти в любом случае. Но во первых тут опять нужен firehorse-программер подписанный производителем(очень не многие его выкладывают). И второй момент, экспериментами с загрузчиками можно "попортить": фьюзы secureboot'а или antirollback'а.

Использую twrp как минимум из за бэкапов в виде nandroid backup+TitaniumBackup. Жаль что нет условного Acronis True Image, чтобы из коробки и без рута делал полноценный бэкап всего и вся без танцев с бубном.

Если у кого есть какие то рабочие альтернативы, пожелитесь пожалуйста.

Отличная статья! Спасибо!

Спасибо!
На мой взгляд Android (не абстрактный, каким он должен быть в идеале, а реальный на большинстве телефонов) сильно недоработанная в плане безопасности система. И вина в этом не только Google, но и большинства конкретных производителей телефонов. Увы, большинство модификаций включая ту же Cyanogen/Lineage заточены под улучшения интерфейса (например темы), а не на безопасность. Безопасность — это доверие. Если условный я не доверяю Google, но доверяю производителю в части железа, например, то никакие ухищрения в новых версиях не будут выглядеть для меня безопасными и я буду стараться их обойти, в том числе получением root-прав.

Теперь аргументы почему с безопасностью все плохо:
1. Современные смартфоны на Android — закрытые системы. 100% открытых телефонов я вообще не видел, у большинства vendor специфичная часть закрыта наглухо, а ведь она занимает половину прошивки. Количество блобов можете посчитать сами, начиная с огромного блоба модема. У некоторых моделей даже ядро невозможно пересобрать, хотя вроде какие-то исходники даже есть, а те производители, которые частично что-то выкладывают — обычно не следят за актуальностью (привет почти всем китайцам). В закрытой системе говорить о безопасности как минимум странно — вы сами не можете не то что исправить ошибки в vendor части, в модеме и много где еще, но даже контролировать что там происходит; гарантированных обновлений от производителя вы тоже можете не получить или получать очень недолго. Cyanogen/Lineage не помогает — там vendor/modem и прочие закрытые части тупо копируются из оригинала.
2. Большинство производителей опять же закрывают телефоны наглухо через AVB/DM-Verity. Если загрузчик можно разблокировать, то обратно заблокировать его с модификациями уже нельзя (у подавляющего большинства). Это открывает проблемы, описанные в статье — люди, вносящие нужные им модификации не могут получить поддержку со стороны железа от других злонамеренных действий. Пользователя вынуждают абсолютно доверять производителям, а любые ультиматумы — это плохо с точки зрения безопасности.
3. Замена FDE на FBE это шаг назад, потому что метаданные файлов не шифруются — это приводит к куче утечек. При этом зашифровать внешнюю sd-карту по прежнему без сильных танцев нельзя, а кое-где и вообще нельзя. Почему вообще нельзя опционально шифровать весь телефон, включая разделы system/vendor/boot и др. — это бы сильно затруднило внедрение трояна описанного в статье? На компьютере же можно что хочешь шифровать, а тут нельзя.
4. Ужасная схема ввода пароля: из коробки не более 16 символов (почему?), нет пароля для сброса данных (против дампа прошивки не спасет, но иногда может выручить), нет настраиваемого учета числа неверных попыток, нельзя вместо пароля использовать ключи, включая внешние, нет возможности выгружать ключи из памяти во время работы (хотя вот в iOS есть), ну и т.д. В системе даже хранится вид пароля, чтобы правильную клавиатуру показывать (буквы, цифры, язык) — шикарная подсказка для взломщиков.
5. Реализация системы разрешений тоже недоработана. Во-первых у части приложений разрешения «неотзывные», т.е. мы вроде как уходили от суперпользователей, но вернулись к ним же. Вроде как все равны, но некоторые равнее. Это не может быть безопасно. Во-вторых, вторичные разрешения вообще не контролируются, т.е. получив доступ к чему-то, приложение может спокойно передать эти данные другому приложению, у которого таких прав нет и в системе никто этого даже не заметит. Подделать данные для приложений впрочем тоже нельзя из коробки, хотя сторонние решения какие-то есть. В третьих, гранулярность разрешений по прежнему очень высокая. Ну что такое «неограниченный доступ в интернет»? Это же дыра огромных размеров, но никто затыкать ее даже не собирается. Надо выдавать разрешения на доступ только к конкретным адресам и по конкретным протоколам как минимум.

Да вобщем, писать можно много, тут на целую статью наверное потянет.

Как итог, система в текущем виде ставит пользователю ультиматум: либо ты доверяешь мне на 100% и тебе при этом будет запрещены многие действия (включая полезные), либо твой телефон превращается в решето и система в этом только поможет и углубит это решето. Вообще, тот факт что людям нужен root-доступ для многих вещей и они готовы его получать жертвуя чем-то, уже говорит о том, что с архитектурой у системы большие проблемы, а значит проблемы и с безопасностью.

Спасибо за вдумчивый комментарий. Всё прям в точку. Практически нечего добавить.


На мой взгляд немало проблем растёт из того, что всё касающееся безопасности очень сильно завязано на пропиетарные компоненты, и даже при желании не может быть исправлено сообществом. Либо проблемы заложены в изначальном дизайне системы и пытаться их исправить ничего не сломав во взаимодействии фреймворка и приложений близко к невозможному (пермишены, подход «всё или ничего»). В итоге, сообщество кастомщиков и радо бы усилить механизмы безопасности, но не может.


Тем не менее, там где это возможно гугл и вендоры стараются подкручивать гайки и это хорошо.

прекрасная статья. спасибо.
был на руках телефон K30 5G. там DYNAMIC_PARTITIONS_PARTITION_LIST (похоже это сейчас становится модным, oneplus nord тоже такой)
и это не дает монтировать в twrp на запись разделы, которые в этот список входят. только RO. и прошить можно только полностью раздел.
т.е. изменить system, например, из twrp путем добавления файлов не получится.

Присоединяюсь к поблагодарившим, спасибо! Прочитал с огромным интересом.
Скажите пожалуйста, какие главные минусы у рута с заблокированным загрузчиком?


П.с. в слове "нЬюансы" опечатка.

Спасибо большое. Главный минус — имея рут доступ можно изменить что-нибудь в системном разделе и вызвать срабатывание dm-verity, что соответственно приведёт к невозможности загрузиться. Это легко сделать неосторожным изменение hosts файла например. Тем не менее вполне можно использовать afwall, т.к. всё для чего ему нужен root — это вызов бинарника iptables. Я бы сам лично не стал бы пользоваться root доступом в системе с заблокированным загрузчиком просто чтобы случайно не наломать дров.


П.С: не только в нём, мне нужно сесть и поправить немало орфографических ошибок

Благодарю, да, afwall замечательная программа, я без неё уже не могу + логирование крайне удобное, недавно заблочил кучу рекламы в hosts, время от времени заглядываю в тёмные комнаты андройда, получается, не первый год хожу по грани, надо что-то с этим делать, скоро оступлюсь.
Скажите, какая ситуация у новейших андройдов с обновлениями и рут доступом, после установки свежих обновлений придётся ломать эксплойтом каждый раз? Если да,
с разблокированным загрузчиком таких проблем можно избежать?


П.п.с. В целом, текст написан весьма достойно, совсем уж незначительные опечатки я не стал указывать.(раза 2 заметил, что нет пробела между словами)

В андроидах установка рута практически всегда идёт через разблокировку загрузчика. Производитель закладывает возможность устанавливать что-то помимо доверенной системы. Вот в iOS приходится прибегать по сути к взлому через эксплоит. Насколько я знаю, пока что это менять не планируется. Новые девайсы на 11 андроиде также возможность разблокировки предоставляют

Про iOS знаю, но тот же кингрут занимается тем же самым по сути, т.е. взломом через эксплойт, ну и троянца своего тоже не забудут подсунуть, но это совсем другая история. Мне интересно понять, как ведут себя при обновлении новые устройства, рутованные разными способами(зловред kingroot и его аналоги или же полноценная разблокировка). В любом случае, спасибо за отзывчивость.

Кингрут уже лет как 5 наверное сдох, там уже с 7 версии ведра никаких эксплойтов не было для его запуска. Сейчас на дворе магиск (который абсолютно прекрасен) и его systemless фичи, фактически системный раздел не затрагивается вообще, задетектить софт это не может, дм-верити проверка так же проходит успешно и устанавливаются все апдейты, ОТА апдейты, гуглпеи и т.д.

Спасибо.

Вставлю свои 5 копеек. Недавно восстановливпал прошивку на разлоченом сто лет назад xiaomi mi5s. Переходил с кастома на 10 Андроиде на miui на 7м. Полный формат всего, и все равно без ввода предыдущего аккаунта Гугла даже не пройти процедуру первоначальной настройки.

Этот механизм называется Factory Reset Protection или просто FRP. Данные FRP хранятся в отдельном разделе на флеш-памяти, поэтому переживают переустановку. По сути, это защита от угона, чтобы предотвратить ситуации с кражей и перепродажей устройства. Наверное на разлоченном устройстве это можно побороть, на закрытом — не получится.
Побороть можно, зависит от конкретной модели и версии прошивки. Обычно всё сводится к тому, чтобы добраться через TalkBack и подобные сервисы до возможности установить и запустить произвольное приложение, а дальше уже дело техники.
О, интересно, спасибо. Не пробовал так делать сам, но очень напоминает историю с тем как на разных POS-терминалах на базе windows вытаскивают служебные системные окна, например справку о системе, и т.д., а уже через них получают доступ дальше, сворачивают рабочее приложение, запускают paint, рисуют в нём что-нибудь хулиганское
В Windows это до сих пор встречается :)
(и это причина, по которой я предпочитаю доверить авторизацию BitLocker-у, а не экрану входа в систему… к этому времени уж больно много всего запущено, соответственно увеличивается число таких вот потенциальных приложений, которые можно использовать для обхода авторизации)

В Android вендоры с этим борются… если устройство ещё получает обновления, конечно.

Спасибо за статью, очень познавательная.
А есть рабочее решение по проверке хэша через twrp?
Также интересует вопрос антивирусов на телефоне, в каких случаях рекомендуется использовать и какие будут рекомендации?

Спасибо!

Решение — просто делать проверки через шелл (можно при желании заавтоматизировать всё через python и subprocess). Загружаемся в TWRP. Образ TWRP содержит многие утилиты для работы с файловыми системами, сбора информации о системе, и т.д. Среди них есть и утилиты для подсчёта хэшей, воспользуемся sha256sum:

$ adb shell                               // подключаемся через adb
# sha256sum /dev/block/by-name/boot       // проверяем хэш boot раздела
# sha256sum /dev/block/by-name/system     // проверяем хэш system раздела
...

Насчёт антивирусов — даже не знаю имеет ли это смысл, и что можно посоветовать. Я попробовал прогнать тесты на нескольких популярных антивирусных продуктах при установленном бэкдоре, и похоже что большинство из них не пытается прогонять сложные проверки на то что система на устройстве была скомпрометирована, или хотя бы просто попробовать прогнать проверку SafetyNet. Я не пытался глубоко анализировать механику работы антивирусов на android. Судя по всему они пытаются получать информацию о пакетах и искать подозрительные данные в манифестах или что-то вроде того. В любом случае, если устройство не предполагает использования аппаратного ТЕЕ в процессе аттестации (такое кажется есть только на пикселях), то на скомпрометированной системе с помощью рантайм-хуков злоумышленник сможет при необходимости обмануть любую проверку, поэтому наверное никто очень сильно и не пытается
Напрашивается устройство на микроконтроллере, которое будет проводить подобную проверку автоматически. Не знаю, как там в случае наличия OTG, но для большинства аппаратов понадобится ещё и «банка с электричеством». Что-то типа кабеля-прослойки между телефоном и «банкой».
Спасибо за статью. Узнал много нового, задумался. Над старым телефоном, возможно, поиздеваюсь, но новый точно трогать не буду: и дырки появляются, которые пока выглядят более существенными чем получаемые преимущества при актуальном для меня наборе угроз, и без гарантии остаться не хочется.

В общем, при правильном подходе можно заменить в стоковой системе практически всё и получить устройство, которое будет практически так же хорошо как и на альтернативной прошивке, при этом иметь заблокированный загрузчик и все плюсы использования немодифицированного устройства, такие как работающий Google Pay и платежи касанием по NFC, беспроблемно работающие приложения банков и иные полагающиеся на проверки SafetyNet, нормально работающая камера и т.д.

С удовольствием прочитал бы статью о том, как это сделать, отключив по максиму гуглософт, и минимизировать таким образом отправку данных в корпорацию добра.

отключив по максиму гуглософт

Имея рут-права — просто удалить соответствующие apk из системного раздела, либо скрыть от системы эти приложения с помощью Magisk.

Ненене, рут - это уязвимость!

НЛО прилетело и опубликовало эту надпись здесь

представим ситуацию, мы – злоумышленник, получивший на некоторое время в свои руки смартфон.

Можно ещё представить ситуацию, что я усилием мысли переместился на Альфу Центавра. Но зачем?

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории