Как вы делаете демо-приложение какао, которое работает только в течение ограниченного времени? - PullRequest
6 голосов
/ 11 октября 2011

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

Ответы [ 3 ]

29 голосов
/ 12 октября 2011

(Отказ от ответственности: я никогда не делал пробную версию раньше, только читал на эту тему и использовал несколько из них.)

Все ограничения связаны с тем, что что-то в системе пользователя,Пользователь может изменить.Итак:

  • Умные cheapskates могут изменить исполняемый файл вашего приложения, чтобы заглушить или иным образом победить любую сделанную вами проверку.
  • Вы должны хранить количество использованного времени (или, что более лениво, ноне так удобно для пользователя, дата, когда они начали использовать ваше приложение) где-то.Где бы вы ни хранили его, пользователь должен иметь возможность изменить его (поскольку ваше приложение запускается как они), что означает, что, если они его найдут, они могут сбросить часы.
  • Это невозможно, если вы запуститев песочнице, если только вы не сохраните вышеупомянутые данные отслеживания времени в пользовательских значениях по умолчанию или связке ключей, которые также могут быть на виду, или не запросите разрешение на временное исключение для записи в любом месте файловой системы.Ограниченные по времени испытания в любом случае не могут быть в App Store, но если в будущей версии Mac OS X потребуется App Store или «песочница», ваш лимит времени будет нарушен, и мы можем только надеяться, что это не помешаетпользователь полностью использует ваше приложение.
  • Существует также вопрос обработки платежей.Одним из способов является продажа приложения в App Store без какого-либо пробного принудительного кода и распространение отдельной сборки, которая всегда требует ограничения по времени.Если вы обрабатываете платежи самостоятельно, вам необходимо сохранить запись о лицензии пользователя в системе пользователя и проверить эту лицензию.Это затем становится уязвимым для той же проблемы: пользователь может подделать лицензию или «одолжить» (например, загрузить с сайта Warez) чужую.

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

В конце пробного периода у вас есть выбор, что произойдет:

  • Полностью заблокируйте пользователя из приложения.
  • Вырежьте функции.Acorn делает это.
  • Позвольте им открывать документы, но не сохранять и не печатать.(Вы можете заблокировать скриншоты, но тогда вам повезет с обработкой отчетов об ошибках.)
  • Позвольте им сохранять или (если применимо) печатать, но каким-либо образом ухудшать часть или весь документ.Для визуальных созданий, таких как изображения, может работать водяной знак.Для аудио вы можете ограничить частоту дискретизации до чего-то неприятного, например, 20 кГц или меньше.(Здесь есть случай, когда у вас есть собственный проприетарный формат, который вы всегда обрабатываете без потерь, и только ухудшаете экспорт в распространенные форматы, такие как TIFF, JFIF или AIFF.) Fission делает это.
  • Просто порежьте их.(Может сочетаться с любым из вышеперечисленного.)
  • Нагните их и отложите возможность пользователя отклонить его.Вы можете даже увеличить задержку, если пользователь дольше не платит.

Хорошей альтернативой пробному периоду является наличие отдельной «бесплатной» версии с меньшим количеством функций (или с рекламой).Это особенно распространено в обоих магазинах приложений.

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

Вы также можетеввести ограничение на количество запусков.Это так же просто реализовать, как и дни с момента первого использования, но не наказывает только игру с приложением один раз.

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

Таквам нужно найти баланс.Вы должны обеспечить базовый уровень сложности, чтобы самые ленивые дешевые скейты не могли просто defaults write com.example.yourapp DaysSinceFirstUse -int 0 и продолжать использовать ваше приложение вечно, при этом не делая ваше приложение настолько обременительным, чтобы испытывать (гораздо меньше платить), чем они этого не делают.

Итак, вот некоторые вещи, которые не нужно сделать:

  • Попытка обеспечить равенство имени пользователя в его лицензии (введено впокупки) и их имя в учетной записи или в адресной книге.Есть дюжина различных способов написания любого имени, и у некоторых людей есть несколько имен (через брак, псевдонимы, законные изменения имени, несколько языков, фэндом Star Trek и т. Д.), Так что это или что-то вроде этого является фиктивной проверкой того, чторасстроит больше законных пользователей, чем отпугнет пиратов.
  • Держите данные пользователя в заложниках.См. Мой пункт выше о достоинствах проприетарного формата, который вы всегда обрабатываете без потерь.Если вы всегда ухудшаете вывод во время пробной версии, сделайте это абсолютно ясно в диалоговом окне запуска приложения «Это пробная версия».
  • Требуется подключение к Интернету.Не у всех есть один (который может подключаться к произвольным серверам), и не у всех он есть постоянно.Учитесь у игровой индустрии: не отталкивайте своих пользователей.
  • Установите любое программное обеспечение для обеспечения соблюдения авторских прав, которое работает в фоновом режиме и / или находится отдельно от вашего приложения.Пользователи будут справедливо ненавидеть вас за это.

Что касается того, как до сделать это, вот что я рекомендую:

  • Реализуйте проверку «дней фактического использования».Это может быть точкой продажи.Это согревает мое сердце, когда суд прямо заявляет, что использует этот вид проверки.
    • Я бы сказал, хранить его в часах.При запуске получите текущее количество часов от того места, где вы его храните.Добавьте два часа и запишите его обратно (чтобы пользователь не мог принудительно выйти из приложения, чтобы победить это).При выходе добавьте действительное число часов с момента запуска к первоначально прочитанному номеру и запишите исправленное число обратно.
  • Сохраните его в невидимом файле в Службе поддержки приложений.Зашифруйте его (опять же, вы хотите победить случайное пиратство), но не тратьте слишком много времени на пуленепробиваемость.Помните, что ваше приложение должно содержать все как для шифрования (для отслеживания), так и для дешифрования (для выполнения проверки), поэтому достаточно определенный (и образованный) cheapskate может сломать это независимо от того, что вы делаете.
  • При запуске получите текущее количество часов, где бы вы ни хранили его, и проверьте, не превысило ли оно лимит.(Если вы воспользуетесь моим предложением добавить два часа сразу, сделайте это после , когда вы проведете тестирование с ограничением.) 30 дней - это 30 × 24 = 720 часов.Если он превышает лимит, примите меры, срок действия которых истек.
  • Если вы продаете программное обеспечение самостоятельно, используйте симметричное шифрование с открытым ключом для файла лицензии.Я думаю, что AquaticPrime делает это.Вы шифруете лицензии своим закрытым ключом и распространяете открытый ключ в приложении, которое использует открытый ключ для расшифровки и проверки лицензии.Практически не ломается.Вы отправляете файлы лицензий клиентам по электронной почте, используя адрес электронной почты, который они предоставляют при покупке.(Сообщите им, что они получат лицензию по электронной почте, чтобы они не вводили выдуманный адрес.)
    • Если вы сделаете это, обязательно проверьте ввод лицензии, как до окончания пробного периода, так и послеоно заканчивается.
    • Выполните пробную проверку только при отсутствии лицензии.
  • Если вы можете продать свое приложение в App Store, я рекомендую вам просто сделать это.Если вы хотите также распространять пробную версию самостоятельно, сделайте это без лицензионного кода, чтобы пробная проверка просто прошла безоговорочно.Разумеется, версия App Store не требует (и не должна иметь) пробной проверки.
  • Посмотрите это. (Примечание. Она предшествует обоим магазинам приложений Apple.)
4 голосов
/ 20 августа 2014

Как правило, они сохраняют количество дней / часов / того, что использовалось где-то, например, в пользовательских настройках приложения.

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

Хорошие местоположения - это невидимые файлы в местах, которые пользователь не ожидает, может быть названы так, что они выглядят как файлыдругое приложение или системный файл.Но будьте осторожны, чтобы вы не засоряли файлы в файловой системе, которые затем придают другому приложению видимость плохого имени.Также стоит подумать о том, чтобы записать ресурс в ветку ресурсов файла, куда большинство людей в наши дни больше не смотрят (один из ваших файлов! Другое приложение или система могут заменить их файл и лишить вас информации, илиможет использовать тот же тип ресурса и вызвать коллизию).

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

Некоторые разработчики приложений вместо этого генерируют лицензионный ключ, срок действия которого истекает вэто и заставить приложение отказаться от запуска без действительного лицензионного ключа.Есть хорошая статья Аллана Одгаарда о том, как подписывать информацию с помощью OpenSSL (убедитесь, что вы используете LibreSSL или CommonCrypto.framework в эти дни, которые очень похожи), чтобы получить дату истечения срока действия для вашего пользователя без возможности его редактирования: http://sigpipe.macromates.com/2004/09/05/using-openssl-for-license-keys/

0 голосов
/ 31 августа 2013

Основываясь на ваших идеях, я сделал краткое доказательство концепции в Java, используя криптографию с эллиптической кривой для генерации UUID при запуске, а затем подписал этот UUID с помощью ECC для создания регистрационного ключа. Код здесь, если кто-то хочет. 1

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...