• Как это работает?
• Установка соединения
• Обмен данными (BlazorPack)
• Получаем HTML
• Формат DOM
• Таблица строк
• Процесс восстановления HTML

Одним вечером у меня появилась необходимость написать парсер HTML одного сайта, но при просмотре содержимого страницы вместо нужных мне данных я увидел данный комментарий:

Я подумал: "Ага, значит данные подгружаются динамически, следовательно должен быть запрос на сервер", однако открыв DevTools я увидел WebSocket, который судя по всему получал HTML от сервера

Как это работает?

Делать полный разбор протокола я не буду, поэтому кратко пройдёмся по основным этапам:

Установка соединения

После того как браузер загрузил страницу происходит POST запрос на /_blazor/negotiate, который возвращает:

• список поддерживаемых транспортных протоколов (WebSockets, Server-Sent Events, Long Polling);
• ID соединения (connectionId);
• Токен доступа (connectionToken).

Браузер перебирает список протоколов, и пытается установить соединение.
Если первый вариант не удался, то пробуется следующий и так далее.

Обмен данными (BlazorPack)

В качестве протокола обмена сообщениями между сервером и браузером используется протокол SignalR, который в свою очередь использует MessagePack (бинарный формат сериализации)

Также поверх этого используется ещё 1 слой - Binary Message Format (BMF).
К данным добавляются префикс длины, что позволяет передать несколько сообщений за один раз.

Получается такая "матрёшка" из кодировок:

BMF -> SignalR -> MessagePack

Каждый слой решает свою задачу:

• MessagePack - компактное представление данных;
• SignalR - вызов методов и маршрутизация сообщений (Ядро BlazorPack);
• Binary Message Format (BMF) - framing сообщений (Передача нескольких сообщений за раз)

Получаем HTML

Данный этап можно назвать самым сложным, так как Blazor не отдаёт HTML в "голом" виде , вместо этого он отдаёт представление DOM в бинарном пакете (RenderBatch) разделённым на секции:

• UpdatedComponents (ArrayRange<Diff>);
• ReferenceFrames (ArrayRange<Frame>);
• DisposedComponentIds (ArrayRange<int>);
• DisposedEventHandlerIds (ArrayRange<long>);
• StringTable (ArrayRange<string offsets>).

В конце пакета находятся 5 чисел (int32) — это смещения каждой секции в байтах (от начала массива).

Формат DOM

Сами узлы DOM хранятся в структуре под названием RenderTreeFrame, одна структура может описывать:

• HTML-тег;
• текстовое значение;
• атрибут;
• компонент Blazor;
• "голый" HTML-фрагмент.

Сам RenderTreeFrame выглядит так:

[Тип фрейма][Параметр 1][Параметр 2][Параметр 3][Параметр 4]

Тип фрейма определяет, что это за узел:

• 1 - HTML-тег (Element);
• 2 - текст (Text);
• 3 - атрибут (Attribute);
• 4 - Компонент Blazor (Component);
• 5 - Регион (Служебные данные) (Region);
• 8 - "Голый" HTML (Markup).

Таблица строк

Чтобы не дублировать текст, все строки (имена тегов, атрибуты, значения, текст)
хранятся в конце пакета в таблице строк.

Каждая запись содержит смещение на строку, а сами строки записаны как:

[LEB128-длина][UTF-8 байты строки]

Процесс восстановления HTML

1. Берём RenderBatch полученный от SignalR
2. Читаем 5 чисел в конце файла - получаем смещение секций
3. Переходим в секцию ReferenceFrames - получаем все узлы дерева (RenderTreeFrame)
4. Последовательно читаем фреймы:
   - если Element - создаём элемент;
   - если Attribute - добавляем к предыдущему тегу;
   - если Text - вставляем текстовое содержимое в предыдущий тег;
   - если Markup - вставляем HTML как есть;
   - если Region - рекурсивно обрабатываем последующие фреймы;
5. Используем свойство subtreeLength, чтобы понять, где заканчивается элемент;
6. Склеиваем всё в строку и получаем HTML.

P.S Реализация TS библиотеки доступна здесь.

Нам понадобится:

1. Моя утилита
2. Сам Рутокен Lite и PIN-код пользователя

1. Клонируем репозиторий и переходим в папку с кодом
2. Собираем утилиту с помощью go build
3. Запускаем утилиту, вводим PIN-код пользователя, и вводим метку (см. ниже) нужного контейнера

В указанной утилитой папке будет лежать экспортированный контейнер

Думаю многим знакома ситуация, когда ФНС (или любой другой УЦ) записывает контейнер с ЭЦП на Рутокен, а в процессе использования возникает необходимость использования ЭЦП без самого Рутокена (например из файловой системы) и т.д.

Однако та же ФНС "отключает" флаг экспортируемости контейнера и при попытке экспорта ключа мы получаем ошибку, а в Центре управления Рутокен'ом есть возможность только экспортировать сертификат.

Также следует упомянуть, что существует популярная утилита Tokens.exe от СКБ Контур, однако у неё есть ряд недостатков:

1. Утилита работает только на Windows
2. Написана на HTML с использованием устаревшего ActiveXObject с связке с DLL
3. Утилиту благополучно "выпилили" с сайта, поэтому приходится искать по всему интернету

Тащим ключи

1. Ищем контейнер

Рутокен Lite - не совсем флешка в привычном понимании, у него максимально облегченная файловая система, поэтому просто открыть его в проводнике не получится

Однако для этих целей можно воспользоваться утилитами от проекта OpenSC

Поэтому подключаем Рутокен, открываем консоль и вводим opensc-tool --list-files

Среди всего списка необходимо найти директорию с 6 файлами, часть из которых доступна для чтения только после авторизации (read[CHV2]). Сделать это легче всего по имени контейнера в КриптоПро, поскольку opensc-tool декодирует ASCII текст:

Файл на скриншоте это name.key, а директория с контейнером (выделена жёлтым) в нашем случае будет 3f00100010030a00

UPD от 05.08: Вероятнее всего все контейнеры действительно лежат по пути 1000/1003. Соответственно при помощи команды asn1 искать по имени контейнера:

2. Выгрузка

Запускаем opensc-explorer и переходим в директорию контейнера с помощью команды cd <путь>

В директории файлы лежат в следующем порядке: name.key, header.key, primary.key, masks.key, primary2.key, masks2.key

Теперь самый важный пункт - необходимо авторизоваться по PIN-коду пользователя (в противном случае Рутокен даст выгрузить только name.key и header.key). Сделать это можно с помощью команды verify CHV2 "PIN-код"

Теперь же просто копируем файлы контейнера в память компьютера с помощью команды get File_ID путь_назначения

На этом всё, мы успешно скопировали контейнер с Рутокен Lite в память нашего компьютера. Далее желательно "пролечить" контейнер, чтобы "включить" флаг экспортируемости, но на текущий момент решение ещё в разработке (оповещение о релизе будет в Telegram канале). To be continued...

Бонус. Экспорт приватного ключа

Для удобства использования ключа подписи, его можно экспортировать в формат .pem (с которым умеет работать OpenSSL и прочие утилиты) с помощью моей онлайн-утилиты
В утилиту загружаем файлы header.key, masks.key и primary.key, поле "Пароль" оставляем пустым (поскольку контейнеры на Рутокенах не имеют пароля т.к происходит авторизация по PIN-коду) и нажимаем "Извлечь", через несколько секунд скачается .pem файл с приватным ключом.

• Принцип работы
• Режимы безопасности
• Теоретические атаки
• Слайд-атака
• Корреляционный подход
• Линейный шаг
• Практические атаки
• Replay-атака
• Клонирование пульта
• Future-атака
• Rollback-атака
• Rolljam-атака
• Атака на мануфактурные ключи (KGB attack)
• Enc00-атака
• Unknown-атака
• Заключение
• Использованные материалы

Итак, начнём с выдержки из Википедии:

KeeLoq - блочный шифр, основанный на NLFSR (регистр сдвига с нелинейной обратной связью), разработан компанией Nanoteq Pty Ltd. и продан компании Microchip Technology Inc. Шифрование происходит блоками по 32 бита с помощью 64 битного ключа за 528 итераций. Ранее использовался в автомобильных сигнализациях, а ныне используется в автоматических воротах, гаражных дверях и т.п

Принцип работы

KeeLoq реализует так называемый code hopping (переключение кода), то есть генерирует уникальный пакет данных для каждой передачи.

Разберём на примере:

239B3DEBF16C47A6

Первые 4 байта - это фиксированная часть (т.н fix), содержит в себе ID нажатой кнопки на пульте (в нашем случае 2) и 28'ми битный серийный номер пульта (39B3DEB)

Следующие 4 байта - динамическая часть (т.н hop), зашифрована мануфактурным ключом (ключом производителя). В расшифрованном виде выглядит так:

21EB000A

Здесь мы видим всё тот же ID нажатой кнопки (2), 12 бит дополнительной информации (зачастую это serial & 0x3FF) и сам 16 битный счётчик нажатий (000A)

Логика работы счётчика такая:

• Если переданное значение счётчика соответствует значению в EEPROM приёмника то приёмник подаёт сигнал контроллеру, что всё хорошо (и контроллер например открывает ворота)

• Если переданное значение больше значения в EEPROM то приёмник синхронизируется с переданным значением и соответственно после следующей передачи значения начнёт работать штатно

• Если переданное значение меньше значения в EEPROM то приёмник игнорирует переданную команду, а в некоторых случаях после нескольких отправок "устаревшего" значения и вовсе отвязывает пульт. (Собственно говоря это и есть опасность при экспериментах с KeeLoq)

Режимы безопасности

В стандарте KeeLoq есть 3 режима безопасности (также известны как KDF, learnings):

• Простой режим (Simple learning)
  Наименее защищённый режим, при котором мануфактурный ключ никак не преобразуется и используется в шифровании as is.
• Классический режим (Normal learning)
  Улучшенная версия, где мануфактурный ключ изменяется с помощью серийного номера пульта с помощью побитовых операций

• Безопасный режим (Secure learning)
  Модифицированная версия классического режима, использующая вместо побитовых операций над серийным номером, дополнительное значение (он же seed), уникальное для каждого пульта и передающееся при первоначальной привязке пульта к приёмнику. На данный момент самый защищённых режим из представленных в стандарте

Однако некоторые производители отклоняются от стандартных режимов безопасности и реализуют свои собственные, давайте рассмотрим некоторые из них:

• Magic XOR Type-1 learning
  Используется производителем Beninca, представляет из себя XOR серийного номера пульта на мануфактурный ключ

• FAAC SLH (SPA) learning
  Как понятно из названия, данный алгоритм используется производителем FAAC и по моему мнению является самым продуманным. Представляет из себя серию побитовых операций и шифрования

Теоретические атаки

Слайд-атака

Атака применима, преимущественно, к многораундовым кодам, каждый раунд которых представляет собой несложное преобразование исходного блока с использованием лишь одного ключа.

На первом этапе набрать порядка 2^32 пар открытый-зашифрованный текст
Далее (M,C) - одна из таких пар, F - функция преобразования. Суть такова:
если (M’,C’) такая, что P’= F(K,M) и C’= F(K,C), то K и есть искомый ключ.

В теории данная атака позволяет получить первые 32 бита ключа.

Корреляционный подход

Атака базируется на свойстве NLFSR - Cor(F) = 1
Оказывается, что для равномерно распределенных x2,x3,x4 имеет место следующее:

• {NLFSR(x4, x3, x2, x1, x0) = 0 | x0 ^ x1 = 0} = 5/8
• {NLFSR(x4, x3, x2, x1, x0) = 1 | x0 ^ x1 = 1} = 5/8

Используя это и аппроксимируя NLFSR вероятности, можно добиться определения очередной части ключа.

Линейный шаг

Последние 16 бит ключа определяются, если известны все предыдущие. Основываясь на том, что если мы знаем полностью 48 состояние в цикле,то можем записать:

Отсюда находим key^48 и аналогично key^49 ... key^63

Общая сложность всех теоретических атак - ≈2^52 (≈4503599627370496)

Практические атаки

Здесь я хочу поблагодарить Derek Jamison за прекрасные материалы по практическим атакам на KeeLoq

Replay-атака

Очень распространённая атака работающая, преимущественно, для статических кодов, и для уявизмых приёмников, которые не проверяют значение счётчика

Клонирование пульта

Если мы знаем мануфактурный ключ пульта то без проблем можем сделать копию, которая будет работать, однако делать так не рекомендуется т.к будет конфликт значения счётчика у оригинального пульта и у копии, и в результате при использования двух пультов (оригинального и копии) приёмник может просто отвязать ваш пульт

Future-атака

Если мы знаем мануфактурный ключ пульта то можно воспользоваться логикой работы счётчика и отправить "будущее" значение счётчика (было 0001 - стало 3E91), приёмник может подумать, что пульт "убежал" далеко вперёд и синхронизироваться с переданным значением и штатно работать со следующими значениями (3E92, 3E93 и т.п). При данной атаке оригинальный пульт полностью рассинхронизируется и дальнейшее его использования не рекомендуется по описанным выше причинам.

Rollback-атака

Данная атака весьма редкая, однако всё же возможна с некоторыми приёмниками. Она похожа на Future-атаку, однако вместо последующих значений, мы откатываем состояние счётчика после нескольких использований и приёмник может заново синхронизироваться с этими значениями.

Rolljam-атака

Вся суть атаки в том, что вы записываете сигналы с оригинального пульта и не даёте приёмнику получить их (например создавая помехи рядом с приёмником), после чего вы можете использовать записанные сигналы.

Однако следует учесть, что почти во всех странах (например в США, странах ЕС, РФ) глушение сигналов является незаконным.

Атака на мануфактурные ключи (KGB attack)

Идея заключается в том, что, возможно, приёмник умеет работать с несколькими мануфактурными ключами, а не только с одним. Если мы отправим fix от оригинального пульта, но закодируем счётчик с помощью другого мануфактурного ключа, то, возможно, оно откроется (обычно эту атаку комбинируют с Future-атакой, потому что вы не знаете, каким должно быть значение счётчика).

Enc00-атака

Атака представляет собой подмену fix оригинального пульта на fix другого пульта (также привязанного к приёмнику) и использование hop с оригинального пульта.

Важно, что после подмены, пульт, fix которого использовали, рассинхронизируется и перестаёт работать

Unknown-атака

Суть в том, что, когда приёмник не может декодировать hop, он использует значение 0. Для универсальных приёмников есть вероятность, что они откроются при значении 0.

Заключение

Не смотря на все описанные выше уязвимости, KeeLoq, также как и Mifare Classic (чей шифр Crypto-1 был взломан в далёких 2000x) остаётся популярным выбором для бюджетных систем безопасности (автоматические ворота, гаражные двери и т.п). Возможно в будущем все производители перейдут на более стойкие алгоритмы шифрования (например на AES), как это сделали Beninca и Hormann

Кстати, имея на руках мануфактурный ключ вы можете "поиграться" с KeeLoq онлайн в моём мини-приложении.

Использованные материалы

1. Моя собственная библиотека для работы с KeeLoq
2. Исходный код Unleashed Firmware для Flipper Zero
3. Материалы Derek Jamison по KeeLoq и его приложение "SubGHZ Rolling Flaws"

Скорее жив чем мёртв?

Учитывая, что метка всё-таки как-то определялась, то необходимость использования команды lf tune отпадала сама собой.

Поэтому необходимо было определить, может ли proxmark3 считать конфигурацию чипа через lf t55xx [detect / p1detect]. Введя команду, я получил следующий ответ:

[!] Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

Что ж, ещё не всё потеряно...

Принудительное оживление

Следующим шагом была попытка перезаписать нулевой блок метки, отвечающий за конфигурацию. Я делал это следующими командами:

lf t55xx write -b 0 -d 000880E0 -t
lf t55xx write -b 0 -d 000880E0 --r0 -t
lf t55xx write -b 0 -d 000880E0 --r1 -t
lf t55xx write -b 0 -d 000880E0 --r2 -t
lf t55xx write -b 0 -d 000880E0 --r3 -t

После чего я проверил метку командой lf t55xx detect и... видимо, одна из команд сработала:

После чего я попробовал записать на метку какой нибудь рандомный EM-Marine ID и считать его, это сработало!

Заключение

Получилась весьма короткая статья, но я думаю, она кому-нибудь да пригодится.

Вообще, восстановление работоспособности T5577 - это довольно-таки индивидуальная тема. То, что работает в одних случаях, может не работать в других.

Всего существует две версии данного алгоритма:

1. Legacy версия (ID начинается с префикса 15)
2. Новая версия (ID начинается с префикса 25)

На данный момент полностью реализованной является legacy версия, а поддержка новой версии есть только в libsession и вроде как планируется в pysogs.

Один ключ -> два ключа. Legacy версия.

Алгоритм

Для работы алгоритма нам понадобится:

• ID пользователя
• Публичный ключ сервера

Сам алгоритм:

1. Генерируем т.н "blinding factor": хэшируем с помощью Blake2B публичный ключ сервера и редуцируем результат.
   Обозначим, как k.
2. Из ID пользователя убираем префикс 05 и переводим его в ed25519.
   Обозначим, как A.
3. Умножаем k на A и получаем ключ ed25519, который является одним из возможных "слепых" id.
   Обозначим, как kA.

Сломанное условие

Как следует из заголовка, legacy версия генерирует 2 возможных "слепых" ID.

Второй возможный ID (kA2) генерируется на основе kA, только с изменённым (XOR на 128) sign битом.

И для того чтобы выяснить какой из двух ключей следует использовать, pysogs предлагает следующий код:

if kA[31] & 0x80:
    return kA[0:31] + bytes([kA[31] & 0x80])

Однако это условие совершенно не работает, поэтому в реализации клиентов пошли другим путём - получение "слепого" id из приватного ключа, вместо того чтобы получать его из публичного ключа. Таким образом сервер не знает наверняка, какой ключ из двух следует использовать, и надеется на клиент в результате чего в теории может произойти раздвоение пользователя.

Обратимая необратимость

Так же немало важным является то, что legacy версия (а фактически единственная версия на момент написания статьи) является обратимой вопреки всем заявлениям.

Для этого достаточно инвертировать полученный ранее "blinding factor", умножить его на слепой id, полученный ключ перевести в Curve25519 и в результате мы имеем ID пользователя.

Один ключ -> один ключ. Новая версия

На момент написания статьи эта версия реализована только в libsession, и поэтому может поменяться.

Самое главное отличие этой версии от legacy в том, что в процессе генерации "blinding factor" принимает участие ID пользователя вместе с публичным ключом сервера, что, в свою очередь, исключает возможность обратимости, как это было с legacy версией.

Т.е алгоритм следующий:

1. Генерируем "blinding factor": хэшируем с помощью Blake2B ID пользователя (вместе с префиксом) и публичный ключ сервера и редуцируем результат.
   Обозначим, как k.
2. Переводим ID пользователя из Curve25519 в ed25519.
   Обозначим, как A.
3. Умножаем скаляр k на A

На выходе получаем единственный Blinded ID для конкретного пользователя на конкретном сервере.

Ссылки

Моя библиотека "Session ID"

Проект Session.js

Проект bunsogs

Многие программы ГИС позволяют реализовать работу в МСК непосредственно. Так, в QGIS и в MapInfo Pro любая проекция может быть дополнена аффинным преобразованием, а в Global Mapper конформные проекции дополняются разворотом.

Постановка задачи

Имеется 6-7 пунктов, для которых известны координат X и Y в ГСК и в МСК. Необходимо подобрать параметры проекции представляющую МСК в ГИС.

При подборе параметров предполагается использовать один из пунктов в качестве центральной точки преобразования.

Подготовка данных

Имеем 2 каталога координат. Один содержит координаты пунктов в государственной системе, а именно в СК-42, 4 зона (EPSG:28404) в формате Y X:

4645997.49 5768521.60
4661392.15 5770068.91
4650059.09 5783332.41
4634241.37 5778952.22
4631481.69 5764570.61
4642125.18 5754643.12
4655952.19 5757337.28

А второй координаты в местной системе:

67266.64 30088.40
82697.29 31184.27
71759.40 44771.50
55822.67 40857.06
52643.65 26564.42
62990.64 16331.35
76888.20 18619.57

Каждая строка в обоих файлах соответствует одному и тому же пункту. В первой строке центральный пункт системы.

Очень важно помнить, что с точки зрения математической картографии МСК остаётся проекцией Гаусса-Крюгера и наследует её искажения. Поэтому важно знать, на какой именно ГСК основана МСК. Зачастую это заранее неизвестно, и приходится проводить предварительное исследование для выяснения этого вопроса.

В нашем примере мы предполагаем, что это либо СК-42, 4 зона, либо СК-63, район C. Создадим также каталог в СК-63:

330797.453706 5755981.4752
346208.044264 5757327.09534
335051.738244 5770735.14419
319180.795365 5766563.18288
316233.724465 5752221.19702
326744.900981 5742157.23182
340603.316544 5744670.19105

Получение параметров

Для вычислений воспользуемся моей утилитой.

Для начала необходимо определить базовую ГСК, сделаем это с помощью координатных невязок.

Загружаем каталог в СК-42 и в МСК в утилиту, и получаем значение невязок:

Теперь вычислим невязки аналогичным способом для СК-63:

Сравнив невязки мы понимаем, что базовая ГСК - СК-63

Получаем параметры 2D преобразования Гельмерта:

А также параметры Аффинного параметрического преобразования:

Вообще тема данной статьи не нова, ещё в далёком 2016 года Михаил Куликов (он же shukan) написал статью на Хабре в которой он предоставил программу на C, которая вытаскивала ключ для ГОСТ 34.10-2001. Чуть позже благодаря сообществу появилась версия и для ГОСТ 34.10-2012. Однако пробуя запустить все эти утилиты для контейнера ГОСТ 34.10-2012 512 бит сгенерированного в КриптоПро CSP 5.0, утилиты выдавали ошибку. Собственно это и стало мотивацией разобраться как там всё устроено и написать свою программу.

Как там всё устроено

Файл masks.key

Содержит в себе три Octet String, которые в свою очередь являются маской ключа (32 байта для 256 бит, 64 для 512), солью для деривации пароля и контрольной суммы маски соответственно.

Файл primary.key

Содержит зашифрованный приватный ключ (32 байта для 256 бит, 64 для 512), который после расшифровки надо разделить по модулю на поле Q эллиптической кривой ключа.

Файл header.key

Содержит всю информацию о контейнере: Сертификат, свойства ключа, параметры эллиптической кривой и алгоритма хэширования, первые 8 байт публичного ключа, а также контрольные суммы.

Получаем приватный ключ

Для получения приватного ключа необходимо выполнить следующие шаги:

1. Получение так ключа хранения с помощью CPKDF (CryptoPro Key Derivation Function) в которую передаётся пароль и соль из файла masks.key.
2. Расшифровка основного ключа с помощью ГОСТ 28147-89 (Магма) в ECB режиме с параметрами набора Z от ТК-26
3. Деление по модулю расшифрованного ключа на маску
4. Подстановка результата в ASN.1 конструкцию приватного ключа

Подводя итоги могу сказать, что это была достаточно сложная работа, отнявшая у меня годовой запас кофе и не только :) Однако я полностью доволен результатом.

Также хочу выразить благодарность Савелию Красовскому за его утилиту go-decrypto-pro, которая стала основной для моей программы, и VovkaTM за консультации и прочую помощь.

Ссылки

Программа - https://github.com/li0ard/ckey

Утилита go-decrypto-pro - https://github.com/savely-krasovsky/go-decrypto-pro

Если вы решили получить 2 магических файла для расшифровки DRM контента и у вас нету Android устройства с root, как в моём случае, то можно использовать эмулятор, который встроен в обычную Android Studio.

Для начала нам необходимо создать конфигурацию нашего устройства, для это заходим в Device manager и нажимаем Create Device

Далее выбираем марку нашего устройства (например я выбирал Pixel 6)

Сейчас нам необходимо сделать первый важный шаг: выбрать версию Android с Google APIs и без Google Play (иначе у вас не будет рута в adb). Лично я выбрал Android 9.0 Pie

Далее идут настройки, которые можно оставить без изменений. Запускаем наше устройство.

Установка Frida

Открывыем терминал и пишем:

pip install frida frida-tools

Далее заходим на официальную страницу проекта и скачиваем frida-server для вашей версии клиента на компьютере

В терминале пишем:

adb devices

Если у вас всё хорошо то отобразится примерно следующая картина:

Теперь настала очередь загрузить frida-server на наше устройство через терминал:

adb push frida-server /sdcard
adb shell
su
mv /sdcard/frida-server /data/local/tmp
chmod +x /data/local/tmp/frida-server
/data/local/tmp/frida-server

Теперь не закрывайте этот терминал и можете приступать к следующему шагу.

Установка дампера и получение ключей

Переходим по ссылке, скачиваем ZIP архив и разархивируем его.

После в терминале пишем:

python dump_keys.py

Должно написать "Hooks completed" и после этого необходимо начать просмотр, какого нибудь защищенного через Widevine контента (например демо страница BitMovin). Во время просмотра будут сообщения в консоли и в результате появится директория key_dumps в которой будут 2 файла с приватным ключом и идентификатором устройства.

Ссылки

Оригинальная статья - https://forum.videohelp.com/threads/408031-Dumping-Your-own-L3-CDM-with-Android-Studio

Мой телеграм канал - https://t.me/li0ard_notes (полумёртвое создание однако)

В этой статье пойдет речь о том, как устроен один из экзаменов ГИА-9, об устном собеседовании по русскому языку, а именно про так называемую безопасность, ведь в описании программы сказано, что подменить аудиозапись экзамена невозможно.

Программное обеспечение

В моем регионе используется программа Russo, которую я добыл с сайта одного образовательного учреждения

После нажатия на кнопку программа создает папку и ZIP архив с идентичным названием и содержимым. Структура названия папки/архива: 01-ДДММГГГГ-000000-код школы-номер аудитории.

В архиве мы можем видеть заголовочный файл и аудиозаписи участников по их порядковым номерам.

Псевдобезопасность

Файлы mp3 мы рассматривать не будем, т.к это самые обычные mp3'шки. Меня интересует заголовочный csv'шный файл. Открыв его, мы можем увидеть следующие данные:

Первая строка тут что то вроде magic заголовка, потом на следующей строке идет дата проведения, город, код учреждения, название учреждение, номер аудитории. Потом идет перечисление файлов участников и кол-во участников, я бы хотел остановиться на перечислении файлов. Как мы можем видеть тут записано название файла, дата и время (с точностью до секунд) создания, длина файла и CRC-32 сумма и всё. Лично я считаю, что это не спасает от подмены файлов, ведь можно оставить имя и отметку о создании файла, подменить файл и вписать новую длину и контрольную сумму, которая рассчитывается очень легко.

Что же делать?

Я считаю, что необходимо переработать данную систему и сделать например так, чтобы программа подписывала detached подписью (например тем же ГОСТ'овским сертификатом подписанным УЦ ФРДО) файл аудиозаписи, а в заголовочный файл можно было бы вносить значение этой самой подписи. Позже при проверке программа бы проверяла подпись на то кем она сделана и сравнивала бы её значение с заголовочным файлом.