Теоретически, разблокированный загрузчик даёт преимущества и удалённому злоумышленнику. Если тот сможет получить root локальным эксплоитом (такое бывает очень редко, но всё таки), то он сможет вносить в систему изменения не боясь вызвать срабатывание verified boot и окирпичивания устройства, но всё же максимум возможностей получает локальный атакующий с физическим доступом к устройству
По моему скромному опыту работы с движками которые определяют лицо, большинство опорных точек которые детектят на лице и используют в распознавании находятся в области у глаз и бровей, а меньшинство лежит в области на лбу и выше, и в области ниже носа. Из за этого использование масок — не такая эффективная мера как хотелось бы. Причём для человека также естественно обращать внимание именно на эту часть лица, о чём может напомнить старая шутка с пикабу про то что «ты узнаешь его из тысячи»:
Я пробовал для интереса разные подходы и наилучший результат получил когда:
— нарушается симметрия лица
— сокращается количество точек в этой самой критической области вокруг глаз
На практике я закрывал один глаз «пиратской повязкой», которая при этом закрывала бровь и некоторую область под глазом. В результате движок даже не понимал что это лицо, хотя всё остальное было на месте. Возможно длинная чёлка закрывающая поллица будет даже ещё эффективнее (а заодно позволит ненадолго вернуться в 2007)
Спасибо. Ну, в некотором смысле наверное оно так. Все знают что разблокированный загрузчик несёт проблемы, но кейсов которые бы поясняли «на пальцах» что именно можно сделать в этом случае совсем немного
С установленным magisk наверное не получится, потому что незачем и наличие рута при заблокированном загрузчике чревато окирпичиванием, или, по крайней мере, потерей данных, при неаккуратном изменении чего-то что нельзя менять. Однако можно заблокировать загрузчик на альтернативной сборке ОС, той же LineageOS, только надо не полениться собрать её в релизном варианте.
Я вот подумал что можно попробовать вытащить код magiskhide и попроьовать поиграться с ним, либо попробовать адаптировать стороннее решение по аппаратной аттестации. Так например свой аппаратный аттестатор сделан в GrapheneOS (там разработчики большие молодцы и очень заботятся о безопасности), свой аттестатор есть в huawei (им отключили гугл сервисы и приходится выкручиваться)
Спасибо! Это много значит для меня. Хабр для меня всегда был ресурсом где люди делятся по настоящему интересными техническими статьями и любят погружаться в детали. Я постарался соответсвовать этому.
Данные действительно остаются расшифрованными всегда после первой разблокировки. Это может быть опасно если включён режим отладки и adb. В этом случае можно вытащить файлы из общего хранилища которое всегда доступно через adb shell. К слову, у наших коллег из iOS операционная система уничтожает ключи в памяти спустя некоторое время неактивности, а при вводе кода разблокировки расшифровка файловой системы будет произведена заново. Может быть и нам подобное завезут в грядущих обновлениях. Вообще, вход в систему нам защищает необходимость ввести код разблокировки, разблокировкой системы управляет сервис gatekeeper, который работает через аппаратный TEE, и запись флагов в RPMB. Gatekeeper ведёт счётчик неправильных последовательно введённых кодов разблокировки и увеличивает таймауты между попытками ввода, обмануть их ни через перезагрузки устройства, ни через брутфорс через рекавери не получится, всё реализовано очень надёжно. Я для интереса попробовал и не смог найти никаких подходов. Терморектальный криптоанализ в данном случае не рассматриваем.
Физический доступ действительно нечастый сценарий атаки на устройство, но данные статистики в статье на хакере которую я привёл пугают. Вполне возможно что через лет 10 досмотр смартфона на границе станет такой же стандартной процедурой, как досмотр багажа металлоискателем. То ли ещё будет.
Основной посыл статьи был не столько про реальность сценарий атаки, сколько про то что о пользе разблокировки загрузчика пишут много, а о минусах — мало. Хотелось разобрать ситуацию и с непопулярной точки зрения
Верно. Условному атакующему нет нужды прошивать свой TWRP, достаточно загрузиться с ним. Однако, как я упоминал в статье, зайдя в TWRP вы можете сравнить хэши важных системных разделов и таким образом понять что они были модифицированы
Боюсь чтобы выбраться из этой ситуации нам нужно куда больше популяризировать и развивать OpenHardware. В ближайшее время вряд ли что-то фундаментально изменится
Спасибо! Тема действительно очевидная, но почему-то довольно непопулярная. Я хотел привлечь внимание к тому что пользуясь рутом или альтернативной сборкой ОС нужно помнить о дополнительных возможностях которые появляются у атакующего с физическим доступом. Предупрежден — значит вооружен
Плюсану, хоть меня тут могут и закидать помидорами. Разумеется, это вопрос личных предпочтений, но для меня единственный инструмент работающий от рута, который я прям уважаю и никак не могу без него если всё-таки накатываю что-то на устройство это afwall, потому что это просто обёртка над iptables (хотя netguard тоже неплох если нужно обрубить доступ в сеть приложениям которым это явно не требуется для работы). Ещё раз, это ИМХО, но я могу для всех остальных задач использовать не требующие рута приложения
Это самый простой вариант из возможных, но самый «не тру» для настоящих энтузиастов кастомного android. Если скомбинировать его со способами выключения предустановленных системных приложений описанных в недавней статье, то вполне может получиться неплохо.
У меня на одном из старых телефонов не только весь подобный хлам был установлен, но даже прошиты уникальные UUID устройства для трекинга для facebook, yandex и сбера. Прошиты прямо build.prop, прямо в /system, прямо на этапе сборки системы производителем. Из можно было увидеть через вызов getprop.
З.Ы. Дата для добровольно принудительного внедрения отечественного ПО выбрана таки знаменательна
Я пока не настолько хорошо разбираюсь в android чтобы подпилить ядро под свои нужды, может быть получится в дальнейшем развить тему статьи в сторону модификации ядра, но пока могу только так. Разумеется, злоумышленнику выгоднее работать напрямую из ядра, так меньше торчит флагов компрометации в системе.
Ситуация с невозможностью контролировать устройства это действительно проблема, думаю, последний десяток лет уже. В андроиде всё особенно тяжело, т.к. даже на альтернативной сборке и со своими avb ключами остаётся целая куча пропиетарных компонентов от производителя без оторых устройство просто не сможет работать.
Насчёт поставки ядра с LineageOS — не знал. На мои устройства приходят обновления только system и vendor образов. Можете пожалуйста ткнуть меня в ссылку где это описано? Исправлю в тексте статьи
Я очень ценю и уважаю приватность и желаю чтобы большинство устройств могли обеспечить её на высочайшем уровне. Я очень люблю кастомные прошивки, довольно много их ковырял и подпиливал под себя, я считаю очень важным их существование и бесконечно благодарен сообществу, которое их развивает. Я как никто другой понимаю то о чем вы говорите, иначе этой статьи просто не появилось бы. Я согласен с вами, просто суть статьи немного не в этом.
Суть в том что в интернете полно статей которые рассказывают про root и альтернативные прошивки, но не рассказывают про обратную сторону их наличия на устройстве. Многие люди насмотревшись на громкие лозунги и красивые картинки с «мужчиной в масочке с усиками» с радостью освобождают свой смартфон, но с точки зренич довольно популярно модели угроз (физическое изъятие) делают его намного более уязвимым чем он был до освобождения. Посыл статьи — рассмотреть ситуацию со всех сторон и дать понимание о том что у освобождения есть минусы, о которых нужно помнить чтобы не создать себе лишних проблем
К сожалению нет. Именно поэтому в официальную TWRP и не вводят эту функцию. Разблокированный загрузчик позволит просто проигнорировать запароленную TWRP и загрузить вместо неё свою, незапароленную через fastboot boot img.img
Теоретически мы сможем также вырезать эти проверки из исходников magisk.
Думаю каждый решает сам для себя что важнее. Опять же, на пикселях и ванплюсах мы можем прописать свои ключи для проверки avb и эта атака работать не будет
Если не ошибаюсь, сейчас для запуска режима отладки нужно вводить код разблокировки. Проблема в том что это тот же самый код разблокировки, которым открывается экран после того как смартфон вышел из режима сна. Если злоумышленник знает его, то и adb запустит.
Тут ключевая мысль всё таки в разблокированном загрузчике. При таком подходе заходить в режим отладки не обязательно чтобы подкинуть в систему проблем
Ramdisk лежит в boot разделе, рядом с ядром. Они загружаются самыми первыми и стартуют init — основной процесс загрузки системы (тот что с анимацией загрузки)
Спасибо! Я пока не достиг кунфу для внедрения в ядро, но может быть разберусь в этом в будущем. Читал что в начале 2010-х существовали зловреды которые внедряли свой модуль ядра и организовывали свою работу через него.
Согласен насчёт того что часто альтернативные сборки решаютв ситуациях когда вендор забросил девайс. Например Xiaomi mi4 вендор забросил, не соврать бы, на android 6, а LineageOS поддерживают его аж до 16 версии (android 9), и всё это силами энтузиастов.
Насколько я понимаю, user-settable root of trust даёт всё то же что и полноценная ОС с embedded root of trust. Ну, только желтую предупреждающую плашку показывает на 10 секунд при запуске. Есть какие-то подводные камни? Мне кажется главный головняк с «желтым» загрузчиком — это собирать обновления руками.
Наверное я употребил слово «старенький» с оглядкой на темпы выхода новых версий ОС. Девайс — Huawei honor 9, в 2018 году брал
Отчасти поэтому и возникла вся движуха с root правами. Действительно, глупо отрицать что гугл не выжимает по максимуму пользовательских данных из устройств на своей ОС, однако суть статьи — просто показать что у альтернативных решений есть свои проблемы
Теоретически, разблокированный загрузчик даёт преимущества и удалённому злоумышленнику. Если тот сможет получить root локальным эксплоитом (такое бывает очень редко, но всё таки), то он сможет вносить в систему изменения не боясь вызвать срабатывание verified boot и окирпичивания устройства, но всё же максимум возможностей получает локальный атакующий с физическим доступом к устройству
По моему скромному опыту работы с движками которые определяют лицо, большинство опорных точек которые детектят на лице и используют в распознавании находятся в области у глаз и бровей, а меньшинство лежит в области на лбу и выше, и в области ниже носа. Из за этого использование масок — не такая эффективная мера как хотелось бы. Причём для человека также естественно обращать внимание именно на эту часть лица, о чём может напомнить старая шутка с пикабу про то что «ты узнаешь его из тысячи»:
https://cs4-pikabu-ru.cdn.ampproject.org/ii/w820/s/cs4.pikabu.ru/post_img/2014/09/17/9/1410965579_446264023.jpg
Я пробовал для интереса разные подходы и наилучший результат получил когда:
— нарушается симметрия лица
— сокращается количество точек в этой самой критической области вокруг глаз
На практике я закрывал один глаз «пиратской повязкой», которая при этом закрывала бровь и некоторую область под глазом. В результате движок даже не понимал что это лицо, хотя всё остальное было на месте. Возможно длинная чёлка закрывающая поллица будет даже ещё эффективнее (а заодно позволит ненадолго вернуться в 2007)
Спасибо. Ну, в некотором смысле наверное оно так. Все знают что разблокированный загрузчик несёт проблемы, но кейсов которые бы поясняли «на пальцах» что именно можно сделать в этом случае совсем немного
С установленным magisk наверное не получится, потому что незачем и наличие рута при заблокированном загрузчике чревато окирпичиванием, или, по крайней мере, потерей данных, при неаккуратном изменении чего-то что нельзя менять. Однако можно заблокировать загрузчик на альтернативной сборке ОС, той же LineageOS, только надо не полениться собрать её в релизном варианте.
Я вот подумал что можно попробовать вытащить код magiskhide и попроьовать поиграться с ним, либо попробовать адаптировать стороннее решение по аппаратной аттестации. Так например свой аппаратный аттестатор сделан в GrapheneOS (там разработчики большие молодцы и очень заботятся о безопасности), свой аттестатор есть в huawei (им отключили гугл сервисы и приходится выкручиваться)
Спасибо! Это много значит для меня. Хабр для меня всегда был ресурсом где люди делятся по настоящему интересными техническими статьями и любят погружаться в детали. Я постарался соответсвовать этому.
Данные действительно остаются расшифрованными всегда после первой разблокировки. Это может быть опасно если включён режим отладки и adb. В этом случае можно вытащить файлы из общего хранилища которое всегда доступно через adb shell. К слову, у наших коллег из iOS операционная система уничтожает ключи в памяти спустя некоторое время неактивности, а при вводе кода разблокировки расшифровка файловой системы будет произведена заново. Может быть и нам подобное завезут в грядущих обновлениях. Вообще, вход в систему нам защищает необходимость ввести код разблокировки, разблокировкой системы управляет сервис gatekeeper, который работает через аппаратный TEE, и запись флагов в RPMB. Gatekeeper ведёт счётчик неправильных последовательно введённых кодов разблокировки и увеличивает таймауты между попытками ввода, обмануть их ни через перезагрузки устройства, ни через брутфорс через рекавери не получится, всё реализовано очень надёжно. Я для интереса попробовал и не смог найти никаких подходов. Терморектальный криптоанализ в данном случае не рассматриваем.
Физический доступ действительно нечастый сценарий атаки на устройство, но данные статистики в статье на хакере которую я привёл пугают. Вполне возможно что через лет 10 досмотр смартфона на границе станет такой же стандартной процедурой, как досмотр багажа металлоискателем. То ли ещё будет.
Основной посыл статьи был не столько про реальность сценарий атаки, сколько про то что о пользе разблокировки загрузчика пишут много, а о минусах — мало. Хотелось разобрать ситуацию и с непопулярной точки зрения
Верно. Условному атакующему нет нужды прошивать свой TWRP, достаточно загрузиться с ним. Однако, как я упоминал в статье, зайдя в TWRP вы можете сравнить хэши важных системных разделов и таким образом понять что они были модифицированы
Именно, просто условный злоумышленник делает fastboot boot unpasswored_twrp.img и игнорирует то TWRP которое установлено в рековери раздел
Ого, неожиданно. Правда вот яндексофоны в продаже найти не так просто
Боюсь чтобы выбраться из этой ситуации нам нужно куда больше популяризировать и развивать OpenHardware. В ближайшее время вряд ли что-то фундаментально изменится
Спасибо! Тема действительно очевидная, но почему-то довольно непопулярная. Я хотел привлечь внимание к тому что пользуясь рутом или альтернативной сборкой ОС нужно помнить о дополнительных возможностях которые появляются у атакующего с физическим доступом. Предупрежден — значит вооружен
Плюсану, хоть меня тут могут и закидать помидорами. Разумеется, это вопрос личных предпочтений, но для меня единственный инструмент работающий от рута, который я прям уважаю и никак не могу без него если всё-таки накатываю что-то на устройство это afwall, потому что это просто обёртка над iptables (хотя netguard тоже неплох если нужно обрубить доступ в сеть приложениям которым это явно не требуется для работы). Ещё раз, это ИМХО, но я могу для всех остальных задач использовать не требующие рута приложения
Это самый простой вариант из возможных, но самый «не тру» для настоящих энтузиастов кастомного android. Если скомбинировать его со способами выключения предустановленных системных приложений описанных в недавней статье, то вполне может получиться неплохо.
У меня на одном из старых телефонов не только весь подобный хлам был установлен, но даже прошиты уникальные UUID устройства для трекинга для facebook, yandex и сбера. Прошиты прямо build.prop, прямо в /system, прямо на этапе сборки системы производителем. Из можно было увидеть через вызов getprop.
З.Ы. Дата для добровольно принудительного внедрения отечественного ПО выбрана таки знаменательна
О, значит мой косяк, спасибо большое за замечание. Исправлю как доберусь до компьютера
Спасибо за отзыв!
Я пока не настолько хорошо разбираюсь в android чтобы подпилить ядро под свои нужды, может быть получится в дальнейшем развить тему статьи в сторону модификации ядра, но пока могу только так. Разумеется, злоумышленнику выгоднее работать напрямую из ядра, так меньше торчит флагов компрометации в системе.
Ситуация с невозможностью контролировать устройства это действительно проблема, думаю, последний десяток лет уже. В андроиде всё особенно тяжело, т.к. даже на альтернативной сборке и со своими avb ключами остаётся целая куча пропиетарных компонентов от производителя без оторых устройство просто не сможет работать.
Насчёт поставки ядра с LineageOS — не знал. На мои устройства приходят обновления только system и vendor образов. Можете пожалуйста ткнуть меня в ссылку где это описано? Исправлю в тексте статьи
Я очень ценю и уважаю приватность и желаю чтобы большинство устройств могли обеспечить её на высочайшем уровне. Я очень люблю кастомные прошивки, довольно много их ковырял и подпиливал под себя, я считаю очень важным их существование и бесконечно благодарен сообществу, которое их развивает. Я как никто другой понимаю то о чем вы говорите, иначе этой статьи просто не появилось бы. Я согласен с вами, просто суть статьи немного не в этом.
Суть в том что в интернете полно статей которые рассказывают про root и альтернативные прошивки, но не рассказывают про обратную сторону их наличия на устройстве. Многие люди насмотревшись на громкие лозунги и красивые картинки с «мужчиной в масочке с усиками» с радостью освобождают свой смартфон, но с точки зренич довольно популярно модели угроз (физическое изъятие) делают его намного более уязвимым чем он был до освобождения. Посыл статьи — рассмотреть ситуацию со всех сторон и дать понимание о том что у освобождения есть минусы, о которых нужно помнить чтобы не создать себе лишних проблем
Думаю каждый решает сам для себя что важнее. Опять же, на пикселях и ванплюсах мы можем прописать свои ключи для проверки avb и эта атака работать не будет
Если не ошибаюсь, сейчас для запуска режима отладки нужно вводить код разблокировки. Проблема в том что это тот же самый код разблокировки, которым открывается экран после того как смартфон вышел из режима сна. Если злоумышленник знает его, то и adb запустит.
Тут ключевая мысль всё таки в разблокированном загрузчике. При таком подходе заходить в режим отладки не обязательно чтобы подкинуть в систему проблем
Ramdisk лежит в boot разделе, рядом с ядром. Они загружаются самыми первыми и стартуют init — основной процесс загрузки системы (тот что с анимацией загрузки)
Спасибо! Я пока не достиг кунфу для внедрения в ядро, но может быть разберусь в этом в будущем. Читал что в начале 2010-х существовали зловреды которые внедряли свой модуль ядра и организовывали свою работу через него.
Согласен насчёт того что часто альтернативные сборки решаютв ситуациях когда вендор забросил девайс. Например Xiaomi mi4 вендор забросил, не соврать бы, на android 6, а LineageOS поддерживают его аж до 16 версии (android 9), и всё это силами энтузиастов.
Насколько я понимаю, user-settable root of trust даёт всё то же что и полноценная ОС с embedded root of trust. Ну, только желтую предупреждающую плашку показывает на 10 секунд при запуске. Есть какие-то подводные камни? Мне кажется главный головняк с «желтым» загрузчиком — это собирать обновления руками.
Наверное я употребил слово «старенький» с оглядкой на темпы выхода новых версий ОС. Девайс — Huawei honor 9, в 2018 году брал
Отчасти поэтому и возникла вся движуха с root правами. Действительно, глупо отрицать что гугл не выжимает по максимуму пользовательских данных из устройств на своей ОС, однако суть статьи — просто показать что у альтернативных решений есть свои проблемы