Напомните пожалуйста кто тут делает продукт — защиту исполняемых файлов от реверс-инжиниринга?
И если кто-то уже использовал и другие решения, особенно кросс-платформенные (OSX, Linux, Windows), поделитесь опытом пожалуйста.
Спасибо!
Здравствуйте, pinebit, Вы писали:
P>Напомните пожалуйста кто тут делает продукт — защиту исполняемых файлов от реверс-инжиниринга? P>И если кто-то уже использовал и другие решения, особенно кросс-платформенные (OSX, Linux, Windows), поделитесь опытом пожалуйста. P>Спасибо!
Кросс-платформенно вряд ли возможно.
Очень эффективно в защитной части делать все вызовы апи функций call в точку входа самой функции в dll. Вирусная метода. Единственный минус нужно будет некоторое время отбиваться от антивирусов тк они ваш обфусцированный код будут считать подозрительным или вирусным.
К этому следует добавить выполнение небольших частей защищенного кода в разных потоках (фибрах). Результаты потоков синхронизируются и собираются отдельно.
Чтобы реверс такого типа проанализировать нужно быть очень хорошо подготовленным и очень заинтересованным.
Здравствуйте, wantus, Вы писали:
W>Чисто из любопытства — надо именно, чтобы не смогли понять как оно конкретно устроено, или, чтобы не смогли сломать?
> чтобы не смогли понять как оно конкретно устроено
Ну и в целом, если разработчики хоть что-то сделали для защиты, взломщики (с любыми целями) поймут, что этот вопрос прорабатывали, а значит легко не будет.
Здравствуйте, pinebit, Вы писали:
P>Ну и в целом, если разработчики хоть что-то сделали для защиты, взломщики (с любыми целями) поймут, что этот вопрос прорабатывали, а значит легко не будет.
Я к тому спросил, что полная защита от реверсинга практически никогда реально не нужна. По сути я знаю единственный случай, где это было действительно оправданно — это оригинальный Skype. У них p2p система была построена на предположении, что все клиенты кошерные и ведут себя по спеку. Если бы клиент не был прошифрован вдоль и поперек, то его можно было бы "подправить" и поломать всю систему.
Если в коде есть само-проверки на целостность, то этого обычно достаточно, что отбить желание ковыряться в коде у большинства кул hacker'ов. Шифровать же его — это напрашиваться на false positives, blacklist'ы и прочие проблемы с репутацией. Даже если код подписан EV сертификатом.
Здравствуйте, TailWind, Вы писали:
W>>Если в коде есть само-проверки на целостность TW>А вы проверяете exe файл, или код в памяти?
Exe и process environment. Код в памяти проверять как бы весьма непросто и смысла особого нет, если его пропатчивают до того, как управление передается программе.
Здравствуйте, Lazytech, Вы писали:
P>>Точно! Спасибо!
L>Чуть не забыл, есть еще сторонний продукт VMPKit (VMProtect Integration Kit). Подробнее см. в этой теме:
Здравствуйте, andy, Вы писали:
A>Очень эффективно в защитной части делать все вызовы апи функций call в точку входа самой функции в dll.
Чем эффективно-то ?
Статическая таблица указателей на функции анализируется ещё на этапе заполнения. Динамический резолв (включая способы с хешем от имени вместо самого имени) тоже детский сад.
A>ИМХО все остальное чепуха.
Генерируемые при накатывании защиты виртуальные машины и преобразование реального кода в обфусцированный байткод — вот что работает. ИМХО даже LLVM преобразования на уровне шага трансформации IR менее эффективны.
Всё остальное чепуха.
Здравствуйте, pinebit, Вы писали:
P>Ну и в целом, если разработчики хоть что-то сделали для защиты, взломщики (с любыми целями) поймут, что этот вопрос прорабатывали, а значит легко не будет.
Разве это будет останавливать ?
Вы не поверите, но существуют люди, которые взламывают хорошо защищённые программы единственной функцией которых является выдача MessageBox.
Здравствуйте, wantus, Вы писали:
W>Код в памяти проверять как бы весьма непросто и смысла особого нет, если его пропатчивают до того, как управление передается программе.
Довольно просто, а сверить можно с образом на диске. Сам образ провалидировать по цифровой подписи. Но это всё тоже хрень.
Здравствуйте, pinebit, Вы писали:
P>Ну и в целом, если разработчики хоть что-то сделали для защиты, взломщики (с любыми целями) поймут, что этот вопрос прорабатывали, а значит легко не будет.
легко не будет если код выполняется на твоем сервере, остальное — вопрос времени и денег
I>легко не будет если код выполняется на твоем сервере, остальное — вопрос времени и денег
так у хакера же нет денег, потому ломать он ничего и не будет
интересно. неужели есть хакеры ломающие проги с числом закачек менее 10 тыс. в сутки?
ну сломает он мало-известную утилиту и как он эту сломанную версию раскручивать-распространять будет?
выложит на страницу с 1 человеком посетителей который есть он сам?
имхо сложность раскрутки для мало-популярных программ для сломанной и нормальной версии по трудозатратм равны.
I>>легко не будет если код выполняется на твоем сервере, остальное — вопрос времени и денег
L>так у хакера же нет денег, потому ломать он ничего и не будет
Стало быть софт никто не ломает. Ч.Т.Д. Тему можно закрывать
L>интересно. неужели есть хакеры ломающие проги с числом закачек менее 10 тыс. в сутки? L>ну сломает он мало-известную утилиту и как он эту сломанную версию раскручивать-распространять будет? L>выложит на страницу с 1 человеком посетителей который есть он сам? L>имхо сложность раскрутки для мало-популярных программ для сломанной и нормальной версии по трудозатратм равны. L>
Не будет никто твою прогу раскручивать.
Один из возможных вариантов для редкого софта: набирается критическое число желающих получить сломанную версию. Хакеру платятся деньги (баллы рейтинга, и т.д.) на всяких закрытых ресурсах. Всё. Для мотивации достаточно.
Другой: продвинут чёрным СЕО (дорвеи, спам), продадут сломанные лицензии и забудут.
Вызывает уважение ваши практические знания и наработки в этой области, а также понимание всех частей фразы, что вы написали. Здесь минимум сарказма.
IID>Генерируемые при накатывании защиты виртуальные машины и преобразование реального кода в обфусцированный байткод — вот что работает. ИМХО даже LLVM преобразования на уровне шага трансформации IR менее эффективны.
Я так же надеюсь, что мы обсуждаем, как в домашних условиях собрать велосипед, а не запустить ракету. Про себя замечу, что в домашних условиях никогда не запускал ракету, то многократно в разное время собирал и разбирал программные велосипеды.
Замечу, что обфусцированный код нужен постольку-поскольку! Обфусцированный байткод из одних ассемблерных команд даст другие ассемблерные команды, которые так же хорошо читаются. Вся свистопляска с обфусцированием затевается, чтобы нарушить опорные точки по которым взломщик может понять алгоритм. Взломщик это не машина, а человек, который положительно воспринимает символьные строки и наименования функций, а не нагромождение машинных команд. Следовательно нужно в первую очередь скрыть порядок вызова апи функций, их символьные наименования и строки или по крайне мере сделать, чтобы это было максимально запутано.
Здравствуйте, pinebit, Вы писали:
P>Напомните пожалуйста кто тут делает продукт — защиту исполняемых файлов от реверс-инжиниринга? P>И если кто-то уже использовал и другие решения, особенно кросс-платформенные (OSX, Linux, Windows), поделитесь опытом пожалуйста.
Ну вот например, если в программе есть какие-то важные, с точки зрения алгоритма ее работы, но не очень критичные по времени исполнения куски, я бы подумал на премет скомпилировать их вот этой забавной штучкой: https://github.com/xoreaxeaxeax/movfuscator
Подробнее см. в этой теме:
