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

ключ нужен с содержанием, тоесть будет представлять из себя зашифрованный массив параметров железа (с обратным дешифрованием) (варианты сокращения ключа в базе данных (так как нет смысла пихать огромный кусок байт): SHA1->HEXtoINT , SHA1->MultiReplace [ к примеру 0=!, F="] , ну и как вариант просто SHA1->MD5->SHA256)

у меня был такой вариант:

Ключ:
code_34748.txt

Сокращение:

code_34749.txt


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

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

Но потом подумал "А зачем ?" можно подойти к делу иначе !
Пересчитать в некий хешь например номер первого кластера системных файлов и папок(не обязательно это можно например взять хешь партишен табле ) добавить "код подлинности" (уникальный код получаемый из SN пакета + например время работы программ + дата и время установки ) Дальше идем на сайт софтины вбиваем код ... после проверки "разумности данных" получаем "ответный код" (SN пакета уникальный и код одноразовый ) если что-то переставил (даже с машины на машину) пошел на сайт (или отправил емайл) ввел предыдущий код ( он при этом отменился ) плюс новый "код машины" ... ВСЕ !

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

Если кто-то украдет прогу едва-ли но будет красть и сохраненные
данные (Можно вообще включать в них микро-екзешник)



Поломать, изначально поставить на ВМ (Хотя таскать из небольшой программы ЦЕЛУЮ ОСЬ сродни мазохизму) и тд наверное можно (НО от самых общераспространенных ВМ наверное зашиться не так уж сложно )
И можно еще например добавить самую примитивную проверку даты прошивки ПЗУ ...
Плюс шифровка критических данных "ответным кодом"и "кодом машины" все это может неплохо улучшить надежность защиты "в пределах разумного"

Важна не надежность привязки а "комплексный подход" и удобство возобновления ...
Еще можно вычислять работающие копии софтины (Что особенно просто если для фукциклирования требуется интернет или доступ к определенному сайту)

ммм... мало что понял , но лучше всё же придерживатся ЖЕЛЕЗА, иногда бывают ситуации когда просто ненадо привязывать 1 ПК определённый к программе и нам требуется сводная информация о железе, а ваши ключи тут не помогут... и что касается сис. файлов и папок, так зачем... что то не понял.

вообще основа уже реализована:
ключ берётся из хэширования массива данных о железе, далее грузится простой HEX масиив с сайта что и представляет собой базу данных, массив защищён от модифицирования путём хэширования и дописи в конец его хэша, дабы никто не смог изменить этот массив, далее попросту ключ сравнивается тот который мы получили и тот который у клиента, ну и запуск самой программы (дабы защитить некоторые ветки, ставим доп проверки ПРОХОЖДЕНИЯ данных в этих ветках, если проходили данные то соответственно происходит событие которое активирует тот или иной модуль в самой программе)

Кстати мысль! Возможно лучшая защита буде та о которой пользователь не осведомлен заранее ...

Ну пришел к соседу ... Запустил "опаньки глюки" !
Что подумает ?

А на самом деле прога настроилась именно на его комп (и инсталлятор тоже )

Для защиты "правы потребителя" можно оставить контактный емайл
и высылать "обновление" по предъявлению например номера договора .... Хешнутый одноразовой утилиткой ...

Извини вредная привычка дописывать посты ...

Всё что вы тут написали, можно обойти за минуты 3-4 и разными способами.
Пакет Windows, совершенно не предусмотрен для решения интересующей вас задачи.
Через IC, ещё кое что можно сделать.
Тут банально в памяти процесса, можно ковыряясь найти нужную информацию, т.к. данные переменных элементов в результате, так и будут висеть в памяти, даже после того, как переменные (адреса на блоки памяти) будут удалены при выходе из стека.
Сделали hex -> string -> md5, в памяти процесса так и останется содержимое этих переменных, пока память выделенная под эти переменных, не будет принудительно обнулена, или, пока система не выделит память в этих блоках памяти под другие данные, и они не перезапишут предыдущую информацию.
Т.е. после каждой операции с приватными данными, нужно применять хотя бы ZeroMemory (WinAPI), или доступными средствами, перезаписывать данные.

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

ммм, для начала надо обойти защиту от модифицирования файла, которая работает только 1 раз, тоесть пропустить данные через цепочку можно только 1 раз... да и там кучу всего напутано, так что за 3-4 минуты это перебрать ...

Rysik, а кто сказал, что нам потребуется изменять сам файл?
Можно сделать загрузчик, который при запуске твоего приложения, аккуратно подменит требуемые вызовыданные.
Или, во время проверки введённого ключа на валидность, loader может перехватить валидный ключ, который был сгенерирован для сравнения.
Зависит конечно от реализации, но, тут очень много разных манёвров имеем мы

Могу напомнить то, что там куча ответвлений от основной ветки, которые тоже надо как то вам отловить и подменить так как надо... , да и данные там передаются не в 1-й форме...

Ну раз уж на то пошло, так не совершить ли небольшой краш тест пакета windows?

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

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

Rysik, а в третьих, надо быть увереным, что ваша супер-пупер программа вызовет интерес аж до такой степени

ну и это тоже

Когда-то для ДОСа делал шифрование екзешеника + самостоятельная загрузка настройка адресов и передача управления в обход системных функций ... То есть вместо EXE-файла грузился какой-то левый формат "ZGR" ...
Загрузчики привязывал к дискете(чередование секторов (т е форматировал 9-й как первый ) + "инженерные дрожки" ) или к дате прошивки ПЗУ(По тем временам способ был довольно надежный ...)

Кстати, интересно, а можно-ли узнать SN контролера обычной флешки ?

Если получится можно привязывать даже ПО продаваемое через инет ...
Алгоритм прост
1 качаем ОДНОРАЗОВУЮ утилиту (Второй раз запустить можно но результат работы будет действителен только один раз )
2 Запускаем ... утиль просит вставить "надежную флешку"
3 Получаем хешь код SN
4 Отсылаем хешь (или сама утиль отсылает) на сайт
5 Получаем привязанную версию
6 Запускаем... вставляем флешку... Много радуемся !