Порекомендуйте как ограничить работу проги 30 днями

В общем подорвался тут у шефа базу состряпать, типа деньгу грести за нее, с триальной версией на попробовать клиентуре всякой. Шеф хочет чтобы 30 дней отработала и пиндык, платите маню. Я посмеялся над этим про себя , но делать че-то надо, я как программер числюсь

Короче вот что подумалось, прога с базкой работает, т.е. пишет туда че-то время от времени, взаимодействует короче, мне думаца это гуд! Типа если защиту в реестр писать то потрут, в какой-нить файл тоже потрут или восстановят его, а если в саму базу, да еще как-нить вшифровывать в данные то хрен потрут. В общем приветствуются идеи как лучше это реализовать чтобы не сделать лажу в виде условного перехода где-нить. Кому какой алгоритм представляетца?

 

Pupa



А если мониторить обращения клиента ко всяким GetSystemTime и давать ей одну и ту же дату?

 

Ёпрст, можно таймер внутренний поставить или количество запусков считать

 

Pupa

по сабжу уже кучу идей напридумывали. просто нужно поискать.

 

Pupa

Ну так как ты тиминги считать-то будешь? Не rdtsc ведь в самом деле.

Hybernate поможет )

 

Hybernate? Шутник однако

 

А предлагаю с помощью прошлой даты запуска шифровать кусок кода. При запуске перешифровывать. Банальный xor тут пригодится. Если изменят - прога глюкнется.

Хотя от крякеров не спасёт.

 

Угу и кукаякнется на x86-64. Так тебе и дали писать в сегмент кода...

 

Хм, о чем это ты? В Windows XP 64 можно прекрасно писать куда угодно (если конечно сделать VirtualProtect). Единственное ограничение - проверка контрольных сумм ядра и системных драйверов в памяти, но она обходиться как нефиг делать.

 

Я прошу прощения. Переглючило меня. Перепутал с NX-битом и стеком. Совсем плохой стал

 

В любом случае, если известен ключ и алгоритм, то не составит труда подать дату на вход XOR-процедуре, а потом ее занопить. Можно вынести дату куда-нить в реестр, само собой, но и оттуда ее достать не сложнее.

 

Самый надежный способ - купить ключ и софтину под него. Сейчас много надежных ключей есть, самые последние еще не кракнуты! Если программа представляет коммерческий интерес, экономить деньги на защиту не стоит. Ключи дают разные варианты защиты, в том числе демо-вариант и ограниченная лицензия. Плюс к сказанному - добавь в код некоторых ответственных процедур параметры, зависящие от результатов проверки лицензии - если лицензия закончилась или нарушена, процедуры будут работать по неправильным веткам и в целом программа будет работать не совсем правильно (или совсем неправильно). Так было сделано в одной из версий 3DMax (точно не помню).

 

Ключи это круто...Программно хуже это да, с вызовам GetSystemTime и т.п. код проверки обламается за пару минут (меня так обламывали ГЫы ) лучше проверять кол-во запусков и считать не типа i++, а к примеру производить сложные ариф операции (*/) ну и не при загрузке, а в таймере с ложными вызовами и прочим запутыванием. И опять же сломают... но простой кодер это не сломает...

 

Ms Rem

гыгы ))) хм...молчу, молодца !

 

crypto

Кстати вот насчет этих параметров, которые будут работать криво если ключ не верный, допустим от ключа зависит имя вызываемой процедуры. Разве не просто получить работающий ключ, отследить какая именно нужная процедура вызывается и сделать патч чтобы код при проверке ключа сразу прыгал на нее? Чем история с 3DMax кончилась, который был защищен подобным образом, ломанули?

 

Pupa

Всем давно известно, что если есть ключ, то профессиональный кракер взлом произведет. Все зависит от степени запутанности, трюков всяких и др. фокусов, которые грамотный девелопер заготовит для взломщика. Мой опыт показывает, что все равно в часть капканов попадешься так или иначе. 3DMax конечно сломали, но первые версии были кракнуты некорректно (не все капканы были обезврежены).

Кстати, не всегда ключ доступен. Некоторые заказчики не могут вынести ключ с работы, потому что там это могут просечь. Другие боятся его передать, потому что ключ+программа стоят бешеных бабок и тогда приходится работать с сырым материалом без ключей.

У меня был заказ на отвязку ключа HARDLOCK от программы Project Expert. Ключа не было, программы были зашифрованы. Спасли ситуацию наличие демок, большой размер блока шифрованных данных и придуманные мною способы ограничения переборов 8-битовых вариантов ключей.

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

 

Извиняюсь, ошибочка вышла, конечно же не 8-битовых вариантов ключей, а 8-байтовых вариантов ключей

 

Если есть ключ, а программе его хэш, то максимум что крякер сделает это кряк, зато кейгена не будит

 

Если не сложно, покажите как выглядит 128 битный ключ?

 

Ситуация с HARDLOCK (с той версией, с которой я имел дело) такая: он хранит для каждых N байт программы 128-битный ключ и по определенному алгоритму (который можно изменить при зашифровании программы) расшифровывает очередные N байт зашифрованной рограммы. Таким образом, имеет место быть целый массив 128-битных ключей, каждый из которых надо опробовать.

Алгоритм расшифрования у меня был следующий: прежде всего я нашел блок дешифрования (до него добираться весьма долго через кучу капканов, но добраться можно); основная трудность заключалась в подборе первого ключа (), после это расшифровывался кусок кода и подбирался второй ключ по принципу либо продолжения полученного кода (получение осмысленной инструкции путем перебора вариантов), либо продолжения данных (получение осмысленных данных). И так далее. Работа муторная, прокатывало только на старых версиях ключа. Теперь и сами алгоритмы стали сложнее, и длина ключа увеличилась...