Странно, что эта функция эксклюзивна для LE Audio (Broadcast Audio), т.к. классический Bluetooth тоже может вещать на множество устройств сразу, на сколько хватит пропускной способности шины Bluetooth-контроллера и качества радиотракта.
Понятно, что в LE Audio это эффективней, не нужно вещать на каждые наушники индивидуальный поток, но и мой Intel AX211 вполне позволяет подключать 4 пары и вещать на все (разную!) музыку одновременно.
SoC’и, как и в программировании, делаются модулями. Покупается (лицензируется) модуль контроллера памяти DDR от компаний вроде Synopsys, они поставляют все необходимое для его работы. Даже если они предоставляют исходные коды конкретно для тренинга, его публикация может быть запрещена лицензией.
Ну мой код не принимают, Greg KH мне просто не отвечает, вероятно из-за того, что я пишу с домена .ru. Знающие люди говорят, что ему юристы рекомендуют не отвечать в спорных моментах, потому что мейнтейнерам подсистем, куда я отправлял патчи, он тоже на их вопросы обо мне не отвечает.
Представьте, что автор мог бы запретить продажу бэушных книг.
Подавляющее большинство издательств спят и думают, как бы такое провернуть. Но законы не позволяют (увы!).
Или вообще запретить чтение своих давно купленых пользователями книг.
В этой статье не упоминаются различия в правах в западном мире и в Японии. У них основа права как в России (авторское право, а не copyright, не «право копирования»), но насколько я понял, без срока давности. Автор сохраняет права за собой даже в случае смерти бесконечно долго. В странах с копирайтом всё так или иначе перейдёт в общественное достояние, а в Японии оно рано или поздно наоборот навсегда исчезнет из легального поля.
sign-box позволяет заблокировать маршрутизацию от программ, которые применили SO_BINDTODEVICE на интерфейс прокси. Если программа исключена из использования прокси, она не сможет выполнить запрос через прокси, а сможет только через Wi-Fi/мобильную сеть. А если не исключена, то сможет и через прокси, и через Wi-Fi/мобильную сеть.
Определить само наличие прокси программа сможет в любом случае.
Ядро должно быть 5.7 и новее. Curl не выдаст ошибку, если SO_BINDTODEVICE не сработает, а попробует просто забиндить source ip сокета (и это успешно сработает, но не даст пакету смаршрутизироваться).
У вас, судя по гуглу, ядро 5.4, где такой ошибки ещё нет.
Запустите ваше ПО на денёк и посмотрите, есть ли трафик от UID = -1. Я предполагаю, что сам Android такие пакеты регулярно отправляет (будто бы system), и не знаю, сломается ли что-либо, если их блокировать.
И действительно похоже на баг, даже два (еще позволяет отправлять запросы в обход установленных VPN-приложением маршрутов). Я был уверен, что это by design, но нет — Network.bindSocket даёт отлуп, а SO_BINDTODEVICE обходит даже allowBypass и allowFamily.
@m0xf, @nidalee, поможете корректно описать проблему в Google? Я сделал PoC, обходящий несколькими методами несколько разных конфигураций.
Include/excluderoutes управляет маршрутами для главной таблицы маршрутизации. Если приложение забиндилось на интерфейс, оно их игнорирует (в обе стороны) — только что проверил на примере OpenVPN for Android, который настроил в режим «только локальная сеть» (маршрут только на диапазон выданного адреса). Curl’ом удалось достучаться до ifconfig.co через tun0.
Подумайте о другой стороне проблемы: многие программы, предназначенные для работы в локальной сети, отправляют ответы на запросы из локалки через направильный интерфейс (через VPN), потому что не биндятся на тот интерфейс, с которого получили запрос. Это типичный баг. Я даже просил разработчиков VPN-программ по умолчанию вводить подобные исключения хотя бы для broadcast-трафика (потому что он вообще в L3 VPN маршрутизироваться не должен, а L2 Android не поддерживает): https://github.com/schwabe/ics-openvpn/issues/1847
А Happ пользуются исключительно потому, что во всех этих прокси-протоколах нет понятия сессии, и заблокировать конфиги для конкретного устройства нельзя, пользователи могут делиться ими бесконечно.
В Happ сделали HWID, прямо как в старфорсе :D
На сервер отсылается HWID и сервер не выдаёт ключи больше, если хоть раз они скачивались с одного HWID. Экспортировать их тоже нельзя.
https://xcancel.com/ValdikSS/status/1214578907405570048
https://xcancel.com/ValdikSS/status/1843024846495834155
Странно, что эта функция эксклюзивна для LE Audio (Broadcast Audio), т.к. классический Bluetooth тоже может вещать на множество устройств сразу, на сколько хватит пропускной способности шины Bluetooth-контроллера и качества радиотракта.
Понятно, что в LE Audio это эффективней, не нужно вещать на каждые наушники индивидуальный поток, но и мой Intel AX211 вполне позволяет подключать 4 пары и вещать на все (разную!) музыку одновременно.
SoC’и, как и в программировании, делаются модулями. Покупается (лицензируется) модуль контроллера памяти DDR от компаний вроде Synopsys, они поставляют все необходимое для его работы. Даже если они предоставляют исходные коды конкретно для тренинга, его публикация может быть запрещена лицензией.
Ну мой код не принимают, Greg KH мне просто не отвечает, вероятно из-за того, что я пишу с домена .ru. Знающие люди говорят, что ему юристы рекомендуют не отвечать в спорных моментах, потому что мейнтейнерам подсистем, куда я отправлял патчи, он тоже на их вопросы обо мне не отвечает.
Подавляющее большинство издательств спят и думают, как бы такое провернуть. Но законы не позволяют (увы!).
В этой статье не упоминаются различия в правах в западном мире и в Японии.
У них основа права как в России (авторское право, а не copyright, не «право копирования»), но насколько я понял, без срока давности. Автор сохраняет права за собой даже в случае смерти бесконечно долго.
В странах с копирайтом всё так или иначе перейдёт в общественное достояние, а в Японии оно рано или поздно наоборот навсегда исчезнет из легального поля.
Чем это отличается от существующего запрета 2019 года? Он не действует? https://habr.com/ru/news/459720/
Или под то, что в этой новости, попадают также SDR и прочее оборудование, напрямую не нацеленное на работу со спутниками?
Его, вроде бы, и так не могли ввозить не-операторы указом ГРЧЦ от 30 ноября 2018.
sign-box позволяет заблокировать маршрутизацию от программ, которые применили SO_BINDTODEVICE на интерфейс прокси. Если программа исключена из использования прокси, она не сможет выполнить запрос через прокси, а сможет только через Wi-Fi/мобильную сеть. А если не исключена, то сможет и через прокси, и через Wi-Fi/мобильную сеть.
Определить само наличие прокси программа сможет в любом случае.
Ядро должно быть 5.7 и новее. Curl не выдаст ошибку, если SO_BINDTODEVICE не сработает, а попробует просто забиндить source ip сокета (и это успешно сработает, но не даст пакету смаршрутизироваться).
У вас, судя по гуглу, ядро 5.4, где такой ошибки ещё нет.
https://sing-box.sagernet.org/configuration/inbound/tun/#strict_route
Это блокируется selinux’ом для обычных программ на современных android. Через adb можно.
Запустите ваше ПО на денёк и посмотрите, есть ли трафик от UID = -1. Я предполагаю, что сам Android такие пакеты регулярно отправляет (будто бы system), и не знаю, сломается ли что-либо, если их блокировать.
P.S. в гугл репорт отправил.
Судя по репорту, раньше SO_BINDTODEVICE обходил даже системную опцию “Block connections without VPN”, и закрыли именно это.
У меня и так последний Graphene. Я только что поставил Pixel OS, чтобы перепроверить на стоке (тоже работает).
Я не могу вам отвечать в ЛС, у вас закрыто.
Hidden text
я сообщу через vulnerability program, не сообщайте гуглу публично, пожалуйста
И действительно похоже на баг, даже два (еще позволяет отправлять запросы в обход установленных VPN-приложением маршрутов). Я был уверен, что это by design, но нет — Network.bindSocket даёт отлуп, а SO_BINDTODEVICE обходит даже allowBypass и allowFamily.
@m0xf, @nidalee, поможете корректно описать проблему в Google? Я сделал PoC, обходящий несколькими методами несколько разных конфигураций.
Include/excluderoutes управляет маршрутами для главной таблицы маршрутизации. Если приложение забиндилось на интерфейс, оно их игнорирует (в обе стороны) — только что проверил на примере OpenVPN for Android, который настроил в режим «только локальная сеть» (маршрут только на диапазон выданного адреса). Curl’ом удалось достучаться до ifconfig.co через tun0.
Подумайте о другой стороне проблемы: многие программы, предназначенные для работы в локальной сети, отправляют ответы на запросы из локалки через направильный интерфейс (через VPN), потому что не биндятся на тот интерфейс, с которого получили запрос. Это типичный баг. Я даже просил разработчиков VPN-программ по умолчанию вводить подобные исключения хотя бы для broadcast-трафика (потому что он вообще в L3 VPN маршрутизироваться не должен, а L2 Android не поддерживает): https://github.com/schwabe/ics-openvpn/issues/1847
А Happ пользуются исключительно потому, что во всех этих прокси-протоколах нет понятия сессии, и заблокировать конфиги для конкретного устройства нельзя, пользователи могут делиться ими бесконечно.
В Happ сделали HWID, прямо как в старфорсе :D
На сервер отсылается HWID и сервер не выдаёт ключи больше, если хоть раз они скачивались с одного HWID. Экспортировать их тоже нельзя.
Пользователям он не нужен, он нужен сервисам.