Как запретить другим пользователям использовать мою сборку .Net?

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

Ответ 1

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

public class NotForAnyoneElse {
  public NotForAnyoneElse() {
    if (typeof(NotForAnyoneElse).Assembly.GetName().GetPublicKeyToken() != Assembly.GetEntryAssembly().GetName().GetPublicKeyToken()) {
      throw new SomeException(...);
    }
  }
}

Ответ 2

В .Net 2.0 или выше сделайте все внутреннее, а затем используйте сборки Friend

http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

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

ILMerge.exe и .dll
obfuscate final.exe

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

Ответ 3

100% полностью невозможно без прыжка через некоторые обручи.

Одним из преимуществ использования .NET является возможность использовать отражение, то есть загрузку сборки и ее проверку, динамические методы вызова и т.д. Это то, что делает возможным взаимодействие между VB.NET и F #.

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

Если вы должны отправить свой код .NET таким образом, чтобы другие люди не выполняли его, вы могли бы использовать NGEN для своего двоичного файла (скомпилировать его на x86) и отправить эти двоичные файлы.

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

Ответ 4

Вы также можете посмотреть, используя Netz исполняемый пакер и компрессор.

Это берет ваши сборки и ваш .exe файл и упаковывает их в один исполняемый файл, поэтому они не видны во внешнем мире без какого-либо поиска.

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

Большое преимущество подхода .netz заключается в том, что он не требует изменения кода. Другим преимуществом является то, что он действительно упрощает процесс установки.

Ответ 5

Вы должны иметь возможность сделать все внутри области, а затем использовать InternalsVisibleTo Атрибут, чтобы предоставить только один доступ к сборке внутренние методы.

Ответ 6

Атрибут безопасности доступа к коду, который @Charles Graham упоминает StrongNameIdentityPermissionAttribute

Ответ 7

Как уже упоминалось, используйте атрибут InternalsVisibleTo и отметьте все как внутреннее. Это, конечно, не защитит от отражения.

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

ОБНОВЛЕНИЕ: Кроме того, IIRC, ilmerge имеет функцию, в которой он может автоматически интегрировать объединенные сборки, что означает, что вам не нужно использовать InternalsVisibleTo вообще

Ответ 8

Я не уверен, что это доступная возможность для вас, но, возможно, вы можете разместить сборку с помощью веб-служб WCF или ASP.NET и использовать какую-то схему аутентификации (LDAP, пары ключей public/rpivate и т.д.), чтобы обеспечить доступ только к подключенным клиентам. Это обеспечит физическую сборку вашей сборки из рук другого человека, и вы сможете контролировать, кто к ней подключается. Просто мысль.

Ответ 9

Возможно, вы сможете установить это в политике безопасности доступа к коду на сборке.

Ответ 10

Вы можете использовать обфускацию.

Это повернется:

int MySecretPrimeDetectionAlgorithm(int lastPrimeNumber);

В нечто нечитаемое вроде:

int Asdfasdfasdfasdfasdfasdfasdf(int qwerqwerqwerqwerqwerqwer);

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

Ответ 11

Похоже, вы ищете инструмент защиты или обфускации. Хотя нет серебряной пули, рекомендуемый инструмент защиты smartassembly. Некоторые альтернативы Salamander Obfuscator, dotfuscator, и Xenocode.

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

Надеюсь, это поможет.:)

Ответ 12

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

Ответ 13

Просто попросите код передачи, который будет отправлен с использованием вызова функции, и если он не был авторизован, ничего не работает, например .setAuthorizeCode('123456'), то в каждом месте, которое можно использовать, проверьте, разрешен ли authorizeCode!= 123456, затем выбросьте ошибку или просто выйдите... Это не похоже на хороший ответ для повторного использования, но это точно так же.

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

Просто мысль, может быть то, что вы ищете, или может вдохновить вас на что-то лучшее.