Вероятно потому, что пока в Русторе не поддерживается разделение на сплиты. Приложения в Гугл Плей принимаются от разработчиков в формате app-bundle, а на устройство пользователя доставляются apk собранные конкретно под его устройство, т.е. имеющие ресурсы и код только под нужные архитектуру ЦПУ, плотность пикселей экрана, локализацию и т.д. Соответсвенно, без поддержки этих возможностей стор вынужден доставлять полный "толстый" апк, а те же нативные библиотеки под неиспользуемые архитектуры могут запросто весить несколько десятков мегабайт
Интереснейшая статья, настоящее техническое творчество. Спасибо!
Кстати, о проекте OpenIPC узнал не так давно и с огромным уважением отношусь к этой инициативе. Надеюсь однажды она разрастётся и станет чем-то вроде OpenWrt в мире WiFi-роутеров
Как человек участвовавший в проектировании и разработке карточных систем для общественного транспорта, я перевидал, перечитал документацию, прошивал и попробовал дюжину разных видов карт и никак не могу пройти мимо этой статьи.
Во-первых, как верно указали в комментариях, речь идёт об уязвимости почти 15-летней давности. Казалось бы, можно было сказать, что сейчас это уже никакого отношения к реальности не имеет, но нет. Подобные системы карт, так же как и карты в СКУДах, к сожалению, нередко завязываются на конкретное оборудование и экосистему, от которой потом крайне сложно отказаться и крайне болезненно уходить. Задачу свою она выполняет, а штучные "ломатели карт", как правило, не являются слишком большой проблемой, вот и тянутся эти проблемы из десятилетия в десятилетие, а во многих системах в ходу карты 15, 20, а то и 30 летней давности.
Корни этой проблемы тянутся из прошлого. К пониманию необходимости защиты карт, и отказа от использования принципа "security by obscurity" человечество пришло далеко не сразу, а карт и оборудования для них уже навыпускали. Компании спешили поскорее выкатить продукт на рынок, а не задумываться о том что в будущем у каждого студента будет в кармане проксмарк/флиппер/телефон с NFC который сможет взаимодействовать с их оборудованием, поэтому защиту в карты даже не закладывали.
Возьмите, например, те же СКУДы, где до сих пор массово используют emmarine карты, они вообще не предполагают никакой защиты и копируются в один тык на китайские болванки за пару десятков рублей. Плохо ли это с точки зрения безопасности? Однозначно! Такие системы используются в бизнес центрах, предприятиях, офисах компаний, и т.д. Но, как часто бывает, карта не является единственным фактором аутентификации, поэтому бизнес и государсто продолжают закрывать глаза на проблему и митигируют её сторонними способами. Например в московском транспорте отлично работает антифрод система, которая почти моментально заблокирует использование и оригинальной карты и дубликата. Ну а копировать карты с магнитной полосой - это вообще избиение младенцев. Разумеется данные на них никак не защищены.
Во-вторых, существуют современные карты, которые уже давно не болеют подобными детскими болезнями. Протокол общения с ними предполагает принудительную двухстороннюю аутентификацию, использование признаваемой надёжной во всём мире криптографии, шифрование и подпись каждого отправляемого apdu, причём расчёт криптограмм используемых в процессе, делегируется отдельным аппаратным модулям безопасности, так что никто, включая злоумышленника получившего контроль над клиентским оборудованием, или даже оборудованием оператора транспортной системы, или даже непосредственно самих турникетов не может получить доступа к ключам карты и несанкционированно записать туда что-то. Пока что с подобными картами существует проблема - несмотря на то что они уже очень много лет существуют на рынке, они мало распространены, хотя по себестоимости зачастую выходят даже дешевле карт тридцатилетней давности с нулевой защитой. Виной всему та же огромная "инертность" технологий в этой сфере, но их время обязательно придёт.
Также, поскольку я много работал с картами NXP mifare, могу сказать что проблема с crypto1 уже также давно решена. Этот алгоритм был своеобразной пробой пера среди массово используемых карт в плане аутентификации включающей в себя криптографию, выработки сессии и дальнейшее шифрование всех передаваемых данных. Да, реализован он был слабо, особенно в плане оборудования карты. Напомню, что внутри карты находится маленький компьютер размером с четверть рисового зёрнышка, и заставить его выполнять вычислительно "тяжёлые" криптографические операции - это далеко не то же самое что делать подобное на полноценном компьютере. Инженеры экономили ресурсы как могли и просчитались не столько на самой криптографии, сколько на невозможности организовать на подобных мощностях криптографически стойкий аппаратных ГПСЧ (это куда сложнее чем кажется на первый взгляд). Тем не менее, спустя некоторое время они выпустили новый тип карт, который после прошивки можно было перевести в режим работы, который полностью повторял интерфейс оригинальных mifare classic, но при этом уже имел стойкий ГПСЧ без вышеупомянутой уязвимости и дополнительные плюшки типа защиты от фаззинга команд и брутфорса ключа. Так что теперь даже эти карты возможно использовать относительно безопасно, хотя в современных реалиях они обладают уже пожалуй слишком короткой длинной ключа, и если вы прямо сейчас разрабатываете современную систему использующую карты, то лучше возьмите хотя бы mifare plus ev1 от тех же NXP, используйте их в максимально защищённом режиме и всё будет хорошо и правильно.
Ну а от гениев использующих открытый 7-байтный UID карты в качестве идентификатора любая безопасность бессильна, т.к. этот UID вообще-то нужен для чисто технических задач типа разрешения коллизии карт и т.д. и вообще может возвращаться случайный в некоторых случаях. Это НЕ прикладные данные и полагаться на них нельзя
Очень давно пользуюсь yt-dlp. Заготовил даже для себя разные шелл-алиасы чтобы быстро скачивать музыку или целые плейлисты с аудио и видео, которые, к сожалению, копирасты нередко с ютуба удаляют. Музыку вообще стараюсь всегда держать только у себя локально и никаких подписок, потому что с ними те же проблемы «недуступно у вас в регионе», «удалено по жалобе правообладателя» и т.д. В личном хранилище всё организовано так как мне нужно и по чьей-то прихоти удалено не будет.
К сожалению, тему с зарезанием скорости замечаю уже некоторое время, последнее время кажется она особенно активна. Пока что разработчики yt-dlp справляются. Низкий им поклон от меня
Интересуюсь тем, что происходит в Китае и довольно давно наблюдаю за тем как Китайские компании потихоньку захватили чуть ли не 90% мировой добычи редкоземельных металлов, которые в будущем, при сохранении текущих темпов роста производства сложных технологических товаров, могут стать дороже золота. Да и вообще Китай контролирует токую огромную долю критически важных мировых ресурсов в производстве, цепочках поставок, логистике, и не только. Всегда удивляло то, что люди по всему миру не бьют тревогу на этот счёт.
Телеметрия Майкрософта таки дошла до необходимости делать добровольно-принудительные полные бэкапы данных пользователей на анализ? Впрочем, учитывая то что они у себя на onedrive даже пытаются подбирать пароли к архивам и анализировать их содержимое - неудивительно
Спасибо огромное за статьи! Очень полезная и актуальная тема.
UPD: Кстати, было бы интересно если бы вы также смогли дать краткое описание и пример настройки функционала xray bridge для тех кому нужен функционал реверс прокси и прокидывания доступа из внешней сети к домашней
Автор молодец! Очень круто, что уже в таком возрасте есть чёткое понимание того к чему хочется стремиться и куда развиваться. Я бы очень хотел быть таким же в свои 16. Если программирование - ваше призвание, то продолжайте, не останавливайтесь, и ни в коем случае не сомневайтесь в своём выборе, кто бы что вам ни говорил. Вашему отцу - уважение, за то что развивает и поддерживает вас в ваших начинаниях.
Как-то мне довелось плотно пообщаться с талантливыми молодыми ребятами на летней стажировке в Яндексе. Я конечно был поражён их уровнем знаний. В свои 18, только закончив школу, многие из них, по уровню навыков и квалификации, были на голову выше некоторых разработчиков с многолетним опытом, которых мне доводилось знать. Их пример, как и ваш, очень заряжают и вдохновляют.
Спасибо за интересную статью. Тема крайне актуальная и важная для крупных проектов. Тоже пытался по разному подступиться к этой проблеме на рабочем проекте (550+ gradle модулей, 2М+ LOC), делал оптимизацию сборки, дружащие с местным DI стабы -impl модулей (разбиение на -api, -impl, -stub), но взрывного эффекта, это, конечно, всё равно не давало.
По моему опыту работы с Gradle, он очень плохо переносит большое количество модулей, каждый новый модуль добавляет существенный импакт на время сборки, даже если это просто -stub модуль с "пустыми" реализациями интерфейсов из -api, количество модулей, к сожалению не меняется, время конфигурации (существенное узкое место, особенно актуальное в "горячих" сборках) не уменьшается, configuration-cache не всегда адекватно работает из-за некоторых подключённых к сборке плагинов, а выигрыш на тасках сборки модуля есть, но не огромный.
Наиболее правильный подход - это конечно вот такие вот демо, к которым можно подключить только 1-2 разрабатываемых в настоящий момент модуля и не страдать с пересборкой всего проекта. Я, к сожалению, не осилил у себя декомпозировать сильно старые базовые модули, авторизацию и проход до главного экрана, которые в своё время были очень монолитными и завязанными друг на друга, а потом стало слишком больно и сложно их рефакторить.
Да, я пришёл примерно к такой же схеме. Верхнеуровнево - разные профили в firefox отправляют трафик в разные сетевые интерфейсы. Это позволяет добиться гарантированно точной выборочной маршрутизации, и по удобству меня вполне устраивает, но всё-таки немножко монструозное решение
Получается, вы заходите на нужный ресурс, тут же в админке видите весь список актуальных доменов ресурса, и потом вручную назначаете им всем правила что их нужно направлять в туннель?
По второму - я имел ввиду то, что у вас не возникает проблемы с "кэшем" dns? Т.е. когда адреса фактически сменились, но утилита занимающаяся маршрутизацией ещё отправляет в туннель старые адреса, в то время как фактически уже используются новые?
Добрый вечер. Интересный проект, спасибо за статью!
Подскажите пожалуйста, как именно происходит перенаправление выборочного трафика в туннель? Я очень хочу пользоваться чем-нибудь подобным, что решает задачу выборочного обхода блокировок, но это никогда не получается просто и удобно. Пытался запилить похожую систему себе самостоятельно, но именно в таком виде как у вас так и не смог достичь нужных результатов.
Я делал себе в своё время похожую систему основанную на policy based routing, настроил клиентское vpn-соединение, получил новый сетевой интерфейс в дополнение к основному, и теперь я вроде как могу управлять тем какой куда трафик отправлять с помощью ipset. Мне не нужны были обходы блокировок абсолютно всего что заблокировано, и всего списка antifilter, только некоторых сайтов. Основной загвоздкой было вот что - ipset управляет именно адресами, но не доменами и не сессиями в браузере, о браузерах, приложениях и других прикладных штуках он вообще ничего не знает. Постараюсь пояснить:
1) Допустим я открываю сайт, например условный инстаграм, вижу что он заблокирован. Я могу добавить домен инстаграма в список перенаправляемого в туннель, однако помимо основного домена там подгружается ещё целая куча всего, разные домены s3 хранилищ, какие-то укороченные домены, плюс всякие интеграции и т.д. Многие из них не входят в вайлдкард и не являются субдоменами основного домена. Поэтому приходится кропотливо забивать их руками, пока сайт не загрузится, после чего ещё забивать руками все вторичные домены, пока сайт не просто загрузится, но ещё и станет исправно работать. Некоторые ресурсы начинают сходить с ума когда часть контента загрузилась через WAN, а часть через TUN. Домены могут переименовываться, добавляться и удаляться. Постоянно обновлять этот список - кропотливая работа, которая со временем жутко надоедает. Я не знаю как можно удобно решить эту проблему. Вы с таким сталкивались? Как получилось решить эту проблему?
2) Далее, допустим я добавил правила для перенаправления всех доменов. Список для ipset и таблица маршрутизации составляется в момент запуска сервиса, для каждого из доменов резолвятся его IP адреса, после чего сервис запоминает их и начинает работать. Многие ресурсы крупных компаний хостятся через cloudflare (блок IPv4 адресов 104/8 и ещё несколько), там на ресурсах может часто происходить ротация IP адресов. Или другая ситуация round-robin отдал сначала один адрес, а через некоторое время другой. Получается что policy-based-routing запомнил определённые адреса, но спустя какое-то время запрос на тот же самый ресурс будет выполнен уже к фактически другому IP адресу, и не попадёт в туннель, а пойдёт в обычный WAN. Для того чтобы всё починить нужно вручную перезапустить сервис policy-based-routing, что, разумеется, неудобно и неприятно и опять требует отвлечения внимания от текущих задач. При этом наглухо зароутить в туннель весь блок 104/8 тоже нельзя, потому что на нём хостится очень много разных ресурсов, включая российские и они начнут сходить с ума и неадекватно работать, либо будет постоянно бросаться капча и т.д. В результате хотел выборочно обойти блокировки, а по итогу - только сам себе заблокировал доступ к целой горе незаблокированных ресурсов. У вас как-нибудь получилось решить такую проблему?
3) Допустим я хочу забить в ipset чисто IP адреса, без оглядки на домены. Т.е. получить все возможные адреса компании, строго забить их и забыть про все неудобства связанные с доменами. Тут опять облом, потому что получить полностью все адреса не всегда легко. Не везде эту информацию можно легко найти, не так просто их взять и собрать, плюс опять же проблема с блоками cloudflare - адреса могут постоянно плавать в них и ротироваться. Этот подход ещё менее надёжный чем с управлением доменами. Как всё-таки вы поступаете - работаете с доменами или с адресами?
В общем, я упёрся в то что именно при подобном подходе приходилось постоянно перезапускать сервис, постоянно обновлять руками списки доменов и адресов. Это было настолько неудобно, что пришлось перейти к совершено другой схеме, но я не теряю надежды что что-нибудь можно выжать и такого подхода как описан у вас, но вот обозначенные выше проблемы при его использовании пока что не смог решить. Буду признателен, если дадите пояснения на мои вопросы и дадите информации для размышления.
Мне однажды доводилось принимать участие в проведении бесплатного обучения по программированию. Компания, в которой я работал, проводила курсы по Java. Дело было в маленьком провинциальном городе, сама компания работала на московского заказчика. Количество разработчиков в городе, в те далёкие дохайповые времена, исчислялось, как мне кажется, несколькими десятками человек, очень были нужны новые люди. Компания объявила обучение, оно длилось несколько месяцев и было бесплатным, а основной целью для нас было - найти новых людей, которых можно взять в джуны. К нам поступило довольно много разных людей. Кто-то уже имел какой-то минимальный любительский опыт написания кода за плечами, кто-то был с местного градообразующего производственного предприятия и работал только поддерживая жуткий малопонятный софт написанный на делфи, кто-то вообще пришёл просто потому что бесплатно. Я в этом процессе выполнял роль "ментора" как бы это назвали на современных курсах - проверял домашние задания, помогал людям если у них были вопросы и т.д.
Так вот, по итогу обучения могу сказать следующее: из группы в несколько десятков человек большая часть в какой-то момент пропала, потому что у них были более важные дела. Какая-то часть не вывезла обучение, потому что по привычке пришла с майндсетом "я пришёл, учите меня" и проявляла ноль инициативы, им казалось что поскольку они отсидели занятия, этого достаточно чтобы их взяли на работу. Лично мне наиболее жалко было тех кто пришёл с градообразующего завода, они уже там много лет работали программистами и даже получали высокую по меркам города зарплату, но уровень их квалификации и деградация способности к обучению были таковы, что мне было сложно объяснить им самые основные концепции ООП - классы и т.д., и что писать весь код огромного проекта в одном файле - это не нормально. Взяли по итогу из всей группы одного талантливого парня самоучку, который имел хорошее техническое и аналитическое мышление, кое-что уже пробовал писать для себя сам ещё до поступления на обучение, был готов вкалывать и проявлял инициативу в обучении, самостоятельно изучал вещи, напрямую не затронутые в курсе.
После того случая, я некоторое время сидел и думал, как стоило правильно поступить? Довольно быстро я пришёл к очевидному выводу, что к люди не ценят бесплатные вещи. Однако что из этого следует дальше? Стоило ли сделать обучение платным, но за символическую цену? Это отсеет большинство "мимокрокодилов", однако не решает проблему с тем, что на обучение будут приходить люди, которые на самом деле не готовы проявлять какую-либо инициативу достаточную чтобы освоить достаточно большой объём знаний и навыков чтобы стать разработчиком. В обучение за "сотни тыщщ" я тоже не верю, всем известные продавцы курсов "войти-в-айти" занимаются отбиванием чудовищных размеров рекламных бюджетов, а людям они продают скорее идею изменить жизнь, чем обучение. Вся информация с подобных курсов легко ищется в интернете, а "структурирование информации", "подача", "менторство" и "помощь с трудоустройством" часто оказываются пустышкой или рекламной заманухой. Тоже так себе формат - безусловно он набивает кошельки владельцев этого бизнеса, но вот людям он несёт мало пользы, а если человеку нравится и хочется учить, передавать знания, да он ещё и готов это делать бесплатно, то разумеется он желает тратить время на тех, кому это по настоящему нужно и по настоящему принесёт пользу.
Ваш подход, кажется, очень неплох. Я даже не подумал о таком в своё время. Спасибо за статью!
Согласен на 100%, именно это же хотел написать. Если уж всё равно взяли решение в духе "погуглили, нашли за полчаса на 4pda", то взяли бы уж лучше и впилили opengapps-ы, всё равно же же нынешней России начихать на лицензионные соглашения. Были бы чистые и честные гугл сервисы, а так сейчас подставят под удар один из самых важных проектов для открытого андроида
Есть опенсорсный плагин для браузера, ссылку оставлять не буду, чтобы не потёрли сообщение, гуглится легко - habrosanitizer. Очень высоко рекомендую, без него хабр читать стало правда тяжело. Плагин позволяет точечно скрывать из ленты публикации отдельных авторов, отдельные корпоративные блоги и отдельные хабы Опубликован в сторах аддонов для браузеров chrome и firefox, исходники - на гитхабе. На гитхабе репо переведён в архив, но, при этом, плагин, пока ещё, к счастью, жив и работает.
Блокировка отдельных пользователей - это как раз ваш случай. Думаю что читатели Хабра сами примерно представляют "золотой список имён" который напрашивается на сокрытие из ленты.
Блокировка по конкретным корпоративным блогам - это то, ради чего этот плагин и задумывался. Показывать пальцем на конкретные компании было бы не вежливо, и я этого делать не буду, но вы и сами, без моей помощи, можете наткнуться на блоги компаний, в которых копирайтеры, пишут на хабр унылую, никому не интересную корпоративную джинсу, но ставят публикацию в популярные хабы и просят всех своих сотрудников проплюсовать статью и кинуть в закладки. Иногда это выглядит очень забавно: вышла статья, у неё почти моментально появляется 20 плюсов и 20 сохранений в закладки, читаешь - материал мягко говоря, не очень, смотришь автора - "блог компании Х", количество сотрудников - 20, при этом у компании довольно много публикаций и у всех ~20 плюсов ~20 сохранений в закладки. Как говорится, "Совпадение? Не думаю". Лично я чаще прибегаю к блокировке по конкретному имени, т.к. бывает что внутри корпоративного блога есть авторы, которые пишут интересно, но вот для таких клинических случаев можно скрыть и весь блог целиком.
Блокировка по хабам тоже очень важна, т.к. умная лента хабра настолько умна, что часто довольно настойчиво выкидывает в ленту статьи из хабов, на которые пользователь вообще не подписан, и никогда не был подписан. Мне таких образом, например, пришлось заблокировать хаб "управление продажами", статьи из которого каким-то образом постоянно оказывались в моей ленте, хотя я подобный материал вообще не читаю. Эта же фича позволяет исключить из ленты статьи, в которых авторы злоупотребляют указанием большего количества названий хабов, чем на самом деле предполагает тематика статьи.
Когда установите плагин, в настройках обязательно активируйте изначально выключенную функцию "show quick UI actions". После этого у вас при открытии хабра в ленте, в шапке статьи, рядом с именами авторов, копоративных блогов и хабов, появятся кнопки быстрой блокировки. Один клик - и хабр снова торт
Добрый вечер. Решил спустя несколько месяцев сделать небольшой апдейт по теме статьи. Возможно кому-то это окажется полезным.
В общем, я решил придать лоска, шарма и благородства данному велосипеду, и запилил плагин для андроид студии, который делает, по сути, всё то же самое что и скрипты приведённые в статье, только лучше - красиво и удобно, одной кнопкой через гуй и самое главное - единообразно на всех операционных системах, включая windows. Были также поправлены некоторые баги оригинального плагина сборки, например невозможность передать apk с сервера на локальный компьютер на версии AGP > 7.0.2, невозможность нормально передавать файлы на сервер с локального компьютера на винде и т.д.
Плагин уже готов и опубликован в маркетплейсе JetBrains. Можете установить его прямо из настроек андроид студии. Заходите в настройки, раздел Plugins, вбивайте в поиске название "SkyForge" и тыкайте "Установить".
На тулбаре запуска рядом с кнопками Run и Debug появляется три новых кнопки:
Открытие окна настроек удалённой сборки для IDE. По сути - конфиг для ssh + несколько дополнительных опциональных параметров
Подготовка зависимостей для сборки проекта на удалённом сервере. После того как настроен ssh доступ, ткните её один раз, она проверит наличие на машине нужных версий JDK, Android SDK, cmdline-tools, platform-tools, build-tools и т.д, установит их в систему если чего-то не хватает (пока поддерживается только Ubuntu 20+)
Тоггл-кнопка, переключатель, показывает какой режим сборки в данный момент активирован (сборка на локальной машине / сборка на сервере) и позволяет в один тык переключиться в другой режим
Теперь достаточно один раз в настройках прописать параметры подключения к серверу по ssh, и далее просто кнопочкой включать и выключать этот режим когда требуется. Нажали один раз - все команды gradle начинают выполняться на сервере вместо локальной машины, нажали второй раз - всё возвращается в исходный режим и все gradle команды выполняются локально (это может быть полезно в случае, например, потери связи с сервером, чтобы не блокировать себе работу).
Теперь нет необходимости никакие дополнительные файлы класть в корень проекта, добавлять какие-то плагины в проект и т.д. Не будет ни одной строчки в git diff. Не потребуется также не забывать "отключать" режим сборки на сервере чтобы gradle на локальном компьютере мог нормально работать с другими проектами (init-script сборки на удалённом сервере теперь не блокирует их работу). Также добавлены некоторые неудобства и исправлены некоторые ошибки по мелочи.
Всё остальное, как и в случае с решением на скриптах, остаётся как было - stdout процесса сборки исправно отображаются в студии, вся работа производится как и раньше через гуй, отладка на реальном устройстве - всё по старому.
Если вдруг вы воспользовались этим плагином, то я буду очень благодарен если в ответ на этот комментарий или в пм вы закинете обратную связь и/или какие-то идеи по фичам. У меня самого имеются кое-какие планы на улучшения, но хотелось бы понимать, что вообще ожидает пользователь.
Да, абсолютно любой. Т.е. если в системе несколько пользователей, например вы пользуетесь компьютером всей семьёй, пользователь условный X может читать личные файлы пользователя Y (но не может их изменять или удалять). Всегда раздражала эта особенность макоси.
Причём многие на эту проблему эплу неоднократно указывали, писали в техподдержку, но они всё время пишут отписки в духе "так надо и вообще всё будет хорошо". Может быть я что-то не понимаю во внутрянке макоси, но пока что я нигде не нашёл внятного ответа от эпла на вопрос зачем выставлены такие права доступа на директории которые являются приватными и предназначаются для одного конкретного пользователя.
Приходится делать руками chmod хоумдиректории своего системного пользователя и менять настройки на права которые ставятся на новые файлы по умолчанию.
Ничего себе! Вот это чтиво! Люблю подобные низкоуровневые штуки. В них - настоящая красота программирования. Автору - огромное уважение
Вероятно потому, что пока в Русторе не поддерживается разделение на сплиты. Приложения в Гугл Плей принимаются от разработчиков в формате app-bundle, а на устройство пользователя доставляются apk собранные конкретно под его устройство, т.е. имеющие ресурсы и код только под нужные архитектуру ЦПУ, плотность пикселей экрана, локализацию и т.д. Соответсвенно, без поддержки этих возможностей стор вынужден доставлять полный "толстый" апк, а те же нативные библиотеки под неиспользуемые архитектуры могут запросто весить несколько десятков мегабайт
Интереснейшая статья, настоящее техническое творчество. Спасибо!
Кстати, о проекте OpenIPC узнал не так давно и с огромным уважением отношусь к этой инициативе. Надеюсь однажды она разрастётся и станет чем-то вроде OpenWrt в мире WiFi-роутеров
Как человек участвовавший в проектировании и разработке карточных систем для общественного транспорта, я перевидал, перечитал документацию, прошивал и попробовал дюжину разных видов карт и никак не могу пройти мимо этой статьи.
Во-первых, как верно указали в комментариях, речь идёт об уязвимости почти 15-летней давности. Казалось бы, можно было сказать, что сейчас это уже никакого отношения к реальности не имеет, но нет. Подобные системы карт, так же как и карты в СКУДах, к сожалению, нередко завязываются на конкретное оборудование и экосистему, от которой потом крайне сложно отказаться и крайне болезненно уходить. Задачу свою она выполняет, а штучные "ломатели карт", как правило, не являются слишком большой проблемой, вот и тянутся эти проблемы из десятилетия в десятилетие, а во многих системах в ходу карты 15, 20, а то и 30 летней давности.
Корни этой проблемы тянутся из прошлого. К пониманию необходимости защиты карт, и отказа от использования принципа "security by obscurity" человечество пришло далеко не сразу, а карт и оборудования для них уже навыпускали. Компании спешили поскорее выкатить продукт на рынок, а не задумываться о том что в будущем у каждого студента будет в кармане проксмарк/флиппер/телефон с NFC который сможет взаимодействовать с их оборудованием, поэтому защиту в карты даже не закладывали.
Возьмите, например, те же СКУДы, где до сих пор массово используют emmarine карты, они вообще не предполагают никакой защиты и копируются в один тык на китайские болванки за пару десятков рублей. Плохо ли это с точки зрения безопасности? Однозначно! Такие системы используются в бизнес центрах, предприятиях, офисах компаний, и т.д. Но, как часто бывает, карта не является единственным фактором аутентификации, поэтому бизнес и государсто продолжают закрывать глаза на проблему и митигируют её сторонними способами. Например в московском транспорте отлично работает антифрод система, которая почти моментально заблокирует использование и оригинальной карты и дубликата. Ну а копировать карты с магнитной полосой - это вообще избиение младенцев. Разумеется данные на них никак не защищены.
Во-вторых, существуют современные карты, которые уже давно не болеют подобными детскими болезнями. Протокол общения с ними предполагает принудительную двухстороннюю аутентификацию, использование признаваемой надёжной во всём мире криптографии, шифрование и подпись каждого отправляемого apdu, причём расчёт криптограмм используемых в процессе, делегируется отдельным аппаратным модулям безопасности, так что никто, включая злоумышленника получившего контроль над клиентским оборудованием, или даже оборудованием оператора транспортной системы, или даже непосредственно самих турникетов не может получить доступа к ключам карты и несанкционированно записать туда что-то. Пока что с подобными картами существует проблема - несмотря на то что они уже очень много лет существуют на рынке, они мало распространены, хотя по себестоимости зачастую выходят даже дешевле карт тридцатилетней давности с нулевой защитой. Виной всему та же огромная "инертность" технологий в этой сфере, но их время обязательно придёт.
Также, поскольку я много работал с картами NXP mifare, могу сказать что проблема с crypto1 уже также давно решена. Этот алгоритм был своеобразной пробой пера среди массово используемых карт в плане аутентификации включающей в себя криптографию, выработки сессии и дальнейшее шифрование всех передаваемых данных. Да, реализован он был слабо, особенно в плане оборудования карты. Напомню, что внутри карты находится маленький компьютер размером с четверть рисового зёрнышка, и заставить его выполнять вычислительно "тяжёлые" криптографические операции - это далеко не то же самое что делать подобное на полноценном компьютере. Инженеры экономили ресурсы как могли и просчитались не столько на самой криптографии, сколько на невозможности организовать на подобных мощностях криптографически стойкий аппаратных ГПСЧ (это куда сложнее чем кажется на первый взгляд). Тем не менее, спустя некоторое время они выпустили новый тип карт, который после прошивки можно было перевести в режим работы, который полностью повторял интерфейс оригинальных mifare classic, но при этом уже имел стойкий ГПСЧ без вышеупомянутой уязвимости и дополнительные плюшки типа защиты от фаззинга команд и брутфорса ключа. Так что теперь даже эти карты возможно использовать относительно безопасно, хотя в современных реалиях они обладают уже пожалуй слишком короткой длинной ключа, и если вы прямо сейчас разрабатываете современную систему использующую карты, то лучше возьмите хотя бы mifare plus ev1 от тех же NXP, используйте их в максимально защищённом режиме и всё будет хорошо и правильно.
Ну а от гениев использующих открытый 7-байтный UID карты в качестве идентификатора любая безопасность бессильна, т.к. этот UID вообще-то нужен для чисто технических задач типа разрешения коллизии карт и т.д. и вообще может возвращаться случайный в некоторых случаях. Это НЕ прикладные данные и полагаться на них нельзя
Очень давно пользуюсь yt-dlp. Заготовил даже для себя разные шелл-алиасы чтобы быстро скачивать музыку или целые плейлисты с аудио и видео, которые, к сожалению, копирасты нередко с ютуба удаляют. Музыку вообще стараюсь всегда держать только у себя локально и никаких подписок, потому что с ними те же проблемы «недуступно у вас в регионе», «удалено по жалобе правообладателя» и т.д. В личном хранилище всё организовано так как мне нужно и по чьей-то прихоти удалено не будет.
К сожалению, тему с зарезанием скорости замечаю уже некоторое время, последнее время кажется она особенно активна. Пока что разработчики yt-dlp справляются. Низкий им поклон от меня
Интересуюсь тем, что происходит в Китае и довольно давно наблюдаю за тем как Китайские компании потихоньку захватили чуть ли не 90% мировой добычи редкоземельных металлов, которые в будущем, при сохранении текущих темпов роста производства сложных технологических товаров, могут стать дороже золота. Да и вообще Китай контролирует токую огромную долю критически важных мировых ресурсов в производстве, цепочках поставок, логистике, и не только. Всегда удивляло то, что люди по всему миру не бьют тревогу на этот счёт.
Кажется, скоро до широких масс начнёт доходить
Телеметрия Майкрософта таки дошла до необходимости делать добровольно-принудительные полные бэкапы данных пользователей на анализ? Впрочем, учитывая то что они у себя на onedrive даже пытаются подбирать пароли к архивам и анализировать их содержимое - неудивительно
Спасибо огромное за статьи! Очень полезная и актуальная тема.
UPD: Кстати, было бы интересно если бы вы также смогли дать краткое описание и пример настройки функционала xray bridge для тех кому нужен функционал реверс прокси и прокидывания доступа из внешней сети к домашней
Очень круто! Спасибо за статью
Автор молодец! Очень круто, что уже в таком возрасте есть чёткое понимание того к чему хочется стремиться и куда развиваться. Я бы очень хотел быть таким же в свои 16. Если программирование - ваше призвание, то продолжайте, не останавливайтесь, и ни в коем случае не сомневайтесь в своём выборе, кто бы что вам ни говорил. Вашему отцу - уважение, за то что развивает и поддерживает вас в ваших начинаниях.
Как-то мне довелось плотно пообщаться с талантливыми молодыми ребятами на летней стажировке в Яндексе. Я конечно был поражён их уровнем знаний. В свои 18, только закончив школу, многие из них, по уровню навыков и квалификации, были на голову выше некоторых разработчиков с многолетним опытом, которых мне доводилось знать. Их пример, как и ваш, очень заряжают и вдохновляют.
Успехов!
Спасибо за интересную статью. Тема крайне актуальная и важная для крупных проектов. Тоже пытался по разному подступиться к этой проблеме на рабочем проекте (550+ gradle модулей, 2М+ LOC), делал оптимизацию сборки, дружащие с местным DI стабы -impl модулей (разбиение на -api, -impl, -stub), но взрывного эффекта, это, конечно, всё равно не давало.
По моему опыту работы с Gradle, он очень плохо переносит большое количество модулей, каждый новый модуль добавляет существенный импакт на время сборки, даже если это просто -stub модуль с "пустыми" реализациями интерфейсов из -api, количество модулей, к сожалению не меняется, время конфигурации (существенное узкое место, особенно актуальное в "горячих" сборках) не уменьшается, configuration-cache не всегда адекватно работает из-за некоторых подключённых к сборке плагинов, а выигрыш на тасках сборки модуля есть, но не огромный.
Наиболее правильный подход - это конечно вот такие вот демо, к которым можно подключить только 1-2 разрабатываемых в настоящий момент модуля и не страдать с пересборкой всего проекта. Я, к сожалению, не осилил у себя декомпозировать сильно старые базовые модули, авторизацию и проход до главного экрана, которые в своё время были очень монолитными и завязанными друг на друга, а потом стало слишком больно и сложно их рефакторить.
Спасибо ещё раз!
Добрый день, спасибо за ответ.
Да, я пришёл примерно к такой же схеме. Верхнеуровнево - разные профили в firefox отправляют трафик в разные сетевые интерфейсы. Это позволяет добиться гарантированно точной выборочной маршрутизации, и по удобству меня вполне устраивает, но всё-таки немножко монструозное решение
Спасибо за ответ.
Получается, вы заходите на нужный ресурс, тут же в админке видите весь список актуальных доменов ресурса, и потом вручную назначаете им всем правила что их нужно направлять в туннель?
По второму - я имел ввиду то, что у вас не возникает проблемы с "кэшем" dns? Т.е. когда адреса фактически сменились, но утилита занимающаяся маршрутизацией ещё отправляет в туннель старые адреса, в то время как фактически уже используются новые?
Добрый вечер. Интересный проект, спасибо за статью!
Подскажите пожалуйста, как именно происходит перенаправление выборочного трафика в туннель? Я очень хочу пользоваться чем-нибудь подобным, что решает задачу выборочного обхода блокировок, но это никогда не получается просто и удобно. Пытался запилить похожую систему себе самостоятельно, но именно в таком виде как у вас так и не смог достичь нужных результатов.
Я делал себе в своё время похожую систему основанную на policy based routing, настроил клиентское vpn-соединение, получил новый сетевой интерфейс в дополнение к основному, и теперь я вроде как могу управлять тем какой куда трафик отправлять с помощью ipset. Мне не нужны были обходы блокировок абсолютно всего что заблокировано, и всего списка antifilter, только некоторых сайтов. Основной загвоздкой было вот что - ipset управляет именно адресами, но не доменами и не сессиями в браузере, о браузерах, приложениях и других прикладных штуках он вообще ничего не знает. Постараюсь пояснить:
1) Допустим я открываю сайт, например условный инстаграм, вижу что он заблокирован. Я могу добавить домен инстаграма в список перенаправляемого в туннель, однако помимо основного домена там подгружается ещё целая куча всего, разные домены s3 хранилищ, какие-то укороченные домены, плюс всякие интеграции и т.д. Многие из них не входят в вайлдкард и не являются субдоменами основного домена. Поэтому приходится кропотливо забивать их руками, пока сайт не загрузится, после чего ещё забивать руками все вторичные домены, пока сайт не просто загрузится, но ещё и станет исправно работать. Некоторые ресурсы начинают сходить с ума когда часть контента загрузилась через WAN, а часть через TUN. Домены могут переименовываться, добавляться и удаляться. Постоянно обновлять этот список - кропотливая работа, которая со временем жутко надоедает. Я не знаю как можно удобно решить эту проблему. Вы с таким сталкивались? Как получилось решить эту проблему?
2) Далее, допустим я добавил правила для перенаправления всех доменов. Список для ipset и таблица маршрутизации составляется в момент запуска сервиса, для каждого из доменов резолвятся его IP адреса, после чего сервис запоминает их и начинает работать. Многие ресурсы крупных компаний хостятся через cloudflare (блок IPv4 адресов 104/8 и ещё несколько), там на ресурсах может часто происходить ротация IP адресов. Или другая ситуация round-robin отдал сначала один адрес, а через некоторое время другой. Получается что policy-based-routing запомнил определённые адреса, но спустя какое-то время запрос на тот же самый ресурс будет выполнен уже к фактически другому IP адресу, и не попадёт в туннель, а пойдёт в обычный WAN. Для того чтобы всё починить нужно вручную перезапустить сервис policy-based-routing, что, разумеется, неудобно и неприятно и опять требует отвлечения внимания от текущих задач. При этом наглухо зароутить в туннель весь блок 104/8 тоже нельзя, потому что на нём хостится очень много разных ресурсов, включая российские и они начнут сходить с ума и неадекватно работать, либо будет постоянно бросаться капча и т.д. В результате хотел выборочно обойти блокировки, а по итогу - только сам себе заблокировал доступ к целой горе незаблокированных ресурсов. У вас как-нибудь получилось решить такую проблему?
3) Допустим я хочу забить в ipset чисто IP адреса, без оглядки на домены. Т.е. получить все возможные адреса компании, строго забить их и забыть про все неудобства связанные с доменами. Тут опять облом, потому что получить полностью все адреса не всегда легко. Не везде эту информацию можно легко найти, не так просто их взять и собрать, плюс опять же проблема с блоками cloudflare - адреса могут постоянно плавать в них и ротироваться. Этот подход ещё менее надёжный чем с управлением доменами. Как всё-таки вы поступаете - работаете с доменами или с адресами?
В общем, я упёрся в то что именно при подобном подходе приходилось постоянно перезапускать сервис, постоянно обновлять руками списки доменов и адресов. Это было настолько неудобно, что пришлось перейти к совершено другой схеме, но я не теряю надежды что что-нибудь можно выжать и такого подхода как описан у вас, но вот обозначенные выше проблемы при его использовании пока что не смог решить. Буду признателен, если дадите пояснения на мои вопросы и дадите информации для размышления.
Спасибо!
О, автору моё уважение! Очень интересный подход.
Мне однажды доводилось принимать участие в проведении бесплатного обучения по программированию. Компания, в которой я работал, проводила курсы по Java. Дело было в маленьком провинциальном городе, сама компания работала на московского заказчика. Количество разработчиков в городе, в те далёкие дохайповые времена, исчислялось, как мне кажется, несколькими десятками человек, очень были нужны новые люди. Компания объявила обучение, оно длилось несколько месяцев и было бесплатным, а основной целью для нас было - найти новых людей, которых можно взять в джуны. К нам поступило довольно много разных людей. Кто-то уже имел какой-то минимальный любительский опыт написания кода за плечами, кто-то был с местного градообразующего производственного предприятия и работал только поддерживая жуткий малопонятный софт написанный на делфи, кто-то вообще пришёл просто потому что бесплатно. Я в этом процессе выполнял роль "ментора" как бы это назвали на современных курсах - проверял домашние задания, помогал людям если у них были вопросы и т.д.
Так вот, по итогу обучения могу сказать следующее: из группы в несколько десятков человек большая часть в какой-то момент пропала, потому что у них были более важные дела. Какая-то часть не вывезла обучение, потому что по привычке пришла с майндсетом "я пришёл, учите меня" и проявляла ноль инициативы, им казалось что поскольку они отсидели занятия, этого достаточно чтобы их взяли на работу. Лично мне наиболее жалко было тех кто пришёл с градообразующего завода, они уже там много лет работали программистами и даже получали высокую по меркам города зарплату, но уровень их квалификации и деградация способности к обучению были таковы, что мне было сложно объяснить им самые основные концепции ООП - классы и т.д., и что писать весь код огромного проекта в одном файле - это не нормально. Взяли по итогу из всей группы одного талантливого парня самоучку, который имел хорошее техническое и аналитическое мышление, кое-что уже пробовал писать для себя сам ещё до поступления на обучение, был готов вкалывать и проявлял инициативу в обучении, самостоятельно изучал вещи, напрямую не затронутые в курсе.
После того случая, я некоторое время сидел и думал, как стоило правильно поступить? Довольно быстро я пришёл к очевидному выводу, что к люди не ценят бесплатные вещи. Однако что из этого следует дальше? Стоило ли сделать обучение платным, но за символическую цену? Это отсеет большинство "мимокрокодилов", однако не решает проблему с тем, что на обучение будут приходить люди, которые на самом деле не готовы проявлять какую-либо инициативу достаточную чтобы освоить достаточно большой объём знаний и навыков чтобы стать разработчиком. В обучение за "сотни тыщщ" я тоже не верю, всем известные продавцы курсов "войти-в-айти" занимаются отбиванием чудовищных размеров рекламных бюджетов, а людям они продают скорее идею изменить жизнь, чем обучение. Вся информация с подобных курсов легко ищется в интернете, а "структурирование информации", "подача", "менторство" и "помощь с трудоустройством" часто оказываются пустышкой или рекламной заманухой. Тоже так себе формат - безусловно он набивает кошельки владельцев этого бизнеса, но вот людям он несёт мало пользы, а если человеку нравится и хочется учить, передавать знания, да он ещё и готов это делать бесплатно, то разумеется он желает тратить время на тех, кому это по настоящему нужно и по настоящему принесёт пользу.
Ваш подход, кажется, очень неплох. Я даже не подумал о таком в своё время. Спасибо за статью!
Террористы с удовольствием используют одобренный товарищем майором ТамТам и не парятся
Согласен на 100%, именно это же хотел написать. Если уж всё равно взяли решение в духе "погуглили, нашли за полчаса на 4pda", то взяли бы уж лучше и впилили opengapps-ы, всё равно же же нынешней России начихать на лицензионные соглашения. Были бы чистые и честные гугл сервисы, а так сейчас подставят под удар один из самых важных проектов для открытого андроида
Есть опенсорсный плагин для браузера, ссылку оставлять не буду, чтобы не потёрли сообщение, гуглится легко - habrosanitizer. Очень высоко рекомендую, без него хабр читать стало правда тяжело. Плагин позволяет точечно скрывать из ленты публикации отдельных авторов, отдельные корпоративные блоги и отдельные хабы Опубликован в сторах аддонов для браузеров chrome и firefox, исходники - на гитхабе. На гитхабе репо переведён в архив, но, при этом, плагин, пока ещё, к счастью, жив и работает.
Блокировка отдельных пользователей - это как раз ваш случай. Думаю что читатели Хабра сами примерно представляют "золотой список имён" который напрашивается на сокрытие из ленты.
Блокировка по конкретным корпоративным блогам - это то, ради чего этот плагин и задумывался. Показывать пальцем на конкретные компании было бы не вежливо, и я этого делать не буду, но вы и сами, без моей помощи, можете наткнуться на блоги компаний, в которых копирайтеры, пишут на хабр унылую, никому не интересную корпоративную джинсу, но ставят публикацию в популярные хабы и просят всех своих сотрудников проплюсовать статью и кинуть в закладки. Иногда это выглядит очень забавно: вышла статья, у неё почти моментально появляется 20 плюсов и 20 сохранений в закладки, читаешь - материал мягко говоря, не очень, смотришь автора - "блог компании Х", количество сотрудников - 20, при этом у компании довольно много публикаций и у всех ~20 плюсов ~20 сохранений в закладки. Как говорится, "Совпадение? Не думаю". Лично я чаще прибегаю к блокировке по конкретному имени, т.к. бывает что внутри корпоративного блога есть авторы, которые пишут интересно, но вот для таких клинических случаев можно скрыть и весь блог целиком.
Блокировка по хабам тоже очень важна, т.к. умная лента хабра настолько умна, что часто довольно настойчиво выкидывает в ленту статьи из хабов, на которые пользователь вообще не подписан, и никогда не был подписан. Мне таких образом, например, пришлось заблокировать хаб "управление продажами", статьи из которого каким-то образом постоянно оказывались в моей ленте, хотя я подобный материал вообще не читаю. Эта же фича позволяет исключить из ленты статьи, в которых авторы злоупотребляют указанием большего количества названий хабов, чем на самом деле предполагает тематика статьи.
Когда установите плагин, в настройках обязательно активируйте изначально выключенную функцию "show quick UI actions". После этого у вас при открытии хабра в ленте, в шапке статьи, рядом с именами авторов, копоративных блогов и хабов, появятся кнопки быстрой блокировки. Один клик - и хабр снова торт
Добрый вечер. Решил спустя несколько месяцев сделать небольшой апдейт по теме статьи. Возможно кому-то это окажется полезным.
В общем, я решил придать лоска, шарма и благородства данному велосипеду, и запилил плагин для андроид студии, который делает, по сути, всё то же самое что и скрипты приведённые в статье, только лучше - красиво и удобно, одной кнопкой через гуй и самое главное - единообразно на всех операционных системах, включая windows. Были также поправлены некоторые баги оригинального плагина сборки, например невозможность передать apk с сервера на локальный компьютер на версии AGP > 7.0.2, невозможность нормально передавать файлы на сервер с локального компьютера на винде и т.д.
Плагин уже готов и опубликован в маркетплейсе JetBrains. Можете установить его прямо из настроек андроид студии. Заходите в настройки, раздел Plugins, вбивайте в поиске название "SkyForge" и тыкайте "Установить".
На тулбаре запуска рядом с кнопками Run и Debug появляется три новых кнопки:
Открытие окна настроек удалённой сборки для IDE. По сути - конфиг для ssh + несколько дополнительных опциональных параметров
Подготовка зависимостей для сборки проекта на удалённом сервере. После того как настроен ssh доступ, ткните её один раз, она проверит наличие на машине нужных версий JDK, Android SDK, cmdline-tools, platform-tools, build-tools и т.д, установит их в систему если чего-то не хватает (пока поддерживается только Ubuntu 20+)
Тоггл-кнопка, переключатель, показывает какой режим сборки в данный момент активирован (сборка на локальной машине / сборка на сервере) и позволяет в один тык переключиться в другой режим
Теперь достаточно один раз в настройках прописать параметры подключения к серверу по ssh, и далее просто кнопочкой включать и выключать этот режим когда требуется. Нажали один раз - все команды gradle начинают выполняться на сервере вместо локальной машины, нажали второй раз - всё возвращается в исходный режим и все gradle команды выполняются локально (это может быть полезно в случае, например, потери связи с сервером, чтобы не блокировать себе работу).
Теперь нет необходимости никакие дополнительные файлы класть в корень проекта, добавлять какие-то плагины в проект и т.д. Не будет ни одной строчки в git diff. Не потребуется также не забывать "отключать" режим сборки на сервере чтобы gradle на локальном компьютере мог нормально работать с другими проектами (init-script сборки на удалённом сервере теперь не блокирует их работу). Также добавлены некоторые неудобства и исправлены некоторые ошибки по мелочи.
Всё остальное, как и в случае с решением на скриптах, остаётся как было - stdout процесса сборки исправно отображаются в студии, вся работа производится как и раньше через гуй, отладка на реальном устройстве - всё по старому.
Если вдруг вы воспользовались этим плагином, то я буду очень благодарен если в ответ на этот комментарий или в пм вы закинете обратную связь и/или какие-то идеи по фичам. У меня самого имеются кое-какие планы на улучшения, но хотелось бы понимать, что вообще ожидает пользователь.
Спасибо!
Да, абсолютно любой. Т.е. если в системе несколько пользователей, например вы пользуетесь компьютером всей семьёй, пользователь условный X может читать личные файлы пользователя Y (но не может их изменять или удалять). Всегда раздражала эта особенность макоси.
Причём многие на эту проблему эплу неоднократно указывали, писали в техподдержку, но они всё время пишут отписки в духе "так надо и вообще всё будет хорошо". Может быть я что-то не понимаю во внутрянке макоси, но пока что я нигде не нашёл внятного ответа от эпла на вопрос зачем выставлены такие права доступа на директории которые являются приватными и предназначаются для одного конкретного пользователя.
Приходится делать руками chmod хоумдиректории своего системного пользователя и менять настройки на права которые ставятся на новые файлы по умолчанию.