Какой код написать для системы, подключенной к ключу, чтобы обеспечить лучшую безопасность?

Прежде всего, поймите, что ключ будет лишь небольшим препятствием. Кто-то, кто знает, что делает, просто удалит вызов ключа и вставит «истину» для любого результата, который был вызван. Это вам все скажут. Но есть препятствия, которые вы можете добавить!

Я бы нашел ключевую часть вашего кода, что-то, что сложно или трудно понять, что-то, что требует знания предметной области. Затем поместите это знание на ключ. Одним из примеров этого могут быть шейдерные процедуры. Подпрограммы шейдеров — это текстовые файлы, которые отправляются на графическую карту для достижения определенных эффектов; для реализации очень простого фильтра яркости/контрастности потребуется менее 500 символов, и вы можете сохранить его в пользовательском пространстве на большинстве аппаратных ключей. Затем вы помещаете эту информацию в ключ и используете только информацию из ключа для отображения изображений. Таким образом, если кто-то попытается просто удалить ваш ключ, все изображения в вашей программе будут затемнены. Потребуется, чтобы кто-то имел копию вашей программы, взял текстовый файл из ключа, а затем модифицировал вашу программу, чтобы включить этот текстовый файл, а затем знал, что этот конкретный файл будет «правильным» способом отображения изображений. Особенности реализации зависят от вашей платформы развертывания. Например, если вы запускаете программу в WPF, вы можете сохранить подпрограмму DirectX в своем ключе, а затем загрузить эту подпрограмму из ключа и применить эффект ко всем изображениям в вашем приложении. Затем взломщик должен иметь возможность перехватить эту процедуру DirectX и применить ее должным образом.

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

Однако лучше всего поместить на ключ специфичную для домена функцию (например, всю процедуру генерации UID). Различные производители будут иметь разные возможности в этом отношении.

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

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

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

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

Тем не менее, с системой, как описано, эмулировать ключ по-прежнему просто, поэтому рано или поздно кто-то это сделает.

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

Как максимально защитить с помощью простого ключа?

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

Вызывайте API-интерфейсы ключа во МНОЖЕСТВЕ мест в вашем приложении. Например, при первом запуске, при открытии файла, при открытии диалогового окна и перед обработкой какой-либо информации. Также, возможно, сделайте некоторую выборочную проверку, даже если вообще ничего не сделано.

Используйте более одной функции для защиты программы. Не используйте только функцию поиска для поиска подключенного ключа.

Используйте несколько dll/библиотек (если применимо) для вызова функций ключа. В случае если одна dll взломана, то есть еще другие части софта, которые используют функции из другой dll. Например, копирование sdx.dll в print.dll, open.dll и другие имена, а затем определение вызовов функций из каждой dll с разными именами.

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

У меня есть эта статья на PRLOG, и я нашел ее весьма полезной для максимальной защиты с помощью простого ключа. Может эта ссылка вам поможет

Максимальная защита с помощью простого ключа для вашего Программное обеспечение

Вы можете реализовать множество контрольных точек в своем приложении.

Я не знаю, используете ли вы HASP, но, к сожалению, < можно эмулировать ключи href="http://www.dongleservice.com/emulate-hasp.phtml" rel="nofollow noreferrer">.

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

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

http://www.microcosm.co.uk/dongles.php

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

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

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

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

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

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

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

Я бы сказал, что если кто-то захочет взломать защиту вашего программного обеспечения, он это сделает. Когда вы говорите «достаточно сильно» — как следует интерпретировать «достаточно»?

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