Самостоятельная реализация защиты
От: neiroman Украина  
Дата: 14.05.06 08:46
Оценка:
В связи с тем, что ASProtect в данный момент представляет для меня непозволительную роскош , встал вопрос о самостоятельной реализации защиты. Придумал такой вариант:
1. При установке инсталлятор создает файл в \Windows, где была бы указана (в защшифрованном виде) начальная и конечная дата триального периода.
2. При запуске прога ищет в Реестре рег.номер и проверяет на валидность. Если все ОК — продолжаем работу, если нет — ищем
ищем ключ в Реестре
если ключ есть — проверяем на валидность
если верен — запускаем прогу
если ключа нет либо он неверен
если триал кончился (смотрим по файлу) — не запускаем прогу
если триал не кончился — показываем наг-скрин и грузим прогу


Минуты
-возможность генерации серийника (хотя,думаю,если использовать ассиметричные системы, этого можно не боятся)
— возможность применения патча
-банальный откат времени

Вобщем, что посоветуете, чтобы зашиты защищала(извините за каламбур) ? И стоит ли сочинять действительно что-то серьезное ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Слова, пустые слова, подумал Стормгрен. Слова, за которые прежде люди дрались и умирали, но никогда больше не станут за них ни умирать, ни драться. И от этого мир станет лучше.
Re: Самостоятельная реализация защиты
От: Аноним  
Дата: 14.05.06 08:55
Оценка: 2 (2)
N>1. При установке инсталлятор создает файл в \Windows, где была бы указана (в защшифрованном виде) начальная и конечная дата триального периода.

используйте Native API для записи в реестр (покрайней мере регедитом не удалят)

N> -возможность генерации серийника (хотя,думаю,если использовать ассиметричные системы, этого можно не боятся)

Roman Pushkin давал exSU библиотеку в этом форуме

N> — возможность применения патча

Yoda's Protector

N> -банальный откат времени

храните время последнего запуска программы

N>Вобщем, что посоветуете, чтобы зашиты защищала(извините за каламбур) ? И стоит ли сочинять действительно что-то серьезное ?


я потратил два месяца (не каждый день писал) написал сносную защиту после чего купил EXEcrypt так как писать фактически два продукта (саой и защиту) надоело

при этом у меня были знания по криптографии и программировании на asm и я не чего не изучал только писал
Re: Самостоятельная реализация защиты
От: Kubyshev Andrey  
Дата: 14.05.06 09:10
Оценка: +2
Сделай нормальный софт и купишь зощиту если сочтешь нужным.
Не трать время.
Re[2]: Самостоятельная реализация защиты
От: neiroman Украина  
Дата: 14.05.06 09:56
Оценка:
В том то и дело, что программа УЖЕ есть.
На ASProtect денег нет.
Но защита нужна хоть какая-то .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Слова, пустые слова, подумал Стормгрен. Слова, за которые прежде люди дрались и умирали, но никогда больше не станут за них ни умирать, ни драться. И от этого мир станет лучше.
Re[3]: Самостоятельная реализация защиты
От: Kubyshev Andrey  
Дата: 14.05.06 10:01
Оценка:
N>В том то и дело, что программа УЖЕ есть.
N>На ASProtect денег нет.
N>Но защита нужна хоть какая-то .

Сделай простую проверочку, че тут думать. Сложить все буквы помножить на X вот и номерок.
На первых порах не помешает программке и на варезе посветиться.
Re[4]: Самостоятельная реализация защиты
От: Аноним  
Дата: 14.05.06 10:26
Оценка:
http://yodap.cjb.net/
http://zalexf.narod.ru/res/orien/index.html
бесплатные пакеры вы точно найдете если поищите
попросите авторы защит часто дают ключь на 1-2 месяца
Re: Самостоятельная реализация защиты
От: tarkil Россия http://5209.copi.ru/
Дата: 14.05.06 10:42
Оценка: 4 (2) +1
Здравствуйте, neiroman, Вы писали:

N>1. При установке инсталлятор создает файл в \Windows, где была бы указана (в защшифрованном виде) начальная и конечная дата триального периода.

N>2. При запуске прога ищет в Реестре рег.номер и проверяет на валидность. Если все ОК — продолжаем работу, если нет — ищем
N> ищем ключ в Реестре
N> если ключ есть — проверяем на валидность
N> если верен — запускаем прогу
N> если ключа нет либо он неверен
N> если триал кончился (смотрим по файлу) — не запускаем прогу
N> если триал не кончился — показываем наг-скрин и грузим прогу

N>Вобщем, что посоветуете, чтобы зашиты защищала(извините за каламбур) ? И стоит ли сочинять действительно что-то серьезное ?


Серьёзное дешевле окажется купить, по моему скромному мнению. Однако несложную самописную защиту примерно в предлагаемом объёме сделать вполне уместно.

1. Надо защититься хотя бы от метода взлома типа "меняем условный переход на безусловный" — когда все проверки крякер оставляет как есть, но заставляет игнорировать их результат. Выход — выполнять проверку многократно и по разному. В первый раз — втупую: if(checkSerNum()) { message(); return; } — для хороших юзеров, не ломающих программу. В последующие разы (когда крякер нейтрализует первую) надо как-нибудь изгаляться с результатом, скажем писать его в байты адресов статических структур данных или в адреса неких косвенно вызываемых функций (и получать access violation, если проверка не прошла). Тут надо чётко заботиться о том, чтоб не было единой точки кода, где получается готовый результат проверки. В частности — код функции checkSerNum() должен вызываться единственный раз, а для второй проверки в программе должна быть вторая копия этого кода, желательно по-другому написанная. Разумеется, вторая (третья, четвёртая) проверки должны работать не сразу при запуске, а попозже, при обращении к определённым функциям, например или просто по истечении таймаута.

Более надёжный выход — держать часть (важного) кода в зашифрованном виде, а дешифровать динамически при запуске софтинки с ключом = серийному номеру для регистрированного юзера. Но это уже сложно.

2. Класть свои данные в системный каталог не лучшая идея, ибо каталог этот — для ОС. Кроме того, начиная с XP есть контроль его целостности. К сожалению, не знаю, контролируется ли только подкаталог system32 или весь, но лучше не лезть. Ещё антивирусы какие-нибудь восстать могут... Нафиг-нафиг. Писать лучше в кошерное место хранения программных настроек — в файл в профиль юзера и параллельно те же данные в реестр, с:\windows ничем его не лучше. Их рассинхронизация — признак взлома. Ну и есть мелкий шанс, крякер может не додуматься мониторить и файловую систему и реестр разом.

3. Эффективный трюк — не отказываться запускать прогу в случае истечения триала (или фиксации взлома), а дать ещё три-четыре дополнительных запуска. Это неплохой метод для осложнения жизни крякеров, которые, выпустив патч и поломав им софтину, не будут толком тестировать работоспособность, а запустят раз-другой, убедятся, что экран с ошибкой не появился и успокоятся.

4. Для противодействия откату времени надо куда-то при установке сохранять текущее время, а потом перекрывать его текущим временем при каждом запуске (уже после прохождения проверок защиты). И если вдруг время запуска окажется меньше, чем сохранённое время или меньше, чем прошитая в программе дата билда, вести себя как при истечении триального срока.

Все перечисленные меры, конечно, давно известны и не дают никаких гарантий. Но хоть самые ламеры из крякеров отвалятся.
--
wbr, Peter Taran
Re: Самостоятельная реализация защиты
От: Relayer http://www.strongbit.com
Дата: 14.05.06 13:43
Оценка: 14 (3)
Здравствуйте, neiroman, Вы писали:

N>Вобщем, что посоветуете, чтобы зашиты защищала(извините за каламбур) ?


можешь реализовать старую идею с разнесенными проверками. суть вот в чем — есть система линейных уравнений. скажем 30 переменных — 20 уравнений. система недоопределенная — решение не единственно. решение — есть серийник. в программу прошиваешь проверки. причем не все 20. а скажем для каждого билда рандомную выборку в 15 уравнений из 20ти. эелементарная проверка — проверка одного уравнения. разбрасываешь проверки по коду своей программы. некоторые вызываешь при определенном стечении обстоятельств. например по четным дням
крякер посмотрит где серийник проверяется. пропачит. и успокоится. а завтра оно вызовет еще одну проверку. и работать не будет
предположим что крякер найдет все проверки и сделает кейген. но в след билде мы будем использовать другую выборку из наших 20ти уравнений и кейген работать не будет.
вобщем просто и со вкусом. реализовать можно достаточно быстро.

можно еще более навернуть эту схему. пусть s1..n — это цифры серийника, a1..n — коэффициенты некоторого уравнения. вместо того чтобы проверять s1*a1+s2*a2+...+sn*an == b поступим хитрее посчитаем левую часть. возьмем от него какойто хеш. ну например тот же sha-1 или md4. и результат сравним с некоторой константой прошитой в программе. если он совпал — проверка пройдена и следовательно может выполняться некоторый код который недоступен в триальной версии. так вот в этом коде в качестве констант при обращении к апи или в качестве границ для счетчика цикла мы будем использовать b mod Ki. b нам известно заранее. константы Ki мы тоже можем рассчитать так чтобы остаток от деления нашего b на эти константы был равен тому что нам надо.
как следствие тут уже пачить jz на jmp не получится — программа будет валится. прийдется скардить как минимум один ключ и выковырять эти самые b.
Re[2]: Самостоятельная реализация защиты
От: Аноним  
Дата: 14.05.06 15:49
Оценка:
Здравствуйте, tarkil, Вы писали:

T>В последующие разы (когда крякер нейтрализует первую) надо как-нибудь изгаляться с результатом, скажем писать его в байты адресов статических структур данных или в адреса неких косвенно вызываемых функций (и получать access violation, если проверка не прошла).

T>Более надёжный выход — держать часть (важного) кода в зашифрованном виде, а дешифровать динамически при запуске софтинки с ключом = серийному номеру для регистрированного юзера. Но это уже сложно.

Можно ещё использовать запутывание исполняемого кода. Разбросать микрофункции по телу программы. Одни из этих микрофункций представляют собой важные участки кода, а другие — наоборот, мусор. Вызов микрофункций осуществляется через единую процедуру поиска по таблице указателей. А последовательность вызова функций из таблицы указателей привязать к цифрам серийного номера. Таким образом, если крякер попытается заменить флажок регистрации, то выполнение программы будет происходить по ложному пути c ошибками. Распутать такой ребус можно с помощью SERIAL (потому что иначе код якобы полной версии программы будет исполняться некорректно). Чтобы сломать брутально в лоб — нужно перелопатить очень много листов кода и разобраться на ассемблере как программа работает.

Если преступник украл сериал, то вместо того чтобы наступать на грабли делая блэк-лист (подарок для кракера) с выходом новых версий можно поменять систему, создав другие блоки микрофункций. Изменения вычислить крякеру будет непросто, т.к. блоки могут быть произвольными, а их размеры и изменения в программе могут быть разными.

Единственный минус такого подхода — нужно обязательно делать ограничение _функциональности_ триальной версии. Т.е. участок кода демо версии должен быть независимым от участка кода рабочей версии.
Re[5]: Самостоятельная реализация защиты
От: Relayer http://www.strongbit.com
Дата: 14.05.06 15:57
Оценка:
Здравствуйте, Аноним, Вы писали:

А>http://yodap.cjb.net/

А>http://zalexf.narod.ru/res/orien/index.html
А>бесплатные пакеры вы точно найдете если поищите

бесплатный сыр в мышеловке как известно. эти бесплатные пакеры а) никого не остановят б) добавят головной боли автору т.к. большинство антивирусов детектят их как малварь не разбираясь что там внутри.
так что если хочется запаковать чемто — только упх. а чтоб руками не лазали — простенькие проверочки что программа распакована (хинт: размер файла, сигнатуры и тп)
Re[2]: Самостоятельная реализация защиты
От: Аноним  
Дата: 14.05.06 16:13
Оценка:
Здравствуйте, Relayer, Вы писали:

R>Здравствуйте, neiroman, Вы писали:


R>можно еще более навернуть эту схему. пусть s1..n — это цифры серийника, a1..n — коэффициенты некоторого уравнения. вместо того чтобы проверять s1*a1+s2*a2+...+sn*an == b поступим хитрее посчитаем левую часть. возьмем от него какойто хеш. ну например тот же sha-1 или md4. и результат сравним с некоторой константой прошитой в программе. если он совпал — проверка пройдена и следовательно может выполняться некоторый код который недоступен в триальной версии. так вот в этом коде в качестве констант при обращении к апи или в качестве границ для счетчика цикла мы будем использовать b mod Ki. b нам известно заранее. константы Ki мы тоже можем рассчитать так чтобы остаток от деления нашего b на эти константы был равен тому что нам надо.

R>как следствие тут уже пачить jz на jmp не получится — программа будет валится. прийдется скардить как минимум один ключ и выковырять эти самые b.

Угу. А вообще защита от кейгена независима от защиты от крэка.

От кейгена действительно помогает хэш. Первый хэш генерируется по имени, второй — по введенному серийнику. Если не совпадают — unregistered. Процедуру вычисления хэша наворотить так чтобы занимала по-больше процессорного времени (чтобы не было возможности перебора).

От крэка — нужно или запутывать или хитро шифровать код по функции второй части серийника.
Re[3]: Самостоятельная реализация защиты
От: Doc Россия http://andrey.moveax.ru
Дата: 14.05.06 16:23
Оценка:
Здравствуйте, neiroman, Вы писали:

N>В том то и дело, что программа УЖЕ есть.

N>На ASProtect денег нет.
N>Но защита нужна хоть какая-то .

Если речь именно о защите, то сделай самую простую.

И потом, сколько стоит программа? $14.95?
Продашь 5-10 копий и будут деньги на покупную защиту.
После ее подставишь и вышлешь новые ключи свои юзерам. Для 10 человек это не проблема.

Если жаба душит в плане вареза — выкини из первой версии пару функций (вообще код убери), а после выпустишь версию с ними.
Re[3]: Самостоятельная реализация защиты
От: Alex Mova  
Дата: 14.05.06 17:50
Оценка: 1 (1) +1
Здравствуйте, neiroman, Вы писали:

N>В том то и дело, что программа УЖЕ есть.

N>На ASProtect денег нет.
N>Но защита нужна хоть какая-то .
Вместо триала сделай демо с ограничением функций и нагскрином, после покупки давай скачать полную версию.
WBR, Александр Мова
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.