Лучшее место для сокрытия ключа в Windows Registry?
Моя программа Delphi имеет встроенный механизм защиты для проверки на запрещенные лицензионные ключи в Интернете и отображает сообщение пользователю, если помещенный в черный список ключ найден.
Я хотел бы сохранить помещенный в черный список ключ в реестре, поэтому если пользователь пытается повторно ввести его (и он не подключен к Интернету), он не принят.
Что лучший способ состоит в том, чтобы скрыть запутываемую запись в реестре Windows?
Спасибо!
Править: Вы у парней есть некоторые хорошие ответы там, но я чувствую, что должен развернуть вопрос.
Это не основное программное обеспечение, но корпоративное. Клиенты предварительно оплачивают один год и получают однолетний лицензионный ключ для активации. Лицензионный ключ включает идентификатор машины и не может использоваться в другом месте.
Проблема состоит в том, что некоторые клиенты склонны не платить вовремя, или они не платят вообще. Так как я не хочу беспокоиться короче, чем лицензионные ключи года (слишком много административных издержек), мне нужен способ отключить их лицензии, пока они не платят.
Таким образом, приложение теперь соединится с Интернетом на запуск и проверит, помещен ли их ключ в черный список. Если это, я должен отключить доступ. В случае, если они переустанавливают или доступ в Интернет блока, я должен знать, был ли ключ помещен в черный список.
Таким образом я думаю, что было бы лучше скрыть его в реестре. Мои пользователи не являются технологией-savy достаточно для использования инструментов реестра для контроля реестра, но если бы я подверг его HKLM/Software/MyCompany/MyProgram, то некоторые из них могли бы сделать, находят его. Таким образом, мне нужно место, где они не могут найти его впоследствии, что это было создано. (Никто не будет ожидать это!)
Какие-либо идеи?
5 ответов
Самый простой способ скрыть ключ или значение - создать ключ / значение, содержащее '\ 0' внутри имени. Вы можете сделать это с учетом встроенных функций NtCreateKey (см. http://msdn.microsoft.com/en-us/library/ff556468.aspx ) NtSetValueKey (см. http://msdn.microsoft.com/en-us/library/ff557688.aspx ), которые используют UNICODE_STRING в качестве параметров вместо LPCTSTR . Вы можете узнать больше об использовании собственного API реестра, например, в http://www.codeproject.com/kb/system/NtRegistry.aspx . Код Delphi вы найдете здесь http://www.delphi3000.com/articles/article_3539.asp .
ОБНОВЛЕНО : Поскольку многие люди читают этот вопрос, я хочу добавить несколько слов к своему ответу.Я хочу разделить часть вопроса, которую мы можем прочитать также в заголовке «Лучшее место для скрытия ключа в реестре Windows» , от субъекта с лицензионными ключами . Поскольку я прочитал некоторые ответы (написанные до меня), которые касались почти только части лицензионных ключей, и практически не прочитал ответа на вопрос из заголовка, я написал мне ответ.
Тема с лицензионным ключом мне кажется очень сложной. Это зависит от выбранной модели лицензирования. Важно, как сгенерировать, распространить (установить) и проверить ключ. Должен ли ключ зависеть от оборудования или нет? Это может быть один на компьютер или один на группу компьютеров. Генерация ключа, установка ключа или проверка ключа могут производиться как в отношении некоторых онлайн-сервисов (в том числе из Интернета), так и без них. Могу продолжить ... Есть много аспектов, преимуществ и недостатков разных подходов.
Поэтому я решаю ответить только на главный вопрос из заголовка , который ясен и представляет отдельный интерес. Все остальные вопросы о лицензионном ключе, на мой взгляд, следует обсудить в отдельном вопросе после снятия всех требований.
ОБНОВЛЕНО 2 на основе обновленного вопроса: Мне кажется, в вашем случае было бы лучше использовать какой-нибудь сценарий, основанный на криптографической подписи билета активации . Например, схема может выглядеть следующим образом:
- Программное обеспечение, установленное на клиентском компьютере, требует активации.Перед активацией он не может работать или работать в очень ограниченной форме (например, включены только некоторые меню, необходимые для активации программного обеспечения).
- Вы пишете серверный компонент, который будет использоваться клиентом во время активации для генерации лицензионного ключа на основе запроса активации, полученного от клиента.
- Если клиент платит за программное обеспечение, вы включаете информацию о «идентификаторе машины» клиента (в любой форме) в базу данных на сервере.
- После запуска процесса активации из клиентского программного обеспечения (либо при запуске программы из меню, либо любым другим способом, как вы хотите) он собирает некоторую информацию о компьютере, такую как имя компьютера («идентификатор машины»), некоторые серийные номера. номера или другая информация об оборудовании или операционной системе, которую нельзя изменить без новой активации. Эту информацию программа отправляет на ваш сервер (это запрос на активацию).
- Сервер проверяет, что клиент с «идентификатором машины» заплатил за программное обеспечение и еще не активирован. Затем сервер вычисляет хэш (SHA1, MD5 или какой-либо другой) из информации, отправленной от клиента, и подписывает ответ закрытым ключом сервера (или сертификатом сервера). Подписанный сервер билетов будет отправлен обратно клиенту. Этот билет будет играть роль лицензионного ключа.
- Сервер может добавить любую дополнительную информацию в билет перед подписанием. Например, он может добавлять информацию о дате до тех пор, пока программа не станет действительной (например, текущий день плюс один год).Таким образом, билет, который будет отправлен обратно клиенту, может содержать хэш входной информации об активации и любую дополнительную информацию, все, что вы хотите. Важно только то, что информация должна быть подписана . В общем, вы можете включить полный запрос клиента в виде открытого текста в билет сервера вместо включения хэша, но использование хеша а) уменьшает размер билета и б) делает билет немного более безопасным.
- Каждый клиент имеет открытый ключ соответствует закрытому ключу, используемому сервером для подписания билета активации. Клиент сохраняет билет, полученный от сервера во время активации, в любом месте реестра или файловой системы.
- Каждый раз, когда будет запущено клиентское программное обеспечение, оно будет читать сохраненный билет активации из реестра (или из файловой системы). Затем программа собирает ту же информацию, которая используется для генерации билета активации, вычисляет хэш и сравнивает его с хешем из сохраненного билета. Он проверяет причину подписи билета в отношении открытого ключа (или в отношении сертификата сервера). Более того, программное обеспечение может проверять любую другую дополнительную информацию о политике из билета, например, время до того, как билет действителен.
Все написанное представляет собой лишь приблизительную схему, но она очень проста и расширяема. Вам нужно только изучить, как использовать простую криптографическую операцию и реализовать ее в своем программном обеспечении.
В качестве опции вы можете не иметь сервер в сети, но вместо этого реализовать в программном обеспечении (например, в меню) возможность генерировать запрос активации и отправлять его на электронная почта например. Затем вы можете в автономном режиме (!!!) сгенерировать билет активации на основе запроса сервера и отправить билет обратно клиенту также по электронной почте. Простой Reg-файл, который можно импортировать двойным щелчком или другой простой возможностью импорта в ваше программное обеспечение (вырезать и вставить в диалоговом окне активации), может завершить процесс активации программного обеспечения.
Если вы действительно хотите пойти по этому пути, хешируйте или зашифруйте ключи, а затем проверьте хешированный или зашифрованный ключ пользователя в реестре.
Не забудьте проверить, есть ли какие-либо ключи в реестре, чтобы убедиться, что пользователь не стер их.
Добиться того, что вы пытаетесь сделать, будет очень сложно, поскольку пользователь может просто удалить и установить заново, а опытные пользователи могут стереть все следы вашего приложения из системы (включая реестр).
Другие приложения (например, Windows), вместо того чтобы проверять наличие отрицательного (запрещенного ключа), проверяют наличие положительного (хорошего ключа). Вы "активируете" программу один раз (при подключении к сети), и эта активация сохраняет "хороший ключ", который затем можно проверять при каждом запуске программы (как онлайн, так и офлайн).
Я бы предложил вам второй подход.
Я не думаю, что реестр - хорошее место для сокрытия такой информации, потому что любой может загрузить и использовать Process Monitor ( http://technet.microsoft.com/ en-us / sysinternals / bb896645.aspx ) и посмотрите, что ваша программа делает с реестром.
И снова об этом думаю. Вы, вероятно, сделаете недовольным пользователей своего программного обеспечения, если оно оставит что-то в реестре и других «секретных» местах на жестком диске пользователя. Подобные местоположения также легко обнаруживаются инструментами, отслеживающими, какие системные функции вызывает ваше программное обеспечение.
В качестве альтернативы вы можете встроить запрещенные ключи в свое приложение при выпуске новых версий. Таким образом, запрещенные ключи будут скрыты в приложении, и взломщикам будет сложнее обойти защиту.
Обратной стороной этого является то, что пользователь потенциально может запускать старую версию с заблокированным ключом с заблокированным доступом в Интернет для вашего сайта, но если ваше программное обеспечение активно разрабатывается с добавлением новых функций и исправлений, тогда никто не захочет запускать старые версии. . А если вы очень параноик, вы можете выпускать «обновления», которые обновляют только встроенный список запрещенных ключей.
Но в конечном итоге ни одна схема защиты программного обеспечения не бывает идеальной. Если ваше программное обеспечение достаточно популярно, всегда найдется пиратский взломщик, который выяснит вашу защиту и сделает патч или даже генератор ключей.
Обратите внимание, что существуют обычные инструменты для конечных потребителей, которые отслеживают, какие приложения записывают в реестр (например, Cleansweep). Это происходит на уровне вызова API, поэтому, вероятно, он также найдет обходные пути №0.
Вы можете попытаться зашифровать весь shebang в ключе реестра, используя что-то, что однозначно идентифицирует машину (например, MAC-адрес) и отметку времени, чтобы люди не могли перенести ключ на другие машины. ТО всегда требует наличия такого ключа для запуска и требует подключения к Интернету для обновлений / активации, если его нет. (или отметка времени очень старая)