Проблемы демо

[JamS007]

Еще было бы неплохо сделать не одну такую проверку, а несколько и в разных местах программы. Например, перед выполнением большинства функций программы. Еще можно вызывать проверку по random’у, чтобы было сложней уловить закономерность.

 Тогда это точно увеличит головную боль взломщика, но и это не гарантирует, что программа не будет взломана.

[Waryable]

Дисасемблер отловит последний jump и злоумышлятель будет знать, где его отключают. А, вообще, насколько хорош потенциальный хакер?

[Igors]

Тогда это точно увеличит головную боль взломщика, но и это не гарантирует, что программа не будет взломана.

Согласен, это не "архитектурное" решение

Дисасемблер отловит последний jump и злоумышлятель будет знать, где его отключают. А, вообще, насколько хорош потенциальный хакер?

jump куда? Я читаю переменную в куче, а модифицирую не ее а что-то другое (чтобы завалить)
К сожалению, есть основания полагать что хакер весьма хорош 

[Waryable]

К сожалению, есть основания полагать что хакер весьма хорош 

В таком случае защиты на основе ключей малоэффективны. Надо ограничивать функционал демки радикально: убирать код(#if DEMO_VERSION...), или делать код заведомо ошибочным с явным указанием в инструкции к демке, что ошибка добавлена сознательно. Либо, если проект сложный, то это все решается на уровне Поддержки Производителя. Без наличия  либо исходников, либо Поддержки Производителя, ни один долгоиграющий проект не может быть эффективным. Естесственно, если это не реализация какого-либо жесткого алгоритма(черный ящик).

Кстати, защиты на основе времени наработки обходятся относительно легко. Лучше делать на основе количества каких-либо атомарных в алгоритме операций. Причем желательно сделать так, что бы это количество "дробило" вокруг некторого значения.

jump куда? Я читаю переменную в куче, а модифицирую не ее а что-то другое (чтобы завалить)

jump на функцию "заваливания" демки.

[Igors]

Надо ограничивать функционал демки радикально: убирать код(#if DEMO_VERSION...),

Это сложно и хлопотно. Многие пользователи прекрасно могут обойтись без отрезанных фичес. А "всех перерезать" - тоже не гуд, что тогда демонстрируем? Вариант "ограничить размер финального вывода" всем понятен и хорош, вот только как его чисто сделать?

или делать код заведомо ошибочным с явным указанием в инструкции к демке, что ошибка добавлена

Ну такая демка может и отпугнуть

jump на функцию "заваливания" демки.

Ф-цию? Зачем?? Не лучше ли втихаря напр. увеличить счетчик одного из контейнеров вдвое?

[Waryable]

Ф-цию? Зачем?? Не лучше ли втихаря напр. увеличить счетчик одного из контейнеров вдвое?

Ну как бэ... Я ведь не знаю что делает ваше приложение, но могу предположить, что удвоение счетчика должно либо сделать работу алгоритма ошибочной, либо замедлит его ну, вообще что-то из этого разряда. Чем это отличается от явно описанной ошибки?
И вцелом, мы сейчас обсуждаем безтолку. Т.к. лучшим вариантом было бы почитать хотя бы что нибудь типа "курс молодого крякера". Это позволит понять как они действуют и сообразить простецкую защиту. Ну а если подразумевается хороший крякер, то кроме как на внесение ошибки в код или ограничение функциональности расчитывать сложно. Защита от хорошего крякера - крякер чуть большей квалификации.
А с другой стороны: всетаки проект не расчитан на перспективу сотрудничества? Аутсорсинг?

[GreatSnake]

Могу предложить примитивный вариант защиты основанный на множественных таймерах.
Т.е. принятие решения о выходе делаем в одном таймере. Выход в другом. А между ними несколько промежуточных. Причём время везде разное.

[Igors]

Могу предложить примитивный вариант защиты основанный на множественных таймерах.
Т.е. принятие решения о выходе делаем в одном таймере. Выход в другом. А между ними несколько промежуточных. Причём время везде разное.

Если была попытка модификации - никаких "цивильных" выходов я обеспечивать не обязан, просто "завалить" как угодно

И вцелом, мы сейчас обсуждаем безтолку. Т.к. лучшим вариантом было бы почитать хотя бы что нибудь типа "курс молодого крякера". Это позволит понять как они действуют и сообразить простецкую защиту. Ну а если подразумевается хороший крякер, то кроме как на внесение ошибки в код или ограничение функциональности расчитывать сложно. Защита от хорошего крякера - крякер чуть большей квалификации.

Идеально было бы именно "ограничение ф-циональности" т.е. application просто "не умеет" делать выход больше заданного (как его ни модифицируй).

[brankovic]

Идеально было бы именно "ограничение ф-циональности" т.е. application просто "не умеет" делать выход больше заданного (как его ни модифицируй).

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

[Igors]

Если речь о перфекционизме, то я бы искуственно усложнил какую-нибудь формулу в вычислениях, чтобы она переполнялась для n>640.

Хорошо бы, но задача не состоит из какой-то одной чудесной формулы. Разные вычисления разбросаны в разных местах, практически всегда используется та или иная их часть