Проект, вне всякого сомнения, нужный и правильный. На самом деле, я тоже давно подумываю о том, что необходимо собрать на базе Графена мод, в котором уши Графена торчать наружу не будут, а всё будет максимально похоже на стоковую систему, плюс передать контроль лично пользователю за разными вещами, вроде данных, на основе которых составляется фингерпринт, или того же plausable deniability. Эти штуки Гугол не исправляет, и никогда не исправит - потому что они нужны для массовой слежки и для своих полицаев в США, а команда Графена с таким заморачиваться не хочет - ей интереснее работать над более фундаментальными вещами.
Не буду присоединяться к едким комментариям выше по поводу того, что это просто оверпрайснутый перекрашенный Графен.
Любая работа в направлении создания андроид прошивки, в которой на первое место ставятся интересы людей, владельцев устройств, а код шарится для сообщества (пусть пока и в таком виде, без серверной части) - это благое дело, и Графен здесь - самый лучший фундамент, на котором можно строить что-то дальше. Было бы очень странно выбирать за основу что-то другое.
А оверпрайс - просто следствие того как устроен мир, в котором мы сейчас живём. Мне, как человеку, который тоже велосипедил в своё время форк АОСПа с уклоном в безопасность, было очень тяжело в своё время зайти в тупик, в котором оказывается абсолютное большинство авторов таких проектов - работа эта сложная и неблагодарная. Она требует квалификации сильно выше обычного рядового андроид разработчика, плюс сжирает невероятное количество времени и сил, и вот ты уже стоишь перед выбором, где на одной чаше весов ты - вольный творец, рвёшь жилы и посвящаешь всё своё время и силы такому вот проекту, но в какой-то момент тебя, уставшего, и без гроша в кармане, семья спрашивает "папа, а что мы сегодня будем кушать?", а на другой - ты откладываешь мечты о светлом и справедливом будущем для всего человечества в долгий ящик, и идёшь красить кнопки в каком-нибудь скучном маркетплейсе или перекладывать джейсоны в джейсоны в унылом бигтехе, тратишь в 10 раз меньше сил и просто живёшь хорошую спокойную жизнь без финансовых проблем. Сделать выбор в пользу первого в таких условиях - очень непросто. Честно признаюсь, я с удовольствием бы поработал над подобным проектом, даже за деньги ниже рынка, с условием если бы результат моей работы гарантировано пошёл в опенсорс. И я знаю, что таких как я немало.
Пусть сегодня за этот оверпрайс заплатят условные владельцы заводов-газет-пароходов, а завтра, благодаря им, вырастет популярность, массовость, спрос, и появятся уже новые решения, более доступные и более открытые, и обычный работяга сможет наконец позволить себе нормальный безопасный телефон, на нормальной безопасной прошивке. Пока же, в нынешних условиях, этого не может себе нормально позволить практически никто.
В общем, я рад что таких проектов становится больше. Успехов!
К сожалению, этого не достаточно. Процесс приложения на Андроиде может быть неявно запущен через ВоркМенеджер, отложенный аларм, полученное пуш-сообщение, или бродкаст и т.д. После чего оно может спокойно сходить в сеть, не стартуя экран, не показывая уведомления, и т.д. Самое печальное - никаких нормальных способов гарантировано предотвратить это не существует.
Я пробовал экспериментировать с тем чтобы через настройки разработчика ограничить количество фоновых процессов в 0, и вроде бы оно даже работает, но нет гарантии, что оно будет единообразно работать у всех вендоров, к тому же лимит, насколько я помню, поставить можно только на всю систему сразу, а не на выбранные приложения, и это создаёт неудобства.
Ещё можно disable-ить приложения через pm, и активировать только когда потребуется, но это необходимо делать через adb, не знаю возможно ли подобное удобно сделать в рамках фреймворка без какой-то local adb прослойки. И опять же - неудобно, т.к. приложение полностью визуально пропадёт из лаунчера.
Даже в кастомных прошивках эту задачу решить не так просто, ну или может быть это я отстал от новинок прошивкостроения
Оборудование для цензуры вынуждено обрабатывать огромное количество сетевых соединений и из-за этого постоянно находится под огромной нагрузкой, т.к. оно вынуждено заглядывать в хендшейк каждого соединения, которых даже в рамках одной страницы браузера могут открываться десятки, и это всё на многие миллионы устройств подключённых к сети. Неудивительно, что такое количество лишней работы приводит к тому, что соединения подолгу, по несколько секунд или даже десятков секунд могут висеть в очереди, из-за чего даже на одобренных партией российских ресурсах всё страшно тормозит.
Как только с вами случается "Внезапный Переезд в Нидерланды", у вас фактически, с точки зрения ящиков цензуры, становится ровно одно сетевое соединение, а не десятки или сотни как ранее. Вы его открываете один раз, один раз проходите цензуру, выходите наружу, после чего все другие соединения у вас уже идут внутри первого, без анализа, и соответсвенно всё действительно начинает работать с нормальной скоростью, как и должно.
Тоже выступаю за то, чтобы каждому иметь подобный селфхостед сетап, и сам пользуюсь похожим, однако должен предупредить - при белых списках это работать не будет.
Не знаю как оно в столицах и городах-миллионниках, но в моём плебейском регионе государство уже какое-то время назад включило на мобильных сетях режим хуже чем в Туркменистане, и доступ даже к российским ресурсам не работает - нет доступа ни к популярным российским VPS провайдерам (если вы хостите ПО в каком-нибудь Селектеле), ни к блокам адресов ISP (если у вас белый адрес от провайдера), ни, что забавно, даже к большей части, собственно, самого белого списка - банки не работают, большинство российских сервисов тоже, из того что работает получилось найти только яндекс и макс. Разумеется, всё селфхостед также недоступно.
Я думаю, что это вопрос нескольких месяцев, максимум полугода, когда чебурнет подобного уровня начнут включать на проводных провайдерах и по всей стране, так что я вот сам подумываю о том, что надо бы скорее пилить мод для макса - использовать его чисто как транспорт и накрутить свой слой end-to-end шифрования сообщений и звонков. На более далёкую перспективу это выглядит более надёжным решением
Ох, не знаю. Я пока "вжухами" не пользовался, но в своё время довелось довольно много поработать с системами СКУД, эмуляцией разных карт-пропусков и т.д. и вот там эта проблема стояла в полный рост ещё 8 лет назад, и там тогда же наступили на те же самые грабли. Суть такова:
В Андроиде есть нормальное человеческое API для работы с NFC. В обе стороны. Вы можете произвольно работать в качестве "ридера" с тэгами на низком уровне - гонять вот прям нужные вам байтики туда-сюда - отправлять команды картам, и т.д. Вы также можете произвольно работать с ридерами будучи "тэгом", т.е. произвольно эмулировать тэги, которые соответствуют стандарту ISO-14443 и имеют систему команд соответствующую ISO-7816, также полностью определять какие именно байтики будут передаваться. Да, там есть куча неприятных мелких ограничений, не все из которых даже зафиксированы в документации, как это часто бывает у Google, но эмулировать платёжный протокол EMV технически возможно. Да, эта эмуляция получается технически не очень безопасной, в отличие от Google Pay, который лучше сынтегрирован с системой и аппаратным кейстором, однако НСПК, обмазавшись массой защит и предупредительных мер, всё-таки взяли и выкатили свою реализацию эмуляции карт и всё это на Андроиде отлично работает.
В iOS с NFC всё довольно грустно. Несмотря на то, что, чисто технически, Apple Pay появился и заработал раньше чем любое решение на Андроиде, Apple ну очень сильно не хочет делиться возможностью нормально работать с NFC, потому что у них есть платное партёрское API с доступом для избранных, а всё что касается платежей вообще огорожено страшным забором и бюрократией. Поддержка NFC вводилась очень постепенно. Сначала появился верхнеуровневый API для чтения NDEF-форматированных тэгов, причём читались тэги в основном плохо, и не от всех производителей. Потом появилось чтение в бэкграунде. Потом Apple наконец-то разродились нормальным API для работы с ISO-14443/ISO-7816 тэгами на низком уровне в режиме "ридера" - т.е. в этой части в iOS в принципе сейчас полноценный паритет по возможностям с Андроидом. Однако вот с API для эмуляции, насколько я знаю, всё ещё всё очень трудно и грустно. Apple действительно выпустили его год назад или типа того, и на нём действительно можно сделать условный МирПей, однако разрешено это пока что ТОЛЬКО для европейского региона, т.к. те всё таки смогли прогнуть Apple многомиллиардными штрафами за огораживание своей платформы, и главное - для этого нужно получить специальный энтайтелмент, который, как утверждают, Apple снова, как всегда, выдаёт только избранным, и отказывает в 99% случаев всем ссылаясь на какие-то мутные требования. Т.е. по факту адекватного, открытого и универсального механизма всё ещё нет.
Так вот, лет этак 8-10 назад многие СКУД системы очень хотели интеграции с уже ставшими очень популярными смартфонами, чтобы "тык" на замок можно было делать не только карточкой, но и телефоном. Реализовать подобное на Андроиде - не сложно, я даже сам не раз писал руками эмуляции разных тэгов, а вот реализовать на iOS было просто технически невозможно, а продавать эту фичу ну очень хотелось. Но вот беда - все директора и ЛПРы, которым эту фичу можно прорекламировать ходят с айфонами. Что делать? Придумали как раз колхозить эмуляцию "проксимити" через болезный Bluetooth Low Energy. Болезный - потому что страшно тормозной и ненадёжный, а классический старый Блютус на iOS ТОЖЕ огорожен и чтобы получить возможность им пользоваться нужно либо, как всегда с Apple, быть избранным, либо заносить им кучу денг за прохождение сертификации и тоже абсолютно без гарантий. В итоге все начали делать велосипеды с BLE, где считали RSSI и понимая по уровню сигнала, что ридер и устройство где-то рядом, эмулировать тот же самый опыт с "тыком" в замок, только сложный аки та самая машина Гольдберга.
По итогу, схема в целом рабочая, но пользоваться этим не нравилось никому. Блютус мог либо не подключаться когда нужно, либо подключаться "мимо" - к другому устройству, либо подключаться слишком долго и человек стоял секунд 10 перед замком тыкая в него телефоном (хотя там не NFC, что тыкать то?), либо тормозила сама связь, либо коннект не успевал от одного замка к другому переподключиться если двери были рядом. Чаще всего также необходим был запуск приложения прямо перед использованием, и Блютус очень плохо работал в фоне. Это я даже не вспоминаю про безопасность на прикладном уровне, с которой тоже иногда были интересные приколы. Сейчас это уже не так актуально, но до Блютуса 4.2 существовали техники даунгрейда соединения до незашифрованного, а поскольку это именно Блютус, а не честный NFC, суть которого в том, что связь производится вот здесь и сейчас, по месту, то можно было, в теории, с нескольких десятков метров вылавливать BLE коммуникацию по радио, а с безопасностью на прикладном уровне, как я упомянул, не всегда всё было супер.
Я не знаю сохранились ли эти самые проблемы сейчас, но тогда ничего кроме бесконечного вороха проблем этот подход "притвориться NFC через Блютус" не приносил. У меня есть подозрения что часть того, о чём я написал сверху запросто может случаться и на "вжухах".
Я тогда, помню, сгорев со всех этих проблем, реализовал концепт того, что вот накинули в комментариях выше хабровчане - настоящую работу, по настоящему честному NFC, но только наоборот - ридер мог быть не только ридером, но и притворяться "тэгом", и там уже между ними был свой протокол, абсолютно аналогичный тому что использовался в картах и в Андроиде, но только айфон должен был передавать своего рода "запросы на команды". Я тогда сильно топил именно за такой путь, тем более что его суперпросто реализовать когда терминальное оборудование на Андроиде (не нужны модификации прошивок и железа), но в компании мне добро на реализацию не дали. Мне кажется, я также несколько лет при каждом удобном случае рассказывал про эту идею всем на конференциях, но так ни в ком, наверное, интерес разжечь и не смог - все продолжают водить хороводы вокруг Блютуса
О, спасибо большое за интересную тему! Я довольно глубоко погружён в тему безопасности в Андроиде, и много игрался, в том числе, и с тем, чтобы насколько это возможно скрывать критически важные значения секретов внутри приложения, если их локального хранения никак нельзя избежать. Тоже горячо сам рекомендую всем скрывать значимые строки в приложениях, раз уж за нас этого не делает ни Гугл, ни proguard/r8, а работу реверсеров, автоматизаторов и разных других людей это упрощает на порядок.
Хотел набросить пару мыслей и вопросов по результатам прочтения статьи.
(1) Компилятор будет играть в эту игру против нас. Подобный код будет, с точки зрения компилятора, выглядеть как неэффективное вычисление и может стать очевидной целью для оптимизации. Соответсвенно, если оптимизатор по нему проедется, то выглядеть в получившемся байткоде это может сильно проще, чем это задумывалось на уровне исходников. Так декомпилятоы ещё и дополнительно попробуют привести байткод в упрощённый псевдокод, что ещё может ещё дополнительно облегчить задачу.
Вы проверяли что на уровне байткода это точно будет иметь достаточную сложность в плане реверса? Я вижу что в функции восстановления строки используются довольно замороченные операции с байтами и смещениями, поэтому полагаю, что да, проверяли, т.к. искали способ сделать код, который не будет автоматически оптимизироваться, но всё равно интересно было бы получить ваш комментарий.
(2) Вторая мысль аналогична предыдущей, но только теперь по стороне ДЕкомпиляторов. Коммерческие декомпиляторы, например JEB, содержат целый ряд модулей которые также находят и оптимизируют уже прямо dex-байткод, если видят что он без сайдэффектов, и часто могут некоторые промежуточные значения безопасно предвычислить. Модули включают в себя раскрутчики безсайдэффектных методов возвращающих булеаны, строки, разные оптимизаторы, конкатенаторы, дерефлекторы, и т.д. Довольно нередко JEB может автоматически раскрутить подобные защиты, и реверсер даже не узнает что они были в приложении. Мне в своё время даже пришлось посидеть, подумать, попрорабатывать разные подходы для того, чтобы не давать работать по байткоду подобным оптимизаторам.
Интересно узнать, довелось ли вам проверить решение на устойчивость к подобным инструментам?
(3) Третья мысль, или скорее наивный вопрос - не думали насчёт того, чтобы воспользоваться готовыми решениями? Я вот пробовал и всем рекомендую https://github.com/LSPosed/LSParanoid - отличный простой и хорошо поддерживаемый gradle плагин, который работает полностью локально - сам модифицирует байткод, заменяя опкоды создания строковых констант на статические инвоуки к классу, который он генерит и вносит в декс сам. Получается, что ничего самому не нужно тянуть, собирать, подменять. Достаточно только отметить в конфиге и/или аннотациями строки, которые необходимо скрыть и всё. Результат - очень даже неплох.
Ну и, конечно, никак нельзя не затронуть вопрос анализа в динамике. Это уже, конечно, немного в сторону тема, но скорее всего исследователь будет пытаться выломать строки именно с помощью различных инструментов динамической инструментации. Почти все подобные решения создают единую и легко обнаруживаемую точку расшифровки, а современные декомпиляторы, даже jadx, умеют в один клик создавать сниппеты для frida и xposed. Против такого уже простых решений нет, но интересно узнать, прикручивали ли вы что-то подобное в довесок к обфускации строк?
Спасибо большое ещё раз за статью! Было бы здорово видеть на Хабре темы про безопасность мобилок почаще
Как будто бы для этой задачи идеально подходит ставшие актуальными в последние годы прокси с xtls-reality, т.к. они делают как раз то, что описал автор статьи - принимают соединения с нужным SNI и проксируют их наружу (ну и защита от active-probeing-a, хоть и не принципиальная конкретно в этом случае будет как бонус). Гуглите в сторону слов "xray" и "reality".
Если система в самолёте НЕ проверяет соответствие адресов доменам, то можно без проблем поднять у себя на своём сервере с условным адресом 12.34.56.78 сервер, который будет правдоподобно представляться wa.me, и даже честно перенаправлять соединение на настоящий wa.me в случае неправильного хендшейка, но только для вас он будет точкой выхода трафика наружу. Ставится это дело за полчаса, клиенты настраиваются под любую десктопную и мобильную ось
100%. Только хотел написать об этом. Бывал там, видел цены на дома в объявлениях и много наслышан о кризисе недвижимости. 22% экономии - это всё равно ничто на фоне сложившейся ситуации. Причём, я абсолютно уверен, что подобные технологии НЕ снизят стоимость для конечного покупателя, потому что корни кризиса недвижимости растут совершенно НЕ из того, что стране не хватает кирпичей.
Такие технологии однозначно удешевят производство для застройщика, он сможет здорово экономить на сырье, очень значительно сэкономить на оплате труда рабочим, но кто сказал что он вдруг станет продавать дома дешевле? Я уверен, что дома останутся такими же недоступными, а скорее даже станут ещё более недоступными для населения, т.к. у людей станет меньше покупательная способность (спроса на рабочие руки то станет меньше), только они станут при этом ещё и значительно хуже по качеству, а вот и без того гигантская сверхприбыль застройщиков вырастет ещё выше.
Приветствую! Благодарю за интерес к статье и комментарии с правильными мыслями, прочитал - всё по делу.
С момента написания статьи прошло уже практически 5 лет и с тех пор многое изменилось. Изменилось, к сожалению, только в худшую сторону. Гугл взял глобальный курс на довольно странные цели. Сам Андроид перестал прирастать прорывным функционалом, и начал всё больше окукливаться в закрытую, во всех смыслах, систему, наподобие iOS. Вендоры стали всё больше наглеть и навязывать пользователям всё больше мусора. Приложения, рекламные и фингерпринтные/трекерные СДК в среднем стали сильно сильно более инвазивными. По всему миру вышел ряд неприятных законов, легализующих и нормализующих массовую слежку, а с развитием LLM масштаб вторжения в личную жизнь пользователя вышел на принципиально новый уровень.
В своё время, статья была написана не столько для "power user"-ов, которые знают что делают и могут обеспечить себе должную безопасность самостоятельно, сколько для обычных людей - для того чтобы массовый пользователь преследуя, абсолютно правильно и справедливо, реализацию своих прав на свободу и конфиденциальность, но не разбираясь в теме, в инструментах и их ограничениях, не подставил себя под ещё большую угрозу чем раньше. В те времена я однозначно рекомендовал обычным людям выбирать устройство с максимально чистой системой, по максимуму вычистить телефон от блоатвари через adb, а дальше просто поддерживать адекватный уровень цифровой гигиены, не устанавливая на устройство откровенный мусор, а тот, который всё-таки необходимо установить, стараться держать в отдельном окружении.
Честно говоря, сейчас я уже не уверен что этого будет достаточно. С тех пор я сам стал использовать больше "power user"-ских инструментов, пересел на кастом, однако я отдаю себе отчёт о том, что не могу рекомендовать то же самое для обычных пользователей, которые не увлекаются безопасностью и не желают тратить время на то, чтобы действовать на этом поле проактивно.
Из интересного, что я открыл для себя лично, но что ПОКА не могу рекомендовать на 100% остальным (но смогу, после определённой доработки идеи) - это правильно сделанные репаки, в которых мусор от производителя вырезан на уровне байткода. Так получилось, что я для себя накидал простенький инструмент, который делает это - распаковывает приложение, вырезает из него код рекламы, трекеров, и т.д, подменяет в логике запросов идентификаторов настоящие данные на случайные, и т.д и, должен сказать, мне очень понравился результат. Более того, огромное количество хороших репаков уже существует. Проблема в том, что с репаками возникает проблема с доверием, т.к. теперь вместо того чтобы доверять разработчику приложения, необходимо будет доверять разработчику мода, и нужен бы правильный механизм, который бы криптографически гарантировал то, что в ходе репака были добавлены/модифицированы/вырезаны только определённые вещи, связанные например со слежкой, но НЕ было внесено никаких других изменений. У меня уже есть идеи и схема как можно было бы сделать процесс модификации байткода, и дальнейшей публикации модов полностью автоматизированным, прозрачным и доверенным, но нужно время на реализацию. Надеюсь дойдут руки сделать. Дело важное и нужное, оно бы позволило людям пользоваться более безопасными приложениями массово.
Всё это, разумеется, полумеры, и по настоящему нужно вкладываться в то, чтобы в сам АОСП добавить возможность пользователю полноценно управлять происходящим на своём устройстве - т.е. чтобы фаервол, гранулированный контроль соединений по доменам, xprivacylua, решения о том, какие именно данные об устройстве показать приложению, а какие нет, и не через существующую систему пермишенов, которая даёт возможность приложению заблокировать свою работу в случае неполучения разрешений, а именно через контроль на стороне пользователя, и прочие вещи работали прямо из самой системы. Чтобы это было не РЕактивное действие - где я перекрыл доступ к тому что получилось, но трекеры всё равно через разные грязные хаки добрались до данных и слили всё на бэк, или я забыл ограничить доступ и при первом запуске оно уже всё собрало и отправило, а ПРОактивное действие, в котором приложение по умолчанию не видит в системе вообще ничего и не может сходить вообще никуда, и сначала я смотрю что именно хочет получить приложение и куда собирается отправить, и только после моего явного разрешения оно получит или не получит возможность сделать это. Вот это самый правильный путь.
Мне кажется, в таких вот "вечных" решениях самое главное - следовать за деньгами. Лично мне буквально первая же мысль, которая приходит в голову - "а кто за эту вечность будет платить?"
Заказать с доставкой роутер, прошить ОпенВрт, настроить на нём ВГ подключение к заранее подготовленной ВПСке, найти клиента, отправить ему оборудование - это всё запросто займёт половину работчего дня. Сама часть настройки - простая, но вот вся беготня вокруг точно сожрёт время. Эти прошитые роутеры, по сравнению с просто подержанными роутерами которые продаются на авито, практически не имеют никакой наценки. Мне сложно поверить в то, что те кто их делает готовы тратить по полдня ради наценки в 1000 рублей, плюс ещё и оплачивать потом аренду сервера.
Если представить себя на месте злоумышленника, то за такую благотворительность они явно захотят вернуть деньги, и самое очевидное и напрашивающееся, это, конечно же, резидентные прокси, а по простому - отмывание трафика. Т.е. злоумышленники продают десятки и сотни подобных роутеров, на них настроен ВПН с возможностью подключения от ВПС к домашнему роутеру счастливого покупателя, поднимают на этом самом роутер пускай тот же Ваергард, но уже сервер (можно даже не светить его в вебморде в люсе), на стороне ВПС настраивается проброс портов, а дальше продаётся доступ к нему уже настоящим клиентам, а не лицам обманутым хулиганами, которым почти бесплатно подарили "роутер для ютуба".
Выход в сеть с подобных адресов - это очень ценная и очень недешёвая услуга, т.к. эти адреса - "чистые", принадлежат блокам провайдеров, т.е. предполагается что за ними сидит настоящий человек, не робот, не программа, соответсвенно, они очень очень нужны разным людям, которым необходимо скрыть свой настоящий адрес, но при этом не спалиться антифрод системам на выходе из прокси, ВПНа или ТОРа. Такое нужно как разным темщикам, авторегам, мультаккаунтерам, так и мошенникам, и хакерам, особенно тем, кто атакует российские сервисы, и т.д. Сами понимаете, что в случае последнего полицаи с бутылкой придут именно за счастливым владельцем роутера для ютубчика, и, скорее всего, именно на него скинут всю уголовную ответсвенность за противоправный движ, который прошёл через его адрес.
Поинтересуйтесь, сколько стоят резидентные прокси. Даже в России, самая минимальная их цена будет выше, чем цена за ВПН для того чтобы смотреть ютубчик. На них также обычно тарифицируется трафик, и продаётся по одному или несколько гигабайт, так что только один клиент может приносить тысячи рублей в месяц за один такой прокси. А если брать максимально чистые провайдерские резидентные адреса, да ещё и в самых чистых странах, да ещё и мобильные, то цены запросто могут быть по несколько десятков долларов за один-два гигабайта трафика.
Даже если мы посмотрим на совсем мелочи. Вот конфиг ваергарда например. Там явно было искусственно сделана возможность проброса доступа к продаваемому роутеру, ведь заизолировать клиентов - не сложно, более того, они даже по умолчанию изолированы друг от друга. Т.е. кто-то явно прописал адрес для пира на роутере с маской, условно, /24, хотя по умолчанию идёт именно /32 и никакие другие клиенты этой сети маршрутизироваться не будут, кто-то явно прописал правила в iptables, которые дают одним клиентам сети иметь возможность форвардинга к другим, т.к. в самом тупом конфиге по умолчанию (всё на выход) этого не подразумевает. Через VLESS, кстати, при желании обратный прокси тоже реализуется.
Допускаю, что во мне говорит моя профдеформация безопасника, и люди кто делают эти роутеры на самом деле занимаются благотворительностью, или просто создают доступную по цене услугу под ключ для сограждан, которые не обладают достаточной технической грамотностью в вопросе сетей. Но, говорят, когда что-то ходит как утка, плавает как утка, крякает как утка и летает как утка, то это скорее всего утка.
Домашний роутер - устройство очень интимное. От него зависит очень многое в личной безопасности, и такое устройство необходимо контролировать самостоятельно. Доверять каким-то мутным людям со, скорее всего, недобрыми намерениями, вроде продавцов с авито или интернет провайдеров иметь контроль над ним - очень плохая идея
Как же приятно было увидеть это расследование в СМИ, и то как сильно оно вышло на общественное обсуждение.
С самого появления Телеграмма я рассказываю всем друзьям и знакомым про то, что в Телеграмме сделано плохо буквально всё: от мутного протокола с местами странными подходами для технической реализации того или иного функционала и абсолютно дырявых настроек по умолчанию, до непрозрачного финансирования и того что Телеграм взлетел исключительно на хайпе разгоревшемся вокруг публичного образа, который построил себе Дуров. Да, в общем то, огромное количество людей говорило об этом, просто их голоса заглушало мнение широких масс общественности "Ты что? телеграмм - это же безопасно! Так сам Паша Дуров сказал, а видел какой он молодец?".
Когда же вдруг за границей, где о личности и популярности Дурова никто не знал, проводили сравнительную оценку безопасности различных месенджеров, и оценивали конкретно технические аспекты каждого из популярных решений, то все эксперты единодушно сходились во мнении, что пользоваться таким сомнительным продуктом как Телеграм для безопасного общения нельзя, категорически, потому что если мессенджер объявляет себя безопасным, то ТАК он быть устроен не может.
Если раньше на мои аргументы люди обычно просто пожимали плечами и говорили что "Ну, это наверное твои заморочки и профдеформация как безопасника", то теперь, после публикации в СМИ, есть шанс, что о проблеме задумаются многие
Тоже пользуюсь сертификатами подписанными собственным корневым ЦС для селфхостед сервисов, которые предназначены для личного использования.
Сталкивался с аналогичной проблемой, и, если я правильно помню, я добавил CAA запись в DNS для своего домена, с данными CN своего ЦС. Тогда браузеры, в том числе сафари, перестали выёживаться
Ооооо, моя остановочка. Вообще, я смарт тв не пользуюсь, но как-то раз он был у меня на одной из съёмных квартир, так что была возможность посмотреть и изучить что там и как работает.
Мне очень повезло. Внутри моего был Андроид. Более того, этот Андроид был практически чистым, и даже более того - это была отладочная сборка, на которой можно было получить рут, но обо всём по порядку.
Логично, что почти любое современное "умное" устройство - это, как правило, помойка с круглосуточной слежкой и впариванием сомнительных услуг. Телевизоры в этом плане не исключение. Хотелось бы, вместо всего этого, иметь просто телевизор, без всего лишнего, т.е. получить систему как можно более простую, свободную, разгруженную от мусора, который туда щедро навалил производитель.
Мой телевизор, конечно же, исключением не был, и содержал целую кучу блоатвари, рекламы, всякого мусора, и т.д. К счастью, поскольку этот телек был простой и дешёвый, прям из супер-эконом сегмента, то и андроид там был самый простой, а значит на нём можно было активировать adb по tcpip, а значит на нём можно было запустить и обычные андроидные деблоатеры, которые могут удалить большинство приложений, а системные - выключить и задушить через pm disable. Вообще, топовые производители современных телевизоров делают многое для того, чтобы вы не имели возможность это сделать, по максимуму зарезают возможность получить adb доступ, и т.д - будьте внимательны.
Отсюда не самая очевидная рекомендация - для приватности однозначно лучше будут ноунейм телевизоры, т.к. крупные вендоры просто не дадут вам выключить ни слежку, ни рекламу, ничего. Блокировать соединения по DNS на уровне роутера, к сожалению, как и в случае со многими другими умными устройствами почти бесполезно, т.к. хостов слишком много, все не выловишь, с обновлениями прилетят новые, плюс, как писали в комментариях выше, производитель может заблокировать работу устройства если оно слишком долго не докладывает в штаб. Проблему надо решать на корню. А если нет adb, то производителя телевизора никак не переиграешь.
Собственно, имея adb и возможность установки приложений по adb я направил трафик на прокси, посмотрел куда вообще пытаются стучаться приложения. Потом даже не поленился, сдампил родные приложения и перепаковал и переустановил их с подсунутыми сертификатами, чтобы изучить трафик. В целом - ничего неожиданного.
Куча приложений желает работать в бекграунде и ходить в сеть на мутные китайские ресурсы. Здесь иронично то, что из-за крайне слабого железа (что-то вроде смартфона из начала 2010-ых на примерно 4-ом андроиде), их почти сразу же прибивает система, т.к. они жрут ресурс. Плюс, похоже, на андроид тв по сравнению со смартфонами сильно строже ограничение по запущенным бекграунд процессам. В принципе, это большой плюс. Опять же, имея доступ к настройкам разработчиков можно вообще его выставить в 0, т.е. по сути разрешив работать только тому приложению что находится на экране прямо сейчас.
К счастью, почти все мусорные приложения можно было удалить через pm, но вот в одну проблему всё равно утыкаешься серьёзно - это лаунчер. В силу своей сути, работает он постоянно и часто, и в бэкграунде тоже, и вот именно он шлёт в сеть большую часть всего мусора и телеметрии, именно он реально загаживал весь лог в прокси под крышку, и в нём же показывалась реклама.
Что можно сделать? Поставить опенсорс лаунчер, конечно же! А родной можно задушить через pm disable. Главное действовать осторожно. Сначала ставим лаунчер, потом и в настройках, и в adb переводим новый лаунчер в дефолтный, и только потом душим системный. Теперь у вас новый лаунчер будет открываться при запуске телевизора и при нажатии центральной кнопки на пульте.
Я рекомендую попробовать приложение FLauncher (https://gitlab.com/flauncher/flauncher), но только что глянул, есть его очень хорошо выглядящий форк (https://github.com/4v3ngR/aLauncher) с рядом дополнений, в котором вырезано даже то немногое что было в FLauncher-e (firebase, unsplash для обоев, итд). Это минималистичный, простой и приятный лаунчер. Просто главный экран устройства, без лишнего мусора.
После этого в прокси стало видно что практически никаких мусорных запросов больше нет. Лаунчер отправлял в районе 99% из них. Далее, когда я удалил все возможные пакеты, я также задушил полностью все ненужные системные, все что относились к Гуглу, кастомные сервисы, и т.д. мусорные запросы пропали совсем. Если на телевизоре ничего не нажимать, не запускать приложения то сеть просто молчит.
Поскольку у меня была userdebug сборка, то я мог, в том числе и изучить и придушить под рутом то, что работает прямо из системы - разные сервисы для airplay и прочее. Но, удивительно, именно такие системные вещи не ходили в сеть совсем, это делали только стандартные приложения.
Ну а дальше, в такой чистой системе, сделать всё красиво - это дело техники и вашего вкуса.
Можно поставить проигрыватель для домашней медиатеки: Jellyfin, Plex и прочие вещи. Для локального проигрывания видео с носителя подойдёт Kodi.
Очень полезно поставить свободный клиент для Ютуба. Рекомендую https://github.com/yuliskov/SmartTube - великолепный, простой и удобный клиент, работает без Гугл сервисов, полностью вырезана реклама, в том числе интегрирован SponsorBlock, чтобы вырезать рекламу, которую блоггеры проговаривают ртом прямо в видео, нативные интеграции и прочее. Оригинальное приложение Ютуба лучше задушить.
Такие дела. Как я упомянул, мне очень сильно повезло с телевизором. Такие встречаюстя, но найти их не просто. На 4pda, если не ошибаюсь, есть даже отдельная тема про них. Честно говоря, я не думаю что это может быть массовым решением. Я лично самым оптимальным вариантом считаю покупку не телевизора, а ТВ-приставки + большой монитор, т.к. приставка - это, по сути, простая коробка с чистым андроидом, причём под некоторые из них можно даже собирать сборки самому, в которых можно контролировать буквально всё на 100%, и стоят они копейки, а монитор будет просто выводить картинку и не иметь никакой собственной "умной" логики.
Минус подобного подхода в том, что это будет дороже. Да, выглядит так, что производители телевизоров, похоже, зарабатывают с того, что пользователь получает ограниченную и неконтролируемую систему, поэтому "глупый" монитор будет стоить сильно дороже "умного" телевизора с аналогичной диагональню экрана. Но, говорят, что freedom is not free, так что куда деваться? :)
Приятно видеть что появляются такие проекты, сделанные людьми для людей. К сожалению, правильные, честные, выгодные для нас, людей, вещи можем сделать только сами мы, люди. Компании никогда на это не пойдут, государства тоже. Наши выгода и свобода - их убытки и потеря контроля. Огромный респект автору за работу! Очень важная, нужная и полезная вещь.
Я вот сейчас даже подумал о том, что здорово было бы накидать аналогичную историю для ряда приложений на андроиде. Сначала, допустим, в виде xposed модуля под рутованные устройства, а дальше на его основе можно и самостоятельные моды приложений делать, которые уже на любых устройствах будут работать без рута. Всё таки, по моим наблюдениям, для подобного шоппинга люди чаще пользуются именно смартфонами, а не браузерами
Кстати, добавлю ещё интересный момент конкретно про устройства 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 точно были в значениях соответствующих релизной сборке. Глубже я тогда копать не стал, т.к. к сожалению, не было достаточно свободного времени. Допускаю что может быть я что-то не так сделал или понял, но, возможно, это тоже было что-то из незадокументированных особенностей устройств производителя, которые автор происследовал в статье. И кто его знает сколько их ещё? И в ВанПлюсах, и не только.
Спасибо за интереснейшее исследование и отличную статью! Нечасто увидишь материал такого качества. В очередной раз убеждаюсь в том, насколько мутно и ненормально многие производители устройств реализуют логику загрузки операционной системы.
Если говорить в целом, то у Гугла предусмотрен интерфейс, через который предполагается управление статусом блокировки загрузчика и сопутствующих этому изменений. Это то самое "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 режиме тоже не просто так пишутся.
Справедливо. Если заглянуть в исходники, например, LineageOS, как одной из самых популярных альтернативных прошивок для Android устройств, в которой запись разговоров реализована из коробки в приложении для звонков, то можно увидеть, что у них там есть целая сложная система определения того где именно сейчас вероятно находится устройство, по нескольким разным параметрам (кажется по локали, геолокации и принадлежности оператора сим-карты), чтобы выдать вердикт - разрешено ли прямо сейчас активировать фичу записи разговоров или нет. Там прям в ресурсах приведены комментарии для каждой отдельной страны со ссылками на законы и другие НПА.
Проблема в том, что, например, в РФ запись звонков законом не запрещена, однако фича всё равно не активируется. Приходится поправить код в месте проверки разрешения на запись звонка, захардкодить там true в месте проверки, собрать систему руками, и вот только тогда запись разговоров появляется как доступная опция в приложении телефона. И то она не активируется автоматически, необходимо самостоятельно нажать руками кнопку записи в процессе звонка, после поднятия трубки, что очень легко забыть сделать.
И не только Гугл, с Эплом аболютно то же самое. Вообще, мне кажется, что телефонный и СМС спам существует по большей части только благодаря тому, что производители мобильных операционных систем всячески не дают возможности своим пользователям нормально контролировать всё что касается телефонной связи на их устройствах.
Сейчас хотя бы определение спам звонков более менее стабильно работает, потому что это не функционал из системы, а появилось АПИ которым могут воспользоваться сторонние разработчики и сделать всё красиво, но, всё равно, ОС не дают возможность обработать звонки корректно - не сбрасывать звонок, а просто игнорировать, чтобы пробивщики не отметили у себя ваш номер как "живой". И всё равно при этом вы увидите сам звонок, хоть и с пометкой "спам", и получите в приложении телефон уведомление о том что вам звонили, и запись о пропущенном звонке будет в списке пропущенных. Не знаю как сейчас, но несколько лет назад запись звонков, чтобы иметь возможность потом легально предъявить что-то на недобросовестных рекламщиков, тоже отсутствовала из коробки, и в абсолютном большинстве случаев она вообще не реализуема без root/jailbreak. Просто смех - приходится натурально ломать систему, чтобы получить абсолютно базовый функционал, наличие которого само по себе разумеется в, казалось бы, умном телефоне.
То же самое с СМС - вам не дают нормально блокировать СМС по ключевым словам или каким-то другим признакам и как-то гранулированно настраивать то, что именно вы хотите получить, а что нет. Вы в любом случае получите всё. Даже если вы "заблокируете" какого-то одного отправителя, то СМС от него всё равно будут приходить, просто вы не будете моментально видеть уведомления о доставке, но вы всё равно получите тихое уведомление, они всё равно попадут в список принятых и вы всё равно прочитаете их когда вам придётся руками их удалять. И опять же, чтобы получить возможность настроить такие простые вещи необходимо даже не просто root получать, но ещё и ставить отдельный модуль переопределяющий логику работы системы.
Механизм работы Zygote позволяет оптимизировать запуск приложений, но обладает и недостатками. Например — раз этот процесс является базовым для всех приложений, то можно заразить его трояном, который затем прорастет в каждое приложение. Так работает один из самых страшных троянов в Android — Triada. А делать он может всё что угодно — например, перехватывать и читать ваши смс. Вывод банальный — не стоит устанавливать на устройство приложения из сомнительных источников.
Не только малварь, но и вполне популярные опенсорсные инструменты для динамической инструментации и модификации поведения андроид фреймворка используют внедрение в процесс приложения в момент форка зиготы. Это может быть полезно как для исследователей, так и просто для продвинутых пользователей андроида.
Исследователей интересует возможность заглянуть под капот работающим процессам, исследовать механизмы работы приложений, техники внедрения зловредов, и т.д. Продвинутых пользователей, например - дать щелбан по носу чересчур любопытной операционной системе и системам трекинга и аналитики, собирающим и отправляющим 24/7 информацию о каждом чихе сделанном пользователем на устройстве, которые сейчас встроены в 99% андроид приложений, или починить в системе что-то, что Гугл упорно не хочет исправлять, например систему пермишенов, или никогда не будет исправлять, например то, что помогает им собирать информацию о владельце устройства. Ключевая идея - иметь возможность выполнить произвольный код или переопределить поведение интерфейса системы ДО передачи управления запущенному процессу.
Единственный нюанс - заинжектить некую кастомную логику ДО форка процесса без рута или хотя бы разблокированного загрузчика и отключённой доверенной загрузки не получится, т.к. это требует изменений на уровне системы. Все популярные инструменты для управления рут доступом имеют модули, которые позволяют удобно организовать внедрение в зиготу, но у обычного непривелегированного приложения так сделать не получится.
Проект, вне всякого сомнения, нужный и правильный. На самом деле, я тоже давно подумываю о том, что необходимо собрать на базе Графена мод, в котором уши Графена торчать наружу не будут, а всё будет максимально похоже на стоковую систему, плюс передать контроль лично пользователю за разными вещами, вроде данных, на основе которых составляется фингерпринт, или того же plausable deniability. Эти штуки Гугол не исправляет, и никогда не исправит - потому что они нужны для массовой слежки и для своих полицаев в США, а команда Графена с таким заморачиваться не хочет - ей интереснее работать над более фундаментальными вещами.
Не буду присоединяться к едким комментариям выше по поводу того, что это просто оверпрайснутый перекрашенный Графен.
Любая работа в направлении создания андроид прошивки, в которой на первое место ставятся интересы людей, владельцев устройств, а код шарится для сообщества (пусть пока и в таком виде, без серверной части) - это благое дело, и Графен здесь - самый лучший фундамент, на котором можно строить что-то дальше. Было бы очень странно выбирать за основу что-то другое.
А оверпрайс - просто следствие того как устроен мир, в котором мы сейчас живём. Мне, как человеку, который тоже велосипедил в своё время форк АОСПа с уклоном в безопасность, было очень тяжело в своё время зайти в тупик, в котором оказывается абсолютное большинство авторов таких проектов - работа эта сложная и неблагодарная. Она требует квалификации сильно выше обычного рядового андроид разработчика, плюс сжирает невероятное количество времени и сил, и вот ты уже стоишь перед выбором, где на одной чаше весов ты - вольный творец, рвёшь жилы и посвящаешь всё своё время и силы такому вот проекту, но в какой-то момент тебя, уставшего, и без гроша в кармане, семья спрашивает "папа, а что мы сегодня будем кушать?", а на другой - ты откладываешь мечты о светлом и справедливом будущем для всего человечества в долгий ящик, и идёшь красить кнопки в каком-нибудь скучном маркетплейсе или перекладывать джейсоны в джейсоны в унылом бигтехе, тратишь в 10 раз меньше сил и просто живёшь хорошую спокойную жизнь без финансовых проблем. Сделать выбор в пользу первого в таких условиях - очень непросто. Честно признаюсь, я с удовольствием бы поработал над подобным проектом, даже за деньги ниже рынка, с условием если бы результат моей работы гарантировано пошёл в опенсорс. И я знаю, что таких как я немало.
Пусть сегодня за этот оверпрайс заплатят условные владельцы заводов-газет-пароходов, а завтра, благодаря им, вырастет популярность, массовость, спрос, и появятся уже новые решения, более доступные и более открытые, и обычный работяга сможет наконец позволить себе нормальный безопасный телефон, на нормальной безопасной прошивке. Пока же, в нынешних условиях, этого не может себе нормально позволить практически никто.
В общем, я рад что таких проектов становится больше. Успехов!
К сожалению, этого не достаточно. Процесс приложения на Андроиде может быть неявно запущен через ВоркМенеджер, отложенный аларм, полученное пуш-сообщение, или бродкаст и т.д. После чего оно может спокойно сходить в сеть, не стартуя экран, не показывая уведомления, и т.д. Самое печальное - никаких нормальных способов гарантировано предотвратить это не существует.
Я пробовал экспериментировать с тем чтобы через настройки разработчика ограничить количество фоновых процессов в 0, и вроде бы оно даже работает, но нет гарантии, что оно будет единообразно работать у всех вендоров, к тому же лимит, насколько я помню, поставить можно только на всю систему сразу, а не на выбранные приложения, и это создаёт неудобства.
Ещё можно disable-ить приложения через pm, и активировать только когда потребуется, но это необходимо делать через adb, не знаю возможно ли подобное удобно сделать в рамках фреймворка без какой-то local adb прослойки. И опять же - неудобно, т.к. приложение полностью визуально пропадёт из лаунчера.
Даже в кастомных прошивках эту задачу решить не так просто, ну или может быть это я отстал от новинок прошивкостроения
Вам не показалось.
Оборудование для цензуры вынуждено обрабатывать огромное количество сетевых соединений и из-за этого постоянно находится под огромной нагрузкой, т.к. оно вынуждено заглядывать в хендшейк каждого соединения, которых даже в рамках одной страницы браузера могут открываться десятки, и это всё на многие миллионы устройств подключённых к сети. Неудивительно, что такое количество лишней работы приводит к тому, что соединения подолгу, по несколько секунд или даже десятков секунд могут висеть в очереди, из-за чего даже на одобренных партией российских ресурсах всё страшно тормозит.
Как только с вами случается "Внезапный Переезд в Нидерланды", у вас фактически, с точки зрения ящиков цензуры, становится ровно одно сетевое соединение, а не десятки или сотни как ранее. Вы его открываете один раз, один раз проходите цензуру, выходите наружу, после чего все другие соединения у вас уже идут внутри первого, без анализа, и соответсвенно всё действительно начинает работать с нормальной скоростью, как и должно.
Заходил сюда чтобы написать этот же комментарий
Тоже выступаю за то, чтобы каждому иметь подобный селфхостед сетап, и сам пользуюсь похожим, однако должен предупредить - при белых списках это работать не будет.
Не знаю как оно в столицах и городах-миллионниках, но в моём плебейском регионе государство уже какое-то время назад включило на мобильных сетях режим хуже чем в Туркменистане, и доступ даже к российским ресурсам не работает - нет доступа ни к популярным российским VPS провайдерам (если вы хостите ПО в каком-нибудь Селектеле), ни к блокам адресов ISP (если у вас белый адрес от провайдера), ни, что забавно, даже к большей части, собственно, самого белого списка - банки не работают, большинство российских сервисов тоже, из того что работает получилось найти только яндекс и макс. Разумеется, всё селфхостед также недоступно.
Я думаю, что это вопрос нескольких месяцев, максимум полугода, когда чебурнет подобного уровня начнут включать на проводных провайдерах и по всей стране, так что я вот сам подумываю о том, что надо бы скорее пилить мод для макса - использовать его чисто как транспорт и накрутить свой слой end-to-end шифрования сообщений и звонков. На более далёкую перспективу это выглядит более надёжным решением
Ох, не знаю. Я пока "вжухами" не пользовался, но в своё время довелось довольно много поработать с системами СКУД, эмуляцией разных карт-пропусков и т.д. и вот там эта проблема стояла в полный рост ещё 8 лет назад, и там тогда же наступили на те же самые грабли. Суть такова:
В Андроиде есть нормальное человеческое API для работы с NFC. В обе стороны. Вы можете произвольно работать в качестве "ридера" с тэгами на низком уровне - гонять вот прям нужные вам байтики туда-сюда - отправлять команды картам, и т.д. Вы также можете произвольно работать с ридерами будучи "тэгом", т.е. произвольно эмулировать тэги, которые соответствуют стандарту ISO-14443 и имеют систему команд соответствующую ISO-7816, также полностью определять какие именно байтики будут передаваться. Да, там есть куча неприятных мелких ограничений, не все из которых даже зафиксированы в документации, как это часто бывает у Google, но эмулировать платёжный протокол EMV технически возможно. Да, эта эмуляция получается технически не очень безопасной, в отличие от Google Pay, который лучше сынтегрирован с системой и аппаратным кейстором, однако НСПК, обмазавшись массой защит и предупредительных мер, всё-таки взяли и выкатили свою реализацию эмуляции карт и всё это на Андроиде отлично работает.
В iOS с NFC всё довольно грустно. Несмотря на то, что, чисто технически, Apple Pay появился и заработал раньше чем любое решение на Андроиде, Apple ну очень сильно не хочет делиться возможностью нормально работать с NFC, потому что у них есть платное партёрское API с доступом для избранных, а всё что касается платежей вообще огорожено страшным забором и бюрократией. Поддержка NFC вводилась очень постепенно. Сначала появился верхнеуровневый API для чтения NDEF-форматированных тэгов, причём читались тэги в основном плохо, и не от всех производителей. Потом появилось чтение в бэкграунде. Потом Apple наконец-то разродились нормальным API для работы с ISO-14443/ISO-7816 тэгами на низком уровне в режиме "ридера" - т.е. в этой части в iOS в принципе сейчас полноценный паритет по возможностям с Андроидом. Однако вот с API для эмуляции, насколько я знаю, всё ещё всё очень трудно и грустно. Apple действительно выпустили его год назад или типа того, и на нём действительно можно сделать условный МирПей, однако разрешено это пока что ТОЛЬКО для европейского региона, т.к. те всё таки смогли прогнуть Apple многомиллиардными штрафами за огораживание своей платформы, и главное - для этого нужно получить специальный энтайтелмент, который, как утверждают, Apple снова, как всегда, выдаёт только избранным, и отказывает в 99% случаев всем ссылаясь на какие-то мутные требования. Т.е. по факту адекватного, открытого и универсального механизма всё ещё нет.
Так вот, лет этак 8-10 назад многие СКУД системы очень хотели интеграции с уже ставшими очень популярными смартфонами, чтобы "тык" на замок можно было делать не только карточкой, но и телефоном. Реализовать подобное на Андроиде - не сложно, я даже сам не раз писал руками эмуляции разных тэгов, а вот реализовать на iOS было просто технически невозможно, а продавать эту фичу ну очень хотелось. Но вот беда - все директора и ЛПРы, которым эту фичу можно прорекламировать ходят с айфонами. Что делать? Придумали как раз колхозить эмуляцию "проксимити" через болезный Bluetooth Low Energy. Болезный - потому что страшно тормозной и ненадёжный, а классический старый Блютус на iOS ТОЖЕ огорожен и чтобы получить возможность им пользоваться нужно либо, как всегда с Apple, быть избранным, либо заносить им кучу денг за прохождение сертификации и тоже абсолютно без гарантий. В итоге все начали делать велосипеды с BLE, где считали RSSI и понимая по уровню сигнала, что ридер и устройство где-то рядом, эмулировать тот же самый опыт с "тыком" в замок, только сложный аки та самая машина Гольдберга.
По итогу, схема в целом рабочая, но пользоваться этим не нравилось никому. Блютус мог либо не подключаться когда нужно, либо подключаться "мимо" - к другому устройству, либо подключаться слишком долго и человек стоял секунд 10 перед замком тыкая в него телефоном (хотя там не NFC, что тыкать то?), либо тормозила сама связь, либо коннект не успевал от одного замка к другому переподключиться если двери были рядом. Чаще всего также необходим был запуск приложения прямо перед использованием, и Блютус очень плохо работал в фоне. Это я даже не вспоминаю про безопасность на прикладном уровне, с которой тоже иногда были интересные приколы. Сейчас это уже не так актуально, но до Блютуса 4.2 существовали техники даунгрейда соединения до незашифрованного, а поскольку это именно Блютус, а не честный NFC, суть которого в том, что связь производится вот здесь и сейчас, по месту, то можно было, в теории, с нескольких десятков метров вылавливать BLE коммуникацию по радио, а с безопасностью на прикладном уровне, как я упомянул, не всегда всё было супер.
Я не знаю сохранились ли эти самые проблемы сейчас, но тогда ничего кроме бесконечного вороха проблем этот подход "притвориться NFC через Блютус" не приносил. У меня есть подозрения что часть того, о чём я написал сверху запросто может случаться и на "вжухах".
Я тогда, помню, сгорев со всех этих проблем, реализовал концепт того, что вот накинули в комментариях выше хабровчане - настоящую работу, по настоящему честному NFC, но только наоборот - ридер мог быть не только ридером, но и притворяться "тэгом", и там уже между ними был свой протокол, абсолютно аналогичный тому что использовался в картах и в Андроиде, но только айфон должен был передавать своего рода "запросы на команды". Я тогда сильно топил именно за такой путь, тем более что его суперпросто реализовать когда терминальное оборудование на Андроиде (не нужны модификации прошивок и железа), но в компании мне добро на реализацию не дали. Мне кажется, я также несколько лет при каждом удобном случае рассказывал про эту идею всем на конференциях, но так ни в ком, наверное, интерес разжечь и не смог - все продолжают водить хороводы вокруг Блютуса
О, спасибо большое за интересную тему! Я довольно глубоко погружён в тему безопасности в Андроиде, и много игрался, в том числе, и с тем, чтобы насколько это возможно скрывать критически важные значения секретов внутри приложения, если их локального хранения никак нельзя избежать. Тоже горячо сам рекомендую всем скрывать значимые строки в приложениях, раз уж за нас этого не делает ни Гугл, ни proguard/r8, а работу реверсеров, автоматизаторов и разных других людей это упрощает на порядок.
Хотел набросить пару мыслей и вопросов по результатам прочтения статьи.
(1) Компилятор будет играть в эту игру против нас. Подобный код будет, с точки зрения компилятора, выглядеть как неэффективное вычисление и может стать очевидной целью для оптимизации. Соответсвенно, если оптимизатор по нему проедется, то выглядеть в получившемся байткоде это может сильно проще, чем это задумывалось на уровне исходников. Так декомпилятоы ещё и дополнительно попробуют привести байткод в упрощённый псевдокод, что ещё может ещё дополнительно облегчить задачу.
Вы проверяли что на уровне байткода это точно будет иметь достаточную сложность в плане реверса? Я вижу что в функции восстановления строки используются довольно замороченные операции с байтами и смещениями, поэтому полагаю, что да, проверяли, т.к. искали способ сделать код, который не будет автоматически оптимизироваться, но всё равно интересно было бы получить ваш комментарий.
(2) Вторая мысль аналогична предыдущей, но только теперь по стороне ДЕкомпиляторов. Коммерческие декомпиляторы, например JEB, содержат целый ряд модулей которые также находят и оптимизируют уже прямо dex-байткод, если видят что он без сайдэффектов, и часто могут некоторые промежуточные значения безопасно предвычислить. Модули включают в себя раскрутчики безсайдэффектных методов возвращающих булеаны, строки, разные оптимизаторы, конкатенаторы, дерефлекторы, и т.д. Довольно нередко JEB может автоматически раскрутить подобные защиты, и реверсер даже не узнает что они были в приложении. Мне в своё время даже пришлось посидеть, подумать, попрорабатывать разные подходы для того, чтобы не давать работать по байткоду подобным оптимизаторам.
Интересно узнать, довелось ли вам проверить решение на устойчивость к подобным инструментам?
(3) Третья мысль, или скорее наивный вопрос - не думали насчёт того, чтобы воспользоваться готовыми решениями? Я вот пробовал и всем рекомендую https://github.com/LSPosed/LSParanoid - отличный простой и хорошо поддерживаемый gradle плагин, который работает полностью локально - сам модифицирует байткод, заменяя опкоды создания строковых констант на статические инвоуки к классу, который он генерит и вносит в декс сам. Получается, что ничего самому не нужно тянуть, собирать, подменять. Достаточно только отметить в конфиге и/или аннотациями строки, которые необходимо скрыть и всё. Результат - очень даже неплох.
Ну и, конечно, никак нельзя не затронуть вопрос анализа в динамике. Это уже, конечно, немного в сторону тема, но скорее всего исследователь будет пытаться выломать строки именно с помощью различных инструментов динамической инструментации. Почти все подобные решения создают единую и легко обнаруживаемую точку расшифровки, а современные декомпиляторы, даже jadx, умеют в один клик создавать сниппеты для frida и xposed. Против такого уже простых решений нет, но интересно узнать, прикручивали ли вы что-то подобное в довесок к обфускации строк?
Спасибо большое ещё раз за статью! Было бы здорово видеть на Хабре темы про безопасность мобилок почаще
Как будто бы для этой задачи идеально подходит ставшие актуальными в последние годы прокси с xtls-reality, т.к. они делают как раз то, что описал автор статьи - принимают соединения с нужным SNI и проксируют их наружу (ну и защита от active-probeing-a, хоть и не принципиальная конкретно в этом случае будет как бонус). Гуглите в сторону слов "xray" и "reality".
Если система в самолёте НЕ проверяет соответствие адресов доменам, то можно без проблем поднять у себя на своём сервере с условным адресом 12.34.56.78 сервер, который будет правдоподобно представляться wa.me, и даже честно перенаправлять соединение на настоящий wa.me в случае неправильного хендшейка, но только для вас он будет точкой выхода трафика наружу. Ставится это дело за полчаса, клиенты настраиваются под любую десктопную и мобильную ось
100%. Только хотел написать об этом. Бывал там, видел цены на дома в объявлениях и много наслышан о кризисе недвижимости. 22% экономии - это всё равно ничто на фоне сложившейся ситуации. Причём, я абсолютно уверен, что подобные технологии НЕ снизят стоимость для конечного покупателя, потому что корни кризиса недвижимости растут совершенно НЕ из того, что стране не хватает кирпичей.
Такие технологии однозначно удешевят производство для застройщика, он сможет здорово экономить на сырье, очень значительно сэкономить на оплате труда рабочим, но кто сказал что он вдруг станет продавать дома дешевле? Я уверен, что дома останутся такими же недоступными, а скорее даже станут ещё более недоступными для населения, т.к. у людей станет меньше покупательная способность (спроса на рабочие руки то станет меньше), только они станут при этом ещё и значительно хуже по качеству, а вот и без того гигантская сверхприбыль застройщиков вырастет ещё выше.
Приветствую! Благодарю за интерес к статье и комментарии с правильными мыслями, прочитал - всё по делу.
С момента написания статьи прошло уже практически 5 лет и с тех пор многое изменилось. Изменилось, к сожалению, только в худшую сторону. Гугл взял глобальный курс на довольно странные цели. Сам Андроид перестал прирастать прорывным функционалом, и начал всё больше окукливаться в закрытую, во всех смыслах, систему, наподобие iOS. Вендоры стали всё больше наглеть и навязывать пользователям всё больше мусора. Приложения, рекламные и фингерпринтные/трекерные СДК в среднем стали сильно сильно более инвазивными. По всему миру вышел ряд неприятных законов, легализующих и нормализующих массовую слежку, а с развитием LLM масштаб вторжения в личную жизнь пользователя вышел на принципиально новый уровень.
В своё время, статья была написана не столько для "power user"-ов, которые знают что делают и могут обеспечить себе должную безопасность самостоятельно, сколько для обычных людей - для того чтобы массовый пользователь преследуя, абсолютно правильно и справедливо, реализацию своих прав на свободу и конфиденциальность, но не разбираясь в теме, в инструментах и их ограничениях, не подставил себя под ещё большую угрозу чем раньше. В те времена я однозначно рекомендовал обычным людям выбирать устройство с максимально чистой системой, по максимуму вычистить телефон от блоатвари через adb, а дальше просто поддерживать адекватный уровень цифровой гигиены, не устанавливая на устройство откровенный мусор, а тот, который всё-таки необходимо установить, стараться держать в отдельном окружении.
Честно говоря, сейчас я уже не уверен что этого будет достаточно. С тех пор я сам стал использовать больше "power user"-ских инструментов, пересел на кастом, однако я отдаю себе отчёт о том, что не могу рекомендовать то же самое для обычных пользователей, которые не увлекаются безопасностью и не желают тратить время на то, чтобы действовать на этом поле проактивно.
Из интересного, что я открыл для себя лично, но что ПОКА не могу рекомендовать на 100% остальным (но смогу, после определённой доработки идеи) - это правильно сделанные репаки, в которых мусор от производителя вырезан на уровне байткода. Так получилось, что я для себя накидал простенький инструмент, который делает это - распаковывает приложение, вырезает из него код рекламы, трекеров, и т.д, подменяет в логике запросов идентификаторов настоящие данные на случайные, и т.д и, должен сказать, мне очень понравился результат. Более того, огромное количество хороших репаков уже существует. Проблема в том, что с репаками возникает проблема с доверием, т.к. теперь вместо того чтобы доверять разработчику приложения, необходимо будет доверять разработчику мода, и нужен бы правильный механизм, который бы криптографически гарантировал то, что в ходе репака были добавлены/модифицированы/вырезаны только определённые вещи, связанные например со слежкой, но НЕ было внесено никаких других изменений. У меня уже есть идеи и схема как можно было бы сделать процесс модификации байткода, и дальнейшей публикации модов полностью автоматизированным, прозрачным и доверенным, но нужно время на реализацию. Надеюсь дойдут руки сделать. Дело важное и нужное, оно бы позволило людям пользоваться более безопасными приложениями массово.
Всё это, разумеется, полумеры, и по настоящему нужно вкладываться в то, чтобы в сам АОСП добавить возможность пользователю полноценно управлять происходящим на своём устройстве - т.е. чтобы фаервол, гранулированный контроль соединений по доменам, xprivacylua, решения о том, какие именно данные об устройстве показать приложению, а какие нет, и не через существующую систему пермишенов, которая даёт возможность приложению заблокировать свою работу в случае неполучения разрешений, а именно через контроль на стороне пользователя, и прочие вещи работали прямо из самой системы. Чтобы это было не РЕактивное действие - где я перекрыл доступ к тому что получилось, но трекеры всё равно через разные грязные хаки добрались до данных и слили всё на бэк, или я забыл ограничить доступ и при первом запуске оно уже всё собрало и отправило, а ПРОактивное действие, в котором приложение по умолчанию не видит в системе вообще ничего и не может сходить вообще никуда, и сначала я смотрю что именно хочет получить приложение и куда собирается отправить, и только после моего явного разрешения оно получит или не получит возможность сделать это. Вот это самый правильный путь.
Мне кажется, в таких вот "вечных" решениях самое главное - следовать за деньгами. Лично мне буквально первая же мысль, которая приходит в голову - "а кто за эту вечность будет платить?"
Заказать с доставкой роутер, прошить ОпенВрт, настроить на нём ВГ подключение к заранее подготовленной ВПСке, найти клиента, отправить ему оборудование - это всё запросто займёт половину работчего дня. Сама часть настройки - простая, но вот вся беготня вокруг точно сожрёт время. Эти прошитые роутеры, по сравнению с просто подержанными роутерами которые продаются на авито, практически не имеют никакой наценки. Мне сложно поверить в то, что те кто их делает готовы тратить по полдня ради наценки в 1000 рублей, плюс ещё и оплачивать потом аренду сервера.
Если представить себя на месте злоумышленника, то за такую благотворительность они явно захотят вернуть деньги, и самое очевидное и напрашивающееся, это, конечно же, резидентные прокси, а по простому - отмывание трафика. Т.е. злоумышленники продают десятки и сотни подобных роутеров, на них настроен ВПН с возможностью подключения от ВПС к домашнему роутеру счастливого покупателя, поднимают на этом самом роутер пускай тот же Ваергард, но уже сервер (можно даже не светить его в вебморде в люсе), на стороне ВПС настраивается проброс портов, а дальше продаётся доступ к нему уже настоящим клиентам, а не лицам обманутым хулиганами, которым почти бесплатно подарили "роутер для ютуба".
Выход в сеть с подобных адресов - это очень ценная и очень недешёвая услуга, т.к. эти адреса - "чистые", принадлежат блокам провайдеров, т.е. предполагается что за ними сидит настоящий человек, не робот, не программа, соответсвенно, они очень очень нужны разным людям, которым необходимо скрыть свой настоящий адрес, но при этом не спалиться антифрод системам на выходе из прокси, ВПНа или ТОРа. Такое нужно как разным темщикам, авторегам, мультаккаунтерам, так и мошенникам, и хакерам, особенно тем, кто атакует российские сервисы, и т.д. Сами понимаете, что в случае последнего полицаи с бутылкой придут именно за счастливым владельцем роутера для ютубчика, и, скорее всего, именно на него скинут всю уголовную ответсвенность за противоправный движ, который прошёл через его адрес.
Поинтересуйтесь, сколько стоят резидентные прокси. Даже в России, самая минимальная их цена будет выше, чем цена за ВПН для того чтобы смотреть ютубчик. На них также обычно тарифицируется трафик, и продаётся по одному или несколько гигабайт, так что только один клиент может приносить тысячи рублей в месяц за один такой прокси. А если брать максимально чистые провайдерские резидентные адреса, да ещё и в самых чистых странах, да ещё и мобильные, то цены запросто могут быть по несколько десятков долларов за один-два гигабайта трафика.
Даже если мы посмотрим на совсем мелочи. Вот конфиг ваергарда например. Там явно было искусственно сделана возможность проброса доступа к продаваемому роутеру, ведь заизолировать клиентов - не сложно, более того, они даже по умолчанию изолированы друг от друга. Т.е. кто-то явно прописал адрес для пира на роутере с маской, условно, /24, хотя по умолчанию идёт именно /32 и никакие другие клиенты этой сети маршрутизироваться не будут, кто-то явно прописал правила в iptables, которые дают одним клиентам сети иметь возможность форвардинга к другим, т.к. в самом тупом конфиге по умолчанию (всё на выход) этого не подразумевает. Через VLESS, кстати, при желании обратный прокси тоже реализуется.
Допускаю, что во мне говорит моя профдеформация безопасника, и люди кто делают эти роутеры на самом деле занимаются благотворительностью, или просто создают доступную по цене услугу под ключ для сограждан, которые не обладают достаточной технической грамотностью в вопросе сетей. Но, говорят, когда что-то ходит как утка, плавает как утка, крякает как утка и летает как утка, то это скорее всего утка.
Домашний роутер - устройство очень интимное. От него зависит очень многое в личной безопасности, и такое устройство необходимо контролировать самостоятельно. Доверять каким-то мутным людям со, скорее всего, недобрыми намерениями, вроде продавцов с авито или интернет провайдеров иметь контроль над ним - очень плохая идея
Как же приятно было увидеть это расследование в СМИ, и то как сильно оно вышло на общественное обсуждение.
С самого появления Телеграмма я рассказываю всем друзьям и знакомым про то, что в Телеграмме сделано плохо буквально всё: от мутного протокола с местами странными подходами для технической реализации того или иного функционала и абсолютно дырявых настроек по умолчанию, до непрозрачного финансирования и того что Телеграм взлетел исключительно на хайпе разгоревшемся вокруг публичного образа, который построил себе Дуров. Да, в общем то, огромное количество людей говорило об этом, просто их голоса заглушало мнение широких масс общественности "Ты что? телеграмм - это же безопасно! Так сам Паша Дуров сказал, а видел какой он молодец?".
Когда же вдруг за границей, где о личности и популярности Дурова никто не знал, проводили сравнительную оценку безопасности различных месенджеров, и оценивали конкретно технические аспекты каждого из популярных решений, то все эксперты единодушно сходились во мнении, что пользоваться таким сомнительным продуктом как Телеграм для безопасного общения нельзя, категорически, потому что если мессенджер объявляет себя безопасным, то ТАК он быть устроен не может.
Если раньше на мои аргументы люди обычно просто пожимали плечами и говорили что "Ну, это наверное твои заморочки и профдеформация как безопасника", то теперь, после публикации в СМИ, есть шанс, что о проблеме задумаются многие
Тоже пользуюсь сертификатами подписанными собственным корневым ЦС для селфхостед сервисов, которые предназначены для личного использования.
Сталкивался с аналогичной проблемой, и, если я правильно помню, я добавил CAA запись в DNS для своего домена, с данными CN своего ЦС. Тогда браузеры, в том числе сафари, перестали выёживаться
Ооооо, моя остановочка. Вообще, я смарт тв не пользуюсь, но как-то раз он был у меня на одной из съёмных квартир, так что была возможность посмотреть и изучить что там и как работает.
Мне очень повезло. Внутри моего был Андроид. Более того, этот Андроид был практически чистым, и даже более того - это была отладочная сборка, на которой можно было получить рут, но обо всём по порядку.
Логично, что почти любое современное "умное" устройство - это, как правило, помойка с круглосуточной слежкой и впариванием сомнительных услуг. Телевизоры в этом плане не исключение. Хотелось бы, вместо всего этого, иметь просто телевизор, без всего лишнего, т.е. получить систему как можно более простую, свободную, разгруженную от мусора, который туда щедро навалил производитель.
Мой телевизор, конечно же, исключением не был, и содержал целую кучу блоатвари, рекламы, всякого мусора, и т.д. К счастью, поскольку этот телек был простой и дешёвый, прям из супер-эконом сегмента, то и андроид там был самый простой, а значит на нём можно было активировать adb по tcpip, а значит на нём можно было запустить и обычные андроидные деблоатеры, которые могут удалить большинство приложений, а системные - выключить и задушить через pm disable. Вообще, топовые производители современных телевизоров делают многое для того, чтобы вы не имели возможность это сделать, по максимуму зарезают возможность получить adb доступ, и т.д - будьте внимательны.
Отсюда не самая очевидная рекомендация - для приватности однозначно лучше будут ноунейм телевизоры, т.к. крупные вендоры просто не дадут вам выключить ни слежку, ни рекламу, ничего. Блокировать соединения по DNS на уровне роутера, к сожалению, как и в случае со многими другими умными устройствами почти бесполезно, т.к. хостов слишком много, все не выловишь, с обновлениями прилетят новые, плюс, как писали в комментариях выше, производитель может заблокировать работу устройства если оно слишком долго не докладывает в штаб. Проблему надо решать на корню. А если нет adb, то производителя телевизора никак не переиграешь.
Собственно, имея adb и возможность установки приложений по adb я направил трафик на прокси, посмотрел куда вообще пытаются стучаться приложения. Потом даже не поленился, сдампил родные приложения и перепаковал и переустановил их с подсунутыми сертификатами, чтобы изучить трафик. В целом - ничего неожиданного.
Куча приложений желает работать в бекграунде и ходить в сеть на мутные китайские ресурсы. Здесь иронично то, что из-за крайне слабого железа (что-то вроде смартфона из начала 2010-ых на примерно 4-ом андроиде), их почти сразу же прибивает система, т.к. они жрут ресурс. Плюс, похоже, на андроид тв по сравнению со смартфонами сильно строже ограничение по запущенным бекграунд процессам. В принципе, это большой плюс. Опять же, имея доступ к настройкам разработчиков можно вообще его выставить в 0, т.е. по сути разрешив работать только тому приложению что находится на экране прямо сейчас.
К счастью, почти все мусорные приложения можно было удалить через pm, но вот в одну проблему всё равно утыкаешься серьёзно - это лаунчер. В силу своей сути, работает он постоянно и часто, и в бэкграунде тоже, и вот именно он шлёт в сеть большую часть всего мусора и телеметрии, именно он реально загаживал весь лог в прокси под крышку, и в нём же показывалась реклама.
Что можно сделать? Поставить опенсорс лаунчер, конечно же! А родной можно задушить через pm disable. Главное действовать осторожно. Сначала ставим лаунчер, потом и в настройках, и в adb переводим новый лаунчер в дефолтный, и только потом душим системный. Теперь у вас новый лаунчер будет открываться при запуске телевизора и при нажатии центральной кнопки на пульте.
Я рекомендую попробовать приложение FLauncher (https://gitlab.com/flauncher/flauncher), но только что глянул, есть его очень хорошо выглядящий форк (https://github.com/4v3ngR/aLauncher) с рядом дополнений, в котором вырезано даже то немногое что было в FLauncher-e (firebase, unsplash для обоев, итд). Это минималистичный, простой и приятный лаунчер. Просто главный экран устройства, без лишнего мусора.
После этого в прокси стало видно что практически никаких мусорных запросов больше нет. Лаунчер отправлял в районе 99% из них. Далее, когда я удалил все возможные пакеты, я также задушил полностью все ненужные системные, все что относились к Гуглу, кастомные сервисы, и т.д. мусорные запросы пропали совсем. Если на телевизоре ничего не нажимать, не запускать приложения то сеть просто молчит.
Поскольку у меня была userdebug сборка, то я мог, в том числе и изучить и придушить под рутом то, что работает прямо из системы - разные сервисы для airplay и прочее. Но, удивительно, именно такие системные вещи не ходили в сеть совсем, это делали только стандартные приложения.
Ну а дальше, в такой чистой системе, сделать всё красиво - это дело техники и вашего вкуса.
Можно поставить проигрыватель для домашней медиатеки: Jellyfin, Plex и прочие вещи. Для локального проигрывания видео с носителя подойдёт Kodi.
Очень полезно поставить свободный клиент для Ютуба. Рекомендую https://github.com/yuliskov/SmartTube - великолепный, простой и удобный клиент, работает без Гугл сервисов, полностью вырезана реклама, в том числе интегрирован SponsorBlock, чтобы вырезать рекламу, которую блоггеры проговаривают ртом прямо в видео, нативные интеграции и прочее. Оригинальное приложение Ютуба лучше задушить.
Такие дела. Как я упомянул, мне очень сильно повезло с телевизором. Такие встречаюстя, но найти их не просто. На 4pda, если не ошибаюсь, есть даже отдельная тема про них. Честно говоря, я не думаю что это может быть массовым решением. Я лично самым оптимальным вариантом считаю покупку не телевизора, а ТВ-приставки + большой монитор, т.к. приставка - это, по сути, простая коробка с чистым андроидом, причём под некоторые из них можно даже собирать сборки самому, в которых можно контролировать буквально всё на 100%, и стоят они копейки, а монитор будет просто выводить картинку и не иметь никакой собственной "умной" логики.
Минус подобного подхода в том, что это будет дороже. Да, выглядит так, что производители телевизоров, похоже, зарабатывают с того, что пользователь получает ограниченную и неконтролируемую систему, поэтому "глупый" монитор будет стоить сильно дороже "умного" телевизора с аналогичной диагональню экрана. Но, говорят, что freedom is not free, так что куда деваться? :)
Приятно видеть что появляются такие проекты, сделанные людьми для людей. К сожалению, правильные, честные, выгодные для нас, людей, вещи можем сделать только сами мы, люди. Компании никогда на это не пойдут, государства тоже. Наши выгода и свобода - их убытки и потеря контроля. Огромный респект автору за работу! Очень важная, нужная и полезная вещь.
Я вот сейчас даже подумал о том, что здорово было бы накидать аналогичную историю для ряда приложений на андроиде. Сначала, допустим, в виде xposed модуля под рутованные устройства, а дальше на его основе можно и самостоятельные моды приложений делать, которые уже на любых устройствах будут работать без рута. Всё таки, по моим наблюдениям, для подобного шоппинга люди чаще пользуются именно смартфонами, а не браузерами
Кстати, добавлю ещё интересный момент конкретно про устройства 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 точно были в значениях соответствующих релизной сборке. Глубже я тогда копать не стал, т.к. к сожалению, не было достаточно свободного времени. Допускаю что может быть я что-то не так сделал или понял, но, возможно, это тоже было что-то из незадокументированных особенностей устройств производителя, которые автор происследовал в статье. И кто его знает сколько их ещё? И в ВанПлюсах, и не только.
Такие дела
Спасибо за интереснейшее исследование и отличную статью! Нечасто увидишь материал такого качества. В очередной раз убеждаюсь в том, насколько мутно и ненормально многие производители устройств реализуют логику загрузки операционной системы.
Если говорить в целом, то у Гугла предусмотрен интерфейс, через который предполагается управление статусом блокировки загрузчика и сопутствующих этому изменений. Это то самое "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 режиме тоже не просто так пишутся.
Справедливо. Если заглянуть в исходники, например, LineageOS, как одной из самых популярных альтернативных прошивок для Android устройств, в которой запись разговоров реализована из коробки в приложении для звонков, то можно увидеть, что у них там есть целая сложная система определения того где именно сейчас вероятно находится устройство, по нескольким разным параметрам (кажется по локали, геолокации и принадлежности оператора сим-карты), чтобы выдать вердикт - разрешено ли прямо сейчас активировать фичу записи разговоров или нет. Там прям в ресурсах приведены комментарии для каждой отдельной страны со ссылками на законы и другие НПА.
Проблема в том, что, например, в РФ запись звонков законом не запрещена, однако фича всё равно не активируется. Приходится поправить код в месте проверки разрешения на запись звонка, захардкодить там true в месте проверки, собрать систему руками, и вот только тогда запись разговоров появляется как доступная опция в приложении телефона. И то она не активируется автоматически, необходимо самостоятельно нажать руками кнопку записи в процессе звонка, после поднятия трубки, что очень легко забыть сделать.
И не только Гугл, с Эплом аболютно то же самое. Вообще, мне кажется, что телефонный и СМС спам существует по большей части только благодаря тому, что производители мобильных операционных систем всячески не дают возможности своим пользователям нормально контролировать всё что касается телефонной связи на их устройствах.
Сейчас хотя бы определение спам звонков более менее стабильно работает, потому что это не функционал из системы, а появилось АПИ которым могут воспользоваться сторонние разработчики и сделать всё красиво, но, всё равно, ОС не дают возможность обработать звонки корректно - не сбрасывать звонок, а просто игнорировать, чтобы пробивщики не отметили у себя ваш номер как "живой". И всё равно при этом вы увидите сам звонок, хоть и с пометкой "спам", и получите в приложении телефон уведомление о том что вам звонили, и запись о пропущенном звонке будет в списке пропущенных. Не знаю как сейчас, но несколько лет назад запись звонков, чтобы иметь возможность потом легально предъявить что-то на недобросовестных рекламщиков, тоже отсутствовала из коробки, и в абсолютном большинстве случаев она вообще не реализуема без root/jailbreak. Просто смех - приходится натурально ломать систему, чтобы получить абсолютно базовый функционал, наличие которого само по себе разумеется в, казалось бы, умном телефоне.
То же самое с СМС - вам не дают нормально блокировать СМС по ключевым словам или каким-то другим признакам и как-то гранулированно настраивать то, что именно вы хотите получить, а что нет. Вы в любом случае получите всё. Даже если вы "заблокируете" какого-то одного отправителя, то СМС от него всё равно будут приходить, просто вы не будете моментально видеть уведомления о доставке, но вы всё равно получите тихое уведомление, они всё равно попадут в список принятых и вы всё равно прочитаете их когда вам придётся руками их удалять. И опять же, чтобы получить возможность настроить такие простые вещи необходимо даже не просто root получать, но ещё и ставить отдельный модуль переопределяющий логику работы системы.
Печально.
Не только малварь, но и вполне популярные опенсорсные инструменты для динамической инструментации и модификации поведения андроид фреймворка используют внедрение в процесс приложения в момент форка зиготы. Это может быть полезно как для исследователей, так и просто для продвинутых пользователей андроида.
Исследователей интересует возможность заглянуть под капот работающим процессам, исследовать механизмы работы приложений, техники внедрения зловредов, и т.д. Продвинутых пользователей, например - дать щелбан по носу чересчур любопытной операционной системе и системам трекинга и аналитики, собирающим и отправляющим 24/7 информацию о каждом чихе сделанном пользователем на устройстве, которые сейчас встроены в 99% андроид приложений, или починить в системе что-то, что Гугл упорно не хочет исправлять, например систему пермишенов, или никогда не будет исправлять, например то, что помогает им собирать информацию о владельце устройства. Ключевая идея - иметь возможность выполнить произвольный код или переопределить поведение интерфейса системы ДО передачи управления запущенному процессу.
Единственный нюанс - заинжектить некую кастомную логику ДО форка процесса без рута или хотя бы разблокированного загрузчика и отключённой доверенной загрузки не получится, т.к. это требует изменений на уровне системы. Все популярные инструменты для управления рут доступом имеют модули, которые позволяют удобно организовать внедрение в зиготу, но у обычного непривелегированного приложения так сделать не получится.