Где создавать/хранить секретные файлы для информации о лицензии/испытаниях в Windows/Mac OS X/Linux?

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

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

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

Итак, вот мой вопрос: что является лучшим местом/стратегией для хранения и создания таких скрытых файлов в Windows, Mac OS X и Linux? Вот что мне пришло в голову:

Linux/Mac OS X

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

Окна

Вероятно, очень похож на Linux/Mac OS X - более поздние версии Windows становятся более ограничительными, когда речь идет о разрешениях файловой системы.

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

Спасибо!

Update

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

Ответ 1

Кому важно, где вы кладете файл. Его содержимое, которое вы хотите защитить.

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

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

Ничто не защитит вас от сложных попыток взломать ваше приложение. Но это решение лишит случайных пользователей возможности разорвать вашу лицензию.

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

Ответ 2

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

Ответ 3

Системы POSIX должны помещать данные приложения в скрытый файл в домашний каталог пользователя. Системы Windows должны помещать что-то под CSIDL_APPDATA.

Ответ 4

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

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

Ответ 5

Чтобы проиллюстрировать проблемы с этим подходом, появился сервер мультимедиа на базе Linux, который хранил его временную метку бесплатной пробной версии в /usr/bin/.tv. Для пользователя требуется только strace, чтобы понять, к какому файлу обращаются - в этом случае просто удаление файла перезапустило пробную версию.

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

Ответ 6

В частности, на Mac этот файл должен находиться в ~/Library/Application Support/YourAppName, если пользовательская лицензия, или /Library/Application Support/YourAppName для лицензии на машину.

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

Ответ 7

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

fooobar.com/info/24918/... - статья, описывающая доступ к реестру с использованием языка программирования Java.

Я не думаю, что у Mac есть что-то вроде этого, и я знаю, что Linux, конечно, не имеет его, но это начало.

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