Как я могу защитить свой исходный код ASP.Net от моих разработчиков

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

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

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

Затем вы сохраняете свою DLL на другом сервере, доступ к которому есть только у вас, и прокси-DLL вызывает ее через какой-то протокол удаленного взаимодействия.

Это странное положение ... мои соболезнования.

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

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

Изменить: на основе комментариев OP, вот обновленный ответ.

Если вы просто беспокоитесь о том, что они украдут DLL, которую вы помещаете в папку bin на своем веб-сервере, просто опубликуйте ее во вложенной папке \ bin, заблокируйте папку с помощью разрешений Windows, чтобы они не могли попасть в его и измените свой web.config, чтобы проверить его.

<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin;bin\mysubfolder;" />
   </assemblyBinding>
</runtime>

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

Связанный: https://stackoverflow.com/questions/181991/suggest-a-good-obfuscator-for-net-closed.
Возможно, вы захотите выборочно запутать свой код (оставьте общедоступные API как есть)

Вы можете попросить dll поговорить с доверенным третьим лицом (которым, вероятно, будет сервер, которым вы будете управлять), чтобы немного пожать руку, чтобы убедиться, что он должен работать.

Что-то вроде

A. Hey, I'm sitting at [hostname->taken from env vars], can i do my job?
B. (checks records of registered hosts)  Yes you can.
A. Thanks.  (does what it does best)

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

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

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

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

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

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

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

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

Я обнаружил, что Keylok предлагает конкурентоспособный продукт по доступной цене, и я настоятельно рекомендую. Еще предстоит увидеть, как защитить вызовы API в PHP, код которого не является двоичным и не запутанным. Я не предвижу никаких проблем с DLL.

Я был менеджером проекта в компании, которая защищала свое программное обеспечение для интеграции SAP с помощью таких ключей. Конечным продуктом был компакт-диск с кодом, руководством по установке, ключом и лицензионным счетом на 200 тысяч долларов. Сладкий !!! Это было 10 лет назад, и я еще не слышал от них никаких историй о пиратстве или нарушении авторских прав!

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