Вариации DRM и прочие TPM?

Вариации DRM и прочие TPM?

Ну да, а дальше? Как это выглядеть-то должно в рамках протокола между клиентом и сервером? Меня вот этот вопрос интересует.

не прокатит. Код будет открытым и DRM выпиливается

не прокатит. Код будет открытым и DRM выпиливается

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

То, что DRM не работает by design, это другой вопрос.

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

Однако, хэши надо бы...

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

Что там с игрушками я не знаю, но я бы ещё смотрел в этом случае таблицу активных процессов на предмет наличия там запущенных имён файлов для известных читов.

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

Хэш чего, куда, кому и как это поможет?

открытый код, выложенный на GitHub

GitHub - это сервис, который выполняет код, исходный код которого выложен на сервисе, который выполняет код, исходный код которого выложен на сервисе…

как удостовериться, что код, который реально запущен на сервере – это именно открытый код, выложенный на GitHub, а не какая-нибудь поделка от ЦРУ/ФСБ/Моссада

Кмк, всё это очень и очень опосредовано. Для примера, если вдруг условный вибер откроет код сервера, он что от этого перестанет быть аффилированным спецслужбами?

Т.е. в реальности остаётся техническое доверие эндпойнту (сертификаты) и вера в добропорядочность хостера.

При старте приложение выполняет взятие хэша файла, который известно что должен быть на машине-клиенте

Удаленный сервер может подсунуть тебе любой хэш. Просто заменяешь функцию calculate_hash на return aaabbbcccdddeeefff и ты в шоколаде.

Отвечая на вопрос ТС: видимо, никак не сделаешь такую проверку. Единственный вариант, который приходит на ум, это когда сборка из исходников делается на стороне CA и они подписывают собранный бинарь.

Единственный вариант, который приходит на ум, это когда сборка из исходников делается на стороне CA и они подписывают собранный бинарь.

Ииииии как это помешает делать проверку подписанного бинаря, а в реале исполнять совершенно другой код?

Я понимаю, что технически это не слишком возможно. Но мне интересно, были ли попытки это сделать.

Если код приложения открыт, и доступ к серверу есть только у одной стороны - то очевидно никак.

Да просто.

Хэш чего, куда, кому и как это поможет?

Положим, есть приложение app. Я хочу удостовериться что это приложение, распространяемое в двоичном виде (уже скомпилированное и слинкованное) запускается у пользователя на машине в немодифицированном виде. Т.е., ни кто не лазил по нему с дебаггером и ничего там не модифицировал.

Самое простое и достаточно надёжное (исключая отдельных «великих гуру отладчика») это на момент сборки бинарника дописать в него функцию проверки хэша для файла argv[0] и прописать результат хэш-функции для сравнения. Т.е., при запуске app вычисляется хэш для файла из argv[0] и сравнивается с заданным в коде приложения.

От модификации кода отладчиком это не спасёт конечно, но для того, чтобы показать что у пользователя код приложения модифицирован, можно например, в отдельном потоке этого же приложения «стучать» на пользователя, дескать, код «подкорректирован». Тут уже на что фантазии хватит.

Разве что клиентское приложение может стучать на другой, эдакий эталонный сервер (заведомо немодифицированный), и сравнивать полученные результаты с ним. Но тогда зачем другие сервера нужны?:)

Вообще-то...

В случае, если у меня права на модификацию файла и отладчик, то по барабану удалённый сервер или нет. И смысл в «удалённом сервере» как таковом вообще ускользает. Потому что достаточно просто при определённых навыках просто и тупо откусить всю проверку, вернув из функции check_validity() что-нибудь типа return TRUE;.

Единственный вариант, который приходит на ум, это когда сборка из исходников делается на стороне CA и они подписывают собранный бинарь.

Нет. Это не работает. Причина выше. Даже в случае, если созданный бинарь зашифрован и при запуске он расшифровывается, вопрос стойкости такого приложения это просто вопрос времени. И желания атакующего. Но для практики такой подход слишком муторный и затратный.

Положим, есть приложение app. Я хочу удостовериться что это приложение, распространяемое в двоичном виде (уже скомпилированное и слинкованное) запускается у пользователя на машине в немодифицированном виде.

Мойша не читатель, речь идет о запуске на сервере, а не клиенте.

Батттенька...

Да только на ЛОРчике аноним может такую глупость сказать.

речь идет о запуске на сервере, а не клиенте.

Во всех остальных более приличных местах, Вас бы забили досмерти ссаными тапками. Просто потому, что понятие «клиент» и «сервер» это чисто программные понятия, которые относительны. И код на «сервере» вполне себе может быть кодом «колента». И код на «клиенте» вполне может оказаться «серверным».

Делание на роли тут условно. Подставьте то, на что у Вас мозгов хватит.

Подставьте то, на что у Вас мозгов хватит.

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

reproducible builds и хэши.

А хеш тебе отдаст сервер.

Это к чему? Собрали бинарник, разместили на сервере, опубликовали хэш, который можно проверить, собрав пакет (reproducible builds).

разместили на сервере, опубликовали хэш

То есть на честном слове? Ты не проверишь, настоящий это хеш или нет, если нет доступа к серверу.

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

То есть на честном слове

На открытости. Если ПО такое важное — за это будет отвечать несколько человек (можно даже при понятых загрузить бинарник на сервер, можно при понятых стрим провести, что ПО компилируется на машине, проверяется хэш, потом загружается на сервер). А в этом ПО может быть своя проверка хэша.

при понятых

Насколько понимаю, ОП интересовался о техническом решении, а не об административном.

А в этом ПО может быть своя проверка хэша.

проверка хеша внутри приложения выкусывается плоскогубцами. никакой серьезной надежды на это нет.

Это и не серьёзная, а дополнительная.

Насколько я понимаю white box cryptography +/- про это.

Тогда reproducible builds и хэш.

Так ты не сможешь убедиться, что запущенный билд - тот самый.

Да.

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

Именно так и реализуется тот же boot guard, т.е., тот кусок BIOS, который при подаче питания на плату запускается первым и проверяет можем ли мы вообще загружать текущий образ BIOS (UEFI там в этот момент ещё и не пахнет).

Но и то это относительная защита, т.к. если я смог каким-либо образом перешить флеш на материнке, то там уже и boot guard можно отключить и подменить образ на нужный, с сохранением нужного хэша. И далее грузиться будет то, что нужно. Это да, гимор, но решаемо.

А так-то Вы правы. Вот только вся эта защита, как и всегда, это «ключи от добрых людей». У злоумышленника всегда есть шанс. Ненулевой.

Не поймёт он.

Тогда reproducible builds и хэш.

Туп он ибо. Умишком зело скорбен.

загружать текущий образ BIOS (UEFI там в этот момент ещё и не пахнет).

В современных UEFI нет никакого BIOS, он переключается в 32/64 битный режим почти сразу после reset. Смотрите исходники EDK2.

White-box cryptography combines methods of encryption and obfuscation to embed secret keys within application code. The goal is to combine code and keys in such a way that the two are indistinguishable to an attacker, and the new “white-box” program can be safely run in an insecure environment.

Нет, чувак, это не про это.

Если ПО такое важное — за это будет отвечать несколько человек (можно даже при понятых загрузить бинарник на сервер, можно при понятых стрим провести, что ПО компилируется на машине, проверяется хэш, потом загружается на сервер). А в этом ПО может быть своя проверка хэша.

А потом кто-нибудь поменяет серверам IP и твои запросы пойдут на совсем другой сервер. Это не работает.

ЛОЛ, ПРАСТИТИ, ШТА?!? =)))

В современных UEFI нет никакого BIOS, он переключается в 32/64 битный режим почти сразу после reset.

Милейший, если бы Вы не были столь бестолковы (в чём я убеждаюсь вот уже в который раз), то Вы бы знали что Tianocore EDK2 выполняется намного позже, чем стадия под названием SEC. Стадия SEC в загрузке BIOS это и есть реализация того самого boot guard, про который я и сказал.

Эту стадию легко заметить на приведённой диаграмме. Она в самом верхнем левом углу показана на приведённой диаграмме. Стадия, где актуален UEFI (да-да-да, тот самый EDK2) начинается в аккурат после стадии DXE и в начале стадии BDS. На картинке нарисовано достаточно хорошо, найдёте и сами.

Далее. Если бы Вы хоть что-то окромя переносимой Вами дури знали, то Вы смогли бы взять открытую реализацию BIOS под названием coreboot и с удивлением узнать что именно coreboot в качестве одного из payloads (там можно выбрать и взять хоть SeaBIOS) грузит этот самый UEFI, который собирается из EDK2. И происходит это намного позже того, как подали питалово на материнку.

Точно так же дело обстоит везде, с чем я сталкивался и сталкиваюсь – хоть в libreboot, хоть в проприетарном решении от AMI под названием AptioV (VisualeBios).

В общем, приговор как обычно – матчасть учить. Бе-гом! =)))

Есть еще одно дебильное решение - ОС, которая не сможет запустить неподписанный третьей стороной бинарь, где третья сторона - «понятые». Но ничего не помешает тебе даже и в таком случае загрузить на сервере ядерный модуль и убрать проверку.

Есть еще одно дебильное решение - ОС, которая не сможет запустить неподписанный третьей стороной бинарь, где третья сторона - «понятые». Но ничего не помешает тебе даже и в таком случае загрузить на сервере ядерный модуль и убрать проверку.

Это не помешает просто загрузить код на другом сервере, на котором нет такой дебильной ОС.

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

то Вы бы знали что Tianocore EDK2 выполняется намного позже, чем стадия под названием SEC. Стадия SEC в загрузке BIOS это и есть реализация того самого boot guard, про который я и сказал.

SEC не имеет никакого отношения к старому BIOS с 16 битными вызовами. Это совершенно другой стек технологий, свободный от наследия IBM PC и DOS.

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

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

Может, как-нибудь ради поиска вдохновения почитаю материалы о реверсе всяких DRM. Там иногда встречается странное и интересное.

Чё, серьёзно? =)))

То Вы пишете:

В современных UEFI нет никакого BIOS,

То Вы пишете:

SEC не имеет никакого отношения к старому BIOS с 16 битными вызовами.

Вы бы определились бы что ли про что «звиздить» изволите? Про старый BIOS я сейчас даже рассуждать не буду, т.к. тема вообще не про это. В остальном, я ещё раз показал на пальцах интуитивно понятном уровне где Вы дол… ну, Вы меня поняли.

И да, в легаси BIOS там вообще много чего может не быть. Того же UEFI. Как это к теме-то относится? И к тому, как люди пытаются обеспечить хоть какую-то безопасность в наши времена?

Замечу так же что я Вас за язык не тянул.

Хотя, опять же, никто не мешает проксировать запросы о проверке целостности на другой сервер, крутящий немодифицированный код.

На этом все и спотыкается. Тут разве что подходит вариант, о котором я писал выше (как работает например электрум, криптокошелек, если память не изменяет) - если какая-то серверная нода отдает отличный от других результат, ты ее выкидываешь. Но по понятным причинам, этот подход не везде работает.

Может, как-нибудь ради поиска вдохновения почитаю материалы о реверсе всяких DRM. Там иногда встречается странное и интересное.

Например?

Тут разве что подходит вариант, о котором я писал выше (как работает например электрум, криптокошелек, если память не изменяет) - если какая-то серверная нода отдает отличный от других результат, ты ее выкидываешь. Но по понятным причинам, этот подход не везде работает.

Да, это работает только в одноранговых сетях. В варианте клиент-сервер это бесполезно, особенно если серверы контролируются одной организацией.

Например?

Напишу когда найду.

BIOS – это прошивка IBM PC-совместимых компьютеров, предоставляющая 16 битный интерфейс вызовов через прерывания (int 10h и т.п.). В современных компьютерах такой прошивки нет, а новые прошивки словом «BIOS» не называют. Вы сами привели SeaBIOS.

Не корми дебила, а то он интересный тред опять скатит.

Вполне возможно, все технологии для этого давно есть. https://signal.org/blog/private-contact-discovery/ тут можешь почитать пример, как это сделано у Signal, весь код у него открыт, можешь и посмотреть.

тут можешь почитать пример, как это сделано у Signal.

Я читал. Ответ тот же: никак.

Ну ок, если тебе так удобней.

Дело не в том, как мне удобнее. Я читал эту статью раньше. Там написано, грубо говоря, следующее:

• Серверный код умеет в повторяемые сборки
• Код (по их словам) выполняется в Intel SGX
• Клиент может послать запрос и получить ответ, посчитанный внутри анклава с учётом версии кода

Подумай сам, что именно здесь может сломаться.