Это похоже на странную позицию, но я все равно позвоню.
Я создал несколько DLL файлов, которые создают волшебный mumbo-jumbo, необходимый для отображения содержимого для веб-сайта, который я сейчас делаю в ASP.Net. У меня есть небольшая команда разработчиков, которые могут мне помочь, но я боюсь, что они украдут мой код (DLL) и будут использовать его в проектах, когда они покинут мою компанию. В программном обеспечении я могу, вероятно, доказать, что они используют мою DLL для генерации контента, но на сервере, где библиотеки DLL недоступны для общественности, я не могу.
Таким образом, несмотря на то, что у меня есть команда, я работаю над этим в одиночку.
Мой вопрос. Есть ли способ, которым вы можете думать о том, как я могу защитить свою DLL (которая входит в папку bin), чтобы мои кодеры не могли ее украсть или она становится непригодной для украденного.
Я просто хочу защитить все, что попадает в папку bin.
Вы могли бы проверить dll свою среду и не работать (я предлагаю вам заставить ее давать неправильные результаты, а не ломаться), если среда не похожа на домашнюю. Вам также придется запутывать код, чтобы помешать усилиям по удалению защиты.
Изменить: вы можете использовать переменную окружения, ключ реестра, наличие счетчика производительности, непонятную настройку в файле machine.config и т.д. и сделать его похожим на подлинную настройку, а затем запутать и подписать с сильным именем.
Это может быть несовместимо с вашей ситуацией, но вы можете предоставить им прокси-библиотеку DLL, которая не выполняет вычисления, а вместо этого называет вашу DLL.
Затем вы сохраняете свою DLL на другом сервере, к которому только вы имеете доступ, и прокси-библиотека вызывает его через какой-то протокол удаленного доступа.
Это странная позиция, которая должна быть в моих... соболезнованиях.
На уровне .Net лучшее, что вы можете сделать, - это обфускацию кода при его создании. Сильно подписав вашу сборку, вы узнаете, происходит ли подделка.
Другой подход, который некоторые люди сделали, - это написать действительно чувствительный код на С++ и скомпилировать его в неуправляемую .dll и вызвать его из .net с помощью interop. С++ bytecode гораздо труднее читать, чем 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)
изменить: Грубо, если кто-то еще знает, что вы это делаете, они могут привязать удаленный адрес к выбранной им машине... в этот момент вы действительно не исправили свою оригинальную проблему.
Я не знаю много о правовой системе в Индии, но убедитесь, что вы заставляете их подписывать какую-то форму NDA, и дайте им понять, что вы считаете это серьезным и будете подавать в суд на них, если они нарушают его.
И, если возможно, выставляйте свою DLL только через службу Windows или COM-сервер вне процесса, чтобы вы могли изолировать свою DLL, где они не могут получить к ней доступ напрямую.
Если у них есть физический доступ к вашей DLL, и они полные компетентные разработчики, то, вероятно, не так много, что вы действительно можете сделать с технологической точки зрения, чтобы фактически предотвратить их использование. Вы можете замедлить их немного, но неизбежно они получат то, что хотят, если у них есть доступ к двоичному. Отказ в доступе к двоичному файлу - единственный эффективный способ предотвратить его.
Однако, если DLL обрабатывает пользовательский ввод каким-либо образом и предоставляет контент для отображения в результате, тогда вы можете ввести какое-то "пасхальное яйцо", которое выведет отдельную подпись какого-то типа, основанную на некоторых неясных, но конкретных вход. В зависимости от правовой системы, которая может быть достаточно хорошей, чтобы открыть расследование и заставить их предоставить доступ к следователям, чтобы доказать, что они не крадут ваши технологии. Если они этого не знают, они, вероятно, не будут искать его и отключить, прежде чем у вас будет возможность его вызвать.
Я бы создал веб-сервис на защищенном сервере, который будет раскрывать функции вашей DLL. После завершения разработки вы можете изменить части кода, вызывающие веб-службу, для прямого вызова DLL.
Я соглашаюсь с стратегией LachlanG распространять прокси-библиотеку вместо того, чтобы предоставить вашим разработчикам доступ к производственной, которая легко может быть взломана и изменена.
Еще один вариант, который вы можете изучить, - это "защитить" вашу DLL. Я наткнулся на ваш вопрос, исследуя решение моей проблемы. Я изучаю этот параметр, так как я нахожусь в том же месте, но с еще более уязвимым решением на базе PHP.
Я обнаружил, что Keylok предлагает конкурентоспособный продукт по доступной цене, которую я очень рассматриваю. Еще не видно, как защитить вызовы API в PHP, код которых не является двоичным и не запутывается. Я не предвижу никаких проблем с DLL.
Я был менеджером проекта для компании, которая защищала их программное обеспечение интеграции SAP с помощью этих ключей. Конечным продуктом был компакт-диск с кодом, руководством по установке, ключом и лицензионным счетом за 200 000 долларов. Sweeet!!! Это было 10 лет назад, и я еще не слышал о каких-либо пиратских или авторских нарушениях.
Надеюсь, это поможет.