Комментарии 11
Можно взять средний китайский смартфон с их же сборкой Android и посмотреть на сколько он фонит в сеть интернет.
Чистых смартфонов фактически нет.
Это бекдор со знаком плюс.
Китайские вендоры днищевого эшелона знают, что их устройства почти все рутуют - иначе этим добром пользоваться сложно ввиду кривого софта. Запилить хороший софт мешает экономика - устройство будет дорогим, и его никто не купит. Но всякие нехорошие люди из сертификации не дают право выбора пользователю, как ему использовать устройство, там жесткая диктатура - жри чего дали, барину видней, что тебе надо. Потому китайцы оставляют довольно очевидные дыры, чтобы не мешать пользователю делать то, что он хочет, но при этом обманом пройти сертификации.
Никакая сертификация не запрещает предоставлять пользователю возможность разблокировки загрузчика. Собственно даже сама Google на своих Pixel эту возможность предоставляет.
Просто у нормальных вендоров это делается через что-то типа fastboot flashing unlock, а не вот так, как описано в статье.
Да не делается это так, как описано в статье. Для современных OnePlus разблокировка осуществляется через их же приложение, которое отдает с сервера ключ для разблокировки, после чего идём в фастбут и посылаем упомянутую выше команду
Google даёт разблокировать загрузчик самостоятельно.
Но другие производители делают разблокировку только через свои онлайн-сервисы.
Я недавно изучал ситуацию с Xiaomi (хорошее железо за небольшие деньги) по темам на 4pda, и оказалось, что для подачи заявки на разблокировку нужно иметь Mi-Account созданный минимум месяц назад, в среднем коды приходят за несколько суток, но некоторым счастливчикам не приходят вовсе. В телефоне должна стоять сим-карта местного оператора и интернет через неё, чтобы проверить географическое расположение.
Я пока в больших раздумьях, нужны ли мне такие приключения, или лучше переплатить x3 и взять Pixel.
С каких пор OnePlus относится к днищевому эшелону? Их устройства для глобального рынка вполне комфортные для использования из коробки без напильника
"Свободные" прошивки типа LineageOS тоже этим грешат. Пользователи в массе своей не знают, что официальные билды LOS идут в варианте userdebug, что позволяет атакующему получить права суперпользователя, даже если смартфон не рутован, и даёт пользователю ложное чувство защищённости.
Для "свободных" прошивок важно больше то, что из них вырезаны мусорные маркетинговые сервисы, которые что-то куда-то отправляют (оставляют след), жрут батарею и для пользователя бесполезны. Возможность отобрать у приложения права, или подсунуть ему левые данные, если оно эти права требует в обязательном порядке. Именно это понимается под безопасностью. Бытовая безопасность, так сказать цифровая гигиена, но никак не игра в супершпиона.
Если кто-то настолько интересен органам некой страны, что ради него будут в том же аэропорту держать "на стреме" бригаду безумно дорогих специалистов по взлому - штош, такой купит нормальное защищеное решение, либо ему выдадут оное по службе.
Спасибо за интереснейшее исследование и отличную статью! Нечасто увидишь материал такого качества. В очередной раз убеждаюсь в том, насколько мутно и ненормально многие производители устройств реализуют логику загрузки операционной системы.
Если говорить в целом, то у Гугла предусмотрен интерфейс, через который предполагается управление статусом блокировки загрузчика и сопутствующих этому изменений. Это то самое "fastboot flashing unlock/lock". Предполагалось, что производители устройств будут интегрировать свои загрузчики именно с ним.
Тем не менее, несложно обратить внимание на то, что в реальности абсолютное большинство устройств, за единичными исключениями вроде Гугл Пикселей, где Гугл честно и по правилам реализовал эту интеграцию, используют для управления статусом блокировки загрузчика команды в духе "fastboot oem unlock/lock". Кажется, что "ну какая разница? просто по другому команда называется", но нет, на самом деле разница очень серьёзная.
В то время как "fastboot flashing" - это специально определённый механизм для блокировки/разблокировки загрузчика, то "fastboot oem" - это интерфейс для передачи произвольных команд, которые определяет производитель устройства сам. Производитель сам определяет формат, сам определяет состав, сам определяет логику реализации этих команд. В принципе там может быть реализовано что угодно и как угодно. По изначальной задумке, этот механизм нужен для реализации на уровне fastboot протокола разной нестандартной логики, специфичной для аппаратной платформы, что вообще-то вполне логично. Однако, производителям также очень легко злоупотребить этим и реализовать в нём также и то, реализация чего предполагается в совершенно другом месте.
Производители, конечно, реализуют блокировку/разблокировку именно через "fastboot oem", потому что это даёт им очень многое. Во-первых, это позволяет не соблюдать полные требования интерфейса "fastboot flashing" которые включают довольно большой набор разных состояний, включая, например, поддержку доверенной загрузки с определяемым пользователем корнем доверия - а это значит что и работы нужно сделать меньше, и контроля на стороне пользователя меньше - проще огородить от исследователей свою систему. Во-вторых, это позволяет производителям устройств уклоняться от требований по возможности предоставления пользователю разблокировки загрузчика - например неоправданно усложнять процесс, делать его нестандартным, к примеру, требовать дополнительный код разблокировки или отсылать в процессе на свои сервера кучу разных данных о том кто, где, как, когда, на каком устройстве запросил разблокировку и т.д. (привет Ксяоми). А дальше, видимо, это вполне можно использовать чтобы ссылаясь на это отказать в гарантийном обслуживании (или понизить социальный рейтинг как слишком умному /s). В-третьих, и это самое главное, Гугл для прохождения сертификации устройства не требует прохождения тестов правильной реализации интерфейса "fastboot flashing" от сторонних производителей. Это рекомендуется, но обязательным для сертификации не является, в результате практически никто этого и не делает, а все с удовольствием срезают углы на "oem" вариантах.
Честно говоря, я так глубоко как автор статьи не копал, но судя по информации в статье, ВанПлюсы пошли ещё дальше и вообще реализовали ещё один дополнительный кастомный слой команд "ops", в который ещё дополнительных мутных возможностей накрутили. В общем то, после такого и перестаёшь удивляться успехам инструментов по извлечению данных для криминалистики типа Cellebrite, "Мобильный Криминалист" и подобных им, которые какой-то очень существенный процент существующих на рынке моделей устройств ломают именно через незадокументированные возможности на уровне fastboot. И фаззеры для поиска незадокументированных команд в fastboot режиме тоже не просто так пишутся.
Кстати, добавлю ещё интересный момент конкретно про устройства OnePlus. Когда несколько лет назад я готовил упомянутую в тексте статью, я все действия производил на OnePlus 5T, который по своей низкоуровневой начинке очень похож на 6Т. Насколько я понимаю, модели OnePlus 5/5T/6/6T имеют вообще достаточно небольшие различия между собой.
Одной из интереснейших их особенностей является то, что на некоторых OnePlus-ах, в которые входят как раз вышеупомянутые модели, есть возможность закрывать загрузчик на нестоковой прошивке (на xda энтузиасты обнаружили), т.к. у них то ли частично, то ли может быть как-то отдельно, по своему, была реализована возможность поддержки определяемого пользователем корня доверия. Сильно точнее детали не подскажу, но у них был выделен доступный к прошивке из fastboot раздел "avb_custom_key". Насколько я понимаю, кстати, эта возможность сохранилась и на некоторых других, более поздних устройствах производителя.
Механизм этот, видимо, также эволюционировал со временем, от более старых моделей устройств к более новым, т.к. требовал определённой минимальной версии firmware, которую нужно было скачать с сайта производителя и зашить на устройство, а также имел свои особенности. Так для модели 5Т было достаточно просто сгенерировать RSA ключ, преобразовать его в специальный формат, подписать внешним инструментом разделы, после чего прошить их как обычно, а ключ прошить в вышеупомянутый раздел "avb_custom_key", то для более поздних моделей OnePlus уже необходимо было немного попатчить сорцы, например того же LineageOS или AOSP, и собирать уже сборку с включёнными хэшами разделов и небольшой дополнительной для сборки логикой, чтобы всё корректно заработало.
Я тогда тоже, благодаря удачному устройству на руках, довольно много поэкспериментировал с тем, чтобы получить на устройстве "жёлтый" статус, когда операционная система установлена не стоковая, разделы подписаны не аппаратными ключами, а ключами из раздела, которые зашил сам пользователь, но загрузчик при этом закрыт, avb работает, и т.д. И у меня это получилось, конкретно - на том самом OnePlus 5T. Я запускал LineageOS на заблокированном загрузчике и даже портировал ради интереса тогда ещё riru модуль xposed, который у меня также работал на системе, чтобы завести "из системы" XPrivacyLua, и это тоже всё работало, с заблокированным загрузчиком.
Я обратил внимание вот на какую штуку, которую тогда в материале не упомянул. Однажды я решил поэкспериментировать и посмотреть как вживую работает dm-verity. Собрал сборку LineageOS с функционалом рута из коробки (дело было давненько, тогда ещё поддерживался addonsu), с подписью системы, разделов, своим корнем доверия и вот это всё. Прошил, заблокировал загрузчик, перезагрузился - всё хорошо, устройство вошло в "жёлтый" режим, система загрузилась. Подключился по adb и вызвал su - получил рутовый шелл. Перемонтировал system в rw, и поменял там кое-что из файлов, т.е. явно нарушил целостность рид-онли раздела. И... ничего не произошло! Т.е. по идее, система должна была обнаружить изменение целостности раздела system, и dm-verity должен быть немедленно прекратить работу системы и, более того, не дать ей загрузиться в дальнейшем, пока раздел не вернётся в изначальное состояние, но этого НЕ произошло, ни сразу, ни после перезагрузки устройства.
Тогда я понял, что, вероятно, что-то очень сильно не так с реализацией этих вещей у OnePlus. И кто знает что это было? Попалось устройство в каком-то незадокументированном режиме? Сборка у меня была "user", т.е. релизная, специально собирал LineageOS именно не в стандартном для них "userdebug". Свойства ro.secure и ro.debuggable точно были в значениях соответствующих релизной сборке. Глубже я тогда копать не стал, т.к. к сожалению, не было достаточно свободного времени. Допускаю что может быть я что-то не так сделал или понял, но, возможно, это тоже было что-то из незадокументированных особенностей устройств производителя, которые автор происследовал в статье. И кто его знает сколько их ещё? И в ВанПлюсах, и не только.
Такие дела
С Xiaomi такая же история. Неск лет назад покупал их 4S, который тоже оказался root разлоченым. Звонилка работала нормально, а вот приложения некоторые из-за этого ставить отказывалась по соображениям безопасности. Происходит такое, думаю, по причине необходимости такого режима для спецслужб, особенно в Китае для локального рынка. И получается. что все китайские бренды этому подвержены. Я не занимался вплотную этим вопросом дальше, но было бы интересно покопаться в различиях между андроидами на пикселах, самсунгах и китайскими брендами. Есть стойкое ощущение, что там еще много скрытых вещей. Кстати, это не только телефоны, а например, дверные звонки-домофоны, которые льют инфу регулярно (проверено wireshark)
В тихом омуте… или интересный режим работы смартфона OnePlus 6T