Зашифровать файл на стороне клиента - PullRequest
0 голосов
/ 08 декабря 2011

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

Я думал о создании .lic или .txt или чего-либо еще, что было бы зашифровано, и при обновлении новыми .lic или .txt и т. Д., Это изменило бы число раз, когда клиент будетбыть в состоянии использовать программное обеспечение.

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

Может ли кто-нибудь помочь мне найти решение для этого?

PS: Программное обеспечение не может быть проверено через Интернет, клиент должен иметь возможность использовать программное обеспечение в автономном режиме, если оно не былоя бы не проверял использование программного обеспечения через Интернет и не столкнулся бы с этой проблемой.

1 Ответ

1 голос
/ 09 декабря 2011

Сначала я должен согласиться с комментарием, который просто говорит, что это не будет безопасно.Несмотря на то, что они верны, разработчику будет легко обойтись, но все же может существовать обоснованная необходимость / желание предотвратить другие 99% населения.Это та же самая битва, с которой сталкивается DRM, всегда есть те 1%, которые готовы потратить время, чтобы расшифровать то, что вы делаете, и обойти это.Но давайте перейдем к тому, как вы этого добьетесь ...

Шаг 1 - вам нужен «счетчик», чтобы узнать, сколько раз было запущено ваше приложение.К сожалению, это будет скрыто только от пользователя, так как ваше приложение должно быть в состоянии прочитать это значение.Часто это запутывание достигается путем скрытия значений в нескольких местах как в реестре, так и в файловой системе.Иногда вы обнаружите, что эта информация «зашифрована» (на самом деле она обфусцируется алгоритмом шифрования) с использованием информации, доступной на хосте, BIOS, типе процессора, идентификаторе жесткого диска и т. Д.counter - это ваш «секретный соус», и единственное, что затрудняет обращение, - это то, что вы держите в секрете то, что вы делаете, (так как большинство форм запутывания полагаются на секретность).Из-за этого я не смог бы предложить вам решение, которое стоит опубликовать здесь, это уже не секрет:)

Шаг 2 - Как только вы получите этот счетчикработая, вам нужно будет предоставить «лицензию» пользователю.Это действительно простая часть, и где PKI криптография может вам помочь.То, что вам нужно, - это закрытый ключ, который вы контролируете только в то время, как в вашем клиентском программном обеспечении где-то жестко задан открытый ключ.Затем вы используете свой закрытый ключ для ' цифровой подписи ' файла лицензии для клиента.Когда ваш клиент загружает файл лицензии, он проверяет подпись, чтобы убедиться, что этот файл лицензии был подписан соответствующим закрытым ключом, что теоретически, поскольку только у вас есть доступ к этому ключу, означает, что вы авторизовали эту лицензию.

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

Проблемы и решения

  1. Наиболее очевидной атакой на такое решение будет обратный инжиниринг кода.Вам нужно будет решить эту проблему с помощью библиотеки .NET obfuscation или путем написания неуправляемого кода.

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

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

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

И, наконец, , всего этого будет недостаточно, чтобы помешать решительному человеку успешно победить вашу стратегию лицензирования. Примите это сейчас и внедрите столько, сколько считаете нужным, исходя из уровня компьютерной грамотности вашего среднего пользователя и суммы потерянного дохода в зависимости от стоимости внедрения. Другими словами, говорите, что вы реализуете что-то действительно глупое и простое и ожидаете, что 20% ваших пользователей смогут это понять. Исходя из ваших клиентов, вы полагаете, что из этих 20% ваших пользователей менее четверти из них фактически обойдут вас в DRM, а не заплатят за лицензию. Таким образом, вы ожидаете потерять 5% от вашего возможного дохода, скажем, вы зарабатываете 1 миллион в год, что означает, что вы теряете 50 000 доходов. Теперь спросите себя, потрачу ли я X долларов своего времени на то, чтобы кому-то было сложнее обойти, в какой момент это стало отрицательным результатом? Конечно, при ожидаемой потере в 50 тыс. Вы не захотите потратить год на работу по DRM.

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

...