Здравствуйте, niXman, Вы писали:
pva>>Это в виде шутки? Ее ж заломали недавно. Да и ценник у нее кусючий. X>а vmprotect взломали, случаем не в курсе?
По VMP 2.x бегают какие-то скрипты + есть одна серъезная работа по восстановлению ВМ кода, но требует хотя бы средней квалификации. Не для скрипткиддис точно.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Barm, Вы писали:
bnk>>>Но вообще, в тращициях данного форума, попинаю bnk>>>IMHO, ерундой занимаетесь, если уж так нужно, просто возьмите готовый протектор.
B>>Угу. Готовые протекторы имеют готовые методики взлома.
M>Ты сможешь лучше, чем сделано в VmProtect?
B>>Мне нужен протектор: B>>1. Закачивающий ключи на клиента при оплате.
M>VmProtect (+vmpKit )
B>>2. Привязка ключей к железу клиента.
M>VmProtect
B>>3. Возможность простой перепривязки программы с одного рабочего места на другое (включая win64 и win32).
M>VmProtect
B>>Программа планируется дешевой, трата ручного времени на привязку каждого клиента исключена. B>>Максимум, что делается вручную — забивается e-mail клиента в базу данных "оплачено".
M>VmProtect
B>>Денег априори на службу поддержки-установки нет. .
M>VmProtect
Все заработало. Кажется я таки справился.
В win32 маска участка исполняемой команды имеет вид:
110000000000000000000011000000000000000000000001100000000000000000011000000000000000000000000000000 и т.д.
где единичками показаны изменяемые байты при загрузке dll в память. Т.е. изменяемые байты располагаются по два друг за другом.
Как показали эксперименты при шифровке их трогать нельзя, а шифровать можно только данные на некотором расстоянии между изменяемыми байтами (в маске это нули).
Тогда dll корректно грузиться в память и данные можно расшифровывать.
Я не верю в стандартные методики защиты, применяемые массово. Для них есть стандартные методики взлома.
На мой взгляд как раз оптимальный вариант — шифрование участков кода своей программы. Тем более, это относительно простая задача.
Если в программе зашифровать сотню процедур — задача слома программы становиться бессмысленной в случае, если цена программы не заоблачна.
Мне показалось, что иметь собственный протектор — более удобный подход, чем пользоваться сторонним.
Да, он более тупой, чем VMProtect, но чтобы его сломать, придется потратить время. А кому это нужно, если программа дешевая, а алгоритм шифровки неизвестен?
Всем спасибо за советы.
B>Все заработало. Кажется я таки справился. B>В win32 маска участка исполняемой команды имеет вид: B>110000000000000000000011000000000000000000000001100000000000000000011000000000000000000000000000000 и т.д. B>где единичками показаны изменяемые байты при загрузке dll в память. Т.е. изменяемые байты располагаются по два друг за другом.
Значит, это релоки.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, flаt, Вы писали:
F>Здравствуйте, Barm, Вы писали:
B>>Задача: сделать защиту программы (dll) путем шифрования участков кода. F>Ух. Это привет из… 1999 года?
Угу. Когда то давно я пописывал на делфи и этот привет тоже юзал.
B>>Метод решения: B>>1. После компиляции участки кода из исполняемого файла (шифруемых процедур, которые прописаны как static) копируются в отдельные файлики, а их место затирается дребеденью. F>Почему не просто зашифровать на месте, зачем файлы? Или зашифровать dll, если уж хочется совсем не давать код для demo?
Да, программу (demo) вообще нельзя сломать, если в ней вообще нет кода.
B>>Байты одни и те же. Т.е. содержимое основной массы байтов сохраняется, а небольшой массы байтов при загрузке меняется. F>За полтора года "проекта" про релоки не слышали?
Полтора года я делал основной код. С шифровкой разбирался около месяца. Это не трудная задача и не требует знания ассемблера вообще (и структуры pe-таблиц тоже). Достаточно сделать дамп памяти проги в файл, потом сравнить его с исходником и затереть данные в исходнике.
B>>2. Может быть в настройках visual studio есть какие-то параметры, которые делают код процедур dll-ки неизменяющимся при загрузке в память? F>В gcc есть -fPIC.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Barm, Вы писали:
B>>Задача: сделать защиту программы (dll) путем шифрования участков кода. Экспериментируем в visual studio 2008.
MD>Это видели? MD>http://rsdn.ru/article/baseserv/peloader.xml
Спасибо за инфу. Я не прячу dll. Я использую немного иной подход. Я поставляю dll без кусков кода, а куски кода поставляются как ключи после оплаты.
Собственно сложность защиты можно наращивать до бесконечности, используя несколько алгоритмов шифрования и формирования ключей. Так как процесс шифровки можно автоматизировать, то
наличие в программе хотя бы 5 вариантов шифра, применяемых по определенному правилу к 500 разбросанным участкам кода — приведет к тому, что задача слома становиться бессмысленной для проги минимальной стоимости.
Здравствуйте, Barm, Вы писали:
B>Я не верю в стандартные методики защиты, применяемые массово. Для них есть стандартные методики взлома.
Не стоит основываться на вере, лучше ориентироваться на факты. Есть факты, что VMProtect хорошо ломается?
B>На мой взгляд как раз оптимальный вариант — шифрование участков кода своей программы. Тем более, это относительно простая задача.
Нужно будет — сломают на раз. У тебя перестановка инструкций есть? Есть виртуализация со случайно генерируемым набором инструкций VM?
B>Если в программе зашифровать сотню процедур — задача слома программы становиться бессмысленной в случае, если цена программы не заоблачна.
А если их зашифровать VMProtect'ом?
B>Мне показалось, что иметь собственный протектор — более удобный подход, чем пользоваться сторонним.
Если есть очень много времени, то подход неплох.
B>Да, он более тупой, чем VMProtect, но чтобы его сломать, придется потратить время. А кому это нужно, если программа дешевая, а алгоритм шифровки неизвестен?
VMProtect легко ломается?
B>Всем спасибо за советы.
Не за что. Я, кстати, думаю, что ты нашел какой-то частный случай, который работает на твоей системе. На другой машине с другой виндой не факт, что заработает.
Удачи
Здравствуйте, Barm, Вы писали:
B>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Здравствуйте, Barm, Вы писали:
B>>>Задача: сделать защиту программы (dll) путем шифрования участков кода. Экспериментируем в visual studio 2008.
MD>>Это видели? MD>>http://rsdn.ru/article/baseserv/peloader.xml
B>Спасибо за инфу. Я не прячу dll. Я использую немного иной подход. Я поставляю dll без кусков кода, а куски кода поставляются как ключи после оплаты.
Ну, суть работы с секциями PE там показана хорошо. Равно как и проблемы типа релоков, защиты страниц exec-памяти от записи (функции семейства VirtualProtect) и т.п.
Причём заметьте, это ещё не вступили в игру корпоративные policy и антивирусы
B>Спасибо за инфу. Я не прячу dll. Я использую немного иной подход. Я поставляю dll без кусков кода, а куски кода поставляются как ключи после оплаты. B>Собственно сложность защиты можно наращивать до бесконечности, используя несколько алгоритмов шифрования и формирования ключей. Так как процесс шифровки можно автоматизировать, то B>наличие в программе хотя бы 5 вариантов шифра, применяемых по определенному правилу к 500 разбросанным участкам кода — приведет к тому, что задача слома становиться бессмысленной для проги минимальной стоимости.
Никто не будет ломать голову над вашими шифрами. Понаставят бракпоинтов и сдампят все в расшифрованном виде
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Barm, Вы писали:
B>Полтора года я делал основной код. С шифровкой разбирался около месяца. Это не трудная задача и не требует знания ассемблера вообще (и структуры pe-таблиц тоже). Достаточно сделать дамп памяти проги в файл, потом сравнить его с исходником и затереть данные в исходнике.
Ахаха, а drVano-то дурень не в курсе, годами сидит пилит свой VmProtect. А тут оказывается всё просто, месяц работы — и никто не взломает.
ЗЫ Твою защиту, думаю, за полдня любой школьник заломает. Тебя от взлома спасет только принцип неуловимого Джо.
Здравствуйте, ononim, Вы писали:
B>>Спасибо за инфу. Я не прячу dll. Я использую немного иной подход. Я поставляю dll без кусков кода, а куски кода поставляются как ключи после оплаты. B>>Собственно сложность защиты можно наращивать до бесконечности, используя несколько алгоритмов шифрования и формирования ключей. Так как процесс шифровки можно автоматизировать, то B>>наличие в программе хотя бы 5 вариантов шифра, применяемых по определенному правилу к 500 разбросанным участкам кода — приведет к тому, что задача слома становиться бессмысленной для проги минимальной стоимости. O>Никто не будет ломать голову над вашими шифрами. Понаставят бракпоинтов и сдампят все в расшифрованном виде
Да. Вы правы. Надо дополнительно шифровать данные, чтобы в них при сломе результат менялся. Тогда дампить память тоже смысла не будет.
Здравствуйте, ononim, Вы писали:
B>>Спасибо за инфу. Я не прячу dll. Я использую немного иной подход. Я поставляю dll без кусков кода, а куски кода поставляются как ключи после оплаты. B>>Собственно сложность защиты можно наращивать до бесконечности, используя несколько алгоритмов шифрования и формирования ключей. Так как процесс шифровки можно автоматизировать, то B>>наличие в программе хотя бы 5 вариантов шифра, применяемых по определенному правилу к 500 разбросанным участкам кода — приведет к тому, что задача слома становиться бессмысленной для проги минимальной стоимости. O>Никто не будет ломать голову над вашими шифрами. Понаставят бракпоинтов и сдампят все в расшифрованном виде
Хорошего состояния памяти нет. Есть состояние отдельных участков кода. Дампить память 500 раз и сравнивать где хороший участок, где плохой — это только если сервер сбербанка надо сломать.
B>>>Собственно сложность защиты можно наращивать до бесконечности, используя несколько алгоритмов шифрования и формирования ключей. Так как процесс шифровки можно автоматизировать, то B>>>наличие в программе хотя бы 5 вариантов шифра, применяемых по определенному правилу к 500 разбросанным участкам кода — приведет к тому, что задача слома становиться бессмысленной для проги минимальной стоимости. O>>Никто не будет ломать голову над вашими шифрами. Понаставят бракпоинтов и сдампят все в расшифрованном виде B>Хорошего состояния памяти нет. Есть состояние отдельных участков кода. Дампить память 500 раз и сравнивать где хороший участок, где плохой — это только если сервер сбербанка надо сломать.
Дампить память 500 раз (каждые 10мсек например) — пишется за 15 минут. Сравнивать потом дампы и выявлять изменившиеся регионы — тоже ни разу не рокетсайнс.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Barm, Вы писали:
B>Я не верю в стандартные методики защиты, применяемые массово. Для них есть стандартные методики взлома.
Кустарный самопал тем более не остановит.
B>На мой взгляд как раз оптимальный вариант — шифрование участков кода своей программы. Тем более, это относительно простая задача.
Фиговый вариант. Шифрованные куски прекрасно вычисляются по стат.распределению. Дальше находится и вызывается их дешифровщик. Всех. Еще раз: ты сам всё расшифруешь взломщику. Он просто вежливо попросит твой самопал это сделать.
B>Всем спасибо за советы.
Здравствуйте, Barm, Вы писали:
B> Я не прячу dll. Я использую немного иной подход. Я поставляю dll без кусков кода, а куски кода поставляются как ключи после оплаты.
Поставляй их внутри аппаратного USB свистка. Причём наружу не отдавай. Только обмен данными. В свисток входные, из свистка только обсчитанный результат. Это единственный более-менее надёжный способ. И то сломают.
Здравствуйте, Barm, Вы писали:
B>Здравствуйте, bnk, Вы писали:
bnk>>Здравствуйте, Barm, Вы писали:
B>>>2. Может быть в настройках visual studio есть какие-то параметры, которые делают код процедур dll-ки неизменяющимся при загрузке в память?
bnk>>Попробуй выключить ASLR в настройках проекта. B>Уже пробовал. Не помогает.
bnk>>Но вообще, в тращициях данного форума, попинаю bnk>>IMHO, ерундой занимаетесь, если уж так нужно, просто возьмите готовый протектор.
B>Угу. Готовые протекторы имеют готовые методики взлома. B>Мне нужен протектор: B>1. Закачивающий ключи на клиента при оплате. B>2. Привязка ключей к железу клиента. B>3. Возможность простой перепривязки программы с одного рабочего места на другое (включая win64 и win32).
B>Программа планируется дешевой, трата ручного времени на привязку каждого клиента исключена. B>Максимум, что делается вручную — забивается e-mail клиента в базу данных "оплачено".
B>Денег априори на службу поддержки-установки нет. .
Это прекрасная идея, но сразу как только код будет расшифрован его можно просто сохранить из памяти в файл,
а после этого с ним работать.
Здравствуйте, Barm, Вы писали:
B>Как показали эксперименты при шифровке их трогать нельзя, а шифровать можно только данные на некотором расстоянии между изменяемыми байтами (в маске это нули).
Если всё так печально, то у тебя вероятно довольно слабая защита...
B>Я не верю в стандартные методики защиты, применяемые массово. Для них есть стандартные методики взлома.
Ломается всё, вопрос только трудозатрат. Можно поверить в то, что изучив всё что есть ты придумал что-то лучше. Но ИМХО, складывается впечатление, что ты не вникал в то что есть и наколхозил велосипед, который ломается ещё проще "стандартных методик". B>На мой взгляд как раз оптимальный вариант — шифрование участков кода своей программы. Тем более, это относительно простая задача. B>Если в программе зашифровать сотню процедур — задача слома программы становиться бессмысленной в случае, если цена программы не заоблачна.
Ключ шифрования, IDA и скрипт на питоне — работа на день. А если ещё и не "стандартный шифр", то вероятно даже ключ шифрования не нужен. B>Мне показалось, что иметь собственный протектор — более удобный подход, чем пользоваться сторонним.
Если твой протектор сопоставим со сторонним по качеству, то да. Нужно будет тратить время на его изучение и обход защит. Если это простое шифрование отдельных участков, то толку от такой защиты сильно меньше. B>Да, он более тупой, чем VMProtect, но чтобы его сломать, придется потратить время. А кому это нужно, если программа дешевая, а алгоритм шифровки неизвестен?
Твоя программа ведь расшифровывает же эти блоки кода? А значит алгоритм "шфировки" известен.
Короче есть мысль, что ты сильно заморачиваешся и тратишь много усилий на относительно простую защиту дешевой программы, когда можно за маленькие деньги с меньшими усилиями сделать более серьезную защиту навесным протектором. Они не панацея, но как раз для простых и дешевых программ тот же VMProtect даёт защиту со слишком большими трудозатратами на взлом.
)
