Комментарии 17
Осталось понять, баг это все-таки или фича:)
Я правильно поднял что для любого приложния достаточно воткнуть видеокарту от MAD и посмотреть как оно работает, т.е. зависит это от системы пользователя, а не от самой программы, и это на совести OpenCL для AMD, а не самих приложений? Есть способ для разработчика обезопасить себя от этого?
Я правильно поднял что для любого приложния достаточно воткнуть видеокарту от MAD и посмотреть как оно работает, т.е. зависит это от системы пользователя, а не от самой программы, и это на совести OpenCL для AMD, а не самих приложений? Есть способ для разработчика обезопасить себя от этого?
Для любого приложения, использующего OpenCl и для AMD, а не MAD, конечно же.
Это фича компилятора от AMD, так как это есть в документации и даже описаны цели, зачем это было сделано.
Да, берем любое приложение с OpenCL, ставим компилятор от AMD, устанавливаем переменную окружения и смотрим на результат.
> зависит это от системы пользователя, а не от самой программы, и это на совести OpenCL для AMD, а не самих приложений?
Да.
> Есть способ для разработчика обезопасить себя от этого?
1) Проверять значение переменной в начале работы, возможно менять это значение в ходе работы.
2) Проверять наличие этих файлов на диске и удалять.
3) Не использовать OpenCL, как крайняя мера. :)
Да, берем любое приложение с OpenCL, ставим компилятор от AMD, устанавливаем переменную окружения и смотрим на результат.
> зависит это от системы пользователя, а не от самой программы, и это на совести OpenCL для AMD, а не самих приложений?
Да.
> Есть способ для разработчика обезопасить себя от этого?
1) Проверять значение переменной в начале работы, возможно менять это значение в ходе работы.
2) Проверять наличие этих файлов на диске и удалять.
3) Не использовать OpenCL, как крайняя мера. :)
Точно так же можно перехватить вызов CUDA dll и сдампить себе ядро, которое потом дизассемблировать. Да, конечно, это немного сложнее.
Так же можно сделать и для AMD dll. Но я написал, что есть лицензии, запрещающие дизассемблирование и reverse engineering. А здесь достаточно установить одну переменную окружения и вуаля!
Я просто к тому, что против дизассемблирования и reverse engineering'a можно бороться и довольно успешно. А тут, если не знать о такой фиче компилятора, можно наступить на грабли, аккуратно разложенные создателями компилятора.
Я просто к тому, что против дизассемблирования и reverse engineering'a можно бороться и довольно успешно. А тут, если не знать о такой фиче компилятора, можно наступить на грабли, аккуратно разложенные создателями компилятора.
Если лицензия запрещает дизассеблирование — то и подход, описанный в статье, тоже противоречит этой лицензии. То, что код получен штатными средствами компилятора никого не волнует.
Что же на счёт защиты, то в большинстве случаев пытаются хотя бы заставить работать ядра на GPU на порядок быстрее, чем на обычном CPU. Если туда вставить всякие защиты от отладки — то производительность ядер упадёт и толку от использования GPU не будет никакого.
Впрочем, сильно оптимизированный код читается и реверсится тоже тяжко. Помню, была одна замечательная статья про умножение разряженных матриц на ATI, результирующее ядро у них получилось вот такое, тут в исходниках то сложно сходу разобраться, как оно работает.
Что же на счёт защиты, то в большинстве случаев пытаются хотя бы заставить работать ядра на GPU на порядок быстрее, чем на обычном CPU. Если туда вставить всякие защиты от отладки — то производительность ядер упадёт и толку от использования GPU не будет никакого.
Впрочем, сильно оптимизированный код читается и реверсится тоже тяжко. Помню, была одна замечательная статья про умножение разряженных матриц на ATI, результирующее ядро у них получилось вот такое, тут в исходниках то сложно сходу разобраться, как оно работает.
То, что генерирует компилятор, не является частью исходного кода приложения. Это, скажем так, временные файлы компилятора. Он их просто сохранил на диск. Разве это попадает под нарушение лицензии?
Естественно, сам код, выполняющийся на GPU, обфусцировать не стоит. Скорость, конечно, упадет на порядок.
Естественно, сам код, выполняющийся на GPU, обфусцировать не стоит. Скорость, конечно, упадет на порядок.
>>против дизассемблирования и reverse engineering'a можно бороться и довольно успешно
как?
как?
>>против дизассемблирования
Шифрование участков программы, применение обфусцирующих средств (виртуальных машин, например).
>>против reverse engineering'a
Проверка целостности памяти кода программы (чтоб break нельзя было поставить), проверка времени выполнения участков кода, применение обфусцирующих средств.
Если задаться целью узнать алгоритм программы, то это, конечно, всегда можно сделать. Вопрос только времени и ресурсов. Но против непрофессионалов указанные методы работают. А вот приведенный в статье метод может выполнить и непрофессионал.
Шифрование участков программы, применение обфусцирующих средств (виртуальных машин, например).
>>против reverse engineering'a
Проверка целостности памяти кода программы (чтоб break нельзя было поставить), проверка времени выполнения участков кода, применение обфусцирующих средств.
Если задаться целью узнать алгоритм программы, то это, конечно, всегда можно сделать. Вопрос только времени и ресурсов. Но против непрофессионалов указанные методы работают. А вот приведенный в статье метод может выполнить и непрофессионал.
>>>>>против дизассемблирования
Шифрование участков программы, применение обфусцирующих средств (виртуальных машин, например).
>>против reverse engineering'a
Проверка целостности памяти кода программы (чтоб break нельзя было поставить), проверка времени выполнения участков кода, применение обфусцирующих средств.
это ненадёжно. Поэтому гпу интересен именно как аппаратная ВМ.
Вам извесны дизассемблеры шейдеров (для ати нвидиа)?
Шифрование участков программы, применение обфусцирующих средств (виртуальных машин, например).
>>против reverse engineering'a
Проверка целостности памяти кода программы (чтоб break нельзя было поставить), проверка времени выполнения участков кода, применение обфусцирующих средств.
это ненадёжно. Поэтому гпу интересен именно как аппаратная ВМ.
Вам извесны дизассемблеры шейдеров (для ати нвидиа)?
>> это ненадёжно
Достаточно, чтобы усложнить жизнь взломщику. :)
>> Вам извесны дизассемблеры шейдеров (для ати нвидиа)?
Nvidia CUDA не оперирует шейдерами, как таковыми.
Дизассемблер кода шейдера в OpenCL? Не, не слышал. Просто шейдеры написаны на своем языке, который не нужно дизассемблировать, чтобы понять его суть.
Достаточно, чтобы усложнить жизнь взломщику. :)
>> Вам извесны дизассемблеры шейдеров (для ати нвидиа)?
Nvidia CUDA не оперирует шейдерами, как таковыми.
Дизассемблер кода шейдера в OpenCL? Не, не слышал. Просто шейдеры написаны на своем языке, который не нужно дизассемблировать, чтобы понять его суть.
Пообщавшись некоторое время с профессионалами, которые в моём BarsWF до его open-source релиза добавляли свой функционал и интересовались некоторыми деталями имплементации (вроде зачем я тащу тригонометрию в ядро криптоанализа) я точно знаю, что бинарник — открытая книга для специалиста.
С GPU кодом это просто иногда чуть проще.
С GPU кодом это просто иногда чуть проще.
Я и не спорю, что специалист может если не все, то очень многое.
Просто хотел предупредить разработчиков об этой лазейке.
Просто хотел предупредить разработчиков об этой лазейке.
Какими, к чёрту, профессионалами?)
откройте любымым hex вювером ваш винарник и поищите: il_ps_2_0
всё найдётся всё: pastebin.com/XNdxZHZ4
откройте любымым hex вювером ваш винарник и поищите: il_ps_2_0
всё найдётся всё: pastebin.com/XNdxZHZ4
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анализируем проприетарное приложение на OpenCL, написанное с использованием AMD APP SDK