Необходимо что бы программа отработала на компьютере не более 30 дней.
Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
Вопросы
— как замерять (есть задумка с интернет синхронизацией)
— где и как лучше хранить дату начала использования программы?

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
Не пробовал.
SSS>- где и как лучше хранить дату начала использования программы?
Писал в несколько мест в реестр в шифрованном виде.

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?

С интернет синхронизацией набо быть поосторожнее, если твоя прога не сетевая!
Юзер может просо испугаться, когда файрвол закричит, что прога лезет в интернет,
И скажут потом, что spy-ware!

Здравствуйте, Аноним, Вы писали:

А>Писал в несколько мест в реестр в шифрованном виде.

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

Допустим, Ю* запустил игру 5 числа месяца. Если он переводит после этого дату на 4-е число, то игра не запускается. Если он переводит дату на 5+триал_дни+1, то игра не запускается. Если же игра запустилась 6-го числа, то начало периода сместилось на 6-е число и триал_дни уменьшились на 1. Таким образом, если Ю запустит теперь игру 5-го числа, то она не будет работать, т.к. интервал уже сместился. И так каждый день допустимый временной интервал уменьшается.

--5*****11--
---6****11--
------9*11--

Ю* — (от англ. user) пользователь.

Всегда остается возможность вычистить реестр и установить пр-му поновой.

Здравствуйте, Аноним, Вы писали:

А>Всегда остается возможность вычистить реестр и установить пр-му поновой.

Не мешало бы в программе шифровать названия ключей реестра — что бы было не понятно куда пишешь.

Вообще, ключи реестра очень легко найти в дизассемблере — я так не раз делал.

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?

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

Кстати, совет. Сделай дополнительный поток при чтении данных из реестра. Будет неприятно соображать потом дизассемблере что да как (по крайней мере мне было бы).

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

FDS>Не мешало бы в программе шифровать названия ключей реестра — что бы было не понятно куда пишешь.

Непонятно будет только в блокноте, а в RegMon'е всё будет как прежде.

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.

Я использую простейший вариант:
— прога записывает в реестре дату первого запуска для отсчета trial-a (юзер это может отследить)
— если trial кончается (а юзер уже уверен что знает где лежит дата и вряд ли проверяет реестр постоянно) прога записывает бинарный ключ "триал закончен" в совершенно другую ветку реестра. Так что даже юзер сотрет первый найденный им ключ, программа всё равно работать не будет.

Делать что-то более сложное ИМХО смысла мало — юзер, которому не лень постоянно возиться с мониторами реестра, покупать прогу всё равно не будет.

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

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

SSS>>Необходимо что бы программа отработала на компьютере не более 30 дней.

DE>Я использую простейший вариант:
DE>- прога записывает в реестре дату первого запуска для отсчета trial-a (юзер это может отследить)
DE>- если trial кончается (а юзер уже уверен что знает где лежит дата и вряд ли проверяет реестр постоянно) прога записывает бинарный ключ "триал закончен" в совершенно другую ветку реестра. Так что даже юзер сотрет первый найденный им ключ, программа всё равно работать не будет.

Надо только записывать тогда не только в конце, а несколько раз. Что бы если пользователь удалил ключ раньше истечения срока — вторая запись всё равно осталась.

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

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

FDS>>Не мешало бы в программе шифровать названия ключей реестра — что бы было не понятно куда пишешь.

MNZ>Непонятно будет только в блокноте, а в RegMon'е всё будет как прежде.

Не понял, причём тут блокнот? Я говорю про дизассеблирование кода.

DE>Делать что-то более сложное ИМХО смысла мало — юзер, которому не лень постоянно возиться с мониторами реестра, покупать прогу всё равно не будет.

Незря же народная мудрость гласит: ...что замки делают от честных людей!

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

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

SSS>>Необходимо что бы программа отработала на компьютере не более 30 дней.

DE>Я использую простейший вариант:
DE>- прога записывает в реестре дату первого запуска для отсчета trial-a (юзер это может отследить)
DE>- если trial кончается (а юзер уже уверен что знает где лежит дата и вряд ли проверяет реестр постоянно) прога записывает бинарный ключ "триал закончен" в совершенно другую ветку реестра. Так что даже юзер сотрет первый найденный им ключ, программа всё равно работать не будет.

DE>Делать что-то более сложное ИМХО смысла мало — юзер, которому не лень постоянно возиться с мониторами реестра, покупать прогу всё равно не будет.
Ну, это как сказать. А если спортивный интерес. Я например в дизассемблере всё делаю.

Кстати. Всё равно есть ли запись по окончании срока или нет, если она проверяется примерно там же, где и запись о начале использования. Её будет очень легко найти в дизассеблере.

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

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

Точнее взломает, но не ключ в реестре, а уже саму блокировку программы.

Здравствуйте, FDSC, Вы писали:
FDS>По моему лучше делать контроль числа запусков или времени работы в программе. Пользователю приятнее и самому удобнее.
Тут такая ситуация что заказчик может ее не выключать более после первого запуска.
Я думал но тогда 30 запусков могут проходить больше года

FDS>Кстати, совет. Сделай дополнительный поток при чтении данных из реестра. Будет неприятно соображать потом дизассемблере что да как (по крайней мере мне было бы).
Хорошая идея.

Здравствуйте, DivMind, Вы писали:
DM>С интернет синхронизацией набо быть поосторожнее, если твоя прога не сетевая!
DM>Юзер может просо испугаться, когда файрвол закричит, что прога лезет в интернет,
DM>И скажут потом, что spy-ware!
Нет с заказчиком вроде поговорили — он готов "проверяться" через интернет..

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?
Забыл добавить...программа 16 битная. Пишу на MSVC v1.5
О реестрах можно только мечтать — только ini файлы...

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

DE>>Делать что-то более сложное ИМХО смысла мало — юзер, которому не лень постоянно возиться с мониторами реестра, покупать прогу всё равно не будет.

FDS>Ну, это как сказать. А если спортивный интерес. Я например в дизассемблере всё делаю.
FDS>И ещё, нужно, что бы был ключ, считывался где-нибудь в программе (только не при запуске!), затем полезные данные из него используются, а время проверяется в совершенно другом месте — умучаешься находить где, домашний пользователь уже вряд ли взломает.
FDS>Точнее взломает, но не ключ в реестре, а уже саму блокировку программы.

"Домашний пользователь", который дизассемблером ломает программы — это точно не моя целевая аудитория

А на навороченную защиту время тратить просто лень, т.к. в материальном плане оно себя вряд ли окупит.

PS: Кстати, ещё раз напомню про огромную популярность (и приличные доходы) Windows Commander — который фактически вообще не имеет никакой защиты.

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

FDS>Не понял, причём тут блокнот? Я говорю про дизассеблирование кода.

Так в том и смысл. Константные строки в программе можно посмотреть, открыв исполняемый файл в том же блокноте. Шифрование приведёт к тому, что сделать это будет невозможно, но не более того. В реестр-то всё записывается в прежнем, расшифрованном виде. Я имею в виду, имена веток реестра в функции API передаются расшифрованными. Более того, сам факт записи в реестр по прежнему присутствует. А такие утилиты как RegMon позволяют проследить, какие ветки реестра открывало, читало, изменяло, записывало и удаляло приложение. И хоть зашифруйся. Теперь понятней?

А нельзя писать в себя? В exe файл? с MZ заголовком?
Была бы отличная система опрделения первого запуска..
Хотя если конечно сам ехе-шник тоже юзер не поменяет...

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

SSS>Забыл добавить...программа 16 битная. Пишу на MSVC v1.5
SSS>О реестрах можно только мечтать — только ini файлы...

Простите, а какой у вас там сейчас год?

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

SSS>А нельзя писать в себя? В exe файл? с MZ заголовком?

Первый же антивирусник назовёт такой софт неизвестным науке мегавирусотрояночервём, замигает всеми красными лампочками, завоет всеми сиренами, и вот тут-то репутация софта и накроется медным тазом раз и навсегда...

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



MNZ>Теперь понятней?

Это и так понятно.
Немножно ерунду наверное я сказал.

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

SSS>Здравствуйте, FDSC, Вы писали:
FDS>>По моему лучше делать контроль числа запусков или времени работы в программе. Пользователю приятнее и самому удобнее.
SSS>Тут такая ситуация что заказчик может ее не выключать более после первого запуска.
SSS>Я думал но тогда 30 запусков могут проходить больше года

Дак попробуй считать время работы программы! Впрочем, не знаю, стоит ли — получается, что 30-дневная копия, что время работы программы — одно и тоже.
Между прочим над этим ещё подумать надо.

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

SSS>А нельзя писать в себя? В exe файл? с MZ заголовком?
SSS>Была бы отличная система опрделения первого запуска..
SSS>Хотя если конечно сам ехе-шник тоже юзер не поменяет...

Вся проблема в том, куда можно записать файл так, что бы пользователь его не мог стереть.
Что-нибудь вроде этого подойдёт C:\Windows\System32\SuDrv.vxd ?

С антивирусами проблемы особой, наверное, не будет. Но exe файл явно находится в той же директории, что и он сам — стереть директорию и всё.

"FDSC" <42583@users.rsdn.ru> wrote in message news:1250053@news.rsdn.ru...
> Здравствуйте, SSSerg, Вы писали:
> Вся проблема в том, куда можно записать файл так, что бы пользователь его не мог стереть.
> Что-нибудь вроде этого подойдёт C:\Windows\System32\SuDrv.vxd ?

Есть еще интересный метод (только для NT+ и програм запускаемых как сервис). Создается в реестре ключ с правами NO ACCESS и владельцем ключа делается пользователь SYSTEM. Такой ключ нельзя удалить обычным регедитом. Хотя от продвинутых юзеров это увы не поможет.

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

>> Здравствуйте, SSSerg, Вы писали:
>> Вся проблема в том, куда можно записать файл так, что бы пользователь его не мог стереть.
>> Что-нибудь вроде этого подойдёт C:\Windows\System32\SuDrv.vxd ?

W>Есть еще интересный метод (только для NT+ и програм запускаемых как сервис). Создается в реестре ключ с правами NO ACCESS и владельцем ключа делается пользователь SYSTEM. Такой ключ нельзя удалить обычным регедитом. Хотя от продвинутых юзеров это увы не поможет.

Тут ка раз обсуждаем, как без реестра обойтись.

я думаю просто демки делать, которые будут работать до определенного срока.
К примеру юзер скачал демку, а она работает до 1 сентября 2005. Если он поставит ее 29 августа, то и работать будет 2 дня

"devic" <37574@users.rsdn.ru> wrote in message news:1250280@news.rsdn.ru...
> я думаю просто демки делать, которые будут работать до определенного срока.
> К примеру юзер скачал демку, а она работает до 1 сентября 2005. Если он поставит ее 29 августа, то и работать будет 2 дня

Это отламывется не сложнее, достаточно найти вызов GetSystem(Local)Time и дело в шляпе, программа будет вечная.

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?


Самый, на мой взглад, безопасный способ хранения — выдавать тридцати дневные ключи лицензии с твоего Интернет сервера (если у тебя есть такая возможность). На сервере можно генерировать ключ, например, такого содержания (в форме ini):

[key]
Created=2005-06-30 (17:41) UTC
Expires=2006-07-29 (17:41) UTC

[Signature]
Value=F63818C832FD730AD9794F13B8C26F53811DB1C85B5300F1BBA7B06B1A0C0B1F15E6394F985B

Где Value раздела Signature будет цифровой подписью, созданной с помощью закрытого ключа, хранящегося на сервере, к параметрам Created и Expires. В программе останется проверить верность подписи с помощью открытого ключа.

Все это несколько надежней чем реестр, откуда данные можно легко удалить (в нашей ситуации прога не запустится без ключа). Правда придется внедрять криптографию; нужно позаботиться о том, чтобы никто не мог подменить открытый ключ (для этого его можно сохранить в исполняемый файл, и при запуске файла проверять его целостность чем-нибудь вроде CSR32, MD5 или SHA1). Закрытый ключ на сервере нужно защитить от воровства, да и к тому же от проверок перевода часов тебя это тоже не освободит, зато таким образом можно легко создать систему выдачи лицензий, как триал, так и целостных. В общем, решать тебе ибо это очень трудоемкая работа, но по-моему она стоит того. А идея с реестром очень бональна и к тому же его легко отследть с помощью программ типа RegMon.

PS
Если есть деньги (около 100 вечно зеленых) покупай ASProtect (http://www.aspack.com/ может и ру — не помню) и не парься: в этой программе есть все (она использует механизмы, подобные описанным выше). Защиту обеспечит надежную.


PPS
Горькой правдой будней остается то, что прогу скорее всего всеравно поломают — главное чтобы не каждый дилетант и середнечек в области крякинга смог это сделать.

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

W>"devic" <37574@users.rsdn.ru> wrote in message news:1250280@news.rsdn.ru...
>> я думаю просто демки делать, которые будут работать до определенного срока.
>> К примеру юзер скачал демку, а она работает до 1 сентября 2005. Если он поставит ее 29 августа, то и работать будет 2 дня

W>Это отламывется не сложнее, достаточно найти вызов GetSystem(Local)Time и дело в шляпе, программа будет вечная.

а вот и нет

1. Можно не только вызов делать, а к примеру смотреть дату какого нибудь файла.
2. Смотреть с разных мест по определенным событиям. Юзер отркыл, закрыл, написал, нажал и т.д.

ну а самое главное, демка на то и демка, в ней нету каких-нибудь важных операций.
Не типа ЕСЛИ РЕГАНА ТОГДА ИНАЧЕ, а кода нету там вообще. Ломать нечего


Так, что мое мнение это самый лучший вариант.

"devic" <37574@users.rsdn.ru> wrote in message news:1250425@news.rsdn.ru...
> 1. Можно не только вызов делать, а к примеру смотреть дату какого нибудь файла.

Ага, у меня вот тут как раз файл лежит, создан в 2010 году

> 2. Смотреть с разных мест по определенным событиям. Юзер отркыл, закрыл, написал, нажал и т.д.
> ну а самое главное, демка на то и демка, в ней нету каких-нибудь важных операций.

Тоже вариант (и тоже ненадежный .

W>Ага, у меня вот тут как раз файл лежит, создан в 2010 году

а я этот файл трогать не буду Ну а если юзер ради моей демки, в которой ограничены возможности, готов менять дату на файлы, то пусть пользуется
А еще можно несколько файлов анализировать на дату

W>Тоже вариант (и тоже ненадежный .

Надежнее я не вижу, поэтому так я и собираюсь делать для себя, чего советую и автору топика.

wellwell пишет:
> Есть еще интересный метод (только для NT+ и програм запускаемых как
сервис). Создается в реестре ключ с правами NO ACCESS и владельцем ключа
делается пользователь SYSTEM. Такой ключ нельзя удалить обычным
регедитом. Хотя от продвинутых юзеров это увы не поможет.

at <время_запуска> /interactive regedt32.exe

и все...

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..

а ты подумай над Windows и WinAPI. там есть такая уйма мест где можно глянуть время а дальше все просто — чтото с чемто не совпало — GPF или молча закрываемся.
с интернетом связываться не рекомендую ... фаерволы и тп.

with best protection
Andre Belokon
http://www.strongbit.com

Здравствуйте, <Аноним>, Вы писали:

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

SSS>>Забыл добавить...программа 16 битная. Пишу на MSVC v1.5
SSS>>О реестрах можно только мечтать — только ini файлы...

А>Простите, а какой у вас там сейчас год?

Год то наш.. просто проект староват..

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?

Я сделал так.
1) Отвязался от системного времени. — использую интернет сервера..
2) При первом (надеюсь первом ) запуске прога создает файлик DLL в SYSTEM
Туда пишется всякая отвлекаюшая информация из заголовка обычной dll.В середине
пишется шифрованная дата начала запуска.
3) При запуске программа сравнивает текущее интернет время с начальным.
Минус в том что если юзер просечет файл...

MNZ>Так в том и смысл. Константные строки в программе можно посмотреть, открыв исполняемый файл в том же блокноте. Шифрование приведёт к тому, что сделать это будет невозможно, но не более того. В реестр-то всё записывается в прежнем, расшифрованном виде. Я имею в виду, имена веток реестра в функции API передаются расшифрованными. Более того, сам факт записи в реестр по прежнему присутствует. А такие утилиты как RegMon позволяют проследить, какие ветки реестра открывало, читало, изменяло, записывало и удаляло приложение. И хоть зашифруйся. Теперь понятней?

можно же писать не в одну а в несколько сотен. Чисто чтобы ручками было это трудно сделать. причем как в свои сознаыые так и в существующие.

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

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

SSS>>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>>Вопросы
SSS>>- как замерять (есть задумка с интернет синхронизацией)
SSS>>- где и как лучше хранить дату начала использования программы?
..........

SSS>Минус в том что если юзер просечет файл...

FileMon, можно просто IDA....
....упаковщик нужен все равно, или хотя бы самомодифицирующийся код для всех сохранений и проверок, так что бы выполнялись 5-10 ASM комманд, и тут же стирались (если 1 проверка при запуске) или упаковывались обратно.
Делать придется в три этапа:

1. Макросики на C, что т вроде:

#define START asm { \
jmp $+6}\
__emmit__ {0x01,0x02,0x03,0x04,0x05,0x06} — это вроде как сигнатура + место для твоего кода мутанта
+ 2й define для пометки конца

2. Планируем мутируемый код так, чтобы всяких goto и return из него не было, иначе пары начало/конец завалишь.

3. Делаем внешний доп. ехе, который просканить твою прогу компильнутую на предмет сигнатур и там первоначально замутирует чистый код, вырежет JMP.

...да, не знаю как под Вынь-16, а под Вынь-32 на сегмент кода этого нада еще разрешение на запись толи ручками exe выставь, то-ли VirtualProtect вызывай...
....это конечно не подробное руководство, но думаю обрисовал примерно, желательно блоков таких поболее и покороче...
...хотя снова же не совершенно это, IDA давно их ловит, потому что все простое и эффективное есть в коммерческих пакерах...

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?

Мысль пришла...
Как бороться будете, если у меня всегда есть чистая винда под VMWare и в любой момент я смогу ваш триал установить заново и юзать?

Здравствуйте, Колян, Вы писали:

К>Мысль пришла...
К>Как бороться будете, если у меня всегда есть чистая винда под VMWare и в любой момент я смогу ваш триал установить заново и юзать?

с такими как Вы бороться бесполезно

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?

синхронизация времени по интернет не пойдет — на пример у юзера стоит фаервол, который тут же ругнется при попытке твоей проги полезть куда то в интернет — фаервол просто не даст тебе шансу вылезти в Инет.

Лучше всего сделать так:

Создать служебный файл — подписать его цифровой подписью для соблюдения целостности, в файле храниться timestamp в формате GMT времени активации и период в течении которого можно использовать твою прогу (в сутках).

При запуске проги проверяй текущую дату по дате создания файла подкачки Windows на пример (Windows не позволит сменить тебе timestamp это файла.

Канечно твоя защита будет легко ломаться на операторе сравнения дат...

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>Варианты с проверкой системного времени — отпадают в силу легкого его иземенения..
SSS>Вопросы
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?

Попробуй такой программный продукт как ExeCryptor,
триальную версию скачать можно из адреса http://www.strongbit.com.

Здравствуйте, Колян, Вы писали:

К>Мысль пришла...
К>Как бороться будете, если у меня всегда есть чистая винда под VMWare и в любой момент я смогу ваш триал установить заново и юзать?

Есть класс прог, по опеределению бесполезный для запуска на VMWare.
Это различные regisrty cleaners и подобное, мониторы сотояния операционной системы
и диагностические утилиты.

Попробуй создание ключей спец длины в реестре с помощью NtCreateKey(находится в ntdll.dll).
Это недокументированное API и думаю, ты его сможешь исспользовать в своей системе.
Защита всего кода броней от хака тоже не будет лишним.

"Hanike" <44059@users.rsdn.ru> wrote in message news:1335218@news.rsdn.ru...
> Попробуй создание ключей спец длины в реестре с помощью NtCreateKey(находится в ntdll.dll).
> Это недокументированное API и думаю, ты его сможешь исспользовать в своей системе.
> Защита всего кода броней от хака тоже не будет лишним.

Это все бессмысленно. Если вашу защиту нельзя сломать, ее будут кардить. Только и всего. Самое главное, нельзя допускать кейгенов, насчет остального, я бы не беспокоился особо. Вот пример IDA (прога такая), сломать практически невозможно (ясень пень, ее такие спецы писали), зато лежит кругом с украденным ключиком.

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

>> Защита всего кода броней от хака тоже не будет лишним.
W>Это все бессмысленно. Если вашу защиту нельзя сломать, ее будут кардить. Только и всего.

ПОЛНОСТЬЮ согласен.
мне кажется юзеры делятся на три части:
1) те кто готовы купить законно если программа им нужна
2) те кто не готов купить ни при каких условиях
3) те кто пока колеблется по каким-либо причинам

С первыми все понятно. Они не будут искать в edonkey пиратскую версию, и лазить по сайтам 0daywarez, они просто не умеют или не хотят.

Со вторыми тоже все понятно. Если программу невозможно взломать, и они не найдут крякнутую версию — они будут пользоватся конкурентом.

Что касается третьих — их надо мягко подталкивать к покупке. Например, доходчиво написать на сайте, что зарегистрированный поль-ль имеет саппорт 24/7, имеет право бесплатного апгрейда версий и тд. Это самая малочисленная группа из трех, и подталкивать ее к покупке супер-защитой нерентабельно, к тому же можно и отпугнуть.

W> Самое главное, нельзя допускать кейгенов.

Легко сказать...

"jit" <42966@users.rsdn.ru> wrote in message news:1335796@news.rsdn.ru...
> W> Самое главное, нельзя допускать кейгенов.
> Легко сказать...

И легко сделать Благо реализаций ассиметричных алгоритмов сейчас доступно до кучи (тот же RSA или El-Gamal), основная суть там что шифруются данные одним ключом (private), а расшифровываются другим (public), при этом один из другого вычислить невозможно, что доказано математически.

wellwell wrote:
>> W> Самое главное, нельзя допускать кейгенов.
>> Легко сказать...
>
> И легко сделать Благо реализаций ассиметричных алгоритмов сейчас
> доступно до кучи (тот же RSA или El-Gamal), основная суть там что
> шифруются данные одним ключом (private), а расшифровываются другим
> (public), при этом один из другого вычислить невозможно, что доказано
> математически.

Можно, но пока очень дорого.. Но, кстати, всё (про сложность и
дороговизну) доказано на нескольких предположениях, про которые
неизвестно почти ничего. Оно, правда, не важно — пока средство ломать не
изобрели.. Если изобретут — получат медаль имени Филдса (или нож в бок?).

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

W>Это все бессмысленно. Если вашу защиту нельзя сломать, ее будут кардить. Только и всего. Самое главное, нельзя допускать кейгенов, насчет остального, я бы не беспокоился особо. Вот пример IDA (прога такая), сломать практически невозможно (ясень пень, ее такие спецы писали), зато лежит кругом с украденным ключиком.

Ребята, вы меня не поняли. Я имел ввиду технологию создания записей в реестре(запись в реестре производят в KEY, т.е. в ключ). Запись создаётся таким образом, что прочитать или изменить её может только ВАШ код, а его от реинжиниринга следует покрывать защитной оболочкой: их сейчас много и самые авторитетные(имхо, may be) — aladdin и guardant(я исспользую аппаратную защиту aladdin hasp 5, но у меня firmware и клиенты только корпоративные).
Главное здесь избежать изменение кода кракером, а метод хронения даты может быть любой: мой или предложенные выше.
Прикрутить в 16-б проект такой код я думаю не сложно.

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

jit>мне кажется юзеры делятся на три части:
jit>1) те кто готовы купить законно если программа им нужна
jit>2) те кто не готов купить ни при каких условиях
jit>3) те кто пока колеблется по каким-либо причинам

Я бы еще добавил:
4) те, кто согласны купить, но из-за сложностей с оплатой им проще найти кряк

Здравствуйте, Сергей, Вы писали:

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

jit>>мне кажется юзеры делятся на три части:
jit>>1) те кто готовы купить законно если программа им нужна
jit>>2) те кто не готов купить ни при каких условиях
jit>>3) те кто пока колеблется по каким-либо причинам

С>Я бы еще добавил:
С>4) те, кто согласны купить, но из-за сложностей с оплатой им проще найти кряк
На самом деле большинство (4) есть ни кто иные, как (2).

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

>> W> Самое главное, нельзя допускать кейгенов.
>> Легко сказать...

W>И легко сделать Благо реализаций ассиметричных алгоритмов сейчас доступно до кучи (тот же RSA или El-Gamal), основная суть там что шифруются данные одним ключом (private), а расшифровываются другим (public), при этом один из другого вычислить невозможно, что доказано математически.

Да я в курсе, всетки мехмат закончил ... Да, один из другого не вычислишь.

Вот только вся проблема в том, что для ДЕкриптования совсем и не обязательно знать личный ключ. В каждом алгоритме свои слабости. Например побайтовые алгоритмы хачатся построением таблицы соовтетствия. И вообще никаких ключе не надо, ни публичных ни приватных.

jit>>>мне кажется юзеры делятся на три части:
jit>>>1) те кто готовы купить законно если программа им нужна
jit>>>2) те кто не готов купить ни при каких условиях
jit>>>3) те кто пока колеблется по каким-либо причинам

С>>Я бы еще добавил:
С>>4) те, кто согласны купить, но из-за сложностей с оплатой им проще найти кряк
L>На самом деле большинство (4) есть ни кто иные, как (2).

Это только так кажется. Я вот, например, хочу купить ASProtect
версии 2. Карточки visa у меня нет. На доступном мне softkey
есть только первая.

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

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

>>> W> Самое главное, нельзя допускать кейгенов.
>>> Легко сказать...

W>>И легко сделать Благо реализаций ассиметричных алгоритмов сейчас доступно до кучи (тот же RSA или El-Gamal), основная суть там что шифруются данные одним ключом (private), а расшифровываются другим (public), при этом один из другого вычислить невозможно, что доказано математически.

jit>Да я в курсе, всетки мехмат закончил ... Да, один из другого не вычислишь.

jit>Вот только вся проблема в том, что для ДЕкриптования совсем и не обязательно знать личный ключ. В каждом алгоритме свои слабости. Например побайтовые алгоритмы хачатся построением таблицы соовтетствия. И вообще никаких ключе не надо, ни публичных ни приватных.

Ассиметричный алгоритм (от 1024 б) взламывается прямым подбором за пару тsczk лет как минимум. См. cryptography.ru

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

jit>>Да я в курсе, всетки мехмат закончил ... Да, один из другого не вычислишь.

jit>>Вот только вся проблема в том, что для ДЕкриптования совсем и не обязательно знать личный ключ. В каждом алгоритме свои слабости. Например побайтовые алгоритмы хачатся построением таблицы соовтетствия. И вообще никаких ключе не надо, ни публичных ни приватных.

N>Ассиметричный алгоритм (от 1024 б) взламывается прямым подбором за пару тsczk лет как минимум. См. cryptography.ru

люблю такие безапелляционные утверждения...

Что подразумевается под "взламывается"? Подбор ключа? Это да...

Но когда на руках уже ЕСТЬ публиный ключ (иначе говоря алгорим ЗАшифровывания), то зашифровав все символы от 0 до 255 можно построить таблицу соответствия, по которой можно РАСшифровать имеющиеся данные. Это в случае побайтового алгоритма (кстати половина реализаций RSA которые валяются на planetsourcecode и подобные — они побайтовые).

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



jit>Но когда на руках уже ЕСТЬ публиный ключ (иначе говоря алгорим ЗАшифровывания), то зашифровав все символы от 0 до 255 можно построить таблицу соответствия, по которой можно РАСшифровать имеющиеся данные. Это в случае побайтового алгоритма (кстати половина реализаций RSA которые валяются на planetsourcecode и подобные — они побайтовые).

В сиистеме PGP публичный ключ на руках есть ВСЕГДА. Ни одного взлома небыло.
И какая такая таблица соответствия ?

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

N>В сиистеме PGP публичный ключ на руках есть ВСЕГДА. Ни одного взлома небыло.
N>И какая такая таблица соответствия ?

Товарищ наверное с XOR попутал немного

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

jit>>Но когда на руках уже ЕСТЬ публиный ключ (иначе говоря алгорим ЗАшифровывания), то зашифровав все символы от 0 до 255 можно построить таблицу соответствия, по которой можно РАСшифровать имеющиеся данные. Это в случае побайтового алгоритма (кстати половина реализаций RSA которые валяются на planetsourcecode и подобные — они побайтовые).

N>В сиистеме PGP публичный ключ на руках есть ВСЕГДА. Ни одного взлома небыло.
N>И какая такая таблица соответствия ?

давайте определимся... Вы когда-нибудь реализовывали или пользовались готовыми реализациями наиболее распространенных алгоритмов асимметричного шифрования? Вы вообще читаете, что я пишу? Разговор слепого с глухим какой-то получется... Еще раз: я пытался сказать, что в реализации алгоритма, будь он хоть 10 раз ассиметричный, могут быть свои слабости. Ассиметричный еще не значит "не ломаемый". В качестве примера привел побайтовый RSA. А вы мне про PGP... При чем тут PGP вообще? PGP это закрытый стандарт. А RSA — открытый, срок его патента давно закончился.

Или вы прелагаете для генерации серийника использовать PGP SDK за 995 долларов?

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

jit>Или вы прелагаете для генерации серийника использовать PGP SDK за 995 долларов?

так — давайте зерна от всякой фигни будем различать есть алгоритм, есть реализация. певрое может быть стойкое, второе иметь "дырки"

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

мы не первый год работаем со схемами коротких криптостойких серийников длиной до 25ти символов. и не надо использовать пгп за штуку — наш HardKey License Manager стоит на порядок меньше. а lite версия вообще копейки. аналогичная схема реализована и в EXECryptor. кейгенов нет и не предвидится.

так что не все так плохо как может показаться на первый взгляд

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


jit>давайте определимся... Вы когда-нибудь реализовывали или пользовались готовыми реализациями наиболее распространенных алгоритмов асимметричного шифрования? Вы вообще читаете, что я пишу? Разговор слепого с глухим какой-то получется... Еще раз: я пытался сказать, что в реализации алгоритма, будь он хоть 10 раз ассиметричный, могут быть свои слабости. Ассиметричный еще не значит "не ломаемый". В качестве примера привел побайтовый RSA. А вы мне про PGP... При чем тут PGP вообще? PGP это закрытый стандарт. А RSA — открытый, срок его патента давно закончился.

jit>Или вы прелагаете для генерации серийника использовать PGP SDK за 995 долларов?

А вы читаете ? Во первых, PGP это не есть алгоритм, это есть программный комплекс, использующий алгоритмы DES,3DES,AED,TwoFish.
НИ ОДНОГО случая взлома этих алгоритмов (в т.ч и обходными путями), нет.
Кстати, какая-то американская фирма предлагает 100 000 $ за взлом оддного из вышеуказанных алгоритмов. Покажите там, КАК вы можете взламать эти системы

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

jit>>давайте определимся... Вы когда-нибудь реализовывали или пользовались готовыми реализациями наиболее распространенных алгоритмов асимметричного шифрования? Вы вообще читаете, что я пишу? Разговор слепого с глухим какой-то получется... Еще раз: я пытался сказать, что в реализации алгоритма, будь он хоть 10 раз ассиметричный, могут быть свои слабости. Ассиметричный еще не значит "не ломаемый". В качестве примера привел побайтовый RSA. А вы мне про PGP... При чем тут PGP вообще? PGP это закрытый стандарт. А RSA — открытый, срок его патента давно закончился.

jit>>Или вы прелагаете для генерации серийника использовать PGP SDK за 995 долларов?

N>А вы читаете ? Во первых, PGP это не есть алгоритм, это есть программный комплекс, использующий алгоритмы DES,3DES,AED,TwoFish.
N>НИ ОДНОГО случая взлома этих алгоритмов (в т.ч и обходными путями), нет.

Что говорит об их грамотной реализации в ПГП. Но не говорит о том, что "любой асимметричный алгоритм нельзя взломать". Не все пишут так как дядьки из ПГП. Скорее наоборот. И то о чем пишет wellwell Благо реализаций ассиметричных алгоритмов сейчас доступно до кучи — многое из этой кучи, что валяется на codeproject.com, psc и тд. — весьма сомнительны с т.з. криптостойкости. Теперь понятно?

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

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

jit>>>давайте определимся... Вы когда-нибудь реализовывали или пользовались готовыми реализациями наиболее распространенных алгоритмов асимметричного шифрования? Вы вообще читаете, что я пишу? Разговор слепого с глухим какой-то получется... Еще раз: я пытался сказать, что в реализации алгоритма, будь он хоть 10 раз ассиметричный, могут быть свои слабости. Ассиметричный еще не значит "не ломаемый". В качестве примера привел побайтовый RSA. А вы мне про PGP... При чем тут PGP вообще? PGP это закрытый стандарт. А RSA — открытый, срок его патента давно закончился.

jit>>>Или вы прелагаете для генерации серийника использовать PGP SDK за 995 долларов?

N>>А вы читаете ? Во первых, PGP это не есть алгоритм, это есть программный комплекс, использующий алгоритмы DES,3DES,AED,TwoFish.
N>>НИ ОДНОГО случая взлома этих алгоритмов (в т.ч и обходными путями), нет.

jit>Что говорит об их грамотной реализации в ПГП. Но не говорит о том, что "любой асимметричный алгоритм нельзя взломать". Не все пишут так как дядьки из ПГП. Скорее наоборот.jit>
jit>И то о чем пишет wellwell Благо реализаций ассиметричных алгоритмов сейчас доступно до кучи — многое из этой кучи, что валяется на codeproject.com, psc и тд. — весьма сомнительны с т.з. криптостойкости. Теперь понятно?
На pgp.com есть исходники реализации.
Математически эти алгоритмы не настолько сложны, чтобы при их реализации допустить ошибки.
Недавно были найдены ошибки в алгоритме( а не в программной реализации) SHA. Количество операций для взлома уменьшилось с 2^83 до 2^63.
От этого его взломать стало проще ? Нужное время измеряется сотнями лет.
А даже если ошибки и есть, велика ли разница, за сколько взломают — за 200 или за 2000 лет ?

neiroman wrote:
> jit>Что говорит об их грамотной реализации в ПГП. Но не говорит о том,
> что "любой асимметричный алгоритм нельзя взломать". Не все пишут так как
> дядьки из ПГП. Скорее наоборот.jit>
> jit>И то о чем пишет wellwell /Благо реализаций ассиметричных алгоритмов
> сейчас доступно до кучи/ — многое из этой кучи, что валяется на
> codeproject.com, psc и тд. — весьма сомнительны с т.з. криптостойкости.
> Теперь понятно?
> На pgp.com есть исходники реализации.
> Математически эти алгоритмы не настолько сложны, чтобы при их реализации
> допустить ошибки.
> Недавно были найдены ошибки в алгоритме( а не в программной реализации)
> SHA. Количество операций для взлома уменьшилось с 2^83 до 2^63.
> От этого его взломать стало проще ? Нужное время измеряется сотнями лет.
> А даже если ошибки и есть, велика ли разница, за сколько взломают — за
> 200 или за 2000 лет ?

Ну-ну. Из-за банальной дыры в генерации ключей NS ломался (не помню
компонент) не за 10^много лет, а за мало часов, а на хороших ПК того
времени — за минуты. Можно написать всё правильно, но применять вот так.
Или — как Вам говорят — побайтно шифровать. Кстати, PWL в ранних Windows
ломались из-за применения мощного алгоритма на слишком маленьких блоках.
Будь блок по более в десять раз — работало бы так же, но не ломалось бы.

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


R>Ну-ну. Из-за банальной дыры в генерации ключей NS ломался (не помню
R>компонент) не за 10^много лет, а за мало часов, а на хороших ПК того
R>времени — за минуты. Можно написать всё правильно, но применять вот так.

Это уже дело радиуса кривизны рук, а не ошибок алгоритмов.
ИМХО, в любом случае (для регистрации программ ) , сложность взлома таких алгоритмов на порядки выше сложности взлома самописны


R>Или — как Вам говорят — побайтно шифровать. Кстати, PWL в ранних Windows
R>ломались из-за применения мощного алгоритма на слишком маленьких блоках.
R>Будь блок по более в десять раз — работало бы так же, но не ломалось бы.

В pwl(как и sam ) применяется хеширование. Взломать их можно только брутфорсом, хотя благодаря удачной реализации MS большинство хешей ломаются максимум за сутки

neiroman wrote:
> R>Ну-ну. Из-за банальной дыры в генерации ключей NS ломался (не помню
> R>компонент) не за 10^много лет, а за мало часов, а на хороших ПК того
> R>времени — за минуты. Можно написать всё правильно, но применять вот так.
>
> Это уже дело радиуса кривизны рук, а не ошибок алгоритмов.
> ИМХО, в любом случае (для регистрации программ ) , сложность взлома
> таких алгоритмов на порядки выше сложности взлома самописных
Вопрос сложности взлома некоторых имеющихся реализаций.
Альтернативой им является написать RSA/ElGamal/* поверх численной
библиотеки, после чего работать не слишком маленькими блоками/не слишком
простыми ключами/не слишком *. Либо надо разбираться в существующих
реализациях. Изобретать криптоалгориты действительно сложно.

> R>Или — как Вам говорят — побайтно шифровать. Кстати, PWL в ранних Windows
> R>ломались из-за применения мощного алгоритма на слишком маленьких блоках.
> R>Будь блок по более в десять раз — работало бы так же, но не ломалось бы.
>
> В pwl(как и sam ) применяется хеширование. Взломать их можно только
> брутфорсом, хотя благодаря удачной реализации MS большинство хешей
> ломаются максимум за сутки
Вот и речь: NS,MS — делали много раз неправильно. Как искать нормальную
реализацию? Что проще — искать или написать? Вопрос не очевиден.

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


R>Вот и речь: NS,MS — делали много раз неправильно. Как искать нормальную
R>реализацию? Что проще — искать или написать? Вопрос не очевиден.

а) взять мануал и проверить конкретную реализацию
б) взять мануал и написать свою реализацию

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

N>а) взять мануал и проверить конкретную реализацию
N>б) взять мануал и написать свою реализацию

мдя... налицо весьма поверхностное владение предметом.

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

SSS>Необходимо что бы программа отработала на компьютере не более 30 дней.
SSS>- как замерять (есть задумка с интернет синхронизацией)
SSS>- где и как лучше хранить дату начала использования программы?

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

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

N>а) взять мануал и проверить конкретную реализацию
N>б) взять мануал и написать свою реализацию

Возьмите, а мы посмотрим, что из этого выйдет.

PS: Это вам не хэндл окна получить...