Все дело в том, что в WPF используется множество механизмов неявного связывания по имени. Наш обфускатор распознает и корректно обрабатывает многие из этих случаев, но во-первых, разумеется, мы могли что-то и упустить, а во-вторых местами неявное связывание слишком уж неявное чтобы его выявить и обработать :) Особенно в этом плане опасны случаи генерации WPF содержимого непосредственно из кода приложения.
Чтобы выявить проблемную область, мы рекомендуем перенаправить поток ошибок в текстовый файл (по типу: you.exe 2> log.err), а затем скормить его стек трейс декодеру. Он подскажет с чем связана ошибка, дальше как правило достаточно добавить атрибут ObfuscationAttribute.
Как альтернативный вариант: если Вы дадите нам пример незащищенной сборки в которой проявляется ошибка, мы сможем диагностировать проблему и помочь Вам исправить её.
Кстати, я думаю, что генерация мусора вообще не обязательна. В не выполняемых ветках предиката можно просто вставить переход на непредсказуемый участок пользовательского кода (точнее передвинуть этот участок под предикат, чтобы скрытно было). Это также убережёт от раздувания екзешника. В текущей реализации мы так и делаем: выглядит очень ествественно как на уровне IL так и в декомпилированном виде.
Неразрешимость будет даже тогда, когда память потенциально бесконечна. Если генерировать ту самую динамическую структуру в памяти, то, из-за того, что эмуляция локальны, в каждом конкретном участке кода нельзя будет предугадать реальный объём занимаемый структурой. Естественно структура должна быть скрытной, чтобы не было априори известно, что в реальности не так много памяти она занимает.
Если встроить длинную арифметику и Диофантовы уравнения, то так же будет неразрешимость, так как параметры уравнения берутся из случайных даже потенциально сколь угодно больших участков в памяти, например. Но тут нет скрытности и хакер просто вырежет все неявные предикаты.
Я уверен, что подавляющее большинство случайных предикатов решается на ура.
Если сделать генератор, который создаёт предикаты и отсеивает те, которые решились на ура, то уже большинство предикатов не будут так просты.
Возможно я не совсем правильно понял Ваш вариант с хэшом. Как мне кажется эмулятор как раз сделан для того, чтобы проэмулировать вычисление sha1 и понять, что значение всегда такое-то. В этом предложении отсутствует элемент псевдослучайности входных параметров без которого задача решается эмуляцией.
Не забывайте что программа, кроме обеспечения непосредственно защиты, должна еще продолжать полноценно работать. Приложение сплошь покрытое предикатами по 20..50 операций умножения\деления\возведения в степень каждый, вряд ли будет приемлемо в использовании.
На самом деле, очень перспективной на будущее, видится реализация Opaque Predicates на базе указателей. В статье говориться о том, что эта задача, как и проблема останова, в общем случае, является неразрешимой. А неразрешимая задача всегда лучше NP полной :) Думаю что в ближайшее время мы продолжим наши исследования в этом направлении.
Не забывайте что программа, кроме непосредственно обеспечения самой защиты, должна еще продолжать работать :) Приложение, которое сплошь покрыто предикатами по 20..50 операций умножения\деления\возведения в степень каждый, вряд ли будет приемлемо в использовании.
На самом деле, очень перспективной на будущее, видится реализация Opaque Predicates на базе указателей. В статье упоминается, что эта задача считается неразрешимой, что еще лучше NP полноты :) Думаю в ближайшее время мы продолжим наши исследования в этом направлении.
Наша реализация генератора, к сожалению, не совсем идеальна
Мы не претендуем на NP-полноту задачи распознавания наших предикатов (именно поэтому не показываем реализацию). Но например, если бы генерировали тождественно истинные 3-КНФ (коньюктивные нормальные формы с тремя операндами в коньюнктах, типа: x==null & y!=null & z==null || x!= null & y==null в таком духе), то гарантировано не получилось бы написать распознаватель. Но когда мы реализовали это на практике, то оказалось, что в программе вставленный код сразу сильно бросается в глаза. Тогда мы задумались о скрытности предикатов, и в качестве временного решения, создали данный генератор. С учетом Control Flow обфускации выявление и удаление таких предикатов из кода будет достаточно затруднительно.
Статья же, охватывает тему Opaque Predicates намного более широко. Здесь поднимается вопрос о видах предикатов и разработке NP полного генератора. Мы планируем продолжать двигаться в эту сторону.
Замедление на нашем синтетическом тесте с большим объемом кода примерно в 1.2 раза, в реальной программе должно получиться еще меньше. Потребление памяти фактически никак не меняется, т.к. в предикатах используются переменные из пользовательского кода.
Да, речь, в первую очередь, шла именно про SenseLock. С ним у нас есть опыт работы.
Про Guardant Code слышу впервые, спасибо, обязательно посмотрю на досуге.
Но это не гарантирует что никто не догадается :) Как минимум, можно заметить что меняется иконка при отправки на обфускацию типового пустого приложения. Второй минус метода — вместимость хранения данных ограничена.
Но никто не мешает совмещать несколько методов ватермарков. Шанс что хакер вычислит их все, существенно меньше. Статья как раз направлена на всестороннее рассмотрение данной проблемы.
Да, аппаратные ключи — хорошее решение, когда клиентов не много и продукт большой. Мы скорее всего добавим их поддержку в Appfuscator в будущем. Но утечку дистрибутива они идентифицировать не помогут, в отличии от Watermark.
Место как раз не точное, каждый раз среди функций, отвечающих критериям «крупности» и вероятности выполнения, выбирается N случайных, в которые внедряется ватермарк. Соответственно в разных программах место так же будет отличаться. Коме того, в усиленном варианте на данные ватермарка буде завязано множество других функций и выпилить его будет весьма проблематично.
Не увидел в статье/комментариях самого главного: сколько в солнечную и в "среднюю" погоду вся конструкция выдает мощности на выходе в ваттах
ESP8266 для таких штук как раз оптимален, т.к. его цена ~3$.
Здесь почти наверняка проблема именно в переименовании.
Да, обязательно напишите что получится. И, в любом случае, мы будем рады помочь Вам советом.
Чтобы выявить проблемную область, мы рекомендуем перенаправить поток ошибок в текстовый файл (по типу: you.exe 2> log.err), а затем скормить его стек трейс декодеру. Он подскажет с чем связана ошибка, дальше как правило достаточно добавить атрибут ObfuscationAttribute.
Как альтернативный вариант: если Вы дадите нам пример незащищенной сборки в которой проявляется ошибка, мы сможем диагностировать проблему и помочь Вам исправить её.
Спасибо за отзыв!
Неразрешимость будет даже тогда, когда память потенциально бесконечна. Если генерировать ту самую динамическую структуру в памяти, то, из-за того, что эмуляция локальны, в каждом конкретном участке кода нельзя будет предугадать реальный объём занимаемый структурой. Естественно структура должна быть скрытной, чтобы не было априори известно, что в реальности не так много памяти она занимает.
Если встроить длинную арифметику и Диофантовы уравнения, то так же будет неразрешимость, так как параметры уравнения берутся из случайных даже потенциально сколь угодно больших участков в памяти, например. Но тут нет скрытности и хакер просто вырежет все неявные предикаты.
Если сделать генератор, который создаёт предикаты и отсеивает те, которые решились на ура, то уже большинство предикатов не будут так просты.
Возможно я не совсем правильно понял Ваш вариант с хэшом. Как мне кажется эмулятор как раз сделан для того, чтобы проэмулировать вычисление sha1 и понять, что значение всегда такое-то. В этом предложении отсутствует элемент псевдослучайности входных параметров без которого задача решается эмуляцией.
На самом деле, очень перспективной на будущее, видится реализация Opaque Predicates на базе указателей. В статье говориться о том, что эта задача, как и проблема останова, в общем случае, является неразрешимой. А неразрешимая задача всегда лучше NP полной :) Думаю что в ближайшее время мы продолжим наши исследования в этом направлении.
На самом деле, очень перспективной на будущее, видится реализация Opaque Predicates на базе указателей. В статье упоминается, что эта задача считается неразрешимой, что еще лучше NP полноты :) Думаю в ближайшее время мы продолжим наши исследования в этом направлении.
Кроме того, предикат еще надо выявить в размазанном коде и, при этом, не зарезать реальные if'ы (даже с 99% вероятностью невыполнимые).
Мы не претендуем на NP-полноту задачи распознавания наших предикатов (именно поэтому не показываем реализацию). Но например, если бы генерировали тождественно истинные 3-КНФ (коньюктивные нормальные формы с тремя операндами в коньюнктах, типа: x==null & y!=null & z==null || x!= null & y==null в таком духе), то гарантировано не получилось бы написать распознаватель. Но когда мы реализовали это на практике, то оказалось, что в программе вставленный код сразу сильно бросается в глаза. Тогда мы задумались о скрытности предикатов, и в качестве временного решения, создали данный генератор. С учетом Control Flow обфускации выявление и удаление таких предикатов из кода будет достаточно затруднительно.
Статья же, охватывает тему Opaque Predicates намного более широко. Здесь поднимается вопрос о видах предикатов и разработке NP полного генератора. Мы планируем продолжать двигаться в эту сторону.
Про Guardant Code слышу впервые, спасибо, обязательно посмотрю на досуге.
Но никто не мешает совмещать несколько методов ватермарков. Шанс что хакер вычислит их все, существенно меньше. Статья как раз направлена на всестороннее рассмотрение данной проблемы.