А вам не кажется, что фраза «воспроизведение FullHD… в оригинальном качестве и со всеми вытекающими от просмотра данного формата плюсами, как на вашей домашней FullHD панели» ну никак не сочетается с пережатием видео в разрешение 640х480 с 70% качеством, а аудио в 48 КГц, 16 бит, стерео?
Код может быть вы и понятно написали «даже для самого начинающего в Python», но вот сам алгоритм я так и не вспомнил по коду. Вы бы побольше комментировали, поменьше приводили куски кода. Код всегда можно самому написать, если алгоритм понятен.
Результат деления чисел с плавающей запятой одинарной точности на Fermi GPU равен результату аналогичного деления на CPU, согласно документации (CUDA C Programming Guide)
Так и представил себе ситуацию, как админы наблюдают «бешеную» сетевую активность на одном из компьютеров, подходят к нему и смотрят на загрузку по сети в менеджере ресурсов. А там тишина да гладь! Только вернутся к своему компу, как опять начинается свистопляска. И так повторить до готовности. :)
Идея прикольная. Но я бы реализовал такой генератор в виде программы для смартфона: она будет также генерировать пароли и запоминать их. В таком случае сотруднику все же придется набивать на клавиатуре пароль при входе в систему, зато не надо будет палиться с «флешкой». Хранилище сгенеренных паролей можно защитить при помощи мастер пароля, который сотрудник может не менять долгое время или вообще не ставить
>> это ненадёжно
Достаточно, чтобы усложнить жизнь взломщику. :)
>> Вам извесны дизассемблеры шейдеров (для ати нвидиа)?
Nvidia CUDA не оперирует шейдерами, как таковыми.
Дизассемблер кода шейдера в OpenCL? Не, не слышал. Просто шейдеры написаны на своем языке, который не нужно дизассемблировать, чтобы понять его суть.
>>против дизассемблирования
Шифрование участков программы, применение обфусцирующих средств (виртуальных машин, например).
>>против reverse engineering'a
Проверка целостности памяти кода программы (чтоб break нельзя было поставить), проверка времени выполнения участков кода, применение обфусцирующих средств.
Если задаться целью узнать алгоритм программы, то это, конечно, всегда можно сделать. Вопрос только времени и ресурсов. Но против непрофессионалов указанные методы работают. А вот приведенный в статье метод может выполнить и непрофессионал.
То, что генерирует компилятор, не является частью исходного кода приложения. Это, скажем так, временные файлы компилятора. Он их просто сохранил на диск. Разве это попадает под нарушение лицензии?
Естественно, сам код, выполняющийся на GPU, обфусцировать не стоит. Скорость, конечно, упадет на порядок.
Так же можно сделать и для AMD dll. Но я написал, что есть лицензии, запрещающие дизассемблирование и reverse engineering. А здесь достаточно установить одну переменную окружения и вуаля!
Я просто к тому, что против дизассемблирования и reverse engineering'a можно бороться и довольно успешно. А тут, если не знать о такой фиче компилятора, можно наступить на грабли, аккуратно разложенные создателями компилятора.
Это фича компилятора от AMD, так как это есть в документации и даже описаны цели, зачем это было сделано.
Да, берем любое приложение с OpenCL, ставим компилятор от AMD, устанавливаем переменную окружения и смотрим на результат.
> зависит это от системы пользователя, а не от самой программы, и это на совести OpenCL для AMD, а не самих приложений?
Да.
> Есть способ для разработчика обезопасить себя от этого?
1) Проверять значение переменной в начале работы, возможно менять это значение в ходе работы.
2) Проверять наличие этих файлов на диске и удалять.
3) Не использовать OpenCL, как крайняя мера. :)
Нет, таких фишек нет (вроде как). Все, что можно реализовать на OpenCL, реализуется на IL, и наоборот. Вот только будет ли это работать на OpenCL — большой вопрос.
Основная фишка IL — больший контроль над происходящим и понимание, почему одно работает, а другое нет.
Я ж написал в первой части в разделе «Отличие от OpenCL».
Что касается скорости работы, у меня ядро на CAL/IL работало на 15% быстрее, чем на OpenCL. Возможно, новое SDK работает лучше, я не проверял.
Купить расческу для рук. Сменить компьютер. Не запускать «Hello world!». :)
Просто хотел предупредить разработчиков об этой лазейке.
Достаточно, чтобы усложнить жизнь взломщику. :)
>> Вам извесны дизассемблеры шейдеров (для ати нвидиа)?
Nvidia CUDA не оперирует шейдерами, как таковыми.
Дизассемблер кода шейдера в OpenCL? Не, не слышал. Просто шейдеры написаны на своем языке, который не нужно дизассемблировать, чтобы понять его суть.
Шифрование участков программы, применение обфусцирующих средств (виртуальных машин, например).
>>против reverse engineering'a
Проверка целостности памяти кода программы (чтоб break нельзя было поставить), проверка времени выполнения участков кода, применение обфусцирующих средств.
Если задаться целью узнать алгоритм программы, то это, конечно, всегда можно сделать. Вопрос только времени и ресурсов. Но против непрофессионалов указанные методы работают. А вот приведенный в статье метод может выполнить и непрофессионал.
Естественно, сам код, выполняющийся на GPU, обфусцировать не стоит. Скорость, конечно, упадет на порядок.
Я просто к тому, что против дизассемблирования и reverse engineering'a можно бороться и довольно успешно. А тут, если не знать о такой фиче компилятора, можно наступить на грабли, аккуратно разложенные создателями компилятора.
Да, берем любое приложение с OpenCL, ставим компилятор от AMD, устанавливаем переменную окружения и смотрим на результат.
> зависит это от системы пользователя, а не от самой программы, и это на совести OpenCL для AMD, а не самих приложений?
Да.
> Есть способ для разработчика обезопасить себя от этого?
1) Проверять значение переменной в начале работы, возможно менять это значение в ходе работы.
2) Проверять наличие этих файлов на диске и удалять.
3) Не использовать OpenCL, как крайняя мера. :)
Основная фишка IL — больший контроль над происходящим и понимание, почему одно работает, а другое нет.
Что касается скорости работы, у меня ядро на CAL/IL работало на 15% быстрее, чем на OpenCL. Возможно, новое SDK работает лучше, я не проверял.