Ну в таком случае способ борьбы тоже примерно понятен. Есть же Accessibility API у мобильных ОС, позволяющий и ввод с клавы эмулировать, и текст из элементов интерфейса считывать. Можно сделать надстройку на тот же макс, которая будет (относительно) прозрачно для юзера гонять PGP через стоковый клиент.
Если переписываться через вк или яндекс.мыло копипастой PGP-кода - что, огребёт вк и яндекс? А если через Silence (E2E на SMSках), тогда кто?
Так же и тут. Ну ок, допустим будет в свободном клиенте некий неудаляемый бэкдор (хотя я слабо представляю, как это возможно технически). Я форкаю клиент “Ласточки”, называю его “Ястреб”, и меняю условное send_message(text) на send_message(pgp_encrypt(text, pubkey)). Защиту от MITM при первичной сверке ключей сделать как у телеграма - хеш в смайлики и сверка голосовым звонком. И… что? Причем тут компания?
Ну, кому шутка, кому и не очень. Профессия у меня, конечно, более общая, но юзеры у меня несказанно довольны
сейчас с иишкиной помощью пишу примерно следующее (краткое содержание), описано процентов 40 системы
Архитектура системы FreeGW физически и логически разделена на два ключевых узла: Входной сервер (IGW), располагающийся в корпоративной ЛВС, и Выходной сервер (OGW), размещенный на зарубежном хостинге. Взаимодействие между ними и маршрутизация трафика обеспечиваются рядом специализированных подсистем.
Входной сервер (IGW)
Отвечает за сбор целевого корпоративного трафика и его защищенную передачу за пределы предприятия. Состоит из следующих задокументированных подсистем:
Подсистема сбора целевого трафика: Представляет собой автоматизированный конвейер скриптов, который собирает, фильтрует и математически оптимизирует списки IP-адресов и подсетей из различных открытых и локальных источников. С помощью BGP-сессии, организованной через демон BIRD2, эта подсистема анонсирует готовые маршруты главному маршрутизатору предприятия.
Подсистема проксирования (sing-box): Центральный узел маршрутизации на IGW. Направляет целевой трафик в виртуальный интерфейс и выполняет непрерывную балансировку (urltest) исходящего магистрального трафика для выбора оптимального канала связи из нескольких протоколов и IP-адресов.
Широкополосные магистральные каналы (haproxy): Механизм защиты от сигнатурного анализа и блокировок. Распределяет единый поток зашифрованного трафика по множеству псевдослучайных портов, создавая «широкополосный шум» и маскируя туннель.
Резервный магистральный канал через I2P (haproxy + i2pd): Канал «последнего эшелона». Использует оверлейную сеть I2P, мультиплексируя магистральный поток в большое количество независимых соединений, при этом haproxy осуществляет жесткую отбраковку нестабильных I2P-туннелей на основе периодического L7-пинга сквозь весь туннель.
Выходной сервер (OGW)
Отвечает за прием, расшифровку и выпуск магистрального трафика в глобальную сеть, а также за обслуживание удаленных сотрудников. Описаны следующие подсистемы:
Прием широкополосного магистрального трафика: Использование DNAT для агрегации входящего широкополосного трафика на единый локальный сокет демона sing-box для последующей терминации.
Прием магистрального I2P-мультиплекса: Зеркальная (относительно IGW) конфигурация массива скрытых сервисов в i2pd, собирающая трафик из оверлейной сети и направляющая его в локальный инбаунд.
Терминация и выпуск магистрального трафика: Обработка собранного sing-box трафика и его выпуск в Интернет со строгой фиксацией единого исходящего публичного IP-адреса, что обеспечивает непрерывность сессий для конечных пользователей при смене магистральных каналов балансировщиком IGW.
Персональное проксирование (Интерфейс для абонентов вне ЛВС объекта): Изолированная от магистрали подсистема на отдельном входном IP-адресе для подключения личных устройств сотрудников. Использует отдельный демон sing-box и веб-панель управления для автоматизированной выдачи конфигураций (Clash Subscription API). Выпуск персонального трафика также выполняется через единый выходной IP-адрес.
Стеганографическая защита абонентского входа. При попытке несанкционированного доступа или сканирования (Active Probing) абонентского входа веб-сервер отдает правдоподобную страницу легитимного веб-сервиса.
Подсистема скрытого управления: Обеспечивает защищенный доступ системного администратора из ЛВС предприятия (от IGW) к служебным интерфейсам OGW через сеть I2P. Использует криптографические механизмы анонимизации и шифрования лизсетов (LeaseSet blinding / Encryption) для защиты от обнаружения внутри сети I2P.
потому что начальник попросил подробно задокументировать этот сделанный за несколько месяцев монструозный комбайн.
Когда внутренняя документация будет готова - надеюсь, найду время превратить эту штуку еще и в публичный гитхаб, вычистив все боевые реквизиты из кода и доков, и оформлю статью на хабр. Если, конечно, к этому моменту интернет продолжит существовать в нынешнем понимании.
Можно всё так же обойтись двумя VPSками. Есть хостеры, у которых пул IP состоит из множества мелких диапазончиков, вероятно скупленных на вторичке, и при докупке адресов на VPSку выдаются адреса, не похожие даже в первом октете. В таком случае этот сервер спокойно имитирует оба - вход условно на 26.x.x.x, а выход на 175.x.x.x.
Второй вариант - I2P-рой между my и freedom2. Создается много-много инстансов клиента (my) и сервера (freedom2) с параметрами: quantity 16/16, length 0/1 (или 1/0 - равноценно, это как левостороннее или правостороннее движение). Оба i2pd включаются на флудфил, чтобы иметь хорошую репутацию и максимально полную netDb, крайне желательно также собрать их в семью. Все инстансы на клиенте агрегирует haproxy с постоянным тестированием и отбраковкой неудачных, на сервере - они просто все смотрят на один сокет. То есть, на место freedom1 встает распределенный рой запараллеленных пиров.
Хотите верьте, хотите нет, но на практике такая система с хорошим размером роя обеспечивает сотни Мбит/с с пингом 300-500 мс. Пруфов не будет (господин жандарм, подите прочь делать сами свою сыскную работу, с вас тошно-с), но проверить мои слова может каждый собственным экспериментом.
Конкретно у меня проблема проявилась при переводе сервера с иксрея (фронтенд 3X-UI) на сингбокс (S-UI).
Когда сервер - сингбокс, для протокола VLESS например ему критически важно чтобы в клиенте было в явном виде прописано: Flow - xtls-vision, Packet encoding - xudp. Когда сервер - иксрей, ему пофигу на отсутствие этих параметров на клиенте; а вот когда сингбокс - без них UDP не проксируется, и неважно тюн режим на клиенте или сокс.
Более того, если используется механизм подписок, то нужно забирать с сервера или JSON или Clash формат. Классический формат (который выглядит как длинный base64 текст) просто не имеет полей для этих параметров, поэтому UDP работать не будет, а если даже вписать руками - будет ломаться каждый раз когда обновляется подписка. Я даже копался в коде парсера подписок некобокса, где и убедился, что эти настройки даже не ищутся парсером в коде b64-подписки.
Из тех клиентов, что я знаю - клиенты от Мацури и их форки понимают формат Clash, а Hiddify - JSON.
Личный опыт: если речь об иксрее/сингбоксе - не при любых настройках туннеля будет работать проксирование UDP. У ватсапа звонки по TCP, у телеги по UDP. Также неправильную настройку UDP легко заметить по такому симптому, что не работает классический DNS, но работает DoH.
Извиняюсь за некропост. Получается, tun2socks + механизм шифрованных лизсетов == тот же самый OpenVPN с авторизацией по сертификатам, но чисто средствами I2P?
По принципу корабля Тесея переносить. Замена небольшого участка мозга на его электронный эквивалент, пробуждение, проверка что всё получилось (биологическая часть не демонстрирует симптомов наподобие инсульта, электронная отдает хорошую телеметрию), замена следующего участка...
Если каждый отдельно взятый блок недостаточен для запуска на нем полноценного сознания, то копирования случиться в принципе не может.
Вспомнилось при прочтении статьи. Как советские школьники мечтали пойти в космонавты, я в первой половине нулевых мечтал пойти в геймдев. А это были времена холиваров Doom 3 vs HL2. Помню как сказал однокласснику - "было бы по кайфу попасть к Габену, а вот к Кармаку что-то не тянет, почему - не знаю."
Кармак в какой-то момент просто отнёс свою вроде бы любимую кошку Митци в приют
Да понятное дело, что скам в первую очередь на пожилых и технически неподкованных рассчитан. Впрочем проблема это интернациональная. Нам звонят зеки из сбера, а американцам - индусы из майкрософта и амазона. На ютубе есть много видео, как их жестко пранкуют, в том числе ставят на вид за "scamming poor old ladies".
Даже если сотрудник СБ банка назовет мне номер паспорта, я все равно отвечу - "Вы ошиблись, это приёмная ФСИН по республике Мордовия". И перезвоню в банк сам.
Я делал радикальнее - убирал печатную антенну "змейку", припаивал RP-SMA гнездо и прикручивал антенну для роутера. Блютус акустика с такой антенной работает метров на 100 от телефона, лишь бы прямая видимость была.
Ну в таком случае способ борьбы тоже примерно понятен. Есть же Accessibility API у мобильных ОС, позволяющий и ввод с клавы эмулировать, и текст из элементов интерфейса считывать. Можно сделать надстройку на тот же макс, которая будет (относительно) прозрачно для юзера гонять PGP через стоковый клиент.
Если переписываться через вк или яндекс.мыло копипастой PGP-кода - что, огребёт вк и яндекс? А если через Silence (E2E на SMSках), тогда кто?
Так же и тут. Ну ок, допустим будет в свободном клиенте некий неудаляемый бэкдор (хотя я слабо представляю, как это возможно технически). Я форкаю клиент “Ласточки”, называю его “Ястреб”, и меняю условное send_message(text) на send_message(pgp_encrypt(text, pubkey)). Защиту от MITM при первичной сверке ключей сделать как у телеграма - хеш в смайлики и сверка голосовым звонком. И… что? Причем тут компания?
Ну, кому шутка, кому и не очень. Профессия у меня, конечно, более общая, но юзеры у меня несказанно довольны
сейчас с иишкиной помощью пишу примерно следующее (краткое содержание), описано процентов 40 системы
Архитектура системы FreeGW физически и логически разделена на два ключевых узла: Входной сервер (IGW), располагающийся в корпоративной ЛВС, и Выходной сервер (OGW), размещенный на зарубежном хостинге. Взаимодействие между ними и маршрутизация трафика обеспечиваются рядом специализированных подсистем.
Входной сервер (IGW)
Отвечает за сбор целевого корпоративного трафика и его защищенную передачу за пределы предприятия. Состоит из следующих задокументированных подсистем:
Подсистема сбора целевого трафика: Представляет собой автоматизированный конвейер скриптов, который собирает, фильтрует и математически оптимизирует списки IP-адресов и подсетей из различных открытых и локальных источников. С помощью BGP-сессии, организованной через демон BIRD2, эта подсистема анонсирует готовые маршруты главному маршрутизатору предприятия.
Подсистема проксирования (sing-box): Центральный узел маршрутизации на IGW. Направляет целевой трафик в виртуальный интерфейс и выполняет непрерывную балансировку (urltest) исходящего магистрального трафика для выбора оптимального канала связи из нескольких протоколов и IP-адресов.
Широкополосные магистральные каналы (haproxy): Механизм защиты от сигнатурного анализа и блокировок. Распределяет единый поток зашифрованного трафика по множеству псевдослучайных портов, создавая «широкополосный шум» и маскируя туннель.
Резервный магистральный канал через I2P (haproxy + i2pd): Канал «последнего эшелона». Использует оверлейную сеть I2P, мультиплексируя магистральный поток в большое количество независимых соединений, при этом haproxy осуществляет жесткую отбраковку нестабильных I2P-туннелей на основе периодического L7-пинга сквозь весь туннель.
Выходной сервер (OGW)
Отвечает за прием, расшифровку и выпуск магистрального трафика в глобальную сеть, а также за обслуживание удаленных сотрудников. Описаны следующие подсистемы:
Прием широкополосного магистрального трафика: Использование DNAT для агрегации входящего широкополосного трафика на единый локальный сокет демона sing-box для последующей терминации.
Прием магистрального I2P-мультиплекса: Зеркальная (относительно IGW) конфигурация массива скрытых сервисов в i2pd, собирающая трафик из оверлейной сети и направляющая его в локальный инбаунд.
Терминация и выпуск магистрального трафика: Обработка собранного sing-box трафика и его выпуск в Интернет со строгой фиксацией единого исходящего публичного IP-адреса, что обеспечивает непрерывность сессий для конечных пользователей при смене магистральных каналов балансировщиком IGW.
Персональное проксирование (Интерфейс для абонентов вне ЛВС объекта): Изолированная от магистрали подсистема на отдельном входном IP-адресе для подключения личных устройств сотрудников. Использует отдельный демон sing-box и веб-панель управления для автоматизированной выдачи конфигураций (Clash Subscription API). Выпуск персонального трафика также выполняется через единый выходной IP-адрес.
Стеганографическая защита абонентского входа. При попытке несанкционированного доступа или сканирования (Active Probing) абонентского входа веб-сервер отдает правдоподобную страницу легитимного веб-сервиса.
Подсистема скрытого управления: Обеспечивает защищенный доступ системного администратора из ЛВС предприятия (от IGW) к служебным интерфейсам OGW через сеть I2P. Использует криптографические механизмы анонимизации и шифрования лизсетов (LeaseSet blinding / Encryption) для защиты от обнаружения внутри сети I2P.
потому что начальник попросил подробно задокументировать этот сделанный за несколько месяцев монструозный комбайн.
Когда внутренняя документация будет готова - надеюсь, найду время превратить эту штуку еще и в публичный гитхаб, вычистив все боевые реквизиты из кода и доков, и оформлю статью на хабр. Если, конечно, к этому моменту интернет продолжит существовать в нынешнем понимании.
Можно всё так же обойтись двумя VPSками. Есть хостеры, у которых пул IP состоит из множества мелких диапазончиков, вероятно скупленных на вторичке, и при докупке адресов на VPSку выдаются адреса, не похожие даже в первом октете. В таком случае этот сервер спокойно имитирует оба - вход условно на 26.x.x.x, а выход на 175.x.x.x.
Второй вариант - I2P-рой между my и freedom2. Создается много-много инстансов клиента (my) и сервера (freedom2) с параметрами: quantity 16/16, length 0/1 (или 1/0 - равноценно, это как левостороннее или правостороннее движение). Оба i2pd включаются на флудфил, чтобы иметь хорошую репутацию и максимально полную netDb, крайне желательно также собрать их в семью. Все инстансы на клиенте агрегирует haproxy с постоянным тестированием и отбраковкой неудачных, на сервере - они просто все смотрят на один сокет. То есть, на место freedom1 встает распределенный рой запараллеленных пиров.
Хотите верьте, хотите нет, но на практике такая система с хорошим размером роя обеспечивает сотни Мбит/с с пингом 300-500 мс. Пруфов не будет (господин жандарм, подите прочь делать сами свою сыскную работу, с вас тошно-с), но проверить мои слова может каждый собственным экспериментом.
Конкретно у меня проблема проявилась при переводе сервера с иксрея (фронтенд 3X-UI) на сингбокс (S-UI).
Когда сервер - сингбокс, для протокола VLESS например ему критически важно чтобы в клиенте было в явном виде прописано: Flow - xtls-vision, Packet encoding - xudp. Когда сервер - иксрей, ему пофигу на отсутствие этих параметров на клиенте; а вот когда сингбокс - без них UDP не проксируется, и неважно тюн режим на клиенте или сокс.
Более того, если используется механизм подписок, то нужно забирать с сервера или JSON или Clash формат. Классический формат (который выглядит как длинный base64 текст) просто не имеет полей для этих параметров, поэтому UDP работать не будет, а если даже вписать руками - будет ломаться каждый раз когда обновляется подписка. Я даже копался в коде парсера подписок некобокса, где и убедился, что эти настройки даже не ищутся парсером в коде b64-подписки.
Из тех клиентов, что я знаю - клиенты от Мацури и их форки понимают формат Clash, а Hiddify - JSON.
Зачем? Без UDP интернет все равно неполноценный. Это скорее способ диагностики того, что сингбокс настроен криво и нужно поправить.
Личный опыт: если речь об иксрее/сингбоксе - не при любых настройках туннеля будет работать проксирование UDP. У ватсапа звонки по TCP, у телеги по UDP. Также неправильную настройку UDP легко заметить по такому симптому, что не работает классический DNS, но работает DoH.
Извиняюсь за некропост. Получается, tun2socks + механизм шифрованных лизсетов == тот же самый OpenVPN с авторизацией по сертификатам, но чисто средствами I2P?
Если рец не пку, то доктор Хьюлет Паккард ;)
В свое время хорошо помог для сборки сурвивалистской аптечки. Антибиотики, анальгетики...
Точно, забыл совсем. Предлагаю сделать перерыв в совете племени и сходить на мамонта, а то помрём ведь с голоду.
По принципу корабля Тесея переносить. Замена небольшого участка мозга на его электронный эквивалент, пробуждение, проверка что всё получилось (биологическая часть не демонстрирует симптомов наподобие инсульта, электронная отдает хорошую телеметрию), замена следующего участка...
Если каждый отдельно взятый блок недостаточен для запуска на нем полноценного сознания, то копирования случиться в принципе не может.
Вспомнилось при прочтении статьи. Как советские школьники мечтали пойти в космонавты, я в первой половине нулевых мечтал пойти в геймдев. А это были времена холиваров Doom 3 vs HL2. Помню как сказал однокласснику - "было бы по кайфу попасть к Габену, а вот к Кармаку что-то не тянет, почему - не знаю."
Теперь знаю.
Источник там нужен будет хитрый - умеющий считывать ток тяги и прибавлять его к току заряда.
2л/100 без розетки? Чисто на собственной генерации?
Да понятное дело, что скам в первую очередь на пожилых и технически неподкованных рассчитан. Впрочем проблема это интернациональная. Нам звонят зеки из сбера, а американцам - индусы из майкрософта и амазона. На ютубе есть много видео, как их жестко пранкуют, в том числе ставят на вид за "scamming poor old ladies".
Даже если сотрудник СБ банка назовет мне номер паспорта, я все равно отвечу - "Вы ошиблись, это приёмная ФСИН по республике Мордовия". И перезвоню в банк сам.
Указка это 2 класс - видимое излучение до 1 мВт. 5 мВт, да еще и ИК - это уже 3 класс.
Но и усилие для пропечатывания пикселя нужно куда меньшее, чем для пропечатывания буквы, а следовательно и размеры соленоида.
Бывают же еще линейные матричники, у которых "головка" - вся ширина листа. Там и скорость высокая, и нет бегающей туда-сюда массы.
Я делал радикальнее - убирал печатную антенну "змейку", припаивал RP-SMA гнездо и прикручивал антенну для роутера. Блютус акустика с такой антенной работает метров на 100 от телефона, лишь бы прямая видимость была.