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

Question

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

1. ILMerge Исполняемых и .dll
2. запутать окончательный EXE-файл

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

Answer 5

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

Answer 6

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

Что получится:

int MySecretPrimeDetectionAlgorithm(int lastPrimeNumber); 

В то нечитаемым, как:

int Asdfasdfasdfasdfasdfasdfasdf(int qwerqwerqwerqwerqwerqwer); 

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

Answer 7

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

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

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

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

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

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

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

Answer 11

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

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

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

Answer 12

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

Answer 13

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

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

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