Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Взломостойкость DRM-систем
Взломостойкость DRM-систем и её связь с бизнес-схемами распространения программного обеспечения.
В данной статье специалисты компании DST Global расскажут о том что почти каждый разработчик или издатель коммерческого программного обеспечения (ПО) хотя бы раз задумывался об использовании в своём продукте какой-нибудь DRM-системы. При этом окончательное решение о том, стоит ли использовать DRM, принималось, в том числе, на основе анализа таких свойств системы, как её взломостойкость и поддержка требуемой бизнес-схемы распространения ПО. Анализ показывает, что перечисленные свойства являются сильно связанными.
Задачи DRM-системы, используемой для распространения ПО
Прежде чем говорить о взломостойкости, рассмотрим бизнес-задачи DRM-системы, предназначенной для продажи автономно работающего ПО. Основные из этих задач перечислены в таблице 1. Приведённый список не является исчерпывающим, но другие задачи либо являются специфичными для конкретной системы (например, борьба с недобросовестностью партнёров по распространению ПО), либо неинтересны с точки зрения взломостойкости (например, сбор статистики по продажам), поэтому в таблицу не включены.
Таблица 1. Бизнес-задачи DRM-системы
| Задача | Угрозы, которым должна противостоять DRM-система при решении задачи | Примечание |
| Организация платежей | Кража платёжных данных | - |
| Защита от нелегального распространения | Устранение кода DRM-системы из приложения, эмуляция объекта привязки, генератор ключей | Под защитой от копирования здесь понимается обеспечение технической невозможности запуска приложения без приобретения лицензии |
| Ограничение времени использования приложения | Продление времени, сброс счётчика | Лицензия может ограничивать календарный период использования приложения, число запусков, суммарное время работы приложения. |
| Ограничение функционала приложения | Расширение функционала | - |
| Предоставление пользователю пробного периода использования приложения | Продление времени, сброс счётчика | Пробный период подразумевает возможность бесплатно использовать приложение в течение ограниченного времени. |
| Предоставление пользователю демонстрационного режима использования приложения | Расширение функционала | Демонстрационный режим характеризуется ограниченным функционалом при неограниченном времени использования. |
| Организация продаж дополнительного контента | Использование нелегально приобретённого контента | Пример решения этой задачи – продажа предметов виртуального мира в компьютерных играх. |
| Защита от анализа и модификации | Анализ и модификация кода DRM-системы с целью изменить логику её работы | Пример реализации описанной угрозы – преодоление защиты от копирования путём внесения таких изменений в код DRM-системы, которые отключали бы соответствующие проверки |
Техническое решение задач DRM-системы
Организация платежей
Сами действия по переводу денег в процессе покупки реализуется вне DRM-системы теми же методами, которые используются для обычной покупки через интернет. DRM-система, тем не менее, часто предоставляет возможности по интеграции с платёжными системами и отслеживания факта покупки. Поэтому при использовании DRM-системы необходимо убедиться, что интеграция произведена правильно и в её результате не образовалось «слабых мест».
Защита от нелегального распространения
Типовым подходом к решению задачи является внедрение в приложение некоторого кода DRM-системы, который бы обеспечивал неработоспособность приложения без наличия некоторого трудно копируемого внешнего по отношению к приложению объекта (объект привязки). Внедряемый код DRM-системы должен быть хорошо связан с приложением, чтобы его сложно было бы удалить или заблокировать.
Можно выделить следующие способы организации привязки:
- Привязка приложения к пассивному внешнему объекту, обладающему какими-либо уникальными параметрами. Самые распространённые пассивные объекты привязки – это компьютер конечного пользователя и компакт-диск, на котором поставляется приложения. Привязка осуществляется выдачей конечному пользователю активационного ключа, соответствующему уникальным параметрам объекта привязки.
- Привязка приложения к активному внешнему объекту, такому как электронный ключ или смарт-карта. Активный объект привязки содержит вычислительный блок, реализующий часть операций, необходимых для функционирования приложения.
- Привязка приложения к аккаунту конечного пользователя на удалённом сервере (привязка к серверу).
Более детальное описание наиболее типичных объектов привязки приведено в таблице 2.
Таблица 2. Типичные объекты привязки.
| Объект привязки | Описание | Уязвимости |
| Компьютер | Привязка производится к программно доступным идентификаторам и параметрам моделей элементов оборудования и ПО. Типичные примеры: модель процессора, объём памяти, MAC-адреса. | Возможность создания генератора ключа, если для его создания не используется криптография с открытым ключом. Несмотря на очевидность данной угрозы, многие производители систем DRM отказываются от применения криптографии с открытым ключом из-за большой длины ключа и упрощения атаки методом модификации кода DRM (типовые алгоритмы трудно защитить от анализа и модификации). |
| Возможность программной эмуляции большинства параметров оборудования. | ||
| Компакт-диск | Привязка производится к физической геометрии расположения секторов, к логической геометрии расположения секторов, наличию искусственно созданных нечитаемых областей. | Возможность создания генератора ключа, если не используется криптография с открытым ключом (аналогично ситуации с привязкой к оборудованию). |
| Возможность копирования диска путём повторения уникальных параметров. Особенно это относится к нечитаемым областям и логической геометрии расположения секторов. | ||
| Возможность создания эмулятора. Данная уязвимость является самой серьёзной для привязки данного типа на платформе PC. | ||
| USB-ключ | Отличительная особенность – сравнительно высокая цена одного ключа, не позволяющая использовать данное решение в дешёвом ПО. | Возможность создания эмулятора путём взлома и восстановления программы микроконтроллера, используемого в ключе. Также сюда относится возможность изменения данных о лицензии в памяти микроконтроллера.  |
| Возможность создания эмулятора путём анализа протокола обмена данными между защищённым приложением и ключом. Теоретически в ключе можно реализовать сколь угодно сложный код, что сделало бы данную уязвимость несущественной, однако на практике очень часто встречается плохая проработка данного вопроса (как разработчиками систем DRM, так и программистами, осуществляющими интеграцию системы DRM с приложением), что делает данную уязвимость наиболее важной. | ||
| Удалённый сервер | Аналогично активным объектам привязки, за исключением того, что в качестве объекта привязки выступает удалённый сервер. Отличительная особенность – необходимость подключения к интернету при каждом запуске или в течение всей работы защищённого приложения. | Возможность создания эмулятора путём анализа протокола (аналогично ситуации с активными объектами привязки). |
В целом следует отметить, что в настоящее время все перечисленные объекты привязки (с оговорками даже и компакт-диск) позволяют получить удовлетворительную взломостойкость, однако наиболее надёжными является всё же удалённый сервер.
Второй аспект защиты от нелегального распространения – создание трудноустранимой связи внедряемого кода DRM-системы с приложением – решается производителями DRM-систем по-разному. Здесь важно заметить следующее:
- Существуют способы решения этой задачи, обеспечивающие хорошую взломостойкость.
- Очень часто разработчики приложения не уделяют достаточного внимания соблюдению всех рекомендаций производителя DRM-системы по защите приложения, ограничиваясь автоматическими средствами встраивания DRM-системы в приложение, в результате задача устранения из приложения кода DRM для злоумышленника существенно упрощается.
Ограничение времени использования и пробный период
В случае использования привязки к серверу данная задача решается тривиально. Аналогично дело обстоит и с активными объектами привязки (тут, правда, появляется уязвимость, связанная с возможностью модификации лицензии в памяти объекта привязки и нарушения работы внутренних часов объекта привязки, однако и в этом случае достижение высокого уровня взломостойкости не является проблемой).
В случае же использования пассивного объекта привязки приходится использовать менее надёжные решения:
Таблица 3. Технические решения задач, связанных с ограничением времени работы приложения при использовании пассивных объектов привязки
| Задача | Решение | Уязвимости |
| Сохранение информации о начале пробного периода | Хранение скрытой информации на компьютере конечного пользователя (как правило, на жёстком диске). | Возможность обнаружения и удаления скрытой информации |
| Сохранение информации о потраченном количестве запусков и потраченном суммарном времени работы приложения | То же. | То же. |
| Определение текущего времени | Использование системных часов компьютера конечного пользователя | Перевод часов назад. Частично проблему перевода часов удаётся решить сохранением скрытой информации о времени последнего запуска, но эту информацию можно удалить. |
Использование удалённых серверов для сохранения информации об использовании лицензии или о текущем времени не используется, т.к. при этом исчезает главное преимущество пассивных объектов привязки перед привязкой к серверу: возможность работы без подключения к интернету.
Ограничение функционала и демонстрационный режим
Если функционал защищаемого приложения, который нужно предоставлять опционально (только в полной версии или за отдельную плату), обширен и хорошо локализован в виде отдельных функций, то теоретически его можно защитить столь же хорошо, как и основное приложение. Действительно, обширный и отделимый от приложения функционал можно рассматривать как отдельное независимое приложение. При этом задача ограничения функционала сводится просто к защите ещё одного приложения.
На практике же достижению хорошей взломостойкости могут препятствовать 2 причины:
- Недостаточная проработка вопросов взломостойкости при ограничении функционала авторами DRM-системы, которые рассматривают данную задачу как вспомогательную.
- Недостаточное обособление функционала разработчиками защищённого приложения.
Продажи дополнительного контента
Хотя задача ограничения использования контента внешне похожа на рассмотренную выше задачу ограничения функционала, качество решения этой задаче в плане взломостойкости обычно получается хуже. Действительно, решение об использовании того или иного файла данных обычно принимается в одной точке программы, тогда как в случае ограничения функционала проверку объекта привязки можно осуществить во многих точках. Это облегчает злоумышленнику взлом путём модификации кода DRM-системы.
Защита от анализа и модификации
Любой взлом DRM-системы предполагает осуществления злоумышленником анализа работы её программного кода. Модификация не является обязательным элементом взлома, так как иногда при анализе злоумышленнику удаётся найти уязвимость системы, с помощью которой механизмы защиты могут быть преодолены без модификации. Характерный пример взлома такого рода – создание генератора ключей.
Решение задач защиты от анализа и модификации обычно является основным ноу-хау DRM-систем, хотя до сих пор не существует идеальных решений: со временем для всех методов защиты появляются средства преодоления. Тем не менее, своевременное обновление решений может обеспечить системам DRM хороший уровень взломостойкости.
Основными подходами к защите от анализа являются:
- Обфускация – преобразования алгоритмов, делающие их непонятными (переименование функций, введение в код избыточных программных конструкций, введение в код ложных связей и т.п.).
- Использование системно-специфических средств противодействия анализу, таких как защита от отладчиков.
Защита от модификации обычно подразумевает вычисление контрольных сумм (в широком смысле) участков кода и проверку их неизменности.
Заключение
Взломостойкость любой системы DRM не является фиксированным параметром, а зависит от многих факторов. Вот наиболее типичные причины ухудшения взломостойкости:
- Несоблюдение рекомендаций производителя DRM-системы по достижению высокого уровня взломостойкости, в том числе по интеграции защищённого приложения с активным объектом привязки или с удалённым сервером.
- Использование пробного периода в случае использования DRM-систем с привязкой к оборудованию или компакт-диску.
- Использование демонстрационного режима при недостаточном программном обособлении платного функционала.
Для того чтобы защита была надежной и совместимой необходимо начать задумываться о ее установке заранее, 2-3 месяца до релиза программы. Производители DRM систем накопили значительный опыт, поэтому хорошим советом для правообладателей, желающих надежно защитить свою интеллектуальную собственность, станет совет всегда консультироваться с производителем и не пренебрегать его указаниями.
Если ПО устроено так, что часть его функционала выполняется на удалённых серверах, задача по защите от копирования обычно не возникают, но вместо них появляются другие специфические задачи, такие как, защита от нарушения игрового баланса в многопользовательских играх с помощью программ-читеров. Рассмотрение DRM-систем для данного типа ПО выходит за рамки данной статьи.
Взломостойкость DRM-систем
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все ваши вопросы.
Комментарии
Вам может быть интересно
Управление цифровыми правами (DRM) – это технология шифрования, обеспечивающая соблюдение прав создателя. Наиболее известные примеры ограничивают создание копий цифровых файлов, однако существуют и др...
Система управления цифровыми правами (Digital Rights Management System) – это си...
Практическое руководство по реализации эффективног...
Ознакомьтесь с руководством от специалистов компан...
Поскольку организации все чаще полагаются на Ku...
Что такое и зачем нужно облако ФЗ-152. Специалисты...
Шифрование хранящихся данных имеет жизненно важное...
Узнайте от специалистов компании DST Global, как о...
Простая утечка данных, как правило, происходит при...
Повысьте уровень DevSecOps с помощью платформ ASOC...
В этой статье специалистами компании DST Global по...
Новые комментарии
Инвитро выражает искреннюю благодарность компании DST Global за разработку нашег...
Инвитро выражает искреннюю благодарность компании DST Global за разработку нашег...
Инвитро выражает искреннюю благодарность компании DST Global за разработку нашег...
Чтобы избежать плачевной ситуации онлайн-кинотеатры защищают контент всеми силами, используя DRM и водяные знаки по указке правообладателей.
У DRM три основные функции:
— шифрование,
— расшифровка контента и
— управление ключами этого шифрования.
Итак, когда видео приходит в браузер пользователя, оно упаковано с помощью DRM. Без ключа для расшифровки невозможно начать просмотр.
Например, в приложениях Netflix'а есть функция, которая позволяет сохранить сериал или фильм и посмотреть позже. Но, даже если эти файлы достать из кэша приложения, не получится их посмотреть в стороннем плеере.
Только те, у кого есть подписка, получают ключ шифрования. Отдельно от контента. Это главный принцип «управления лицензией» DRM.
Поддержка DRM браузерами
— Подписчики могут смотреть сколько угодно, когда угодно, где угодно — на любом устройстве с интернетом
— Netflix
«Нетфликс на любом экране» — главная идея сервиса, и разработчики сделали возможным просмотр на огромном количестве устройств без ущерба для компании. Но среди всех платформ для просмотра браузер самый важный.
Но с ним не все так просто. Поэтому разработали кучу технологий для просмотра DRM-защищенного контента в браузерах. Давайте пробежимся по истории и заглянем в будущее сервисов видео-стриминга, DRM и веб-стандартов.
В прошлом — проприетарные DRM, требующие установки плагинов
С запуска онлайн-сервиса Нетфликса в 2000-х и в течение всего десятилетия большинство контентных сервисов использовали для защиты проприетарные DRM.
Их тогда было большое количество: Microsoft PlayReady, Google Widevine Classic, Adobe Access, Intertrust Marlin и INKA Entworks Netsync. Это разнообразие и стало большой проблемой, проблемой плагинов.
ActiveX-плагины знакомы многим — их использовали в те времена многие компании для защиты любого контента в вебе. Эти традиционные проприетарные DRM принуждали пользователей устанавливать отдельные плагины в их браузеры, такие как Flash, чтобы видео и аудио оставалось в безопасности, но проигрывалось в браузере.
Во всяком случае, из-за проблем безопасности и прожорливости этих решений браузеры просто отказались от их поддержки.
Сейчас — Мульти-DRM без плагинов
Итак, для решения проблем с плагинами в HTML5 создали несколько стандартов.
Например, стандарт расширений для зашифрованного контента (Encrypted Media Extension — EME) предоставляет API для веб-приложений, которое позволяет им взаимодействовать с DRM.
А с помощью стандарта EME и расширений источника медиа (Media Source Extension — MSE) браузеры обзавелись поддержкой проигрывания защищенного контента, что называется, из коробки.
К слову, почему Мульти-DRM? Все-таки разные браузеры все равно поддерживают разные DRM, а не одно общее решение. Поэтому все DRM объединяют одним словосочетанием.
Например, умирающий Internet Explorer и Edge поддерживали только PlayReady — DRM своих создателей Microsoft.
Точно также, Google Chrome поддерживает только модульную Google Widevine, а Эппловский Safari — только FairPlay. Но Firefox использует Google Widevine, также как и Хром.
Следовательно, чтобы предоставлять сервис пользователям с разными браузерами и ОС, нужно интегрировать сразу три DRM.
А ещё разные DRM используют разные технологии потоковой передачи данных: PlayReady и Widevine используют MPEG-DASH, тогда как FairPlay DRM — HLS (HTTP Live Streaming).
Естественно Мульти-DRM используют не только в браузерах, но и на смартфонах или смарт-тв.
Мульти-DRM работают на большинстве устройств современных юзеров. Но если надо поддерживать и старые устройства, на которых нет поддержки Мульти-DRM, придется использовать устаревшие форматы, как и делает Нетфликс.
Цель CMAF — это поддержка сразу всех браузеров и платформ используя одну технологию, формат и не требующую перекодирования. Но это требует обновления каждой спецификации, каждой DRM.
Большинство проблем уже разрешили Microsoft, Apple, Google и другие сочувствующие компании, объединившись.
Однако, из-за обилия разных девайсов у юзеров (например, старых андроид-смартфонов), которые всё еще не могут в CMAF нужно еще подождать, пока эту технологию станут использовать сервисы видеостриминга (OTT-services).
Помимо унификации форматов DRM, главное преимущество CMAF — супер-низкая задержка с помощью технологии Chunked Transfer Encoding (фрагментированная передача зашифрованного контента).
Низкая задержка — это очень важный фактор для стриминга видео в реальном времени. Таких как футбольные матчи, например. Недавно технология низкой задержки CMAF стала обсуждаемой темой у разработчиков из индустрии.
Больше прочитать про унификацию DRM можно в отдельной статье.
Мульти-DRM — удобно, но сложно
Мульти-DRM сразу поддерживает все платформы, где можно что-либо смотреть и не требует установки — она намного более удобна для конечных юзеров технология, чем старые DRM.
Однако провайдерам контента, которые используют DRM трудно интегрировать разные DRM и форматы потоковой передачи.
Для легкого внедрения Multi-DRM рекомендую использовать комплексные решения, которые объединяют в себе сразу несколько технологий защиты контента и предоставляют единый API с готовыми интеграции с энкодерами и видеоплеерами.
А что делает Кинопоиск?
Я написал в поддержку Кинопоиска HD и узнал, что они используют Google Widevine. Это мне написали в поддержке, но, думаю, для Apple-юзеров FairPlay тоже есть.
Часть II, про криминалистику и невидимые водяные знаки
В первой части мы узнали про Мульти-DRM, которые используют сервисы видеостриминга, такие Netflix, для защиты контента от пиратов.
Так как DRM-защищенный контент распространяется зашифрованным — любой, у кого нет лицензии DRM (права на проигрывание) не может просмотреть видео. Это уже какая-то защита.
Но её не достаточно.
Так, приложение человека с купленной подпиской должно преобразовать защифрованный контент в проигрываемый, обычный. И во время проигрывания уже расшифрованного видео есть некоторые очевидные и не очень технические ограничения, которые делают возможным утечку.
Следовательно, добавлять водяные знаки нужно, чтобы понять, у кого всё-таки получилось слить видео на торренты и предотвратить дальнейшее распространение…
Что такое эти невидимые водяные знаки?
— В оригинале — Forensic Watermarking — криминалистические водяные знаки. Но я перевёл по смыслу.
Это такие же водяные знаки, как на фотостоках, только более продвинутые.
В то время как обычные цифровые водяные знаки предназначены для подтверждения авторских прав с помощью встраивания информации о владельце прямо в контент, невидимые водяные знаки содержат в себе информацию о самих потребителях контента для отслеживания утечек.
Когда правообладатель или стриминговый сервис находит незаконно распространенный контент, он найдет водяной знак и определит по нему, кто слил контент. А потом отключит подписку юзера и передаст дело в руки правоохранительных органов.
Зачем нужны невидимые водяные знаки?
У вас могут оставаться вопросы по поводу реальной необходимости невидимых водяных знаков. На самом деле, даже когда контент защищен DRM, трудно полностью предотвратить утечку.
Да, содержимое передается клиенту по защищенному каналу, в зашифрованном виде. Клиентскому приложению в любом случае придется расшифровать контент для проигрывания.
На этой расшифрованной стадии контент всё-таки можно защитить, применив DRM аппаратного уровня (Hardware-level DRM), доверенное окружение воспроизведения (Trusted Execution Environment — TEE) и высоко-пропускную защиту цифрового контента (High-bandwidth Digital Content Protection — HDCP).
Но все равно, эти технологии уязвимы.
Пираты используют внешние камеры
Традиционный способ слива кино — CamRip или же экранки.
По простому, когда смартфон или отдельную камеру просто записывают экран, поставив перед ним на штатив.
— Аналогово-цифровое преобразование (Analog-to-Digital — A2D) aka один из видов пиратства, от которого защищают водяные знаки
Благодаря новым компактным камерам с высоким разрешением теперь можно записывать видео с тем же качеством, что и оригинал — в 4k. Уже не только 720p!
Вообще, для стриминговых сервисов экранки — намного бо́льшая проблема, чем для кинотеатров, где можно просто запретить записывать видео и звук. К слову, в кинотеатрах есть, в добавок к видеонаблюдению, определяющее блики камеры оборудование. И водяные знаки у каждого кинотеатра тоже свои.
Пираты записывают с помощью программ
Итак, возможность проигрывания DRM-защищенного контента в браузерах — одна из главных для подписчиков и, следовательно, самих стриминговых сервисов.
Однако, поскольку некоторые браузеры используют программное DRM, можно легко сохранить видео DRM в виде обычного видео формата MOV или MP4 с помощью простых программ для записи экрана.
Но в случае PlayReady DRM в браузерах IE11 (Win 8.1) и Edge (Win 10) невозможно сделать скриншот или записать экран из-за запрета на это со стороны операционки. В Mac OS FairPlay Streaming DRM тоже не дает записать экран в Safari.
А вот Chrome и Firefox, несмотря на поддержку программной WIdevine DRM не защищают контент от записи экрана…
Требование Голливуда
В 2007 году самые крупные студии Голливуда, включая Disney, Sony, Warner Bros., Universal и Paramount создали некоммерческую организацию, которую назвали Motion Picture Laboratories (MovieLabs), чтобы изучать технологии распространения и защиты от пиратства фильмов.
Чтобы предотвратить нарушение авторских прав, спецификации MovieLabs требуют применения DRM на уровне железа и невидимых водяных знаков для особо-ценного контента. Например, фильмов в 4k UHD.
Азы невидимых водяных знаков
Два главных условия для успешного применения таких водяных знаков — это, собственно, невидимость и стойкость.
— Невидимость. Различие между изначальным изображением и защищенным водяным знаком не должно быть видно.
— Стойкость. Водяной знак должен пережить атаки (перекодирование, обрезание, фильтрацию) и быть после распознаваемым.
Обычные видимые водяные знаки, очевидно, не подходят для этих целей. Голливуду же не нужно ухудшение картинки.
Чтобы обеспечить невидимость, водяные знаки вставляют так, что разница не заметна, создавая небольшой шум.
Следующее требование — уникальность водяных знаков, чтобы знать, кто пират. Для этого технология на основе сеанса кодирует информацию о пользователе водяными знаками и вставляет в контент.
Технологии, вставляющие водяные знаки на основе сессий можно поделить на серверные и клиентские.
— Клиентский вотермаркинг: водяные знаки вставляют приложения на устройстве пользователя. Для этого требуется минимум изменений на сервере, но есть недостаток в том, что для каждой платформы нужно программировать эту функциональность. Да и не особо надежно это.
— Серверный вотермаркинг: бэкенд видеосервиса вставляет водяные знаки. Преимущество здесь в том, что видеоплеер на клиенте никак не нужно программировать.
Где обитают невидимые водяные знаки
Невидимый вотермаркинг используется на различных стадиях показа фильмов, сериалов и тому подобного контента. А проще говоря, почти всегда.
— На предпоказе: когда некоторым заинтересованным лицам дают посмотреть раньше всех. Иногда билеты на такие показы разыгрывают. Утечка будет очень не кстати в этом случае, поэтому превентивно вставляют защиту.
— В кинотеатре: как я заметил в кинотеатрах тоже не зевают. В фильм вставляют и время сеанса и информацию про сам кинотеатр.
— На стриминговом сервисе: тут водяные знаки с зашитыми данными о потребителе вставляют «в режиме реального времени», прямо в премиум-контент.
Мульти-DRM и криминалистический вотермаркинг
Резюмирую. В то время, как DRM — технология для предотвращения халявного доступа к просмотру, вотермаркинг служит для отслеживания сливов уже заплатившими пользователями.
DRM и вотермаркинг дополняют друг друга и их нужно принимать вместе. Что и делают большинство онлайн-кинотеатров.
Как Okko ловит пиратов
В подкасте Запуск Завтра, выпуск про то, как устроены онлайн-кинотеатры, там гости рассказали, как в Окко используют водяные знаки для отлова пиратов. Довольно простое объяснение (около 29 минуты), как именно кодируется информация «водяными знаками»:
— Нужно некоторые зоны экрана, условно, квадратики пикселей сделать чуть менее интенсивными. Глаз это не увидит, но алгоритм, который будет анализировать видео, на 10 минутах заметит, что вот эти пиксели чуть-менее яркие, чем соседние.
Слева — нетронутая Лена из плейбоя, справа — защищенная водяными знаками
Замечательный пример выше демонстрирует, что защищенное изображение должно быть совсем неотличимо от оригинала.
Слишком сильная устойчивость к атакам сделает невидимые водяные знаки видимыми. Применение максимальной защиты и при этом соответствующей требованиям — главная задача баланса в деле с невидимыми водяными знаками.
2. Находим разницу в стриме
3. Уравниваем
4. ??????????????????????????
5. PROFIT!
А может так уже и делают…
Ещё вариантом атаки может быть как раз комбинация двух источников + наложение случайного полнокадрового шума тоже как невидимого вотермарка + дополнительная обработка с комбинированием двух кадров одного с размытием другого с шарпом — конечно это может чуть ухудшить качество картинки — зато вполне себе затрёт любой невидимый вотермарк. В общем вотермарки не так уж хорошо защищают — технология старая и профессионалы давно уже научились её обходить. Но вот дилетантов-пиратов вотермарки должны хорошо сдерживать
С одного сервиса качаешь с 4 учётных записей, разными устройствами с разных IP, в разное время. В видео оставляешь только те участки, где есть совпадения на 2-3 копиях. Там, где различается, можно смешать все 4 и добавить шум поверх + выровнять по яркости\насыщенности с рядом находящимися участками.
Либо, как тут, уже писали, с одного источника можно снять несколько изображнений в разное время, с разных IP и эккаунтов, и с чистым кешем — водяные знаки идентификации пользователя будут разные — можно сравнивать — 3-х таких источников будет вполне достаточно для надёжного тройного сравнения. Но не годится для уникального источника, который доступе пирату в одной копии (например слив с уникального показа в кинотеаторе) — тогда способом выше пытаемся исказить вотермарк без его поиска
Правообладатель будет знать на какие пиксели глядеть.