Совет потребности разработать 'взломано-защищенное' [закрытое] программное обеспечение

Разве это не признак успеха, когда ваш продукт взламывают? :)

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

Но все еще существует вездесущий метод IsValid (), который можно взломать, чтобы всегда возвращать истину.

Вы даже можете поместить этот метод в подписанную сборку, чтобы предотвратить вмешательство, но все, что вы сделали, это создали еще один слой «IsValid ()», который тоже можно взломать.

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

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

Мы бы потратили больше денег, пытаясь придать нашему решению «защищенность от несанкционированного доступа», которую мы теряем для пиратов.

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

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

Вам нужно начать с проникновения в местную хакерскую банду, изображающую из себя 11-летнего мальчика, который хочет «взломать это». Как только вы заслужите их доверие, вы сможете узнать, какие функции им труднее всего взломать. Когда вы тайно публикуете «невзламываемое» программное обеспечение для местных форумов, вы можете видеть, что они с ним делают. Развивайте свои внутренние знания до тех пор, пока они не перестанут взламывать ваше программное обеспечение. Когда это будет сделано, дайте знать свою личность. В идеале это будет восприниматься как предательство, что вы работаете против них. Надеюсь, это побудит их связаться с другими хакерами за пределами местного сообщества, чтобы атаковать ваше программное обеспечение.

Продолжайте, пока не достигнете вершины хакерской мафии. Напишите свою диссертацию как книгу, продайте HBO.

Я скажу вам, что ближе всего к "взломостойкости": веб-приложение.

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

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

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

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

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

Как сказал нут, любой код, который вы выпускаете на машину клиента, можно взломать .

Не пытайтесь «не взломать». Попробуйте указать «есть достаточно средств устрашения, чтобы разумно защитить мои активы».

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

Взлом любого двоичного файла имеет конечную стоимость. Эта стоимость увеличивается из-за количества взламываемых двоичных файлов.Если вы выпускаете новые функции каждую неделю, вы, по сути, делите своих пользователей на две группы:

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

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

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

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

Если вы развертываете программу на виртуальной машине, это очень плохо. Там не так много альтернатив. Все популярные виртуальные машины (java, clr и т.д.) очень просто декомпилируются, и для этого не достаточно ни обфускатора, ни сигнатуры.

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

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

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

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

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